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

Заменен RFC 9301.

Заменен RFC 9302.

Заменен RFC 9300 и RFC 9301.

Internet Engineering Task Force (IETF)                          Q. Vohra
Request for Comments: 6793                              Juniper Networks
Obsoletes: 4893                                                  E. Chen
Updates: 4271                                              Cisco Systems
Category: Standards Track                                  December 2012
ISSN: 2070-1721

Поддержка 4-октетных номеров АС в протоколе BGP

BGP Support for Four-Octet Autonomous System (AS) Number Space

PDF

Аннотация

Номера автономных систем (AS¹) а базовой спецификации BGP представлены 2-октетными значениями. Этот документ описывает расширение BGP для использования 4-октетных номеров AS. Документ отменяет действие RFC 4893 и обновляет RFC 4271.

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

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

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

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

В базовой спецификации BGP [RFC4271] номера AS представляются 2-октетными значениями. Для решения проблемы нехватки двухоктетных номеров AS в этом документе предлагается расширение протокола BGP, позволяющее использовать 4-октетные номера AS.

Говоря точнее, этот документ определяет новую возможность протокола BGP — Four-octet AS Number Capability, которая может использоваться узлом BGP для индикации поддержки этим узлом четырехоктетных номеров AS. Для реализации новой возможности добавляются два новых атрибута AS4_PATH и AS4_AGGREGATOR, которые могут использоваться для распространения 4-октетных номеров AS в атрибутах пути между узлами BGP, которые не поддерживают этого расширения. В документе также предложен механизм представления информации о путях с использованием атрибутов AS_PATH и AS4_PATH.

Предложенное в этом документе расширение протокола обеспечивает возможность постепенного перехода к использованию 4-октетных номеров AS.

Этот документ отменяет действие RFC 4893 и обновляет RFC 4271. Он также включает некоторые разъяснения и редакторские правки, а также задает обработку ошибок для новых атрибутов.

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

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

3. Расширения протокола

В этом документе узлы BGP, не поддерживающие 4-октетные номера AS, будет называться старыми узлами BGP, а поддерживающие расширение узлы — новыми узлами BGP.

BGP передает номера автономных систем в поле My Autonomous System сообщений OPEN, а также в атрибутах AS_PATH и AGGREGATOR сообщений UPDATE. Кроме того, номера автономных систем BGP включаются в атрибуты BGP Communities.

Новые узлы BGP используют BGP Capability Advertisement [RFC5492] для анонсирования своим соседям (внутренним или внешним) поддержки 4-октетных номеров AS, описанной в данном документе.

Возможность (Capability), используемая узлом BGP для передачи другим узлам BGP информации о поддержке 4-октетных номеров AS, также использует передачу 4-октетного номера AS данного узла в поле Capability Value. Поле Capability Length для Capability имеет значение 4.

Новые узлы BGP передают информацию о пути в виде 4-октетных номеров AS с использованием существующего атрибута AS_PATH, но каждый номер AS в таком атрибуте представляется 4-октетным значением вместо 2-октетного. Для атрибута AGGREGATOR новые узлы BGP также используют 4-октетные номера AS вместо 2-октетных.

Атрибуты AS_PATH и AGGREGATOR между новыми и старыми узлами BGP по-прежнему передаются с 2-октетными номерами AS.

Для передачи информации о пути с 4-октетными номерами через старые узлы BGP в данном документе определен новый атрибута пути — AS4_PATH. Этот дополнительный переходный атрибут содержит значение AS path, представленное 4-октетными номерами AS. Атрибут AS4_PATH семантически не отличается от атрибута AS_PATH, но относится к числу дополнительных переходных атрибутов и использует 4-октетные номера AS.

Для предотвращения возможности распространения внутренних сегментов путей конфедераций за пределы этих конфедераций, типы сегментов пути AS_CONFED_SEQUENCE и AS_CONFED_SET [RFC5065] для атрибута AS4_PATH считаются некорректными и их недопустимо включать в атрибуты AS4_PATH сообщение UPDATE.

Аналогично, этот документ определяет дополнительный переходный атрибут AS4_AGGREGATOR. Семантика атрибутов AS4_AGGREGATOR и AGGREGATOR одинакова, но первый использует 4-октетный номер AS.

Выделенные к настоящему времени 2-октетные номера AS преобразуются в 4-октетные номера AS путем установки в 0 двух старших октетов номера. Такие 4-октетные номера AS могут быть отображены на 2-октетные номера AS и называются отображаемыми (mappable).

Для представления 4-октетных номеров AS с отличными от 0 старшими октетами (такие номера не отображаются на 2-октетные) в информации AS path, содержащей 2-октетные номера AS, в настоящем документе резервируется специальный 2-октетный номер AS. Этот специальный номер AS в оставшейся части спецификации будет обозначаться AS_TRANS. Номер AS_TRANS также включается в поле «My Autonomous System» сообщений OPEN, инициируемых новым узлом BGP, если последний не имеет уникального в глобальном масштабе 2-октетного номера AS.

4. Операции

4.1. Взаимодействие между новыми узлами BGP

Узлам BGP, поддерживающим 4-октетные номера AS, нужно анонсировать эту возможность с использованием анонсов BGP Capability. Номер AS узла BGP должен передаваться в поле возможности поддержки 4-октетных номеров AS.

Когда новый узел BGP обрабатывает сообщение OPEN от нового узла BGP, он должен использовать номер AS из поля Capability Value возможности поддержки 4-октетных номеров AS вместо значения поля My Autonomous System из сообщения OPEN.

Узел BGP, который анонсировал тому или иному партнеру такую возможность и получил от партнера аналогичный анонс, должен использовать 4-октетные номера AS в атрибутах AS_PATH и AGGREGATOR обновлений, передаваемых этому партнеру, а в принятых от того обновлениях должен рассматривать эти атрибуты, как содержащие 4-октетные номера AS.

Новые атрибуты AS4_PATH и AS4_AGGREGATOR недопустимо передавать в сообщениях UPDATE между новыми узлами BGP. Новый узел BGP, получивший атрибут AS4_PATH или AS4_AGGREGATOR в сообщении UPDATE от нового узла BGP, должен отбросить эти атрибуты и продолжить обработку сообщения UPDATE.

4.2. Взаимодействие между новыми и старыми узлами BGP

4.2.1. Партнерство BGP

Отметим, что партнерские отношения между новым и старым узлами BGP возможны только в том случае, когда новый узел BGP имеет 2-октетный номер AS. Однако в этом документе не предполагается, что каждому новому узлу BGP требуется выделить уникальный 2-октетный номер AS — вместо этого при отсутствии у нового узла 2-октетного номера должен применяться специальный номер AS_TRANS, который может использоваться множеством AS одновременно.

4.2.2. Генерация обновлений

При взаимодействии со старыми узлами BGP новый узел должен передавать информацию о пути в атрибутах AS_PATH с 2-октетными номерами AS. Новый узел должен также передавать информацию о пути в атрибутах AS4_PATH (с 4-октетными номерами AS) за исключением тех случаев, когда вся информация о пути представлена 4-октетными отображаемыми номерами AS. В последнем случае новому узлу BGP недопустимо передавать атрибут AS4_PATH.

В атрибуте AS_PATH с 2-октетными номерами AS, неотображаемые 4-октетные номера AS представляются общеизвестным 2-октетным номером AS_TRANS. Это позволяет сохранить размер пути и помогает обновить информацию о пути полученную новым узлом BGP от старого узла, как описано в следующем параграфе.

Новый узел BGP создает атрибут AS4_PATH из информации в пути AS. В случаях, когда информация пути AS содержит сегменты пути AS_CONFED_SEQUENCE или AS_CONFED_SET, новый узел BGP при создании атрибута AS4_PATH должен исключить такие сегменты пути.

Атрибут AS4_PATH (будучи необязательным переходным) будет передаваться через старые узлы BGP без изменения и поможет сохранить неотображаемые 4-октетные номера AS в информации о пути AS.

Подобно этому, если новый узел передает атрибут AGGREGATOR и агрегирующая AS имеет неотображаемый 4-октетный номер, узел должен использовать атрибут AS4_AGGREGATOR и устанавливать в поле номера AS имеющегося атрибута AGGREGATOR зарезервированное значение AS_TRANS. Отметим, что для отображаемого номера AS передавать атрибут AS4_AGGREGATOR недопустимо.

4.2.3. Обработка полученных обновлений

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

Отметим, что маршрут может проходить через последовательность автономных систем с 2-октетными номерами, в которых используются только старые узлы BGP. В этом случае, если маршрут содержит атрибут AS4_PATH, этот атрибут должен сохраняться в неизменном виде после того, как маршрут покинет последний новый узел BGP. Последующая информация о пути (представляющая автономные системы с 2-октетными номерами AS и только старыми узлами BGP) содержится только в текущем атрибуте AS_PATH (начальная часть атрибута AS_PATH).

При некоторых условиях восстановление полной информации о пути из атрибутов AS_PATH и AS4_PATH может оказаться невозможным. Это происходит в тех случаях, когда два или более маршрута, содержащие атрибут AS4_PATH, агрегируются старым узлом BGP, а атрибут AS4_PATH хотя бы одного из таких маршрутов содержит по крайней мере один 4-октетный номер AS (в противоположность 2-октетному номеру AS, представленному 4 октетами). В зависимости от реализации при агрегировании может быть потерян атрибут AS4_PATH или оба атрибута AS_PATH и AS4_PATH будут содержать корректную частичную информацию, которая не может быть объединена без разрывов, приводящих к неполноте информации о пути.

Новый узел BGP должен также быть готов к получению от старого узла BGP атрибута AS4_AGGREGATOR вместе с атрибутом AGGREGATOR. При получении обоих атрибутов, если номер AS в атрибуте AGGREGATOR не совпадает с AS_TRANS:

• атрибуты AS4_AGGREGATOR и AS4_PATH нужно игнорировать;

• атрибут AGGREGATOR нужно трактовать как информацию об агрегирующем узле;

• атрибут AS_PATH нужно трактовать как информацию о пути.

В остальных случаях:

• атрибут AGGREGATOR нужно игнорировать;

• атрибут AS4_AGGREGATOR нужно трактовать как информацию об агрегирующем узле;

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

Для конструирования информации о пути необходимо сначала рассчитать номера AS в атрибутах AS_PATH и AS4_PATH с использованием метода, описанного в параграфе 9.1.2.2 документа [RFC4271] и документе [RFC5065] для выбора маршрута.

Если число номеров AS в атрибуте AS_PATH меньше числа номеров AS в AS4_PATH, атрибут AS4_PATH нужно игнорировать, а атрибут AS_PATH нужно трактовать как информацию о пути.

Если число номеров AS в атрибуте AS_PATH больше или равно числу номеров AS в AS4_PATH, информацию о пути нужно восстанавливать, принимая столько номеров AS и сегментов пути из атрибута AS_PATH, сколько требуется и добавляя их в начало (prepend) атрибута AS4_PATH так, чтобы в результате число номеров AS в информации о пути совпадало с числом номеров AS в атрибуте AS_PATH. Отметим, что перед корректными сегментами пути AS_CONFED_SEQUENCE или AS_CONFED_SET нужно добавлять (prepend) информацию, если сегмент является первым в пути или смежным с сегментом, перед которым добавляется информация.

5. Обслуживание групп BGP

Как отмечено в [RFC1997], два старших октета атрибута группы (community attribute) не могут принимать значения 0x0000 или 0xffff, в этих двух октетах указывается номер AS. Понятно, что это условие не будет работать для узлов BGP, которые используют 4-октетные номера AS. Таким узлам BGP следует использовать специальное расширение Four-octet AS Specific Extended Communities [RFC5668] .

6. Обработка ошибок

Этот раздел обновляет RFC 4271 [RFC4271] в части обработки ошибок.

Исходя из доминирования 2-октетных номеров AS в процессе перехода и их использования в атрибуте AS_PATH старыми узлами BGP, в этом документе выбрано отбрасывание атрибутов (attribute discard) для обработки атрибутов AS4_PATH с некорректным форматом.

Поскольку атрибут AS4_AGGREGATOR является лишь информационным, для некорректно сформированных атрибутов AS4_AGGREGATOR также выбрано отбрасывание.

Атрибуты AS4_PATH и AS4_AGGREGATOR недопустимо передавать в сообщениях UPDATE между новыми узлами BGP. Новый узел BGP при получении атрибута AS4_PATH или AS4_AGGREGATOR в сообщении UPDATE от другого нового узла BGP должен отбросить атрибут пути и продолжить обработку сообщения UPDATE. Такие случаи следует отмечать в системном журнале для анализа.

Кроме того, сегменты пути типов AS_CONFED_SEQUENCE и AS_CONFED_SET [RFC5065] недопустимо передавать в атрибуте AS4_PATH сообщения UPDATE. Новый узел BGP, получивший такой сегмент пути в атрибуте AS4_PATH сообщения UPDATE от старого узла BGP, должен отбросить эти сегменты пути, скорректировав соответствующие поля атрибутов, и продолжить обработку сообщения UPDATE. Такие случаи следует отмечать в системном журнале для анализа.

Атрибут AS4_PATH в сообщении UPDATE нужно считать сформированным некорректно при выполнении любого из перечисленных ниже условий:

• размер атрибута не кратен 2 или слишком мал (меньше 6) для атрибута, который должен включать хотя бы один номер AS;

• размер сегмента пути в атрибуте равен 0 или не соответствует размеру атрибута;

• тип сегмента пути в атрибуте не относится к AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE или AS_CONFED_SET.

Новый узел BGP, получивший некорректно сформированный атрибут AS4_PATH в сообщении UPDATE от старого узла BGP, должен отбросить атрибут и продолжить обработку сообщения UPDATE. Такие случаи следует отмечать в локальном системном журнале для анализа.

Атрибут AS4_AGGREGATOR в сообщении UPDATE нужно считать некорректно сформированным, если размер атрибута отличается от 8.

Новый узел BGP, получивший некорректно сформированный атрибут AS4_AGGREGATOR в сообщении UPDATE от старого узла BGP, должен отбросить атрибут и продолжить обработку сообщения UPDATE. Такие случаи следует отмечать в локальном системном журнале для анализа.

7. Переход

Когда AS использует 2-октетный номер, узлы BGP в этой AS могут поэтапно обновляться для поддержки 4-октетных номеров. В этом случае не предъявляется требований к координации обновления. Однако, если AS хочет использовать 4-октетное значение в качестве своего номера, в этом документе предполагается, что такое возможно лишь после полного обновления всех узлов BGP в данной AS для поддержки 4-октетных номеров AS.

Неотображаемые 4-октетные номера AS не могут использоваться в качестве Member AS Number для конфедерации BGP, пока все узлы BGP в этой конфедерации не перейдут к использованию 4-октетных номеров AS.

В среде, где AS со старыми узлами BGP имеет партнерские отношения с двумя или более AS, включающими новые узлы BGP, и использует AS_TRANS (а не уникальный в глобальном масштабе отображаемый номер AS), использование атрибута MULTI_EXIT_DISC [RFC4271] автономной системой со старыми узлами BGP может приводить к ситуации, когда атрибут MULTI_EXIT_DISC будет влиять на выбор среди маршрутов, полученных из других соседних AS.

В некоторых условиях реконструирование полной информации о пути из атрибутов AS_PATH и AS4_PATH может оказаться невозможным. Это происходит в тех случаях, когда по крайней мере два маршрута, передающих атрибут AS4_PATH, агрегируются старым узлом BGP и атрибут AS4_PATH по крайней мере одного из таких маршрутов содержит хотя бы один 4-октетный номер AS (в противоположность 2-октетным номерам, представленным 4 октетами). Когда такое агрегирование приводит к созданию маршрута, являющегося менее конкретным, чем любая из компонент агрегирования (значение NLRI⁴ агрегированного маршрута покрывает NLRI всех компонент), потеря информации о пути не создает риска возникновения петли. В остальных случаях потеря информации о пути может приводить к возникновению маршрутной петли.

8. Вопросы управляемости

Если поддерживается BGP4-MIB [RFC4273], не возникает дополнительный вопросов управляемости в результате использования 4-октетных номеров AS, поскольку текстовое соглашение InetAutonomousSystemNumber [RFC4001] определено как Unsigned32.

При поддержке IPFIX⁵ [RFC5101] не возникает дополнительный вопросов управляемости в результате использования 4-октетных номеров AS. Информационные элементы bgpSourceAsNumber и bgpDestinationAsNumber [IANA-IPFIX] могут по-прежнему применяться, поскольку в новом шаблоне для них задан размер 4 октета.

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

Этот документ расширяет пространство номеров AS с 0 — 65535 до 0 — 4294967295. Распределение номеров AS фиксируется в реестре IANA Autonomous System Numbers. Кроме расширения пространства номеров AS в данном документе не предлагается каких-либо изменений существующих правил и процедур распределения номеров AS.

Этот документ использует код BGP Capability для индикации поддержки узлом BGP 4-октетных номеров AS. Выделенное IANA в соответствии с [RFC5492] значение кода равно 65.

Кроме того, в этом документе определены два новых дополнительных переходных атрибута BGP, коды которых назначены IANA. Для атрибута AS4_PATH выделено значение 17, которое используется для передачи информации AS path с 4-октетными номерами AS через старые системы BGP. Для второго атрибута AS4_AGGREGATOR выделено значение 18. Этот атрибут используется подобно AGGREGATOR, но содержит 4-октетный номер AS.

Этот документ заменяет ссылку на RFC 4893 ссылкой на данный документ в части резервирования 2-октетного номера AS_TRANS (23456). Агентство IANA заменило ссылку на RFC 4893 ссылкой на данный документ в реестре 32-bit Autonomous System Numbers.

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

Это расширение BGP не меняет состояния безопасности существующего протокола BGP за исключением указанного ниже.

Несогласованность атрибутов AS_PATH и AS4_PATH может приводить к возникновению петель в информации AS path и, потенциально, в маршрутах, как отмечено выше. Эта особенность может быть использована для организации атак.

Будет конфигурационной ошибкой назначение неотображаемых 4-октетных номеров AS в качестве Member AS Number в BGP Confederation до того, как все узлы BGP в конфедерации начнут поддерживать 4-октетные номера AS. Такие конфигурационные ошибки ослабляют возможности обнаружения петель в путях AS внутри конфедерации.

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

Авторы благодарят Yakov Rekhter, Chaitanya Kodeboyina и Jeffrey Haas за плодотворные дискуссии при подготовке документа.

Авторы также благодарны участникам рабочей группы IDR за их рецензии и комментарии.

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

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

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, August 1996.

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

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC5065] Traina, P., McPherson, D., and J. Scudder, «Autonomous System Confederations for BGP», RFC 5065, August 2007.

[RFC5492] Scudder, J. and R. Chandra, «Capabilities Advertisement with BGP-4», RFC 5492, February 2009.

[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, «4-Octet AS Specific BGP Extended Community», RFC 5668, October 2009.

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

[IANA-IPFIX] IANA, «IP Flow Information Export (IPFIX) Entities», <http://www.iana.org/assignments/ipfix>.

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, «Textual Conventions for Internet Network Addresses», RFC 4001, February 2005.

[RFC4273] Haas, J., Ed., and S. Hares, Ed., «Definitions of Managed Objects for BGP-4», RFC 4273, January 2006.

[RFC5101] Claise, B., Ed., «Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information», RFC 5101, January 2008.

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

Quaizar Vohra

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

USA

EMail: quaizar.vohra@gmail.com

Enke Chen

Cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

USA

EMail: enkechen@cisco.com

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                    Z. Shelby, Ed.
Request for Comments: 6775                                     Sensinode
Updates: 4944                                             S. Chakrabarti
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                              E. Nordmark
                                                           Cisco Systems
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                           November 2012

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

Допущения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот документ предполагает знакомство читателя с терминами и концепциями Neighbor Discovery for IP version 6 (IPv6) [RFC4861], IPv6 Stateless Address Autoconfiguration [RFC4862], IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals [RFC4919], Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944], IP Addressing Model in Ad Hoc Networks [RFC5889]. В документе применяется терминология [RFC4861], если ниже не приведено другое определение термина.

6LoWPAN link — канал 6LoWPAN

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

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

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

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

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

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

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

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

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

Mesh-under

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

Route-over

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

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

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

IP-over-foo document

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tentative — проба

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

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

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

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

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

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

4.1. Опция ARO

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

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

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

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length = 2  |    Status     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                            EUI-64                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

33

Length

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

Status

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

Reserved

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

Registration Lifetime

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

EUI-64

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

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

Статус	Описание
0	Успех
1	Дубликат адреса
2	Переполнение кэша соседей
3-255	Выделяются по процедуре Standards Action [RFC5226]

4.2. Опция 6CO

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |Context Length | Res |C|  CID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |         Valid Lifetime        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                       Context Prefix                          .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Type

34

Length

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

Context Length

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

C

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

CID

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

Res, Reserved

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

Valid Lifetime

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

Context Prefix

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

4.3. Опция ABRO

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

Опция ABRO должна включаться во все сообщения RA, если эти сообщения служат для распространения информации между маршрутизаторами, как описано в параграфе 8.2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  Length = 3   |          Version Low          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Version High         |        Valid Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                          6LBR Address                         +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

35

Length

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

Version Low, Version High

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

Valid Lifetime

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

Reserved

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

6LBR Address

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

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

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Status     |   Reserved    |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                            EUI-64                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Registered Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

IPv6 Source

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

IPv6 Destination

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

Hop Limit

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

Поля ICMP

Type

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

Code

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

Checksum

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

Status

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

Reserved

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

Registration Lifetime

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

EUI-64

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

Registered Address

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

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

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

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

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

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

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

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

5.3. Отправка RS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.5.1. Передача NS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1.5. Отправка RA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ICMP Code = 0;

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

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

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

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

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

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

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

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

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

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

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

• MULTIHOP_HOPLIMIT в поле IPv6 Hop Limit4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Константа 6LBR

MIN_CONTEXT_CHANGE_DELAY+

300 секунд

Константы 6LR

MAX_RTR_ADVERTISEMENTS

3 передачи

MIN_DELAY_BETWEEN_RAS*

10 секунд

MAX_RA_DELAY_TIME*

2 секунды

TENTATIVE_NCE_LIFETIME+

20 секунд

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

MULTIHOP_HOPLIMIT+

64

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

RTR_SOLICITATION_INTERVAL*

10 секунд

MAX_RTR_SOLICITATIONS

3 передачи

MAX_RTR_SOLICITATION_INTERVAL+

60 секунд

10. Примеры

10.1. Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LL64

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

GP16

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

GP64

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

MAC64

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

MAC16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Address Registration Option (33);

• 6LoWPAN Context Option (34);

• Authoritative Border Router Option (35).

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

• Duplicate Address Request (157);

• Duplicate Address Confirmation (158).

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

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

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

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

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

Статус	Описание
0	Успех
1	Дубликат адреса
2	Переполнение кэша соседей
3-255	Выделяются по процедуре Standards Action [RFC5226]

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

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

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

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

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

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

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

Параграф	Описание	Развёртывание	Реализация
3.1	RA по инициативе хоста	должно	должно
3.2	Адрес IPv6 на основе EUI-64	должно	должно
	16-битовый адрес на основе MAC	может	следует
	Иные неуникальные адреса	может	может
3.3	RS по инициативе хоста	должно	должно
	Обработка ABRO	следует	должно
4.1	Регистрация с опцией ARO	должно	должно
4.2, 5.4	6CO	следует	следует
5.2	Присоединение к группе solicited-node	—	—
	Присоединение к группе all-nodes	должно	должно
	Использование данных канального уровня для NUD	может	может
5.5	6LoWPAN-ND NUD	должно	должно
5.8.2	Поведение при пробуждении	следует	следует

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

Параграф	Описание	Развёртывание	Реализация
3.1	Периодические RA	не следует	не следует
3.2	Назначение адреса при старте	следует	должно
3.3	Поддержка MAC хостов на основе EUI-64	должно	должно
	Поддержка 16-битовых MAC хостов	может	следует
3.4, 4.3, 8.1.3, 8.1.4	Передача и обработка ABRO	следует	должно
8.1	Сохранение и распространение префиксов через узлы пересылки	следует	должно
3.5	Tentative NCE	должно	должно
8.2	Multihop DAD	следует	должно
4.1, 6.5, 6.5.1 — 6.5.5	Поддержка ARO	должно	должно
4.2	6CO	следует	следует
6.3	Обработка RS/ABRO	должно	должно

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

Параграф	Описание	Развёртывание	Реализация
3.1	Периодические RA	не следует	не следует
3.2	Автоматическая настройка адреса на интерфейсе маршрутизатора	недопустимо	недопустимо
3.3	Поддержка EUI-64 MAC на интерфейсе 6LoWPAN	должно	должно
8.1 — 8.1.1, 8.1.5	Распространение префиксов через узлы пересылки	следует	должно
8.2	DAD через узлы пересылки	следует	должно

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

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

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

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

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

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

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

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460⁴, December 1998.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, «IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals», RFC 4919, August 2007.

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

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

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

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

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

Zach Shelby (editor)

Sensinode

Konekuja 2

Oulu 90620

Finland

Phone: +358407796297

EMail: zach@sensinode.com

Samita Chakrabarti

Ericsson

EMail: samita.chakrabarti@ericsson.com

Erik Nordmark

Cisco Systems

EMail: nordmark@cisco.com

Carsten Bormann

Universitaet Bremen TZI

Postfach 330440

Bremen D-28359

Germany

Phone: +49-421-218-63921

EMail: cabo@tzi.org

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

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

nmalykh@protokols.ru

Этот документ заменен RFC 8077.

Internet Engineering Task Force (IETF)                         A. Morton
Request for Comments: 6673                                     AT&T Labs
Category: Standards Track                                    August 2012
ISSN: 2070-1721

Round-Trip Packet Loss Metrics

Показатель потерь при круговом обходе

PDF

Аннотация

Многие пользовательские приложения (и транспортные протоколы, делающие их возможными) требуют двухстороннего обмена. Для оценки такой возможности и упрощения систем тестирования на практике часто применяют измерение потерь при круговом обходе. Протокол двухсторонних активных измерений TWAMP (Two-Way Active Measurement Protocol), заданный в RFC 5357, позволяет измерить потери при круговом обходе в Internet. Однако в настоящее время нет показателей потерь при круговом обходе в соответствии с моделью RFC 2330.

Этот документ определяет показатели потерь при круговом обходе (IP Performance Metrics или IPPM).

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

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

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

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

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

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

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

1. Введение

Документ определяет показатель для количественной оценки способности сети IP передавать пакеты в обоих направлениях от одного хоста к другому. Двухсторонняя связь требуется почти всегда, поэтому отказ при передаче в любом из направлений ведёт к потерям при круговом обходе (round-trip packet loss).

Документ определяет показатель круговых потерь на путях Internet, основанный на понятиях и соглашениях модели показателей производительности IP (IP Performance Metrics или IPPM) [RFC2330]. В документе часто упоминаются и изменяются в соответствии с рассматриваемым здесь двухсторонним обменом показатели потерь в одном направлении [RFC2680] и круговой задержки [RFC2681] для IPPM. Предполагается, что читатель знаком с упомянутыми документами, поэтому материал из [RFC2681] здесь не дублируется.

Термины двухсторонний (two-way) и круговой (round-trip) применяются в документе как синонимы.

1.1. Мотивация

Многим пользовательским приложениям и поддерживающим их транспортным протоколам требуется двухстороннее взаимодействие. Например, трёхстороннее согласование TCP SYN->, <-SYN-ACK, ACK->, используемое постоянно, не может завершиться без двухсторонней связности примерно с одинаковыми временными параметрами для каждого направления. Таким образом, измерение круговых потерь в Internet обеспечивает основу для определения производительности приложений.

Разработчики измерительных систем также признали преимущества простоты решений, где хост просто возвращает (отражает) тестовые пакеты отправителю. Измерения круговых потерь пакетов часто выполняются на практике. Широко используемый инструмент ping позволяет измерить круговую задержку и потери, но обычно требует поддержки ICMP Echo-Request/Reply, а для пакетов ICMP на пути измерения может применяться особая обработка (см. параграф 2.6 в [RFC2681]). Протокол двухсторонних активных измерений TWAMP, предложенный в [RFC5357] обеспечивает возможность измерения круговых потерь в Internet. Однако в настоящее время нет показателя для круговых потерь, соответствующего модели [RFC2330].

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

В [RFC2681] также указано, что последовательное измерение путей в каждом направлении, указываемое как круговое измерение, может дать именно желаемые показатели. С другой стороны, может оказаться сложным определить круговые потери из односторонних измерений в каждом направлении, если заранее не согласовать метод соответствующих односторонних измерений.

Многие измерительные системы указывают статистику условного распределения задержки. Это приведено в [RFC3393], [RFC5481], [RFC6703]. В результате о потере пакетов нужно сообщать отдельно, в соответствии со стандартизованными показателями. Этот документ определяет такие показатели.

Дополнительная мотивация для показателей потери пакетов приведена в параграфе 1.1 [RFC2680].

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

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

2. Область действия

Этот документ определяет показатель круговых потерь на основе соглашений модели IPPM [RFC2330].

Документ определяет одиночное измерение, выборку и статистику, как в [RFC2330]. Модель [RFC2330] предназначена для активных методов. Хотя описанные показатели можно применить и к пассивным измерениям, рассмотрение пассивных измерений выходит за рамки нормативной части документа.

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

3. Общие спецификации показателей кругового обхода

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

3.1. Type-P-*

Все показатели используют соглашение Type-P, как описано в [RFC2330]. Остальная часть имени уникальна для каждого показателя.

3.2. Параметры показателя

Src — IP- адрес хоста

Dst — IP- адрес хоста

T — время начала теста

Tf — время завершения теста

lambda — скорость в 1/сек (для потоков Пуассона)

incT — номинальная продолжительность интервала следования пакетов (от первого бита до первого бита, для периодических потоков)

T0 — время, которое должно случайно выбираться из интервала [T, T+dT] для запуска генерации пакетов и проведения измерений (для периодических потоков)

TstampSrc — время в линии (wire time) для пакета, измеренное в MP(Src) при отправке для Dst

TstampDst — время в линии, измеренное в MP(Dst), которое присваивается пакетам, прибывшим в «разумное» время (меньше Tmax)

Tmax — максимальное время ожидания прибытия пакетов в Src, достаточно большое, чтобы отличить задержку пакета от потери (отбрасывания)

M — общее число пакетов, переданных между T0 и Tf

N — общее число пакетов, полученных в Dst (переданы между T0 и Tf)

Type-P в соответствии с [RFC2330] включает любые поля, которые могут влиять на обработку пакета при прохождении через сеть.

3.3. Определение показателя

Сведения, относящиеся к конкретному показателю.

3.4. Единицы измерения

Единицы измерения являются логическими (1 или 0) при описании потери одного пакета, где 0 указывает успешную передачу пакета, 1 — потерю.

Единицы времени заданы в [RFC2330].

Другие единицы измерения при необходимости определяются в соответствующих параграфах (например, параграф 6.1 для Type-P-Round-trip-Loss-<Sample>-Ratio).

4. Показатель одиночного измерения потерь

4.1. Имя показателя

Type-P-Round-trip-Loss

4.2. Параметры показателя

См. параграф 3.2.

4.3. Определение и единицы измерения

Type-P-Round-trip-Loss нужно представлять двоичными логическими значениями (или их эквивалентами) с учётом приведённых ниже условий.

Type-P-Round-trip-Loss = 0:

• Src передаёт первый бит пакета Type-P получателю Dst в момент TstampSrc;

• Dst получает этот пакет;

• Dst передаёт пакет Type-P обратно Src как можно быстрее (конечно меньше Tmax и достаточно быстро для предусмотренной цели);

• Src получает первый бит отражённого пакета до времени в линии TstampSrc + Tmax.

Type-P-Round-trip-Loss = 1:

• Src передаёт первый бит пакета Type-P получателю Dst в момент TstampSrc;

• после этого Src не получает последнего бита отражённого пакета до истечения момента TstampSrc + Tmax.

Возможными причинами установки Loss = 1 могут быть:

• Dst не получил пакет;

• Dst не передал пакет Type-P обратно Src

• Src не получил отражённого пакета Type-P от Dst.

Следуя прецеденту из параграфа 2.4 в [RFC2681], принимается упрощение, что круговые потери, измеренные между двумя хостами, равны, независимо от того, какой из хостов начинает тест

Type-P-Round-trip-Loss(Src->Dst->Src) = Type-P-Round-trip-Loss(Dst->Src->Dst)

(согласитесь, что это скромная плата за эффективность измерения).

Таким образом, каждое одиночное измерение (singleton) можно представить парой элементов, как показано ниже.

• TstampSrc — время в линии для пакета в Src (начало кругового обмена).

• L — 0 или 1 (или некоторый эквивалент), где L=1 указывает потерю, а L=0 — успешный круговой обход до момента TstampSrc + Tmax.

4.4. Обсуждение и другие детали

В [RFC2680] и [RFC2681] рассмотрены методы измерения, ошибки и погрешности, а также другие фундаментальные вопросы, которые не повторяются здесь. Мы добавляем рекомендацию относящуюся к процессу ответчика по «отправке пакета Type-P обратно Src как можно быстрее».

Отклик, который не был создан в интервале Tmax, не подходит для какого-либо реалистического теста и Src будет отбрасывать такие отклики. Ответчику, выполняющему типовое тестирование круговых потерь (связанное с тестирование производительности приложений вышележащего уровня), следует создавать не более 1 отклика в секунду. Неспособному выполнить это требование ответчику следует записать этот факт в системный журнал (log), чтобы оператор мог настроить должным образом нагрузку и приоритеты. Анализу временных меток [RFC5357], обнаружившему, что отклик не был создан своевременно, следует уведомить оператора, а тому следует приостановить тестирование ответчика, поскольку он может быть перегружен. Дополнительное рассмотрение измерений приведено в разделе 8.

5. Выборка для показателя круговых потерь

На основе одиночного показателя Type-P-Round-trip-Loss определяется выборка таких одиночных измерений. Идея заключается в отборе конкретной связки параметров Src, Dst, Type-P и последующем определении выборки значения параметра TstampSrc. Это можно сделать несколькими способами, включая указанные ниже.

1. Пуассновская выборка. Псевдослучайный пуассоновский процесс потока для скорости lambda со значениями между T и Tf. Временной интервал между последовательными значениями TstampSrc будет средним значением 1/lambda в соответствии с параграфом 11.1.1 в [RFC2330].

2. Периодическая выборка. Периодический процесс потока с псевдослучайным временем запуска T0 между T и dT и номиналиным интервалом передачи пакетов incT в соответствии с [RFC3432].

В имени показателя переменную часть <Sample> нужно заменить процессом, служащим для определения выборки, используя один из упомянутых выше процессов или иной процесс, соответствующий критериям параграфа 11.1 в [RFC2330], детали которого должны быть включены в отчет.

5.1. Имя показателя

Type-P-Round-trip-Loss-<Sample>-Stream

5.2. Параметры показателя

См. параграф 3.2.

5.3. Определение и единицы измерения

На основе одного из методов определения интервала тестирования (выборки значений TstampSrc или иных параметров показателя) получается последовательность одиночных измерений Type-P-Round-trip-Loss, как определено в параграфе Section 4.3.

Потоку Type-P-Round-trip-Loss-<Sample>-Stream нужно быть последовательностью пар показанных ниже элементов.

• TstampSrc, как указано выше.

• L — 0 или 1 (или иной логический эквивалент), где L=1 указывает потерю, L=0 — успешную круговую доставку для истечения TstampSrc + Tmax.

Вместо <Sample> нужно указать Poisson, Periodic или подходящее обозначение иного метода выборки, как указано выше в параграфе 5.

5.4. Обсуждение и другие детали

В [RFC2680] и [RFC2681] широко рассмотрены методы измерений, ошибки и погрешности, а также друние фундаментальные вопросы, которые нет необходимости повторять здесь. Однако на момент выхода этих документов показатель переупорядочения пакетов [RFC4737] ещё не были определены и вопросы переупорядочения ещё не были решены в методологии IPPM.

В [RFC4737] сказано, что пакет, «запаздывающий» относительно порядка отправки, считается переупорядоченным. Например, когда пакеты приходят в порядке 4, 7, 5, 6, пакеты 5 и 6 являются переупорядоченными и они обычно не теряются при условии прибытия в течение некого разумного срока ожидания. Наличие переупорядочения на круговом пути оказывает некоторое влияние на измерения, как указано ниже.

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

2. Распределение времени одиночных измерений в выборках существенно изменено.

3. Исходный или отражённый поток может сталкиваться с нестабильностью пути и исходные условия могут отсутствовать.

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

6. Статистика круговых потерь

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

6.1. Type-P-Round-trip-Loss-<Sample>-Ratio

Для Type-P-Round-trip-Loss-<Sample>-Stream средним значением всех логических параметров (L) в потоке будет Type-P-Round-trip-Loss-<Sample>-Ratio. Это отношение указывается числом потерянных пакетов, поделенным на число круговых передач. Значение Type-P-Round-trip-Loss-<Sample>-Ratio является неопределённым для пустой выборки.

7. Круговые тесты и отчёты для одного направления

Здесь обсуждаются результаты, полученные с использованием архитектуры двухсторонних измерений, такой как TWAMP [RFC5357].

Процесс выборки для обратного пути (Dst->Src) является условным и зависит от прибытия пакета в Dst и корректной работы Dst по генерации отражённого пакета. Поэтому на выборку из обратного пути будут существенно влиять заметные потери на пути Src→Dst, делающие недействительной оценку производительности пути возврата (в плане потерь и возможно других показателей).

Кроме того, время выборки на обратном пути (Dst->Src) определяется случайным процессом, зависящим от исходного времени выборки (TstampSrc), односторонней задержки для успешного прибытия пакета в Dst и времени, потребного Dst для создания отражённого пакета. Поэтому на процесс выборки для пути возврата будет существенно влиять заметное изменение задержки на пути Src->Dst, делающее недействительной попытку оценки производительности обратного пути (в плане потерь и возможно других показателей).

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

8. Измерение и калибровка

Перед выполнением измерений участвующие в них хосты должны быть настроены на передачу и приём тестовых пакетов выбранного Type-P. Стандартные протоколы измерений способны справиться с этой задачей [RFC5357], но достаточно любого надёжного метода (например, можно устранить проблемы, связанные с ICMP, которые рассмотрены в параграфе 2.6 [RFC2681], и выполнить требования параграфов 4.3 и 4.4 перед использованием ICMP).

Два важных свойства принимающего тестовые пакеты и возвращающего отклики на них хоста описаны в параграфе 4.2 [RFC5357]. Каждый полученный пакет должен вызывать отклик и отклики должны генерироваться как можно скорей. Это предполагает быстрое обслуживание буферов интерфейса и крайне редкое отбрасывание буферов. Эти свойства измерительного оборудования должны калиброваться в соответствии с параграфом 3.7.3 [RFC2679] при работе с заметным уровнем измерительной нагрузки (в соответствии с определением пользователя). Должны записываться как неожиданное отбрасывание пакетов, так и систематические и случайные ошибки и погрешности.

Отметим, что в параграфе 4.2.1 [RFC5357] указан метод сбора всех 4 значимых временных меток, требуемых для описания круговой задержки пакетов [RFC2681] и исключения времени обработки на отвечающем хосте. Эти сведения поддерживают измерение соответствующих односторонних задержек, встречающихся на круговом пути, что может выявить асимметрию путей или неожиданное время обработки на отвечающем узле.

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

9.1. Отказ в обслуживании (DoS)

Для этого показателя нужен поток пакетов, передаваемых от одного хоста (источник) к другому (получатель) через промежуточные сети. Этот метод можно использовать для организации DoS-атак, направленных на получателя и/или промежуточные сети.

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

9.2. Конфиденциальность данных пользователей

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

9.3. Влияние на показатели

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

Методы проверки подлинности и шифрования, такие как цифровые подписи можно применять в подходящих случаях для защиты от атак с вставкой трафика. Свойства аутентификации и шифрования рассмотрены в [RFC5357].

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

Показатели, определённые ранее в IETF, включены в реестр IANA IPPM Metrics Registry, однако этот процесс был прерван, когда структуру реестра сочли неадекватной и реестр был отменен [RFC6248].

Хотя показатели из этого документа могут рассматриваться в будущем для той или иной регистрации, в настоящий момент действий IANA не требуется.

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

Авторы благодарны Tiziano Ionta за внимательное рецензирование документа, результатом которого в первую очередь стали соображения об использовании протокола TWAMP [RFC5357] как примера метода. рецензии Adrian Farrel и Benoit Claise также способствовали ясности документа.

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

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

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

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, September 1999.

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Packet Loss Metric for IPPM», RFC 2680, September 1999.

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, «A Round-trip Delay Metric for IPPM», RFC 2681, September 1999.

[RFC3393] Demichelis, C. and P. Chimento, «IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)», RFC 3393, November 2002.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, «Network performance measurement with periodic streams», RFC 3432, November 2002.

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, «Packet Reordering Metrics», RFC 4737, November 2006.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, October 2008.

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

[RFC5481] Morton, A. and B. Claise, «Packet Delay Variation Applicability Statement», RFC 5481, March 2009.

[RFC6248] Morton, A., «RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete», RFC 6248, April 2011.

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, «Reporting IP Network Performance Metrics: Different Points of View», RFC 6703, August 2012.

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

Al Morton

AT&T Labs

200 Laurel Avenue South

Middletown, NJ 07748

USA

Phone: +1 732 420 1571

Fax: +1 732 368 1192

EMail: acmorton@att.com

URI: http://home.comcast.net/~acmacm/

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                  J. Schoenwaelder
Request for Comments: 6643                             Jacobs University
Category: Standards Track                                      July 2012
ISSN: 2070-1721

Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules

Преобразование модулей SMIv2 в модули YANG

PDF

Аннотация

Язык моделирования данных YANG служит для создания моделей данных конфигурации и состояния, которыми управляют на основе протокола NETCONF¹, вызовов удаленных процедур NETCONF и уведомления NETCONF. Структура информации управления SMIv2² определяет фундаментальны типы данных, модель объекта и правила создания и пересмотра модулей MIB для использования с протоколом SNMP³. Этот документ определяет трансляцию модулей SMIv2 MIB в модули YANG, обеспечивающие (только) чтение (config false) объектов данных, определенных в модулях SMIv2 MIB, по протоколу NETCONF.

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

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

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

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации как RFC или перевода с английского языка на другие языки.

1. Введение

Этот документ описывает трансляцию модулей SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB в модули YANG [RFC6020], позволяющие (только) считывать (config false, как указано в параграфе 7.19.1 RFC 6020) объекты SMIv2, определенные с модулях SMIv2 MIB, с помощью протокола NETCONF [RFC6241]. Обсуждение причин, по которым доступные для записи (read-write и read-create) объекты SMIv2 транслируются в доступные лишь для чтения (config false) объекты YANG, приведено в разделе 11.

Модули YANG, созданные из модулей SMIv2, не следует изменять. Все, что требуется сделать — изменить исходные модули SMIv2 (с подобающим обновлением операторов SMIv2 LAST-UPDATED и REVISION), а затем запустить описанную в этом документе трансляцию. Отметим, что это не влияет на использование дополнений отклонений YANG — модули YANG, полученные из SMIv2, можно дополнять как любые другие модули YANG, а отклонения могут использоваться для документирования отклонения реализации от полученного при трансляции модуля YANG.

Модули SMIv1 можно преобразовать в YANG, следуя правилам [RFC3584] для преобразования SMIv1 в SMIv2, а затем правилам этого документа для преобразования полученного модуля SMIv2 в YANG.

Отображение SMIv2 в YANG иллюстрируется примерами, показывающими трансляцию фрагментов модулей SMIv2 IF-MIB [RFC2863], DIFFSERV-MIB [RFC3289] и RMON2-MIB [RFC4502].

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

2. Отображение общеизвестных типов

Базовые типы SMIv2 и некоторые общеизвестные текстовые соглашения отображены на типы YANG в соответствии с приложением A. Отображение типа OCTET STRING зависит от контекста. Если строка октетов имеет связанное сообщение DISPLAY-HINT, ей будет соответствовать строка YANG (string). Реализации должны форматировать значения OCTET STRING в соответствии с DISPLAY-HINT, как описано в RFC 2579. Если OCTECT STRING не имеет связанного DISPLAY-HINT, используется двоичный (binary) тип. Отображение типа INTEGER зависит от его применения в качестве перечисляемого или 32-битового интегрального типа. Реализациям следует поддерживать опции для обработки ситуаций с добавлением DISPLAY-HINT при пересмотре модуля и должна сохраняться совместимость с прежними версиями (т. е. игнорирование DISPLAY-HINT).

Показанные в приложении A отображения могут потребовать импорта модулей YANG ietf-yang-types, ietf-inet-types или ietf-yang-smiv2, поскольку отображения некоторых типов и текстовых соглашений SMIv2 в типы YANG определены в модулях ietf-yang-types и ietf-inet-types из [RFC6021], а также в модуле ietf-yang-smiv2, определенном в данном документе. Реализации должны добавлять импорт всех модулей, требуемых для отображения типов.

3. Трансляция модулей SMIv2 и операторов SMIv2 IMPORT

Модули SMIv2 отображаются в соответствующие модули YANG. Имена создаваемых модулей YANG должны совпадать с именами модулей SMIv2.

Пространство имен YANG должно создаваться на основе зарегистрированного IANA префикса urn:ietf:params:xml:ns:yang:smiv2: (раздел 12), за которым следует имя модуля SMIv2. Поскольку имена модулей SMIv2 можно считать уникальными (см. раздел 3 в [RFC2578]), полученное пространство имен YANG будет уникальным.

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

Операторы SMIv2 IMPORT преобразуются в операторы YANG import. Одно из основных различий между импортом SMIv2 и YANG заключается в том, что SMIv2 IMPORT импортируют конкретные символы из модуля SMIv2, а операторы YANG import импортируют все символы указанного модуля YANG.

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

• Обработка каждого элемента в каждом SMIv2 IMPORT в соответствии с приведенным ниже порядком.

1. 1. Если оператор import для этого модуля SMIv2 уже был сгенерирован, элемент игнорируется.

   2. Если именем модуля SMIv2 является SNMPv2-SMI или SNMPv2-CONF, элемент игнорируется. Отметим, что эти два модуля можно игнорировать полностью, поскольку все определения из них преобразуются правилами трансляции.

   3. Если элемент является текстовым соглашением, соответствующим одному из текстовых соглашений в колонке SMIv2 types приложения A (например, MacAddress, PhysAddress или TimeStamp), элемент игнорируется.

   4. Если элемент используется в SYNTAX для OBJECT-TYPE, где MAX-ACCESS на является accessible-for-notify, оператор import генерируется в соответствии с приведенным ниже описанием.

   5. Если элемент используется в OBJECTS для NOTIFICATION-TYPE, оператор import генерируется в соответствии с приведенным ниже описанием.

   6. Если элемент используется в INDEX или AUGMENTS, оператор import генерируется в соответствии с приведенным ниже описанием.

   7. В остальных случаях элемент игнорируется. Примерами этого являются назначения OBJECT IDENTIFIER и объекты, указанные лишь в MODULE-COMPLIANCE, OBJECT-GROUP или NOTIFICATION-GROUP.

• Генерация дополнительных операторов import в соответствии с типом трансляции и таблицей отображения типов из приложения A. Это требует от транслятора рассмотрения всех типов, использованных в модуле SMIv2, для создания соответствующих операторов import.

• Генерация оператора import для модуля YANG ietf-yang-smiv2 с префиксом smiv2.

Созданные операторы import используют в качестве аргументов нетранслированные имена SMIv2 или имена общеизвестных модулей YANG. Оператор import должен включать оператор prefix. Префиксы можно создавать путем применения алгоритма, описанного в приложении B.

3.1. Пример — импорт IF-MIB

Трансляция IF-MIB [RFC2863] создает модуль YANG с показанными ниже операторами namespace/prefix и import. Префиксом будет перевод имени модуля SMIv2 IF-MIB в нижний регистр (состоит из двух компонент и не требует дальнейшего сокращения).

     module IF-MIB {
       namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB";
       prefix "if-mib";

       import IANAifType-MIB      { prefix "ianaiftype-mib"; }
       import SNMPv2-TC           { prefix "snmpv2-tc"; }
       import ietf-yang-types     { prefix "yang"; }
       import ietf-yang-smiv2     { prefix "smiv2"; }
     }

4. Трансляция макроса MODULE-IDENTITY

SMIv2 требует вызова макроса MODULE-IDENTITY для предоставления контактных данных и истории выпусков модуля MIB. Операторы макроса SMIv2 MODULE-IDENTITY должны транслироваться в операторы YANG, как описано ниже.

4.1. Правила трансляции MODULE-IDENTITY

• SMIv2 ORGANIZATION отображается в оператор YANG organization.

• SMIv2 CONTACT-INFO отображается в оператор YANG contact.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• Каждый SMIv2 REVISION отображается в оператор YANG revision. Выпуск указывается аргументом date в SMIv2 REVISION. DESCRIPTION из REVISION отображаются в соответствующие операторы description, вложенные в revision.

• SMIv2 LAST-UPDATED игнорируется, если связанная дата соответствует REVISION. В остальных случаях создается дополнительный оператор revision.

• Создается контейнер YANG верхнего уровня. Именем контейнера служит имя модуля SMIv2 и для контейнера должно устанавливаться значение config false. Создание этого контейнера можно пропустить, если модуль SMIv2 не определяет никаких объектов для контейнера верхнего уровня (например, определяет лишь текстовые соглашения).

• Значение идентификатора объекта вызова SMIv2 MODULE-IDENTITY транслируется в оператор smiv2:oid, содержащий оператор smiv2:alias, который представляет вызов макроса MODULE-IDENTITY (см. расширение YANG, определенное в разделе 10).

Хотя все корректные модули SMIv2 должны включать точно один вызов макроса MODULE-IDENTITY, имеется несколько важных исключений. Модули, определяющие язык SMIv2 (т. е. SNMPv2-SMI, SNMPv2-TC и SNMPv2-CONF) не вызывают макрос MODULE-IDENTITY. Кроме того, модули SMIv2, созданные из модулей SMIv1 могут пропускать вызов макроса MODULE-IDENTITY. В таких случаях предпочтительно не создавать операторы organization, contact, description или revision.

4.2. Пример — MODULE-IDENTITY из IF-MIB

Трансляция MODULE-IDENTITY из IF-MIB [RFC2863] дает приведенные ниже операторы YANG.

     organization
      "IETF Interfaces MIB Working Group";

     contact
      "Keith McCloghrie
       Cisco Systems, Inc.
       170 West Tasman Drive
       San Jose, CA  95134-1706
       US

       408-526-5260
       kzm@cisco.com";

     description
      "The MIB module to describe generic objects for network
       interface sub-layers.  This MIB is an updated version of
       MIB-II's ifTable, and incorporates the extensions defined in
       RFC 1229.";

     revision "2000-06-14" {
       description
        "Clarifications agreed upon by the Interfaces MIB WG, and
         published as RFC 2863.";
     }
     revision "1996-02-28" {
       description
        "Revisions made by the Interfaces MIB WG, and published in
         RFC 2233.";
     }
     revision "1993-11-08" {
       description
        "Initial revision, published as part of RFC 1573.";
     }

     container IF-MIB {
       config false;
     }

5. Трансляция макроса TEXTUAL-CONVENTION

SMIv2 использует вызов макроса TEXTUAL-CONVENTION для определения типов, выведенных из базовых типов SMIv2. Вызовы TEXTUAL-CONVENTION должны транслироваться в операторы YANG typedef, как описано ниже.

5.1. Правила трансляции TEXTUAL-CONVENTION

Имя вызова макроса TEXTUAL-CONVENTION служит в качестве имени создаваемого оператора typedef. Операторы макроса SMIv2 TEXTUAL-CONVENTION отображаются в операторы YANG, вложенные в оператор typedef, как описано ниже.

• SMIv2 DISPLAY-HINT служит для определения отображений типов, выведенных из типа OCTET STRING, как описано в разделе 2. Кроме того, значение DISPLAY-HINT может служить для генерации регулярного выражения в операторе YANG pattern внутри оператора type.

• SMIv2 DISPLAY-HINT транслируется в оператор smiv2:display-hint (см. расширение YANG, определенное в разделе 10).

• SMIv2 STATUS отображается в оператор YANG status. Генерация YANG пропускается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

Эта трансляция предполагает, что метки именованных чисел и битов не меняются в новых выпусках модуля SMIv2. Это согласуется с правилами выпуска модулей SMIv2, заданными в параграфе 4.9 [RFC4181].

5.2. Пример — OwnerString и InterfaceIndex из IF-MIB

Трансляция текстовых соглашений OwnerString и InterfaceIndex из модуля IF-MIB [RFC2863] показана ниже.

     typedef OwnerString {
       type string {

• SMIv2 SYNTAX отображается в оператор YANG type. Ограничения диапазона SMIv2 отображаются в операторы YANG range, а ограничения размера SMIv2 — в операторы YANG length. Перечисляемые значения SMIv2 INTEGER отображаются в операторы YANG enum/value. SMIv2 BITS отображаются в операторы YANG bit/position. Для типов OCTET STRING отображаемый в базовый тип YANG string (см. раздел 2), размер, заданный в операторе YANG length, должен соответствовать строковому представлению значений. Если реализация не может вывести корректные ограничения размера, оператор YANG должен быть опущен.

         length "0..255";
         pattern '\p{IsBasicLatin}{0,255}';
       }
       status deprecated;
       description
        "This data type is used to model an administratively
         assigned name of the owner of a resource.  This information
         is taken from the NVT ASCII character set.  It is suggested
         that this name contain one or more of the following: ASCII
         form of the manager station's transport address, management
         station name (e.g., domain name), network management
         personnel's name, location, or phone number.  In some cases
         the agent itself will be the owner of an entry.  In these
         cases, this string shall be set to a string starting with
         'agent'.";
       smiv2:display-hint "255a";
     }

     typedef InterfaceIndex {
       type int32 {
         range "1..2147483647";
       }
       description
        "A unique value, greater than zero, for each interface or
         interface sub-layer in the managed system.  It is
         recommended that values are assigned contiguously starting
         from 1.  The value for each interface sub-layer must remain
         constant at least from one re-initialization of the entity's
         network management system to the next re-initialization.";
       smiv2:display-hint "d";
     }

5.3. Пример — IfDirection из DIFFSERV-MIB

Трансляция текстового соглашения IfDirection из DIFFSERV-MIB [RFC3289] приведена ниже.

     typedef IfDirection {
       type enumeration {
         enum inbound  { value 1; }
         enum outbound { value 2; }
       }
       description
        "IfDirection specifies a direction of data travel on an
         interface. 'inbound' traffic is operated on during reception
         from the interface, while 'outbound' traffic is operated on
         prior to transmission on the interface.";
     }

6. Трансляция назначений OBJECT IDENTIFIER

SMIv2 использует назначения OBJECT IDENTIFIER для ввода имен промежуточных узлов дерева OBJECT IDENTIFIER. Назначения OBJECT IDENTIFIER транслируются в операторы smiv2:alias (см. расширение YANG, определенное в разделе 10).

7. Трансляция макроса OBJECT-TYPE

SMIv2 использует макрос OBJECT-TYPE для определения объектов и структуры концептуальных таблиц. Объекты существуют в виде скаляров (в точности один экземпляр в контексте SNMP) или колонок с концептуальными таблицами (множество, возможно пустое, экземпляров в контексте SNMP). Ряд дополнительных объектов определяет индекс (ключ) концептуальной таблицы. Кроме того, концептуальные таблицы могут дополняться другими концептуальными таблицами. Все эти аспекты должны приниматься во внимание при трансляции вызовов макроса SMIv2 OBJECT-TYPE в YANG. Вызовы OBJECT-TYPE должны транслироваться в операторы YANG, как описано ниже.

• SMIv2 SYNTAX отображается в оператор YANG type. Ограничения диапазона SMIv2 отображаются в операторы YANG range, а ограничения размера SMIv2 length — в операторы YANG length. Перечисляемые значения SMIv2 INTEGER отображаются в операторы YANG enum/value, а SMIv2 BITS — в YANG bit/position. Для типов OCTET STRING, отображаемых в базовый тип YANG (раздел 2), размер, задаваемый в операторе YANG length, должен соответствовать строковому представлению значения. Если реализация не может вывести корректные ограничения размера, оператор YANG должен быть опущен.

7.1. Правила трансляции скаляров и колонок

Вызовы макроса SMIv2 OBJECT-TYPE, определяющие скаляры или колонки с MAX-ACCESS со значением not-accessible, read-only, read-write и read-create, транслируются в операторы YANG leaf. В дополнение к этому колонки с MAX-ACCESS = accessible-for-notify транслируются в операторы YANG leaf, если объект является частью INDEX для таблицы, содержащей колонку. Именем листа служит имя, связанное с вызовом макроса SMIv2 OBJECT-TYPE. Вызовы макроса SMIv2 OBJECT-TYPE с MAX-ACCESS = accessible-for-notify транслируются не в листья дерева данных YANG, а в листья уведомлений YANG.

Операторы leaf для скалярных объектов создаются в контейнере, представляющем родительский узел скаляра в дереве OID. Этот контейнер именуется после родительского узла скаляра в дереве OID и помещается в контейнер верхнего уровня, представляющий модуль SMIv2 (параграф 4.1). В редких случаях, когда родитель скаляра имеет множество имен, автоматическая трансляция должна давать отказ, а конфликт имен нужно изучить и исправить вручную. Если в предыдущем выпуске модуля SMIv2 неоднозначности не было, должно применяться имя из этого выпуска. Операторы leaf, представляющие колонки, создаются в списке, представляющем концептуальную строку (параграф 7.3).

• SMIv2 UNITS отображается в оператор YANG units.

• SMIv2 MAX-ACCESS транслируется в оператор smiv2:max-access (см. расширение YANG, определенное в разделе 10).

• SMIv2 STATUS отображается в оператор YANG status. Генерация оператора YANG пропускается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• SMIv2 DEFVAL отображается в оператор smiv2:defval (см. расширение YANG, определенное в разделе 10).

• Значение макроса SMIv2 OBJECT-TYPE транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

Эта трансляция предполагает, что именованные числа и биты не меняются при новом выпуске модуля SMIv2. Это согласуется с правилами выпуска модулей SMIv2, заданными в параграфе 4.9 [RFC4181].

7.2. Пример — ifNumber и ifIndex из IF-MIB

Трансляция скалярного объекта ifNumber и колонки ifIndex из IF-MIB [RFC2863] показана ниже. Поскольку ifNumber является скалярным объектом в ветви interfaces модуля IF-MIB, лист YANG ifNumber заменен контейнеров YANG с именем interfaces, который регистрируется в контейнере верхнего уровня IF-MIB.

     leaf ifNumber {
       type int32;
       description
        "The number of network interfaces (regardless of their
         current state) present on this system.";
       smiv2:max-access "read-only";
       smiv2:oid "1.3.6.1.2.1.2.1";
     }

     leaf ifIndex {
       type if-mib:InterfaceIndex;
       description
        "A unique value, greater than zero, for each interface.  It
         is recommended that values are assigned contiguously
         starting from 1.  The value for each interface sub-layer
         must remain constant at least from one re-initialization of
         the entity's network management system to the next re-
         initialization.";
       smiv2:max-access "read-only";
       smiv2:oid "1.3.6.1.2.1.2.2.1.1";
     }

7.3. Правила трансляции нерасширяемых концептуальных таблиц

Вызов макроса OBJECT-TYPE, определяющего нерасширяемую концептуальную таблицу, транслируется в оператор YANG container с именем вызова макроса OBJECT-TYPE. Этот контейнер создается в контейнере верхнего уровня, представляющем модуль SMIv2. Правила трансляции макроса представлены ниже.

• SMIv2 SYNTAX игнорируется.

• SMIv2 UNITS игнорируется.

• SMIv2 MAX-ACCESS игнорируется.

• SMIv2 STATUS отображается в оператор YANG status. Генерация этого оператора пропускается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• Значение вызова макроса SMIv2 OBJECT-TYPE транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

Вызов макроса OBJECT-TYPE, определяющего концептуальную строку, транслируется в оператор YANG list, содержащийся в контейнере YANG, представляющем концептуальную таблицу. Созданный список использует имя вызова макроса OBJECT-TYPE. Правила трансляции макроса представлены ниже.

• SMIv2 SYNTAX игнорируется.

• SMIv2 UNITS игнорируется.

• SMIv2 MAX-ACCESS игнорируется.

• SMIv2 STATUS отображается в оператор YANG status. Генерация этого оператора пропускается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• SMIv2 INDEX отображается в YANG key со списком колонок, формирующих ключ YANG list. Если один объект неоднократно указана в INDEX, к дубликатам добавляются суффиксы _<n>, где <n> порядковый номер экземпляра в INDEX, начиная с 2. Для определения создаваемых листьев должны использоваться дополнительные операторы leaf.

• Если SMIv2 INDEX содержит ключевое слово IMPLIED keyword, генерируется оператор smiv2:implied для записи имени объекта, которому предшествует ключевое слово IMPLIED (см. расширение YANG, определенное в разделе 10).

• Значение вызова макроса SMIv2 OBJECT-TYPE транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

Внутри оператора list создаются операторы YANG leaf для колонок, как описано в параграфе 7.1. Для объектов, перечисленных в SMIv2 INDEX, которые не являются частью концептуальной таблицы, создаются операторы YANG leaf типа leafref, указывающие на определение.

7.4. Пример — ifTable из IF-MIB

Трансляция определения ifTable из модуля IF-MIB [RFC2863] показана ниже.

     container ifTable {
       description
        "A list of interface entries.  The number of entries is
         given by the value of ifNumber.";
       smiv2:oid "1.3.6.1.2.1.2.2";

       list ifEntry {
         key "ifIndex";
         description
          "An entry containing management information applicable to a
           particular interface.";
         smiv2:oid "1.3.6.1.2.1.2.2.1";

         leaf ifIndex {
           type if-mib:InterfaceIndex;
           description
            "A unique value, greater than zero, for each interface.  It
             is recommended that values are assigned contiguously
             starting from 1.  The value for each interface sub-layer
             must remain constant at least from one re-initialization of
             the entity's network management system to the next re-
             initialization.";
           smiv2:max-access "read-only";
           smiv2:oid "1.3.6.1.2.1.2.2.1.1";
         }

         // ...
       }
     }

7.5. Пример — ifRcvAddressTable из IF-MIB

Ниже показана трансляция определения ifRcvAddressTable из модуля IF-MIB [RFC2863].

     container ifRcvAddressTable {
       description
        "This table contains an entry for each address (broadcast,
         multicast, or uni-cast) for which the system will receive
         packets/frames on a particular interface, except as follows:

         - for an interface operating in promiscuous mode, entries are
           only required for those addresses for which the system would
           receive frames were it not operating in promiscuous mode.

         - for 802.5 functional addresses, only one entry is required,
           for the address which has the functional address bit ANDed
           with the bit mask of all functional addresses for which the
           interface will accept frames.

         A system is normally able to use any unicast address which
         corresponds to an entry in this table as a source address.";
       smiv2:oid "1.3.6.1.2.1.31.1.4";

       list ifRcvAddressEntry {
         key "ifIndex ifRcvAddressAddress";
         description
          "A list of objects identifying an address for which the
           system will accept packets/frames on the particular
           interface identified by the index value ifIndex.";
         smiv2:oid "1.3.6.1.2.1.31.1.4.1";

         leaf ifIndex {
           type leafref {
             path "/if-mib:IF-MIB/if-mib:ifTable" +
                  "/if-mib:ifEntry/if-mib:ifIndex";
           }
         }

         leaf ifRcvAddressAddress {
           type yang:phys-address;
           description
            "An address for which the system will accept packets/frames
             on this entry's interface.";
           smiv2:max-access "not-accessible";
           smiv2:oid "1.3.6.1.2.1.31.1.4.1.1";
         }

         // ...
       }
     }

7.6. Пример — alHostTable из RMON2-MIB

Ниже показана трансляция определения alHostTable из модуля RMON2-MIB [RFC4502].

   container alHostTable {
     description
      "A collection of statistics for a particular protocol from a
       particular network address that has been discovered on an
       interface of this device.

       The probe will populate this table for all protocols in the
       protocol directory table whose value of
       protocolDirHostConfig is equal to supportedOn(3), and
       will delete any entries whose protocolDirEntry is deleted or
       has a protocolDirHostConfig value of supportedOff(2).

       The probe will add to this table all addresses
       seen as the source or destination address in all packets with
       no MAC errors and will increment octet and packet counts in
       the table for all packets with no MAC errors.  Further,
       entries will only be added to this table if their address
       exists in the nlHostTable and will be deleted from this table
       if their address is deleted from the nlHostTable.";
     smiv2:oid "1.3.6.1.2.1.16.16.1";

     list alHostEntry {
       key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex "
         + "nlHostAddress protocolDirLocalIndex_2";
       description
        "A conceptual row in the alHostTable.

         The hlHostControlIndex value in the index identifies the
         hlHostControlEntry on whose behalf this entry was created.
         The first protocolDirLocalIndex value in the index identifies
         the network-layer protocol of the address.
         The nlHostAddress value in the index identifies the network-
         layer address of this entry.
         The second protocolDirLocalIndex value in the index identifies
         the protocol that is counted by this entry.

         An example of the indexing in this entry is
         alHostOutPkts.1.783495.18.4.128.2.6.6.34.

         Note that some combinations of index values may result in an
         index that exceeds 128 sub-identifiers in length, which exceeds
         the maximum for the SNMP protocol.  Implementations should take
         care to avoid such combinations.";
       smiv2:oid "1.3.6.1.2.1.16.16.1.1";

       // ...

       leaf protocolDirLocalIndex {
         type leafref {
           path "/rmon2-mib:RMON2-MIB/"
              + "rmon2-mib:protocolDirTable/"
              + "rmon2-mib:protocolDirEntry/"
              + "rmon2-mib:protocolDirLocalIndex";
         }
       }

       // ...

       leaf protocolDirLocalIndex_2 {
         type leafref {
           path "/rmon2-mib:RMON2-MIB/"
              + "rmon2-mib:protocolDirTable/"
              + "rmon2-mib:protocolDirEntry/"
              + "rmon2-mib:protocolDirLocalIndex";
         }
       }

       // ...
     }
   }

7.7. Правила трансляции расширяемых концептуальных таблиц

Вызов макроса OBJECT-TYPE, определяющего расширяемую концептуальную таблицу, транслируется в оператор YANG smiv2:alias (см. расширение YANG, определенное в разделе 10). Правила трансляции макроса представлены ниже.

• SMIv2 SYNTAX игнорируется.

• SMIv2 UNITS игнорируется.

• SMIv2 MAX-ACCESS игнорируется.

• SMIv2 STATUS отображается в оператор YANG status. Генерация этого оператора пропускается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• Значение вызова макроса SMIv2 OBJECT-TYPE транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

Вызов макроса OBJECT-TYPE, определяющего концептуальную строку расширения, транслируется в оператор YANG smiv2:alias и оператор YANG augment, использующий путь к расширенной таблице в качестве аргумента. Правила трансляции макроса представлены ниже.

• SMIv2 SYNTAX игнорируется.

• SMIv2 UNITS игнорируется.

• SMIv2 MAX-ACCESS игнорируется.

• SMIv2 STATUS отображается в оператор YANG status. Генерация этого оператора пропускается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• Значение вызова макроса SMIv2 OBJECT-TYPE транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

Внутри оператора augment создаются операторы YANG leaf, как описано в параграфе 7.1.

7.8. Пример — ifXTable из IF-MIB

Ниже показана трансляция определения ifXTable из модуля IF-MIB [RFC2863].

     smiv2:alias "ifXTable" {
       description
        "A list of interface entries.  The number of entries is
         given by the value of ifNumber.  This table contains
         additional objects for the interface table.";
       smiv2:oid "1.3.6.1.2.1.31.1.1";
     }

     smiv2:alias "ifXEntry" {
       description
        "An entry containing additional management information
         applicable to a particular interface.";
       smiv2:oid "1.3.6.1.2.1.31.1.1.1";
     }

     augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" {
       description
        "An entry containing additional management information
         applicable to a particular interface.";
       smiv2:oid "1.3.6.1.2.1.31.1.1.1";

       leaf ifName {
         type snmpv2-tc:DisplayString;
         description
          "The textual name of the interface.  The value of this
           object should be the name of the interface as assigned by
           the local device and should be suitable for use in commands
           entered at the device's `console'.  This might be a text
           name, such as `le0' or a simple port number, such as `1',
           depending on the interface naming syntax of the device.  If
           several entries in the ifTable together represent a single
           interface as named by the device, then each will have the
           same value of ifName.  Note that for an agent which responds
           to SNMP queries concerning an interface on some other
           (proxied) device, then the value of ifName for such an
           interface is the proxied device's local name for it.

           If there is no local name, or this object is otherwise not
           applicable, then this object contains a zero-length string.";
         smiv2:max-access "read-only";
         smiv2:oid "1.3.6.1.2.1.31.1.1.1.1";
       }

       // ...
     }

8. Трансляция макроса OBJECT-IDENTITY

SMIv2 использует вызовы макроса OBJECT-IDENTITY для определения информации о назначении OBJECT IDENTIFIER. Вызовы макроса OBJECT-IDENTITY должны транслироваться в операторы YANG identity, как описано ниже.

8.1. Правила трансляции OBJECT-IDENTITY

Имя вызова макроса OBJECT-IDENTITY служит именем созданного оператора identity, который использует в качестве базы отождествление smiv2:object-identity, определенное в разделе 10. Отображение SMIv2 OBJECT-IDENTITY в операторы YANG показано ниже.

• SMIv2 STATUS отображается в оператор YANG status. Этот оператор не создается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• Значение вызова макроса SMIv2 OBJECT-IDENTITY транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

8.2. Пример — diffServTBParamSimpleTokenBucket из DIFFSERV-MIB

Ниже показана трансляция diffServTBParamSimpleTokenBucket из модуля DIFFSERV-MIB [RFC3289] (отметим, что описание должно следовать параграфу 5.1.3 в RFC 3290).

     identity diffServTBParamSimpleTokenBucket {
       base "smiv2:object-identity";
       description
        "Two Parameter Token Bucket Meter as described in the Informal
         Differentiated Services Model section 5.2.3.";
       smiv2:oid "1.3.6.1.2.1.97.3.1.1";
     }

9. Трансляция макроса NOTIFICATION-TYPE

SMIv2 обеспечивает макрос NOTIFICATION-TYPE для определения уведомлений о событиях. YANG для этих целей применяет оператор notification. Вызовы макроса NOTIFICATION-TYPE должны транслироваться в операторы YANG notification, как описано ниже.

9.1. Правила трансляции NOTIFICATION-TYPE

Имя вызова макроса NOTIFICATION-TYPE служит именем создаваемого оператора notification. Операторы макроса NOTIFICATION-TYPE отображаются в операторы YANG, встроенные в notification, как показано ниже.

• SMIv2 OBJECTS отображается в последовательность контейнеров YANG. Для каждого объекта, указанного в значении OBJECTS, создается оператор YANG container с именем object-<n>, где <n> указывает позицию элемента в значении OBJECTS (первый элемент имеет позицию 1). Если текущий объект относится к концептуальной таблице, создается последовательность операторов leaf для каждого объекта INDEX в концептуальной таблице. Эти листья именуются по объектам INDEX и имеют тип leafref. В заключение создается оператор leaf с именем текущего объекта. Если текущий объект имеет MAX-ACCESS со значением read-only, read-write или read-create, создается лист типа leafref. В остальных случаях, если текущий объект имеет MAX-ACCESS = accessible-for-notify, лист создается в соответствии с параграфом 7.1.

• SMIv2 STATUS отображается в оператор YANG status. Этот оператор не создается, если значение STATUS является текущим.

• SMIv2 DESCRIPTION отображается в оператор YANG description.

• SMIv2 REFERENCE отображается в оператор YANG reference.

• Значение вызова макроса SMIv2 OBJECT-IDENTITY транслируется в оператор smiv2:oid (см. расширение YANG, определенное в разделе 10).

9.2. Пример — linkDown NOTIFICATION-TYPE из IF-MIB

Ниже показана трансляция уведомления linkDown из модуля IF-MIB [RFC2863].

     notification linkDown {
       description
        "A linkDown trap signifies that the SNMP entity, acting in
         an agent role, has detected that the ifOperStatus object for
         one of its communication links is about to enter the down
         state from some other state (but not from the notPresent
         state).  This other state is indicated by the included value
         of ifOperStatus.";
       smiv2:oid "1.3.6.1.6.3.1.1.5.3";

       container object-1 {
         leaf ifIndex {
           type leafref {
             path "/if-mib:IF-MIB/if-mib:ifTable" +
                  "/if-mib:ifEntry/if-mib:ifIndex";
           }
         }
       }

       container object-2 {
         leaf ifIndex {
           type leafref {
             path "/if-mib:IF-MIB/if-mib:ifTable" +
                  "/if-mib:ifEntry/if-mib:ifIndex";
           }
         }
         leaf ifAdminStatus {
           type leafref {
             path "/if-mib:IF-MIB/if-mib:ifTable" +
                  "/if-mib:ifEntry/if-mib:ifAdminStatus";
           }
         }
       }

       container object-3 {
         leaf ifIndex {
           type leafref {
             path "/if-mib:IF-MIB/if-mib:ifTable" +
                  "/if-mib:ifEntry/if-mib:ifIndex";
           }
         }
         leaf ifOperStatus {
           type leafref {
             path "/if-mib:IF-MIB/if-mib:ifTable" +
                  "/if-mib:ifEntry/if-mib:ifOperStatus";
           }
         }
       }
     }

10. Определение расширения языка YANG

В этом разделе определены некоторые операторы расширения YANG, которые могут служить для фиксации информации, присутствующей в модулях SMIv2, которая не транслируется с помощью базовых операторов YANG. Модуль YANG ссылается на [RFC2578] и [RFC2579].

   <CODE BEGINS> file "ietf-yang-smiv2@2012-06-22.yang"

 module ietf-yang-smiv2 {

   namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2";
   prefix "smiv2";

   organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

   contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/> 
     WG List:  <mailto:netmod@ietf.org> 

     WG Chair: David Kessens
               <mailto:david.kessens@nsn.com> 

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

     Editor:   Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>"; 

   description
    "Этот модуль определяет расширения YANG, применяемые для
     трансляции SMIv2 в YANG.

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

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

     Модуль является частью RFC 6643, где правовые аспекты указаны
     более детально.";

   revision 2012-06-22 {
     description
      "Initial revision.";
     reference
      "RFC 6643: Translation of Structure of Management Information
       Version 2 (SMIv2) MIB Modules to YANG Modules";
   }

   identity object-identity {
     description
      "Базовое отождествление для всех SMIv2 OBJECT-IDENTITY.";
   }

   typedef opaque {
     type binary;
     description
      "Тип opaque поддерживает возможность передачи произвольного 
       синтаксиса ASN.1. Значение кодируется с использованием ASN.1 BER6
       в строку октетов, которая кодируется в OCTET STRING, давая
       'двойное заворачивание' исходного значения ASN.1.

       По значению и его семантике этот тип эквивалентен типу Opaque в
       SMIv2. Этот тип применяется в SMIv2 исключительно для совместимости
       со старыми версиями, что сохраняется и для данного типа YANG.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
   }

   extension display-hint {
     argument "format";
     description
      "Оператор display-hint принимает в качестве аргумента значение 
       DISPLAY-HINT, назначенное текстовому соглашению SMIv2.";
     reference
      "RFC 2579: Textual Conventions for SMIv2";
   }

   extension max-access {
     argument "access";
     description
      "Оператор max-access принимает в качестве аргумента значение
       MAX-ACCESS, назначенное определению объекта SMIv2.

       Значение MAX-ACCESS относится лишь к SMIv2 и не влияет на
       доступ к объектам YANG по протоколам типа NETCONF.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
   }

   extension defval {
     argument "value";
     description
      "Оператор defval принимает в качестве аргумента принятое по 
       умолчанию значение, определенное в SMIv2 DEFVAL. Отметим, что
       значение находится в пространстве SMIv2, определенном синтаксисом
       SMIv2 соответствующего объекта, а не в пространстве YANG, 
       определенном соответствующим типом данных YANG.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
   }

   extension implied {
     argument "index";
     description
      "Если объекту SMIv2 INDEX предшествует ключевое слово IMPLIED, 
       оператор implied присутствует в модуле YANG и принимает в
       качестве аргумента имя индексного объекта IMPLIED.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
    }

   extension alias {
     argument "descriptor";
     description
      "Оператор alias вводит дескриптор SMIv2. Предполагается, что тело
       оператора alias содержит оператор oid, который указывает числовой
       идентификатор OID, связанный с дескриптором.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
   }

   extension oid {
     argument "value";
     description
      "Оператор oid принимает в качестве аргумента идентификатор объекта,
       назначенный определению SMIv2. Значение идентификатора объекта
       указывается в десятичной нотации с разделением точками.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
   }

   extension subid {
     argument "value";
     description
      "Оператор subid принимает в качестве аргумента последний 
       субидентификатор идентификатора объекта, назначенного определению 
       SMIv2. Значением субидентификатора является одно положительное
       десятичное натуральное число. Оператор subid не может служит 
       субоператором какого-либо узла верхнего уровня в документе YANG. 
       Оператор subid может быть лишь субоператором узла, имеющего 
       родителя, определенного в субоператоре smiv2:oid или smiv2:subid.";
     reference
      "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
   }

 }

   <CODE ENDS>

11. Реализация конфигурационных узлов данных

Результат трансляции модулей SMIv2 MIB в модули YANG содержит объекты YANG, доступные лишь для чтения (config false), даже если объекты SMIv2 имеет доступ read-write или read-create. Одна из причин этого заключается в том, что модели постоянства базовых протоколов SNMP и NETCONF существенно различаются. В SNMP постоянство доступного для записи объекта зависит от определения объекта (т. е. текста в DESCRIPTION) или свойств постоянства концептуальной строки, к которой он относится, иногда управляемых через объект-колонку с использованием текстового соглашения StorageType. В NETCONF постоянство конфигурационных объектов определяется свойствами базового хранилища данных. Кроме того, NETCONF, в соответствии с определением [RFC6241], не обеспечивает стандартных операций для изменения рабочего состояния. Операции <edit-config> и <copy-config> работают только с данными конфигурации. Поэтому невозможно создать узлы конфигурационных данных YANG из определений SMIv2 автоматически.

Однако для некоторых объектов SMIv2, где семантика постоянства SNMP и NETCONF согласована, разработчики могут реализовать некоторые узлы данных YANG, созданные из определений SMIv2, в качестве узлов данных конфигурации. Такие отклонения от доступных лишь для чтения модулей YANG следует формально документировать в виде отдельных модулей YANG с использованием оператора YANG deviation для изменения свойства config узлов данных, реализованный в качестве конфигурационных, с false на true. Отклонения, которые меняют свойство config false на true без других изменений семантики узла данных, не влияют на соответствие модуля YANG, созданного из SMIv2.

11.1. Пример — addressMapControlTable из RMON2-MIB

Приведенный ниже пример показывает, как некоторые колоночные объекты addressMapControlTable из модуля RMON2-MIB [RFC4502] можно преобразовать в узлы данных конфигурации YANG. Отметим, что отклонения YANG влияют лишь на свойство целевого узла и не наследуются.

     module acme-RMON2-MIB-deviations {
       namespace "http://acme.example.com/RMON2-MIB-deviations";
       prefix "acme-rmon2-devs";

       import RMON2-MIB {
         prefix "rmon2-mib";
         revision-date 2006-05-02;
       }

       revision 2012-01-11 {
         description
           "First version.";
       }

       deviation "/rmon2-mib:RMON2-MIB" {
         deviate replace {
           config true;
         }
       }

       deviation "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:addressMapControlTable" {
         deviate replace {
           config true;
         }
       }

       deviation "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:addressMapControlTable/"
               + "rmon2-mib:addressMapControlEntry" {
         deviate replace {
           config true;
         }
       }

       deviation "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:addressMapControlTable/"
               + "rmon2-mib:addressMapControlEntry/"
               + "rmon2-mib:addressMapControlIndex" {
         deviate replace {
           config true;
         }
       }

       deviation "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:addressMapControlTable/"
               + "rmon2-mib:addressMapControlEntry/"
               + "rmon2-mib:addressMapControlDataSource" {
         deviate replace {
           config true;
         }
       }

       deviation "/rmon2-mib:RMON2-MIB/"
               + "rmon2-mib:addressMapControlTable/"
               + "rmon2-mib:addressMapControlEntry/"
               + "rmon2-mib:addressMapControlOwner" {
         deviate replace {
           config true;
         }
       }
     }

Сервер NETCONF, реализующий модуль RMON2-MIB с такими отклонениями, будет анонсировать в сообщении <hello> приведенные ниже возможности (пробелы добавлены лишь для форматирования).

     <capability>
       urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB?
         module=RMON2-MIB&amp;
         revision=2006-05-02&amp;
         deviations=acme-RMON2-MIB-deviations
     </capability>
     <capability>
       http://acme.example.com/RMON2-MIB-deviations?
         module=acme-RMON2-MIB-deviations&amp;
         revision=2012-01-11
     </capability>

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

Этот документ регистрирует два идентификатора URI в реестре IETF XML [RFC3688]. В соответствии с форматом RFC 3688 эти регистрации имеют вид.

     URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
     Registrant Contact: The NETMOD WG of the IETF.
     XML: N/A, the requested URI is an XML namespace.

     URI: urn:ietf:params:xml:ns:yang:smiv2
     Registrant Contact: The NETMOD WG of the IETF.
     XML: N/A, the requested URI is an XML namespace.

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

     Name:         ietf-yang-smiv2
     Namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
     Prefix:       smiv2
     Reference:    RFC 6643

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

Этот документ определяет трансляцию модулей SMIv2 MIB в модули YANG, обеспечивающие лишь возможность чтения (config false) для объектов данных, определенных в SMIv2 MIB, по протоколу NETCONF. Сама трансляция не оказывает влияния на безопасность Internet.

Пользователям моделей данных YANG, созданных из моделей данных SMIv2, которые опубликованы в серии RFC, рекомендуется рассмотреть раздел, посвященный безопасности, в соответствующем RFC. Вопросы безопасности в RFC, содержащих модели данных SMIv2, указывают «чувствительные» и важные объекты. Пользователям NETCONF рекомендуется применять модель управления доступом NETCONF [RFC6536], которая позволяет задать правила для защиты конфиденциальной информации.

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

Автор благодарит за ценные замечания к предварительным вариантам документа Andy Bierman, Benoit Claise, Martin Bjorklund, Leif Johansson, David Reid, Dan Romascanu и David Spakes.

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

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

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

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020⁷, October 2010.

[RFC6021] Schoenwaelder, J., «Common YANG Data Types», RFC 6021⁸, October 2010.

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

[RFC2863] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[RFC3289] Baker, F., Chan, K., and A. Smith, «Management Information Base for the Differentiated Services Architecture», RFC 3289, May 2002.

[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, «Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework», RFC 3584, August 2003.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC4181] Heard, C., «Guidelines for Authors and Reviewers of MIB Documents», BCP 111, RFC 4181, September 2005.

[RFC4502] Waldbusser, S., «Remote Network Monitoring Management Information Base Version 2», RFC 4502, May 2006.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

[RFC6536] Bierman, A., Ed. and M. Bjorklund, Ed., «Network Configuration Protocol (NETCONF) Access Control Model», RFC 6536, March 2012.

Приложение A. Отображение общеизвестных типов (нормативное)

В этом нормативном приложении описано отображение типов SMIv2 на типы YANG, полностью совместимое с таблицами 1 и 2 в [RFC6021].

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   INTEGER       (используется как перечисляемый тип)
   YANG Type:    enumeration

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   INTEGER       (используется как численный тип)
   YANG Type:    int32

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   Integer32
   YANG Type:    int32

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   OCTET STRING  (используется как двоичная строка)
   YANG Type:    binary

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   OCTET STRING  (используется как строка UTF-8 или ASCII)
   YANG Type:    string

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   OBJECT IDENTIFIER
   YANG Module:  ietf-yang-types
   YANG Type:    object-identifier-128

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   BITS
   YANG Type:    bits

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   IpAddress
   YANG Module:  ietf-inet-types
   YANG Type:    ipv4-address

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   Counter32
   YANG Module:  ietf-yang-types
   YANG Type:    counter32

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   Gauge32
   YANG Module:  ietf-yang-types
   YANG Type:    gauge32

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   TimeTicks
   YANG Module:  ietf-yang-types
   YANG Type:    timeticks

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   Counter64
   YANG Module:  ietf-yang-types
   YANG Type:    counter64

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   Unsigned32
   YANG Type:    uint32

   SMIv2 Module: SNMPv2-SMI
   SMIv2 Type:   Opaque
   YANG Module:  ietf-yang-smiv2
   YANG Type:    opaque

   SMIv2 Module: SNMPv2-TC
   SMIv2 Type:   PhysAddress
   YANG Module:  ietf-yang-types
   YANG Type:    phys-address

   SMIv2 Module: SNMPv2-TC
   SMIv2 Type:   MacAddress
   YANG Module:  ietf-yang-types
   YANG Type:    mac-address

   SMIv2 Module: SNMPv2-TC
   SMIv2 Type:   TruthValue
   YANG Type:    boolean

   SMIv2 Module: SNMPv2-TC
   SMIv2 Type:   TimeStamp
   YANG Module:  ietf-yang-types
   YANG Type:    timestamp

   SMIv2 Module: RMON2-MIB
   SMIv2 Type:   ZeroBasedCounter32
   YANG Module:  ietf-yang-types
   YANG Type:    zero-based-counter32

   SMIv2 Module: HCNUM-TC
   SMIv2 Type:   ZeroBasedCounter64
   YANG Module:  ietf-yang-types
   YANG Type:    zero-based-counter64

   SMIv2 Module: HCNUM-TC
   SMIv2 Type:   CounterBasedGauge64
   YANG Module:  ietf-yang-types
   YANG Type:    gauge64

   SMIv2 Module: INET-ADDRESS-MIB
   SMIv2 Type:   InetAutonomousSystemNumber
   YANG Module:  ietf-inet-types
   YANG Type:    as-number

   SMIv2 Module: INET-ADDRESS-MIB
   SMIv2 Type:   InetVersion
   YANG Module:  ietf-inet-types
   YANG Type:    ip-version

   SMIv2 Module: INET-ADDRESS-MIB
   SMIv2 Type:   InetPortNumber
   YANG Module:  ietf-inet-types
   YANG Type:    port-number

   SMIv2 Module: DIFFSERV-DSCP-TC
   SMIv2 Type:   Dscp
   YANG Module:  ietf-inet-types
   YANG Type:    dscp

   SMIv2 Module: IPV6-FLOW-LABEL-MIB
   SMIv2 Type:   IPv6FlowLabel
   YANG Module:  ietf-inet-types
   YANG Type:    ipv6-flow-label

   SMIv2 Module: URI-TC-MIB
   SMIv2 Type:   Uri
   YANG Module:  ietf-inet-types
   YANG Type:    uri

Приложение B. Генерация префиксов (информативное)

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

Таблица 1. Специальные префиксы для общеизвестных модулей YANG.

 

Модуль YANG	Префикс
ietf-yang-types	yang
ietf-inet-types	inet
ietf-yang-smiv2	smiv2

 

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

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

В худшем случае префиксом модуля, созданного из имени модуля SMIv2, становится полное имя этого модуля, приведенное к нижнему регистру. Но обычно создаются более короткие префиксы.

Адрес автора

Juergen Schoenwaelder

Jacobs University

EMail: j.schoenwaelder@jacobs-university.de

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                           S. Rose
Request for Comments: 6672                                          NIST
Obsoletes: 2672                                            W. Wijngaards
Updates: 3363                                                 NLnet Labs
Category: Standards Track                                      June 2012
ISSN: 2070-1721

DNAME Redirection in the DNS

Перенаправление DNAME в DNS

PDF

Аннотация

Запись DNAME обеспечивает перенаправление для субдерева доменных имён в DNS, т. е. все имена с соответствующим суффиксом перенаправляются в другую часть DNS. Этот документ отменяет исходную спецификацию RFC 2672, а также обновляет документ о представлении адресов IPv6 в DNS (RFC 3363).

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

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

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

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации как RFC или перевода с английского языка на другие языки.

1. Введение

DNAME — это запись о ресурсе DNS, исходно определённая в RFC 2672 [RFC2672]. DNAME обеспечивает перенаправления части дерева имён DNS в другую часть дерева имён DNS.

DNAME RR и CNAME RR [RFC1034] заставляют поиск (потенциально) возвращать данные, соответствующие доменному имени, отличному от запрошенного. Различие между этими типами записей состоит в том, что CNAME RR направляет поиск данных для владельца на (одно) другое имя, а DNAME RR направляет поиск данных для потомков владельца имени на соответствующие имена в (одном) другом узле дерева.

Примером может служить поиск в зоне (см. п. 3 в параграфе 4.3.2 RFC 1034 [RFC1034]) доменного имени foo.example.com с обнаружением в example.com записи DNAME, указывающей, что все запросы ниже example.com перенаправляются в example.net. Процесс поиска возвращается к п. 1 с запросом нового имени foo.example.net. Если в запросе было имя www.foo.example.com, новый запрос будет содержать www.foo.example.net.

Этот документ является пересмотром исходной спецификации DNAME из RFC 2672 [RFC2672]. Запись DNAME была предназначена для решения задачи поддержки сопоставления адресов с именами в контексте смены сетевых адресов. При тщательной настройке смена адресов в сети не ведёт к смене полномочных серверов, содержащих отображения адресов на имена. Практическим примером является делегирование реверсного пространства бесклассовых адресов.

Другим применением DNAME являются псевдонимы в пространстве имён. Например, администратор зоны может пожелать, чтобы ветви дерева DNS содержали одну информацию. Примеры включают варианты punycode [RFC3492] для доменных пространств.

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

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

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

2. Запись DNAME

2.1. Формат

Записи DNAME RR имеют мнемоническое имя DNAME и десятичный код типа 39. Записи не зависят от класса адреса. Элемент RDATA состоит из одного поля <target>, содержащего полное доменное имя, которое должно передаваться в несжатой форме [RFC1035] [RFC3597]. Поле <target> должно присутствовать и использует формат представления доменных имён [RFC1035]. Формат представления RR показан ниже.

           <owner> <ttl> <class> DNAME <target>

Влияние DNAME RR заключается в подстановке вместо поля <target> имя владельца записи в качестве суффикса домена. Эта подстановка применяется ко всем именам, размещённым в иерархии ниже имени владельца DNAME RR, для каждой DNAME RR, найденной в процессе распознавания, что разрешает достаточно длинные цепочки DNAME RR.

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

2.2. Подстановка DNAME

Если при выполнении п. 3 алгоритма из параграфа 4.3.2 в RFC 1034 [RFC1034]: «Начало поиска соответствия (метка за меткой) в зоне» обнаруживается узел, владеющий записью DNAME, выполняется подстановка DNAME. Искомое имя может быть именем из исходного запроса, результатом следования CNAME или найденной ранее записи DNAME. Как и при поиске CNAME или набора записей NS, обработка DNAME происходит до нахождения желаемого доменного имени.

Подстановка DNAME выполняется путём замены суффиксных меток искомого имени, совпадающих с именем владельца DNAME, строкой меток из поля RDATA. Во всех случаях совпадающие метки заканчиваются меткой корня. Заменяются только метки целиком. Общие и частные случаи приведены в таблице примеров ниже. QNAME в таблице указывает имя в запросе, владельцем DNAME является владелец доменного имени, а target указывает цель записи DNAME. Результатом является имя, полученное при подстановке DNAME в имя из запроса. Отсутствие совпадений говорит, что запрос не соответствует DNAME, подстановка не выполняется и может возвращаться сообщение об ошибке (если нет иного результата). Каждая строка таблицы содержит пример подстановки, cyc и shortloop содержат петли.

Таблица . Примеры подстановки DNAME.

 

QNAME	Владелец DNAME	target	Результат
com.	example.com.	example.net.	Нет совпадений
example.com.	example.com.	example.net.	3
a.example.com.	example.com.	example.net.	a.example.net.
a.b.example.com.	example.com.	example.net.	a.b.example.net.
ab.example.com.	b.example.com.	example.net.	Нет совпадений
foo.example.com.	example.com.	example.net.	foo.example.net.
a.x.example.com.	x.example.com.	example.net.	a.example.net.
a.example.com.	example.com.	y.example.net.	a.y.example.net.
cyc.example.com.	example.com.	example.com.	cyc.example.com.
cyc.example.com.	example.com.	c.example.com.	cyc.c.example.com.
shortloop.x.x.	x.	.	shortloop.x.
shortloop.x.	x.	.	shortloop.

 

Записи DNAME могут создавать петли, аналогично CNAME, а также эти записи могут создавать петли совместно и даже одна краевая запись DNAME может формировать петлю. Распознавателям и серверам следует соблюдать осторожность при выделении ресурсов для запроса, но следует учитывать возможность наличия достаточно длинных цепочек DNAME. Администраторам содержимого зон следует принимать меры против возникновения петель при использовании перенаправлений DNAME и DNAME/CNAME.

В результате подстановки доменное имя может стать слишком длинным. Предположим, например, что целевое имя DNAME RR содержит 250 октетов (множество меток). Тогда при входящем QNAME размером более 5 октетов размер результата будет больше 255 октетов. В таких случаях сервер возвращает RCODE YXDOMAIN [RFC2136]. Запись DNAME и её подпись (если зона подписана) включаются в ответ, как подтверждение кода YXDOMAIN (6).

2.3. Совпадение имени владельца DNAME с QNAME

В отличие от CNAME RR, запись DNAME RR перенаправляет имена DNS, подчинённые имени владельца, а само имя владельца DNAME не перенаправляется. Доменному имени, владеющему записью DNAME, разрешено иметь другие типы записей о ресурсах, исключая DNAME, CNAME и другие типы, имеющие ограничения на сосуществование с ним.

При совпадении QTYPE с типом или типами, также принадлежащими имени владельца, отклик исходит от имени владельца. Например, для QTYPE типа ANY будут возвращены (доступные) типу по имени владельца, а не цели.

DNAME RR недопустимо присутствовать с тем же именем владельца, что и NS RR, если имя владельца не является вершиной зоны. Если это не вершина, NS RR указывает точку делегирования и DNAME RR должна появляться ниже среза зоны в вершине дочерней зоны.

Если запись DNAME присутствует на вершине зоны, там все равно требуются записи SOA и NS. Такую запись DNAME нельзя использовать для полного отражения зоны, поскольку она не отражает вершину зоны.

Приведённые правила позволяют запрашивать записи DNAME через кэш, совместимый с RFC 1034 [RFC1034] и не знающий о DNAME.

2.4. Имена вслед за записью DNAME и ниже её

Недопустимо существование записей о ресурсах в любом из субдоменов владельца DNAME RR. Для получения содержимого для имён, подчинённых имени владельца должно применяться перенаправление DNAME, запрашивающее результирующую цель. Сервер может отказаться загружать зону, имеющую данные в субдомене доменного имени, владеющего DNAME RR. Если сервер загружает зону, имена ниже DNAME RR будут скрыты, как описано в параграфе 7.18 RFC 2136 [RFC2136]. Кроме того, сервер должен отказаться загружать зону, подчинённую владельцу записи DNAME в родительской зоне. Вопросы динамического обновления обсуждаются в параграфе 5.2.

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

2.5. Сжатие записи DNAME

Имя владельца DNAME может быть сжато, как и любое другое имя владельца. Целевое имя DNAME RDATA недопустимо передавать в сжатой форме и оно должно приводиться к нижнему регистру (downcased) для проверки DNSSEC.

Хотя в прежней спецификации DNAME [RFC2672] (отменена этим документом) говорилось о сигнализации, позволяющей сжимать целевое имя, такая сигнализация не была задана.

В RFC 2672 (отменен этим документом) сказано, что версия расширенного DNS (Extended DNS или EDNS) имеет средства для понимания сжатия DNAME и целевых имён DNAME. Этот документ отменяет эти слова, поскольку для DNAME отсутствует сигнализация EDNS.

3. Обработка

3.1. Создание CNAME

При подготовке отклика сервер, выполняющий подстановку DNAME, во всех случаях включает в раздел ответа соответствующую DNAME RR. Такие случаи указаны ниже.

1. DNAME применяется как инструкция для подстановки.

2. Запись DNAME соответствует QTYPE, а имя владельца совпадает с QNAME.

Если имя владельца совпадает с QNAME, а QTYPE совпадает с другим типом, принадлежащим ему, DNAME не включается в ответ.

Если DNAME применяется в качестве инструкции подстановки, синтезируется запись CNAME RR со сроком действия (Time to Live или TTL), равным сроку действия DNAME RR, и включается в раздел ответов. Именем владельца CNAME является QNAME из запроса. В спецификации DNSSEC ([RFC4033] [RFC4034] [RFC4035]) сказано, что синтезированную запись CNAME не требуется подписывать. В подписанной DNAME имеется поле RRSIG и проверяющий распознаватель может сравнить CNAME с записью DNAME и подтвердить подпись DNAME RR.

Серверы должны быть способны отвечать на запрос для синтезированной записи CNAME. Как и другие типы запросов, этот запрос вызывает DNAME, сервер синтезирует запись CNAME и помещает её а раздел ответов. Если рассматриваемый сервер является кэшем, TTL синтезированной записи CNAME следует делать равным декрементированному TTL кэшированной записи DNAME.

Распознаватели должны быть способны обрабатывать синтезированные CNAME с TTL = 0 или совпадающим с TTL соответствующей записи DNAME (поскольку некоторые старые реализации полномочных серверов устанавливают в синтезированных CNAME TTL = 0). Нулевое значение TTL означает, что CNAME можно отбросить сразу после обработки ответа.

3.2. Серверный алгоритм

Ниже приведён пересмотренный вариант серверного алгоритма из параграфа 4.1 в RFC 2672.

1. Устанавливается или сбрасывается значение доступности рекурсии в зависимости от готовности сервера имён предоставлять рекурсивные услуги. Если рекурсия доступна и запрошена битом RD в запросе, выполняется переход к п. 5, иначе — к п. 2.

2. Поиск в доступных зонах для зоны, являющейся ближайшим предком QNAME. При нахождении такой зоны выполняется п. 3, иначе — п. 4.

3. Сопоставление метки за меткой вниз по этой зоне. Сопоставление может прерываться как указано ниже.

   1. Полное совпадение QNAME означает, что узел найден.

      Если данные узла являются CNAME, а QTYPE не соответствует CNAME, копия CNAME RR помещается в раздел ответа отклика, QNAME меняется на каноническое имя в CNAME RR и выполняется возврат к п. 1. В иных случаях все RR, соответствующие QTYPE, копируются в раздел ответов с переходом к п. 6.

   2. Если соответствие выводит за пределы полномочных данных, это будет ссылка (referral). Такое происходит при наличии узла с NS RR, маркирующими срез по нижней части зоны.

      NS RR для субзоны копируются в раздел полномочий (authority) отклика. Все доступные адреса помещаются в дополнительный раздел с использованием склеивающих RR, если адреса недоступны из полномочных данных или кэша. Переход к п. 4.

   3. Если для какой-либо метки сопоставление невозможно (соответствующей метки нет), проверяется наличие у последней соответствующей метки записи DNAME.

      Если запись DNAME в этой точке существует, она копируется в раздел ответов. Если подстановка её <target> для её <owner> в QNAME приводит к превышению допустимого размера <domain-name>, устанавливается RCODE = YXDOMAIN [RFC2136] и выполнение завершается (выход). В иных случаях выполняется подстановка и обработка продолжается. Сервер должен синтезировать запись CNAME, как описано выше, и включить её в раздел ответов. Возврат к п. 1.

      Если записи DNAME нет, проверяется наличие метки *. Если такой метки нет, проверяется совпадение искомого имени с исходным QNAME из запроса или именем, которое было найдено по CNAME или DNAME. При совпадении с исходным именем в отклике устанавливается ошибка полномочного имени и обработка завершается, в иных случаях обработка завершается без ошибки. При наличии метки * RR этого узла сопоставляются с QTYPE. При совпадении запись копируется в раздел ответов с указанием владельцем RR имени QNAME, а не узла с меткой *. Если данные узла с меткой * — это CNAME и QTYPE не соответствует CNAME, запись CNAME RR копируется в раздел ответов отклика с заменой владельца имени на QNAME, сменой QNAME на каноническое имя в CNAME RR и возвратом к п. 1. В иных случаях выполняется п. 6.

4. Сопоставление с кэшем. При нахождении QNAME в кэше все присоединённые к нему RR, соответствующие QTYPE, копируются в раздел ответов. Если QNAME не найдено в кэше, но имеется запись DNAME у предка владельца QNAME, эта запись DNAME копируется в раздел ответов. Если не было делегирования из полномочных данных, выбирается лучшее из кэша и помещается в раздел authority. Переход к п. 6.

5. Применяется локальный распознаватель или копия его алгоритма для ответа на запрос. Результат сохраняется в разделе ответов отклика, включая любые промежуточные CNAME и DNAME.

6. Предпринимается попытка добавить другие RR, которые могут быть полезны в дополнительный раздел запроса с использованием только локальных данных. Обработка завершается (выход).

Отметим, что будет не более 1 предка с DNAME, как описано в п. 4, если только данные какой-либо зоны не нарушают ограничение на потомков (no-descendants) из раздела 3. Реализация может воспользоваться этим ограничениемЮ останавливая поиск на этапе 3c или 4 при обнаружении записи DNAME.

3.3. Шаблоны

Применять DNAME с шаблонами не рекомендовано в [RFC4592]. Таким образом, не следует использовать DNAME вида *.example.com.

Взаимодействие между подстановкой шаблона и перенаправлением из DNAME является неопределенным. Из-за неопределённости обработки проверяющие распознаватели DNSSEC могут оказаться не в состоянии проверить DNAME с шаблоном.

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

3.4. Восприятие и промежуточное хранение

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

Рекурсивные серверы имён с кэшированием должны синтезировать CNAME от имени клиентов.

Если рекурсивный сервер имён с кэшированием встречает подтверждённую DNSSEC запись DNAME RR, которая противоречит находящимся в кэше сведениям (за исключением записей CNAME), ему следует кэшировать DNAME RR, но можно кэшировать запись CNAME, полученную вместе с DNAME, в соответствии с правилами для CNAME. Если DNAME RR невозможно подтвердить через DNSSEC (т. е. это не BOGUS, но проверка не возможна), рекурсивному серверу с кэшированием не следует кэшировать DNAME RR, но можно кэшировать полученную с ней запись CNAME в соответствии с правилами для CNAME.

3.4.1. Алгоритм распознавателя

Ниже представлена пересмотренная версия алгоритма распознавателя, описанного в параграфе 4.2 RFC 2672.

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

2. Определяется наилучший сервер для запроса.

3. Запросы передаются, пока не будет возвращён отклик.

4. Анализируется полученный отклик.

   1. Если отклик отвечает на вопрос или указывает ошибку имени, данные из него кэшируются и возвращаются клиенту.

   2. Если отклик указывает лучшее делегирование другим серверам, данные делегирования кэшируются и происходит возврат к п. 2.

   3. Если отклик указывает CNAME и не является ответом, CNAME кэшируется, в CNAME RR значение SNAME меняется на каноническое имя и происходит возврат к п. 1.

   4. Если отклик указывает DNAME и не является ответом, DNAME кэшируется (после подтверждения DNSSEC, если клиент является проверяющим распознавателем). Если замена целевого имени DNAME именем владельца ведёт к превышению допустимого для доменного имени размера SNAME, приложению возвращается зависящая от реализации ошибка. Иначе выполняется подстановка и возврат к п. 1.

   5. Если отклик говорит об отказе сервера или содержит странные сведения, сервер удаляется из SLIST с возвратом к п. 3.

4. Рассмотрение DNAME в других документах

В параграфе 10.3 [RFC2181] при рассмотрении записей MX и NS затрагивается перенаправление с помощью CNAME, но это относится и к DNAME. В параграфе 10.3 (Записи MX и NS) [RFC2181] сказано:

Доменное имя, используемое в качестве значения записи NS или части значения записи MX не должно быть псевдонимом. Это не просто разъяснение – использование псевдонима в любой из указанных позиций не обеспечит корректной работы и не приведёт к ожидаемым результатам. Это доменное имя должно иметь в качестве значения по крайней мере одну адресную запись. В настоящее время в качестве таких значений могут использоваться записи типа A, однако в будущем могут появиться другие типы, дающие адресную информацию. Это также может быть RR другого типа, но ни в коем случае не CNAME RR.

DNAME RR рассматриваются в разделе 4 RFC 3363, посвящённом A6 и DNAME. Вступительная посылка этого раздела явно ошибочна, а значит неверен и основанный на ней вывод. В частности, [RFC3363] запрещает применять DNAME в реверсном дереве IPv6. На основе накопленного опыта [RFC3363] пересматривается с отменой всех ограничений на наличие DNAME RR в этих зонах [RFC6434]. Это существенно повысит управляемость реверсного дерева IPv6. Изменения явно указаны ниже. Соответствующий абзац [RFC3363] заменяется приведённым ниже текстом и применение DNAME RR в реверсном дереве больше не запрещается.

Проблемы применения DNAME в дереве реверсного отображения тесно связаны с необходимостью использовать в основном дереве фрагментированные A6. Поэтому, переводя RFC 2874 в статус экспериментального, этот документ предполагает, что использование DNAME RR в реверсном дереве будет отменено.

5. Другие проблемы, связанные с DNAME

При использовании DNAME следует учитывать описанные в последующих параграфах аспекты.

5.1. Канонические имена хостов не могут быть ниже владельца DNAME

Имена целей в записях MX, NS, PTR, SRV [RFC2782] должны быть каноническими именами хостов. Это означает невозможность перенаправления CNAME или DNAME в процессе поиска DNS адресных записей хостов. Этот вопрос рассматривается в параграфе 10.3 RFC 2181 [RFC2181] и в параграфе 2.4 RFC 1912 [RFC1912]. Записи SRV рассмотрены на стр. 4 RFC 2782 [RFC2782].

В итоге получается, что имя, указанное в записи PTR не может размещаться ниже DNAME, хотя поиск PTR может включать DNAME. Это относится и к записям NS, SRV, MX. Например, punycode [RFC3492] меняет для зоны использование DNAME, записи NS, MX, SRV и PTR, указывающие эту зону, должны использовать в своих RDATA имена, которые не являются псевдонимами. Тогда требуется, чтобы подстановка DNAME уже была применена к доменным имена в данных MX, NS, PTR, SRV. Это будут канонические имена хостов.

5.2. Динамическое обновление и DNAME

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

Если сообщение динамического обновления пытается добавить DNAME, с именем владельца которой уже связана запись CNAME, сервер должен игнорировать DNAME. Если с этим именем уже связана запись DNAME, она заменяется новой DNAME. В остальных случаях запись DNAME добавляется в зону. Если добавляется запись CNAME, с именем владельца которой уже связана запись DNAME, эта запись CNAME должна игнорироваться. Аналогичное поведение имеет место и при динамическом обновлении имени владельца CNAME RR [RFC2136].

5.3. DNSSEC и DNAME

В последующих параграфах рассматривается поведение реализаций, поддерживающих DNSSEC и DNAME (синтез).

5.3.1. Подписанные DNAME и синтезированные CNAME без подписи

В любом отклике подписанная DNAME RR указывает нетерминальное перенаправление запроса. В разделе ответов может (не обязательно) быть синтезированная сервером запись CNAME, но такие записи никогда не подписываются. Для валидатора DNSSEC достаточно проверки DNAME RR и корректности синтеза CNAME.

5.3.2. Бит DNAME в битовой карте NSEC

В любом негативно отклике NSEC или NSEC3 [RFC5155] следует проверять битовую карту типа, чтобы убедиться в отсутствии записи DNAME, которую можно применить. Если бит DNAME установлен и имя в запросе является субдоменом ближайшего включающего имени, которое заявлено, это указывает, что следовало выполнить подстановку DNAME, но это не было сделано, как задано.

5.3.3. Действенность цепочек DNAME

Отклик может содержать цепочку перенаправлений DNAME и CNAME, которая может завершаться позитивным или негативным (нет имени или данных) откликом. Каждый шаг цепочки ведёт к добавлению записей о ресурсах в раздел ответов или полномочий отклика. Бит AD (Authentic Data — аутентичные данные) может быть установлен лишь при безопасности каждого шага. Если любой из шагов является ложным, вся цепочка становится фальшивой.

5.3.4. Валидаторы должны понимать DNAME

Ниже приведены примеры, показывающие, почему валидаторы DNSSEC должны понимать DNAME. В примерах опущены или сокращены записи SOA, NSEC, отвергающие шаблоны, и другие данные, не связанные с обсуждением.

5.3.4.1. Отклик с ошибкой непригодного имени, вызванной DNAME в битовой карте

   ;; Заголовок: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Вопрос
   foo.bar.example.com. IN A
   ;; Полномочия
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [действительная подпись]

Если это полцченный отклик, только понимание того, что бит DNAME в битовой маске NSEC указывает, что foo.bar.example.com нужно перенаправлять по DNAME. Валидатор может увидеть, что это фиктивный ответ (BOGUS) злоумышленника, собравшего имеющиеся записи DNS для создания вносящего путаницу ответа. Если бы бит DNAME не был установлен в показанной выше записи NSEC, ответ был бы подтверждён как отклик об ошибке имени.

5.3.4.2. Действительный отклик об ошибке имени с DNAME в битовой карте

   ;; Заголовок: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Вопрос
   cee.example.com. IN A
   ;; Полномочия
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [действительная подпись]

Этот отклик имеет такие же записи NSEC, как в первом примере, но с таким именем в запросе (cee.example.com), ответ подтверждается, поскольку cee не перенаправляется по DNAME в bar.

5.3.4.3. Отклик с синтезированной записью CNAME

   ;; Заголовок: QR AA RCODE=0(NOERROR)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Вопрос
   foo.bar.example.com. IN A
   ;; Ответ
   bar.example.com. DNAME bar.example.net.
   bar.example.com. RRSIG DNAME [действительная подпись]
   foo.bar.example.com. CNAME foo.bar.example.net.

Показанный выше отклик включает синтезированную запись CNAME, которая не имеет подписи, поскольку сервер не подписывает онлайн. Такому отклику нельзя доверять, поскольку атакующий может изменить его на foo.bar.example.com CNAME bla.bla.example. Запись DNAME включает подпись, поэтому изменить её не удастся. Валидатор должен проверить подпись DNAME, а затем рекурсивно распознать её для запроса записи A для имени foo.bar.example.net.

6. Примеры использования DNAME в зоне

Ниже приведено несколько примеров использования DNAME в зоне. Примеры не охватывают всех вариантов.

6.1. Переименование организации

Если организация с доменным именем FROBOZZ.EXAMPLE.NET становится частью организации с доменом ACME.EXAMPLE.COM, она может облегчить переход, поместив в старой зоне записи вида

       frobozz.example.net.  DNAME    frobozz-division.acme.example.com.
                             MX       10       mailhub.acme.example.com.

Отклик на расширенный рекурсивный запрос для www.frobozz.example.net будет содержать в разделе ответов запись DNAME, приведённую выше и соответствующие RR для www.frobozz-division.acme.example.com.

Если организация хочет иметь псевдонимы для имён с разным написанием или на другом языке, примени тот же способ. Отметим, что MX RR на вершине зоны не перенаправляется и должна повторяться в целевой зоне. Отметим также, что службы в mailhub и www.frobozz-division.acme.example.com. должны распознавать и обрабатывать эти псевдонимы.

6.2. Бесклассовое делегирование коротких префиксов

Бесклассовую схему делегирования in-addr.arpa [RFC2317] можно расширить на префиксы короче 24 битов с помощью записи DNAME. Например, префикс 192.0.8.0/22 можно делегировать с помощью показанных ниже записей.

       $ORIGIN 0.192.in-addr.arpa.
       8/22    NS       ns.slash-22-holder.example.com.
       8       DNAME    8.8/22
       9       DNAME    9.8/22
       10      DNAME    10.8/22
       11      DNAME    11.8/22

Типичная запись результирующей реверсной зоны для хоста с адресом 192.0.9.33 может иметь вид

        $ORIGIN 8/22.0.192.in-addr.arpa.
        33.9    PTR     somehost.slash-22-holder.example.com.

Замечания в [RFC2317] относительно выбора символа / применимы и здесь.

6.3. Поддержка смены сетевых адресов

Если бы смена адресов IPv4 в сетях происходила часто, поддержку делегирования адресного пространства можно было бы упростить применяя записи DNAME вместо NS, как показано ниже.

       $ORIGIN new-style.in-addr.arpa.
       189.190           DNAME    in-addr.example.net.

       $ORIGIN in-addr.example.net.
       188               DNAME    in-addr.customer.example.com.

       $ORIGIN in-addr.customer.example.
       1                 PTR      www.customer.example.com
       2                 PTR      mailhub.customer.example.com.
       ; ...

Это позволит сменить адресный блок 190.189.0.0/16, выделенный провайдеру example.net, без необходимости менять данные зоны, описывающие использование этого блока провайдером и его клиентами.

Смена адресов в сетях IPv4 в настоящее время является тяжёлой задачей и обновление DNS является лишь малой частью работы, поэтому ценность приведённой выше схемы невелика. Однако есть надежда, что механизм смены адресов IPv6 будет иным и механизм DNAME может оказаться полезным.

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

Код записи DNAME с десятичным значением 39 исходно включён [RFC2672] в таблице реестра DNS Resource Record (RR) http://www.iana.org/assignments/dns-parameters. Агентство IANA обновило реестр записей о ресурсах DNS для типа 39, указав в нем этот документ.

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

DNAME перенаправляет запросы, что может влиять на безопасность в зависимости от политики и состояния защиты зоны с DNAME и зоны перенаправления. Для проверяющих распознавателей к результат определяется самым слабым звеном цепочки перенаправлений CNAME и DNAME. Если проверяющий распознаватель воспринимает шаблонные DNAME, возникают проблемы безопасности. Поскольку обработка шаблонных DNAME недетерминирована, а CNAME, подставленные сервером, не имеют подписи, распознаватель может выбрать результат, отличающийся от предусмотренного сервером, и, соответственно, попасть не в тот пункт назначения. Ни в каких случаях не рекомендуется применять записи DNAME с шаблонами [RFC4592]. Проверяющий распознаватель должен понимать записи DNAME, согласно [RFC4034]. Иллюстрация этого представлена в примерах параграфа 5.3.4.

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

Авторы документа признательны Matt Larson за начало работы по решению проблем, связанных с типом DNAME RR. Авторы также благодарны Paul Vixie, Ed Lewis, Mark Andrews, Mike StJohns, Niall O’Reilly, Sam Weiler, Alfred Hoenes, Kevin Darcy за рецензии и комментарии к документу.

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

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

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, «Classless IN-ADDR.ARPA delegation», BCP 20, RFC 2317, March 1998.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, July 2006.

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, «DNS Security (DNSSEC) Hashed Authenticated Denial of Existence», RFC 5155, March 2008.

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

[RFC1912] Barr, D., «Common DNS Operational and Configuration Errors», RFC 1912, February 1996.

[RFC2672] Crawford, M., «Non-Terminal DNS Name Redirection», RFC 2672, August 1999.

[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, «Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)», RFC 3363, August 2002.

[RFC3492] Costello, A., «Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)», RFC 3492, March 2003.

[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, «IPv6 Node Requirements», RFC 6434, December 2011.

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

A.1. Изменения в поведении сервера

Ниже перечислены основные изменения в поведении сервера по сравнению с исходной спецификацией DNAME.

• Правила подстановки DNAME уточнены в параграфе 2.2.

• Опция EDNS для сигнализации понимания и сжатия DNAME не была задана и этот документ указывает, что метода сигнализации не существует (параграф 2.5).

• В поле TTL синтезированных CNAME RR устанавливается TTL из DNAME, а не 0 (параграф 3.1).

• Рекурсивные кэширующие серверы должны выполнять синтез CNAME от имени клиентов (параграф 3.4).

• Пересмотренный алгоритм сервера представлен в параграфе 3.2.

• Правила для сообщений динамического обновления, добавляющих DNAME или CNAME RR в зону, где уже имеются CNAME или DNAME, детализированы в параграфе 5.2.

A.2. Изменения в поведении клиента

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

• Клиенты должны быть способны воспринимать синтезированные CNAME RR с TTL = 0 или TTL из DNAME RR, сопровождающей CNAME RR.

• Клиентам с поддержкой DNSSEC следует кэшировать DNAME RR и можно кэшировать синтезированные CNAME RR, полученные в том же отклике. Таким клиента следует также проверять битовую карту типа NSEC/NSEC3, чтобы убедиться в необходимости перенаправления DNAME. Распознаватели DNSSEC должны понимать DNAME (параграф 5.3).

• Пересмотренный алгоритм клиента представлен в параграфе 3.4.1.

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

Scott Rose

NIST

100 Bureau Dr.

Gaithersburg, MD 20899

USA

Phone: +1-301-975-8439

Fax: +1-301-975-6238

EMail: scott.rose@nist.gov

 

Wouter Wijngaards

NLnet Labs

Science Park 140

Amsterdam 1098 XH

The Netherlands

Phone: +31-20-888-4551

EMail: wouter@nlnetlabs.nl

---

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

nmalykh@protokols.ru

---