RFC 9620 Guidelines for Human Rights Protocol and Architecture Considerations

Internet Research Task Force (IRTF)                            G. Grover
Request for Comments: 9620                                              
Updates: 8280                                               N. ten Oever
Category: Informational                          University of Amsterdam
ISSN: 2070-1721                                           September 2024

Guidelines for Human Rights Protocol and Architecture Considerations

Рекомендации по правам человека при разработке протоколов и архитектур

PDF

Аннотация

В этом документе приведены рекомендации по учёту прав человека при разработке сетевых протоколов и архитектуры, аналогично рекомендациям по учёту приватности (конфиденциальности) в RFC 6973. Документ является обновлением рекомендаций по правам человека, приведённых в RFC 8280.

Документ создан исследовательской группой IRTF Human Right Protocol Considerations (HRPC).

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

Документ не относится к категории Internet Standards Track и публикуется для информации.

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы QIRG в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (https://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение

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

Вопросы основаны на исследованиях, выполненных группой Human Rights Protocol Considerations (HRPC) Research Group, которые были документированы до выхода этого документа. Исследования установили, что права человека связаны со стандартами и протоколами, и предоставляют базовый словарь технических понятий, влияющий на права человека, а также способы объединения этих технических понятий для сохранения в Internet благоприятной среды в части прав человека. Это формирует контуры для решения вопросов прав человека в протоколах.

Документ представляет собой итерацию руководств, представленных в [RFC8280]. Методы анализ прав человека (параграф 3.2) и рекомендации по учёту этих прав (параграф 3.3) в данном документе протестированы на предмет актуальности, точности и обоснованности [HR-RT]. Толкование прав человека основано на «Всеобщей декларации прав человека» (Universal Declaration of Human Rights) [UDHR] и последующих соглашениях, которые совместно формируют свод международных законов о правах человека [UNHR].

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

Этот информационный документ одобрен для публикации исследовательской группой HRPC в составе IRTF. Документ был рассмотрен, опробован и протестирован исследовательской группой, а также внешними исследователями и практиками. Исследовательская группа признает, что понимание воздействия протоколов и архитектуры Internet на общество ещё не завершено и включает совокупность продолжающихся исследований. Документ не является результатом работы IETF и не задаёт стандартов.

2. Угрозы правам человека

Угрозы реализации прав человека в Internet имеют много форм. Протоколы и стандарты могут наносить ущерб правам на свободу выражения и информации, отсутствие дискриминации, равную защиту, участие в культурной жизни, искусстве и науке, свободу собраний и ассоциаций, безопасность. Конечный пользователь, которому отказано в доступе к неким услугам или содержимому, может оказаться не в состоянии раскрыть важные сведения о недобросовестных действиях правительства или иных органов. Человеку, чьи коммуникации отслеживаются, могут препятствовать в осуществлении его прав на свободу ассоциаций или участие в политических процессах [Penney]. В худшем варианте утечка информации может вызывать физическую опасность. Реалистичным примером являются случаи, когда лица, сочтённые угрозой государству, подвергаются мучениям, внесудебным казням или заключению по стражу на основе сведений, собранных государственными органами путём отслеживания сетевого трафика.

В этом документе приведено несколько примеров реализации угроз правам человека в Internet. Моделирование угроз вдохновлено документом Privacy Considerations for Internet Protocols [RFC6973], основанным на анализе угроз безопасности. Этот метод ещё разрабатывается и не является идеальным для оценки рисков для прав человека в протоколах и системах Internet. Некоторые конкретные угрозы правам человека опосредованно учитываются в протоколах Internet как часть вопросов безопасности [RFC3552], однако соображения приватности [RFC6973], не говоря уже о влиянии протоколов на права человека не стандартизованы и не реализованы.

Многие угрозы, способствующие их возникновению факторы и риски связаны с различными правами. Это неудивительно с учётом взаимосвязанности, взаимозависимости и неделимости прав человека. Однако здесь рассматриваются лишь права человека, связанные с информационными и коммуникационными технологиями (Information and Communication Technologies или ICT) в целом, а также протоколами и стандартами, в частности [Orwat]:

Основным источником значимости прав человека является «Международный билль о правах человека», состоящий из «Всеобщей декларации прав человека» (UDHR) [UDHR], а также «Международного пакта о гражданских и политических правах (International Covenant on Civil and Political Rights или ICCPR) [ICCPR] и «Международного пакта об экономических, социальных и культурных правах» (International Covenant on Economic, Social and Cultural Rights или ICESCR) [ICESCR]. В свете некоторых фактов цензуры в Internet в 2012 г. была принята резолюция комитета по правам человека ООН (UN Human Rights Council Resolution) 20/8, в которой сказано: « … те же права, которые люди имеют вне сети (offline), должны быть защищены и в сети (online) …» [UNHRC2016]. В 2015 г. была разработана и опубликована «Хартия прав человека и принципов для Internet (Charter of Human Rights and Principles for the Internet) [IRP] [Jorgensen]. Согласно этим документам, примерами прав человека, связанных с системами ICT, являются человеческое достоинство (ст. 1 UDHR), отсутствие дискриминации (ст. 2), право на жизнь, свободу и безопасность (ст. 3), свобода мнений и их выражения (ст. 19), свобода собраний и ассоциаций (ст. 20), право на равную защиту, правовую защиту, справедливый суд, надлежащее судопроизводство, презумпция невиновности (ст. 7-11), подобающий социальный и международный порядок (ст. 28), участие в общественных делах (ст. 21), участие в культурной жизни, защита интеллектуальной собственности (ст. 27), приватность (ст. 12).

Часть каталога прав человека, связанных с ICT, включая экономически права, приведена в [Hill].

Здесь не предпринимается попыток исключить конкретные права или отдать предпочтение отдельным правам.

3. Обзоры по правам человека

В идеале создателям протоколов и их соавторам следует рассматривать вопросы прав человека в процессе разработки (см. параграф 3.1). В этом разделе приведены рекомендации по выполнению анализа прав человека, т. е. оценке на них протокола или стандарта. Анализ прав человека может выполнять любой участник на разных этапах создания Internet-Draft. Как правило, легче повлиять на разработку технологии на ранних этапах процесса, нежели на более поздних. Это не означает, что рецензии Last Call не имеют значения, но вероятность существенных изменений на их основе будет ниже.

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

Методы анализа технологий на предмет влияния на права человека ещё только зарождаются. К настоящему моменту группа по анализу прав человека изучила 5 методов, часто применяемых в сочетании друг с другом.

3.1. Анализ Internet-Draft на основе рекомендаций модели

При таком анализе применяется модель, описанная в разделе 4. Описанные категории и вопросы можно применять для рецензирования Internet-Draft. Преимущество этого состоит в предоставлении понятного обзора и авторы документов могут обратиться к этому документу и [RFC8280] для понимания предыстории и контекста.

3.2. Анализ Internet-Draft на основе воздействия

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

3.3. Общение с экспертами

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

  1. Возможность рецензента глубже понять (предусмотренную) работу протокола.

  2. Возможность рецензента начать обсуждение с экспертами или даже авторами документа, что может помочь в понимании рецензии после её публикации.

3.4. Собеседование с затрагиваемыми лицами и сообществами

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

3.5. Отслеживание влияния реализаций

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

4. Рекомендации по вопросам прав человека

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

Протоколы и стандарты Internet могут выиграть от документированного обсуждения возможных рисков для прав человека, возникающих из-за неправильного применения протокола или технологии, описанных в RFC. Это может быть дополнено заявлением о применимости (Applicability Statement) данного RFC.

Отметим, что представленные в этом разделе рекомендации не задают конкретной практики. Спектр разрабатываемых IETF протоколов слишком широк, чтобы давать рекомендации о конкретном использовании данных или балансе прав человека и других аспектов разработки. Однако тщательное продумывание ответов на приведённые ниже вопросы поможет авторам выполнить всесторонний анализ, который может стать основой для обсуждения адекватности учёта в протоколе конкретных угроз правам человека. Это руководство призвано помочь в процессе анализа прав человека и не содержит конкретных указаний для написания раздела о правах человека (как в примере из [RFC6973]).

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

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

4.1. Посредники

Вопросы

Зависит ли протокол от конкретных функций на узлах-посредниках и разрешает ли такие функции?

Пояснения

Принцип сквозной (end-to-end) работы [Saltzer] гласит, что некоторые функции могут выполняться и их следует выполнять на концах сети. В [RFC1958] сказано «в более общем виде сообщество считает, что целью является связность …, а информация является сквозной, а не спрятанной где-то в сети». При включении в протокол конечных точек и посредников, особенно не находящихся под контролем какой-либо из конечных точек или даже практически невидимых для конечных точек (например, перехватывающие прокси HTTPS [HTTPS-interception]) появляются новые возможности отказов. Это также ведёт к консервативности, поскольку посредники могут задавать ограничения для протоколов (иногда в нарушение спецификации), которые помешают конечным точкам применять более современные протоколы, как описано в параграфе 9.3 [RFC8446].
Отметим, что посредники отличаются от служб. В первом случае сторонний элемент является частью протокольного обмена, а во втором конечные точки явно взаимодействуют со службой. Модель клиент-сервер обеспечивает более чёткое разделение ответственности между элементами, нежели наличие посредников. Однако даже в системах клиент-сервер зачастую полезно обеспечивать сквозное шифрование между конечными точками для элементов протокола, не входящих в сферу действия службы, как это сделано в Messaging Layer Security (MLS) [RFC9420].

Пример

Шифрование между конечными точками можно применять для защиты протокола от воздействия посредников. Примерами являются шифрование информации транспортного уровня в QUIC [RFC9000] и поле индикации имени сервера TLS (Server Name Indication или SNI) [TLS-ESNI]. Одним из следствий этого является ограничение возможности инспектирования трафика операторами сети, в случае шифрования оператору для отслеживания поведения потребуется контроль над ними.

Влияние

  • Право на свободу выражения.
  • Право на свободу собраний и ассоциаций

4.2. Связность

Вопросы

Оптимизирован ли протокол для соединений с малой пропускной способностью и высокой задержкой? Может ли протокол работать без поддержки состояний (stateless)?
С учётом изменения качества и условий в сети в зависимости от места и времени важно разрабатывать протоколы так, чтобы они были надёжными даже для соединений с малой пропускной способностью и высокой задержкой.

Влияние

  • Право на свободу выражения
  • Право на свободу собраний и ассоциаций

4.3. Надёжность

Вопросы

Устойчив ли протокол к отказам? Имеются ли механизмы аккуратного «отката» (downgrade) и/или уведомления? Может ли протокол противостоять злонамеренным попыткам сокращения возможностей (degradation)? Имеется ли документированный способ информирования о сокращении возможностей? Имеются ли средства (меры) восстановления или частичного исправления при отказе? Может ли протокол обеспечивать надёжность и производительность при непредвиденных изменениях или обстоятельствах?

Пояснения

Надёжность и отказоустойчивость гарантируют, что протокол будет выполнять свои функции согласованно и устойчиво к ошибкам (как описано), не приводя к неожиданным результатам. Меры обеспечения надёжности в протоколах гарантируют пользователям успешное выполнение желаемых коммуникаций.
Надёжная система сокращает свои возможности (деградирует) аккуратно и имеет документированные средства информирования об этом. Она также будет обеспечивать механизмы аккуратного восстановления после отказов и, по возможности, поддерживать частичное восстановление. Важно отличать случайное сокращение возможностей от злонамеренного. Например, некоторые атаки на прежние версии TLS использовали способность TLS аккуратно переходить к менее стойким шифрам [FREAK] [Logjam], что полезно с точки зрения функциональности, но может быть катастрофическим в плане безопасности.
Для надёжности требуется, чтобы службы уведомляли пользователей об отказах при доставке. В системах, работающих в реальном масштабе времени, протокол также должен обеспечивать своевременную доставку.

Пример

В структуре современного стека IP надёжный транспортный уровень требует индикации успешного завершения транспортной обработки, такой как сообщения TCP ACK [RFC9293]. Протокол прикладного уровня может требовать зависящий от приложения подтверждений, содержащих код состояния, указывающий статус обработки запроса (см. [RFC3724]).

Влияние

  • Право на свободу выражения
  • Право на безопасность (защиту)

4.4. Распознавание содержимого

Вопросы

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

Пример

Когда сетевые посредники могут определить тип содержимого передаваемых пакетов, они могут воспользоваться этими сведениями для дискриминации одного типа содержимого в пользу другого. Это влияет на возможности пользователей передавать и принимать желаемое содержимое.
Как рекомендовано в [RFC8558], разработчикам протоколов следует избегать конструкций в неявной индикацией содержимого. В общем случае разработчикам следует избегать явных индикаторов содержимого для посредников. Иногда может возникать необходимость в добавлении таких явных индикаторов, но применять их следует лишь в случае уверенности разработчиков в их явной пользе для конечных пользователей (приоритеты пользователей более подробно рассмотрены в [RFC8890]). В таких случаях следует документировать влияние таких сигналов на права человека.
Отметим, что многие протоколы предоставляют предназначенные для конечных точек сигналы, которые посредники могут использовать как неявные индикаторы для разделения трафика по содержимому (например, номер порта TCP) или отправителям/получателям (адреса IP). По возможности следует использовать шифрование для защиты от посредников. Во многих случаях трудно скрыть сигналы (например, адреса IP), но в таких случаях, как TLS Application Layer Protocol Negotiation [RFC7301], предпринимаются усилия по защите данных [TLS-ESNI].

Влияние

  • Право на свободу выражения
  • Право на недискриминацию
  • Право на равную защиту

4.5. Поддержка разных языков

Вопросы

Поддерживает ли протокол или спецификация задание в содержимом или заголовках строковых элементов, которые должны быть поняты или введены человеком? Поддерживает ли спецификация кодировку Unicode? Если эта кодировка поддерживается, принимается ли только UTF-8 или также другие кодировки (может быть опасно в плане совместимости)? Если разрешены кодировки, отличные от UTF-8, требует ли спецификация корректного указания набора символов? Знакомы ли вы с [RFC6365]?

Пояснения

Поддержка разных языков (internationalization) позволяет создавать протоколы, стандарты и реализации, пригодные для использования с различными языками и шрифтами (см. параграф 4.6). В IETF это означает добавление или улучшение обработки в протоколе текстов, отличных от ASCII [RFC6365]. Другая точка зрения, более подходящая для протоколов, изначально предназначенных для глобального применения, используется в определении World Wide Web Consortium (W3C) [W3Ci18nDef]:
Интернационализация — это проектирование и разработка продукции, приложений и документов, позволяющая легко приспособить (localization) их для целевой аудитории, религии или языка.
Многие протоколы, работающие с текстом, используют лишь одну кодировку (US-ASCII) или оставляют выбор применяемой кодировки и набора символов пользователю (что, безусловно, ведёт к проблемам совместимости). Если поддерживается несколько кодировок, требуется явное указание применяемой [RFC2277]. Добавление в протокол отличного от ASCII текста позволяет обрабатывать большее число текстов, которые, как можно надеяться, представляют пользователей по всему миру. Сегодня это лучше всего обеспечивать за счёт поддержки кодировки Unicode UTF-8.
В современной практике IETF [RFC2277] поддержка разных языков нацелена на обращённые к пользователю строки, а не на элементы протокола, такие как используются в некоторых текстовых протоколах (следует отметить, что некоторые строки, например, идентификаторы, являются одновременно содержимым и элементами протокола). Хотя это разумно для элементов, не видимых пользователю, разработчикам следует обеспечивать полную и равную поддержку всех текстов и кодировок в ориентированных на пользователя функциях протокола, а также любом содержимом, которое передаётся.

Пример

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

Влияние

  • Право на свободу выражения
  • Право на участие в политической жизни
  • Право на участие в культурной жизни, искусстве и науке

4.6. Локализация

Вопросы

Поддерживает ли протокол стандарты интернационализации? Сделаны ли какие-либо шаги в направлении локализации протокола для соответствующей аудитории?

Пояснения

«Локализация — это адаптация продукции, приложения или содержимого документов в соответствии с требованиями языка, культуры и т. д. конкретного целевого рынка (locale)» [W3Ci18nDef]. Для целей документа локализацию можно описать как перевод реализации для обеспечения функциональности на конкретном языке или для пользователей с определёнными локальными настройками (см. параграф 4.5). Интернационализация связана с локализацией, но не совпадает с ней. Поддержка разных языков является необходимым условием локализации.

Пример

Internet является глобальной средой, но многие протоколы и продукция разработаны с учётом интересов некой аудитории, которая часто обладает определёнными свойствами, например, умеет читать и писать в кодировке стандартного американского кода обмена информацией (American Standard Code for Information Interchange или ASCII) и знает английский язык. Это ограничивает возможности значительной части мирового сетевого сообщества использовать Internet так, чтобы сеть была доступна с точки зрения языка и культуры. Пример стандарта, учитывающего мнение о том, что люди хотят иметь доступ к данным, на предпочтительном для них языке, содержится в [RFC5646], где описан способ маркировки информации с помощью языковых тегов. Это позволяет представлять информацию и получать доступ к ней на нескольких языках.

Влияние

  • Право на недискриминацию
  • Право на участие в культурной жизни, искусстве и науке
  • Право на свободу выражения

4.7. Открытые стандарты

Вопросы

Документирован ли протокол полностью так, чтобы его можно было легко реализовать, улучшить, развить или продолжить его разработку? Требуется ли фирменный (proprietary) код для реализации, работы или дальнейшего развития протокола? Отдаёт ли протокол предпочтение своей спецификации перед технически эквивалентами конкурирующих спецификаций, например, делая встроенную спецификацию производителя требуемой или рекомендуемой [RFC2026]? Имеются ли ссылки на другие стандарты, которые требуют оплаты (можно ли обойтись без неё)? Известны ли какие-либо патенты, препятствующие полной реализации стандарта [RFC8179] [RFC6701]?

Пояснения

Сеть Internet смогла стать глобальной сетью сетей благодаря наличию открытых, не патентованных (non-proprietary) стандартов [Zittrain], которые имеют решающее значение для функциональной совместимости. Однако открытые стандарты не определены явно в рамках IETF. По этому поводу в [RFC2026] сказано:

Различные национальные и международные организации (такие, как ANSI, ISO, IEEE, ITU-T) разрабатывают многочисленные спецификации протоколов и услуг, подобные определенным здесь [в IETF] техническим спецификациям (Technical Specifications). Национальные и международные группы также публикуют «соглашения разработчиков», аналогичные определенным здесь заявлениям о применимости (Applicability Statement) и содержащие детали зависящих от реализации практических применений своих стандартов. В рамках процесса стандартизации Internet все эти документы рассматриваются, как открытые внешние стандарты (open external standards).

В [RFC3935] также нет определения открытых стандартов, но подчёркнута важность «открытого процесса»:
… любое заинтересованное лицо может участвовать в работе, знать, что решается, и высказывать [своё] мнение по данному вопросу.

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

Все стандарты, требующие реализации, следует делать доступными свободно и обеспечивать им разумную защиту от патентных претензий, чтобы эти стандарты можно было реализовать в программах с открытым кодом или бесплатных программах. Патенты зачастую сдерживают открытую стандартизацию или используются против тех, кто внедряет открытые стандарты, особенно в сфере криптографии [Newegg]. Иногда делаются исключения, если стандартизованный протокол нормативно полагается на спецификации, разработанные другими органами стандартизации (Standards Development Organization или SDO), к которым нет свободного доступа. Патентам в открытых стандартах и нормативных ссылках на другие стандарты следует содержать раскрытие [Note-well], бесплатное лицензирование [Patent-policy] или иной вариант разумных, справедливых и недискриминационных условий.

Пример

В [RFC6108] описана система предоставления критических уведомлений конечным пользователям web-браузеров, которая была внедрена провайдером (Internet Service Provider или ISP) Comcast. Такая система уведомлений служит для практически мгновенного информирования клиентов, например, о том, что их трафик имеет поведение, характерное для наличия вредоносного кода или заражения вирусом. Имеются и другие фирменные системы, поддерживающие такие уведомления, но в них применяется технология глубокой проверки пакетов (Deep Packet Inspection или DPI). В упомянутом документе описана система, не использующая DPI и основанная на открытых стандартах IETF и приложениях с открытым исходным кодом.

Влияние

  • Право на свободу выражения
  • Право на участие в культурной жизни, искусстве и науке

4.8. Поддержка неоднородности

Вопросы

Поддерживает ли протокол неоднородность (гетерогенность) по своему устройству? Позволяет ли протокол использовать несколько типов оборудования? Разрешает ли протокол использовать несколько типов прикладных протоколов? Насколько строг протокол в отношении того, что он принимает и обрабатывает? Останется ли протокол пригодным для использования и открытым при смене контекста?

Пояснения

Сеть Internet является неоднородной на многих уровнях — устройства, узлы, алгоритмы планирования в маршрутизаторах, механизмы управления очередями, протоколы маршрутизации, уровни мультиплексирования, версии и реализации протоколов, базовые канальные уровни (например, «точка-точка», каналы с множественным доступом, FDDI и т. п.) в картине трафика и уровнях перегрузки в разное время в разных местах. Кроме того, Internet состоит из автономных организаций и ISP со своими интересами, поэтому имеется значительная неоднородность административных доменов и структур ценообразования. В результате при проектировании требуется поддерживать [FIArch] принципы неоднородности, предложенные в [RFC1958]. Таким образом, поддержка неоднородности протоколом может позволить широкому кругу устройств и (как следствие) пользователей участвовать в работе сети.

Пример

Поддержка неоднородности оказала существенное влияние на успех архитектуры Internet [Zittrain]. Есть знаменитая цитата, часто приписываемая Нильсу Бору: «Предсказывать очень трудно, особенно, когда речь идёт о будущем.» Это справедливо и для будущего архитектуры и инфраструктуры Internet. Поэтому, как правило, важно, насколько это возможно, разрабатывать протоколы для разных устройств и приложений, особенно на нижних уровнях стека. Если же это не делается, следует описать причины такого решения в соответствующем документе.

Влияние

  • Право на свободу выражения
  • Право на участие в политической жизни

4.9. Адаптивность

Вопросы

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

Пояснения

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

Пример

WebRTC генерирует голосовые и/или визуальные (видео) данные и может использоваться в разных местах различными сторонами. Разработаны стандартные интерфейсы прикладных программ (Application Programming Interface или API) для поддержки приложение от различных поставщиков голосовых услуг. Разные участники (стороны) получают близкие возможности. Чтобы все стороны могли опираться на имеющиеся стандарты, эти стандарты должны быть адаптивными и должны позволять инновации без специального разрешения.

Влияние

  • Право на обучение
  • Право на науку
  • Право на свободу выражения
  • Право на свободу собраний и ассоциаций

4.10. Целостность

Вопросы

Обеспечивает ли протокол поддержку, гарантию и/или проверку целостности данных в содержимом? Обеспечивает ли протокол поддержку и гарантии согласованности данных? Позволяет ли протокол (преднамеренно или нечаянно) изменить данные?

Пояснения

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

Пример

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

Влияние

  • Право на свободу выражения
  • Право на безопасность (защиту)

4.11. Подлинность

Вопросы

Достаточны ли меры подтверждения подлинности отдельной атрибутов части данных или сущности (объекта)? Могут ли атрибуты быть искажены в пути (см. параграф 4.13)? Применяется ли стандарт защиты IPsec, DNS Security (DNSSEC), HTTPS и т. п., если это уместно?

Пояснения

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

Пример

Аутентификация данных важна для предотвращения уязвимостей и атак в пути доставки. Такие атаки происходят, когда посторонние перехватывают (зачастую с враждебными целями) коммуникации между двумя сторонами, внедряясь в них и выдавая себя за обе стороны. На практике это выглядит так:
Алиса хочет взаимодействовать с Бобом и передаёт ему сообщение, которое Корин перехватывает (и может изменять). Боб не может знать, что данные поступили от Корин, а не от Алисы.
При надлежащей аутентификации сценарий может выглядеть, как показано ниже.
Алиса хочет взаимодействовать с Бобом и передаёт ему сообщение. Корин перехватывает данные, направленные Бобу. Корин читает и изменяет направленное Бобу сообщение. Боб не может проверить, поступили ли данные от Алисы.

Влияние

  • Право на приватность
  • Право на свободу выражения
  • Право на безопасность (защиту)

4.12. Конфиденциальность

Вопросы

Раскрывает ли протокол передаваемые в линию данные? Раскрываются ли сведения, связанные с идентификаторами или данными? Если да, то что раскрывается каждому элементу протокола (получателям, посредникам, организаторам) [RFC6973]? Какие возможности предоставляются разработчикам для ограничения сведений, раскрываемых каждому элементу? Какие средства оперативного контроля доступны для ограничения сведений, передаваемых каждому объекту?
Какие механизмы контроля или согласования определяет или требует протокол до передачи или раскрытия персональных данных или идентификаторов? При отсутствии таких механизмов и элементов управления предполагаются ли внешние механизмы контроля или согласования?
Предусмотрены ли в протоколе возможности передачи инициатором разных частей информации разным получателям? Если нет, существуют ли внешние механизмы для такой дифференциации?
Предусматривает ли протокол средства для ограничения обмена информацией или выражения индивидуальных предпочтений в части сбора, использования или раскрытия персональных данных? Если нет, имеются ли внешние механизмы, предоставляющие пользователям такой контроль? Предполагается ли, что пользователи поддерживают отношения (соглашения или иные способы), регулирующие использование информации сторонами, которые управляют посредниками? Предпочитает ли протокол использовать шифрование, а не открытые данные?

Пояснения

Конфиденциальность означает сохранение данных в тайне от непредусмотренных лиц [RFC3552]. Рост Internet зависит от уверенности пользователей в защите сетью их персональных данных [RFC1984]. Возможность повсеместного мониторинга и наблюдения подрывает доверие пользователей и может быть снижена за счет гарантий конфиденциальности, т. е. пассивные атакующие не смогут получить информации (или получат очень мало сведений) из своих наблюдений и выводов об активности протоколов [RFC7258] [RFC7624].

Пример

Протоколы, не шифрующие содержимое, делают сообщения доступными для идеализированного злоумышленника на пути. В соответствии с [RFC3365] большинство таких протоколов имеет защищённый вариант с шифрованием содержимого для обеспечения конфиденциальности и такие варианты применяются все шире. Примечательным исключением является протокол DNS [RFC1035], поскольку DNSSEC [RFC4033] не включает требований конфиденциальности. Это означает, что без применения более современных стандартов, таких как DNS через TLS [RFC7858] или HTTPS [RFC8484], все запросы и отклики DNS, создаваемые при работе любого протокола, будут доступны злоумышленникам. При использовании протоколов пересылки с промежуточным хранением (store-and-forward, например, SMTP [RFC5321]) посредники оставляют сохранённые данные доступными для взломавших посредника злоумышленников, если только не применяется сквозное шифрование данных в протоколах прикладного уровня или реализация не помещает данные в шифрованное хранилище [RFC7624].

Влияние

  • Право на приватность
  • Право на безопасность (защиту)

4.13. Безопасность

Вопросы

Знакомы ли вы с «Руководством по написанию текста RFC по вопросам безопасности» [RFC3552]? Обнаружены ли какие-либо атаки, в той или иной степени связанные с протоколом (спецификацией), но считающиеся выходящими за рамки этого документа? Относятся ли эти атаки к свойствам Internet, связанным с правами человека (как описано в этом документе)?

Пояснения

Безопасность не является монолитным свойством протокола или системы, а скорее состоит из ряда связанных, но в определённой степени независимых свойств. Не все эти свойства нужны каждому приложению. Поскольку взаимодействия происходят между системами, а доступ к этим системам осуществляется по каналам связи, цели безопасности очевидно будут взаимосвязанными, но могут быть достигнуты независимыми путями [RFC3552].
Обычно любой протокол, применяемый в Internet, может стать целью пассивных (злоумышленник имеет доступ в сеть и способен просматривать пакеты) и активных (злоумышленник способен осуществлять запись в пакеты) атак [RFC3552].

Пример

См. [RFC3552].

Влияние

  • Право на свободу выражения
  • Право на свободу собраний и ассоциаций
  • Право на недискриминацию
  • Право на безопасность (защиту)

4.14. Приватность

Вопросы

Ознакомились ли вы с рекомендациями раздела 7 «Вопросы приватности для протоколов Internet» [RFC6973]? Поддерживает ли протокол конфиденциальность метаданных? Может ли протокол противостоять анализу трафика? Придерживается ли протокол принципам минимизации данных? Указаны ли в документе потенциально чувствительные данные, записываемые (log) протоколов и как долго их нужно хранить по техническим причинам?

Пояснения

Приватность относится к праву субъекта (обычно человека), действующего от своего имени, определять степень взаимодействия с окружением, включая уровень готовности делиться своей персональной информацией с другими [RFC4949]. Если протокол не обеспечивает достаточной защиты приватности, он может негативно влиять на свободу выражения, поскольку пользователи будут применять самоцензуру, опасаясь слежки, или сочтут невозможным свободное выражение своего мнения.

Пример

См. [RFC6973].

Влияние

  • Право на свободу выражения
  • Право на приватность
  • Право на недискриминацию

4.15. Анонимность и псевдонимы

Вопросы

Использует ли протокол идентификаторы? Являются ли идентификаторы постоянными? Применяются ли идентификаторы в разном контексте? Может ли пользователь сбросить или поменять идентификатор без негативного влияния на работу протокола? Видны ли идентификаторы за пределами конечных точек протокола? Связаны ли они с идентификаторами из реального мира? Рассматривался ли документ «Вопросы приватности для протоколов Internet» [RFC6973], особенно параграф 6.1.2?

Пояснения

Большинство протоколов зависит от использования тех или иных идентификаторов для сопоставления действий в пространстве и времени, например:
  • адреса IP служат для идентификации отправителей и получателей дейтаграмм IP;
  • идентификаторы соединений QUIC служат для распознавания пакетов, относящихся к соединению;
  • в HTTP применяются cookie для сопоставления запросов HTTP с клиентом;
  • в электронной почте применяются адреса вида example@example.com для указания отправителей и получателей.

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

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

  • Идентификатор может не раскрывать пользователя, но позволять собрать достаточно подробные сведения о его поведении, чтобы поставить под угрозу его приватность, как в случае с HTTP cookie.

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

Влияние

  • Право на недискриминацию
  • Право на свободу выражения
  • Право на участие в политической жизни
  • Право на свободу собраний и ассоциаций

4.15.1. Псевдонимы

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

Пример

При разработке протокола IPv6 рассматривался вопрос встраивания адреса канального уровня (Media Access Control или MAC) в уникальный адрес IP. Это позволило бы прослушивающим трафик и другим сборщикам сведений сопоставлять адреса из разных транзакций с конкретными узлами. По этой причине были предприняты усилия по стандартизации, такие как «Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6» [RFC8981] и рандомизация адресов MAC [MAC-ADDRESS-RANDOMIZATION].
Отметим, что зачастую представляется привлекательным создание псевдонимов из постоянных идентификаторов. Очень сложно сделать это так, чтобы невозможно было раскрыть такой постоянный идентификатор.

Пример

Распространённой практикой web-отслеживания является «шифрование» адресов электронной почты путём их хэширования, что якобы делает адреса не связанными с персональным идентификатором. Однако функции хэширования являются общедоступными и можно провести поиск по словарю возможных адресов и найти исходный адрес электронной почты [Email-hashing].

4.15.2. Невозможность привязки

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

Пример

Примером является протокол динамической настройки хостов (Dynamic Host Configuration Protocol или DHCP), где передача постоянного идентификатора в качестве имени клиента не была обязательной и на практике многие реализации делали это ещё до появления DHCP [RFC7844].

Пример

Сторонние cookie кв HTTP позволяют отслеживающим сопоставлять трафик HTTP с разными сайтами. Это является основой целой системы web-отслеживания. Браузеры web все чаще ограничивают использование сторонних cookie для защиты приватности пользователей.

4.16. Стойкость к цензуре

Вопросы

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

Пояснения

Правительства и поставщики услуг блокирует или фильтруют содержимое или трафик, зачастую в тайне от конечных пользователей [RFC7754]. Обзор применяемых методов цензуры приведён в [RFC9505], где описаны свойства протоколов, используемые для цензуры доступа к информации. Стойкость к цензуре относится к методам и мерам предотвращения цензуры в Internet.

Пример

В современной структуре Web имеется ряд архитектурных точек, допускающих вмешательство цензоров. Это включает получение контроля над доменным именем, блокировку DNS на уровне протокола или распознавателей, блокировку адресов IP и блокировку web-серверов. Ведётся активная работа по системам распространения содержимого, которые предполагаются более стойкими к цензуре, и некоторые из таких систем (например, BitTorrent) получили широкое распространение. Однако эти системы могут обладать меньшей надёжностью и производительностью по сравнению с Web (например, не поддерживают активное содержимое на серверах).

Пример

Идентификаторы содержимого, раскрываемые в протоколе, могут применяться для облегчения цензуры, позволяя цензорам определять, какой трафик блокировать. Запросы DNS, заголовки host в запросах HTTP и индикация имён серверов (Server Name Indication или SNI) в ClientHello протокола TLS являются примерами протокольных элементов, которые передаются в открытом виде и применяются цензорами для идентификации содержимого, к которому пользователь пытается получить доступ [RFC9505]. Механизмы вроде Encrypted ClientHello [TLS-ESNI] и DNS через HTTPS [RFC8484], которые шифруют метаданные, обеспечивают некоторую стойкость к этому типу инспекции протоколов. Для доступа к подвергаемым цензуре ресурсам могут также применяться системы с полным шифрованием трафика, такие как Tor <https://torproject.org>.

Пример

Как отмечено выше, одним из способов цензуры web-трафика является требование к серверам блокировать трафик или требование к ISP блокировать запросы к серверам. В HTTP отказ или ограничение доступа могут быть замечены в результате возврата кода состояния 451, который позволяет операторам серверов и посредникам более прозрачно выполнять операции в условиях, когда на их работу оказывают влияние законы или политика государств [RFC7725]. Если протокол потенциально допускает цензуру, разработчикам следует стремиться к заданию кодов ошибок, отражающих различные варианты (например, блокировку по административным правилам, недоступность в соответствии с законом и т. п.) для минимизации двусмысленности на стороне пользователей.

Влияние

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

4.17. Понимание результатов

Вопросы

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

Пояснения

Некоторые технические решения могут приводить к непредвиденным последствиям.

Пример

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

Влияние

  • Право на свободу выражения
  • Право на приватность
  • Право на свободу собраний и ассоциаций
  • Право на доступ к информации

4.18. Доступность

Вопросы

Предназначен ли протокол для обеспечения благоприятной среды для всех? Обращались ли разработчики к W3C Web Accessibility Initiative за примерами и рекомендациями [W3CAccessibility]?

Пояснения

Иногда при разработке протоколов, web-сайтов, web-технологий и инструментов создаются барьеры, препятствующие людям в использовании Web. Internet следует организовывать так, чтобы все люди, независимо от их оборудования, программ, языка, культуры, физических и умственных возможностей, могли пользоваться сетью. При соответствии технологий Internet этим целям сеть станет доступной для людей с разными возможностями слуха, зрения, подвижности, а также разными познавательными (когнитивными) возможностями [W3CAccessibility].

Пример

Протокол HTML, определённый в [HTML], требует, чтобы каждое изображение (с некоторыми исключениями) имело атрибут alt, чтобы изображения были доступны для людей, не способных самостоятельно разобраться с нетекстовым содержимым web-страниц.
Другим примером может служить работа групп AVT и AVTCORE в IETF по прочтению текста в multimedia, текстовой телефонии, беспроводным системам multimedia, и видеосвязи для языка жестов и чтения по губам (см. [RFC9071]).

Влияние

  • Право на недискриминацию
  • Право на свободу собраний и ассоциаций
  • Право на обучение
  • Право на участие в политической жизни

4.19. Децентрализация

Вопросы

Можно ли реализовать протокол без единой точки контроля? Можно ли, если это применимо, развернуть протокол федеративным образом? Создаёт ли протокол дополнительные централизованные точки контроля?

Пояснения

Децентрализация является одной из основных технических концепций Internet и принята в таком качестве IETF [RFC3935]. Это означает отсутствие или минимизацию централизованных точек управления, что, как предполагается, упростит присоединение новых пользователей и использование новых возможностей [Ziewitz]. Децентрализация также смягчает проблемы, связанные с критическими точками отказа и обеспечивает функционирование сети даже при отключении одного или нескольких узлов. С коммерциализацией Internet в начале 1990-х годов начался медленный отход от децентрализации в ущерб техническим преимуществам децентрализованной сети Internet. Более подробно этот вопрос рассматривается в [Arkko].

Пример

Данные (биты), передаваемые через Internet, становятся все более чувствительными к отслеживанию и цензуре со стороны правительств и ISP, а также третьих лиц (злоумышленников). Возможности мониторинга и цензуры становятся более доступными с ростом централизации в сети, создающей централизованные точки для подключения. Создание одноранговых сетей и разработка протоколов передачи голоса по IP (voice-over-IP) с использованием одноранговой технологии в сочетании с распределенными хэш-таблицами (Distributed Hash Table или DHT) для масштабируемости является примером сохранения децентрализации [Pouwelse].

Влияние

  • Право на свободу выражения
  • Право на свободу собраний и ассоциаций

4.20. Правовая защита

Вопросы

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

Пояснения

Предоставление государствам и корпорациям доступа к средствам защиты является частью Руководящих принципов ООН для предпринимательской деятельности в аспекте прав человека (UN Guiding Principles on Business and Human Rights) [UNGP]. Доступ к средствам правовой защиты может способствовать жертвам нарушений прав человека в достижении справедливости или позволить правоохранительным органам установить личность возможного нарушителя. Однако имеющиеся в протоколах механизмы, пытающиеся разрешить «атрибутирование» отдельных лиц, препятствуют осуществлению права на приватность. Бывший специальный докладчик ООН по вопросам свободы выражения мнений (UN Special Rapporteur for Freedom of Expression) утверждал, что анонимность является неотъемлемой частью свободы выражения мнений [Kaye]. С учётом возможного влияния атрибутирования на право на приватность и свободу выражения мнений возможность атрибутирования на уровне отдельных лиц скорей всего не будет соответствовать правам человека.

Пример

Добавление идентифицирующих лицо сведений в потоки данных для реализации прав человека на правовую защиту может способствовать выявлению нарушителей прав человека и обеспечить доступ к средствам правовой защиты, но может оказывать непропорциональное влияние на право на приватность, анонимность выражения и участие в ассоциациях других пользователей. Кроме того, в последнее время были достигнуты успехи в части выявления злоупотреблений в системах обмена со сквозным шифрованием, с которыми также связан определённый риск нарушения приватности пользователей [Messenger-franking] [Hecate].

Влияние

  • Право на правовую защиту (возмещение)
  • Право на безопасность (защиту)
  • Право на приватность

4.21. Прочие вопросы

Вопросы

Рассмотрены ли возможные негативные последствия внедрения протокола или документа на отдельных лиц и общество?

Пояснения

Публикация RFC с определенным статусом имеет последствия. Публикация в качестве Internet Standard как часть Standards Track может говорить об определённой зрелости спецификации, опыте её внедрения и согласия на применение. Публикация в качестве экспериментального документа в рамках Standards Track будет указывать сообществу, что документ «может быть не рассчитан на применение как Internet Standard или предназначен для будущей стандартизации, но ещё не готов» для широкого внедрения [RFC2026]. Область внедрения и, следовательно, суммарное влияние на конечных пользователей могут зависеть от статуса документа, указанного в RFC. Более полное описание приведено в [RFC2026] и дополнениях к этому документу.

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

В этом документе исследовательской группы представлен опыт и рекомендации в части экспертизы влияния на права человека сетевых протоколов, архитектур и других документов Internet-Draft и RFC.

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

Третья статья Всеобщей декларации прав человека гласит: «Каждый человек имеет право на жизнь, свободу и личную неприкосновенность» [UDHR]. В этой статье подчёркнута важность безопасности и её связь с жизнью и свободой человека, а, поскольку права человека неделимы, взаимосвязаны и взаимозависимы, безопасность человека тесно связана с другими правами и свободами. Данный документ нацелен на укрепление прав человека, его свободы и безопасности путём сопоставления и трансляции этих концепций в концепции и практику при разработке протоколов и архитектуры Internet. Целью является соблюдение прав человека и соответствующее повышение устойчивости, эффективности и удобства использования сети. Документ стремиться достигнуть поставленных целей путём предоставления руководящих принципов в разделе 3.

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

Этот документ не предполагает действий IANA.

8. Сведения об исследовательской группе

Дискуссионная конференция исследовательской группы IRTF Human Rights Protocol Considerations доступна по адресу <mailto:hrpc@ietf.org>. Сведения о группе и способах подписки на рассылки доступны по ссылке <https://www.irtf.org/mailman/listinfo/hrpc>, архивы почтовой конференции — по ссылке <https://mailarchive.ietf.org/arch/browse/hrpc/>.

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

[Arkko] Arkko, J., Trammell, B., Nottingham, M., Huitema, C., Thomson, M., Tantsura, J., and N. ten Oever, «Considerations on Internet Consolidation and the Internet Architecture», Work in Progress, Internet-Draft, draft-arkko-iab-internet-consolidation-02, 8 July 2019, <https://datatracker.ietf.org/doc/html/draft-arkko-iab-internet-consolidation-02>.

[Email-hashing] Acar, G., Englehardt, S., and A. Narayanan, «Four cents to deanonymize: Companies reverse hashed email addresses», April 2018, <https://freedom-to-tinker.com/2018/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/>.

[FIArch] Papadimitriou, D., Zahariadis, T., Martinez-Julia, P., Papafili, I., Morreale, V., Torelli, F., Sales, B., and P. Demeester, «Design Principles for the Future Internet Architecture», The Future Internet, pp. 55-67, DOI 10.1007/978-3-642-30241-1_6, January 2012, <https://link.springer.com/chapter/10.1007/978-3-642-30241-1_6>.

[FREAK] University of Michigan, «Tracking the FREAK Attack», Wayback Machine archive, March 2015, <https://web.archive.org/web/20150304002021/https://freakattack.com/>.

[Hecate] Issa, R., Alhaddad, N., and M. Varia, «Hecate, Abuse Reporting in Secure Messengers with Sealed Sender», 31st USENIX Security Symposium (USENIX Security 22), pp 2335-2352, August 2022, <https://www.usenix.org/conference/usenixsecurity22/presentation/issa>.

[Hill] Hill, R., «Partial Catalog of Human Rights Related to ICT Activities», May 2014, <http://www.apig.ch/UNIGE%20Catalog.pdf>.

[HR-RT] «IRTF-HRPC / reviews», commit 3f5fbff, December 2020, <https://github.com/IRTF-HRPC/reviews>.

[HTML] WHATWG, «HTML Living Standard», August 2024, <https://html.spec.whatwg.org/multipage/>.

[HTTPS-interception] Durumeric, Z., Ma, Z., Springall, D., Barnes, R., Sullivan, N., Bursztein, E., Bailey, M., Halderman, J., and V. Paxson, «The Security Impact of HTTPS Interception», NDSS Symposium 2017, DOI 10.14722/ndss.2017.23456, February 2017, <https://doi.org/10.14722/ndss.2017.23456>.

[ICCPR] United Nations General Assembly, «International Covenant on Civil and Political Rights», December 1966, <https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-civil-and-political-rights>.

[ICESCR] United Nations General Assembly, «International Covenant on Economic, Social and Cultural Rights», December 1966, <https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-economic-social-and-cultural-rights>.

[IRP] Internet Rights and Principles Dynamic Coalition, «10 Internet Rights & Principles», <https://internetrightsandprinciples.org/campaign/>.

[Jorgensen] Jørgensen, R. F., «An internet bill of rights», Research Handbook on Governance of the Internet, edited by Ian Brown. Cheltenham: Edward Elgar Publishing, DOI 10.4337/9781849805025.00022, April 2013, <https://doi.org/10.4337/9781849805025.00022>.

[Kaye] Kaye, D., «Report of the Special Rapporteur on the Promotion and Protection of the Right to Freedom of Opinion and Expression, David Kaye», A/HRC/29/32, May 2015, <https://digitallibrary.un.org/record/798709?v=pdf>.

[Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Béguelin, S., and P. Zimmerman, «Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice», CCS ’15: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp 5-17, DOI 10.1145/2810103.2813707, October 2015, <https://doi.org/10.1145/2810103.2813707>.

[MAC-ADDRESS-RANDOMIZATION] Zúñiga, J. C., Bernardos, C. J., Ed., and A. Andersdotter, «Randomized and Changing MAC Address State of Affairs», Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-15, 15 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-15>.

[Messenger-franking] Grubbs, P., Lu, J., and T. Ristenpart, «Message Franking via Committing Authenticated Encryption», Cryptology ePrint Archive, Paper 2017/664, July 2017, <https://eprint.iacr.org/2017/664>.

[Newegg] Mullin, J., «Newegg on trial: Mystery company TQP rewrites the history of encryption», Ars Technica, November 2013, <https://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/>.

[Note-well] IETF, «Note Well», <https://www.ietf.org/about/note-well/>.

[Orwat] Orwat, C. and R. Bless, «Values and Networks: Steps Toward Exploring their Relationships», ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, pp 25-31, DOI 10.1145/2935634.2935640, May 2016, <https://doi.org/10.1145/2935634.2935640>.

[Patent-policy] Weitzner, D., «W3C Patent Policy», W3C Recommendation, February 2004, <https://www.w3.org/Consortium/Patent-Policy-20040205/>.

[Penney] Penney, J., «Chilling Effects: Online Surveillance and Wikipedia Use», Berkeley Technology Law Journal, vol. 31, no. 1, pp 117-182, DOI 10.15779/Z38SS13, September 2016, <https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2769645>.

[Pouwelse] Pouwelse, J., Ed., «Media without censorship (CensorFree) scenarios», Work in Progress, Internet-Draft, draft-pouwelse-censorfree-scenarios-02, 22 October 2012, <https://datatracker.ietf.org/doc/html/draft-pouwelse-censorfree-scenarios-02>.

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

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

[RFC1984] IAB and IESG, «IAB and IESG Statement on Cryptographic Technology and the Internet», BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <https://www.rfc-editor.org/info/rfc1984>.

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

[RFC2277] Alvestrand, H., «IETF Policy on Character Sets and Languages», BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <https://www.rfc-editor.org/info/rfc2277>.

[RFC3365] Schiller, J., «Strong Security Requirements for Internet Engineering Task Force Standard Protocols», BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <https://www.rfc-editor.org/info/rfc3365>.

[RFC3552] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, «The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture», RFC 3724, DOI 10.17487/RFC3724, March 2004, <https://www.rfc-editor.org/info/rfc3724>.

[RFC3935] Alvestrand, H., «A Mission Statement for the IETF», BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <https://www.rfc-editor.org/info/rfc3935>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4101] Rescorla, E. and IAB, «Writing Protocol Models», RFC 4101, DOI 10.17487/RFC4101, June 2005, <https://www.rfc-editor.org/info/rfc4101>.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.

[RFC5321] Klensin, J., «Simple Mail Transfer Protocol», RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.

[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, «Comcast’s Web Notification System Design», RFC 6108, DOI 10.17487/RFC6108, February 2011, <https://www.rfc-editor.org/info/rfc6108>.

[RFC6365] Hoffman, P. and J. Klensin, «Terminology Used in Internationalization in the IETF», BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.

[RFC6701] Farrel, A. and P. Resnick, «Sanctions Available for Application to Violators of IETF IPR Policy», RFC 6701, DOI 10.17487/RFC6701, August 2012, <https://www.rfc-editor.org/info/rfc6701>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7258] Farrell, S. and H. Tschofenig, «Pervasive Monitoring Is an Attack», BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, «Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension», RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, «Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement», RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.

[RFC7725] Bray, T., «An HTTP Status Code to Report Legal Obstacles», RFC 7725, DOI 10.17487/RFC7725, February 2016, <https://www.rfc-editor.org/info/rfc7725>.

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, «Technical Considerations for Internet Service Blocking and Filtering», RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, «Anonymity Profiles for DHCP Clients», RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, «Specification for DNS over Transport Layer Security (TLS)», RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC8179] Bradner, S. and J. Contreras, «Intellectual Property Rights in IETF Technology», BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, <https://www.rfc-editor.org/info/rfc8179>.

[RFC8280] ten Oever, N. and C. Cath, «Research into Human Rights Protocol Considerations», RFC 8280, DOI 10.17487/RFC8280, October 2017, <https://www.rfc-editor.org/info/rfc8280>.

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

[RFC8484] Hoffman, P. and P. McManus, «DNS Queries over HTTPS (DoH)», RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC8558] Hardie, T., Ed., «Transport Protocol Path Signals», RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.

[RFC8890] Nottingham, M., «The Internet is for End Users», RFC 8890, DOI 10.17487/RFC8890, August 2020, <https://www.rfc-editor.org/info/rfc8890>.

[RFC8980] Arkko, J. and T. Hardie, «Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development», RFC 8980, DOI 10.17487/RFC8980, February 2021, <https://www.rfc-editor.org/info/rfc8980>.

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, «Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6», RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., «QUIC: A UDP-Based Multiplexed and Secure Transport», RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9071] Hellström, G., «RTP-Mixer Formatting of Multiparty Real-Time Text», RFC 9071, DOI 10.17487/RFC9071, July 2021, <https://www.rfc-editor.org/info/rfc9071>.

[RFC9293] Eddy, W., Ed., «Transmission Control Protocol (TCP)», STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, «The Messaging Layer Security (MLS) Protocol», RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/info/rfc9420>.

[RFC9505] Hall, J. L., Aaron, M. D., Andersdotter, A., Jones, B., Feamster, N., and M. Knodel, «A Survey of Worldwide Censorship Techniques», RFC 9505, DOI 10.17487/RFC9505, November 2023, <https://www.rfc-editor.org/info/rfc9505>.

[Saltzer] Saltzer, J. H., Reed, D. P., and D. D. Clark, «End-to-end arguments in system design», ACM Transactions on Computer Systems, vol. 2, no. 4, pp 277-288, DOI 10.1145/357401.357402, November 1984, <https://doi.org/10.1145/357401.357402>.

[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, «TLS Encrypted Client Hello», Work in Progress, Internet-Draft, draft-ietf-tls-esni-20, 4 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20>.

[UDHR] United Nations General Assembly, «Universal Declaration of Human Rights», December 1948, <https://www.un.org/en/about-us/universal-declaration-of-human-rights>.

[UNGP] United Nations, «Guiding Principles on Business and Human Rights: Implementing the United Nations ‘Protect, Respect and Remedy’ Framework», January 2012, <https://www.ohchr.org/en/publications/reference-publications/guiding-principles-business-and-human-rights>.

[UNHR] United Nations, «The Core International Human Rights Instruments and their monitoring bodies», <https://www.ohchr.org/en/core-international-human-rights-instruments-and-their-monitoring-bodies>.

[UNHRC2016] United Nations Human Rights Council, «The promotion, protection and enjoyment of human rights on the Internet», A/HRC/32/L.20, June 2016, <https://digitallibrary.un.org/record/845728?ln=en>.

[W3CAccessibility] W3C, «Accessibility», <https://www.w3.org/standards/webdesign/accessibility>.

[W3Ci18nDef] Ishida, R. and S. Miller, «Localization vs. Internationalization», December 2005, <https://www.w3.org/International/questions/qa-i18n.en>.

[Ziewitz] Ziewitz, M. and I. Brown, «A Prehistory of Internet Governance», Research Handbook on Governance of the Internet, edited by Ian Brown. Cheltenham: Edward Elgar Publishing, DOI 10.4337/9781849805025.00008, April 2013, <https://doi.org/10.4337/9781849805025.00008>.

[Zittrain] Zittrain, J., «The Future of the Internet and How to Stop It», Yale University Press, 2008, <https://dash.harvard.edu/handle/1/4455262>.

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

Спасибо:

  • Corinne Cath-Speth за работу над [RFC8280];

  • Reese Enghardt, Joe Hall, Avri Doria, Joey Salazar, Corinne Cath-Speth, Farzaneh Badii, Sandra Braman, Colin Perkins, John Curran, Eliot Lear, Mallory Knodel, Brian Trammell, Jane Coffin, Eric Rescorla, Sofía Celi и почтовой конференции hrpc за рецензии и предложения;

  • лицам, выполнившим обзоры прав человека, за их рецензии и отклики — Amelia Andersdotter, Shane Kerr, Beatrice Martini, Karan Saini, Shivan Kaul Sahib.

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

Gurshabad Grover
Email: gurshabad@cis-india.org
 
Niels ten Oever
University of Amsterdam
Email: mail@nielstenoever.net

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

nmalykh@protokols.ru


1Internet Research Task Force — комиссия по исследовательским задачам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9595 YANG Schema Item iDentifier (YANG SID)

Internet Engineering Task Force (IETF)                 M. Veillette, Ed.
Request for Comments: 9595                       Trilliant Networks Inc.
Category: Standards Track                                  A. Pelov, Ed.
ISSN: 2070-1721                                           IMT Atlantique
                                                          I. Petrov, Ed.
                                                 Google Switzerland GmbH
                                                              C. Bormann
                                                  Universität Bremen TZI
                                                           M. Richardson
                                                Sandelman Software Works
                                                               July 2024

YANG Schema Item iDentifier (YANG SID)

Идентификатор элемента схемы YANG

PDF

Аннотация

Идентификатор элемента схемы YANG (YANG Schema Item iDentifier или YANG SID) — глобально уникальное 63-битовое целое число без знака, служащее для идентификации элементов YANG. SID обеспечивают более компактный метод идентификации тех элементов YANG, которые могут использоваться эффективно, в частности, в средах с ограничениями (RFC 7228). Этот документ задаёт семантику, процессы регистрации и процессы назначения YANG SID для управляемых IETF модулей YANG. Для обеспечения возможности реализации процессов документ также определяет формат файла, используемый для хранения и публикации назначенных YANG SID.

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

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

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

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

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

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

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

1. Введение

Для некоторых элементов, определённых в YANG [RFC7950], требуется использовать уникальный идентификатор. В протоколах NETCONF3 [RFC6241] и RESTCONF [RFC8040] эти идентификаторы реализуются в форме имён. Для реализации моделей данных YANG в устройствах [RFC7228] и сетях с ограничениями, требуется более компактный метод идентификации элементов YANG. Этот компактный идентификатор, называемый идентификатором элемента схемы YANG (YANG Schema Item iDentifier, YANG SID или просто SID, когда контекст в этом документе понятен), представляется в форме 63-битового целого числа без знака. Ограничение размера 63 битами позволяет проще работать с SID на платформах, где для иных задач не требуется поддержка операций с 64-битовыми целыми числами без знака. Потеря одного бита не является существенной с учётом остающегося пространства значений.

С использованием SID указываются:

  • отождествления (идентификаторы);

  • узлы данных (включая узлы, заданные расширениями rc:yang-data [RFC8040] и sx:structure [RFC8791]);

  • вызовы удалённых процедур (remote procedure call, RPC) и связанные с ними входные и выходные данные);

  • действия и связанные с ними входные и выходные данные);

  • уведомления и связанная с ними информация;

  • модули YANG и свойства (функции).

Возможно, что некоторые протоколы будут использовать лишь часть назначенных SID. Например, для отличных от NETCONF [RFC6241] протоколов, предоставляющих доступ к данным на основе моделей YANG, таких как [CORE-COMI], доставка SID модуля YANG может быть ненужной. Доставка такой информации может потребоваться другим протоколам, например, протоколам, связанным с обнаружением, таким как библиотека модулей YANG с ограничениями (Constrained YANG Module Library) [YANG-LIBRARY].

SID — это глобально уникальные целые числа. Для обеспечения уникальности применяется система регистрации. SID регистрируются блоками (диапазонами) — SID range. После признания SID «стабильными» они назначаются навсегда. Элементы, назначенные новой версией модуля YANG добавляются в список уже выделенных SID. Этот вопрос более подробно рассматривается в разделе 2.

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

В разделе 3 подробно рассматриваются процессы регистрации для модулей YANG и связанных с ними SID. Для обеспечения реализации этих процессов в разделе 4 определён стандартный формат файлов для хранения и публикации SID.

Управляемые IETF модули YANG, которым нужно выделить SID, будут использовать механизмы IANA, заданные в этом документе (см. раздел 6). Для модулей YANG других организаций выделение SID происходит с помощью механизмов IANA через мегадиапазоны (Mega-Range, см. параграф 6.3), в рамках которых соответствующая сторона может использовать свои механизмы выделения значений.

YANG SID особенно полезны для компактного кодирования YANG-CBOR [RFC9254]. На момент создания этого документа инструмент для автоматизированного создания файлов .sid был доступен в рамках проекта с открытым кодом PYANG [PYANG].

1.1. Термины и обозначения

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

Ниже перечислены элементы, определённые в [RFC7950].

  • action
  • feature
  • module
  • notification
  • RPC
  • schema node
  • schema tree
  • submodule

В этой спецификации также используются указанные ниже термины.

Item — элемент

Узел схемы, идентификатор (отождествление), модуль или свойство, заданные с использованием языка моделирования YANG.

YANG Schema Item iDentifier (YANG SID или SID) — идентификатор узла схемы YANG

Целое число без знака, служащее для идентификации элемента YANG (см. параграф 3.2 в [RFC9254]).

YANG name — имя YANG

Текстовая строка, служащая для идентификации элемента YANG (см. параграф 3.3 в [RFC9254]).

2. Цели

Главная цель системы назначения и регистрации SID состоит в обеспечении глобальной совместимости протоколов, применяющих SID для обмена данными, смоделированными в YANG. Это вносит определённые требования к стабильности SID, но не препятствует активному развитию модулей YANG, для поддержки которых предназначены SID. Дополнительные цели включают:

  • предоставление разработчикам модулей YANG возможности создания относящихся к этим модулям SID;

  • упрощение разработчикам YANG получения SID;

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

  • поддержка режима назначения, при котором короткие SID (2-4 байта) легко доступны для приложений, где они будут полезны, в сочетании с использованием 63-битового пространства SID для облегчения действий, не требующих разрешения;

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

  • поддержка некоторой лакальности назначения SID для эффективного использования диапазонов (SID delta);

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

Хотя реестры, управляющие SID для определяемых IETF модулей, в конечном итоге поддерживает IANA, нужны различные инструменты (такие как каталог YANG [yangcatalog]) для предоставления возможности назначать и использовать SID в модулях, ещё находящихся в разработке IETF. Разработчикам открытых и фирменных модулей YANG требуется возможность автономного назначения идентификаторов, возможно, с формированием независимых от IETF объединений, с сохранением общего пространства значений SID, управляемого IANA. Очевидно, что этот процесс имеет много сходства с распределением адресов IP, но между ними есть и существенные различия.

2.1. Технические цели

Как отмечено в введении, идентификаторы SID задуманы как глобально уникальные целые числа без знака. Это, в частности, означает цель 1 (MUST — должно):

Любое 63-битовое целое число без знака (1) либо не назначается как SID, либо (2) незыблемо связывается в точности с одним именем YANG. Разрешен лишь переход невыделенных значений в число привязанных навсегда.

Это позволяет получателю структуры данных, содержащей SID, преобразовать их в глобально значимые имена YANG, которые применяются в настоящее время в имеющихся кодировках данных YANG, таких как YANG-XML [RFC7950] и YANG-JSON [RFC7951].

Термин «имя YANG» не определён вне этого документа и в YANG применяется сложная схема имён и сущностей, которые могут иметь имена. Вместо технического определения термина набор целей использует его так, чтобы были достигнуты общие цели YANG SID. Желательная цель 2 (SHOULD — следует):

Любое активно применяемое имя YANG имеет один назначенный ему идентификатор SID.

Это означает, что:

  1. не следует иметь имена YANG без назначенного SID;

  2. именам YANG не следует иметь несколько SID.

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

2.2. Эволюция и версии модулей

Модули YANG эволючионируют (см. раздел 11 в [RFC7950] и параграф 4.27 в RFC 8407 [BCP216]), а технические цели с формулированы выше без учёта этого развития. Однако некоторые модули все ещё находятся в очень подвижном состоянии и назначать постоянные SID именам YANG из таких модулей нежелательно. Это относится не только к новым модулям, но и к создаваемым новым версиях имеющихся стабильных модулей. С этим связана цель 3 (MUST — должно):

Система назначения SID независима от версий модулей.

2.3. Компоненты решения и производные цели

Для гарантии уникальности SID применяется система регистрации. Чтобы обеспечить некоторую автономность при выделении (и избежать раскрытия информации там, где это нежелательно) SID регистрируются диапазонами (SID range). Значения SID выделяются навсегда и не могут быть изменены. Элементы, введённые новым выпуском модуля YANG, добавляются к списку уже выделенных SID.

2.4. Участники и роли

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

module controller — контролёр модуля

Владелец модуля YANG, т. е. лицо (организация), контролирующее развитие модуля.

registration entity — орган регистрации

Контролёр пространства имён модуля, в частности, префиксов, которые обычно применяются (неообязательная строна).

module repository — репозиторий модулей

Сущность, предоставляющая модули их пользователям. Это может быть «официальный» (например, IANA для модулей IETF) или «неофициальный» орган (например, каталог YANG [yangcatalog]). Не все репозитории могут выступать в роли реестра, т. е. постоянного хранилища записей для предоставляемой информации. Репозитории могут обращаться к владельцам модулей как стабильному источнику сведений.

module user — пользователь модуля

Субъект, использующий модуль после его получения от контролёра или из репозитория.

Этот набор сторон нужно расширить с учётом дополнительных ролей, требуемых для процесса назначения SID.

SID assigner — назначающий SID орган (сущность)

Орган, назначающих SID для модуля. Цель 2 состоит в том, чтобы для каждого модуля SID назначал лишь один орган. Желательно, чтобы назначающий SID орган не менялся в процессе разработки модуля, однако данная спецификация определяет файлы .sid для обеспечения организованной передачи.

SID range registry — реестр диапазонов SID

Орган, которыя предоставляет назначающему SID органу диапазоны SID для выделения SID модулям. В данной спецификации имеется структура с мегадиапазонами (Mega-Range) и индивидуальными диапазонами SID.

SID repository — репозиторий SID

Сущность, предоставляющая назначенные SID их пользователям (обычно в форме файла .sid).

SID user — пользователь SID

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

По мере внедрения SID в модели данных YANG распределение ролей между имеющимися сторонами для модуля YANG будет развиваться. Желаемое финальное состояние этого развития показано в таблице 1.

Таблица . Стороны и роли — желаемое финальное состояние.

 

Роль

Сторона

Назначающий SID орган

Разработчик модуля

Реестр диапазонов SID

В соответствии с данной спецификацией

Репозиторий SID

Репозиторий модулей

Пользователь SID

Пользователь модуля

 

Такое распределение ролей позволяет разработчику модуля достигнуть целей, указанных в этом разделе (контролёр модуля руководящий SID, тип 1). Хотя теоретически кто-то другой может назначить дополнительные SID в противоречие цели 2, для этого будет мало причин, если разработчик модуля всегда предоставляет вместе с модулем файл .sid.

Остальная часть раздела посвящена переходу в желаемое финальное состояние.

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

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

Если контролёр модуля знает о SID, но пока не назначает их, он может указать назначающего SID вместо себя. Это может привести к тому, что стабильный набор уникальных SID будет назначаться разработчиком модуля опосредованно (знающий о SID контролёр, тип 2). Органы, предлагающие услуги назначенного SID-ассистента, могут обеспечивать обслуживание удобным способом, например, через web-интерфейс.

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

Назначающий SID орган, имеющий дело с разрабатываемым (ещё нестабильным) модулей, должен решить, назначать ли SID для нового выпуска «с нуля» (с чистого листа) или использовать имеющиеся назначения из предыдущего выпуска как базу и назначать новые SID только для новых имён. Когда модуль сочтён стабильным, назначенные для него SID также следует объявить стабильными (с учётом того, что для имеющихся модулей YANG может потребоваться тот или иной пересмотр).

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

3. Жизненный цикл файла .sid

Язык YANG предназначен для моделирования данных, доступ к которым осуществляется по одному из совместимых протоколов, например, NETCONF [RFC6241], RESTCONF [RFC8040], CORECONF (CoAP Management Interface) [CORE-COMI]). Модули YANG задают иерархии данных, включая данные конфигурации и состояния, RPC, действия и уведомления. Многие модули YANG создаются вне контекста приложений с ограничениями. Модули YANG можно реализовать с использованием NETCONF [RFC6241] или RESTCONF [RFC8040] без необходимости назначать SID.

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

Элементы, введённые новым выпуском модуля YANG, добавляются в список уже выделенных SID. Когда это происходит в процессе создания документа по новому протоколу, может потребоваться предварительное назначение идентификаторов, которые могут быть изменены, пересмотрены или отозваны во время разработки нового стандарта. Такие предварительные назначения получают статус нестабильных, чтобы их можно было удалить, а SID потом заново выделить для другого имени/пути схемы YANG в процессе разработки. Когда спецификация становится завершённым документом, назначенные идентификаторы получают статус стабильных. В процессе разработки, начиная с момента публикации спецификации, для средств разработки следует делать доступными два варианта файла .sid: (1) «общедоступный файл» файл .sid, содержащий только стабильные (в том числе в процессе разработки) SID, и «непубличный», который содержит нестабильные назначения SID.

Регистрация файла .sid, связанного с модулем YANG не требуется, но рекомендуется и будет способствовать функциональной совместимости устройств, а также позволит избежать дублирования SID для одного модуля YANG. Реестры могут предъявлять разные требования к регистрации и публикации файлов .sid. В качестве одного из вариантов может служить диаграмма действий на рисунке 4 в Приложении C.

При каждом обновлении модуля YANG, его субмодулей или импортируемых модулей может создаваться новый файл .sid, если новым или измененным элементам нужны SID. Все SID из прежней версии файла .sid, которая активно применялась, должны присутствовать в новаой версии файла. Создавать новые версии файлов .sid следует с помощью автоматизированных инструментов.

Если для новой версии требуется больше SID, чем было выделено изначально, в элемент assignment-range (раздел 4) должен добавляться новый диапазон SID. Эти SID применяются для последующих назначений. Пример процесса обновления представлен на рисунке 5 в Приложении C.

4. Формат файла .sid

Файлы .sid применяются для хранения и публикации SID, выделенных элементам YANG в конкретном модуле YANG. На рисунке 1 представлено дерево [BCP215], иллюстрирующее модель данных.

   module: ietf-sid-file

     structure sid-file:
       +-- module-name            yang:yang-identifier
       +-- module-revision?       revision-identifier
       +-- sid-file-version?      sid-file-version-identifier
       +-- sid-file-status?       enumeration
       +-- description?           string
       +-- dependency-revision*   [module-name]
       |  +-- module-name         yang:yang-identifier
       |  +-- module-revision     revision-identifier
       +-- assignment-range*      [entry-point]
       |  +-- entry-point         sid
       |  +-- size                uint64
       +-- item*                  [namespace identifier]
          +-- status?             enumeration
          +-- namespace           enumeration
          +-- identifier          union
          +-- sid                 sid

Рисунок . Дерево YANG для ietf-sid-file.


Ниже представлен модуль YANG, определяющий структуру файлов .sid. Кодирование выполняется в формате JSON [STD90] по правилам, заданным в [RFC7951]. Этот модуль импортирует ietf-yang-types [RFC6991] и ietf-yang-structure-ext [RFC8791], а также ссылается на [STD68], [RFC7950] и [BCP216].

   <CODE BEGINS> file "ietf-sid-file@2024-07-31.yang"
   module ietf-sid-file {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
     prefix sid;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-structure-ext {
       prefix sx;
       reference
         "RFC 8791: YANG Data Structure Extensions";
     }

     organization
       "IETF CORE Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/core/> 

        WG List:  <mailto:core@ietf.org> 

        Editor:   Michel Veillette
                  <mailto:michel.veillette@trilliant.com> 

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

        Editor:   Alexander Pelov
                  <mailto:alexander.pelov@imt-atlantique.fr> 

        Editor:   Ivaylo Petrov
                  <mailto:ivaylopetrov@google.com>"; 

     description
       "Этот модуль определяет структуру файлов .sid.

        Каждый файл .sid содержит сопоставление строковых идентификаторов
        модуля YANG с соответствующими числовыми значениями YANG SID.

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

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

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

        Эта версия данного модуля YANG является частью RFC 9595, где
        правовые вопросы рассмотрены более полно.";

     revision 2024-07-31 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9595: YANG Schema Item iDentifier (YANG SID)";
     }

     typedef revision-identifier {
       type string {
         pattern '[0-9]{4}-[0-9]{2}-[0-9]{2}';
       }
       description
         "Дата в формате YYYY-MM-DD.";
     }

     typedef sid-file-version-identifier {
       type uint32;
       description
         "Версия файла .sid.";
     }

     typedef sid {
       type uint64 {
         range "0..9223372036854775807";
       }
       description
         "Идентификатор элемента схемы YANG.";
       reference
         "RFC 9595: YANG Schema Item iDentifier (YANG SID)";
     }

     typedef schema-node-path {
       type string {
         pattern
           '/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +
           '(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';
       }
       description
         "Путь к узлу схемы - это абсолютный идентификатор узла схемы 
          YANG, по правилу YANG ABNF absolute-schema-nodeid, но с
          использованием имён модулей вместо префиксов.
          К этой строке дополнительно применяются указанные ниже правила
          -  самое левое (верхний уровень) имя узла данных всегда 
             указывается с пространством имён (namespace-qualified);
          -  любое последующее имя узла схемы имеет форму namespace-
             qualified, если узел определён в модуле, отличном от
             родительского, и простую форму в иных случаях. Предикаты
             не разрешены";
       reference
         "RFC 5234 (STD 68): Augmented BNF for Syntax Specifications:
                             ABNF
          RFC 7950: The YANG 1.1 Data Modeling Language,
                    Section 6.5: Schema Node Identifier";
     }

     sx:structure sid-file {
       uses sid-file-contents;
     }

     grouping sid-file {
       description
         "Группировка с контейнером YANG, представляющим структуру
          файла .sid.";

       container sid-file {
         description
           "Контейнер-оболочка, который вместе с расширением 
            sx:structure маркирует находящиеся в нем структуры данных
            YANG как не предназначенные для реализации в виде части
            хранилища конфигурации или рабочего состояния на сервере.";
         uses sid-file-contents;
       }
     }

     grouping sid-file-contents {
       description
         "Группировка, задающая содержимое контейнера, представляющего
          структуру файла .sid.";

       leaf module-name {
         type yang:yang-identifier;
         mandatory true;
         description
           "Имя модуля YANG, связанного с файлом .sid.";
       }

       leaf module-revision {
         type revision-identifier;
         description
           "Выпуск модуля YANG, связанного с этим файлом .sid. Этот лист
            отсутствует, если в модуле YANG нет оператора revision.";
       }

       leaf sid-file-version {
         type sid-file-version-identifier;
         default 0;
         description
           "Необязательный лист, указывающий номер версии файла .sid.
            Нумерация версий определяется конкретным выпуском модуля
            YANG, начинается с 0 для первого выпуска и далее возрастает
            монотонно. Значение позволяет различать обновления файла
            .sid, например, в результате обработки или исправления
            найденных ошибок.";
       }

       leaf sid-file-status {
         type enumeration {
           enum unpublished {
             description
               "Этот файл .sid не является общедоступным (BCP 216) и
                называется рабочим. Он может сопровождать непубличный
                модуль YANG. Список item МОЖЕТ включать записи со
                статусом unstable.";
             reference
               "RFC 8407 (BCP 216): Guidelines for Authors and
                                    Reviewers of Documents Containing
                                    YANG Data Models";
           }
           enum published {
             description
               "Этот файл .sid является опубликованным. Такой статус 
                применяется к файлам .sid для опубликованных модулей
                YANG. В список item НЕДОПУСТИМО включать записи со
                статусом unstable.";
           }
         }
         default "published";
         description
           "Необязательный лист, указывающий статус файла .sid.";
       }

       leaf description {
         type string;
         description
           "Метаинформация о сгенерированном файле в произвольной форме.
            Може указывать инструмент, создавший файл .sid, время
            генерации и другие данные.";
       }

       list dependency-revision {
         key "module-name";

         description
           "Сведения о выпусках, использованных при генерации файла .sid
            для каждой зависимости, т. е. для каждого модуля YANG,
            импортируемого связанным в файлом .sid модулем YANG.";

         leaf module-name {
           type yang:yang-identifier;
           description
             "Имя модуля YANG для данной зависимости.";
         }
         leaf module-revision {
           type revision-identifier;
           mandatory true;
           description
             "Выпуск модуля YANG для данной зависимости .";
         }
       }

       list assignment-range {
         key "entry-point";
         description
           "Диапазоны YANG-SID, выделенные модулю YANG, указанному
            module-name и module-revision.
            -  Первое значение диапазона YANG-SID - это  entry-point,
               последнее - (entry-point + size - 1).
            -  НЕДОПУСТИМО перерытие диапазонов assignment-range.";

         leaf entry-point {
           type sid;
           description
             "Наименьшее значение YANG SID для выделения.";
         }

         leaf size {
           type uint64;
           mandatory true;
           description
             "Число YANG SID, доступных для выделения.";
         }
       }

       list item {
         key "namespace identifier";
         unique "sid";

         description
           "Каждая запись списка сопоставляет строку идентификатора YANG
            с YANG SID. Список ДОЛЖЕН включать сопоставления для всех
            элементов YANG, заданных в модуле, указанном в module-name и
            module-revision.";

         leaf status {
           type enumeration {
             enum stable {
               value 0;
               description
                 "Это назначение SID опубликовано как стабильное для
                  данного пространства имён и идентификатора.";
             }
             enum unstable {
               value 1;
               description
                 "Это назначение SID выполнено в процессе разработки
                  и ещё не является стабильным.";
             }
             enum obsolete {
               value 2;
               description
                 "Это значение SID больше не используется и указано для
                  предотвращения повторного выделения.";
             }
           }
           default "stable";
           description
             "Сведения о стабильности назначения. Каждое конкретное
              значение SID с течением времени может переходить из 
              состояния unstable в stable, а stable может смениться на
              obsolete.";
         }

         leaf namespace {
           type enumeration {
             enum module {
               value 0;
               description
                 "Все имена в модуле и субмодулях используют глобальное
                  пространство имён идентификаторов этого модуля.";
             }
             enum identity {
               value 1;
               description
                 "Все имена идентификаторов в модуле и его субмодулях 
                  используют некое общее пространство имен.";
             }
             enum feature {
               value 2;
               description
                 "Все имена свойств (feature) в модуле и его субмодулях
                  используют некое общее пространство имен.";
             }
             enum data {
               value 3;
               description
                 "Пространство имён всех узлов данных задано в YANG.";
             }
           }
           description
             "Пространство имён для элемента YANG в этом отображении.";
         }

         leaf identifier {
           type union {
             type yang:yang-identifier;
             type schema-node-path;
           }
           description
             "Строковый идентификатор элемента YANG в этой записи. Если
              соответствующее поле namespace имеет значение module,
              feature, или identity, это поде ДОЛЖНО содержать
              действительный идентификатор YANG. Если поле namespace
              имеет значение data, поле ДОЛЖНО содержать действительный
              путь к узлу схемы YANG.";
         }

         leaf sid {
           type sid;
           mandatory true;
           description
             "Значение YANG SID, выделенное элементу YANG.";
         }
       }
     }
   }
   <CODE ENDS>

Рисунок . Модуль YANG ietf-sid-file.

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

Этот документ определяет новый тип идентификатора, применяемый для кодирования данных, моделируемых в YANG [RFC7950]. Новый идентификатор сопоставляет семантические поняти с целыми числами и при отсутствия доверия к источнику отображения могут возникать новые риски безопасности, если злоумышленник контролирует отображение.

На момент написания документа предполагалось, что файлы .sid обрабатываются разработчиками программ в среде разработки. Разработчикам рекомендуется импортировать файлы .sid только из полномочных источников. Для поддерживаемых IETF модулей YANG полномочным источником является IANA.

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

Файлы .sid указываются ссылочными идентификаторами и могут включать их, т. е. такие идентификаторы в определённых ситуациях могут автоматически организовать удалённый доступ, цель которого хотя бы частично указывается соответствующим идентификатором. Это может предоставить злоумышленникам сведения о таком доступе и даже контроль над ним, что может повлиять на приватность и безопасность. Дополнительные сведения по этим вопросам представлены в разделах 6 и 7 [DEREF-ID].

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

6.1. Регистрация пространства имён YANG

Этот документ регистрирует пространство имён XML URN в реестре IETF XML Registry в соответствии с [BCP81].

   URI:  urn:ietf:params:xml:ns:yang:ietf-sid-file
   Registrant Contact:  The IESG.
   XML:  N/A; регистрируемый URI является пространством имён XML.
   Reference:  RFC 9595

6.2. Регистрация модуля формата файла .sid

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

   Name:  ietf-sid-file
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-sid-file
   Prefix:  sid
   Reference:  RFC 9595

6.3. Новый реестр IANA YANG-SID Mega-Ranges

Реестр YANG-SID Mega-Ranges служит для записей о передаче полномочий управления блоками SID тем или иным организациям, например, органам стандартизации (Standards Development Organization или SDO) или регистраторам.

6.3.1. Структура

Каждая запись реестра должна включать:

  • начальную точку (первый SID) зарегистрированного блока SID;

  • размер зарегистрированного блока SID (следует выделять блоки по 1 миллиону SID, но в исключительных случаях можно выделять кратные миллиону блоки);

  • политика выделения SID из блока (Public, Private или то и другое);

  • компактные сведений о запросившей блок организации, включая:

    • название организации;

    • URL.

6.3.2. Правила выделения

Для добавления в этот реестр используется процедура IANA Expert Review (параграф 4.5 в RFC 8126 [BCP26]).

Организация, желающая управлять диапазоном YANG-SID (иметь запись в реестре YANG-SID Mega-Ranges), должна иметь указанные ниже возможности.

  • Способность управлять и поддерживать реестр диапазонов YANG-SID, который должен обеспечивать для всех выделенных реестром диапазонов YANG-SID:

    • начальную точку выделенного диапазона YANG-SID;

    • размер выделенного диапазона YANG-SID;

    • тип (Public или Private).

      • Публичные диапазоны должны включать, по меньшей мере, ссылку на модуль YANG и файлы .sid для этого диапазона YANG-SID (в параграфе 6.4.3 дан пример для реестра IETF YANG-SID Ranges).

      • Частные диапазоны должны иметь метку Private.

  • Политика выделения, чётко указывающая, будет ли выделенный диапазон YANG-SID частным (Private), общедоступным (Public) или тем и другим сразу.

  • Техническая возможность предоставления файлов .sid или ссылок на них с обеспечением целостности данных в этих файлах (см. раздел 5).

  • Техническая возможность обеспечить стабильную работу реестра в течение, по меньшей мере, 5 лет. Если допускается регистрация в категории Private, этот период должен быть не мнее 10 лет.

Если желателен диапазон более 1 миллиона значений, организация дожна продемонстрировать устойчивость технического подхода к использованию такого блока, отсутствие негативного влияния на удобство использования механизмов выделения SID в целом. Такие блоки SID предпочтительно размещать в пространстве не менее 4295000000 (64 бита).

6.3.2.1. Первое выделение

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

6.3.2.2. Последующее выделение

При последующем выделении диапазона организация должна продемонстрировать исчерпание выделенного ранее диапазона, что должно быть подтверждено назначенным экспертом (экспертами). Если запрос на дополнительное выделение подан не позднее 3 лет после предыдущего выделения, эксперты должны обсудить этот запрос в почтовой конференции рабочей группы CORE и достичь согласия по части выделения нового Mega-Range.

6.3.3. Исходное содержимое реестра

Таблица . Исходное содержимое реестра YANG-SID Mega-Ranges.

 

Начало

Размер

Выделение

Организация

URL

0

1 000 000

Public

IANA

<https://www.iana.org/>

 

6.4. Новый реестр IANA IETF YANG-SID Ranges

Реестр IETF YANG-SID Ranges служит для записи сведений о назначений из диапазонов SID (например, начало и размер) для модулей YANG, указанных именем.

6.4.1. Структура

Каждая запись реестра должна включать:

  • начальное значение диапазона SID;

  • размер диапазона SID;

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

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

6.4.2. Правила выделения

Первый миллион SID, выделенных IANA поделён, как показано ниже.

  1. Значения от 0 до 999 (размер 1000) выделяются по процедуре IESG Approval, заданной в параграфе 4.10 и RFC 8126 [BCP26], при этом значение 0 зарезервировано для реализаций, указывающих отсутствие SID, и не применяется в обмене.

  2. Значения от 1000 до 59999 (размер 59000) и от 100000 до 299999 (размер 200000) предназначены для модулей YANG, заданных в RFC.

    1. Процедуры IANA для добавления в реестр указаны ниже.

      1. Expert Review (параграф 4.5 в RFC 8126 [BCP26]), если файл .sid происходит из модуля YANG, заданного имеющимся RFC.

      2. RFC Required (параграф 4.7 в RFC 8126 [BCP26]) в ином случае.

    2. Эксперт должен убедиться, что модуль YANG, для которого выделяются значения, опубликован в RFC или документ находится в стадии публикации RFC (раннее выделение по запросу от руководителей рабочей группы, как указано в [BCP100]).

  3. Значения от 60000 до 99999 (размер 40000) зарезервированы для экспериментальных модулей YANG. Этот диапазон недопустимо использоваться в рабочих системах, поскольку SID из него не являются глобально уникальными и их функциональная совместимость ограничена. Для выделения значений применяется процедура IANA Experimental Use (параграф 4.2 в RFC 8126 [BCP26]).

  4. Диапазон от 300000 до 999999 (размер 700000) является резервным, как указано в разделе 6 RFC 8126 [BCP26].

Таблица . Реестр IETF YANG-SID Ranges, правила для диапазонов IETF.

 

Начало

Размер

Процедура IANA

0

1000

IESG Approval

1000

59000

RFC и Expert Review (см. п. 2)

60000

40000

Experimental Use

100000

200000

RFC и Expert Review (см. п. 2)

300000

700000

Reserved

 

Размер диапазона SID, выделяемого модулю YANG, рекомендуется делать кратным 50 и по меньшей мере на 33% больше числа имеющихся в модуле элементов YANG. Это позволит выделять новым элементам YANG идентификаторы из имеющегося запаса. Размер диапазона SID не следует делать больше 1000, но авторы модуля могут запросить больший размер при необходимости. Важно отметить, что имеющемуся модулю YANG может быть выделен дополнительный диапазон SID, если исходный диапазон исчерпан. Это ведёт лишь к некоторому снижению эффективности представления.

Если диапазон SID выделяется для имеющегося RFC по процедуре Expert Review (параграф 4.5 в RFC 8126 [BCP26]), в поле Reference для этой записи следует указывать RFC, где определён модуль YANG.

Если диапазон SID требуется до публикации RFC, поскольку реализациям нужны стабильные SID, для процедуры RFC Required может применять раннее выделение (Early Allocation, раздел 2 в RFC 7120 [BCP100]).

6.4.3. Публикация файла .sid

В процессе публикации RFC IANA связывается с назначенными экспертами (команда), отвечающими за предоставление окончательного файла .sid для каждого модуля, определённого в этом RFC. Для разработчиков типа 3 (SID-oblivious, см. параграф 2.4) команда создаёт файл .sid из каждого модуля YANG (см. ниже). Для разработчиков типа 2 (SID-aware) команда сначала получает черновой файл .sid по стабильной ссылке в одобренном проекте, для разработчиков типа 1 (SID-guiding) файл .sid берётся из одобренного черновика. Команда использует инструменты для создания окончательного файла .sid по каждому из модулей YANG, в котором все назначения SID имеют статус stable, а сам файл .sid имеет статус published. В опубликованном файле .sid недопустимы SID со статусом unstable.

Кроме случаев типа 3 (SID-oblivious) команда подаёт имеющийся черновик .sid на вход используемого инструмента (опорный файл), чтобы изменения при повторной генерации были минимальными. Для модулей YANG, являющихся новым выпуском опубликованного ранее модуля имеющийся опубликованный файл .sid должен применяться в качестве опорного для инструмента при генерации пересмотренного чернового (типы 1 и 2) или окончательного (тип 3) файла .sid.

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

Затем назначенные эксперты передают файл .sid в IANA для публикации в реестре IETF YANG-SID Modules (параграф 6.5) вместе с модулем YANG.

Недопустимо публиковать файл .sid как часть RFC. Реестр IANA является полномочным и ссылка на него включается в RFC (данный RFC является исключением из этого правила, поскольку файл .sid в нем служит для иллюстрации). Документы Internet-Draft, которым требуются SID для новых модулей, используемые в тексте документа (скажем, для примеров), должны указать это редактору RFC в тексте чернового документа. Такие RFC не могут создавать разработчики типа 3 (SID-oblivious), SID, используемые в тексте, должны быть назначены в имеющемся черновом файле .sid, а команда экспертов должна проверить согласованность назначения в окончательном файле .sid и использования идентификаторов в тексте RFC или соответствующего одобренного черновика.

6.4.4. Исходное содержимое реестра

Таблица . Реестр IETF YANG-SID Ranges, исходное выделение.

 

Начало

Размер

Имя модуля

Документ

0

1

Резерв, не является действительным SID

RFC 9595

1000

100

ietf-coreconf

RFC 9595, [CORE-COMI]

1100

50

ietf-yang-types

[RFC6991]

1150

50

ietf-inet-types

[RFC6991]

1200

50

iana-crypt-hash

[RFC7317]

1250

50

ietf-netconf-acm

[STD91]

1300

50

ietf-sid-file

RFC 9595

1500

100

ietf-interfaces

[RFC8343]

1600

100

ietf-ip

[RFC8344]

1700

100

ietf-system

[RFC7317]

1800

400

iana-if-type

[RFC7224]

 

Для выделения диапазона требуется публикация RFC с модулем YANG в соответствии с процедурой RFC Required, заданной в параграфе 4.7 RFC 8126 [BCP26]. Модуль YANG должен регистрироваться в реестре YANG Module Names по правилам, заданным в разделе 14 [RFC6020].

6.5. Новый реестр IANA IETF YANG-SID Modules

Реестр IETF YANG-SID Modules служит для записи выделения SID элементам отдельных модулей YANG.

6.5.1. Структура

Каждая запись реестра должна включать:

  • имя модуля YANG, которое должно быть представлено в столбце Name реестра YANG Module Names;

  • URI связанного файле .yang, который должен быть указан в столбце File реестра YANG Module Names;

  • URI файла .sid, определяющего выделение идентификаторов (файл .sid сохраняется агентством IANA);

  • число фактически выделенных в файле .sid идентификаторов SID.

6.5.2. Правила выделения

Выделение происходит по процедуре Expert Review (параграф 4.5 в RFC 8126 [BCP26]). Эксперты должны обеспечить выполнение указанных ниже условий.

  • Файл .sid имеет корректную структуру:

    • файл .sid должен быть корректным файлом JSON, соответствующим структуре заданного здесь модуля.

  • Файл .sid назначает индивидуальные SID только из диапазонов YANG-SID для данного модуля YANG (как указано в реестре IETF YANG-SID Ranges):

    • все SID в файле .sid должны относиться к диапазонам, выделенным данному модулю YANG в реестре IETF YANG-SID Ranges.

  • Если другой файл .sid уже содержит SID для этого модуля YANG (например, для других версий модуля), элементам YANG присваиваются SID, которые уже указаны в том файле .sid.

  • Если имеется более старая версия файла .sid, выделенные в нем SID включаются в текущий файл.

6.5.3. Рекурсивное выделение YANG SID при принятии документа

Из-за сложности смены значений SID в процессе обработки документа в IETF ожидается, для для большинства it документов будет запрашиваться выделение SID заранее (Early Allocation [BCP100]). Детали раннего выделения, включая предполагаемые сроки, следует включать в запрос на принятие документа рабочей группой. До принятия проекта документа (Internet-Draft) рабочей группой авторы могут использовать SID из диапазона для экспериментов (см. параграф 6.4.2) или иные значения, не вызывающие путаницы с другими SID (например, можно использовать диапазоны из реестров, не управляемых IANA, которые основаны на выделении YANG-SID Mega-Range).

Предполагается, что после принятия рабочей группой любые изменения файла .sid обсуждаются в списке рассылки этой группы. Особое внимание следует уделять мнениям внедряющих после Working Group Last Call, если значение SID меняет смысл. Во всех случаях файл .sid и связанные с ним SID можно изменить до публикации Internet-Draft как RFC.

Поскольку концепция SID применяется впервые, для опубликованных ранее модулей YANG значения SID не выделены. Чтобы назначение было полезным, для включённых модулей YANG также может потребоваться выделение SID в процессе, который обычно будет аналогичен процессу из параграфа 6.4.3 для типа 3 (SID-oblivious).

Эксперты, анализирующие (ранее) назначение, должны просмотреть список включённых модулей YANG и выделить для них SID.

  • Если документ опубликован как RFC, выделение SID для ссылающихся на него модулей YANG будет постоянным. Эксперт-рецензент предоставляет сгенерированный файл .sid в IANA для регистрации.

  • Если документ является необработанным Internet-Draft, принятым рабочей группой, для него применяется раннее выделение, которое требует одобрения руководителем направления IESG. Ранее выделение, требующее дополнительных назначений, будет включать в своё описание список таких выделений, который будет передаваться в списки рассылки затрагиваемых рабочих групп.

  • Модуль YANG, ссылающийся на модуль из документа, который ещё не принят рабочей группой, не может получить раннее выделение для этого документа, пока тот не будет принят рабочей группой. Как указано в разделе 3 RFC 7120 [BCP100], курирующий директор направления (AD) будет выступать в роли руководителя рабочей группы, если документ не является результатом работы группы IETF, что фактически позволяет AD обойти применение для документа этого правила.

В конце процесса IETF всем зависимостям модуля, для которого выделяются SID, также следует иметь SID. Эти назначения следует делать постоянными (не Early Allocation).

Модуль YANG с выделенными ранее SID, который меняет свои ссылки, включая модуль YANG, ещё не имеющий SID, должен повторить процедуру Early Allocation.

В [BCP100] задан срок действия Early Allocation, по истечении которого выделение теряет силу, если оно не возобновлено. В параграфе 3.3 RFC 7120 [BCP100] также сказано:

Отметим, что для случаев, когда документ представлен на рассмотрение IESG и на момент подачи срок действия Early Allocation ещё не истёк, назначения не будут считаться просроченными, пока документ рассматривается в IESG или ожидает публикации в очереди RFC Editor после одобрения IESG.

6.5.4. Исходное содержимое реестра

На момент написания этого документа в реестре ещё не было записей.

6.6. Регистрация типа носителя и формата содержимого

6.6.1. Тип носителя application/yang-sid+json

Этот документ добавляет описанный ниже тип носителя в реестр Media Types.

Таблица . Регистрация типа носителя для файлов .sid.

 

Имя

Шаблон

Документ

yang-sid+json

application/yang-sid+json

RFC 9595

 

   Type name:  application
   Subtype name:  yang-sid+json
   Required parameters:  N/A
   Optional parameters:  N/A
   Encoding considerations:  binary (UTF-8)
   Security considerations:  см. раздел 5 в RFC 9595.
   Published specification:  RFC 9595
   Applications that use this media type: Приложения, которым нужны YANG
      SID для обмена данными YANG с компактным представлением.
   Fragment identifier considerations: Синтаксис и семантика 
      идентификаторов фрагментов для application/yang-sid+json совпадают
      с заданными для application/json (на момент публикации документа
      синтаксис для application/json не был задан).
   Additional information:
      Magic number(s):  N/A
      File extension(s):  .sid
      Macintosh file type code(s):  N/A
   Person & email address to contact for further information: список 
      рассылки CORE WG (core@ietf.org) или IETF Applications and 
      Real-Time Area (art@ietf.org). 
   Intended usage:  COMMON
   Restrictions on usage:  нет
   Author/Change controller:  IETF

6.6.2. Формат содержимого CoAP

Этот документ добавляет указанный в таблице 6 формат содержимого (Content-Format) в реестр CoAP Content-Formats группы реестров Constrained RESTful Environments (CoRE) Parameters, со значением 260 из диапазона IETF Review (256 — 9999) (см. параграф 4.8 в RFC 8126 [BCP26]).

Таблица . Регистрация формата содержимого для файлов .sid.

 

Тип содержимого

Кодирование содержимого

ID

Документ

application/yang-sid+json

260

RFC 9595

 

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

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

[BCP100] Best Current Practice 100, <https://www.rfc-editor.org/info/bcp100>. At the time of writing, this BCP comprises the following: Cotton, M., «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[BCP14] Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>. At the time of writing, this BCP comprises the following:
Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[BCP81] Best Current Practice 81, <https://www.rfc-editor.org/info/bcp81>. At the time of writing, this BCP comprises the following: Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

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

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

[RFC7951] Lhotka, L., «JSON Encoding of Data Modeled with YANG», RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

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

[RFC8791] Bierman, A., Björklund, M., and K. Watsen, «YANG Data Structure Extensions», RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.

[STD68] Internet Standard 68, <https://www.rfc-editor.org/info/std68>. At the time of writing, this STD comprises the following: Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[STD90] Internet Standard 90, <https://www.rfc-editor.org/info/std90>. At the time of writing, this STD comprises the following: Bray, T., Ed., «The JavaScript Object Notation (JSON) Data Interchange Format», STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

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

[BCP215] Best Current Practice 215, <https://www.rfc-editor.org/info/bcp215>. At the time of writing, this BCP comprises the following: Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[BCP216] Best Current Practice 216, <https://www.rfc-editor.org/info/bcp216>. At the time of writing, this BCP comprises the following: Bierman, A., «Guidelines for Authors and Reviewers of Documents Containing YANG Data Models», BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.

[BCP26] Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>. At the time of writing, this BCP comprises the following: Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[CORE-COMI] Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Ed., Bierman, A., and C. Bormann, Ed., «CoAP Management Interface (CORECONF)», Work in Progress, Internet-Draft, draft-ietf-core-comi-18, 23 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-18>.

[DEREF-ID] Bormann, C. and C. Amsüss, «The ‘dereferenceable identifier’ pattern», Work in Progress, Internet-Draft, draft-bormann-t2trg-deref-id-03, 2 March 2024, <https://datatracker.ietf.org/doc/html/draft-bormann-t2trg-deref-id-03>.

[PYANG] Björklund, M., «An extensible YANG validator and converter in python», commit fc9a965, May 2024, <https://github.com/mbj4668/pyang>.

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

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

[RFC7224] Bjorklund, M., «IANA Interface Type YANG Module», RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, «Terminology for Constrained-Node Networks», RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7317] Bierman, A. and M. Bjorklund, «A YANG Data Model for System Management», RFC 7317, DOI 10.17487/RFC7317, August 2014, <https://www.rfc-editor.org/info/rfc7317>.

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

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

[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, «Handling Long Lines in Content of Internet-Drafts and RFCs», RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.

[RFC9195] Lengyel, B. and B. Claise, «A File Format for YANG Instance Data», RFC 9195, DOI 10.17487/RFC9195, February 2022, <https://www.rfc-editor.org/info/rfc9195>.

[RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, «Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)», RFC 9254, DOI 10.17487/RFC9254, July 2022, <https://www.rfc-editor.org/info/rfc9254>.

[STD91] Internet Standard 91, <https://www.rfc-editor.org/info/std91>. At the time of writing, this STD comprises the following: Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[YANG-LIBRARY] Veillette, M., Ed. and I. Petrov, Ed., «Constrained YANG Module Library», Work in Progress, Internet-Draft, draft-ietf-core-yang-library-03, 11 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-library-03>.

[yangcatalog] «YANG Catalog», <https://yangcatalog.org>.

Приложение A. Пример файла .sid

Приведённый ниже файл .sid (ietf-system@2014-08-06.sid) создан с использованием модулей YANG:

  • ietf-system@2014-08-06.yang [RFC7317];

  • ietf-yang-types@2013-07-15.yang [RFC6991];

  • ietf-inet-types@2013-07-15.yang [RFC6991];

  • ietf-netconf-acm@2018-02-14.yang [STD91];

  • iana-crypt-hash@2014-08-06.yang [RFC7317].

В соответствии с [RFC8792] длинные строки JSON разделены символом \.

   {
     "ietf-sid-file:sid-file": {
       "module-name": "ietf-system",
       "module-revision": "2014-08-06",
       "description": "Example '.sid' file",
       "dependency-revision": [
         {
           "module-name": "ietf-yang-types",
           "module-revision": "2013-07-15"
         },
         {
           "module-name": "ietf-inet-types",
           "module-revision": "2013-07-15"
         },
         {
           "module-name": "ietf-netconf-acm",
           "module-revision": "2018-02-14"
         },
         {
           "module-name": "iana-crypt-hash",
           "module-revision": "2014-08-06"
         }
       ],
       "assignment-range": [
         {
           "entry-point": "1700",
           "size": "100"
         }
       ],
       "item": [
         {
           "namespace": "module",
           "identifier": "ietf-system",
           "sid": "1700"
         },
         {
           "namespace": "identity",
           "identifier": "authentication-method",
           "sid": "1701"
         },
         {
           "namespace": "identity",
           "identifier": "local-users",
           "sid": "1702"
         },
         {
           "namespace": "identity",
           "identifier": "radius",
           "sid": "1703"
         },
         {
           "namespace": "identity",
           "identifier": "radius-authentication-type",
           "sid": "1704"
         },
         {
           "namespace": "identity",
           "identifier": "radius-chap",
           "sid": "1705"
         },
         {
           "namespace": "identity",
           "identifier": "radius-pap",
           "sid": "1706"
         },
         {
           "namespace": "feature",
           "identifier": "authentication",
           "sid": "1707"
         },
         {
           "namespace": "feature",
           "identifier": "dns-udp-tcp-port",
           "sid": "1708"
         },
         {
           "namespace": "feature",
           "identifier": "local-users",
           "sid": "1709"
         },
         {
           "namespace": "feature",
           "identifier": "ntp",
           "sid": "1710"
         },
         {
           "namespace": "feature",
           "identifier": "ntp-udp-port",
           "sid": "1711"
         },
         {
           "namespace": "feature",
           "identifier": "radius",
           "sid": "1712"
         },
         {
           "namespace": "feature",
           "identifier": "radius-authentication",
           "sid": "1713"
         },
         {
           "namespace": "feature",
           "identifier": "timezone-name",
           "sid": "1714"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:set-current-datetime",
           "sid": "1715"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:set-current-datetime/input",
           "sid": "1775"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:set-current-datetime/input/\
                                                      current-datetime",
           "sid": "1776"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system",
           "sid": "1717"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-restart",
           "sid": "1718"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-shutdown",
           "sid": "1719"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state",
           "sid": "1720"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/clock",
           "sid": "1721"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/clock/boot-datetime\
                                                                      ",
           "sid": "1722"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/clock/current-\
                                                              datetime",
           "sid": "1723"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/platform",
           "sid": "1724"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/platform/machine",
           "sid": "1725"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/platform/os-name",
           "sid": "1726"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/platform/os-release\
                                                                      ",
           "sid": "1727"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system-state/platform/os-version\
                                                                      ",
           "sid": "1728"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication",
           "sid": "1729"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user",
           "sid": "1730"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user-\
                                                  authentication-order",
           "sid": "1731"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user/\
                                                        authorized-key",
           "sid": "1732"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user/\
                                              authorized-key/algorithm",
           "sid": "1733"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user/\
                                               authorized-key/key-data",
           "sid": "1734"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user/\
                                                   authorized-key/name",
           "sid": "1735"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user/name",
           "sid": "1736"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/authentication/user/\
                                                              password",
           "sid": "1737"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/clock",
           "sid": "1738"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/clock/timezone-name",
           "sid": "1739"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/clock/timezone-utc-offset\
                                                                      ",
           "sid": "1740"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/contact",
           "sid": "1741"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver",
           "sid": "1742"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/options",
           "sid": "1743"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/options/\
                                                              attempts",
           "sid": "1744"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/options/\
                                                               timeout",
           "sid": "1745"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/search",
           "sid": "1746"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/server",
           "sid": "1747"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/server/name",
           "sid": "1748"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/server/udp-\
                                                               and-tcp",
           "sid": "1749"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/server/udp-\
                                                       and-tcp/address",
           "sid": "1750"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/dns-resolver/server/udp-\
                                                          and-tcp/port",
           "sid": "1751"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/hostname",
           "sid": "1752"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/location",
           "sid": "1753"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp",
           "sid": "1754"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/enabled",
           "sid": "1755"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server",
           "sid": "1756"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/association-\
                                                                  type",
           "sid": "1757"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/iburst",
           "sid": "1758"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/name",
           "sid": "1759"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/prefer",
           "sid": "1760"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/udp",
           "sid": "1761"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/udp/address",
           "sid": "1762"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/ntp/server/udp/port",
           "sid": "1763"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius",
           "sid": "1764"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/options",
           "sid": "1765"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/options/attempts",
           "sid": "1766"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/options/timeout",
           "sid": "1767"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server",
           "sid": "1768"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server/\
                                                   authentication-type",
           "sid": "1769"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server/name",
           "sid": "1770"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server/udp",
           "sid": "1771"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server/udp/address\
                                                                      ",
           "sid": "1772"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server/udp/\
                                                   authentication-port",
           "sid": "1773"
         },
         {
           "namespace": "data",
           "identifier": "/ietf-system:system/radius/server/udp/shared-\
                                                                secret",
           "sid": "1774"
         }
       ]
     }
   }

Рисунок . Пример файла .sid (модуль ietf-system с переносом длинных строк).

Приложение B. Автоматическая генерация SID

Назначение SID для элементов YANG следует автоматизировать. Рекомендуемый процесс приведён ниже.

  1. Инструмент извлекает элементы, заданные в конкретном модуле YANG.

  2. Элементы сортируются по алфавиту с размещением записей namespace в порядке убывания, а identifier — в порядке возрастания. Формат namespace и identifier описан в модуле YANG ietf-sid-file, заданном в разделе 4.

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

  4. Если число элементов превышает размер диапазона SID, выделенного модулю YANG, добавляется ещё один диапазон для назначения.

  5. В элементе списка dependency-revision следует отражать номера выпусков каждого импортируемого модуля YANG (на момент генерации).

При обновлении активно используемого модуля YANG имеющиеся назначения SID сохраняются, а при обновлении рабочей версии Internet-Draft, ещё не принятой сообществом, назначение SID лучше выполнять «с нуля». Если имя узла схемы меняется, а данные структурно и семантически схожи с доступными раньше по старому имени, SID для старого имени можно продолжать использовать с новым. Если меняется значение элемента, ему можно выделить новый SID, это особенно полезно для идентификации новой структуры и семантики элемента. Если тип данных YANG меняется в новом выпуске опубликованного модуля так, что в результате изменяется кодирование CBOR, реализация существенно упростится при назначении нового SID. Отметим, что такие решения обычно принимает автор модуля YANG, которому следует решить, нужно ли ручное вмешательство в процесс автоматического назначения.

При обновлении имеющегося файла .sid требуется дополнительный шаг для увеличения номера версии файла .sid. Если у прежнего файла не было номера версии, принимается значение 0 и новому файлу .sid присваивается номер версии 1. Изменения в файлах .sid можно автоматизировать с использованием приведённой выше схемы за исключением того, что в п. 3 сохраняются прежние назначения SID и обрабатываются только новые элементы YANG, которым назначаются SID. Имеющимся в файле .sid элементам не следует присваивать новые SID.

Отметим, что версия файла .sid специфична для выпуска модуля YANG т для каждого нового модуля YANG или нового выпуска имеющегося модуля начальному файлу .sid следует (1) задавать версию 0 или (2) не указывать версию.

Отметим, что элементам YANG input и output в RPC и action должны назначаться SID, даже если в них нет других элементов YANG. Причина этого заключается в том, что данный модуль может дополняться другими модулями, которым могут требоваться SID.

Приложение C. Жизненный цикл файла .sid

До назначения SID элементам модулей YANG авторы модуля должны получить диапазон SID из реестра YANG-SID Ranges. Если модуль YANG является частью IETF Internet-Draft или RFC, диапазон SID нужно получать из реестра IETF YANG-SID Ranges, как указано в параграфе 6.4. Для иных модулей YANG авторы могут получить диапазон SID из любого реестра YANG-SID Ranges.

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

C.1. Создание файла .sid

          +---------------+
    o     | Создание      |
   -+- -->| модуля YANG   |
   / \    +------+--------+
                 |
                 v
          .-------------.
         / Стандатизован.\     да
         \ модуль YANG?  /------------+
          '-----+-------'             |
                |  нет                |
                v                     v
         .-------------.      +---------------+
   +--> / Приложения с  \ да  | Регистрация   |
   |    \ ограничениями?/---->| диапазона SID |<--------+
   |     '-----+-------'      +------+--------+         |
   |           |  нет                |                  |
   |           v                     v                  |
   |    +---------------+    +---------------+          |
   +----+ Обновление    |    | Выделение     |          |
        | модуля YANG   |    | субблока SID  |<---------+
        +---------------+    +-------+-------+          |
                                     |                  |
                                     v                  |
                            +---------------+    +------+------+
                            | Генерация     |    | Переработка |
                            | файла .sid    |    | модуля YANG |
                            +-------+-------+    +-------------+
                                    |                   ^
                                    v                   |
                              .----------.  да          |
                             /   Работа   \ ------------+
                             \  продолж.? /
                              '----+-----'
                                   |  нет
                                   v
                          .-------------.
                         /  Публикация   \ нет
                         \      RFC?     /--------------+
                          '------+------'               |
                            да   |                      |
                                 v                      v
                       +---------------+        +---------------+
                       |  Регистрация  |        |   Сторонняя   |
                       |      IANA     |        |  регистрация  |
                       +-------+-------+        +-------+-------+
                               |                        |
                               +------------------------+
                               v
                             [DONE]

Рисунок . Жизненный цикл SID.

На рисунке ниже кратко представлен процесс создания модуля YANG и файла .sid для него.

C.2. Обновление файла .sid

На рисунке ниже кратко представлен процесс обновления модуля YANG и связанного с ним файла .sid.


           +--------------------+
     o     | Обновление модуля  |
    -+- -->| YANG, включённых и |
    / \    | импортируемых фалов|
           +------+-------------+
                  |
                  v
              .-------------.
             / Созданы новые \ да
             \ элементы?     /------+
              '------+------'       |
                     |  нет         v
                     |       .-------------.      +----------------+
                     |      /  Диапазон SID \ да  | Выделение      |
                     |      \  исчерпан?    /---->| дополнительного|
                     |       '------+------'      +-------+--------+
                     |              |  нет                |
                     |              +---------------------+
                     |              |
                     |              v
                     |      +---------------+
                     |      | Обновление    |
                     |      | файла .sid на |
                     |      |основе прежнего|
                     |      +-------+-------+
                     |              |
                     |              v
                     |       .-------------.      +---------------+
                     |      /  Доступен     \ да  | Регистрация   |
                     |      \  публично?    /---->| модуля YANG   |
                     |       '------+------'      +-------+-------+
                     |              | нет                 |
                     +--------------+---------------------+
                                    |
                                    v
                                  [DONE]

Рисунок . Обновление модуля YANG и файла .sid.

Приложение D. Сохранение файла .sid в файле данных экземпляра

В [RFC9195] определён формат данных экземпляра YANG (YANG instance data). Это, по сути, ведёт к инкапсуляции данных экземпляра в некую «оболочку» метаданных.

Если файл .sid нужно сохранить в файле данных экземпляра YANG, это можно сделать, встроив файл .sid как значение элемента content-data, как показано в шаблоне ниже (элементы второго уровня указаны в квадратных скобках).

   {
     "ietf-yang-instance-data:instance-data-set": {
       "name": "<module-name>@<module-revision>.sid",
       "description":  ["<description>"],
       "content-schema": {
         "module": "ietf-sid-file@2024-06-17"
       },
       "content-data": {  <замените этот объект>
         "ietf-sid-file:sid-file" : {
           "module-name": ...
         }
       }
     }
   }

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

Авторы благодарны Andy Bierman, Abhinav Somaraju, Peter van der Stok, Laurent Toutain и Randy Turner за помощь в создании этого документа и полезные комментарии в процессе рецензирования. Особая благодарность членам IESG, предоставившим очень полезные замечания в процессе обработки IESG, в частности, Benjamin Kaduk и Rob Wilton, а также Francesca Palombini (ответственный руководитель направления AD).

Участник работы

Andy Bierman
YumaWorks
685 Cochran St.
Suite #160
Simi Valley, CA 93065
United States of America
Email: andy@yumaworks.com

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

Michel Veillette (editor)
Trilliant Networks Inc.
610 Rue du Luxembourg
Granby Quebec J2J 2V2
Canada
Phone: +1-450-375-0556
Email: michel.veillette@trilliant.com
 
Alexander Pelov (editor)
IMT Atlantique
2 rue de la Châtaigneraie
35510 Cesson-Sévigné Cedex
France
Email: alexander.pelov@imt-atlantique.fr
 
Ivaylo Petrov (editor)
Google Switzerland GmbH
Brandschenkestrasse 110
CH-8002 Zurich
Switzerland
Email: ivaylopetrov@google.com
 
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
 
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3Network Configuration Protocol — протокол настройки сети.

Рубрика: RFC | Оставить комментарий

RFC 9606 DNS Resolver Information

Internet Engineering Task Force (IETF)                        T. Reddy.K
Request for Comments: 9606                                         Nokia
Category: Standards Track                                   M. Boucadair
ISSN: 2070-1721                                                   Orange
                                                               June 2024

DNS Resolver Information

Сведения о распознавателе DNS

PDF

Аннотация

Этот документ задаёт для распознавателей DNS метод публикации сведений о себе. Клиенты DNS могут использовать эти сведения для определения возможностей распознавателя DNS. Способ использования сведений клиентами DNS выходит за рамки этого документа.

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

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

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

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

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

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

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

1. Введение

Исторически сложилось так, что клиенты DNS взаимодействуют с распознавателями без необходимости знать что-либо о поддерживаемых теми функциях. Однако все больше рекурсивных распознавателей поддерживает разные функции, что может влиять на предоставляемые ими услуги DNS (сохранение приватности, фильтрация, прозрачность поведения и т. п.). Клиенты DNS могут находить и аутентифицировать распознаватели DNS с поддержкой шифрования в своей локальной сети, используя, например, протоколы обнаружения назначенных сетью распознавателей (Discovery of Network-designated Resolvers или DNR) [RFC9463] и обнаружения назначенных распознавателей (Discovery of Designated Resolvers или DDR) [RFC9462]. Однако эти клиенты DNS не могут получить от найденных рекурсивных распознавателей сведений об их возможностях для процесса выбора распознавателя. Вместо того, чтобы приспосабливаться к распознавателям, клиентам DNS нужны более надёжные механизмы определения функций, настроенных на этих распознавателях.

Данный документ задаёт механизм, позволяющий передавать клиентам DNS сведения о распознавателях DNS в процессе выбора распознавателя. Например, процедура выбора распознавателя может использовать извлечённые сведения о распознавателях для установки более высокого приоритета сохраняющим приватность распознавателям по отношению к не поддерживающим минимизацию QNAME [RFC9156].Другим примером является выбор клиентом DNS распознавателя на основе возможностей фильтрации. Например, клиент DNS может выбрать распознаватель, фильтрующий домены на основе правил безопасности с блокировкой расширенных ошибок (Blocked (15) Extended DNS Error или EDE) [RFC8914]. Как вариант, клиент может использовать правило отказа от выбора распознавателей, подменяющих отклики с использованием Forged Answer (4) EDE. Однако определение процедур и правил выбора выходит за рамки документа. Если явно не указано иное, этот документ не влияет на операции распознавателя после выбора распознавателя клиентом DNS.

Документ определяет новый тип записи о ресурсах (resource record или RR), позволяющий клиентам DNS подавать запросы к рекурсивным распознавателям. Исходные сведения, которые может захотеть предоставлять распознаватель, указаны в разделе 5. Эта информация включает свойства, влияющие на политику приватности и прозрачности распознавателя. В будущем могут регистрироваться и другие сведения, как указано в параграфе 8.2. Сведения о распознавателях не предназначены для конечного пользователя.

2. Термины

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

В документе применяются термины, определённые в [RFC9499], а также приведённые ниже термины.

Encrypted DNS — DNS с шифрованием

Схема DNS где обмен сообщениями DNS выполняется по шифрованному каналу между клиентом и сервером DNS (например, DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250]).

Encrypted DNS resolver — распознаватель DNS с шифрованием

Распознаватель DNS, поддерживающий схему DNS с шифрованием.

Reputation — репутация

Оценка, получаемая идентифицируемым участником в сообществе или Internet в целом, как указано в разделе 1 [RFC7070].

3. Извлечение сведений о распознавателе

Клиент DNS, желающий получить сведения о распознавателе, может использовать RR типа RESINFO, определённого в этом документе. Содержимое RDATA в отклике на запрос RESINFO RR QTYPE описано в разделе 5. Если распознаватель понимает RESINFO RR, в RRset должна включаться единственная запись. Клиенты DNS должны игнорировать недействительные записи. RESINFO — это свойство распознавателя, а не субъект рекурсивного распознавания.

Клиент DNS может извлекать сведения о распознавателе и помощью RESINFO RR и QNAME доменного имени, применяемого для аутентификации распознавателя DNS и названного Authentication Domain Name (ADN) в DNR [RFC9463].

Если применяется специальное имя resolver.arpa, определённое в [RFC9462], для обнаружения распознавателей DNS с шифрованием, клиент может получить сведения о распознавателе с помощью RESINFO RR и QNAME resolver.arpa. В этом случае клиенту придётся сталкиваться с риском отсутствия поддержки распознавателем типа RESINFO. Распознаватель может передать запрос выше (upstream) и тогда клиент может получить положительный отклик RESINFO от любого легитимного распознавателя DNS или от злоумышленника.

Клиент DNS должен сбрасывать (0) в запросе бит желательности рекурсии (Recursion Desired или RD). Клиент DNS должен отбрасывать отклик, если в нем сброшен (0) флаг AA, что указывает отсутствие у распознавателя DNS полномочий для данного отклика.

Если группа распознавателей имеет общий домен ADN и/или anycast-адрес, этим распознавателям следует раскрывать согласованные сведения RESINFO.

4. Формат сведений о распознавателе

Записи сведений о распознавателе имеют такой же формат, как DNS TXT. Правила для записей TXT заданы в базовой спецификации DNS (параграф 3.3.14 в [RFC1035]) и более подробно описаны в спецификации обнаружения служб на основе DNS (DNS-based Service Discovery или DNS-SD) (параграф 6.1 в [RFC6763]). Рекомендации по ограничению размера записей TXT рассмотрены в параграфе 6.1 [RFC6763].

Подобно DNS-SD, тип RESINFO RR использует пары ключ-значение для передачи сведений о распознавателе. Каждая пара кодируется с использованием правил, заданных в параграфе 6.3 [RFC6763]. Использование стандартизованного синтаксиса для типа RESINFO RR упрощает определение новых ключей. Если клиент DNS встречает в RESINFO RR неизвестный ключ, он должен игнорировать его. Для ключей RESINFO должны применяться правила параграфа 6.4 [RFC6763].

Ключи сведений о распознавателе должны быть определены в реестре IANA (параграф 8.2) или начинаться с префикса temp-, обозначающего локальное использование.

5. Ключи и значения сведений о распознавателе

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

qnamemin

Наличие этого ключа указывает поддержку распознавателем DNS минимизации QNAME [RFC9156] для повышения уровня приватности DNS. Отметим, что в соответствии с правилами параграфа 6.4 в [RFC6763] отсутствие символа = делает ключ логическим атрибутом, не имеющим значения.
Наличие ключа указывает, что распознаватель DNS настроен на минимизацию влияющих на приватность данных, передаваемых полномочному серверу имён.
Этот атрибут является необязательным.

exterr

Если распознаватель DNS поддерживает опцию EDE, определённую в [RFC8914], для возврата дополнительных сведений о причинах ошибок DNS, значение этого ключа содержит коды EDE, которые может возвращать этот распознаватель DNS. Это может быть один или несколько кодов EDE. Диапазоны значений должны указываться через дефис (-), набор несмежных значений должен указываться через запятые.
Возвращаемые коды EDE (например, Blocked (15), Censored (16), Filtered (17)) показывают, настроен ли распознаватель DNS на раскрытие причин, по которым запрос был отфильтрован/заблокирован при возникновении соответствующего события. Если возможности распознавателя обновляются для включения новых похожих кодов, он может прервать сессию TLS, предлагая клиенту организовать новое соединение TLS и снова извлечь сведения о распознавателе. Это позволяет клиенту иметь актуальные сведения о возможностях распознавателя. При получении клиентом для запроса DNS кода EDE, не указанного в exterr, клиент может снова запросить распознаватель о его возможностях в части возврата новых кодов ошибок. Если несоответствие сохраняется, клиент может счесть сведения о распознавателе недостоверными и отбросить их.
Этот атрибут является необязательным.

infourl

Ссылка URL, указывающая базовые неструктурированные сведения о распознавателе (например, поддерживаемые DoH API, возможные коды статуса HTTP, возвращаемые сервером DoH, способы оповещения о проблемах) для поиска неполадок. Сервер, раскрывающий такие сведения, называется сервером сведений о распознавателе (resolver information server). Такой сервер должен поддерживать для сведений о распознавателе только тип содержимого text/html. Клиент DNS должен отвергать, как недействительные, URL с отличной от https схемой. Недействительные URL должны игнорироваться. Полученные по URL сведение должны рассматриваться лишь как диагностическая информация для персонала IT. Они не предназначены для конечных пользователей, поскольку могут вводить их в заблуждение.
Этот ключ может применяться персоналом IT для получения иных полезных сведений о распознавателе, а также для процедур информирования о проблемах (например, некорректная фильтрация).
Этот атрибут является необязательным.

Новые ключи могут создаваться по процедуре, указанной в параграфе 8.2.

6. Пример

На рисунке 1 представлен пример записи со сведениями о распознавателе.

     resolver.example.net. 7200 IN RESINFO qnamemin exterr=15-17
                           infourl=https://resolver.example.com/guide

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


Как отмечено в разделе 3, клиент DNS, обнаруживший ADN resolver.example.net своего распознавателя с использованием DNR, будет передавать запрос RESINFO RR QTYPE для ADN и узнает, что:

  • распознаватель поддерживает минимизацию QNAME;

  • распознаватель может возвращать коды Blocked (15), Censored (16), Filtered (17);

  • дополнительную информацию можно получить по ссылке https://resolver.example.com/guide.

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

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

  1. Организация аутентифицированного защищённого соединения с распознавателем DNS.

  2. Реализация локальной проверки DNSSEC (раздел 10 в [RFC9499]) для контроля подлинности сведений о распознавателе.

Важно отметить, что для запросов resolver.arpa подходит лишь первый вариант.

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

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

8.1. Тип RESINFO RR

Агентство IANA обновило реестр Resource Record (RR) TYPEs в рамках группы реестров Domain Name System (DNS) Parameters [RRTYPE], как показано ниже.

   Type:  RESINFO
   Value:  261
   Meaning:  Resolver Information as Key/Value Pairs
   Reference:  RFC 9606

8.2. Регистрация ключей DNS Resolver Information

Агентство IANA создало новый реестр DNS Resolver Information Keys в рамках группы реестров Domain Name System (DNS) Parameters [IANA-DNS]. Этот реестр содержит определения ключей, которые могут применяться для предоставления сведений о распознавателях. Ключи добавляются в реестр по процедуре Specification Required (параграф 4.6 в [RFC8126]). Назначенным экспертам следует тщательно рассматривать влияние на безопасность в результате добавления ключа в этот реестр. Дополнительные подробности приведены в параграфе 8.3. Структура реестра приведена ниже.

Name

Имя ключа, которое должно соответствовать определению из раздела 4. В реестр IANA недопустимо включать имена с префиксом temp-, поскольку такие имена могут свободно применяться в любой реализации.

Description

Описание зарегистрированного ключа.

Reference

Указание документа со спецификацией зарегистрированного элемента.

Исходное содержимое реестра представлено в таблице 1.

Таблица . Исходное содержимое реестра DNS Resolver Information Keys.

Имя

Описание

Документ

qnamemin

Наличие этого ключа указывает поддержку минимизации QNAME.

RFC 9606

exterr

Список поддерживаемых кодов расширенных ошибок DNS. Это должны быть десятичные значения INFO-CODE из реестра Extended DNS Error Codes <https://www.iana.org/assignments/dns-parameters/>.

RFC 9606

infourl

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

RFC 9606

8.3. Рекомендации для назначенных экспертов

Предполагается назначать несколько экспертов для рассмотрения запросов на включение в реестр.

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

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

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

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

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

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

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

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

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

[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, «Extended DNS Errors», RFC 8914, DOI 10.17487/RFC8914, October 2020, <https://www.rfc-editor.org/info/rfc8914>.

[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, «DNS Query Name Minimisation to Improve Privacy», RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/info/rfc9156>.

[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, «Discovery of Designated Resolvers», RFC 9462, DOI 10.17487/RFC9462, November 2023, <https://www.rfc-editor.org/info/rfc9462>.

[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, «DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)», RFC 9463, DOI 10.17487/RFC9463, November 2023, <https://www.rfc-editor.org/info/rfc9463>.

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

[IANA-DNS] IANA, «Domain Name System (DNS) Parameters», <https://www.iana.org/assignments/dns-parameters/>.

[RESINFO] Sood, P. and P. Hoffman, «DNS Resolver Information Self-publication», Work in Progress, Internet-Draft, draft-pp-add-resinfo-02, 27 June 2020, <https://datatracker.ietf.org/doc/html/draft-pp-add-resinfo-02>.

[RFC7070] Borenstein, N. and M. Kucherawy, «An Architecture for Reputation Reporting», RFC 7070, DOI 10.17487/RFC7070, November 2013, <https://www.rfc-editor.org/info/rfc7070>.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, «Specification for DNS over Transport Layer Security (TLS)», RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC8484] Hoffman, P. and P. McManus, «DNS Queries over HTTPS (DoH)», RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, «DNS over Dedicated QUIC Connections», RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.

[RFC9499] Hoffman, P. and K. Fujiwara, «DNS Terminology», BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/info/rfc9499>.

[RRTYPE] IANA, «Resource Record (RR) TYPEs», <https://www.iana.org/assignments/dns-parameters/>.

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

В этой спецификации используется документ [RESINFO].

Спасибо Tommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben Schwartz, Tony Finch, Daniel Kahn Gillmor, Eric Rescorla, Shashank Jain, Florian Obser, Richard Baldry, Martin Thomson за обсуждения и комментарии.

Спасибо Mark Andrews, Joe Abley, Paul Wouters, Tim Wicinski за обсуждение правил форматирования RR.

Отдельная благодарность Tommy Jensen за тщательную вдумчивую рецензию Shepherd.

Спасибо Johan Stenstam и Jim Reid за рецензию dns-dir, Ray Bellis за рецензию выделения RRTYPE, Arnt Gulbrandsen за рецензию ART и Mallory Knodel за рецензию gen-art.

Спасибо Éric Vyncke за рецензию AD.

Спасибо Gunter Van de Velde, Erik Kline, Paul Wouters, Orie Steele, Warren Kumari, Roman Danyliw, Murray Kucherawy за рецензию IESG.

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

Tirumaleswar Reddy.K
Nokia
India
Email: kondtir@gmail.com
 
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9608 No Revocation Available for X.509 Public Key Certificates

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 9608                                Vigil Security
Updates: 5280                                                   T. Okubo
Category: Standards Track                                       DigiCert
ISSN: 2070-1721                                                J. Mandel
                                                            AKAYLA, Inc.
                                                               June 2024

No Revocation Available for X.509 Public Key Certificates

Расширение для указания недоступности отзыва сертификатов открытых ключей X.509

PDF

Аннотация

Сертификаты открытых ключей X.509v3 описаны в RFC 5280. В Internet всё шире применяются краткосрочные сертфикаты и удостоверяющие центры (Certification Authority или CA), выпускающие такие сертификаты не публикуют сведений об отзыве, поскольку сроки действия сертификатов меньше времени, требуемого на обнаружение и распространение сведений об отзыве. У некоторых долгосрочных сертификатов открытых ключей X.509v3 срок действия не ограничен и они тоже не отзываются. Данная спецификация определяет расширение сертификата noRevAvail, чтобы полагающаяся на сертификат сторона могла легко определить, что CA не публикует сведений об отзыве и обновить алгоритм проверки пути сертификации, заданный в RFC 5280, чтобы пропускать проверку отзыва при наличии в сертификате расширения noRevAvail.

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

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

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

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

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

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

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

1. Введение

Краткосрочные сертификаты открытых ключей X.509v3 [RFC5280] все шире применяются в Internet. Например, среда автоматического управления сертификатами (Automatic Certificate Management Environment или ACME) [RFC8555] обеспечивает простой способ получения краткосрочных сертификатов. Во многих случаях удостоверяющие центры (CA) не предоставляют сведений об отзыве краткосрочных сертификатов. Это обусловлено тем, что срок их действия меньше времени, требуемого для обнаружения и распространения сведений об отзыве. В результате отзыв краткосрочных сертификатов, служащих для проверки подлинности или управления ключами, становится ненужным и бессмысленным. С другой стороны, отзыв сертификатов, связанных с долгосрочными подписями (например, для документов или программного кода), позволяет получить важные сведения о моментах обнаружения компрометации.

Некоторые сертификаты открытых ключей X.509v3 имеют неограниченный срок действия и никогда не отзываются. Например, фабрика может включать сертификат IDevID [IEEE802.1AR] для привязки назначенного устройству идентификатора к устаноленному при производстве открытому ключу. Идентификатор может включать модель и серийный номер устройства, которые никогда не меняются. Для указания того, что для сертификата не задан срок действия, в поле notAfter периода действия сертификата устанавливается значение 99991231235959Z [RFC5280].

Данная спецификация задаёт расширение сертификата noRevAvail, позволяющее доверяющей стороне легко понять, что CA не публикует сведений об отзыве сертификата конечного субъекта, и обновляет алгоритм проверки пути сертификации [RFC5280], чтобы проверка отзыва не выполнялась при наличии в сертификате расширения noRevAvail.

Отметим, что расширение сертификата noRevAvail обеспечивает функциональность, похожую на расширение ocsp-nocheck [RFC6960]. Последнее подходит лишь для включения в сертификаты, выпущенные для респондентов протокола Online-статуса сертификатов (Online Certificate Status Protocol или OCSP), тогда как расширение noRevAvail можно применять в любом сертификате конечного субъекта, для которого CA не публикует сведений об отзыве. Чтобы не нарушать экосистему OCSP, разработчикам не следует считать расширение noRevAvail заменой ocsp-nocheck и оно может включаться в сертификаты для ответчиков OCSP, как дополнение к ocsp-nocheck.

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

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

1.2. ASN.1

Сертификаты X.509 создаются с помощью ASN.1 [X.680] по базовым (Basic Encoding Rules или BER) и отличительным (Distinguished Encoding Rules или DER) правилам кодирования [X.690].

1.3. История

В 1988 г. сертификат X.509v1 был определён CCITT [X.509-1988].

В 1997 г. сертификат X.509v3 и сертификат атрибута был определён ITU-T [X.509-1997].

В 1999 г. IETF впервые было предложено использовать сертификаты X.509v3 в Internet [RFC2459].

В 2000 г. определено (ITU-T) расширение noRevAvail для использования сертификатами атрибутов [X.509-2000].

В 2002 г. впервые задан профиль сертификата атрибута (IETF) для использования в Internet [RFC3281] и этот профиль включал поддержку расширения noRevAvail.

В 2019 г., опубликовано обновление ITU-T Recommendation X.509 [X.509-2019].

В связи с расширяющимся применением в Internet краткосрочных сертификатов недавнее техническое исправление (Technical Corrigendum) для ITU-T Recommendation X.509 [X.509-2019-TC2] позволяет применять расширение noRevAvail для сертификатов открытых ключей и атрибутов.

2. Расширение сертификата noRevAvail

Расширение noRevAvail, заданное в [X.509-2019-TC2], позволяет CA указать недоступность сведений об отзывае для этого сертификата.

Это расширение недопустимо включать в сертификаты открытых ключей CA.

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

   name           id-ce-noRevAvail
   OID            { id-ce 56 }
   syntax         NULL (i.e. '0500'H is the DER encoding)
   criticality    MUST be FALSE

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

3. Другие расширения сертификатов X.509

В сертификаты CA недопустимо включать расширение noRevAvail. В сертификаты с noRevAvail недопустимо включать расширения, указывающие репозитории CRL или местоположение ответчиков OCSP. При наличии noRevAvail в сертификате:

  • недопустимо включать в него расширение с cA BOOLEAN = TRUE (см. параграф 4.2.1.9 в [RFC5280]);

  • недопустимо включать в него расширение CRL Distribution Points (см. параграф 4.2.1.13 в [RFC5280]);

  • недопустимо включать в него расширение Freshest CRL (см. параграф 4.2.1.15 в [RFC5280]);

  • при наличии расширения Authority Information Access недопустимо включать в него id-ad-ocsp accessMethod (см. параграф 4.2.2.1 в [RFC5280]).

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

4. Проверка пути сертификации

В параграфе 6.1.3 [RFC5280] описана обработка сертификата в рамках процедур проверки пути сертификации. В частности, в п. (a)(3) сказано:

В настоящий момент сертификат не отозван. Это можно определить из соответствующего CRL (параграф 6.3), сведений о состоянии или автономных (out-of-band) механизмов.

При наличии заданного здесь расширения noRevAvail или расширения ocsp-nocheck [RFC6960] п. (a)(3) пропускается, а ином случае выполняется определение статуса отзыва сертификата.

5. Модуль ASN.1

В этом разделе представлен модуль ASN.1 [X.680] для расширения сертификата noRevAvail с использованием соглашений [RFC5912] и [RFC6268].

   <CODE BEGINS>
     NoRevAvailExtn
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-noRevAvail(110) }

     DEFINITIONS IMPLICIT TAGS ::=
     BEGIN

     IMPORTS
       EXTENSION
       FROM PKIX-CommonTypes-2009  -- RFC 5912
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-pkixCommon-02(57) } ;

     -- Расширение сертификата noRevAvail

     ext-noRevAvail EXTENSION ::= {
       SYNTAX NULL
       IDENTIFIED BY id-ce-noRevAvail
       CRITICALITY { FALSE } }

     -- noRevAvail Certificate Extension OID

     id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

     id-ce-noRevAvail OBJECT IDENTIFIER ::= { id-ce 56 }

     END
   <CODE ENDS>

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

К этом документу применим одноимённый раздел [RFC5280].

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

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

Отсутствие сведений об отзыве ограничивает возможности принимающей сертификат стороны в плане обнаружения компрометации ключевого материала конечного субъекта или вредоносных сертификатов. Это также ограничивает возможности обнаружения CA, не обеспечивающих практику безопасности, правила выпуска сертификатов и контроль операций, заданные в политике сертификата (Certificate Policy или CP) или заявлении о практике сертификации (Certification Practices Statement или CPS) [RFC3647].

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

6.1. Краткосрочные сертификаты

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

6.2. Долгосрочные сертификаты

Для некоторых долгосрочных сертификатов сведения об отзыва не предоставляются, поскольку срок действия сертификата никогда не заканчивается. Например, сертификаты IDevID [IEEE802.1AR] включаются в устройства при производстве и служат для получения сертификатов LDevID [IEEE802.1AR] в рабочей среде. В этом случае необходимо выбирать криптографические алгоритмы, которые считаются безопасными в течение предполагаемого срока использования устройств. Если применяется расширение noRevAvail, у CA не будет возможности уведомить доверяющие стороны о компрометации установленного при производстве ключевого материала.

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

Агентство IANA выделило приведённый в таблице 1 идентификатор объекта (OID) для модуля ASN.1 (раздел 5) в реестре SMI Security for PKIX Module Identifier (1.3.6.1.5.5.7.0).

Таблица .

 

Десятичное значение

Описание

110

id-mod-noRevAvail

 

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

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

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

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

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

[X.509-2019-TC2] ITU-T, «Information Technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks — Technical Corrigendum 2», ITU-T Recommendation X.509-2019/Cor.2-2023, October 2023, <https://www.itu.int/rec/T-REC-X.509-202310-I!Cor2>.

[X.680] ITU-T, «Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation», ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.680>.

[X.690] ITU-T, «Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)», ITU-T Recommendation X.690, ISO/IEC 8825-1-2021, February 2021, <https://www.itu.int/rec/T-REC-X.690>.

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

[IEEE802.1AR] IEEE, «IEEE Standard for Local and Metropolitan Area Networks — Secure Device Identity», IEEE 802.1AR-2018, DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, <https://ieeexplore.ieee.org/document/8423794>.

[RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and CRL Profile», RFC 2459, DOI 10.17487/RFC2459, January 1999, <https://www.rfc-editor.org/info/rfc2459>.

[RFC3281] Farrell, S. and R. Housley, «An Internet Attribute Certificate Profile for Authorization», RFC 3281, DOI 10.17487/RFC3281, April 2002, <https://www.rfc-editor.org/info/rfc3281>.

[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, «Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework», RFC 3647, DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc3647>.

[RFC5912] Hoffman, P. and J. Schaad, «New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)», RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.

[RFC6268] Schaad, J. and S. Turner, «Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)», RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.

[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP», RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.

[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, «Automatic Certificate Management Environment (ACME)», RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.

[X.509-1988] CCITT, «The Directory — Authentication Framework», CCITT Recommendation X.509-1988, November 1988, <https://www.itu.int/rec/T-REC-X.509-198811-S>.

[X.509-1997] ITU-T, «Information technology — Open Systems Interconnection — The Directory: Authentication framework», ITU-T Recommendation X.509-1997, August 1997, <https://www.itu.int/rec/T-REC-X.509-199708-S>.

[X.509-2000] ITU-T, «Information Technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks», ITU-T Recommendation X.509-2000, March 2000, <https://www.itu.int/rec/T-REC-X.509-200003-S>.

[X.509-2019] ITU-T, «Information Technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks», ITU-T Recommendation X.509-2019, October 2019, <https://www.itu.int/rec/T-REC-X.509-201910-I>.

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

Большое спасибо Erik Anderson за его усилия по созданию расширения сертификатов noRevAvail для использования с сертификатами открытых ключей конечных субъектов и сертификатами атрибутов.

Большое спасибо Corey Bonnell, Hendrik Brockhaus, Tim Hollebeek, Mike Ounsworth, Seo Suchan, Carl Wallace, Éric Vyncke, Paul Wouters (указаны в алфавитном порядке) за рецензиии и полезные комментарии.

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

Russ Housley
Vigil Security, LLC
Herndon, Virginia
United States of America
Email: housley@vigilsec.com
 
Tomofumi Okubo
DigiCert, Inc.
Fairfax, Virginia
United States of America
Email: tomofumi.okubo+ietf@gmail.com
 
Joseph Mandel
AKAYLA, Inc.
Tacoma, Washington
United States of America
Email: joe@akayla.com

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9583 Application Scenarios for the Quantum Internet

Internet Research Task Force (IRTF)                              C. Wang
Request for Comments: 9583              InterDigital Communications, LLC
Category: Informational                                        A. Rahman
ISSN: 2070-1721                                                 Ericsson
                                                                   R. Li
                                                     Kanazawa University
                                                              M. Aelmans
                                                        Juniper Networks
                                                          K. Chakraborty
                                             The University of Edinburgh
                                                               June 2024

Application Scenarios for the Quantum Internet

Сценарии применения Quantum Internet

PDF

Аннотация

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

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

Документ не относится к категории Internet Standards Track и публикуется для информации.

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы QIRG в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (https://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение

Классическая (не квантовая) сеть Internet постоянно растёт с момента, когда она стала коммерчески доступной в начале 1990-х годов. По сути, сеть состоит из большого числа конечных узлов (например, ноутбуков, смартфонов, серверов), соединённых маршрутизаторами и объединённых в автономные системы (Autonomous System или AS). На конечных узлах могут работать приложения, предоставляющие конечным пользователям такие услуги, как передача голоса, видео или данных. Соединения между узлами Internet включают магистральные каналы (например, оптические), линии доступа (например, оптически, Wi-Fi, сотовые сети, DSL2). Биты передаются через Classical Internet в пакетах.

В последние несколько лет активизировались исследования и эксперименты по разработке квантовых сетей (Quantum Internet) [Wehner]. Конечные узлы также будут частью Quantum Internet и в этом случае их называют квантовыми конечными узлами (quantum end node). Эти узлы могут соединяться квантовыми повторителями и маршрутизаторами. На конечных квантовых узлах будут работать добавляющие услуги (value-added) приложения, которые будут рассмотрены ниже.

Квантовые каналы физического уровня между узлами Quantum Internet могут быть волноводами (например, оптическими волокнами) или открытым пространством. Особенно полезны фотонные каналы, поскольку свет (фотоны) очень хорошо подходит для физической реализации кубитов. Quantum Internet будет работать в соответствии с принципами квантовой физики, такими как суперпозиция и запутанность [RFC9340].

Предполагается, что Quantum Internet не заменит, а усовершенствует Classical Internet и/или обеспечит прорывные приложения. Например, квантовое распространение ключей может повысить уровень безопасности Classical Internet, а квантовые вычисления — ускорить и оптимизировать задачи с большим объёмом расчётов. Quantum Internet будет работать в связке с Classical Internet, а процессы интеграции будут похожи на процесс внедрения новых коммуникационных и сетевых парадигм в существующую сеть Internet, но с более серьёзными последствиями.

Назначение этого документа состоит в обеспечении базового понимания и моделей применения Quantum Internet. Отмечается, что в ITU-T SG13-TD158/WP3 [ITUT] кратко описаны 4 вида использования квантовых сетей в дополнение к квантовому распространению ключей. Это квантовая синхронизация часов, квантовые вычисления, квантовые генераторы случайных чисел и квантовые коммуникации (например, квантовые цифровые подписи, квантовая анонимная передача, квантовые деньги). Этот документ сосредоточен на квантовых приложениях, оказывающих важное влияние на работу сетей, таких как организация защищённых коммуникаций, квантовые вычисления вслепую и распределенные квантовые вычисления. Хотя такие приложения упомянуты в [ITUT], этот документ указывает больше деталей и задаёт некоторые требования с точки зрения сети.

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

2. Термины и сокращения

В этом документе предполагается знакомство читателя с концепциями и терминами квантовой теории информации, представленными в [RFC9340]. Кроме того, ниже даны определения некоторых терминов и сокращений.

Bell Pairs — пары Белла

Особый тип квантового состояния двух кубитов. Такие два кубита демонстрируют корреляцию, которую невозможно встретить в классической теории информации. Такую корреляцию называют квантовой запутанностью. Пары Белла демонстрируют максимальную квантовую запутанность. Одним из примеров пары Белла является (|00>+|11>)/(Sqrt(2)). Пары Белла являются фундаментальным ресурсом квантовых коммуникаций.

Bit — бит

Двоичная цифра (фундаментальная единица информации в классических коммуникациях и вычислениях). Биты применяются в Classical Internet, где состояние бита детерминировано. В Quantum Internet состояние кубита является неопределённым до его измерения.

Classical Internet

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

Entanglement Swapping — обмен запутанностью

Процесс обобщения (sharing) запутанности между двумя удалёнными одна от другой сторонами через некие промежуточные узлы. Предположим, например, что имеется три стороны (A, B, C) и каждая из сторон имеет общие пары Белла — (A, B) и (B, C). B может использовать кубиты, общие с A и C, для выполнения операций обмена запутанностью и в результате A и C будут иметь одщие пары Белла. Обмен запутанностью, по сути, реализует распространение (распределение) запутанности, где два разнесённых территориально узла могут иметь общую пару Белла.

Fast Byzantine Negotiation — быстрые византийские переговоры (согласование)

Квантовый метод быстрого согласования в Византийских переговорах3 [Ben-Or] [Taherkhani].

Local Operations and Classical Communication (LOCC) — локальные операции и классические коммуникации

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

Noisy Intermediate-Scale Quantum (NISQ) — зашумлённые квантовые системы промежуточного уровня

Определение NISQ было дано в [Preskill] для представления ближайшей эры квантовой технологии. Согласно этому определению, компьютеры NISQ имеют две важных особенности: (1) размер компьютеров NISQ варьируется от 50 до нескольких сотен физических кубитов (промежуточный уровень) и (2) кубиты в компьютерах NISQ имеют врожденные ошибки и контроль над ними несовершенен (шум).

Packet — пакет

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

Prepare and Measure — подготовка и измерение

Набор сценариев Quantum Internet, в которых квантовые узлы поддерживают лишь простые квантовые функции (подготовка и измерение кубитов). Например, BB84 [BB84] — это протокол квантового распределения ключей с подготовкой и измерением.

Quantum Computer (QC) — квантовый компьютер

Квантовый конечный узел, имеющий квантовую память и возможности квантовых вычислений, считается полноценным квантовым компьютером.

Quantum End Node — квантовый конечный узел

Конечный узел, на котором размещаются приложения и интерфейсы с остальной частью Internet. Обычно конечный узел может служить клиентом, сервером или узлом одноранговой сети в зависимости от приложения. Квантовый конечный узел должен также быть способным взаимодействовать с Classical Internet для целей управления, т. е. принимать, обрабатывать и передавать классические биты и/или пакеты.

Quantum Internet

Сеть квантовых сетей. Предполагается слияние Quantum Internet с Classical Internet. Quantum Internet может улучшить классические приложения и создать новые квантовые приложения.

Quantum Key Distribution (QKD) — квантовое распространение ключей

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

Quantum Network — квантовая сеть

Новый тип сети, создаваемый на основе квантовой теории информации, где квантовые ресурсы, такие как кубиты и запутанность, используются и передаются между квантовыми узлами. Квантовая сеть будет использовать квантовые каналы и классические каналы Classical Internet. Это называется гибридной реализацией.

Quantum Teleportation — квантовая телепортация

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

Qubit — кубит

Квантовый бит (фундаментальная единица информации в квантовых коммуникациях и вычислениях). Кубит похож на классический бит в том, что имеет после измерения состояние 0 или 1, обозначаемые как |0> и |1> в нотации Дирака. Однако кубит отличается от классического бита тем, что он до измерения может быть линейной комбинацией обоих состояний, которую называют суперпозицией. Для кодирования кубита может применяться любая из нескольких степеней свободы (Degrees of Freedom или DOF) фотона (например, поляризация, time-bin, частота) или электрона (например, спин).

Teleport a Qubit — телепортация кубита

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

Transfer a Qubit — перенос кубита

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

Transmit a Qubit — передача кубита

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

3. Применение Quantum Internet

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

Приложения можно группировать по решаемым задачам (услугам). В частности, можно выделить указанные ниже категории.

Quantum cryptography applications — квантовая криптография

Использование квантовой теории информации для задач криптографии (например, квантового распространения ключей [Renner]).

Quantum sensor applications — квантовые датчики

Использование квантовой теории информации для поддержки распределенных датчиков (например, синхронизации часов [Jozsa2000] [Komar] [Guo]).

Quantum computing applications — квантовые вычисления

Использование квантовой теории информации для поддержки удалённых квантовых вычислительных комплексов (например, распределённые квантовые вычисления [Denchev]).

Эта схема будет понятна технической и нетехнической аудитории. Ниже схема рассматривается более подробно.

3.1. Квантовая криптография

Примеры квантовой криптографии включают организацию защищённой квантовой связи и быстрое византийское согласование.

Secure communication setup — организация защищённых коммуникаций

Защищённое распространение криптографических ключей между двумя (или более) конечными узлами. Наиболее известный метод называется квантовым распространением ключей (QKD) [Renner].

Fast Byzantine negotiation — быстрое византийское согласование

Квантовый мотод быстрого согласования в византийских переговорах [Ben-Or], например, для сокращения числа ожидаемых раундов связи и ускоренного соглашения в классических византийских переговорах. Квантовое византийское соглашение в сетях квантовых повторителей, предложенное в [Taherkhani], включает методы оптимизации, позволяющие значительно сократить глубину квантовой схемы (устройства) и число кубитов на каждом узле. Квантовые методы бытрого согласования в византийских переговорах можно применять для улучшения протколов согласия (consensus), таких как pBFT4, а также иных функций распределенного вычисления, использующих византийское согласование.

Quantum money — квантовые деньги

Основным требованием к деньгам является невозможность их подделки. Схема квантовых денег нацелена на использованием свойства невозможности клонирования неизвестных квантовых состояний. Хотя идея квантовых денег возникла ещё в 1970 г., ранние протоколы позволяли проверить подлинность квантовых денег лишь банку-эмитенту. Недавние протоколы, такие как квантовые деньги с открытым ключом [Zhandry] позволяют любому локально проверить подлинность денег.

3.2. Квантовые датчики и метрология

Запутанность, суперпозиция, интерференция и сжатие свойств могут повышать чувствительность квантовых датчиков и в конечном счёте превзойти классические варианты. Примерами применения квантовых датчиков являются синхронизация часов, высокочувствительные датчики и т. п. Эти приложения в основном используют сеть запутанных квантовых датчиков (т. е. сеть квантовых датчиков) для высокоточных измерений множества параметров [Proctor].

Network clock synchronization — синхронизация часов

Общемировой набор часов, подключённых к Quantum Internet для обеспечения сверхточных сигналов часов [Komar] с ограничениями точности, определяемыми квантовой теорией.

High-sensitivity sensing — датчики с высокой чувствительностью

Приложения, использующие квантовые явления для достижения надёжного наноразмерного измерения физических величин. Например, в [Guo] применяется запутанная квантовая сеть для измерения среднего сдвига фазы между множеством распределенных узлов.

Interferometric telescopes using quantum information — интерферометрические телескомы

Интерферометрические методы, применяемые для объединения сигналов от двух и более телескопов с целью получения изображений с более высоким разрешением, нежели может обеспечить отдельный телескоп. Это позволяет исследовать очень мелкие астрономические объекты, если телескопы распределены по большой площади. Однако флуктуации фазы и потери фотонов в каналах связи между телескопами вносят ограничения на размер базы оптических интерферометров. Потенциально это ограничение можно обойти с помощью квантовой телепортации. В общем случае обобщение пар Эйнштейна-Подольского-Розена с использованием квантовых повторителей позволяет оптическим интерферометрам обмениваться фотонами на больших расстояниях, обеспечивая базу произвольного размера [Gottesman2012].

3.3. Квантовые вычисления

В этом параграфе рассматриваются приложения для квантовых вычислений. Предполагается, что квантовые компьютеры в будущем станут доступными как облачные услуги. Иногда для запуска таких приложений в облаке с сохранением приватности клиенту и серверу потребуется обмен кубитами (например, для расчётов вслепую [Fitzsimons], как описано ниже. Поэтому для сохранения приватности в приложениях квантовых вычислений потребуется Quantum Internet.

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

Distributed quantum computing — распределенные квантовые вычисления

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

Blind quantum computing — квантовые вычисления вслепую

Квантовые расчёты с сохранением приватности, обеспечивающие клиентам возможность передачи вычислительных задач одному или нескольким удалённым квантовым компьютерам без раскрытия источника данных для расчётов [Fitzsimons].

4. Некоторые приложения Quantum Internet

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

4.1. Организация защищённых коммуникаций

В этом сценарии двум узлам (например, квантовым узлам A и B) требуется организовать защищённую связь для передачи конфиденциальных сведений (см. рисунок 1). Для этого им сначала нужно защищённым способом организовать общий классический секретный криптографический ключ (последовательность классических битов). Процесс запускает конечный пользователь с защищённым локальным интерфейсом к квантовому узлу A. В результате квантовый узел A защищённо организует классический секретный ключ с квантовым узлом B. Это называется организацией защищённой связи. Отметим, что квантовые узлы A и B могут быть простыми (bare-bone) квантовыми узлами или полноценными квантовыми компьютерами. Это приложение показывает, что Quantum Internet можно использовать для повышения защищенности приложений Classical Internet.

Одним из требований к такому процессу организации защищённой связи является неуязвимость к классическим и квантовым вычислительным атакам. Этого можно добиться с помощью квантового распространения ключей (QKD), которое в принципе не поддаётся взлому. QKD может защищённо организовать секретный ключ между парой квантовых узлов, используя классический канал проверки подлинности и незащищённый квантовый канал без физической передачи ключа через сеть, что обеспечивает требуемую защиту. Однако необходимо позаботиться о защите системы QKD от атак по побочным физическим каналам, которые могут скомпрометировать систему. Примером атаки по побочному физическому каналу является скрытое введение дополнительного света в оптические устройства, применяемые QKD, чтобы получить сведения о системе, такие как поляризация. Другие специализированные атаки на QKD используют классический канал аутентификации и незащищённый квантовый канал. К таким атакам относятся переотображение фазы (phase-remapping), расщепление числа фотонов, ложное состояние [Zhao2018]. QKD можно применять для разных криптографических коммуникаций, таких как IPsec и защита транспортного уровня (Transport Layer Security или TLS), где участвующие стороны должны организовать общий ключ защиты, хотя это обычно влечёт высокую задержку.

QKD является наиболее развитым свойством квантовой информационной технологии и такое распространение ключей уже реализовано коммерчески в небольших системах и на коротких расстояниях. Варианты применения QKD описаны в документе ETSI [ETSI-QKD-UseCases], а интерфейс между пользователями и устройствами QKD задан в [ETSI-QKD-Interfaces].

В общем случае протоколы QKD с подготовкой и измерением (например, [BB84]) без использования запутанности работают, как описано ниже.

  1. Квантовый узел A кодирует классические биты в кубиты. Узел A генерирует две строки случайных классических битов X и Y. Строка X служит для выбора базы, Y — для выбора состояния, соответствующего выбранной базе. Например, при X=0 в случае использования протокола BB84 Алиса готовит состояние в базе {|0>, |1>}, иначе — в базе {|+>, |->}. При Y=0 Алиса готовит кубит как |0> или |+> (в зависимости от X), а при Y =1 — как |1> или |->.

  2. Квантовый узел A передаёт кубиты квантовому узлу B по квантовому каналу.

  3. Квантовый узел B принимает кубиты и измеряет каждый из них в одной из двух баз, выбранной случайно.

  4. Квантовый узел B информирует квантовый узел A о своём выборе базы для каждого кубита.

  5. Квантовый узел A сообщает квантовому узлу B, какие из случайно выбранных баз были верны.

  6. Оба узла отбрасывают все биты измерений с отличающейся квантовой базой, а оставшиеся биты могут служить секретным ключом. Перед генерацией финального секретного ключа выполняется процедура пост-обработки через аутентифицированные классические каналы. Эта процедура может делиться на 3 этапа — оценка параметров, исправление ошибок и повышение приватности. На этапе оценки параметров Алиса и Боб используют некоторые из битов для оценки канальных ошибок. Если число ошибок превышает некий порог, протокол прерывается, иначе выполняется корректировка ошибок. Если подслушивающий попытается перехватить и прочитать кубиты, переданные от A к B, он будет обнаружен в соответствии с теоремой квантовой механики об энтропийной неопределённости. Как часть процедуры пост-обработки оба узла обычно выполняют сверку (reconciliation) информации [Elkouss] для эффективного исправления ошибок и/или проводят усиление приватности [Tang] для генерации окончательных ключей на основе теории информации.

  7. Процедура пост-обработки должна выполняться по аутентифицированному классическому каналу. Иными словами, квантовым узлам A и B нужно убедиться в подлинности классического канала, чтобы быть уверенными в отсутствии на пути подслушивающих или атакующих. Проверка выполняется по протоколам аутентификации, иаким как [Kiktenko]. В соответствии с [Kiktenko] подлинность классического канала проверяется в самом конце процедуры пост-обработки вместо того, чтобы делать это для каждого классического сообщения передаваемого по каналу между квантовыми узлами A и B.

Следует отметить ряд обстоятельств, указанных ниже.

  1. Имеются усовершенствованные протоколы QKD, основанные на [BB84]. Например, был обнаружен ряд брешей, связанных с несовершенством измерительных устройств, и имеются решения, учитывающие такие атаки, например, независимое от измерительных устройств решение QKD [Zheng2019]. Эти улучшенные протоколы QKD могут работать иначе, нежели описанные этапы протокола BB84 [BB84].

  2. Для крупномасштабных QKD, требуются сети QKD (QKD Network или QKDN), которые можно считать частью Quantum Internet. QKDN может включать прикладной, сетевой и канальный уровень QKD [Qin]. Между квантовыми узлами A и B может находиться один или несколько ретрансляторов QKD [Zhang2018], соединённых через QKDN. Как вариант, QKDN может работать на основе распространения запутанности и основанных на запутанности протоколов QKD. В результате для крупномасштабных QKD будут требоваться квантовые повторители и/или маршрутизаторы вместо доверенных ретрансляторов QKD. Для распределения запутанности может применяться обмен запутанностью.

  3. QKD обеспечивает основанные на теории информации общие секретные ключи для двух сторон (передатчик и приёмник) при наличии подслушивания. Однако это верно в теории, которая в значительной мере оторвана от практики. Используя несовершенство детекторов, Ева может получить сведения об общем ключе [Xu]. Для предотвращения таких атак через побочные каналы в [Lo] исследователи предложили протокол QKD, названный независимым от измерительных устройств (Measurement Device-Independent или MDI) QKD, где два пользователя (передатчик Алиса и приёмник Боб) могут безопасно взаимодействовать даже если используемое ими (измерительное) оборудование подменено (захвачено) злоумышленником и перестало быть доверенным. Это достигается путём измерения корреляция между сигналами от Алисы и Боба вместо измерения самих сигналов.

  4. Протоколы QKD, основанные на QKD с непрерывной переменной (Continuous Variable QKD или CV-QKD), вызывают в последнее время большой интерес, поскольку для их реализации достаточно легко доступного и широко распространённого телекоммуникационного оборудования. Этот тип технологии потенциально обеспечит высокопроизводительный метод защищённого распространения ключей на ограниченных расстояниях. Недавние демонстрации CV-QKD показали совместимость с классическими схемами когерентного детектирования, которые широко применяются в классических широкополосных системах связи [Grosshans]. Отметим, что до сих пор нет квантовых повторителей для систем с непрерывными переменными, поэтому этот тип QKD пригоден лишь для коротких расстояний или сетей QKD с доверенными ретрансляторами.

  5. Распространение секретов может применяться для распределения секретного ключа между множеством узлов, позволяя каждому узлу знать долю или часть секретного ключа, но не предоставляя всего ключа ни одному из узлов. Секретный ключ можно восстановить лишь при совместной работе достаточного числа узлов. Квантовым обменом секретами (Quantum Secret Sharing или QSS) обычно называют сценарий, где секретный ключ обобществляется на основе квантовых состояний, а не классических битов. QSS позволяет разделять (splitting) и обобществлять (sharing) такие квантовые состояния между множеством узлов.

  6. Имеются основанные на запутанности протоколы QKD, такие как описано в [Treiber], [E91] и [BBM92], которые работают не так, как описано в предыдущих этапах. Основанные на запутанности схемы, где состояния запутанности подготавливаются вне квантовых узлов A и B, обычно не считают подготовкой и измерением, описанными в [Wehner]. Другие схемы на основе запутанности, где запутанность создаётся внутри квантового узла-источника и служит для вывода ключей, могут считаться подготовкой и измерением. Схемы с передачей и возвратом (Send-and-return) могут считаться подготовкой и измерением, если информационное содержимое, из которого выводятся ключи, подготавливаются в квантовом узле A перед их отправкой квантовому узлу B для измерения.

Quantum Internet на рисунке 1 включает квантовые каналы. Для организации защищённой связи, особенно в больших системах, требуется также генерация и распространение запутанности [QUANTUM-CONNECTION], квантовые повторители и/или маршрутизаторы, доверенные ретрансляторы QKD.

+---------------------+
|Конечный пользователь|
+---------------------+
      ^
      | Локальный защищённый интерфейс
      | (например, то же физическое оборудование
      | или локальная защищённая сеть)
      V
+-----------------+     /--------\     +-----------------+
|                 |--->( Quantum  )--->|                 |
|                 |    ( Internet )    |                 |
|                 |     \--------/     |                 |
|Квантовый узел A |                    |Квантовый узел B |
|                 |     /--------\     |                 |
|                 |    ( Classical)    |                 |
|                 |<-->( Internet )<-->|                 |
+-----------------+     \--------/     +-----------------+

Рисунок . Организация защищённой связи.


4.2. Квантовые расчёты вслепую

Квантовыми расчётами вслепую называют описанный ниже сценарий.

  1. Клиентский узел с исходными данными передаёт вычисления удалённому расчётному узлу (серверу).

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

  3. Нет каких-либо допущений или гарантий о доверии к удалённому расчётному узлу в части приватности исходных данных.

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

Как новая вычислительная модель клиент-сервер, квантовые расчёты вслепую (Blind Quantum Computation или BQC) в целом позволяет выполнить представленный ниже процесс.

  1. Клиент делегирует вычислительную функцию серверу.

  2. Клиент не передаёт исходные кубиты серверу, но передаёт тому преобразованные кубиты.

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

  4. Клиент получает кубиты промежуточных результатов и преобразует их в кубиты окончательных результатов.

В этом процессе сервер не может восстановить исходные кубиты из преобразованных. Прямое и обратное (для результатов) преобразование кубитов не требует от клиента значительных усилий. Один из первых протоколов BQC (например, описанный в [Childs]) следует этому процессу, но у клиента требуется наличие некоторого объёма квантовой памяти, подготовка и измерение кубитов, а также их передача. Основанные на измерениях квантовые вычисления выходят за рамки этого документа, а более подробные сведения приведены в [Jozsa2005].

Следует отметить ряд обстоятельств, указанных ниже.

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

  2. Universal BQC (UBQC) из [Broadbent] — это основанная на измерениях модель BQC, где выполняются квантовые измерения с использованием запутанных состояний. Принцип UBQC основан на том, что квантовая трансформация плюс измерение Белла с поворотом (базы) реализуют квантовые вычисления, которые могут повторяться для реализации расчётной цепочки. В этом случае клиент сначала готовит преобразованные кубиты, затем передаёт их серверу, а тому нужно сначала подготовить запутанные состояния из всех принятых кубитов. Далее между клиентом и сервером выполняется множество раундов взаимодействия и измерения:

    1. клиент передаёт серверу новые инструкции по измерению или его адаптации;

    2. сервер выполняет измерения в соответствии с полученными инструкциями для получения результатов (в кубитах или классических битах);

    3. клиент получает результаты измерения и преобразует их в окончательные результаты.

  3. В [Zhang2009] предложен гибридный вариант UBQC, где сервер реализует квантовые устройства (схемы), подобно показанным в [Childs], и квантовые измерения, похожие на показанные в [Broadbent], для снижения числа требуемых запутанных состояний [Broadbent]. Клиент в этом случае много проще, нежели в [Childs]. Этот гибридный вариант BQC является сочетанием моделей BQC на основе схемы и измерений.

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

  5. Проверка соответствия выполненного сервером запросам и ожиданиям клиента важна для многих протоколов BQC, называемых верифицируемыми. В [Fitzsimons] обсуждается этот вопрос и сравниваются протоколы BQC.

На рисунке 2 Quantum Internet включает квантовые каналы и квантовые повторители и/или квантовые маршрутизаторы для передачи кубитов на большие расстояния [RFC9340].

+----------------+     /--------\     +-------------------+
|                |--->( Quantum  )--->|                   |
|  Терминальный  |    ( Internet )    | Удалённый узел    |
|  узел          |     \--------/     | квантовых расчётов|
|  (например     |                    | (например,        |
|  небольшой     |     /--------\     | удалённый         |
|  квантовый     |    ( Classical)    | квантовый         |
|  компьютер     |<-->( Internet )<-->| мэйнфрейм)        |
+----------------+     \--------/     +-------------------+

Рисунок . Квантовые расчёты вслепую.


4.3. Распределённые квантовые расчёты

Существует два способа распределенных квантовых расчётов [Denchev].

  1. Использование квантовой механики для улучшений классических распределенных расчётов. Например, можно использовать запутанные квантовые состояния для улучшения выбора лидера в классических распределенных расчётах путём простого измерения запутанных квантовых состояний на каждой стороне (например, на узле или устройстве) без каких-либо классических коммуникаций между разнесёнными сторонами [Pal]. Обычно сначала нужно организовать между сторонами предварительную запутанность, а затем выполнить операции LOCC на каждой стороне. При этом обычно не нужно передавать кубиты между сторонами.

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

    1. Запутанные состояния можно создавать заранее и хранить или буферизовать.

    2. Скорость создания запутанности будет ограничивать производительность практических приложений Quantum Internet, включая распределенные квантовые расчёты, хотя запутанные состояния можно буферизовать.

    Например, в [Gottesman1999] и [Eisert] показано, что управляемые инверторы (Controlled NOT или CNOT) можно реализовать совместно на нескольких квантовых компьютерах и распределить между ними. Далее в этом параграфе рассматривается в основном этот тип распределенных квантовых вычислений.

В качестве варианта распределенных квантовых вычислений второго типа можно рассматривать зашумлённые квантовые компьютеры среднего масштаба (NISQ), размещённые в разных местах, доступных для обобществления. В соответствии с определением [Preskill] компьютер NISQ может реализовать лишь небольшое число кубитов и имеет ограниченные возможности корректировки квантовых ошибок. Этот вариант называют распределёнными квантовыми расчётами [Caleffi] [Cacciapuoti2020] [Cacciapuoti2019]. Он отражает значительный рост вычислительной мощности, которые квантовые компьютеры могут обеспечить в составе Quantum Internet по сравнению с классическими компьютерами Classical Internet в контексте экосистемы распределенных квантовых вычислений [Cuomo]. Согласно [Cuomo], квантовая телепортация позволяет применять новую парадигму связи, называемую «теледанными» (teledata) [VanMeter2006-01], где квантовые состояния переносятся между кубитами разнесённых квантовых компьютеров. Для распределенных квантовых расчётов требуется возможность удалённо выполнять квантовые вычисления на кубитах распределённых квантовых компьютеров, например, методом «телевентилей» (telegate) [VanMeter2006-02].

Например, пользователь может применить соединённые компьютеры NISQ для выполнения сложных научных расчётов, таких как анализ химических взаимодействий для разработки медицинских препаратов [Cao] (см. рисунок 3). В этом случае кубиты передаются между квантовыми компьютерами по квантовым каналам, а запросы пользователя для координации и управления — по классическим. Другим примером являются многосторонние защищённые квантовые расчёты (Multi-Party Quantum Computation или MPQC) [Crepeau], которые можно считать квантовым вариантом классических многосторонних защищённых расчётов (Multi-Party Computation или MPC). В защищённом протоколе MPQC множество участников совместно выполняют квантовые расчёты с набором входных квантовых состояний, подготавливаемых и предоставляемых разными участниками. Одной из целей защищённого MPQC является гарантия того, что ни один из участников не будет знать квантовых состояний, предоставленных другими. Защищённые расчёты MPQC полагаются на верифицированный квантовый обмен секретами [Lipinska].

В примере на рисунке 3 нужно перенести кубиты с одного компьютера NISQ на другой. Для этого можно применить квантовую телепортацию для переноса с квантового компьютера (A) на квантовый компьютер (B). Отметим, что на рисунке 3 не рассматриваются распределенный квантовый расчёт на основе измерений, где телепортация может не требоваться. При реализации квантовой телепортации между узлами A и B выполняются указанные ниже действия. Фактически на обоих компьютерах выполняются операции LOCC [Chitambar] для выполнения квантовой телепортации.

  1. Квантовый компьютер A генерирует некие кубиты конфиденциальных данных для телепортирования в B.

  2. Организуется общая запутанность A и B (т. е. имеется два запутанных кубита — q1 на A и q2 на B). Например, квантовый компьютер A может создать два запутанных кубита (q1 и q2) и передать q2 квантовому компьютеру B, используя квантовую связь.

  3. Компьютер A выполняет измерение Белла для запутанного кубита q1 и кубита конфиденциальных данных.

  4. Результат измерения Белла кодируется в 2 классических бита, которые передаются по классическому каналу квантовому компьютеру B.

  5. На основе полученных 2 классических битов компьютер B меняет состояние запутанного кубита q2, чтобы создать кубит, идентичный кубиту конфиденциальных данных в компьютере A.

На рисунке Quantum Internet включает квантовые каналы и квантовые повторители и/или маршрутизаторы [RFC9340]. Этот вариант приложения должен поддерживать создание и распространение запутанности (или квантовое соединение) [QUANTUM-CONNECTION] для выполнения квантовой телепортации.

                +---------------------+
                |Конечный пользователь|
                +---------------------+
                           ^
                           | Локальный защищённый интерфейс
                           | (например, то же физическое оборудование
                           |  или локальная защищённая сеть)
                           V
        +------------------+-------------------+
        |                                      |
        |                                      |
        V                                      V
+----------------+     /--------\     +----------------+
|                |--->( Quantum  )--->|                |
|                |    ( Internet )    |                |
|   Квантовый    |     \--------/     |   Квантовый    |
|   компьютер A  |                    |   компьютер B  |
|  (например,    |     /--------\     |  (например,    |
|   сайт 1)      |    ( Classical)    |   сайт 2)      |
|                |<-->( Internet )<-->|                |
+----------------+     \--------/     +----------------+

Рисунок . Распределённые квантовые вычисления.


5. Общие требования

Квантовые технологии постоянно развиваются и совершенствуются, поэтому сложно предсказать сроки и этапы будущего квантовых технологий, как отмечено в [Grumbling]. В настоящее время компьютер NISQ может поддерживать от 50 до нескольких сотен кубитов с определённой долей ошибок.

В работе [Wehner] описаны 6 этапов развития Quantum Internet на сетевом уровне.

  1. Сети доверенных повторителей (Этап 1).

  2. Сети с подготовкой и измерением (Этап 2).

  3. Сети распределения запутанности (Этап 3).

  4. Сети квантовой памяти (Этап 4).

  5. Устойчивые к отказам сети из нескольких кубитов (Этап 5).

  6. Сети квантовых вычислений (Этап 6).

Первый этап — это простые сети доверенных повторителей, а на последнем возникают сети квантовых вычислений, образующие Quantum Internet. Каждый промежуточный этап добавляет функции, приложения и характеристики. В таблице 1 показаны сценарии применения Quantum Internet, описанные в разделах 3 и 4, с отображением на этапы Quantum Internet из [Wehner]. Например, организация защищённой связи может поддерживаться на этапе 1, 2 или 3, но с применением разных решений QKD.

  • На этапе 1 возможны базовые решения QKD для поддержки организации защищённой связи, но для сквозной защиты нужны доверенные узлы. Их наличие является основным требованием.

  • На этапе 2 конечные пользователи могут подготавливать и измерять кубиты. Доступна проверка классических паролей без их раскрытия.

  • На этапе 3 может обеспечиваться сквозная защита на основе квантовых повторителей и распределения запутанности для поддержки одного и того же приложения организации защищённой связи. Основным требованием является распространение запутанности для использования QKD на длинных дистанциях.

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

  • На этапе 5 квантовые повторители смогут исправлять ошибки, что позволит выполнять отказоустойчивые квантовые расчёты по полученным данным. Эти повторители позволят выполнять распределенные квантовые расчёты и приложения с квантовыми датчиками на небольшом числе кубитов.

  • На этапе 6 станут возможны распределенные между большим числом кубитов квантовые расчёты.

Таблица . Примеры приложений на разных этапах Quantum Internet.

 

Этап

Примеры приложений Quantum Internet

Характеристики

1

Организация защищённой связи с базовыми QKD

Доверенные узлы

2

Организация сквозной защиты связи с применением QKD

Подготовка и измерение

3

Организация защищённой связи с применением QKD с запутанностью

Распространение запутанности

4

Квантовые вычисления вслепую

Квантовая память

5

Высокоточная синхронизация часов

Отказоустойчивость

6

Распределенные квантовые вычисления

Множество кубитов

 

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

5.1. Операции на запутанных кубитах

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

5.2. Распределение запутанности

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

5.3. Необходимость классических каналов

Квантовые конечные узлы должны передавать дополнительную информацию по классическим каналам, чтобы помочь в передаче и распознании кубитов через квантовые повторители и/или маршрутизаторы. Примеры такой дополнительной информации включают измерения кубитов при организации защищённой связи (параграф 4.1) и измерения Белла в распределенных квантовых вычислениях (параграф 4.3). Кроме того, кубиты передаются индивидуально и с ними не связано заголовков пакетов, которые могли бы помочь при передаче. Любые сведения, способствующие маршрутизации, идентификации кубитов и т. п., должны передаваться по классическим каналам.

5.4. Управление Quantum Internet

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

6. Заключение

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

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

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

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

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

Этот документ не задаёт архитектуру или конкретные протоколы для Quantum Internet и посвящён лишь вариантам применения, требованиям и описанию типичных приложений Quantum Internet. Тем не менее можно сделать несколько важных замечаний в части безопасности Quantum Internet.

В [NISTIR8240] отмечено, что реализация крупномасштабных квантовых вычислений позволит взломать множество систем с открытым ключом (асимметричных), используемых сегодня. Это связано с ростом вычислительных возможностей квантовых компьютеров для некоторых классов задач (например, факторизации и оптимизации простых чисел). Это негативно повлияет на многие механизмы защиты, применяемые в Classical Internet и основанные на шифровании с открытым ключом (Diffie-Hellman (DH)). Это стало мощным стимулом для разработки новых криптографических систем, устойчивых в атакам с использованием квантовых вычислений [NISTIR8240]. Развитие Quantum смягчит угрозы, вносимые атаками на криптосистемы на основе открытых ключей DH. В частности, организация защищённых коммуникаций Quantum (параграф 4.1) будет устойчива к квантовым и классическим атакам на криптосистемы с открытыми ключами Diffie-Hellman.

В [RFC7258] рассмотрена важная для Quantum Internet угроза и отмечена опасность внедрения повсеместного мониторинга как широкой атаки на приватность. Повсеместный мониторинг определён как широко распространённое и обычно скрытое наблюдение путём сбора содержимого приложений или метаданных протокола, таких как заголовки. Это может быть реализовано путём пассивного или активного прослушивания, анализа трафика или подмены криптографических ключей, применяемых для защиты коммуникаций.

Организация защищённой связи в Quantum Internet (параграф 4.1) устойчива к повсеместному мониторингу, основанному на прямых атаках на ключи шифрования (Diffie-Hellman). Кроме того, в параграфе 4.2 описан метод распределенных квантовых расчётов с сохранением приватности исходных данных. Присущее кубитам свойство распада при наблюдении (даже скрытном) теоретически позволит обнаружить нежелательное наблюдение в некоторых будущих решениях.

Современные сети основаны на принципах отсутствия доверия (zero trust), где классическая криптография служит для защиты конфиденциальности и целостности, а также для аутентификации на разных логических уровнях сетевого стека, зачастую на всем пути от устройства до программ в облаке [NISTSP800-207]. Используемые сегодня криптографические решения основаны на хорошо известных примитивах, заведомо безопасных протоколах и современных реализациях, защищённых от множества атак через побочные каналы.

В отличие от традиционной и постквантовой криптографии (Post-Quantum Cryptography или PQC), защита QKD неотъемлемо связана с физическим уровнем, что делает фронты атаки на QKD и традиционную криптографию совершенно разными. Реализации QKD уже подвергались известным атакам [Zhao2008] и Агентство национальной безопасности (National Security Agency или NSA) США отмечает, что профиль рисков традиционной криптографии известен лучше [NSA]. Реализация традиционной криптографии и PQC на более высоких уровнях, чем физический, означает, что PQC можно использовать для передачи защищённой информации через недоверенные ретрансляторы. Это контрастирует с QKD, где основой является сквозная защита путём передачи через доверенные промежуточные узлы. PQC лучше подходит для современных технологий, где все больше приложение переходит к принципам сквозной защиты и отсутствия доверия. Важно отметить, что PQC можно внедрить путём обновления программ, а для QKD требуется новое оборудование. В IETF имеется рабочая группа по использованию постквантовой криптографии в протоколах (Post-Quantum Use In Protocols или PQUIP), изучающая вопросы перехода на PQC.

В плане реализации QKD АНБ (NSA) утверждает, что в QKD требования к защите и связи имеют физические противоречия, а инженерные решения для их балансировки крайне неустойчивы к ошибкам. Традиционная криптография может быть реализована аппаратно для повышения производительности или по иным причинам, а QKD по своей природе является аппаратным решением. АНБ отмечает, что это делает подход QKD менее гибким в части обновления или защитных исправлений. Поскольку QKD является протоколом «точка-точка» (point-to-point), АНБ также отмечает, что сети QKD часто требуют использования доверенных ретрансляторов, что повышает риск, связанный с внутренними угрозами.

Национальный центр кибербезопасности Великобритании (UK National Cyber Security Centre) предостерегает от применения QKD, особенно в критически важных секторах национальной инфраструктуры, и предлагает использовать криптографию PQC, стандартизованную NIST, как лучшее решение [NCSC]. Национальное агентство кибербезопасности Франции (National Cybersecurity Agency of France) считает возможным применять QKD в качестве средства глубокой защиты, дополняющего традиционную криптографию, если связанные с этим затраты не окажут негативного влияния на защиту от текущих угроз инфраструктуре систем IT [ANNSI].

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

[ANNSI] French Cybersecurity Agency (ANSSI), «Should Quantum Key Distribution be Used for Secure Communications?», May 2020, <https://www.ssi.gouv.fr/en/publication/should-quantum-key-distribution-be-used-for-secure-communications/>.

[BB84] Bennett, C. H. and G. Brassard, «Quantum cryptography: Public key distribution and coin tossing», DOI 10.1016/j.tcs.2014.05.025, December 2014, <https://doi.org/10.1016/j.tcs.2014.05.025>.

[BBM92] Bennett, C. H., Brassard, G., and N. D. Mermin, «Quantum cryptography without Bell’s theorem», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.68.557, February 1992, <https://link.aps.org/doi/10.1103/PhysRevLett.68.557>.

[Ben-Or] Ben-Or, M. and A. Hassidim, «Fast quantum byzantine agreement», STOC ’05, Association for Computing Machinery, DOI 10.1145/1060590.1060662, May 2005, <https://dl.acm.org/doi/10.1145/1060590.1060662>.

[Broadbent] Broadbent, A., Fitzsimons, J., and E. Kashefi, «Universal Blind Quantum Computation», 50th Annual IEEE Symposium on Foundations of Computer Science, IEEE, DOI 10.1109/FOCS.2009.36, December 2009, <https://arxiv.org/pdf/0807.4154.pdf>.

[Cacciapuoti2019] Cacciapuoti, A. S., Caleffi, M., Van Meter, R., and L. Hanzo, «When Entanglement meets Classical Communications: Quantum Teleportation for the Quantum Internet (Invited Paper)», DOI 10.48550/arXiv.1907.06197, July 2019, <https://arxiv.org/abs/1907.06197>.

[Cacciapuoti2020] Cacciapuoti, A. S., Caleffi, M., Tafuri, F., Cataliotti, F. S., Gherardini, S., and G. Bianchi, «Quantum Internet: Networking Challenges in Distributed Quantum Computing», IEEE Network, DOI 10.1109/MNET.001.1900092, February 2020, <https://ieeexplore.ieee.org/document/8910635>.

[Caleffi] Caleffi, M., Cacciapuoti, A. S., and G. Bianchi, «Quantum internet: from communication to distributed computing!», NANOCOM ’18, Association for Computing Machinery, DOI 10.1145/3233188.3233224, September 2018, <https://dl.acm.org/doi/10.1145/3233188.3233224>.

[Cao] Cao, Y., Romero, J., and A. Aspuru-Guzik, «Potential of quantum computing for drug discovery», IBM Journal of Research and Development, DOI 10.1147/JRD.2018.2888987, December 2018, <https://doi.org/10.1147/JRD.2018.2888987>.

[Castelvecchi] Castelvecchi, D., «The quantum internet has arrived (and it hasn’t)», Nature 554, 289-292, DOI 10.1038/d41586-018-01835-3, February 2018, <https://www.nature.com/articles/d41586-018-01835-3>.

[Childs] Childs, A. M., «Secure assisted quantum computation», DOI 10.26421/QIC5.6, July 2005, <https://arxiv.org/pdf/quant-ph/0111046.pdf>.

[Chitambar] Chitambar, E., Leung, D., Mančinska, L., Ozols, M., and A. Winter, «Everything You Always Wanted to Know About LOCC (But Were Afraid to Ask)», Communications in Mathematical Physics, Springer, DOI 10.1007/s00220-014-1953-9, March 2014, <https://link.springer.com/article/10.1007/s00220-014-1953-9>.

[Crepeau] Crépeau, C., Gottesman, D., and A. Smith, «Secure multi-party quantum computation», STOC ’02, Association for Computing Machinery, DOI 10.1145/509907.510000, May 2002, <https://doi.org/10.1145/509907.510000>.

[Cuomo] Cuomo, D., Caleffi, M., and A. S. Cacciapuoti, «Towards a distributed quantum computing ecosystem», IET Quantum Communication, DOI 10.1049/iet-qtc.2020.0002, July 2020, <http://dx.doi.org/10.1049/iet-qtc.2020.0002>.

[Denchev] Denchev, V. S. and G. Pandurangan, «Distributed quantum computing: a new frontier in distributed systems or science fiction?», ACM SIGACT News, DOI 10.1145/1412700.1412718, September 2008, <https://doi.org/10.1145/1412700.1412718>.

[E91] Ekert, A. K., «Quantum cryptography based on Bell’s theorem», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.67.661, August 1991, <https://link.aps.org/doi/10.1103/PhysRevLett.67.661>.

[Eisert] Eisert, J., Jacobs, K., Papadopoulos, P., and M. B. Plenio, «Optimal local implementation of nonlocal quantum gates», Physical Review A, American Physical Society, DOI 10.1103/PhysRevA.62.052317, October 2000, <https://doi.org/10.1103/PhysRevA.62.052317>.

[Elkouss] Elkouss, D., Martinez-Mateo, J., and V. Martin, «Information Reconciliation for Quantum Key Distribution», DOI 10.48550/arXiv.1007.1616, April 2011, <https://arxiv.org/pdf/1007.1616.pdf>.

[ETSI-QKD-Interfaces] ETSI, «Quantum Key Distribution (QKD); Components and Internal Interfaces», V2.1.1, ETSI GR QKD 003, March 2018, <https://www.etsi.org/deliver/etsi_gr/QKD/001_099/003/02.01.01_60/gr_QKD003v020101p.pdf>.

[ETSI-QKD-UseCases] ETSI, «Quantum Key Distribution; Use Cases», V1.1.1, ETSI GS QKD 002, June 2010, <https://www.etsi.org/deliver/etsi_gs/qkd/001_099/002/01.01.01_60/gs_qkd002v010101p.pdf>.

[Fitzsimons] Fitzsimons, J. F., «Private quantum computation: an introduction to blind quantum computing and related protocols», DOI 10.1038/s41534-017-0025-3, June 2017, <https://www.nature.com/articles/s41534-017-0025-3.pdf>.

[Gottesman1999] Gottesman, D. and I. Chuang, «Demonstrating the viability of universal quantum computation using teleportation and single-qubit operations», Nature 402, 390-393, DOI 10.1038/46503, November 1999, <https://doi.org/10.1038/46503>.

[Gottesman2012] Gottesman, D., Jennewein, T., and S. Croke, «Longer-Baseline Telescopes Using Quantum Repeaters», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.109.070503, August 2012, <https://link.aps.org/doi/10.1103/PhysRevLett.109.070503>.

[Grosshans] Grosshans, F. and P. Grangier, «Continuous Variable Quantum Cryptography Using Coherent States», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.88.057902, January 2002, <https://doi.org/10.1103/PhysRevLett.88.057902>.

[Grumbling] Grumbling, E., Ed. and M. Horowitz, Ed., «Quantum Computing: Progress and Prospects», National Academies of Sciences, Engineering, and Medicine, The National Academies Press, DOI 10.17226/25196, 2019, <https://doi.org/10.17226/25196>.

[Guo] Guo, X., Breum, C. R., Borregaard, J., Izumi, S., Larsen, M. V., Gehring, T., Christandl, M., Neergaard-Nielsen, J. S., and U. L. Andersen, «Distributed quantum sensing in a continuous-variable entangled network», Nature Physics, DOI 10.1038/s41567-019-0743-x, December 20219, <https://www.nature.com/articles/s41567-019-0743-x>.

[Huang] Huang, H-L., Zhao, Q., Ma, X., Liu, C., Su, Z-E., Wang, X-L., Li, L., Liu, N-L., Sanders, B. C., Lu, C-Y., and J-W. Pan, «Experimental Blind Quantum Computing for a Classical Client», DOI 10.48550/arXiv.1707.00400, July 2017, <https://arxiv.org/pdf/1707.00400.pdf>.

[ITUT] ITU-T, «Draft new Technical Report ITU-T TR.QN-UC: ‘Use cases of quantum networks beyond QKDN'», ITU-T SG 13, November 2022, <https://www.itu.int/md/T22-SG13-221125-TD-WP3-0158/en>.

[Jozsa2000] Josza, R., Abrams, D. S., Dowling, J. P., and C. P. Williams, «Quantum Clock Synchronization Based on Shared Prior Entanglement», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.85.2010, August 2000, <https://link.aps.org/doi/10.1103/PhysRevLett.85.2010>.

[Jozsa2005] Josza, R., «An introduction to measurement based quantum computation», DOI 10.48550/arXiv.quant-ph/0508124, September 2005, <https://arxiv.org/pdf/quant-ph/0508124.pdf>.

[Kiktenko] Kiktenko, E. O., Malyshev, A. O., Gavreev, M. A., Bozhedarov, A. A., Pozhar, N. O., Anufriev, M. N., and A. K. Fedorov, «Lightweight authentication for quantum key distribution», DOI 10.1109/TIT.2020.2989459, September 2020, <https://arxiv.org/pdf/1903.10237.pdf>.

[Komar] Kómár, P., Kessler, E. M., Bishof, M., Jiang, L., Sørensen, A. S., Ye, J., and M. D. Lukin, «A quantum network of clocks», DOI 10.1038/nphys3000, October 2013, <https://arxiv.org/pdf/1310.6045.pdf>.

[Lipinska] Lipinska, V., Murta, G., Ribeiro, J., and S. Wehner, «Verifiable hybrid secret sharing with few qubits», Physical Review A, American Physical Society, DOI 10.1103/PhysRevA.101.032332, March 2020, <https://doi.org/10.1103/PhysRevA.101.032332>.

[Lo] Lo, H-K., Curty, M., and B. Qi, «Measurement-Device-Independent Quantum Key Distribution», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.108.130503, March 2012, <https://doi.org/10.1103/PhysRevLett.108.130503>.

[NCSC] National Cyber Security Centre (NCSC), «Quantum security technologies», Whitepaper, March 2020, <https://www.ncsc.gov.uk/whitepaper/quantum-security-technologies>.

[NISTIR8240] Alagic, G., Alperin-Sheriff, J., Apon, D., Cooper, D., Dang, Q., Liu, Y-K., Miller, C., Moody, D., Peralta, R., Perlner, R., Robinson, A., and D. Smith-Tone, «Status Report on the First Round of the NIST Post-Quantum Cryptography Standardization Process», DOI 10.6028/NIST.IR.8240, NISTIR 8240, January 2019, <https://nvlpubs.nist.gov/nistpubs/ir/2019/NIST.IR.8240.pdf>.

[NISTSP800-207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, «Zero Trust Architecture», NIST SP 800-207, DOI 10.6028/NIST.SP.800-207, August 2020, <https://doi.org/10.6028/NIST.SP.800-207>.

[NSA] National Security Agency (NSA), «Post-Quantum Cybersecurity Resources», <https://www.nsa.gov/Cybersecurity/Post-Quantum-Cybersecurity-Resources/>.

[Pal] Pal, S. P., Singh, S. K., and S. Kumar, «Multi-partite Quantum Entanglement versus Randomization: Fair and Unbiased Leader Election in Networks», DOI 10.48550/arXiv.quant-ph/0306195, June 2003, <https://arxiv.org/pdf/quant-ph/0306195.pdf>.

[Preskill] Preskill, J., «Quantum Computing in the NISQ era and beyond», DOI 10.22331/q-2018-08-06-79, July 2018, <https://arxiv.org/pdf/1801.00862>.

[Proctor] Proctor, T. J., Knott, P. A., and J. A. Dunningham, «Multiparameter Estimation in Networked Quantum Sensors», Physical Review Letters, American Physical Society, DOI 10.1103/PhysRevLett.120.080501, February 2018, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.120.080501>.

[Qin] Qin, H., «Towards large-scale quantum key distribution network and its applications», June 2019, <https://www.itu.int/en/ITU-T/Workshops-and-Seminars/2019060507/Documents/Hao_Qin_Presentation.pdf>.

[QUANTUM-CONNECTION] Van Meter, R. and T. Matsuo, «Connection Setup in a Quantum Network», Work in Progress, Internet-Draft, draft-van-meter-qirg-quantum-connection-setup-01, 11 September 2019, <https://datatracker.ietf.org/doc/html/draft-van-meter-qirg-quantum-connection-setup-01>.

[Renner] Renner, R., «Security of Quantum Key Distribution», DOI 10.48550/arXiv.quant-ph/0512258, September 2005, <https://arxiv.org/pdf/quant-ph/0512258.pdf>.

[RFC7258] Farrell, S. and H. Tschofenig, «Pervasive Monitoring Is an Attack», BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC9340] Kozlowski, W., Wehner, S., Van Meter, R., Rijsman, B., Cacciapuoti, A. S., Caleffi, M., and S. Nagayama, «Architectural Principles for a Quantum Internet», RFC 9340, DOI 10.17487/RFC9340, March 2023, <https://www.rfc-editor.org/info/rfc9340>.

[Taherkhani] Taherkhani, M. A., Navi, K., and R. Van Meter, «Resource-aware System Architecture Model for Implementation of Quantum aided Byzantine Agreement on Quantum Repeater Networks», DOI 10.1088/2058-9565/aa9bb1, January 2017, <https://arxiv.org/abs/1701.04588>.

[Tang] Tang, B-Y., Liu, B., Zhai, Y-P., Wu, C-Q., and W-R. Yu, «High-speed and Large-scale Privacy Amplification Scheme for Quantum Key Distribution», Scientific Reports, DOI 10.1038/s41598-019-50290-1, October 2019, <https://doi.org/10.1038/s41598-019-50290-1>.

[Treiber] Treiber, A., Poppe, A., Hentschel, M., Ferrini, D., Lorünser, T., Querasser, E., Matyus, T., Hübel, H., and A. Zeilinger, «A fully automated entanglement-based quantum cryptography system for telecom fiber networks», New Journal of Physics 11 045013, DOI 10.1088/1367-2630/11/4/045013, April 2009, <https://iopscience.iop.org/article/10.1088/1367-2630/11/4/045013>.

[VanMeter2006-01] Van Meter, R., Nemoto, K., Munro, W. J., and K. M. Itoh, «Distributed Arithmetic on a Quantum Multicomputer», 33rd International Symposium on Computer Architecture (ISCA ’06), DOI 10.1109/ISCA.2006.19, June 2006, <https://doi.org/10.1109/ISCA.2006.19>.

[VanMeter2006-02] Van Meter, R. D., «Architecture of a Quantum Multicomputer Optimized for Shor’s Factoring Algorithm», DOI 10.48550/arXiv.quant-ph/0607065, February 2008, <https://arxiv.org/pdf/quant-ph/0607065.pdf>.

[Wehner] Wehner, S., Elkouss, D., and R. Hanson, «Quantum internet: A vision for the road ahead», Science 362, DOI 10.1126/science.aam9288, October 2018, <http://science.sciencemag.org/content/362/6412/eaam9288.full>.

[Xu] Xu, F., Qi, B., and H-K. Lo, «Experimental demonstration of phase-remapping attack in a practical quantum key distribution system», New Journal of Physics 12 113026, DOI 10.1088/1367-2630/12/11/113026, November 2010, <https://iopscience.iop.org/article/10.1088/1367-2630/12/11/113026>.

[Zhandry] Zhandry, M., «Quantum Lightning Never Strikes the Same State Twice», Advances in Cryptology — EUROCRYPT 2019, DOI 10.1007/978-3-030-17659-4_14, April 2019, <http://doi.org/10.1007/978-3-030-17659-4_14>.

[Zhang2009] Zhang, X., Luo, W., Zeng, G., Weng, J., Yang, Y., Chen, M., and X. Tan, «A hybrid universal blind quantum computation», DOI 10.1016/j.ins.2019.05.057, September 2019, <https://www.sciencedirect.com/science/article/abs/pii/S002002551930458X>.

[Zhang2018] Zhang, Q., Xu, F., Chen, Y-A., Peng, C-Z., and J-W. Pan, «Large scale quantum key distribution: challenges and solutions [Invited]», Optics Express, DOI 10.1364/OE.26.024260, August 2018, <https://doi.org/10.1364/OE.26.024260>.

[Zhao2008] Zhao, Y., Fred Fung, C-H., Qi, B., Chen, C., and H-K. Lo, «Quantum hacking: Experimental demonstration of time-shift attack against practical quantum-key-distribution systems», Physical Review A, American Physical Society, DOI 10.1103/PhysRevA.78.042333, October 2008, <https://link.aps.org/doi/10.1103/PhysRevA.78.042333>.

[Zhao2018] Zhao, Y., «Development of Quantum Key Distribution and Attacks against It», Journal of Physics: Conference Series, DOI 10.1088/1742-6596/1087/4/042028, 2018, <https://iopscience.iop.org/article/10.1088/1742-6596/1087/4/042028>.

[Zheng2019] Zheng, X., Zhang, P., Ge, R., Lu, L., He, G., Chen, Q., Qu, F., Zhang, L., Cai, X., Lu, Y., Zhu, S., Wu, P., and X-S. Ma, «Heterogeneously integrated, superconducting silicon-photonic platform for measurement-device-independent quantum key distribution», DOI 10.1117/1.AP.3.5.055002, December 2019, <https://arxiv.org/abs/1912.09642>.

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

Авторы благодарны Michele Amoretti, Mathias Van Den Bossche, Xavier de Foy, Patrick Gelard, Álvaro Gómez Iñesta, Mallory Knodel, Wojciech Kozlowski, John Preuß Mattsson, Rodney Van Meter, Colin Perkins, Joey Salazar, Joseph Touch, Brian Trammell и сообществу QIRG в целом за полезные рецензии и комментарии к документу.

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

Chonggang Wang
InterDigital Communications, LLC
1001 E Hector St
Conshohocken, PA 19428
United States of America
Email: Chonggang.Wang@InterDigital.com
 
Akbar Rahman
Ericsson
349 Terry Fox Drive
Ottawa Ontario K2K 2V6
Canada
Email: Akbar.Rahman@Ericsson.Com
 
Ruidong Li
Kanazawa University
Kakumamachi, Kanazawa, Ishikawa
920-1192
Japan
Email: lrd@se.kanazawa-u.ac.jp
 
Melchior Aelmans
Juniper Networks
Boeing Avenue 240
1119 PZ Schiphol-Rijk
Netherlands
Email: maelmans@juniper.net
 
Kaushik Chakraborty
The University of Edinburgh
10 Crichton Street
Edinburgh, Scotland
EH8 9AB
United Kingdom
Email: kaushik.chakraborty9@gmail.com

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

nmalykh@protokols.ru


1Internet Research Task Force — комиссия по исследовательским задачам Internet.

2Digital Subscriber Line — цифровая абонентская линия.

3В русском языке принят термин «задача византийских генералов», см. здесь. Прим. перев.

4Byzantine Fault Tolerance — византийская отказоустойчивость.

Рубрика: RFC | Оставить комментарий

RFC 9587 YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)

Internet Engineering Task Force (IETF)                         A. Lindem
Request for Comments: 9587                       LabN Consulting, L.L.C.
Category: Standards Track                                      S. Palani
ISSN: 2070-1721                                                Microsoft
                                                                   Y. Qu
                                                  Futurewei Technologies
                                                               June 2024

YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)

Модель данных YANG для расширенных анонсов LSA в OSPFv3

PDF

Аннотация

В этом документе определена модель данных YANG, дополняющая модель IETF OSPF YANG (RFC 9129) для поддержки расширяемости анонсов состояния каналов (Link State Advertisement или LSA) в OSPFv3, определённой в RFC 8362. OSPFv3 Extended LSA обеспечивают на основе TLV расширения типов LSA, определённых в RFC 5340.

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

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

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

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

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

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

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

1. Обзор

Язык определения данных YANG [RFC7950] служит для задания содержимого концептуального хранилища данных, которое позволяет управлять сетевыми устройствами с помощью NETCONF [RFC6241]. YANG подходит и для других ситуаций, таких как привязка к другим интерфейсам (например, RESTCONF [RFC8040]) и отличное от XML кодирование (например, JSON). Кроме того, модели данных YANG могут служить основой для реализации таких интерфейсов, как командный (Command-Line Interface или CLI) или программный API.

В этом документе задана модель данных YANG, дополняющая модель IETF OSPF YANG [RFC9129], которая сама дополняет [RFC8349], для поддержки конфигурации и рабочих состояний расширенных анонсов состояния каналов OSPFv3 (LSA), определённых в [RFC8362].

Заданный здесь модуль YANG соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].

2. Диаграммы деревьев

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

3. OSPFv3 Extended LSA

Этот документ определяет модель данных YANG для OSPFv3 Extended LSA, дополняя базовую модель OSPF [RFC9129] для поддержки расширения OSPFv3 LSA [RFC8362]. Расширенные OSPFv3 LSA поддерживают анонсы состояния каналов на основе TLV в соответствии с [RFC5340].

Модуль YANG OSPFv3 Extended LSA требует поддержки базовой модели OSPF, определяющей базовые состояния и конфигурацию OSPF. Модуль YANG OSPF дополняет модель данных YANG ietf-routing, заданную в [RFC8349]. Дополнения модуля YANG ietf-ospfv3-extended-lsa обеспечивают поддержку глобальной конфигурации, конфигурации областей (area) и добавление OSPFv3 Extended LSA к рабочему состоянию базы состояний каналов (Link State Database или LSDB).

   module: ietf-ospfv3-extended-lsa

     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf:
       +--rw extended-lsa-support?   boolean
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:areas
               /ospf:area:
       +--rw extended-lsa-support?   boolean
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
               /ospf:interfaces/ospf:interface/ospf:database
               /ospf:link-scope-lsa-type/ospf:link-scope-lsas
               /ospf:link-scope-lsa/ospf:version/ospf:ospfv3/ospf:ospfv3
               /ospf:body:
       +--ro e-link
          +--ro rtr-priority?   uint8
          +--ro lsa-options
          |  +--ro lsa-options*   identityref
          +--ro e-link-tlvs* []
             +--ro unknown-tlv
             |  +--ro type?     uint16
             |  +--ro length?   uint16
             |  +--ro value?    yang:hex-string
             +--ro intra-prefix-tlv
             |  +--ro metric?           ospf:ospf-metric
             |  +--ro prefix?           inet:ip-prefix
             |  +--ro prefix-options
             |  |  +--ro prefix-options*   identityref
             |  +--ro sub-tlvs* []
             |     +--ro unknown-sub-tlv
             |        +--ro type?     uint16
             |        +--ro length?   uint16
             |        +--ro value?    yang:hex-string
             +--ro ipv6-link-local-addr-tlv
             |  +--ro link-local-address?   inet:ipv6-address
             |  +--ro sub-tlvs* []
             |     +--ro unknown-sub-tlv
             |        +--ro type?     uint16
             |        +--ro length?   uint16
             |        +--ro value?    yang:hex-string
             +--ro ipv4-link-local-addr-tlv
                +--ro link-local-address?   inet:ipv4-address
                +--ro sub-tlvs* []
                   +--ro unknown-sub-tlv
                      +--ro type?     uint16
                      +--ro length?   uint16
                      +--ro value?    yang:hex-string
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
               /ospf:database/ospf:area-scope-lsa-type
               /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
               /ospf:ospfv3/ospf:ospfv3/ospf:body:
       +--ro e-router
       |  +--ro router-bits
       |  |  +--ro rtr-lsa-bits*   identityref
       |  +--ro lsa-options
       |  |  +--ro lsa-options*   identityref
       |  +--ro e-router-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro link-tlv
       |        +--ro interface-id?            uint32
       |        +--ro neighbor-interface-id?   uint32
       |        +--ro neighbor-router-id?      rt-types:router-id
       |        +--ro type?                    ospf:router-link-type
       |        +--ro metric?                  ospf:ospf-link-metric
       |        +--ro sub-tlvs* []
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-network
       |  +--ro lsa-options
       |  |  +--ro lsa-options*   identityref
       |  +--ro e-network-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro attached-router-tlv
       |        +--ro adjacent-neighbor-router-id*   rt-types:router-id
       +--ro e-nssa
       |  +--ro e-external-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro external-prefix-tlv
       |        +--ro flags
       |        |  +--ro ospfv3-e-external-prefix-bits*   identityref
       |        +--ro metric?           ospf:ospf-metric
       |        +--ro prefix?           inet:ip-prefix
       |        +--ro prefix-options
       |        |  +--ro prefix-options*   identityref
       |        +--ro sub-tlvs* []
       |           +--ro ipv6-fwd-addr-sub-tlv
       |           |  +--ro forwarding-address?   inet:ipv6-address
       |           +--ro ipv4-fwd-addr-sub-tlv
       |           |  +--ro forwarding-address?   inet:ipv4-address
       |           +--ro route-tag-sub-tlv
       |           |  +--ro route-tag?   uint32
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-inter-area-prefix
       |  +--ro e-inter-prefix-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro inter-prefix-tlv
       |        +--ro metric?           ospf:ospf-metric
       |        +--ro prefix?           inet:ip-prefix
       |        +--ro prefix-options
       |        |  +--ro prefix-options*   identityref
       |        +--ro sub-tlvs* []
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-inter-area-router
       |  +--ro e-inter-router-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro inter-router-tlv
       |        +--ro lsa-options
       |        |  +--ro lsa-options*   identityref
       |        +--ro metric?                  ospf:ospf-metric
       |        +--ro destination-router-id?   rt-types:router-id
       |        +--ro sub-tlvs* []
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-intra-area-prefix
          +--ro referenced-ls-type?         uint16
          +--ro referenced-link-state-id?   uint32
          +--ro referenced-adv-router?      rt-types:router-id
          +--ro e-intra-prefix-tlvs* []
             +--ro unknown-tlv
             |  +--ro type?     uint16
             |  +--ro length?   uint16
             |  +--ro value?    yang:hex-string
             +--ro intra-prefix-tlv
                +--ro metric?           ospf:ospf-metric
                +--ro prefix?           inet:ip-prefix
                +--ro prefix-options
                |  +--ro prefix-options*   identityref
                +--ro sub-tlvs* []
                   +--ro unknown-sub-tlv
                      +--ro type?     uint16
                      +--ro length?   uint16
                      +--ro value?    yang:hex-string
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:database
               /ospf:as-scope-lsa-type/ospf:as-scope-lsas
               /ospf:as-scope-lsa/ospf:version/ospf:ospfv3/ospf:ospfv3
               /ospf:body:
       +--ro e-as-external
          +--ro e-external-tlvs* []
             +--ro unknown-tlv
             |  +--ro type?     uint16
             |  +--ro length?   uint16
             |  +--ro value?    yang:hex-string
             +--ro external-prefix-tlv
                +--ro flags
                |  +--ro ospfv3-e-external-prefix-bits*   identityref
                +--ro metric?           ospf:ospf-metric
                +--ro prefix?           inet:ip-prefix
                +--ro prefix-options
                |  +--ro prefix-options*   identityref
                +--ro sub-tlvs* []
                   +--ro ipv6-fwd-addr-sub-tlv
                   |  +--ro forwarding-address?   inet:ipv6-address
                   +--ro ipv4-fwd-addr-sub-tlv
                   |  +--ro forwarding-address?   inet:ipv4-address
                   +--ro route-tag-sub-tlv
                   |  +--ro route-tag?   uint32
                   +--ro unknown-sub-tlv
                      +--ro type?     uint16
                      +--ro length?   uint16
                      +--ro value?    yang:hex-string

4. Модуль YANG OSPFv3 Extended LSA

[RFC6991] и [RFC8294] не упоминаются в этом документе, но ссылки на них даны в модуле ietf-ospfv3-extended-lsa.yang.

   <CODE BEGINS> file "ietf-ospfv3-extended-lsa@2024-06-07.yang"
   module ietf-ospfv3-extended-lsa {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ospfv3-extended-lsa";
     prefix ospfv3-e-lsa;

     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing
          Management (NMDA Version)";
     }
     import ietf-ospf {
       prefix ospf;
       reference
         "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     organization
       "IETF LSR - Link State Routing Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/lsr/> 
        WG List:  <mailto:lsr@ietf.org> 

        Author:   Acee Lindem
                  <mailto:acee.ietf@gmail.com> 
        Author:   Sharmila Palani
                  <mailto:sharmila.palani@microsoft.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.ietf@gmail.com>"; 
     description
       "Этот модуль YANG определяет конфигурацию и рабочее состояние
        OSPFv3 Extended LSA, общие для реализаций всех производителей.
        Семантика и кодирование OSPFv3 Extended LSA описаны в RFC 8362. 
        OSPFv3 Extended LSA обеспечивают на основе TLV расширения базовых 
        типов LSA, определённых в RFC 5340.

        Модуль YANG соответствует архитектуре NMDA (RFC 8342).

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

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

        Эта версия данного модуля YANG является частью RFC 9587, где
        правовые вопросы рассмотрены более полно.";

     reference
       "RFC 9587: YANG Data Model for OSPFv3 Extended Link State
        Advertisements (LSAs)";

     revision 2024-06-07 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9587: YANG Data Model for OSPFv3 Extended Link State
          Advertisements (LSAs)";
     }

     /*
      * Идентификаторы типов OSPFv3 Extended LSA
      */

     identity ospfv3-e-router-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Router-LSA - тип 0xA021.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.1";
     }

     identity ospfv3-e-network-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Network-LSA - тип 0xA022.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.2";
     }

     identity ospfv3-e-summary-lsa-type {
       base ospf:ospfv3-lsa-type;
       description
         "Типы OSPFv3 Extended Summary LSA 
          E-Inter-Area-Prefix-LSA and E-Inter-Area-Router-LSA.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграфы 4.3 и 4.4";
     }

     identity ospfv3-e-inter-area-prefix-lsa {
       base ospfv3-e-summary-lsa-type;
       description
         "OSPFv3 E-Inter-Area-Prefix-LSA - тип 0xA023.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.3";
     }

     identity ospfv3-e-inter-area-router-lsa {
       base ospfv3-e-summary-lsa-type;
       description
         "OSPFv3 E-Inter-Area-Router-LSA - тип 0xA024.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.4";
     }

     identity ospfv3-e-external-lsa-type {
       base ospf:ospfv3-lsa-type;
       description
         "Типы OSPFv3 Extended External LSA 
          E-AS-External-LSA и E-NSSA-LSA (NSSA- это 
          Not-So-Stubby-Area — не совсем тупиковая область).";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграфы 4.5 и 4.6";
     }

     identity ospfv3-e-as-external-lsa {
       base ospfv3-e-external-lsa-type;
       description
         "OSPFv3 E-AS-External-LSA - тип 0xC025.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.5";
     }

     identity ospfv3-e-nssa-lsa {
       base ospfv3-e-external-lsa-type;
       description
         "OSPFv3 E-NSSA-LSA - тип 0xA027.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.6";
     }

     identity ospfv3-e-link-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Link-LSA - тип 0x8028.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.7";
     }

     identity ospfv3-e-intra-area-prefix-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Intra-Area-Prefix-LSA - тип 0xA029.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.8";
     }

     identity ospfv3-e-prefix-option {
       description
         "Базовые идентификаторы для опций префикса OSPFv3.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1";
     }

     identity nu-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс следует исключать
          из расчётов IPv6.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity la-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс фактически является
          адресом IPv6 анонсирующего маршрутизатора.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity p-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс NSSA следует транслировать
          в E-AS-External-LSA и анонсировать транслирующему NSSA BR.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity dn-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс E-Inter-Area-Prefix-LSA или
          E-AS-External-LSA анонсируется как префикс L3VPN.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity n-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс является адресом хоста,
          который идентифицирует анонсирующий маршрутизатор.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity ospfv3-e-external-prefix-option {
       description
         "Базовый идентификатор для опций внешнего префикса OSPFv3.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.6";
     }

     identity e-bit {
       base ospfv3-e-external-prefix-option;
       description
         "При установленном флаге E заданная метрика является внешней
          метрикой типа 2. Это означает, что метрика считается больше,
          чем у любого пути внутри AS. Сброшенный бит E указывает 
          внешнюю метрику типа 1. Это означает, что она выражается в 
          таких же единицах, как и в других LSA (как стоимость
          интерфейса в Router-LSA).";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.6";
     }

     grouping unknown-sub-tlv {
       description
         "Неизвестная группа TLV.";
       container unknown-sub-tlv {
         uses ospf:tlv;
         description
           "Неизвестный суб-TLV внешнего TLV.";
       }
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 6.3";
     }

     grouping ospfv3-lsa-prefix {
       description
         "Префикс OSPFv3 LSA.";
       leaf prefix {
         type inet:ip-prefix;
         description
           "LSA prefix.";
       }
       container prefix-options {
         leaf-list prefix-options {
           type identityref {
             base ospfv3-e-prefix-option;
           }
           description
             "Список флагов опций префикса OSPFv3, содержащий
              идентификаторы опций OSPFv3, установленных для
              префикса OSPFv3.";
         }
         description
           "Опции префикса.";
         reference
           "RFC 8362:  OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 3.1";
       }
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3";
     }

     grouping external-prefix-tlv {
       container external-prefix-tlv {
         description
           "External-Prefix TLV.";
         container flags {
           leaf-list ospfv3-e-external-prefix-bits {
             type identityref {
               base ospfv3-e-external-prefix-option;
             }
             description
               "Список битов OSPFv3 External-Prefix TLV.";
           }
           description
             "Флаги внешнего префикса.";
         }
         leaf metric {
           type ospf:ospf-metric;
           description
             "Метрика внешнего префикса.";
         }
         uses ospfv3-lsa-prefix;
         list sub-tlvs {
           description
             "Суб-TLV External-Prefix TLV.";
           container ipv6-fwd-addr-sub-tlv {
             description
               "Суб-TLV IPv6-Forwarding-Address для E-AS-External-LSA
                и E-NSSA-LSA для семейства адресов IPv6.";
             leaf forwarding-address {
               type inet:ipv6-address;
               description
                 "Адрес пересылки IPv6.";
             }
             reference
               "RFC 8362: OSPFv3 Link State Advertisement (LSA)
                Extensibility, параграф 3.10";
           }
           container ipv4-fwd-addr-sub-tlv {
             description
               "Суб-TLV IPv4-Forwarding-Address для E-AS-External-LSA
                и E-NSSA-LSA для семейства адресов IPv4.";
             leaf forwarding-address {
               type inet:ipv4-address;
               description
                 "Адрес пересылки IPv4.";
             }
             reference
               "RFC 8362: OSPFv3 Link State Advertisement (LSA)
                Extensibility, параграф 3.11";
           }
           container route-tag-sub-tlv {
             description
               "Суб-TLV Route-Tag.";
             leaf route-tag {
               type uint32;
               description
                 "Тег маршрута.";
             }
             reference
               "RFC 8362: OSPFv3 Link State Advertisement (LSA)
                Extensibility, параграф 3.12";
           }
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа External-Prefix TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.6";
     }

     grouping intra-area-prefix-tlv {
       container intra-prefix-tlv {
         description
           "Intra-Area-Prefix-LSA TLV.";
         leaf metric {
           type ospf:ospf-metric;
           description
             "Метрика внутриобластного префикса.";
         }
         uses ospfv3-lsa-prefix;
         list sub-tlvs {
           description
             "Суб-TLV Intra-Area-Prefix TLV.";
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа Intra-Area-Prefix TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.7";
     }

     grouping ipv6-link-local-addr-tlv {
       container ipv6-link-local-addr-tlv {
         description
           "IPv6 Link-Local Address TLV.";
         leaf link-local-address {
           type inet:ipv6-address;
           description
             "Адрес IPv6 Link-Local.";
         }
         list sub-tlvs {
           description
             "Суб-TLV IPv6 Link-Local Address TLV.";
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа IPv6 Link-Local Address TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.8";
     }

     grouping ipv4-link-local-addr-tlv {
       container ipv4-link-local-addr-tlv {
         description
           "IPv4 Link-Local Address TLV.";
         leaf link-local-address {
           type inet:ipv4-address;
           description
             "Адрес IPv4 Link-Local.";
         }
         list sub-tlvs {
           description
             "Суб-TLV IPv4 Link-Local Address TLV.";
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа IPv4 Link-Local Address TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.9";
     }

     /* Конфигурация */

     augment "/rt:routing/rt:control-plane-protocols"
           + "/rt:control-plane-protocol/ospf:ospf" {
       when "../rt:type = 'ospf:ospfv3'" {
         description
           "Дополняет протокол маршрутизации OSPFv3.";
       }
       description
         "Дополняет конфигурацию на уровне экземпляра OSPFv3 поддержкой
          Extended LSA. При включённой поддержке будут анонсироваться
          OSPFv3 Extended LSA, и не будут передаваться OSPFv3 Legacy
          LSA, которые анонсируются при отключённой поддержке. Однако 
          OSPFv3 Extended LSA могут анонсироваться в Extended LSA Sparse
          Mode для поддержки постепенного внедрения, как описано в
          параграфе 6.2 of RFC 8362.";
       leaf extended-lsa-support {
         type boolean;
         default "false";
         description
           "Включает поддержку OSPFv3 Extended LSA для домена OSPFv3.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, Приложение A - Global Configuration Support";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf:ospf/ospf:"
           + "areas/ospf:area" {
       when "../../../rt:type = 'ospf:ospfv3'" {
         description
           "Дополняет конфигурацию протокола OSPFv3 на уровне области.";
       }
       description
         "Дополняет конфигурацию протокола OSPFv3 на уровне области
          поддержкой Extended LSA.";
       leaf extended-lsa-support {
         type boolean;
         must "derived-from(../ospf:area-type,'stub-nssa-area') or "
            + "(current() = 'true') or "
            + "(../../../extended-lsa-support = 'false')" {
           description
             "Для обычных областей (области с лавинной рассылкой LSA
              уровня AS) отключение AreaExtendedLSASupport на уровне
              области запрещено при включении ExtendedLSASupport на
              уровне экземпляра. Анонсы E-AS-External-LSA рассылаются
              лавинно во все обычные области OSPFv3 (не тупиковые и не
              NSSA), поэтому отключение поддержки на уровне области
              невозможно.";
         }
         description
           "Дополняет конфигурацию протокола OSPFv3 на уровне области
            поддержкой Extended LSA. При включённой поддержке будут
            анонсироваться OSPFv3 Extended LSA и не будут передаваться 
            OSPFv3 Legacy LSA, которые анонсируются при отключённой 
            поддержке. Однако OSPFv3 Extended LSA могут анонсироваться
            в Extended LSA Sparse Mode для поддержки постепенного 
            внедрения, как описано в параграфе 6.2 of RFC 8362. По
            умолчанию статус поддержки Extended LSA наследуется из
            конфигурации на уровне экземпляра.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, Приложение B - Area Configuration Support";
       }
     }

     /*
      * Дополнения базы состояний каналов (Link State Database или LSDB)
      */

     augment "/rt:routing/"
           + "rt:control-plane-protocols/rt:control-plane-protocol/"
           + "ospf:ospf/ospf:areas/ospf:area/"
           + "ospf:interfaces/ospf:interface/ospf:database/"
           + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/"
           + "ospf:link-scope-lsa/ospf:version/ospf:ospfv3/"
           + "ospf:ospfv3/ospf:body" {
       when "../../../../../../../../../../../"
          + "rt:type = 'ospf:ospfv3'" {
         description
           "Это дополнение применимо лишь к OSPFv3.";
       }
       description
         "Добавляет OSPFv3 Link-scoped Extended LSA к рабочему
          состоянию LSDB на интерфейсе.";
       container e-link {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-link-lsa'" {
           description
             "Применимо лишь к E-Link-LSA.";
         }
         description
           "E-Link-LSA contents.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.7";
         leaf rtr-priority {
           type uint8;
           description
             "Приоритет маршрутизатора для интерфейса.";
         }
         uses ospf:ospfv3-lsa-options;
         list e-link-tlvs {
           description
             "E-Link-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Link TLV.";
           }
           uses intra-area-prefix-tlv;
           uses ipv6-link-local-addr-tlv;
           uses ipv4-link-local-addr-tlv;
         }
       }
     }

     augment "/rt:routing/"
           + "rt:control-plane-protocols/rt:control-plane-protocol/"
           + "ospf:ospf/ospf:areas/ospf:area/ospf:database/"
           + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/"
           + "ospf:area-scope-lsa/ospf:version/ospf:ospfv3/"
           + "ospf:ospfv3/ospf:body" {
       when "../../../../../../../../../"
          + "rt:type = 'ospf:ospfv3'" {
         description
           "Это дополнение применимо лишь к OSPFv3.";
       }
       description
         "Добавляет OSPFv3 Area-scoped Extended LSA к рабочему
          состоянию LSDB для области.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4";
       container e-router {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-router-lsa'" {
           description
             "Применимо лишь к OSPFv3 E-Router-LSA.";
         }
         description
           "Содержимое OSPFv3 E-Router-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.1";
         uses ospf:ospf-router-lsa-bits;
         uses ospf:ospfv3-lsa-options;
         list e-router-tlvs {
           description
             "E-Router-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Router TLV.";
           }
           container link-tlv {
             description
               "E-Router-LSA TLV.";
             leaf interface-id {
               type uint32;
               description
                 "Идентификатор интерфейса для канала.";
             }
             leaf neighbor-interface-id {
               type uint32;
               description
                 "Идентификатор интерфейса соседа по каналу.";
             }
             leaf neighbor-router-id {
               type rt-types:router-id;
               description
                 "Идентификатор соседнего маршрутизатора на канале.";
             }
             leaf type {
               type ospf:router-link-type;
               description
                 "Тип канала: 1 - «точка-точка»
                              2 - канал в транзитную сеть
                              3 - канал в тупиковую сеть
                              4 - виртуальный канал.";
             }
             leaf metric {
               type ospf:ospf-link-metric;
               description
                 "Метрика канала.";
             }
             list sub-tlvs {
               description
                 "Суб-TLV Link TLV.";
               uses unknown-sub-tlv;
             }
           }
         }
       }
       container e-network {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-network-lsa'" {
           description
             "Применимо лишь к E-Network-LSA.";
         }
         description
           "Содержимое E-Network-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.2";
         uses ospf:ospfv3-lsa-options;
         list e-network-tlvs {
           description
             "E-Network-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Network TLV.";
           }
           container attached-router-tlv {
             description
               "Attached-Routers TLV.";
             leaf-list adjacent-neighbor-router-id {
               type rt-types:router-id;
               description
                 "Идентификатор смежного маршрутизатора.";
             }
           }
         }
       }
       container e-nssa {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-nssa-lsa'" {
           description
             "Применимо лишь к E-NSSA-LSA.";
         }
         description
           "Содержимое E-NSSA-LSA.";
         list e-external-tlvs {
           description
             "E-NSSA-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-External TLV.";
           }
           uses external-prefix-tlv;
         }
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.6";
       }
       container e-inter-area-prefix {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-inter-area-prefix-lsa'" {
           description
             "Применимо лишь к E-Inter-Area-Prefix-LSA.";
         }
         description
           "Содержимое E-Inter-Area-Prefix-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.3";
         list e-inter-prefix-tlvs {
           description
             "E-Inter-Area-Prefix-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Inter-Area-Prefix TLV.";
           }
           container inter-prefix-tlv {
             description
               "Неизвестный E-Inter-Area-Prefix-LSA TLV.";
             leaf metric {
               type ospf:ospf-metric;
               description
                 "Метрика внутриобластного префикса.";
             }
             uses ospfv3-lsa-prefix;
             list sub-tlvs {
               description
                 "Суб-TLV Inter-Area-Prefix TLV.";
               uses unknown-sub-tlv;
             }
           }
         }
       }
       container e-inter-area-router {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-inter-area-router-lsa'" {
           description
             "Применимо лишь к E-Inter-Area-Router-LSA.";
         }
         description
           "Содержимое E-Inter-Area-Router-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.4";
         list e-inter-router-tlvs {
           description
             "E-Inter-Area-Router-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Inter-Area-Router TLV.";
           }
           container inter-router-tlv {
             description
               "Неизвестный E-Inter-Area-Router-LSA TLV.";
             uses ospf:ospfv3-lsa-options;
             leaf metric {
               type ospf:ospf-metric;
               description
                 "Метрика межобластного маршрутизатора.";
             }
             leaf destination-router-id {
               type rt-types:router-id;
               description
                 "Идентификатор целевого маршрутизатора.";
             }
             list sub-tlvs {
               description
                 "Inter-Area-Router TLV sub-TLV.";
               uses unknown-sub-tlv;
             }
           }
         }
       }
       container e-intra-area-prefix {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-intra-area-prefix-lsa'" {
           description
             "Применимо лишь к E-Intra-Area-Prefix-LSA.";
         }
         description
           "Содержимое E-Intra-Area-Prefix-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.8";
         leaf referenced-ls-type {
           type uint16;
           description
             "Тип Referenced Link State.";
         }
         leaf referenced-link-state-id {
           type uint32;
           description
             "Referenced Link State ID.";
         }
         leaf referenced-adv-router {
           type rt-types:router-id;
           description
             "Анонсирующий маршрутизатор.";
         }
         list e-intra-prefix-tlvs {
           description
             "E-Intra-Area-Prefix-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Intra-Area-Prefix TLV.";
           }
           uses intra-area-prefix-tlv;
         }
       }
     }

     augment "/rt:routing/"
           + "rt:control-plane-protocols/rt:control-plane-protocol/"
           + "ospf:ospf/ospf:database/"
           + "ospf:as-scope-lsa-type/ospf:as-scope-lsas/"
           + "ospf:as-scope-lsa/ospf:version/ospf:ospfv3/"
           + "ospf:ospfv3/ospf:body" {
       when "../../../../../../../"
          + "rt:type = 'ospf:ospfv3'" {
         description
           "Это дополнение действительно лишь для OSPFv3.";
       }
       description
         "Это дополнение добавляет OSPFv3 AS-scoped Extended LSA к
          рабочему состоянию для LSDB на уровне экземпляра AS.";
       container e-as-external {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-as-external-lsa'" {
           description
             "Применимо лишь к E-AS-External-LSA.";
         }
         description
           "Содержимое E-AS-External-LSA.";
         list e-external-tlvs {
           description
             "E-AS-External-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-External TLV.";
           }
           uses external-prefix-tlv;
         }
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.5";
       }
     }
   }
   <CODE ENDS>

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

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

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В заданном здесь модуле ietf-ospfv3-extended-lsa.yang определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/ospf:ospf/extended-lsa-support

/ospf:ospf/ospf:areas/ospf:area/extended-lsa-support

Способность управлять поддержкой OSPFv3 Extended LSA может приводить к атакам на службы (Denial-of-Service или DoS), поскольку маршрутизаторы OSPFv3 будут использовать для расчётов OSPFv3 SPF исключительно OSPFv3 Extended LSA, либо OSPFv3 Legacy LSA. Использование маршрутизаторами OSPFv3 разных типов LSA приведёт к неполной доступности и возможному разделению на части домена маршрутизации OSPFv3. Дополнительные сведения о совместимости OSPFv3 Extended LSA приведены в разделе 6 [RFC8362].

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification).

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

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

В соответствии с этим документом агентство IANA внесло URI в реестр IETF XML Registry [RFC3688]

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

В соответствии с этим документом агентство IANA зарегистрировало модуль YANG в реестре YANG Module Names [RFC6020]

   Name:  ietf-ospfv3-extended-lsa
   Maintained by IANA:  N
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ospfv3-extended-lsa
   Prefix:  ospfv3-e-lsa
   Reference:  RFC 9587

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

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

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

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, «OSPF for IPv6», RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

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

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

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

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

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

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

[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, «Common YANG Data Types for the Routing Area», RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.

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

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

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

[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, «OSPFv3 Link State Advertisement (LSA) Extensibility», RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.

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

[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, «YANG Data Model for the OSPF Protocol», RFC 9129, DOI 10.17487/RFC9129, October 2022, <https://www.rfc-editor.org/info/rfc9129>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», W3C Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/xml/>.

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

[RFC7951] Lhotka, L., «JSON Encoding of Data Modeled with YANG», RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

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

[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, «Handling Long Lines in Content of Internet-Drafts and RFCs», RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.

Приложение A. Пример конфигурации

Ниже приведён пример XML (в соответствии с [W3C.REC-xml-20081126]) использования модели данных YANG для OSPFv3 Extended LSA. Длинные строки разорваны (\) в соответствии с [RFC8792].

   <?xml version='1.0' encoding='UTF-8'?>
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <router-id>192.0.2.1</router-id>
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf">\
           ospf:ospfv3</type>
           <name>"OSPFv3"</name>
           <ospf xmlns="urn:ietf:params:xml:ns:yang:ietf-ospf">
             <extended-lsa-support xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ospfv3-extended-lsa">true</extended-lsa-support>
           </ospf>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>

Этот же пример в формате JSON [RFC7951] показан ниже.

   {
     "routing": {
       "router-id": "192.0.2.1",
       "control-plane-protocols": {
         "control-plane-protocol": {
           "type": "ospf:ospfv3",
           "name": "\"OSPFv3\"",
           "ospf": {
             "extended-lsa-support": true
           }
         }
       }
     }
   }

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

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

Большое спасибо Tom Petch, Mahesh Jethanandani, Renato Westphal, Victoria Pritchard, Reshad Rahman, Chris Hopps за их рецензии и комментарии.

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

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
 
Sharmila Palani
Microsoft
1 Microsoft Way
Redmond, WA 98052
United States of America
Email: sharmila.palani@microsoft.com
 
Yingzhen Qu
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.ietf@gmail.com

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9542 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 9542                                   Independent
BCP: 141                                                        J. Abley
Obsoletes: 7042                                               Cloudflare
Category: Best Current Practice                                    Y. Li
ISSN: 2070-1721                                      Huawei Technologies
                                                              April 2024

IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Соображения IANA, использование протоколов и документации IETF для параметров IEEE 802

PDF

Аннотация

Некоторые протоколы IETF используют форматы кадров Ethernet и параметры IEEE 802. В этом документе обсуждаются некоторые аспекты таких параметров и их использование в протоколах IETF, приведены соображения IANA по выделению точек под IANA Organizationally Unique Identifier (OUI), а также указаны некоторые значения для использования в документации. Документ заменяет RFC 7042.

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

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

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

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

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

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

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


1. Введение

В некоторых протоколах IETF применяются форматы и параметры кадров Ethernet и других кадров, связанных с IEEE 802 [IEEE802], включая MAC-адреса и идентификаторы протоколов. Регистрационное агентство (Registration Authority) IEEE [IEEE_RA] управляет выделением идентификаторов, используемых в сетях IEEE 802, в некоторых случаях выделяя блоки таких идентификаторов для дальнейшего распределения получившей блок организацией. IEEE RA также предоставляет ряд учебных пособий, относящихся к этим параметрам [IEEEtutorials].

Агентство IEEE RA выделило IANA уникальный идентификатор организации (Organizationally Unique Identifier или OUI) и соответствующий набор MAC-адресов, а также иные коды, основанные на полученном OUI. Этот документ описывает соображения IANA по распределению кодов в рамках IANA OUI, включая MAC-адреса и идентификаторы протоколов, а также указывает некоторые значения для использования в документации. Как указано в [RFC2606] и [RFC5737], использование значений кодов, зарезервированных для документации и примеров, снижает вероятность конфликтов и путаницы в результате использования кодов, выделенных для других целей (применения в реальных системах). В документе рассматривается несколько других случаев применения IETF кодов IEEE 802, включая коды IEEE 802 для контроля отказов связности (Connectivity Fault Management тлт CFM) [RFC7319] и связанных с производителями субтипов TLV (Vendor-Specific TLV Sub-Type) [RFC8520] протокола IEEE 802 для обнаружения локального канала (Link Local Discovery Protocol или LLDP) [IEEE802.1AB]. Документ также задаёт теги краткого двоичного представления объектов (Concise Binary Object Representation или CBOR) для MAC-адресов и OUI/CID.

Приведённые здесь описания правил и процедур [IANA] являются полномочными, но описания правил, процедур и стандартов регистрации IEEE имеют лишь информативный характер, а полномочные сведения IEEE следует получать из документов IEEE.

Этот документ включает процедуры [RFC8126], за исключением случаев противоречия данному документу. Здесь термин «ратификация IESG» (IESG Ratification), определённый в параграфе 5.1, указывает сочетание процедур Expert Review и IESG Approval, определённых в [RFC8126], где IESG Approval требуется лишь в тех случаях, когда эксперт не отклоняет запрос. Это не совпадает с трактовкой IESG Approval в [RFC8126].

1.1. Используемые обозначения

В документе применяется шестнадцатеричная нотация. Каждый октет (8-битовый байт) представляется двумя шестнадцатеричными цифрами, указывающими октет как целое число без знака. Последовательные октеты разделяются символом дефиса (-). В документе используется принятый в IETF (сетевой) порядок битов, хотя физически битов октета передаются по каналу IEEE [IEEE.802.3_2012], начиная с младшего (обратный по отношению к IETF).

AFN

Address Family Number [RFC4760] — номер семейства адресов.

CBOR

Concise Binary Object Representation [RFC8949] — краткое двоичное представление.

CFM

Connectivity Fault Management [RFC7319] — контроль отказов связности.

CID

Company Identifier — идентификатор компании (см. параграф 2.1.2).

DSAP

Destination Service Access Point — точка доступа к целевому сервису (см. раздел 3).

EUI

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

EUI-48

48-битовый EUI.

IEEE

Institute of Electrical and Electronics Engineers [IEEE] — Институт инженеров по электротехнике и электронике.

IEEE 802

LAN/MAN Standards Committee [IEEE802] — Комитет стандартизации локальных и городских сетей.

IEEE RA

IEEE Registration Authority [IEEE_RA] — Регистрационное агентство IEEE.

IEEE SA

IEEE Standards Association [IEEE_SA] — Ассоциация стандартов IEEE.

LLC

Logical Link Control — управление логическим каналом. Тип заголовка кадра, где протокол указывается полями LSAP отправителя и получателя (см. раздел 3).

LSAP

Link-Layer Service Access Point — точка доступа к услугам канального уровня (см. раздел 3).

MA-L

MAC Address Block Large — большой блок MAC-адресов.

MA-M

MAC Address Block Medium — средний блок MAC-адресов.

MA-S

MAC Address Block Small — мелкий блок MAC-адресов.

MAC

Media Access Control — управление доступом к среде (не Message Authentication Code).

MAC-48

48-битовый MAC-адрес. Термин устарел, для глобально уникальных адресов применяется EUI-48.

OUI

Organizationally Unique Identifier — уникальный идентификатор организации (см. параграф 2.1.2).

RRTYPE

DNS Resource Record type [RFC6895] — тип записи о ресурсе DNS.

SLAP

IEEE 802 Structured Local Address Plan [IEEE802_OandA] — структурированный план локальной адресации IEEE 802 (см. параграф 2.1.1).

SNAP

Subnetwork Access Protocol — протокол доступа в подсеть (см. раздел 3).

SSAP

Source Service Access Point — точка доступа к сервису у источника (см. раздел 3).

tag

Ттермин «тег» в этом документе используется в двух значениях. Теги Ethernet описаны в разделе 3, теги CBOR — в параграфе 2.4.

TLV

Type-Length-Value — тип-размер-значение.

**

Обозначение возведения в степень. Например, 2**24 указывает 2 в степени 24.

1.2. Регистрационное агентство IEEE

Изначально за регистрацию параметров Ethernet отвечала корпорация Xerox Corporation, а в 1986 г. было организовано агентство IEEE Registration Authority, доступное через Web [IEEE_RA].

IEEE Registration Authority работает под руководством совета управляющих (Board of Governors) Ассоциации стандартов IEEE (IEEE SA), а надзор за деятельность агентства осуществляет специальный комитет (IEEE Registration Authority Committee или IEEE RAC), являющийся комитетом Совета управляющих.

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

1.3. Идентификатор IANA OUI

Агентство IEEE RA выделило IANA уникальный идентификатор организации (OUI) 00-00-5E. В настоящее время нет значения OUI, зарезервированного для документации, но имеются коды в иерархии IANA OUI, описанные ниже.

1.4. Коды CFM

В стандарте IEEE Std 802.1Q [IEEE.802.1Q_2014] для IETF выделены два блока кодов 802 CFM — один для CFM OpCode, другой для CFM TLV Type (дополнительные сведения приведены в [RFC7319]). В реестре IANA Connectivity Fault Management (CFM) OAM IETF Parameters созданы субреестры для этих кодов. В данном документе эти блоки кодов больше не обсуждаются.

2. Параметры идентификаторов Ethernet

В этом разделе приведены обобщающие контекст сведения из [IEEE802_OandA]. При возникновении каких-либо расхождений преимущество отдаётся [IEEE802_OandA]. В параграфе 2.1 рассмотрены 48-битовые идентификаторы MAC, их связь с OUI и другими префиксами, а также выделение значений в рамках IANA OUI. В параграфе 2.2 рассматриваются 64-битовые идентификаторы, а в параграфе 2.3 обсуждаются другие идентификаторы IETF MAC, не связанные с IANA OUI. Параграф 2.4 задаёт теги CBOR для MAC-адресов и OUI/CID.

Историческое примечание. В устаревшем документе Internet-Draft Note [RAC_OUI] представлены дополнительные сведения о реестрах [IEEE802].

2.1. 48-битовые идентификаторы MAC, OUI и другие префиксы

48-битовые «адреса» MAC являются наиболее распространёнными идентификаторами интерфейсов Ethernet. Уникальные в глобальном масштабе идентификаторы этого типа называются EUI-48 (Extended Unique Identifier 48). Идентификатор EUI-48 состоит из префикса, выделяемого IEEE RA и дополнительных битов, назначаемых владельцем префикса. С 2024 г. выделяются префиксы трёх размеров, однако некоторые биты префикса могут иметь специальное значение, как показано на рисунке 1.

Таблица .

 

Размер префикса в битах

Имя

Представляемые владельцем биты MAC-48

24

MA-L

24

28

MA-M

20

36

MA-S

12

 

4 младших бита первого из 6 октетов 48-битового MAC имеют особое значение и называются далее битами M, X, Y, Z (рисунок 1).

  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  Z  Y  X  M| .  .  .  .  .  .  .  .| октеты 0+1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  .  .  .  .| .  .  .  .  .  .  .  .| октеты 2+3
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  .  .  .  .| .  .  .  .  .  .  .  .| октеты 4+5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Рисунок . Структура 48-битового MAC-адреса.


Для глобальных адресов X = 0 и MAC-адрес начинается с префикса размером 3 октета или больше, указывающего блок адресов MAC. За префиксом следуют дополнительные дополнительные биты3 до полного размера MAC-адреса. Например IEEE выделяет мелкий блок MAC (MA-S), где заданы первые 4 ½ октета (36 битов), а держателю MA-S оставлены полтора октета (12 битов), которые он может использовать для создания 48-битовых MAC-адресов. Префиксы могут иметь несколько размеров [IEEEtutorials].

Для 48-битовых MAC-адресов выделены теги AFN, DNS RRTYPE и CBOR, как указано в параграфах 2.4, 5.3 и 5.9.

В IEEE Std 802 описаны процедуры и правила выделения идентификаторов, связанных с IEEE 802 [IEEE802_OandA]. Документация IEEE RA по EUI, OUI и CID доступна в [IEEEtutorials].

2.1.1. Особые биты первого октета

В первом октете адреса IEEE MAC имебтся особые биты [IEEE802_OandA], описанные ниже.

M

Этот бит часто называют групповым или многоадресным (multicast). Для индивидуальных MAC-адресов бит сброшен (0). Установленный (1) бит означает многоадресную передачу (групповую или широковещательную). Значение бита не зависит от установки битов X, Y, Z.

X

Этот бит называют universal/local (универсальный/локальный), а раньше использовалось название Local/Global. Сброшенный (0) быт указывает глобальный MAC-адрес, контролируемый владельцем выделенного IEEE префикса. Ранее установка (1) этого бита указывала «локальный» адрес MAC, контролируемый местным оператором сети (см. также параграф 2.3). Если бит установлен и действует IEEE 802 SLAP, характер MAC-адреса может определяться битами Y и Z, как описано ниже.

Y и Z

Эти два бита не имеют особого значения при сброшенном (0) бите X. Если бит X и действует IEEE 802 SLAP, эти биты делят ранее единое пространство «локальных» адресов MAC на 4 квадранта, как описано ниже.

Таблица .

 

Бит Y

Бит Z

Квадрант

0

0

Назначен административно

0

1

Расширенный локальный адрес

1

0

Резерв

1

1

Назначен стандартом

 

Хотя локальный администратор может установить (1) бит X в любом адресе, необязательный план SLAP выделяет 4 квадранта для пространства «локальных» адресов с помощью битов Y и Z, как указано ниже

Administratively Assigned — назначен административно

MAC-адреса этого квадранта называют назначенными административно идентификаторами (Administratively Assigned Identifier). Они предназначены для произвольного локального распределения, например, случайного (см. также параграф 2.3.1).

Extended Local — расширенный локальный адрес

MAC-адреса этого квадранта называют расширенными локальными идентификаторами (Extended Local Identifier). Фактически они не являются «локальными» при использовании SLAP. Эти адреса доступны организации, которой выделен идентификатор CID (параграф 2.1.2), задающий другие 20 битов 24-битового префикса с X=1, Y=0 и Z = 1.

Reserved — резерв

MAC-адреса этого квадранта зарезервированы для будущего использования со SLAP4. До этого они могут распределяться локально (как Administratively Assigned Identifier), но при последующем использовании SLAP могут возникнуть конфликты с этим распределением.

Standard Assigned — назначен стандартом

MAC-адреса этого квадранта называют назначенными стандартом (Standard Assigned Identifier или SAI). SAI выделяются протоколом, заданным в стандартеiIEEE 802, например, [IEEE802.1CQ]5.

2.1.2. OUI и CID

Префиксы MA-L, MA-M и MA-S выделяются со сброшенным битом Local (X=0). Держатель OUI имеет исключительное право назначать групповые MAC-адреса, используя изменённый вариант назначенного OUI, где бит M = 1 (рисунок 1) [IEEEtutorials].

Бит Local (X) сброшен (0) для глобально уникальных идентификаторов EUI-48, назначаемых владельцем MAC-L или более длинного префикса. При установленном бите Local идентификатор исторически считается локальным и находящимся под контролем местного администратора сети. Однако в настоящее время имеются рекомендации по необязательному управлению локальным пространством адресов, как описано в параграфе 2.1.1. Если бит Local установлен (1), владелец OUI не имеет особых полномочий для идентификаторов MAC, где три первых октета соответствуют его OUI или началу более длинного префикса.

CID является 24-битовым идентификатором компании и выделяется нуждающимся в таких идентификаторах организациям. Этот идентификатор можно применять вместо OUI, но не требуется назначать дочерние глобальные адреса MAC. В CID биты X и Z установлены (1), а бит Y сброшен в 0 (см. рисунок 1).

Для идентификаторов OUI и CID назначены теги AFN и CBOR, как описано в параграфах 2.4, 5.3, 5.9.

2.1.3. Назначение 48-битовых MAC в иерархии IANA OUI

OUI 00-00-5E назначен IANA, как указано в параграфе 1.3. Это включает 224 48-битовых групповых идентификаторов от 01-00-5E-00-00-00 до 01-00-5E-FF-FF-FF и 224 индивидуальных EUI-48 от 00-00-5E-00-00-00 до 00-00-5E-FF-FF-FF. Эти идентификаторы разделены на субблоки, как описано ниже.

Индивидуальные (unicast) блоки по 28 адресов

00-00-5E-00-00-00 — 00-00-5E-00-00-FF — резерв, распределяемый по процедуре IESG Ratification (параграф 5.1).
00-00-5E-00-01-00 — 00-00-5E-00-01-FF — выделен для протокола VRRP [RFC5798].
00-00-5E-00-02-00 — 00-00-5E-00-02-FF — выделен для протокола IPv6 VRRP [RFC5798].
00-00-5E-00-52-00 — 00-00-5E-00-52-FF — используется для мелких блоков (на 2024 г. выделены 4 блока из 256). См. [EthernetNum].
00-00-5E-00-53-00 — 00-00-5E-00-53-FF — используется для документации в соответствии с эти документом.
00-00-5E-90-01-00 — 00-00-5E-90-01-FF — используется для мелких блоков, где нужны индивидуальные и групповые MAC-адреса (на 2024 г. выделено 1 из 256 значений). См. [EthernetNum].

Групповые (multicast)

01-00-5E-00-00-00 — 01-00-5E-7F-FF-FF — 223 адресов для IPv4 multicast [RFC1112].
01-00-5E-80-00-00 — 01-00-5E-8F-FF-FF — 220 адресов для MPLS multicast [RFC5332].
01-00-5E-90-00-00 — 01-00-5E-90-00-FF — 28 адресов для мелких блоков (на 2024 г. выделены 4 блока из 256). См. [EthernetNum].
01-00-5E-90-01-00 — 01-00-5E-90-01-FF — используется для мелких блоков, где нужны индивидуальные и групповые MAC-адреса (на 2024 г. выделено 1 из 256 значений). См. [EthernetNum].
01-00-5E-90-10-00 — 01-00-5E-90-10-FF — 28 адресов для документации в соответствии с эти документом.

Более подробные и актуальные сведения представлены в реестре IANA OUI Ethernet Numbers [EthernetNum].

2.1.4. Значения 48-битовых адресов MAC для документации

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

  • 00-00-5E-00-53-00 — 00-00-5E-00-53-FF для индивидуальных адресов.

  • 01-00-5E-90-10-00 — 01-00-5E-90-10-FF для групповых адресов.

2.1.5. Вопросы распределения 48-битовых IANA MAC

Назначения 48-битовых адресов в иерархии текущего и будущих IANA OUI (см. параграф 5.6) должны соответствовать приведённым ниже требованиям.

  • Назначение для стандартных целей (IETF Standard или иные стандарты, связанные с IETF).

  • Выделение блоков размером в степень 2, начиная с границы, равной или большей степени 2, включая выделение одного (20) идентификатора.

  • Использование для обхода требования к производителям сетевых интерфейсов получать свой блок от IEEE.

  • Документирование в Internet-Draft или RFC.

Кроме того, выделение должно быть одобрено (см. процедуры в параграфе 5.1):

  • для мелких и средних блоков из 1, 2, 4, …, 32768, 65536 (20, 21, 22, …, 215, 216) идентификатора EUI-48 по процедуре Expert Review (параграф 5.1).

  • для больших блоков из 131072 (217) и более адресов EUI-48 по процедуре IESG Ratification ( параграф 5.1).

2.2. 64-битовые идентификаторы MAC

В IEEE определены 64-битовые идентификаторы MAC, включая EUI-64, которые применяются:

  • в IEEE Std 1394 [IEEE1394] (называется также FireWire и i.Link);

  • в IEEE Std 802.15.4 [IEEE802.15.4] ( называется также Zigbee);

  • в [InfiniBand];

  • в изменённой форме для создания некоторых идентификаторов интерфейсов IPv6, как описано в параграфе 2.2.1, хотя сейчас это признано устаревшим.

Добавление 5-октетного (40 юитов) расширения к 3-октетному (24 бита) OUI или более короткое расширение более длинного префикса [RAC_OUI], чтобы в сумме получилось 64 бита, создаёт EUI-64 битовый идентификатор в рамках OUI или более длинного префикса. Первый октет имеет особые биты, как и в идентификаторах EUI-48.

Для 64-битовых MAC-адресов выделены теги AFN, DNS RRTYPE и CBOR, как описано в параграфах 2.4, 5.3 и 5.9.

Далее рассматривается в основном «изменённая» форма идентификаторов EUI-64, однако те, кому такой идентификатор выделен, могут применять не изменённую форму MAC на любом канале, где 64-битовые идентификаторы применяются для интерфейсов.

2.2.1. Использование изменённых идентификаторов EUI-64 в IPv6

Описанный ниже подход к созданию идентификаторов IPv6 для интерфейсов в настоящее время признан устаревшим и взамен рекомендуется использовать метод, описанный в [RFC8064].

Идентификаторы EUI-64 служат в качестве 64 младших битов некоторых адресов IPv6 (параграф 2.5.1 и Приложение A к [RFC4291], Приложение A к [RFC5214]). При таком использовании EUI-64 бит X (universal/local) инвертируется для формирования «идентификатора Modified EUI-64» IETF. Примером изменённого индивидуального идентификатора EUI-64 в рамках IANA OUI может служить 02-00-5E-aa-bb-cc-dd-ee, где aa-bb-cc-dd-ee — это расширение. Первый октет имеет значение 02, а не 00, поскольку в изменённых EUI-64 бит X инвертируется по сравнению с EUI-48. Бит 0x02 (X или universal/local) в первом октете имеют уникальные в глобальном масштабе идентификаторы, тогда как идентификаторы со сброшенным (0) битом назначаются локально и не подлежат глобальному управлению. Бит X (universal/local) инвертирован для упрощения ввода идентификаторов локального действия администраторами сетей. В результате изменённые идентификаторы EUI-64 вида 1, 2 и т. д. (нули в начале не показаны) являются локальными. Без этого изменения локальные идентификаторы бы имели вид 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02 и т. д.

Как и в 48-битовых MAC бит M (0x01) в первом октете указывает групповой или широковещательны идентификатор.

Когда первые два октета расширения изменённого идентификатора EUI-64 имеют значение FF-FE, остальное расширение является 24-битовым значением, заданным владельцем OUI для EUI-48. Например, в идентификаторах 02-00-5E-FF-FE-yy-yy-yy и 03-00-5E-FF-FE-yy-yy-yy октеты yy-yy-yy являются частью (глобального индивидуального или группового идентификатора EUI-48), назначенной владельцем OUI (в данном случае IANA). Таким образом, держатель одного или множества идентификаторов EUI-48 в рамках IANA OUI имеет равное число изменённых идентификаторов EUI-64, которые могут формироваться вставкой FF-FE в середину идентификаторов EUI-48 и инвертированием бита X.

Некоторые изменённые идентификаторы EUI-64 в рамках IANA OUI зарезервированы для держателей адресов IPv4. Например, в 02-00-5E-FE-xx-xx-xx-xx октеты xx-xx-xx-xx указывают 32-битовый адрес IPv4. Владелец адреса IPv4 получает индивидуальный и групповой адрес EUI-64 address. Изменённые идентификаторы EUI-64 из диапазона от 02-00-5E-FE-F0-00-00-00 до 02-00-5E-FE-FF-FF-FF-FF фактически зарезервированы в ожидании спецификации адресов IPv4 класса E [RFC1112]. Однако в изменённых идентификаторах EUI-64 на основе адреса IPv4 бит universal/local следует устанавливать в соответствии с локальным или глобальным характером адреса IPv4, не забывая о том, что трактовка этого бита в изменённых идентификаторах EUI-64 обратна по отношению к обычным (неизменным) EUI-64.

2.2.2. Вопросы назначения IANA EUI-64

В таблице 3 показано распределение идентификаторов Modified EUI-64 в рамках IANA OUI. Как отмечено выше, соответствующие MAC-адреса могут формироваться добавлением бита 02 к первому октету. Во всех случаях соответствующие групповые 64-битовые адреса MAC, созданные путём добавления к первому октету бита 01, имеют такой же статус, как и указанные в таблице блоки 64-битовых индивидуальных адресов. Значения применяются с префиксом 02-00-5E для формирования изменённых адресов EUI-64.

Таблица . 64-битовые MAC-адреса IANA.

 

Адреса

Применение

Документ

00-00-00-00-00 — 0F-FF-FF-FF-FF

Резерв

RFC 9542

10-00-00-00-00 — 10-00-00-00-FF

Документация

RFC 9542

10-00-00-01-00 — EF-FF-FF-FF-FF

Не выделены

FD-00-00-00-00 — FD-FF-FF-FF-FF

Резерв

RFC 9542

FE-00-00-00-00 — FE-FF-FF-FF-FF

Держатели адресов IPv4

RFC 9542

FF-00-00-00-00 — FF-FD-FF-FF-FF

Резерв

RFC 9542

FF-FE-00-00-00 — FF-FE-FF-FF-FF

IANA EUI-48

RFC 9542

FF-FF-00-00-00 — FF-FF-FF-FF-FF

Резерв

RFC 9542

 

Выделения указанных в таблице резервных идентификаторов выполняется по процедуре IESG Ratification (параграф 5.1). Идентификаторы IANA EUI-64 в рамках IANA OUI выделяются в соответствии с указанными ниже требованиями.

  • Назначение для стандартных целей (IETF Standard или иные стандарты, связанные с IETF).

  • Выделение блоков размером в степень 2, начиная с границы, равной или большей степени 2, включая выделение одного (20) идентификатора.

  • Использование для обхода требования к производителям сетевых интерфейсов получать свой блок от IEEE.

  • Документирование в Internet-Draft или RFC.

Кроме того, выделение должно быть одобрено (см. процедуры в параграфе 5.1):

  • для мелких и средних блоков из 1, 2, 4, …, 134217728, 268435456 (20, 21, 22, …, 227, 228) идентификатора EUI-64 по процедуре Expert Review (параграф 5.1).

  • для больших блоков из 536870912 (229) и более адресов EUI-64 по процедуре IESG Ratification ( параграф 5.1).

2.2.3. Значения EUI-64 для документации

Ниже приведены блоки неизмененных 64-битовых адресов MAC для использования в документации. Полученные из IPv4 адреса основаны на адресах IPv4 для документации [RFC5737], а полученные из MAC — на описанных выше адресах EUI-48 для документации.

Индивидуальные адреса для документации

00-00-5E-EF-10-00-00-00 — 00-00-5E-EF-10-00-00-FF — общее назначение.
00-00-5E-FE-C0-00-02-00 — 00-00-5E-FE-C0-00-02-FF, 00-00-5E-FE-C6-33-64-00 — 00-00-5E-FE-C6-33-64-FF и 00-00-5E-FE-CB-00-71-00 — 00-00-5E-FE-CB-00-71-FF — основаны на IPv4.
00-00-5E-FF-FE-00-53-00 — 00-00-5E-FF-FE-00-53-FF — основаны на EUI-48.
00-00-5E-FE-EA-C0-00-02, 00-00-5E-FE-EA-C6-33-64 и 00-00-5E-FE-EA-CB-00-71 — групповые адреса IPv4 на основе индивидуальных адресов IPv4 [RFC6034].

Групповые адреса для документации

01-00-5E-EF-10-00-00-00 — 01-00-5E-EF-10-00-00-FF — общее назначение.
01-00-5E-FE-C0-00-02-00 — 01-00-5E-FE-C0-00-02-FF, 01-00-5E-FE-C6-33-64-00 — 01-00-5E-FE-C6-33-64-FF и 01-00-5E-FE-CB-00-71-00 — 01-00-5E-FE-CB-00-71-FF — основаны на IPv4.
01-00-5E-FE-EA-C0-00-02, 01-00-5E-FE-EA-C6-33-64 и 01-00-5E-FE-EA-CB-00-71 IPv4 — групповые адреса IPv4 на основе индивидуальных адресов IPv4 [RFC6034].
01-00-5E-FF-FE-90-10-00 — 01-00-5E-FF-FE-90-10-FF — основаны на EUI-48.

2.3. Другие 48-битовые идентификаторы MAC, применяемые IETF

Ниже описаны ещё два блока 48-битовых адресов MAC, используемые IETF.

2.3.1. Идентификаторы с префиксом 33-33

Все 48-битовые идентификаторы MAC с префиксом 33-33 (232 групповых идентификатора MAC из диапазона 33-33-00-00-00-00 — 33-33-FF-FF-FF-FF) используются в соответствии с [RFC2464] для группового обмена IPv6. Во всех этих идентификаторах бит Group (последний в первом октете) установлен (1), как это требуется для корректной работы в качестве группового идентификатора с имеющимся оборудованием. Установлен (1) также бит Local, но в Ethernet со стандартной групповой адресацией IPv6 нужно учитывать такое использование адресов. Эти групповые MAC-адреса относятся к квадранту административно назначаемых адресов SLAP (параграф 2.1.1).

Историческое замечание. При разработке IPv6 было принято использовать цифру 3 для неизвестных значений и примеров, 3333 Coyote Hill Road, Palo Alto, California — это адрес исследовательского центра Palo Alto (Palo Alto Research Center или PARC), ранее называвшегося Xerox PARC. Спецификация Ethernet была разработана Digital Equipment Corporation, Intel Corporation и Xerox Corporation. До IEEE [IEEE.802.3_2012] протокол Ethernet иногда называли DIX Ethernet по первым буквам названий этих компаний.

2.3.2. Серия CF

В информационном [RFC2153] 3-октетные значения CF-00-00 — CF-FF-FF объявлены как OUI, доступные для распределения IANA производителям программ для использования с PPP [RFC1661] или иных применений, где не требуется OUI от IEEE. При использовании в качестве 48-битовых префиксов MAC в этих значениях особые биты Z, Y, X (Local) и M (Group) в конце первого октета будут иметь значение 1, тогда как в выделенных IEEE идентификаторах OUI биты X и M сброшены (0), а во всех CID сброшены биты Y и M. Таким образом, конфликтов между OUI серии CF и выделенными IEEE значениями OUI/CID не возникает. Групповые MAC-адреса, созданные с OUI серии CF, попадают в квадрант SLAP Standard Assigned (параграф 2.1.1). Бит Group не имеет значения для PPP. В [RFC2153] сказано «Серия CF0000 была выбрана для удобства запоминания, чтобы соответствовать PPP NLPID ‘CF’». Дополнительные сведения об идентификаторах протоколов сетевого уровня (Network Layer Protocol Identifier или NLPID) приведены в [RFC6328].

CF-00-00 является зарезервированным, CF-00-00-00-00-00 — групповой идентификатор указанный IANA как используемый для шлейфовых тестов Ethernet.

За срок более 10 лет было выделено лишь несколько значений из серии CF, указанных в реестрах IANA OUI Ethernet Numbers» [EthernetNum] и Point-to-Point (PPP) Protocol Field Assignments [PPPNum].

2.3.2.1. Отличия от RFC 2153

Раздел «Взаимодействие с IANA» [RFC2153] обновлён после одобрения [RFC5342] и остаётся в этом состоянии (нет технических изменений).

  • Использование идентификаторов серии CF, выделяемых IANA, отменено.

  • Агентству IANA предписано в дальнейшем не выделять значений в серии CF.

2.4. Теги CBOR

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

Агентство IANA выделило значение 48 как тег CBOR для указания MAC-адреса. Приложенный к тегу элемент данных является строкой октетов, размер которой указывает, представлен ли 48-битовый (6 октетов) или 64-битовый (8 октетов) MAC-адрес. Если в будущем для размера адресов MAC будет применяться иное значение, кратное 8 битам, например 128 битов (16 октетов) использование тега 48 сохранится.

Тег CBOR 1048 выделен IANA для указания идентификаторов организаций OUI, CID или CF. Приложенный элемент данных является строкой из 3 октетов для размещения 24-битовых OUI и CID (параграф 2.1.2).

3. Параметры протокола Ethernet

Параметры протокола Ethernet позволяют указать в начале кадра его содержимое, например, пакет IPv4 или IPv6. Имеется два типа параметров идентификатора протокола [EthernetNum].

EtherType

16-битовый идентификатор, который при рассмотрении как целого числа без знака имеет значение не меньше 0x0600. На рисунке 2 показан простейший случай, где EtherType данных протокола в кадре указывается сразу после MAC-адресов отправителя и получателя. В [IEEE802_OandA] заданы два EtherType для локальных экспериментов — 0x88B5 и 0x88B6.
  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Destination MAC Address                     ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Source MAC Address                          ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  EtherType (не меньше 0x0600)                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Protocol Data                               ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Рисунок . Маркировка EtherType.


LSAP

Это 8-битовые идентификаторы протокола, размещаемые парой после поля, указывающего размер кадра. Это размер должен быть меньше 0x5DD (при рассмотрении как целого числа без знака), иначе его можно ошибочно принять за EtherType. Однако вместо размера может использоваться инкапсуляция LLC с EtherType = 0x8870 [IEEE802.1AC] в качестве индикатора незаданного размера. Значение LSAP указываются парами, где один элемент указывает обработчик протокола на стороне источника (SSAP), другой — на стороне получателя (DSAP), однако на практике разные значения этих элементов встречаются сравнительно редко. На рисунке 3 показан простейший случай, где поле размера указано сразу после MAC-адресов отправителя и получателя. На этом рисунке поле CTL (control) со значением 3 указывает службу дейтаграмм. Такой тип указания протокола иногда называют управлением логическим каналом (Logical Link Control или LLC).
  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Destination MAC Address                     ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Source MAC Address                          ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Frame length (или 0x8870)                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  DSAP                 |  SSAP                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  CTL = 0x03           |  Protocol Data       ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Рисунок . Маркировка LSAP.


Концепция маркировки EtherType была расширена для маркировки «тегами» Ethernet. Тег Ethernet в этом смысле является префиксом, тип которого указан EtherType, за которым следует другой тег, EtherType или индикатор протокола точки доступа к сервису канального уровня (LLC Link-Layer Service Access Point или LSAP) для «основного» тела кадра. Обычно в среде [IEEE802_OandA] теги имеют фиксированный размер и не включают кодирования своего размера, Например, C-Tag (ранее Q-Tag) [IEEE.802.1Q_2014] указывает для кадра VLAN клиента и приоритет. Обрабатывающее кадр устройство в общем случае не может безопасно обрабатывать что-либо в кадре после непонятного EtherType.

Значения EtherType и LSAP не выделяются IANA, их назначает IEEE RA [IEEE_RA] (см. параграф 1.2 и Приложение B). Однако для LSAP и EtherType имеются механизмы расширения, позволяющие использовать их с 5-октетными идентификаторами протокола Ethernet в рамках OUI, включая назначенные IANA в иерархии IANA OUI.

При использовании для кадра формата IEEE 802 LLC format (Subnetwork Access Protocol (SNAP)) [IEEE802_OandA] идентификатор протокола на основе OUI можно выразить в форме xx-xx-AA-AA-03-yy-yy-yy-zz-zz, где xx-xx — размер кадра (см. выше), который должен быть достаточно малым, чтобы не путаться с EtherType, AA — октет LSAP, указывающий такое применение и иногда называемый точкой доступа к услугам SNAP (SNAP Service Access Point или SNAP SAP), 03 — октет управления LLC, указывающий службу дейтаграмм, yy-yy-yy — OUI, а zz-zz — номер протокола в рамках OUI, назначенный владельцем OUI. 5-октетный размер таких идентификаторов протокола на основе OUI с октетом управления LLC (0x03) обеспечивает выравнивание по 16-битовой границе.

При использовании EtherType для указания основного типа тела кадра доступен особый тип 0x88B7 (OUI Extended EtherType). В этом случае тело кадра может начинаться с последовательности 88-B7-yy-yy-yy-zz-zz, где yy-yy-yy и zz-zz имеют такой же смысл, как в описанном выше формате SNAP, однако для формате с EtherType = 0x88B7 не сохраняется выравнивание по 16-битовым границам.

В формате SNAP возможно использование произвольного EtherType. Это делается указанием EtherType в поле zz-zz после OUI, содержащего лишь нули (00-00-00), и имеет вид xx-xx-AA-AA-03-00-00-00-zz-zz, где zz-zz — EtherType.

Помимо маркировки содержимого кадра, тип протокола IEEE 802 указывается в сообщениях протокола распознавания следующего узла (Next Hop Resolution Protocol) [RFC2332] сетей с множественным доступом без широковещания (Non-Broadcast Multi-Access или NBMA). В таких сообщениях предусмотрены 2-октетные EtherType и типы протокола на основе OUI. 16-битовые значения EtherType присутствуют также в заголовках базовой маршрутной инкапсуляции (Generic Routing Encapsulation или GRE) [RFC2784] и базовой инкапсуляции для виртуализации сетей (Generic Network Virtualization Encapsulation или Geneve) [RFC8926].

3.1. Назначение протоколов Ethernet в иерархии IANA OUI

Доступны 2-октетные номера протоколов в рамках IANA OUI. Например, в 88-B7-00-00-5E-qq-qq или xx-xx-AA-AA-03-00-00-5E-qq-qq поле qq-qq указывает номер протокола..

Было выделено несколько значения из 216 номеров протоколов диапазона 00-00-5E-00-00 — 00-00-5E-FF-FF (см. [EthernetNum]). Крайние значения 00-00-5E-00-00 и 00-00-5E-FF-FF зарезервированы и для их назначения требуется процедура IESG Ratification (см. параграф 5.1). Назначения номеров протокола (qq-qq) в рамках IANA OUI должны удовлетворять приведённым ниже требованиям.

  • Использование в стандарте (IETF Standard или иной стандарт, связанный с работой IETF).

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

  • Документирование в Internet-Draft или RFC.

  • Протокол не имеет EtherType (значение EtherType моет использоваться напрямую или, в случае LSAP, — вместе с SNAP SAP путём размещения OUI 00-00-00 перед EtherType, как описано выше).

Кроме того, для выделения значений должна использоваться процедура Expert Review (или IESG Ratification для зарезервированных значений), как описано в параграфе 5.1.

3.2. Номер протокола для документации

Номер протокола 0x0042 в рамках IANA OUI (т. е. 00-00-5E-00-42) выделен для использования в документации.

4. Другие параметры на основе OUI/CID

В некоторых протоколах IEEE 802 и др. предусмотрены основанная на OUI или CID параметры, помимо описанных выше. Такие параметры обычно включают OUI или CID, а также 1 октет дополнительного значения. Они называются фирменными (Organizationally Specific) параметрами, а иногда (менее точно), параметрами производителя (vendor specific). Параметры имеют вид yy-yy-yy-zz, где yy-yy-yy — OUI или CID, а zz — дополнительное значение. Примером такого параметра является селектор шифра (Cipher Suite Selector) [IEEE.802.11_2012].

Значения могут выделяться в рамках IANA OUI для других параметров на основе OUI по процедуре Expert Review, за исключением того, что для дополнительных значения, содержащих только 0 (00-00-5E-00) или только 1 (00-00-5E-FF), применяется процедура IESG Ratification (параграф 5.1), а дополнительное значение 0x42 (00-00-5E-42), дополненное нулями справа для выравнивания, служит для примеров в документации.

Значения параметров на основе IANA OUI должны выделяться для стандартов (IETF Standard или иной стандарт, связанный с IETF) и документироваться в Internet-Draft или RFC. При первоначальном выделении значения для конкретного параметра создаётся реестр IANA, включающий это значение, а также последующие значения этого параметра в рамках IANA OUI. Эксперт может задать имя для такого реестра. Если для такого параметра нужны правила, отличающиеся от приведённых выше, следует подготовить (обновить) RFC со статусом BCP или Standards Track RFC с указанием новых правил и параметра.

4.1. Тип TLV для IETF LLDP

Пример такого параметра на основе IANA OUI представлен в [RFC8520]. Он включает тип Organizationally Specific TLV для анонсирования унифицированного идентификатора ресурса (Uniform Resource Locator или URL) описания использования от производителя (Manufacturer Usage Description или MUD) в протоколе IEEE для обнаружения канального уровня (Link Local Discovery Protocol или LLDP) [IEEE802.1AB]. Дополнительно в IETF предложено использование кодов из этого пространства [BGP11dp] (см. параграф 5.8.).

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

Этот документ касается взаимодействия с IANA по вопросам назначения параметров Ethernet в связи с IANA OUI и смежным вопросам.

Примечание. Группа реестров (web-страница) IANA OUI Ethernet Numbers предназначена для реестров значений в рамках IANA OUI, а группа реестров IEEE 802 Numbers содержит списки значений, выделенных IEEE RA.

Документ не создаёт новых реестров IANA и не меняет имеющихся назначений.

Значения MAC-адресов и номеров протоколов для документации выделены [RFC7042].

5.1. Expert Review и IESG Ratification

В этом параграфе заданы процедуры Expert Review и IESG Ratification для MAC, протоколов и других идентификаторов на основе IANA OUI. В качестве эксперта выступает один или несколько человек, назначенных и работающих по поручению IESG.

5.1.1. Рекомендации для Expert Review

Описанная здесь процедура Expert Review соответствует aIANA Expert Review из [RFC8126].

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

5.1.2. Процедуры Expert Review и IESG Ratification

Может иметь смысл выделение очень больших частей пространства идентификаторов MAC (в настоящее время выделено лишь 1 значение из пространства индивидуальных 48-битовых кодов IANA и 1 значение из 16 доступных в пространстве групповых кодов). В этих случаях, а также при выделении «резервных» значений требуется процедура IESG Ratification для Expert Review с одобрением запроса, как описано ниже. Это можно считать сочетанием процедур Expert Review и IESG Approval, заданных в [RFC8126]. Процедура IESG Approval требуется лишь в тех случаях, когда эксперты не отклоняют запрос. Сама процедура описана ниже.

Заявитель заполняет соответствующий шаблон из Приложения A и направляет его IANA по адресу <iana@iana.org>.

Агентство IANA передаёт шаблон назначенному эксперту. Если эксперт берет самоотвод или не отвечает на запрос, IANA может выбрать другого назначенного эксперта, а при его отсутствии — обратиться в IESG.

Если IANA получает неодобрение от эксперта, выбранного для рассмотрения шаблона заявки, эта заявка отклоняется. Эксперту следует указывать причину отклонения, которую IANA передаёт заявителю.

При использовании процедуры Expert Review

IANA выделяет запрошенные значения при получении одобрения и доступности запрошенных кодов.

При использовании процедуры IESG Ratification

Сначала выполняется процедура Expert Review. Если эксперты отклоняют запрос, они просто информируют IANA, а те — заявителя. Если же эксперты считают, что заявку следует одобрить, или имеются неясности и предположения о том, что следует привлечь внимание IESG, эксперты информируют IANA о своём мнении и IANA пересылает заявку вместе с мнениями экспертов в IESG. Окончательное решение о выделении значений или отказе должно приниматься IESG. Это может быть сделано через элемент управления в телечате IESG, как для других типов запросов. Если IESG не подтверждает положительное мнение экспертов или отклоняет заявку, для которой у экспертов нет уверенности, заявка отвергается. В иных случаях заявка одобряется. IESG информирует о своём решении экспертов и IANA. В случае отказа IESG следует указать его причину, которую IANA сообщает заявителю.

5.2. Смена имени группы реестров IANA (Web-страницы)

Для ясности и сходства с реестром IANA IEEE 802 Numbers группа реестров IANA Ethernet Numbers переименована в IANA OUI Ethernet Numbers.

Поскольку этот документ заменяет [RFC7042], ссылки на [RFC7042] в реестрах IANA IEEE 802 Numbers и IANA OUI Ethernet Numbers заменены ссылками на данный документ. В других реестрах IANA ссылки на [RFC7042] сохранены.

5.3. AFN и RRTYPE для MAC-адресов

Агентство IANA выделило значения Address Family Number (AFN) для MAC-адресов, как указано в таблице 4.

Таблица .

 

AFN

Десятичный

Шестнадцатеричный

Документ

48-битовый MAC

16389

0x4005

[RFC7042]

64-битовый MAC

16390

0x4006

[RFC7042]

OUI

16391

0x4007

[RFC7961]

Младшие 24 бита 48-битовых MAC-адресов — MAC/24

16392

0x4008

[RFC7961]

Младшие 40 битов 64-битовых MAC-адресов — MAC/40

16393

0x4009

[RFC7961]

 

Агентство IANA выделило значения DNS RRTYPE [RFC6895] для MAC-адресов, как указано в таблице 5.

Таблица .

 

Код RRTYPE

Данные

Обозначение

Десятичный

Шестнадцатеричный

Документ

48-битовый MAC

EUI48

108

0x006C

[RFC7043]

64-битовый MAC

EUI64

109

0x006D

[RFC7043]

 

5.4. Информационный материал группы реестров IANA

IANA поддерживает группу реестров, в настоящее время реализованную в форме web-страницы, для EtherType, OUI и групповых адресов, выделенных в рамках OUI, отличных от IANA OUI. Эта группа называется IEEE 802 Numbers. IANA обновляет сведения в реестрах при изменениях и одобрении значений экспертами.

5.5. Процесс назначения EtherType

Подача в IEEE RA заявки на выделение EtherType для протокола IETF требует процедуры IESG Approval, как указано в Приложении B. Для снижения путаницы этот процесс обычно выполняет главный эксперт реестра EtherType в группе IEEE 802 Numbers, как описано ниже (см. также параграф 5.4).

После IESG Approval для запроса EtherType IESG следует передать этот вопрос в IANA. В любом случае IANA будет просить эксперта реестра EtherType выполнить процесс запроса EtherType в IEEE RA [IEEE_RA]. Этот путь указан потому, что IESG обычно имеет дело с IANA для действий по выделению значений, а IANA следует знать, кто из экспертов реестра EtherType доступен (обычно запрос на выделение EtherType передаётся основному эксперту).

Ниже приведён примерный текст Internet-Draft, где требуется назначение от IANA и IEEE. Шаблон YYY заменяется разъяснением, для чего (почему) требуется EtherType с достаточным уровнем детализации, и обычно включает ссылки на соответствующие части Internet-Draft.

X. Assignment Considerations (вопросы назначение).

X.1. IEEE Assignment Considerations (вопросы назначения в IEEE).

IESG предлагается одобрить передачу в IEEE RA запроса на EtherType для YYY (IESG следует сообщить о свом одобрении в IANA и связанным с документом лицам; IANA пересылает IESG Approval эксперту реестра EtherType из группы IEEE 802 Numbers, который передаёт заявку в IEEE RA, информируя об этом IANA).

X.2. IANA Considerations (взаимодействие с IANA).

5.6. Исчерпание OUI

При исчерпании пространства индивидуальных или групповых идентификаторов EUI-48 в рамках OUI 00-00-5E на 90% и более IANA следует запросить в IEEE RA дополнительный идентификатор OUI для последующих назначений IANA. Назначенным экспертам следует контролировать распределение идентификаторов и информировать IANA о его исчерпании.

5.7. Таблица MAC-адресов IANA OUI

Этот документ вносит указанные ниже изменения в примечания к реестрам IANA Unicast 48-bit MAC Addresses, IANA Multicast 48-bit MAC Addresses и IANA 64-bit MAC Addresses. Кроме того, в этих реестрах обновляются ссылки, как указано в параграфе 5.2.

В Примечания к IANA Unicast 48-bit MAC Addresses и IANA Multicast 48-bit MAC Addresses вносится следующее изменение:

Эти значения используют префикс 00-00-5E (см. параграф 2.1.3 в RFC 9542).

В Примечания к IANA 64-bit MAC Addresses вносится следующее изменение:

Эти значения используют префикс 00-00-5E для формирования индивидуальных MAC-адресов и 01-00-5E — для групповых, а также префикс 02-00-5E для индивидуальных изменённых адресов EUI-64 и 03-00-5E — для групповых. Дополнительные сведения представлены в RFC 9542, в частности, в параграфе 2.2.2.

5.8. Субтипы IANA LLDP TLV

Агентство IANA перенесло реестр IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes из группы IEEE 802 Numbers в группу IANA OUI Ethernet Numbers, поскольку коды в этом реестре назначаются IANA. Кроме того, в реестр добавлена ссылка на RFC 9542. Обновлены также три записи этого реестра, как показано в таблице 6.

Таблица .

 

Значение

Описание

Документ

0

Резерв

RFC 9542

42

Пример для использования в документации

RFC 9542

255

Резерв

RFC 9542

 

Записи для значений 1 (MUD), 2-41 (не выделены) и 43-254 (не выделены) не изменились.

5.9. Назначение тегов CBOR

Агентство IANA выделило два тега CBOR Tags в реестре Concise Binary Object Representation (CBOR) Tags (таблица 7).

Таблица .

 

Тег

Элемент данных

Назначение

Документ

48

Строка байтов

Адрес IEEE MAC

RFC 9542

1048

Строка байтов

IEEE OUI/CID

RFC 9542

 

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

Этот документ посвящено назначению параметров IEEE 802, переданных в IANA (в частности, в рамках IANA OUI), и тесно связанным с этим вопросам. Документ не оказывает прямого влияния на безопасность, за исключением указанного ниже.

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

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

MAC-адрес идентифицирует физический или виртуальный интерфейс и может применяться для отслеживания устройства с этим интерфейсом, а, следовательно, и пользователей такого устройства. В [madinas] рассматриваются связанные с этим вопросы приватности, а также обсуждается применение случайных MAC-адресов для частичного снижения такой угрозы. В [RFC7043] рассматриваются вопросы безопасности и приватности при публикации MAC-адресов в DNS.

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

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

[IEEE.802.1Q_2014] IEEE, «IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks», IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, 18 December 2014, <http://ieeexplore.ieee.org/servlet/opac?punumber=6991460>.

[IEEE802.1AB] IEEE, «IEEE Standard for Local and metropolitan area networks — Station and Media Access Control Connectivity Discovery», IEEE Std 802.1AB-2016, DOI 10.1109/IEEESTD.2016.7433915, March 2016, <https://doi.org/10.1109/IEEESTD.2016.7433915>.

[IEEE802_OandA] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.

IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture — Amendment 2: Local Medium Access Control (MAC) Address Usage», IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, <https://doi.org/10.1109/IEEESTD.2017.8016709>.

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

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

[BGP11dp] Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, «BGP Logical Link Discovery Protocol (LLDP) Peer Discovery», Work in Progress, Internet-Draft, draft-acee-idr-lldp-peer-discovery-17, 4 January 2024, <https://datatracker.ietf.org/doc/html/draft-acee-idr-lldp-peer-discovery-17>.

[EthernetNum] IANA, «IANA OUI Ethernet Numbers», <https://www.iana.org/assignments/ethernet-numbers>.

[IANA] IANA, «Internet Assigned Numbers Authority», <https://www.iana.org>.

[IEEE] IEEE, «Institute of Electrical and Electronics Engineers», <https://www.ieee.org>.

[IEEE.802.11_2012] IEEE, «IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, 5 April 2012, <http://ieeexplore.ieee.org/servlet/opac?punumber=6178209>.

[IEEE.802.3_2012] IEEE, «IEEE Standard for Ethernet», IEEE 802.3-2012, DOI 10.1109/ieeestd.2012.6419735, 24 January 2013, <http://ieeexplore.ieee.org/servlet/opac?punumber=6419733>.

[IEEE1394] IEEE, «IEEE Standard for a High-Performance Serial Bus», IEEE Std 1394-2008, DOI 10.1109/IEEESTD.2008.4659233, October 2008, <https://doi.org/10.1109/IEEESTD.2008.4659233>.

[IEEE802] IEEE 802, «IEEE 802 LMSC», <https://www.ieee802.org>.

[IEEE802.15.4] IEEE, «IEEE Standard for Low-Rate Wireless Networks», IEEE Std 802.15.4-2020, DOI 10.1109/IEEESTD.2020.9144691, July 2020, <https://doi.org/10.1109/IEEESTD.2020.9144691>.

[IEEE802.1AC] IEEE 802, «IEEE Standard for Local and metropolitan area networks — Media Access Control (MAC) Service Definition», IEEE Std 802.1AC-2016, DOI 10.1109/IEEESTD.2017.7875381, March 2017, <https://doi.org/10.1109/IEEESTD.2017.7875381>.

[IEEE802.1CQ] IEEE, «Draft Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment», draft 0.8, IEEE Std 802.1CQ/D0.8, July 2022.

[IEEEtutorials] IEEE, «Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)», August 2017, <https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf>.

[IEEE_RA] IEEE, «Registration Authority», <https://standards.ieee.org/products-programs/regauth/>.

[IEEE_SA] IEEE, «IEEE Standards Association», <https://standards.ieee.org>.

[InfiniBand] InfiniBand Trade Association, «InfiniBand Architecture Specification Volume 1», November 2007, <https://www.infinibandta.org/>.

[madinas] Zúñiga, JC., Bernardos, CJ., Ed., and A. Andersdotter, «Randomized and Changing MAC Address state of affairs», Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-12, 28 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-12>.

[PPPNum] IANA, «Point-to-Point (PPP) Protocol Field Assignments», <https://www.iana.org/assignments/ppp-numbers>.

[RAC_OUI] Parsons, G., «OUI Registry Restructuring», Work in Progress, Internet-Draft, draft-ieee-rac-oui-restructuring-01, 9 September 2013, <https://datatracker.ietf.org/doc/html/draft-ieee-rac-oui-restructuring-01>.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1661] Simpson, W., Ed., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <https://www.rfc-editor.org/info/rfc1661>.

[RFC2153] Simpson, W., «PPP Vendor Extensions», RFC 2153, DOI 10.17487/RFC2153, May 1997, <https://www.rfc-editor.org/info/rfc2153>.

[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, «NBMA Next Hop Resolution Protocol (NHRP)», RFC 2332, DOI 10.17487/RFC2332, April 1998, <https://www.rfc-editor.org/info/rfc2332>.

[RFC2464] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.

[RFC2606] Eastlake 3rd, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <https://www.rfc-editor.org/info/rfc2606>.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.

[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, «Etymology of «Foo»», RFC 3092, DOI 10.17487/RFC3092, April 2001, <https://www.rfc-editor.org/info/rfc3092>.

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

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)», RFC 5214, DOI 10.17487/RFC5214, March 2008, <https://www.rfc-editor.org/info/rfc5214>.

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, «MPLS Multicast Encapsulations», RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.

[RFC5342] Eastlake 3rd, D., «IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters», RFC 5342, DOI 10.17487/RFC5342, September 2008, <https://www.rfc-editor.org/info/rfc5342>.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

[RFC6034] Thaler, D., «Unicast-Prefix-Based IPv4 Multicast Addresses», RFC 6034, DOI 10.17487/RFC6034, October 2010, <https://www.rfc-editor.org/info/rfc6034>.

[RFC6328] Eastlake 3rd, D., «IANA Considerations for Network Layer Protocol Identifiers», BCP 164, RFC 6328, DOI 10.17487/RFC6328, July 2011, <https://www.rfc-editor.org/info/rfc6328>.

[RFC6895] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

[RFC7042] Eastlake 3rd, D. and J. Abley, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.

[RFC7043] Abley, J., «Resource Records for EUI-48 and EUI-64 Addresses in the DNS», RFC 7043, DOI 10.17487/RFC7043, October 2013, <https://www.rfc-editor.org/info/rfc7043>.

[RFC7319] Eastlake 3rd, D., «IANA Considerations for Connectivity Fault Management (CFM) Code Points», BCP 191, RFC 7319, DOI 10.17487/RFC7319, July 2014, <https://www.rfc-editor.org/info/rfc7319>.

[RFC7961] Eastlake 3rd, D. and L. Yizhou, «Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV», RFC 7961, DOI 10.17487/RFC7961, August 2016, <https://www.rfc-editor.org/info/rfc7961>.

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

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8520] Lear, E., Droms, R., and D. Romascanu, «Manufacturer Usage Description Specification», RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.

[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., «Geneve: Generic Network Virtualization Encapsulation», RFC 8926, DOI 10.17487/RFC8926, November 2020, <https://www.rfc-editor.org/info/rfc8926>.

[RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, «Link-Layer Address Assignment Mechanism for DHCPv6», RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.

[RFC8948] Bernardos, CJ. and A. Mourad, «Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6», RFC 8948, DOI 10.17487/RFC8948, December 2020, <https://www.rfc-editor.org/info/rfc8948>.

[RFC8949] Bormann, C. and P. Hoffman, «Concise Binary Object Representation (CBOR)», STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

Приложение A. Шаблоны

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

A.1. Шаблон идентификатора или блока идентификаторов EUI-48/EUI-64

Applicant Name:

Applicant Email:

Applicant Telephone: (с указанием кода страны)

Use Name: (короткое имя параметра, например, Foo Protocol [RFC3092])

Document: (Internet-Draft или RFC со спецификацией применения идентификатора или блока идентификаторов)

Specify whether this is an application for EUI-48 or EUI-64 identifiers:

Size of Block requested: (должен быть равен целой степени 2, включая 20)

Specify multicast, unicast, or both:

A.2. Шаблон номера протокола на основе IANA OUI/CID

Applicant Name:

Applicant Email:

Applicant Telephone: (с указанием кода страны)

Use Name: (короткое имя параметра, например, Foo Protocol)

Document: (Internet-Draft или RFC со спецификацией применения номера протокола)

Note: (любые дополнительные сведения)

A.3. Шаблон для других параметров на основе IANA OUI/CID

Applicant Name:

Applicant Email:

Applicant Telephone: (с указанием кода страны)

Protocol where the OUI/CID-Based Parameter for which a value is being requested appears: (например, выбор Cipher Suite в IEEE 802.11)

Use Name: (короткое имя для применения кода, например, Foo Cipher Suite» [RFC3092])

Document: ( Internet-Draft или RFC со спецификацией применения параметра на основе IANA OUI)

Note: (любые дополнительные сведения)

Приложение B. EtherType

В этом приложении представлена копия заявления IESG (1 мая 2023 г.) о получении новых IETF EtherType (B.1). Отметим, что имеется информационный реестр IANA для некоторых важных EtherType, заданных для протоколов IETF или IEEE 802 [IANA]. Может быть полезна также страница IEEE RA для EtherType (см. раздел 3) <https://standards.ieee.org/regauth/ethertype/eth.txt>.

B.1. Заявление IESG для EtherType

From: IESG

Date: 1 May 2023

Регистрационное агентство IEEE (IEEE RA) под надзором IEEE Registration Authority Committee (IEEE RAC) выделило значения EtherType (см. https://standards.ieee.org/products-programs/regauth/ethertype/). В спецификациях некоторых протоколов IETF применяются значения EtherType. Все случаи применения EtherType подлежат техническому рецензированию IEEE RA на предмет соответствия правилам.

Поскольку ресурс EtherType достаточно ограничен, IEEE RAC сообщает, что не будет выделять новых EtherType для спецификаций протоколов IETF, пока IESG не одобрит спецификацию протокола для публикации как RFC. В исключительных случаях IEEE RA может рассмотреть раннее выделение EtherType для находящегося в разработке протокола IETF при получении запроса, одобренного IESG.

Для информирования IEEE RAC об одобрении IESG запроса на выделение параметров Ethernet для протокола IETF все будущие запросы EtherType для протоколов IETF будут направляться в IESG.

Отметим, что EtherType для локальных экспериментов были выделены IEEE 8026 для использования в процессе разработки и экспериментах.

Приложение C. Отличия от RFC 7042

Этот документ отменяет [RFC7042] и вносит указанные ниже изменения. Тем не менее, заполненный шаблон, на основе которого было выделено значение для протокола, основанное на IANA OUI, для использования в документации, сохраняется в соответствии с Приложением C к [RFC7042].

  • Добавлены сведения о префиксах EUI MA-M (28 битов) и MA-S (36 битов), выделяемых IEEE RA.

  • Добавлены сведения о разделении пространства «локальных» MAC-адресов на 4 квадранта в рамках SLAP [IEEE802_OandA].

  • Включено Заявление IESG Statement для EtherType (Приложение B.1) и более подробно описаны процедуры IETF для подачи заявок в IEEE RA на значения EtherType для использования в протоколах IETF (параграф 5.5).

  • Упомянуты коды IEEE 802 CFM, выделенные IETF ( параграф 1.4).

  • Упомянут элемент данных Organizationally Specific LLDP, выделенный в рамках IANA OUI, и создан реестр для будущих значений ( параграф 4.1).

  • Уточнены некоторые детали в параграфе 5.1 для процедур Expert Review и IESG Ratification.

  • Заданы теги CBOR для MAC-адресов и OUI/CID ( параграф 2.4).

  • Добавлено требование к полю версии для выделения номеров протоколов в рамках IANA OUI ( параграф 3.1).

  • Упомянуто использование EtherType в заголовках инкапсуляции Geneve [RFC8926] (раздел 3).

  • Добавлено сочетание процедур Expert Review и IESG Approval как часть процедуры IESG Ratification.

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

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

Для текущего документа: Carsten Bormann, Bob Hinden, рабочая группа IEEE 802.1, Éric Vyncke, Dale Worley, Amanda Baber.

Для [RFC7042] (отменен этим документом): David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, Dan Romascanu.

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

Donald E. Eastlake 3rd
Independent
2386 Panoramic Circle
Apopka, Florida 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com, donald.eastlake@futurewei.com
 
Joe Abley
Cloudflare
Amsterdam
The Netherlands
Phone: +31 45 56 36 34
Email: jabley@strandkip.nl
 
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Phone: +86-13809002299
Email: liyizhou@huawei.com

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3В оригинале некорректно говорится о дополнительных октетах, см. https://www.rfc-editor.org/errata/eid7952. Прим. перев.

4Tне существует автоматизированного способа определить, настроена ли локальная сеть на SLAP и/или работу в соответствии с ним.

5Хотя в SLAP используются MAC-адреса, назначаемые локальным протоколом из квадранта SAI м назначаемые протоколом, заданным в стандарте IEEE 802, использование SLAP не является обязательным. Локальные администраторы моут использовать положения протоколов IETF из [RFC8947] и [RFC8948], которые поддерживают распределение MAC-адресов в локальном пространстве MAC с использованием DHCPv6 [RFC8415] или иного протокола.

6IEEE Std 802. IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture.

Рубрика: RFC | Оставить комментарий

RFC 9568 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Internet Engineering Task Force (IETF)                         A. Lindem
Request for Comments: 9568                       LabN Consulting, L.L.C.
Obsoletes: 5798                                                 A. Dogra
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                               April 2024

Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Протокол резервирования виртуальных маршрутизаторов (VRRP) версии 3 для IPv4 и IPv6

PDF

Аннотация

Этот документ определяет версию 3 протокола резервирования виртуальных маршрутизаторов (Virtual Router Redundancy Protocol или VRRP) для IPv4 и IPv6. Документ заменяет собой RFC 5798, ранее задававший VRRP (версия 3). RFC 5798 отменил RFC 3768, задававший VRRP (версия 2) для IPv4. VRRP задаёт протокол выбора для динамического назначения ответственности за виртуальный маршрутизатор одному из маршрутизаторов VRRP в ЛВС. Маршрутизатор VRRP, контролирующий адреса IPv4 или IPv6, связанные с виртуальным маршрутизатором, (Virtual Router или VR) называется активным (Active Router или AR) и пересылает пакеты на эти адреса IPv4 или IPv6. На активных маршрутизаторах настраиваются виртуальные адреса IPv4 или IPv6, а резервные маршрутизаторы (Backup Router или BR) определяют семейство виртуальных адресов для анонсирования на основе версии протокола IP. Внутри маршрутизатора VRRP виртуальные маршрутизаторы для каждого из семейств адресов IPv4 и IPv6 независимы один от другого и всегда считаются отдельными экземплярами VR. Процесс выбора обеспечивает динамический перенос ответственности пересылку, если AR становится недоступным. Для IPv4 преимуществом использования VRRP является более высокая доступность принятого по умолчанию маршрута без необходимости менять настройки протоколов динамической маршрутизации и обнаружения маршрутизаторов на каждом конечном хосте. Для IPv6 преимуществом является более быстрое переключение на BR, чем при использовании стандартных механизмов IPv6 Neighbor Discovery.

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

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

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

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

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

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

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

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

1. Введение

Этот документ определяет версию 3 протокола резервирования виртуальных маршрутизаторов (VRRP) для IPv4 и IPv6. Документ заменяет собой RFC 5798, ранее задававший VRRP (версия 3). RFC 5798 отменил RFC 3768, задававший VRRP (версия 2) для IPv4. VRRP задаёт протокол выбора для динамического назначения ответственности за виртуальный маршрутизатор (см. парагра 1.7) одному из маршрутизаторов VRRP в ЛВС. Маршрутизатор VRRP, контролирующий адреса IPv4 или IPv6, связанные с виртуальным маршрутизатором, (VR) называется активным (AR) и пересылает пакеты на эти адреса IPv4 или IPv6 (за исключением пакетов, адресованных на эти адреса, как указано в параграфе 8.3.1). На активных маршрутизаторах настраиваются виртуальные адреса IPv4 или IPv6, а резервные маршрутизаторы (BR) определяют семейство виртуальных адресов для анонсирования на основе версии протокола IP. Внутри маршрутизатора VRRP виртуальные маршрутизаторы для каждого из семейств адресов IPv4 и IPv6 независимы один от другого и всегда считаются отдельными экземплярами VR. Процесс выбора обеспечивает динамический перенос ответственности пересылку, если AR становится недоступным.

VRRP обеспечивает функции, похожие на функции фирменных протоколов Hot Standby Router Protocol (HSRP) [RFC2281] IP Standby Protocol [IPSTB].

1.1. Отличия от RFC 5798

Ниже перечислены изменения, внесённые в [RFC5798].

  1. Обновлена терминология VRRP в соответствии с рекомендациями по всеохватному языку для технологий IETF, в качестве которых выбран документ Национального института стандартов и технологий (National Institute of Standards and Technology или NIST) Guidance for NIST Staff on Using Inclusive Language in Documentary Standards [NISTIR8366].

  2. Термин VRRP Router для маршрутизатора, принимающего на себя ответственность за пересылку пакетов, был заменён на Active Router в соответствии со всеохватывающей терминологией IETF. Кроме того, исправлены несоответствия терминов [RFC5798] Active Router и Backup Router, а также изменён нежелательный термин для привлечения и отбрасывания нежелательных пакетов.

  3. Исправлены ошибки, относящиеся в конечному автомату, в разделе 6.

  4. Уточнён расчёт контрольных сумм в параграфе 5.2.8 для точного указания включаемых частей для псевдозаголовка IPv4.

  5. При получении анонса VRRP от маршрутизатора VRRP с меньшим приоритетом активный маршрутизатор VRRP незамедлительно отправляет анонс VRRP, чтобы мосты с обучением могли пересылать пакеты в корректный сегмент Ethernet (см. параграф 6.4.3).

  6. Удалены приложения, описывающие работу с устаревшими технологиями (Fiber Distributed Data Interface (FDDI), Token Ring, ATM LAN Emulation).

  7. Добавлены рекомендации, указывающие, что анонсы IPv6 Unsolicited Neighbor Advertisement следует воспринимать активным и резервным маршрутизаторам (параграф 8.2.4).

  8. Рекомендуется проверять совпадение Maximum Advertisement Interval, хотя это не влияет на отбрасывание пакетов VRRP ( параграф 7.1).

  9. Внесены редакционные правки для улучшения читаемости.

  10. Раздел «Взаимодействие с IANA» дополнен сведениями о выделении групповых адресов IPv4/IPv6 и MAC-адресов Ethernet.

1.2. Примечание по терминологии

В документе рассматриваются операции IPv4 и IPv6, для которых применительно к протоколу VRRP описания и процедуры совпадают. Было бы уместно использовать термин IP для обозначения IPv4 или IPv6, однако его часто относят только к IPv4. Поэтому в спецификации применяется обозначение IPvX (где X — 4 или 6) для обозначения обоих протоколов. Там, где версия IP имеет значение, указывается полный протокол, а термин IP не применяется.

1.3. IPv4

Имеется множество методов, с помощью которых конечный хост IPv4 может определить первый маршрутизатор (first-hop) на пути к целевому адресу IPv4. Они включают запуск (или отслеживание) протокола динамической маршрутизации, такого как Routing Information Protocol (RIP) [RFC2453] или OSPF версии 2 [RFC2328], запуск клиента обнаружения маршрутизаторов по ICMP [RFC1256], запуск DHCPv4 [RFC2131] или использование заданного статически маршрута по умолчанию.

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

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

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

1.4. IPv6

Хоты IPv6 в ЛВС обычно узнают о принятых по умолчанию маршрутизаторах из полученных анонсов Router Advertisement протокола обнаружения соседей IPv6 (Neighbor Discovery или ND) [RFC4861]. Групповые (multicast) анонсы Router Advertisement передаются периодически с такой скоростью, что хостам может потребоваться более 10 секунд, чтобы узнать о принятых по умолчанию маршрутизаторах в ЛВС. Анонсы передаются не настолько часто, чтобы полагаться на отсутствие Router Advertisement для обнаружения отказов маршрутизаторов.

Протокол ND включает механизм детектирования недоступности соседей (Neighbor Unreachability Detection) для обнаружения отказов соседних узлов (маршрутизаторов или хостов) или путей пересылки к соседям. Это выполняется путём отправки соседям индивидуальных сообщений ND Neighbor Solicitation. Для снижения издержек, связанных с этим сообщения Neighbor Solicitation передаются лишь соседям, которым узел активно отправляет трафик и лишь при отсутствии положительной индикации активности маршрутизатора в течение некоторого времени. При использовании принятых по умолчанию параметров ND хосту может потребоваться более 10 секунд для обнаружения недоступности маршрутизатора, чтобы переключиться на другой маршрутизатор, заданный по умолчанию. Такая задержка заметна для пользователей и может приводить к тайм-аутам некоторых реализаций транспортных протоколов.

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

Протокол VRRP для IPv6 обеспечивает более быстрое переключение на другой маршрутизатор, нежели стандартные процедуры ND. При использовании VRRP маршрутизатор BR может заменить принятый по умолчанию примерно за 3 секунды (с принятыми по умолчанию парамерами VRRP). Это происходит без взаимодействия с хостами и при минимальном трафике VRRP.

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

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

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

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

1.7. Определения

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

Маршрутизатор, на котором работает протокол VRRP. Он может участвовать в одном или нескольких VR.

Virtual Router — виртуальный маршрутизатор

Абстрактный объект, управляемый VRRP и выступающий принятым по умолчанию маршрутизатором для хостов общей ЛВС. VR имеет идентификатор (Virtual Router Identifier) и набор связанных с ним адресов IPv4 или IPv6 из общей ЛВС. Маршрутизатор VRRP может служить резервным (Backup Router) для одного или нескольких VR.

Virtual Router Identifier — идентификатор виртуального маршрутизатора

Целое число (1-255), указывающее экземпляр VR в ЛВС. Используется также аббревиатура VRID.

Virtual Router MAC Address — MAC-адрес виртуального маршрутизатора

Групповой адрес Ethernet MAC, используемый в анонсах VRRP для VRID (см. параграф 7.3).

IP Address Owner — владелец адреса IP

Маршрутизатор VRRP, имеющий адреса VR IPvX в качестве адресов реальных интерфейсов. Это маршрутизатор, который, будучи работающим, отвечает за пакеты, направленные по этим адресам IPvX, для ICMP, запросов соединений TCP и т. п.

Primary IP Address — первичный адрес IP

В IPv4 — это адрес IPv4, выбранный из набора реальных адресов интерфейса. Одним из возможных алгоритмов является выбор первого адреса. В IPv4 анонсы VRRP всегда передаются с использованием первичного адреса IPv4 в поле отправителя пакета IPv4. В IPv6 применяется локальный для канала адрес (link-local) интерфейса, через который передаётся пакет.

Forwarding Responsibility — ответственность за пересылку

Ответственность за пересылку пакетов, переданных по адресам IPvX, связанным с VR. Это включает восприятие пакетов, переданных по MAC-адресу VR, пересылку пакетов в соответствии с локальной базой маршрутной информации (Routing Information Base или RIB) и пересылки (Forwarding Information Base или FIB), ответы на запросы ARP для адресов IPv4 и на запросы ND для адресов IPv6.

Active Router — активный маршрутизатор

Маршрутизатор VRRP, принимающий на себя ответственность за пересылку пакетов, переданных по адресам IPvX, связанным с VR, отклики на запросы ARP (для IPv4) и ND (для IPv6. Отметим, что при доступности владельца адреса IPvX он всегда будет AR.

Backup Router(s) — резервные маршрутизаторы

Набор маршрутизаторов VRRP, доступных для принятия ответственности за VR в случае отказа текущего AR.

Drop Route — маршрут отбрасывания

Маршрут в базе RIB, который будет приводить к отбрасыванию трафика, соответствующего ему.

2. Требуемые свойства

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

2.1. Резервирование адресов IPvX

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

  • минимизировать продолжительность недоступности;

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

  • работать с широким спектром технологий ЛВС с множественным доступом, способных поддерживать IPvX;

  • разрешать несколько VR в сети для распределения нагрузки;

  • поддерживать множество логических подсетей IPvX в одном сегменте ЛВС.

2.2. Указание предпочтительного пути

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

2.3. Минимизация прерывания обслуживания

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

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

2.4. Эффективная работа в расширенных ЛВС

Передача пакетов IPvX (IPv4 или IPv6) в ЛВС с множественным доступом требует сопоставления адресов IPvX с адресами MAC. Использование MAC-адреса VR в расширенной ЛВС с обучающимися мостами может существенно влиять на издержки пропускной способности для пакетов, передаваемых виртуальному маршрутизатору. Если MAC-адрес VR не применяется как адрес отправителя в кадрах канального уровня, местоположение этого MAC-адреса не будет определено, что приведёт к лавинной передаче всех пакетов, отправленных маршрутизатору VR. Для повышения эффективности в таких средах протоколу следует:

  1. использовать MAC-адрес VR в поле отправителя пакетов от маршрутизатора AR для изучения MAC;

  2. выдавать сообщение срезу после переключения AR для обновления MAC-адресов;

  3. периодически передавать сообщения от AR для поддержки кэша MAC-адресов.

2.5. Субсекундные операции для IPv4 и IPv6

Для сред IPv4 и IPv6 требуется обнаружение отказа AR за доли секунды. В предыдущих работах были предложены субсекундные операции для IPv6, а данная спецификация использует этот подход для IPv4 и IPv6.

Одной из возможных проблемных ситуаций при использовании малых значений Advertisement_Interval (см. параграф 6.1) является генерация маршрутизатором VRRP большего числа пакетов, нежели он способен передать, и рост очереди на этом маршрутизаторе. В таких случаях пакеты для передачи в защищаемую VRRP ЛВС могут задерживаться в очереди на время, превышающее наименьшее значение Advertisement_Interval. При этом интервал Active_Down_Interval (см. параграф 6.1) может быть настолько малым, что даже обычные задержки в очереди могут заставить резервный маршрутизатор сделать вывод об отказе AR и предложить себя в качестве нового AR. Вскоре после этого задержанные пакеты от исходного AR заставят маршрутизатор VRRP снова переключиться на BR и это может происходить много раз в секунду, вызывая значительные перебои в трафике. Для смягчения этой проблемы следует рассмотреть возможность предоставления пакетам VRRP приоритета на выходном интерфейсе. Если AR замечает такую ситуацию, ему следует указать это в системном журнале (с учётом ограничения частоты записей).

3. Обзор VRRP

VRRP задаёт протокол выбора для обеспечения функций VR, описанных выше. Обмен сообщениями протокола выполняется с помощью групповых дейтаграмм IPv4 или IPv6, поэтому протокол может работать в разных ЛВС с множественным доступом, поддерживающих групповую адресацию IPvX. С каждым каналом виртуального маршрутизатора VRRP связан 1 общеизвестный MAC-адрес. Этот документ в задаёт детали отображения лишь для сетей, использующих 48-битовые адреса MACIEEE 802. MAC-адрес VR указывается в поле отправителя всех периодических сообщений VRRP, передаваемых AR, чтобы стало возможным изучение MAC на канальном уровне (L2) мостами расширенных ЛВС.

VR указывается идентификатором VRID и набором адресов IPv4 или IPv6. Маршрутизатор VRRP может связывать VR с реальным адресом на своём интерфейсе. Область действия каждого VR ограничивается одной ЛВС. На маршрутизаторе VRRP могут настраиваться дополнительные отображения VR и приоритеты для VR, которые маршрутизатор готов реализовать. Сопоставление VRID с адресами IPvX должно быть настраиваемым для всех маршрутизаторов VRRP в ЛВС.

Не задаётся ограничений на многократное использование VRID с другими сопоставлениями адресов в разных ЛВС и применение одного VRID для набора адресов IPv4 и IPv6. Однако это будут разные маршрутизаторы VR.

Для минимизации трафика периодические сообщения VRRP Advertisement для каждого VR передаёт лишь AR. Маршрутизатор BR не пытается вытеснить AR, пока у него нет более высокого приоритета. Это исключает перебои в обслуживании, пока не появится более предпочтительный путь. Можно также административно запретить попытки вытеснение AR. Единственным исключением является то, что маршрутизатор VRRP всегда будет становиться AR для любого VR, связанного с адресом, которым он владеет. Если AR становится недоступным, BR с наивысшим приоритетом становится AR с небольшой задержкой, обеспечивая контролируемую передачу ответственности за VR с минимальным прерыванием обслуживания.

Протокол VRRP обеспечивает быстрый переход BR в состояние AR для минимизации перебоев в обслуживании и включает оптимизацию, снижающую сложность протокола в сочетании с гарантиями контролируемого перехода в состояние AR для типичных рабочих ситуаций. Эта оптимизация обеспечивает протокол выбора с минимальными требованиями к рабочим состояниям, минимальным набором активных состояний протокола и одним типом сообщений и отправителем. Определены типовые рабочие сценарии с двумя резервными маршрутизаторами и/или разными предпочтениями путей для каждого маршрутизатора. Побочным эффектом несоблюдения этих допущений, т. е. наличия более двух резервных путей с одинаковым предпочтением, является кратковременная пересылка дубликатов пакетов в течение короткого периода выбора AR. Однако допущение типичных сценариев, вероятно, верно для большинства ситуаций — потеря AR случается достаточно редко, а ожидаемая продолжительность процесса выбора AR достаточно мала (< 4 секунд для принятого по умолчанию Advertisement_Interval с возможностью снижения до значений < 1/25 секунды). Таким образом, оптимизация VRRP значительно упрощает устройство протокола при сохранении невысокой вероятности кратковременных нарушений работы.

4. Примеры сетей VRRP

4.1. Пример 1

На рисунке 1 показана простая сеть с двумя маршрутизаторами VRRP, реализующими один VR.

        +-----------+ +-----------+
        | Router-1  | | Router-2  |
        |(AR VRID=1)| |(BR VRID=1)|
        |           | |           |
VRID=1  +-----------+ +-----------+
IPvX A------>*            *<---------IPvX B
             |            |
             |            |
-------------+------------+--+-----------+-----------+-----------+
                             ^           ^           ^           ^
                             |           |           |           |
     Адреса IPvX принятого   |           |           |           |
     по умолчанию    ---> (IPvX A)    (IPvX A)    (IPvX A)    (IPvX A)
     маршрутизатора          |           |           |           |
                    IPvX H1->*  IPvX H2->*  IPvX H3->*  IPvX H4->*
                          +--+--+     +--+--+     +--+--+     +--+--+
                          |  H1 |     |  H2 |     |  H3 |     |  H4 |
                          +-----+     +-----+     +--+--+     +--+--+
Обозначения
    --+---+---+-- = Ethernet
                H = хост
               AR = AR
               BR = BR
               *  = адрес IPvX: X = 4 для IPv4 и 6 для IPv6
               (IPvX) = принятый по умолчанию маршрутизатор для хостов

Рисунок . Пример сети VRRP.


В случае IPv4 (IPvX на рисунке обозначает IPv4) на каждом маршрутизаторе заранее назначается адрес IPv4 на интерфейсе ЛВС (на Router-1 это IPv4 A, на Router-2 — IPv4 B), а на каждом хосте устанавливается принятый по умолчанию маршрут (по протоколу DHCPv4 или настройку статического маршрута) через один из маршрутизаторов (на рисунке все хосты используют адрес IPv4 A). В случае IPv6 (IPvX на рисунке обозначает IPv6) каждый маршрутизатор имеет свой адрес IPv6 link-local на интерфейсе ЛВС и адрес IPv6 link-local для VRID, который является общим для всех маршрутизаторов с одним VRID. Каждый хост узнаёт принятый по умолчанию маршрут из сообщений Router Advertisement от одного из этих маршрутизаторов (на рисунке все хосты используют IPv6 Link-Local A).

В среде VRRP IPv4 каждый маршрутизатор поддерживает приём и передачу для одного и того же адреса IPv4. Router-1 является владельцем IPv4 A, а Router-2 — IPv4 B. VR определяется привязкой уникального идентификатора VRID к адресу, принадлежащему Router-1. В среде VRRP IPv6 каждый маршрутизатор поддерживает приём и передачу для адресов IPv6, связанных с VRID. Router-1 является владельцем IPv6 A, а Router-2 — IPv6 B. VR определяется привязкой уникального идентификатора VRID к адресу, принадлежащему Router-1. В обоих случаях (IPv4 и IPv6) протокол VRRP обеспечивает переключения VR при отказе на BR.

В примере показан VR, настроенный на охват адреса IPvX, принадлежащего Router-1 (VRID=1, IPvX_Address=A). При включении VRRP на Router-1 для VRID=1 этот маршрутизатор будет заявлять себя как AR с priority = 255, поскольку он владеет адресом IPvX для VR. При включении VRRP на Router-2 для VRID=1 этот маршрутизатор будет заявлять себя как BR с priority = 100 (принятое по умолчанию значение), поскольку он не является владельцем адреса IPvX. При отказе Router-1 протокол VRRP переведёт Router-2 в состояние AR, временно передав ему ответственность за пересылку IPvX A для обеспечения бесперебойного обслуживания хостов.

Отметим, что для обоих случаев на рисунке IPvX B не резервируется и используется только маршрутизатором Router-2 в качестве адреса на интерфейсе. Для резервирования IPvX B требуется настроить второй VR, как показано ниже.

4.2. Пример 2

На рисунке 2 показана конфигурация с двумя VR, между которыми хосты распределяют трафик.

В примере для IPv4 (IPvX на рисунке обозначает адрес IPv4) половина хостов настраивается со статическим маршрутом по умолчанию через IPv4 A (Router-1), остальные используют IPv4 B (Router-2 ). Настройка VR с VRID=1 совпадает с предыдущим примером (параграф 4.1), а второй VR добавлен для охвата адреса IPv4, принадлежащего Router-2 (VRID=2, IPv4_Address=B). В этом случае Router-2 будет заявлять себя как AR для VRID=2, а Router-1 будет служить BR. Это демонстрирует развёртывание с распределением нагрузки при доступности обоих маршрутизаторов с обеспечением полного резервирования для отказоустойчивости.

        +-----------+  +-----------+
        |  Router-1 |  | Router-2  |
        |(AR VRID=1)|  |(BR VRID=1)|
        |(BR VRID=2)|  |(AR VRID=2)|
VRID=1  +-----------+  +-----------+  VRID=2
IPvX A ----->*             *<---------- IPvX B
             |             |
             |             |
   ----------+-------------+-+-----------+-----------+-----------+
                             ^           ^           ^           ^
                             |           |           |           |
     Адрес IPvX принятого    |           |           |           |
     по умолчанию    ---> (IPvX A)    (IPvX A)    (IPvX B)    (IPvX B)
     маршрутизатора          |           |           |           |
                    IPvX H1->*  IPvX H2->*  IPvX H3->*  IPvX H4->*
                          +--+--+     +--+--+     +--+--+     +--+--+
                          |  H1 |     |  H2 |     |  H3 |     |  H4 |
                          +-----+     +-----+     +--+--+     +--+--+

Обозначения
    --+---+---+-- = Ethernet
                H = хост
               AR = AR
               BR = BR
               *  = адрес IPvX: X = 4 для IPv4 и 6 для IPv6
               (IPvX) = принятый по умолчанию маршрутизатор для хостов

Рисунок . Пример сети VRRP.


В примере для IPv6 (IPvX на рисунке обозначает адрес IPv6) половина хостов настраивается с маршрутом по умолчанию через IPv6 A (Router-1), остальные используют IPv6 B(Router-2 ). Настройка VR с VRID=1 совпадает с предыдущим примером (параграф 4.1), а второй VR добавлен для охвата адреса IPv6, принадлежащего Router-2 (VRID=2, IPv6_Address=B). В этом случае Router-2 будет заявлять себя как AR для VRID=2, а Router-1 будет служить BR. Это демонстрирует развёртывание с распределением нагрузки при доступности обоих маршрутизаторов с обеспечением полного резервирования для отказоустойчивости.

Отметим, что детали распределения нагрузки выходят за рамки этого документа. Если серверам нужны различные веса, полагаться на сообщения Router Advertisement для распределения трафика между маршрутизаторами может быть бессмысленно [RFC4311].

5. Протокол

Назначением VRRP Advertisement является передача всем маршрутизаторам VRRP значения Maximum Advertisement Interval и адреса IPvX маршрутизатора AR, связанного с VRID.

Когда VRRP служит для защиты адреса IPv4, пакеты VRRP инкапсулируются в пакеты IPv4, которые передаются по групповому адресу IPv4, назначенному VRRP. При использовании VRRP для защиты адреса IPv6 пакеты VRRP инкапсулируются в пакеты IPv6, которые передаются по групповому адресу IPv6, назначенному VRRP.

5.1. Формат пакетов VRRP

В этом параграфе описан формат пакетов VRRP и соответствующих полей заголовков IPvX (с учётом семейства).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Поля IPv4 или IPv6                     |
...                                                           ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type  | Virtual Rtr ID|   Priority    |IPvX Addr Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserve| Max Advertise Interval|          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                         Адреса IPvX                           |
+                                                               +
+                                                               +
+                                                               +
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакетов IPv4/IPv6 VRRP Advertisement.


5.1.1. Описание полей IPv4

5.1.1.1. Source Address

Первичный адрес IPv4 на интерфейсе, с которого передаётся пакет.

5.1.1.2. Destination Address

Групповой адрес IPv4, назначенный IANA для протокола VRRP (224.0.0.18). Это групповой адрес, действующий на локальном канале. Маршрутизаторам недопустимо пересылать такие дейтаграммы независимо от значения TTL.

5.1.1.3. TTL

Должно иметь значение 255. Маршрутизатор VRRP должен отбрасывать пакеты с иным значением [RFC5082].

5.1.1.4. Protocol

Номер протокола IPv4, выделенный IANA для VRRP (десятичное значение 112).

5.1.2. Описание полей IPv6

5.1.2.1. Source Address

Адрес IPv6 link-local на интерфейсе, с которого передаётся пакет.

5.1.2.2. Destination Address

Групповой адрес IPv6, назначенный IANA для протокола VRRP (ff02:0:0:0:0:0:0:12). Это групповой адрес, действующий на локальном канале. Маршрутизаторам недопустимо пересылать такие дейтаграммы при любом значении Hop Limit.

5.1.2.3. Hop Limit

Должно иметь значение 255. Маршрутизатор VRRP должен отбрасывать пакеты с иным значением [RFC5082].

5.1.2.4. Next Header

Протокол IPv6 Next Header, выделенный IANA для VRRP (десятичное значение 112).

5.2. Описание полей VRRP

5.2.1. Version

Версия протокола VRRP для этого пакета. Этот документ задаёт версию 3.

5.2.2. Type

Указывает тип пакета VRRP. В этой версии протокола определён лишь один тип:

1

ADVERTISEMENT (анонс).

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

5.2.3. Virtual Rtr ID (VRID)

Поле Virtual Rtr ID указывает VR, для которого пакет указывает состояние.

5.2.4. Priority

8-битовое целое число без знака, указывающее приоритет передающего маршрутизатора VRRP для VR. Большие значения указывают более высокий приоритет. Для маршрутизатора VRRP, владеющего адресом IPvX, связанным с VR, поле должно иметь значение 255 (десятичное).

Маршрутизаторы VRRP, резервирующие VR, должны использовать для приоритета десятичные значения 1-254. По умолчанию для маршрутизаторов VRRP, резервирующих VR, используется десятичное значение 100. Рекомендации по выбору приоритета приведены в параграфе 8.3.2. Значение приоритета 0 указывает, что текущий AR прекратил своё участие в VRRP. Это служит для того, чтобы маршрутизаторы BR приступали к выбору AR, не ожидая завершения текущего Active_Down_Interval (см. параграф 6.1).

5.2.5. IPvX Addr Count

Поле IPvX Addr Count указывает число адресов (IPv4 или IPv6) в анонсе VRRP и должно иметь значение не меньше 1. Анонсы VRRP со значением 0 должны игнорироваться.

5.2.6. Reserve

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

5.2.7. Max Advertise Interval

12-битовое поле, указывающее интервал между анонсами в сотых долях секунды (по умолчанию 100 — 1 секунда).

Отметим, что высокоприоритетные AR с более низкой скоростью, чем у их BR, будут нестабильны, поскольку BR с низким приоритетом и более высокой скоростью могут присоединиться к ЛВС и решить, что им следует быть AR до получения сигнала от медленного AR с высоким приоритетом. Это временное явление и после получения узлом с низким приоритетом сообщения от высокоприоритетного AR он откажется от своего статуса AR.

5.2.8. Checksum

Поле контрольной суммы служит для обнаружения повреждений данных в сообщениях VRRP. Для семейств адресов IPv4 и IPv6 контрольная сумма представляет собой 16-битовое дополнение до 1 суммы дополнений до 1 для сообщения VRRP. При расчёте контрольной суммы значение поля Checksum принимается равным 0. Детали расчёта контрольных сумм описаны в [RFC1071].

Для адресов IPv4 при расчёте контрольной суммы используются поля сообщения VRRP, начиная с поля Version и заканчивая последним адресом IPv4 (см. параграф 5.2). Для адресов IPv6 в расчёт контрольной суммы включается также добавленный в начало псевдозаголовок, определённый в параграфе 8.1 [RFC8200]. В поле Next Header псевдозаголовка для протокола VRRP следует устанавливать десятичное значение 112.

5.2.9. Адреса IPvX

Эти поля относятся к одному или нескольким адресам IPvX, связанным с VR. Число адресов указывается в поле IPvX Addr Count. Поля применяются для поиска и устранения неполадок в настройках маршрутизаторов. При отправке более одного адреса рекомендуется настраивать на всех маршрутизаторах передачу адресов в одном порядке, чтобы упростить сравнение.

Для IPv4 эти поля содержат один или несколько адресов IPv4, резервируемых маршрутизатором VR.

Для IPv6 первым должен указываться адрес IPv6 link-local, связанный с VR.

Эти поля содержат 1 или несколько адресов IPv4 или IPv6. Семейство (IPv4 или IPv6, но не сочетание) должно совпадать с семейством адреса в заголовке IPvX пакета VRRP.

6. Конечный автомат протокола

6.1. Параметры виртуального маршрутизатора

VRID

Идентификатор VR — настраиваемое десятичное значение от 1 до 255. Значение по умолчанию отсутствует.

Priority

Значение приоритета, используемое маршрутизатором VRRP при выборе AR для данного VR. Десятичное значение 255 зарезервировано для маршрутизатора, владеющего адресом IPvX, связанным с VR, значение 0 зарезервировано для AR с целью указания снятия ответственности за VR. Десятичные значения 1-254 доступны для маршрутизаторов VRRP, резервирующих VR. Большее значение указывает более высокий приоритет. По умолчанию используется десятичное значение 100.

IPv4_Addresses

Один или несколько адрес IPv4, связанный с VR. Настраиваемый список адресов без значения по умолчанию.

IPv6_Addresses

Один или несколько адрес IPv6, связанный с VR. Настраиваемый список адресов без значения по умолчанию. Первым в списке должен быть адрес Link-Local, связанный с VR.

IPvX_Addresses

Адрес IPv4 или IPv6, связанный с этим VR (см. выше IPv4_Addresses и IPv6_Addresses).

Advertisement_Interval

Интервал времени между анонсами VRRP Advertisement, передаваемых эти VR (в сотых долях секунды). По умолчанию установлено значение 100 (1 секунда).

Active_Adver_Interval

Интервал анонсирования, содержащийся в VRRP Advertisement, полученных от AR (в сотых долях секунды). Это значение сохраняется маршрутизаторами VR в состоянии Backup и применяется для расчёта Skew_Time (см. параграф 8.3.2) и Active_Down_Interval. Исходное значение совпадает с Advertisement_Interval.

Skew_Time

Время для изменения Active_Down_Interval в сотых долях секунды. Рассчитывается по формуле (((256 — Priority) * Active_Adver_Interval) / 256).

Active_Down_Interval

Интервал времени, по истечение которого BR объявляет AR отказавшим в сотых долях секунды. Рассчитывается по формуле (3 * Active_Adver_Interval) + Skew_Time.

Preempt_Mode

Указывает, будет ли BR с более высоким приоритетом (при запуске или перезапуске) вытеснять AR с низким приоритетом. Значение True (принято по умолчанию) разрешает вытеснение, False — запрещает.
Примечание. Маршрутизатор, владеющий адресом IPvX, связанным с VR использует вытеснение всегда, независимо от установки этого флага.

Accept_Mode

Указывает, будет ли VR в состоянии Active воспринимать пакеты, направленные владельцу адреса IPvX, как свои, даже если они ему не принадлежат. По умолчанию установлено значение False. Системы, полагающиеся, например, на ping IPvX-адреса владельца, могут пожелать установить Accept_Mode = True.
Примечание. Сообщения IPv6 Neighbor Solicitation и Neighbor Advertisement недопустимо отбрасывать при Accept_Mode = False.

Virtual_Router_MAC_Address

MAC-адрес, используемый в поле MAC отправителя анонсов VRRP и анонсируемый в сообщениях ARP/ND как MAC-адрес для использования в IPvX_Addresses.

6.2. Таймеры

Active_Down_Timer

Таймер, срабатывающий при отсутствии VRRP Advertisement в течение Active_Down_Interval (только BR).

Adver_Timer

Таймер для запуска передачи VRRP Advertisement по времени Advertisement_Interval (только AR).

6.3. Диаграмма смены состояний

                +---------------+
     +--------->|               |<-------------+
     |          |  Initialize   |              |
     |   +------|               |----------+   |
     |   |      +---------------+          |   |
     |   |                                 |   |
     |   V                                 V   |
+---------------+                       +---------------+
|               |---------------------->|               |
|    Active     |                       |    Backup     |
|               |<----------------------|               |
+---------------+                       +---------------+

Рисунок . Диаграмма смены состояний.


6.4. Описания состояний

В описаниях ниже имена состояний указываются как {state-name}, а пакеты — заглавными буквами.

Маршрутизатор VRRP реализует экземпляр конечного автомата для каждого VR, в котором он участвует.

6.4.1. Initialize

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

По событию Startup выполняются указанные ниже действия.

  • Если Priority = 255, т. е. маршрутизатор владеет адресами IPvX, связанными с VR:

    • передаётся сообщение ADVERTISEMENT;

    • если защищаемый адрес IPvX является IPv4:

      • для каждого адреса IPv4, связанного с VR, передаётся широковещательное беспричинное сообщение ARP с IPv4-адресом1 VR и MAC-адресом VR в качестве целевого адреса канального уровня;

    • иначе // IPv6

      • для каждого адреса IPv6, связанного с VR, передаётся незапрошенный анонс ND Neighbor Advertisement с установленным флагом Router Flag (R), сброшенным флагом Solicited Flag (S), установленным флагом Override flag (O), целевым адресом IPv6 для VR и MAC-адресом VR в качестве целевого адреса канального уровня;

    • завершение проверки семейства адресов;

    • для Adver_Timer устанавливается значение Advertisement_Interval;

    • состояние меняется на {Active};

  • иначе // маршрутизатор не является владельцем адреса

    • для Active_Adver_Interval устанавливается значение Advertisement_Interval;

    • для Active_Down_Timer устанавливается значение Active_Down_Interval;

    • состояние меняется на {Backup};

  • завершение проверки условия Priority = 255.

На этом обработка события Startup завершается.

6.4.2. Backup

Состояние {Backup} предназначено для отслеживания доступности и статуса AR. В приведённом ниже описании применяется групповой адрес Solicited-Node [RFC4291].

Находясь в состоянии {Backup} маршрутизатор VRRP должен выполнять указанные ниже действия.

  • Если защищаемый адрес IPvX является IPv4:

    • маршрутизатору недопустимо отвечать на запросы ARP, для адресов IPv4 маршрутизатора VR;

  • иначе // защищаемый адрес относится к IPv6

    • маршрутизатору недопустимо отвечать на сообщения ND Neighbor Solicitation для адресов IPv6, связанных с VR;

    • маршрутизатору недопустимо передавать сообщения ND Router Advertisement для VR;

  • завершение проверки принадлежности защищаемого адреса к IPv4;

  • маршрутизатор должен отбрасывать пакеты с MAC-адресом получателя, совпадающим с MAC-адресом VR;

  • маршрутизатору недопустимо воспринимать пакеты, направленные по адресам IPvX, связанным с VR;

  • по событию Shutdown:

    • отключается таймер Active_Down_Timer;

    • состояние меняется на {Initialize};

  • завершение обработки события Shutdown;

  • по срабатыванию таймера Active_Down_Timer:

    • передаётся сообщение ADVERTISEMENT;

  • если защищаемый адрес IPvX является IPv4:

      • для каждого адреса IPv4, связанного с VR передаётся широковещательное беспричинное сообщение ARP, содержащее IPv4-адрес VR и MAC-адрес VR в качестве целевого адреса канального уровня;

    • иначе // IPv6

      • рассчитывается присоединяется групповой адрес Solicited-Node [RFC4291] для адресов IPv6, связанных с VR;

      • для каждого адреса IPv6, связанного с VR, передаётся незапрошенный анонс ND Neighbor Advertisement с установленным флагом Router Flag (R), сброшенным флагом Solicited Flag (S), установленным флагом Override flag (O), целевым адресом IPv6 для VR и MAC-адресом VR в качестве целевого адреса канального уровня;

    • завершение проверки принадлежности защищаемого адреса к IPv4;

    • для Adver_Timer устанавливается значение Advertisement_Interval;

    • состояние меняется на {Active};

  • завершение обработки по таймеру Active_Down_Timer;

  • при получении сообщения ADVERTISEMENT:

    • если Priority в ADVERTISEMENT имеет ненулевое значение:

      • для Active_Down_Timer устанавливается значение Skew_Time;

    • завершение обработки ненулевого приоритета;

      • если Preempt_Mode = False или Priority в ADVERTISEMENT не меньше локального Priority:

        • для Active_Adver_Interval устанавливается значение Max Advertise Interval из ADVERTISEMENT;

        • заново рассчитывается Skew_Time;

        • заново рассчитывается Active_Down_Interval;

        • для Active_Down_Timer устанавливается значение Active_Down_Interval;

      • иначе // вытеснение было разрешено, а приоритет в анонсе меньше локального;

        • ADVERTISEMENT отбрасывается;

      • завершение проверки возможности вытеспения;

    • завершение обработки нулевого приоритета;

  • завершение проверки получения анонса.

На этом обработка в состоянии {Backup} завершается.

6.4.3. Active

В состоянии {Active} маршрутизатор выполняет пересылку для адресов IPvX, связанных с VR. Флаг Preempt_Mode Flag в режиме {Active} не принимается во внимание.

В состоянии {Active} маршрутизатор VRRP должен выполнять указанные ниже действия.

  • Если защищаемый адрес IPvX относится к IPv4:

    • маршрутизатор должен отвечать на запросы ARP для адресов IPv4, связанных с VR;

  • иначе // IPv6

    • маршрутизатор должен быть членом группы Solicited-Node для адресов IPv6, связанных с VR;

    • маршрутизатор должен отвечать на сообщения ND Neighbor Solicitation (с установленным флагом Router Flag (R)) для адресов IPv6, связанных с VR;

    • маршрутизатор должен передавать сообщения ND Router Advertisement для VR;

    • если Accept_Mode = False:

      • маршрутизатору недопустимо отбрасывать IPv6 Neighbor Solicitation и Neighbor Advertisement;

  • завершение проверки семейства адресов;

  • маршрутизатор должен пересылать пакеты с MAC-адресом получателя, совпадающим с MAC-адресом VR;

  • маршрутизатор должен воспринимать пакеты, направленные по адресам IPvX, связанным с VR, если он владеет этим адресом IPvX или Accept_Mode = True, в иных случаях воспринимать пакеты недопустимо;

  • по событию Shutdown:

    • выключается таймер Adver_Timer;

    • передаётся ADVERTISEMENT с Priority = 0;

    • состояние меняется на {Initialize};

  • завершение обработки Shutdown;

  • по таймеру Adver_Timer:

    • передаётся ADVERTISEMENT;

    • для Adver_Timer устанавливается значение Advertisement_Interval;

  • завершение обработки по таймеру анонсов;

  • при получении сообщения ADVERTISEMENT:

    • если поле Priority в ADVERTISEMENT имеет значение 0:

      • передаётся ADVERTISEMENT;

      • для Adver_Timer устанавливается значение Advertisement_Interval;

    • иначе // приоритет отличен от 0;

      • если Priority в ADVERTISEMENT больше локального Priority или приоритеты совпадают и первичный адрес IPvX отправителя больше локального первичного адреса IPvX (сравнение как целых чисел без знака с сетевым порядком байтов):

        • выключается таймер Adver_Timer;

        • для Active_Adver_Interval устанавливается значение Max Advertise Interval из ADVERTISEMENT;

        • заново рассчитывается Skew_Time;

        • заново рассчитывается Active_Down_Interval;

        • для Active_Down_Timer устанавливается значение Active_Down_Interval;

        • состояние меняется на {Backup};

      • иначе // логика нового AR

        • ADVERTISEMENT отбрасывается;

        • незамедлительно передаётся ADVERTISEMENT для подтверждения статуса {Active} передавшему анонс маршрутизатору VRRP и обновления обучающихся мостов указанием корректного пути к активному маршрутизатору VRRP;

      • завершение обработки при обнаружении нового AR;

    • завершение обработки по приоритету;

  • завершение обработки полученного анонса.

На этом работа в состоянии {Active} завершается.

Примечание. Пакеты VRRP передаются с MAC-адресом VR в поле отправителя, чтобы обеспечить обучающимся мостам корректное определение сегмента ЛВС, к которому подключён VR.

7. Передача и приём пакетов VRRP

7.1. Приём пакетов VRRP

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

  • Если получен пакет IPv4:

    • должно проверяться наличие значения 255 в поле IPv4 TTL;

  • иначе // получен пакет VRRP IPv6;

    • должно проверяться наличие значения 255 в поле IPv6 Hop Limit;

  • завершение обработки по семейству адресов;

  • должен проверяться номер версии VRRP (3);

  • должно проверяться значение типа пакета VRRP (1 — ADVERTISEMENT);

  • должна проверяться полнота полученного пакета VRRP (включая фиксированные поля и адрес IPvX);

  • должна проверяться контрольная сумма VRRP;

  • должна выполняться проверка настройки VRID на принявшем пакет интерфейсе и того, что локальный маршрутизатор не является владельцем адреса IPvX (Priority = 255 ).

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

Получателю следует проверять, что Max Advertise Interval в принятом пакете VRRP совпадает со значением Advertisement_Interval настроенным для VRID, поскольку при различии интервалов может возникать нестабильность (см. параграф 5.2.7). При отрицательном результате проверки следует внести запись об этом в системный журнал (с учётом ограничения частоты записей) и можно указать некорректность настройки через систему управления.

Получатель может проверить соответствие IPvX Addr Count и сприска адресов IPvX настроенным для VRID адресам IPvX. При отрицательном результате проверки следует внести запись об этом в системный журнал (с учётом ограничения частоты записей) и можно указать некорректность настройки через систему управления.

7.2. Передача пакетов VRRP

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

  • Заполнение полей пакета VRRP в соответствии с состоянием конфигурации VR.

  • Расчёт контрольной суммы VRRP.

  • Установка в поле MAC-адреса отправителя значения MAC-адреса VR.

  • Если защищаемым адресом является IPv4,

    • установка в поле адреса отправителя IPv4 первичного адреса IPv4 на интерфейсе

  • иначе // IPv6

    • установка в поле адреса отправителя IPv6 адреса IPv6 link-local для интерфейса

  • завершение обработки по семействам адресов;

  • установка для протокола IPvX значения VRRP;

  • передача пакета VRRP в группу IPvX VRRP.

Примечание. Пакеты VRRP передаются с MAC-адресом VR в поле MAC отправителя, чтобы обучающиеся мосты могли корректно определить сегмент ЛВС, к которому подключён VR.

7.3. MAC-адрес VR

MAC-адрес, связанный с Virtual является адресом IEEE 802 MAC [RFC9542] в формате

   IPv4: 00-00-5E-00-01-{VRID} (шестнадцатеричное с сетевым порядком байтов)

Три первых октета взяты из уникального идентификатора IANA (Organizationally Unique Identifier или OUI), следующие 2 (00-01) указывают блок адресов, выделенных VRRP для протокола IPv4. {VRID} — это идентификатор VR. Этот формат позволяет иметь в ЛВС до 255 маршрутизаторов IPv4 VRRP.

   IPv6: 00-00-5E-00-02-{VRID} (шестнадцатеричное с сетевым порядком байтов)

Три первых октета взяты из IANA OUI, следующие 2 (00-01) указывают блок адресов, выделенных VRRP для протокола IPv6. {VRID} — это идентификатор VR. Формат позволяет иметь в ЛВС до 255 маршрутизаторов IPv6 VRRP.

7.4. Идентификаторы интерфейсов IPv6

В [RFC8064] указано, что [RFC7217] применяется в качестве принятой по умолчанию схемы создания стабильных адресов при автоматической настройке IPv6 без поддержки состояний (Stateless Address Autoconfiguration или SLAAC) [RFC4862]. MAC-адрес VR недопустимо применять для параметра Net_Iface в алгоритмах создания идентификаторов интерфейсов (Interface Identifier или IID) [RFC7217] и [RFC8981].

Эта спецификация VRRP описывает, как анонсируется и преобразуется адрес IPv6 link-local маршрутизатора VRRP и связанные с ним адреса IPv6 в MAC-адрес VR.

8. Вопросы эксплуатации

8.1. IPv4

8.1.1. ICMP Redirect

Перенаправление ICMP можно использовать при работе VRRP между группой маршрутизаторов, что позволяет принять VRRP в средах с несимметричной топологией.

Адресу отправителя IPv4 в перенаправлении ICMP следует быть адресом, который конечный хост использовал при принятии решения о следующем маршрутизаторе (next-hop). Если маршрутизатор VRRP является AR для VR, содержащих адреса, которыми он не владеет, при выборе адреса источника перенаправления этот маршрутизатор должен определить, какому из VR был направлен пакет. Одним из методов определения VR является изучение MAC-адреса получателя в пакете, вызвавшем перенаправление.

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

8.1.2. Запросы ARP от хостов

Когда хост передаёт запрос ARP для обного из адресов IPv4 маршрутизатора VR, маршрутизатор AR должен отвечать сообщением ARP, указывающим MAC-адрес VR. Отметим, что адресом отправителя в кадре Ethernet с откликом ARP является физический MAC-адрес физического маршрутизатора. Маршрутизатору AR недопустимо указывать свой физический MAC-адрес в отклике ARP. Это позволяет хостам всегда использовать один MAC-адрес, независимый от текущего AR.

При загрузке или перезагрузке маршрутизатора VRRP ему не следует передавать каких-либо сообщений ARP, использующих его физический MAC-адрес для адреса IPv4, которым он владеет (в соответствии с параграфом 1.7), и следует передавать лишь сообщения ARP с MAC-адресом VR. Это означает соблюдение указанных ниже условий.

  • При настройке интерфейса маршрутизаторам AR следует широковещательно передавать беспричинное сообщение ARP с MAC-адресом VR для каждого адреса IPv4 на этом интерфейсе.

  • При инициализации интерфейсов для операций VRRP в процессе загрузки системы беспричинные сообщения ARP должны задерживаться до момента установки адреса IPv4 и MAC-адреса VR.

  • При доступе к конкретному маршрутизатору VRRP, например, с помощью Secure Shell (SSH), следует использовать адрес IPv4, заведомо принадлежащий этому маршрутизатору.

8.1.3. Proxy ARP

При использовании Proxy ARP на маршрутизаторе VRRP он должен анонсировать MAC-адрес VR в сообщении Proxy ARP, поскольку в противном случае хосты получат реальный MAC-адрес маршрутизатора VRRP.

8.2. IPv6

8.2.1. ICMPv6 Redirect

Перенаправления ICMPv6 обычно могут применяться при работе VRRP на группе маршрутизаторов [RFC4443]. Это позволяет использовать VRRP в средах, где топология не симметрична, например, маршрутизаторы VRRP не соединены с одними и теми же получателями. В качестве адреса отправителя ICMPv6 следует указывать адрес, который конечный хост использовал при выборе next-hop. Если маршрутизатор VRRP играет роль AR для маршрутизатора(ов) VR, содержащих адреса, которыми он не владеет, при выборе адреса источника перенаправления нужно определить, какому VR был направлен пакет. Определение выполняется по MAC-адресу получателя в пакете, вызвавшем перенаправление.

8.2.2. ND Neighbor Solicitation

Когда хост передаёт сообщение ND Neighbor Solicitation для обного из адресов IPv6 маршрутизатора VR, маршрутизатор AR должен отвечать на него, указывая MAC-адрес VR. Маршрутизатору AR недопустимо указывать свой физический MAC-адрес в отклике. Это позволяет хостам всегда использовать один MAC-адрес, независимый от текущего AR.

При передаче маршрутизатором AR сообщения ND Neighbor Solicitation для адреса хоста IPv6 он должен включать в это сообщение MAC-адрес VR, если в сообщении передаётся опция адреса канального уровня отправителя. Использовать свой физический MAC-адрес в качестве канального адреса источника недопустимо.

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

  • При настройке интерфейса маршрутизаторам AR следует передавать незапрошенное сообщение ND Neighbor Advertisement с MAC-адресом VR для адреса IPv6 на этом интерфейсе.

  • При инициализации интерфейсов для операций VRRP в процессе загрузки системы все сообщения ND Router Advertisement, ND Neighbor Advertisement и ND Neighbor Solicitation должны задерживаться до момента установки адреса IPv6 и MAC-адреса VR.

При перезапуске AR, где защищаемый VRRP адрес является адресом интерфейса (т. е. маршрутизатор владеет адресом) обнаружения дубликатов адресов (Duplicate Address Detection) может не срабатывать, поскольку BR может сообщать, что адрес принадлежит ему. Одним из решений является отказ от обнаружения дубликатов в таких случаях.

8.2.3. Анонсы маршрутизаторов

Когда резервный маршрутизатор VRRP становится AR для VR, он отвечает за передачу сообщений Router Advertisement для VR, как указано в параграфе 6.4.3. Маршрутизаторы BR должны быть настроены для передачи тех же опций Router Advertisement, что и владелец адреса.

Опции Router Advertisement, анонсирующие особые службы, такие как Home Agent Information Option, которые присутствуют у владельца адреса, владельцу не следует передавать, пока маршрутизаторы BR не подготовлены для полного предоставления таких же услуг и не имеют полной и синхронизированной базы данных для этих услуг.

8.2.4. Незапрошенные анонсы соседей

Маршрутизатору VRRP, действующему как AR или BR для IPv6, следует воспринимать сообщения Unsolicited Neighbor Advertisement и обновлять соответствующий кэш соседей [RFC4861]. Поскольку эти анонсы передаются по групповому адресу IPv6 all-nodes (ff02::1) [RFC4861] млм IPv6 all-routers (ff02::2), они будут получены. Сообщения Unsolicited Neighbor Advertisement передаются при смене адреса канального уровня [RFC4861] и для незапрошенного обнаружения первого маршрутизатора (first-hop) [RFC9131]. Может потребоваться дополнительная настройка, чтобы сообщения Unsolicited Neighbor Advertisement обновляли соответствующий кэш соседей.

8.3. IPvX

8.3.1. Возможные петли при пересылке

Маршрутизатору VRRP, не являющемуся владельцем адреса, не следует пересылать пакеты, направленные по адресу IPvX, для которого он стал AR, поскольку такая пересылка создаёт ненужный трафик. Кроме того, при получении ЛВС пакетов, которые эта сеть передала, могут возникать петли, исчезающие лишь по завершении IPvX TTL. Одним из механизмов предотвращения таких петель маршрутизаторами VRRP является добавление (удаление) Drop Route для хостов на каждом не принадлежащем маршрутизатору адресе IPvX при переходе в состояние AR (выходе из него).

8.3.2. Рекомендации по установке приоритета

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

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

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

8.4. Взаимодействие VRRPv3 и VRRPv2

8.4.1. Допущения

  1. Функциональная совместимость VRRPv2 и VRRPv3 не является обязательной.

  2. Смешение VRRPv2 и VRRPv3 следует допускать лишь при переходе от VRRPv2 к VRRPv3 и не оставлять в качестве постоянного решения.

8.4.2. Поддержка взаимодействия с VRRPv2 в VRRPv3

Как отмечено выше такая поддержка предназначена для перехода и не рекомендуется как постоянное решение.

Реализация может использовать флаг конфигурации, указывающий поддержку приёма и передачи анонсов VRRPv2 и VRRPv3.

Когда VR настроен таким образом и является AR, он должен передавать оба типа анонсов с настроенной скоростью, даже если она субсекундная. Настроенный таким образом VR, являющийся BR, должен использовать тайм-аут на основе скорости, анонсированной AR. В случае VRRPv2 AR это означает, что маршрутизатор должен перевести полученное значение тайм-аута (в секундах) в сотые доли секунды. Маршрутизатору BR следует игнорировать анонсы VRRPv2 от текущего AR, если от него приходят и пакеты VRRPv3it. BR может сообщать, что VRRPv3 AR не передаёт пакетов VRRPv2, поскольку это говорит о несогласии поддерживать взаимодействие с VRRPv2.

8.4.2.1. Вопросы взаимодействия
8.4.2.1.1. Медленные AR с высоким приоритетом

Этот вопрос рассмотрен в параграфе 5.2.7.

VRRPv2 AR, взаимодействующий с субсекундным VRRPv3 BR является наиболее важным примером такой ситуации.

Для реализации VRRPv2 не следует задавать приоритет выше, чем у реализации VRRPv2 или VRRPv3 с которой она взаимодействует, при субсекундной скорости передачи анонсов VRRPv2 или VRRPv3.

8.4.2.1.2. Перегрузка резервных маршрутизаторов VRRPv2

Возможно, что VRRPv3 AR, передающий анонсы с субсекундной скоростью, перегрузит VRRPv2 BR с потенциально неопределённым результатом

В случае обновления следует сначала запускать VRRPv3 AR с более низкой частотой анонсов, например, 100 (1 анонс в секунду), пока маршрутизаторы VRRPv2 не будут обновлены. После проверки корректности работы VRRPv3 поддержку VRRPv2 можно отключить и настроить субсекундную скорость передачи.

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

VRRP для IPvX не поддерживает проверки подлинности. Прежние версии VRRP включали несколько типов аутентификации (от её отсутствия до строгой проверки подлинности). Опыт эксплуатации и анализ показали, что это не обеспечивает достаточной защиты для преодоления уязвимости из-за неверно настроенных секретов, что приводило к выбору нескольких AR сразу. В силу особенностей протокола VRRP даже криптографическая защита сообщений VRRP не препятствует враждебным узлам выдавать себя за AR, создавая в сети сразу несколько AR. Аутентификация сообщений VRRP может предотвратить переход всех нормально работающих маршрутизаторов в состояние Backup из-за действий враждебных узлов. Однако наличие нескольких AR может создать больше проблем, чем отсутствие маршрутизаторов, но аутентификация это не препятствует. Даже если враждебный узел не может нарушить работу VRRP, он способен повредить ARP/ND и результат будет таким же, как при переходе всех маршрутизаторов в состояние Backup.

Некоторые коммутаторы L2 способны фильтровать, например, сообщения ARP и/или ND от конечных хостов по портам коммутатора. Этот механизм позволяет фильтровать и сообщения VRRP с портов коммутатора, связанных с конечными хостами, и может рассматриваться для внедрения в сетях с недоверенными хостами.

Следует отметить, что такие атаки являются подмножеством атак, которые может организовать любой подключенный к ЛВС узел независимо от VRRP, включая:

  • неразборчивый (promiscuous) приём пакетов с любого MAC-адреса маршрутизатора;

  • передача пакетов с MAC-адресом маршрутизатора в поле MAC отправителя заголовка L2, чтобы вынудить коммутаторы L2 отправлять адресованные маршрутизатору пакеты вредоносному узлу;

  • отправка перенаправления, указывающих всем хостам направлять свои пакеты в другое место;

  • передача незапрошенных откликов ND;

  • отклики на запросы ND и т. п.

Все означенное может происходить независимо от VRRP и протокол не добавляет уязвимостей, а большинство из них устраняется независимо, например с помощью защищённого обнаружения соседей (SEcure Neighbor Discovery или SEND) [RFC3971].

VRRP включает механизм (установка значения 255 в IPv4 TTL и IPv6 Hop Limit и проверка при получении), защищающий от внедрения пакетов VRRP из удалённой сети [RFC5082]. Это ограничивает возможности атак.

VRRP не обеспечивает конфиденциальности, которая и не требуется для корректной работы протокола. В сообщениях VRRP нет сведений, которые нужно хранить в секрете от других узлов ЛВС.

В контексте IPv6 при наличии SEND протокол VRRP совместим с режимами SEND trust anchor (привязка доверия) и trust anchor or CGA (привязка доверия или CGA) [RFC3971]. В настройках SEND нужно предоставлять маршрутизаторам AR и BR одинаковое делегирование префиксов, чтобы те и другие анонсировали общий набор префиксов подсети. Однако AR и BR следует иметь свои пары ключей, чтобы избежать применения общего секретного ключа.

В контексте IPv6 рекомендуется следовать руководству по защите из параграфа 2.3 в [RFC9099].

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

Агентство IANA обновило в своих реестрах ссылки на [RFC5798] ссылками на данный документ, как указано ниже.

Выделено значение 112 для VRRP в реестре Assigned Internet Protocol Numbers.

В реестре Local Network Control Block (224.0.0.0 — 224.0.0.255 (224.0.0/24)) внутри IPv4 Multicast Address Space Registry [RFC5771] агентство IANA выделило для VRRP групповой адрес IPv4 224.0.0.18.

В реестре Link-Local Scope Multicast Addresses внутри IPv6 Multicast Address Space Registry [RFC3307] агентство IANA выделило групповой адрес IPv6 link-local ff02:0:0:0:0:0:0:12 для VRRP с протоколом IPv6.

В реестре IANA MAC ADDRESS BLOCK [RFC9542] агентство IANA выделило блоки индивидуальных адресов Ethernet, приведённые в таблице 1 (в шестнадцатеричном формате).

Таблица .

 

Адреса

Использование

Документ

00-01-00 — 00-01-FF

VRRP (Virtual Router Redundancy Protocol)

RFC 9568

00-02-00 — 00-02-FF

VRRP IPv6 (Virtual Router Redundancy Protocol IPv6)

RFC 9568

 

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

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

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

[RFC3307] Haberman, B., «Allocation Guidelines for IPv6 Multicast Addresses», RFC 3307, DOI 10.17487/RFC3307, August 2002, <https://www.rfc-editor.org/info/rfc3307>.

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

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

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

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

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, «IANA Guidelines for IPv4 Multicast Address Assignments», BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <https://www.rfc-editor.org/info/rfc5771>.

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

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, <https://www.rfc-editor.org/info/rfc9542>.

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

[IPSTB] Higginson, P. and M. Shand, «Development of Router Clusters to Provide Fast Failover in IP Networks», Digital Technical Journal, Volume 9, Number 3, 1997.

[NISTIR8366] National Institute of Standards and Technology (NIST), «Guidance for NIST Staff on Using Inclusive Language in Documentary Standards,», NISTIR 8366, DOI 10.6028/NIST.IR.8366, April 2021, <https://doi.org/10.6028/NIST.IR.8366>.

[RFC1071] Braden, R., Borman, D., and C. Partridge, «Computing the Internet checksum», RFC 1071, DOI 10.17487/RFC1071, September 1988, <https://www.rfc-editor.org/info/rfc1071>.

[RFC1256] Deering, S., Ed., «ICMP Router Discovery Messages», RFC 1256, DOI 10.17487/RFC1256, September 1991, <https://www.rfc-editor.org/info/rfc1256>.

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.

[RFC2281] Li, T., Cole, B., Morton, P., and D. Li, «Cisco Hot Standby Router Protocol (HSRP)», RFC 2281, DOI 10.17487/RFC2281, March 1998, <https://www.rfc-editor.org/info/rfc2281>.

[RFC2328] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, «Virtual Router Redundancy Protocol», RFC 2338, DOI 10.17487/RFC2338, April 1998, <https://www.rfc-editor.org/info/rfc2338>.

[RFC2453] Malkin, G., «RIP Version 2», STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

[RFC3768] Hinden, R., Ed., «Virtual Router Redundancy Protocol (VRRP)», RFC 3768, DOI 10.17487/RFC3768, April 2004, <https://www.rfc-editor.org/info/rfc3768>.

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

[RFC4311] Hinden, R. and D. Thaler, «IPv6 Host-to-Router Load Sharing», RFC 4311, DOI 10.17487/RFC4311, November 2005, <https://www.rfc-editor.org/info/rfc4311>.

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

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

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

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

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, «Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6», RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.

[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, «Operational Security Considerations for IPv6 Networks», RFC 9099, DOI 10.17487/RFC9099, August 2021, <https://www.rfc-editor.org/info/rfc9099>.

[RFC9131] Linkova, J., «Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers», RFC 9131, DOI 10.17487/RFC9131, October 2021, <https://www.rfc-editor.org/info/rfc9131>.

[VRRP-IPv6] Hinden, R. and J. Cruz, «Virtual Router Redundancy Protocol for IPv6», Work in Progress, Internet-Draft, draft-ietf-vrrp-ipv6-spec-08, 5 March 2007, <https://datatracker.ietf.org/doc/html/draft-ietf-vrrp-ipv6-spec-08>.

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

Текст для IPv6 в этой спецификации основан на [RFC2338], авторами которого являются S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. Авторы [VRRP-IPv6] признательны Erik Nordmark, Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh Gupta, Don Provan, Mark Hollinger, John Cruz, Melissa Johnson за их полезные предложения.

Текст для IPv4 в этой спецификации основан на [RFC3768]. Авторы спецификации благодарны Glen Zorn, Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve M. Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman, Russ Housley, Harald Alvestrand, Ned Freed, Ted Hardie, Bert Wijnen, Bill Fenner, Alex Zinin за их комментарии и предложения.

Спасибо Steve Nadas за работу по объединению и редактированию [RFC3768] и [VRRP-IPv6], приведшему в итоге к [RFC5798].

Спасибо Stewart Bryant, Sasha Vainshtein, Pascal Thubert, Alexander Okonnikov, Ben Niven-Jenkins, Tim Chown, Mališa Vučinić, Russ White, Donald Eastlake, Dave Thaler, Eric Kline, Vijay Gurbani за комментарии к текущему документу (RFC 9568). Спасибо Gyan Mishra, Paul Congdon, Jon Rosen за обсуждения, связанные с исключением приложений для устаревших технологий. Спасибо Dhruv Dhody и Donald Eastlake за комментарии и предложения для улучшения раздела IANA. Спасибо Sasha Vainshtein за рекомендации по проверке Maximum Advertisement Interval. Спасибо Tim Chown и Fernando Gont за дискуссии и обновления, связанные с IPv6 SLAAC. Особая благодарность Quentin Armitage за подробную рецензию и обширные комментарии к текущему документу (RFC 9568).

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

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
 
Aditya Dogra
Cisco Systems
Sarjapur Outer Ring Road
Bangalore 560103
Karnataka
India
Email: addogra@cisco.com

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

nmalykh@protokols.ru


1В оригинале ошибочно указан MAC-адрес, см. https://www.rfc-editor.org/errata/eid7947. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 9557 Date and Time on the Internet: Timestamps with Additional Information

Internet Engineering Task Force (IETF)                         U. Sharma
Request for Comments: 9557                                  Igalia, S.L.
Updates: 3339                                                 C. Bormann
Category: Standards Track                         Universität Bremen TZI
ISSN: 2070-1721                                               April 2024

Date and Time on the Internet: Timestamps with Additional Information

Даты и время в Internet — временные метки с дополнительной информацией

PDF

Аннотация

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

Документ обновляет RFC 3339 в части интерпретации локального смещения Z, которое больше не считается «подразумевающим, что UTC является предпочтительной точкой отсчёта для указанного времени».

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

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

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

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

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

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

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

1. Ведение

Даты и время применяются в самых разных приложениях Internet — от ведения журналов на серверах до создания календарей и расписаний.

Каждый момент времени может быть представлен в описательном текстовом формате с использованием временной метки. В [ISO8601-1:2019] стандартизован широко применяемый формат временных меток, а ранняя версия стандарта [ISO8601:1988] стала основой для формата дат и времени в Internet [RFC3339]. Однако этот формат очень ограничивает включение в метки дополнительной информации. Кроме того, любые контекстные сведения, связанные с данной временной меткой, требуется обрабатывать отдельно или добавлять нестандартным способом.

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

Этот документ задаёт расширение формата временных меток [RFC3339] для представления дополнительных сведений, включая часовой пояс.

Документ обновляет [RFC3339] в части интерпретации локального смещения Z, которое больше не считается «подразумевающим, что UTC является предпочтительной точкой отсчёта для указанного времени» (см. раздел 2).

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

В [RFC3339] задан синтаксис временных меток для представления даты и времени в Internet. Настоящий документ задаёт синтаксис расширения с указанными ниже свойствами.

  • Суффикс расширения не обязателен, что делает метки [RFC3339] совместимыми с новым форматом.

  • Формат совместим с имеющимся популярным синтаксисом для добавления в метки времени имён часовых поясов [JAVAZDT].

  • Формат обеспечивает обобщенный способ добавления информации во временные метки.

Этот формат назван расширенным форматом дат и времени Internet (Internet Extended Date/Time Format или IXDTF).

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

  • время в будущем, указанное как местное время в конкретном часовом поясе, когда изменения в определении этого часового пояса (такие, как политические решения о введении или отмене перехода на сезонное время) влияют на момент, представляемый временной меткой;

  • «плавающее время», т. е. местное время без указания смещения от UTC или часового пояса, в котором следует интерпретировать время;

  • использование временных шкал, отличающихся от UTC, например, международных атомных часов (International Atomic Time или TAI).

Однако дополнительных сведений в фиксированной временной метке может быть достаточно для обнаружения несоответствия между намерением и фактическими данными временной метки, такими как смещение от UTC или имя часового пояса. Несоответствия могут возникать, например, в результате:

  • политических решений, как отмечено выше;

  • обновления определения часовых поясов, применяемые в разное время создателями и получателями временных меток;

  • ошибок в программах, создающих и применяющих временные метки.

Хотя сведений из строки IXDTF в общем случае не достаточно для исправления несоответствий, они могут служить для инициирования отдельной (out-of-band) обработки с целью получения нужных для устранения несоответствия данных.

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

1.2. Определения

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

UTC

Всемирное координированное время (Coordinated Universal Time), поддерживаемое с 1988 г. Международным бюро мер и весов (Bureau International des Poids et Mesures или BIPM) с учётом високосных секунд, указываемых Международной службой вращения земли и эталонных систем (International Earth Rotation and Reference Systems Service) [IERS]. С 1972 г. до 1987 г поддержка UTC полностью обеспечивалась Международным бюро времени (Bureau International de l’Heure или BIH). До 1972 г. не было общего признания UTC и гражданское время определялось отдельными юрисдикциями, использующими разные методы, чтобы пытаться следовать Мировому времени (Universal Time) на основе измерений вращения Земли.
UTC часто ошибочно называют GMT (Greenwich Mean Time — среднее время по Гринвичу) — более ранней шкалой времени, преемником которой является UTC.

ABNF

Дополненная форма Бэкуса-Наура (Augmented Backus-Naur Form) — формат, применяемый для представления допустимых строка протокола или языка, как определено в [RFC5234]. Правила Приложения B к [RFC5234] импортируются неявно.

IXDTF

Расширенный формат дат и времени Internet (Internet Extended Date/Time Format), заданный в разделе 4.

Timestamp — временная метка

Однозначное представление определённого момента времени.

UTC Offset — смещение от UTC

Разница между местным временем и UTC, обычно указываемая положительным или отрицательным числом часов и минут. Например, местное время в городе Нью-Йорк (New York, NY, USA) зимой 2023 г. отставало на 5 часов от UTC, поэтому смещение UTC было -05:00.

Z

Суффикс, который применительно ко времени означает смещение от UTC 00:00. Обычно произносится как Zulu по фонетическому представлению буквы Z в алфавите ICAO. Определение взято из раздела 2 в [RFC3339], фонетический алфавит описан в документе Международной организации гражданской авиации (International Civil Aviation Organization или ICAO) [ICAO-PA].

Time Zone — часовой пояс

Набор правил, представляющих соотношение местного времени и UTC для определённого места или региона. Математически часовой пояс можно представить как функцию, сопоставляющую временные метки со смещением от UTC. Часовой пояс позволяет детерминировано преобразовать временную метку в местное время. Можно применять часовой пояс для обратного преобразования с учётом того, что местное время может иметь несколько разных временных меток вблизи перехода на сезонное время или иных изменений смещения от UTC для данного часового пояса. В отличие от смещения от UTC во временной метке, где не принимается каких-либо допущений о смещении от UTC других связанных временных меток (что не позволяет применять его для операций с локальным временем, таких как «на 1 день позже»), часовой пояс определяет также способ получения новых временных меток на основе разницы в местном времени. Например, для расчёта времени «на один день позже данной метки в Сан-Франциско (Калифорния), нужен часовой пояс, поскольку смещение от UTC местного времени в Сан-Франциско может меняться от одного дня к другому.

IANA Time Zone — часовой пояс IANA

Именованный часовой пояс, включенный в базу данных часовых поясов (Time Zone Database), часто обозначаемую tz или zoneinfo, которые поддерживает IANA [TZDB] [BCP175]. Большинство часовых поясов IANA названо по крупнейшему городу определённого региона в рамках одним правил часового пояса, например, Europe/Paris или Asia/Tokyo [TZDB-NAMING].
Правила, заданные для именованных часовых поясов IANA, могут меняться с течением времени. Использование именованных часовых поясов IANA предполагает следование правилам, действующим на момент интерпретации. Дополнительные сведения, передаваемые с использованием имён часовых поясов меняются при изменении правил, занесённом в IANA Time Zone Database.

Offset Time Zone — часовой пояс со смещением

Часовой пояс, указанный конкретным смещением от UTC (например, +08:45) и сериализованный с использованием в качестве имени того же формата численного смещения от UTC, который применяется во временной метке [RFC3339], например, 2022-07-08T00:14:07+08:45[+08:45]
Смещение в суффиксе, не повторяющее смещение во временной метке, является несогласованным (см. параграф 3.4).
Хотя сериализация часовых поясов со смещением поддерживается в этом документе для совместимости с прежними версиями java.time.ZonedDateTime [JAVAZDT], использовать часовые пояса со смещением настоятельно не рекомендуется. В частности, программам недопустимо копировать смещение от UTC из метки в смещение часового пояса для выполнения требования других программ, которым нужен на входе суффикс часового пояса. Это будет приводить к некорректному допущению о неисзменности смещения от UTC временных меток в данном месте, что может привести к ошибкам расчётов в программах, которые выводят временные метки из полученных путём сложения, вычитания или иных операций. Например, 2020-01-01T00:00+01:00[Europe/Paris] позволяет программам добавить шесть месяцев к временной метке с поправкой на летнее время. Однако такой же расчёт, применённый к 2020-01-01T00:00+01:00[+01:00], даст некорректный результат, который будет отставать на 1 час от времени часового пояса Europe/Paris.

CLDR

Common Locale Data Repository [CLDR] — проект консорциума Unicode для предоставления приложениям данных о локальных настройках (locale data).

Дополнительные сведения о шкалах времени приведены в Приложении E к [RFC1305], разделе 3 в [ISO8601:1988] и соответствующих документах ITU [ITU-R-TF.460-6] (отметим, что [RFC1305] был заменён [RFC5905], где нет приложения E, упомянутого здесь).

2. Обновление RFC 3339

2.1. Основания

В параграфе 4.3 [RFC3339] сказано, что смещение, указанное как Z или +00:00, предполагает, что «UTC является предпочтительной точкой отсчёта для указанного времени». Смещение -00:00 указывает, что «известно время UTC, но неизвестно смещение локального времени».

Это соглашение отражает похожее соглашение для сведений о дате и времени в сообщениях электронной почты, описанное в параграфе 3.3 [RFC5322] и введённое ранее в параграфе 3.3 [RFC2822]. Это соглашение для заголовков электронной почты применяется на практике, тогда как его адаптация в [RFC3339] всегда оставалась затруднительной из-за того, что [ISO8601:2000] и более поздние версии фактически не допускают использование -00:00.

Поэтому реализации, которым нужно выразить семантику -00:00, обычно использовали вместо этого Z.

2.2. Изменения в RFC 3339

Эта спецификация обновляет параграф 4.3 в [RFC3339], приводя его в соответствие с фактической практикой интерпретации смещения Z как -00:00: «известно время UTC, но неизвестно смещение локального времени».

Параграф 4.3 в [RFC3339] в новой редакции следует представлять как указано ниже.

Если известно время в UTC, но смещение местного времени не известно, это может быть представлено как смещение Z (в исходной спецификации для этого указано смещение -00:00, которое не разрешено в [ISO8601:2000] и поэтому не обеспечивает функциональной совместимости; в параграфе 3.3 [RFC5322] описано похожее соглашение для электронной почты, которое не вызывает проблем). Семантически это отличается от смещения +00:00, которое предполагает, что UTC является предпочтительной точкой отсчёта для указанного времени.

2.3. Примечания

Отметим, что семантика локального смещения +00:00 не изменилась, оно по-прежнему означает, что UTC является предпочтительной точкой отсчёта для указанного времени.

Отметим также, что факт запрета в [ISO8601:2000] и последующих вресиях стандарта использовать -00:00 в качестве локального смещения снижает функциональную совместимость, которая может обесчпечиваться при использовании этого свойства, однако данная спецификация формально не запрещает этот синтаксис. С учётом обновления [RFC3339] вместо этого следует применять суффикс локального смещения Z.

3. Расширенный формат даты и времени в Internet (IXDTF)

В этом разделе обсуждаются желаемые качаства суффикса расширения временных меток и определяется формат IXDTF, расширяющий [RFC3339] для использования в протоколах Internet.

3.1. Формат расширенной информации

Формат позволяет приложениям добавлять дополнительные важные сведения к обычным временным меткам [RFC3339]. Это делается путём определения тегов с ключом и значением через знак равенства (=). Значением тега может быть один или несколько элементов, разделённых символом дефиса (знака вычитания). Приложения могут создавать информационные суффиксы временных меток с любым числом таких тегов. В ключах используются только символы нижнего регистра. В значениях регистр символов учитывается, если не указано иное. Обработка несогласованных сведений в суффиксах рассматривается в параграфе 3.3.

3.2. Ключи регистрации для тегов расширенной информации

Ключи тегов суффиксов регистрируются с предоставлением сведений, указанных в этом параграфе. Эта информация задана по образу используемой в реестре Media Types [RFC6838] и при возникновении сомнений следует применять положения для этого реестра.

Key Identifier

Ключ (в соответствии с suffix-key из параграфа 4.1).

Registration Status

Статус регистрации — временная (Provisional) или постоянная (Permanent).

Description

Очень краткое описание ключа.

Change Controller

Контролёр изменений — лицо, отвечающее за спецификацию, регулирующую значения этого ключа. Эти сведения могут включать адрес электронной почты, списки рассылки или ссылки на соответствующие web-страницы (URL).

Reference

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

Имена ключей, начинающиеся с символа подчёркивания (_), предназначены для экспериментов в контролируемых средах и не могут регистрироваться. Такие ключи недопустимо использовать для обмена и они должны отвергаться реализациями, не включёнными в такие эксперименты. Опасности утечки экспериментальных ключей в среды общего пользования и необходимости предотвращения таких утечек таких утечек рассматриваются в [BCP178].

3.3. Необязательность, выборочность и критичность тегов

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

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

Суффиксный тег может указывать свою критичность. Это говорит получателю, что недопустимо действовать со строкой IXDTF, пока не обработан указанный тег. Критичный суффиксный тег указывается восклицательным знаком (!) после открывающей скобки (см. critical-flag в параграфе 4.1).

Строка IXDTF вида 2022-07-08T00:14:07+01:00[Europe/Paris] внутренне противоречива (см. параграф 3.4), поскольку Europe/Paris не использует часовой пояс со смещением +01:00 в июле 2022 г. Однако подсказка часового пояса в суффиксном теге является выборочной и получатель не обязан реагировать на несоответствие, он может рассматривать строку IXDTF как 2022-07-08T00:14:07+01:00

В соответствии с разделом 2 (см. также параграф 3.4) строка IXDTF 2022-07-08T00:14:07Z[Europe/Paris] не показывает несоответствия, поскольку локальное смещение Z не предполагает конкретного часого пояса при интерпретации. Применение правил Time Zone Database для Europe/Paris летом 2022 делает её эквивалентом 2022-07-08T02:14:07+02:00[Europe/Paris]

Неизвестный суффикс вида 2022-07-08T00:14:07+01:00[knort=blargel] можно игнорировать полностью (в предположении непонимания ключа knort).

В отличие от избирательного использования суффксного тена строки вида

   2022-07-08T00:14:07+01:00[!Europe/Paris]
   2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese]
   2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese]
   2022-07-08T00:14:07Z[!knort=blargel]

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

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

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

   2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
   2022-07-08T00:14:07Z[u-ca=chinese]

будут считаться одинаковыми.

3.4. Несогласованность time-offset и сведений о часовом поясе

Временная метка [RFC3339] может включать значение time-offset, указывающее разницу между местным временем и UTC (см. раздел 4 в [RFC3339] с учётом изменений, внесённых в разделе 2 этой спецификации в параграф 4.3 [RFC3339]). Сведения, указанные значением time-offset, могут не соответствовать информации, представленной суффиксом часового пояса для метки IXDTF. Например, приложение-календарь может хранить строку IXDTF, представляющую встречу в далёком будущем в определённом часовом поясе. Если затем определение часового пояса будет изменено, исходно согласованные строки IXDTF могут стать несогласованными.

При установленном флаге критичности и несоответствии time-offset суффиксу часового пояса приложение должно реагировать на несоответствие. Если флаг критичности не установлен, приложение может реагировать на несоответствие. Реакция на несоответствие может включать отклонение временной метки или устранение несоответствия с использованием дополнительной информации, например, ввода данных от пользователя или запрограммированного поведения.

Временные метки IXDTF на рисунке 1 представляют время 00:14:07 UTC, указывая местное время с time-offset +00:00. Однако в часовом поясе Europe/London в июле 2022 г. используется смещение +01:00, поэтому временные метки будут несогласованными, причём в первом случае приложение должно реагировать на несоответствие (критический суффикс часового пояса), а во втором — может реагировать на несоответствие (выборочный суффикс).

В

2022-07-08T00:14:07+00:00[!Europe/London]
2022-07-08T00:14:07+00:00[Europe/London]

Рисунок . Несогласованность меток IXDTF.


соответствии с параграфом 4.3 [RFC3339], обновлённым в разделе 2, временные метки IXDTF могут не включать сведения о местном времени в часть [RFC3339], просто используя Z вместо числового смещения часового пояса. Временные метки IXDTF на рисунке 2 (то же время, что и в строках рисунка 1) являются несогласованными, поскольку они не указывают ни местного времени, ни местного смещения в своей части [RFC3339]. Приложения, получающие такие строки, могут местное смещение и время, используя правила для суффикса часового пояса. Например, суффикс Europe/London на рисунке 2 (как и на рисунке 1), может быть помечен как критический (т. е. приложение должно понимать сведения о часовом поясе) или является выборочным, представляющим лишь дополнительные сведения.

О

2022-07-08T00:14:07Z[!Europe/London]
2022-07-08T00:14:07Z[Europe/London]

Рисунок . Согласованность меток IXDTF.


тметим, что вместо Z можно использовать -00:00, поскольку они имеют одинаковый смысл в соответствии с разделом 2, но [ISO8601:2000] не разрешает -00:00, поэтому предпочтительно использовать Z.

4. Синтаксические расширения RFC 3339

4.1. ABNF

Ниже приведены правила, расширяющие синтаксис ABNF, заданный в [RFC3339], для включения необязательного суффикса. Расширенный формат дат и времени Internet (IXDTF) описывается правилом date-time-ext. Элементы date-time и time-numoffset взяты из параграфа 5.6 в [RFC3339], а ALPHA и DIGIT из Приложения B.1 к [RFC5234].

   time-zone-initial = ALPHA / "." / "_"
   time-zone-char    = time-zone-initial / DIGIT / "-" / "+"
   time-zone-part    = time-zone-initial *time-zone-char
                       ; но не . или ..
   time-zone-name    = time-zone-part *("/" time-zone-part)
   time-zone         = "[" critical-flag
                           time-zone-name / time-numoffset "]"

   key-initial       = lcalpha / "_"
   key-char          = key-initial / DIGIT / "-"
   suffix-key        = key-initial *key-char

   suffix-value      = 1*alphanum
   suffix-values     = suffix-value *("-" suffix-value)
   suffix-tag        = "[" critical-flag
                           suffix-key "=" suffix-values "]"
   suffix            = [time-zone] *suffix-tag

   date-time-ext     = date-time suffix

   critical-flag     = [ "!" ]

   alphanum          = ALPHA / DIGIT
   lcalpha           = %x61-7A

Рисунок . Грамматика ABNF для расширений RFC 3339.

Отметим, что time-zone и suffix-tag синтаксически похожи но первый не включает знака равенства (=). Этот особый случай доступен лишь для тегов часовых поясов.

Определению ABNF для time-zone-part соответствуют «.» и «..», которые явно исключены (см. примечание для time-zone-part).

Элемент time-zone-name предназначен быть именем IANA Time Zone. Поскольку генератор и получатель могут использовать разные версии Time Zone Database, получатели могут не знать имени IANA Time Zone и им следует рассматривать такие ситуации как любые другие несоответствия.

Примечание. На момент создания документа размер time-zone-part был ограничен 14 символами правилами из [TZDB-NAMING]. Одна платформа может соблюдать это ограничение, а другая использовать более длинные имена. Поскольку time-zone-name в конечном итоге приходится искать в локальной базе данных, создание time-zone-part на рисунке 3 намеренно сделано разрешительным.

4.2. Примеры

В этом параграфе приведены некоторые примеры расширенного формата дат и времени Internet (IXDTF).

Н

1996-12-19T16:39:57-08:00

Рисунок . Дата и время RFC 3339 со смещением часового пояса.


а рисунке 4 представлен момент 39 минут 57 секунд после 16 часов 19 декабря 1996 г. со смещением -08:00 от UTC. Отметим, что это совпадает с моментом 1996-12-20T00:39:57Z, выраженным в UTC.

Н

1996-12-19T16:39:57-08:00[America/Los_Angeles]

Рисунок . Добавление имени часового пояса.


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

Н

1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

Рисунок . Проектирование для еврейского календаря.


а рисунке 6 представлен тот же момент, но он информирует осведомленные о календаре приложения (см. раздел 5), что им следует отображать это время на еврейский календарь.

Н

1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]

Рисунок . Добавление экспериментальных тегов.


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

5. Ключ u-ca — осведомлённость о календаре

Суффикс u-ca предназначен для указания календаря, предпочтительного для представления даты и времени. Календарь — это набор правил, определяющих учёт и использование дат реализациями. Набор значений суффиксов, разрешённых для этого ключа — это значения, определённые для идентификатора календаря Unicode (Calendar Identifier) [TR35]. В [CLDR-LINKS] приведены ссылки на наиболее свежие данные о [CLDR], как стабильные, так и находящиеся в разработке.

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

Агентство IANA создало реестр Timestamp Suffix Tag Keys в новой группе реестров Internet Date/Time Format. В каждую запись реестра следует включать сведения, указанные в параграфе 3.2. Исходное содержимое реестра приведено в таблице 1.

Таблица . Исходное содержимое реестра Timestamp Suffix Tag Keys.

Идентификатор ключа

Статус регистрации

Описание

Контролёр изменений

Документ

u-ca

постоянная

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

IETF

раздел 5 в RFC 9557

Регистрация выполняется по процедуре Specification Required [BCP26] для постоянных записей и Expert Review — для временных. В последнем случае экспертам следует убедиться в наличии базовой спецификации, даже если она ещё не опубликована. Экспертам также следует экономно распределять идентификаторы ключей, указывающих на общеприменимую семантику, сохраняя их в резерве для случаев потенциально широкого использования, когда могут обеспечиваться преимущества за счёт коротких ключей. Если эксперты узнают о внедрении и использовании ключа, они могут сами инициировать регистрацию, чтобы предотвратить возможные в будущем конфликты.

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

7.1. Избыточное раскрытие

Возможность включать во временные метки различные элементы дополнительной информации может приводить к избыточному раскрытию, пример чего представлен в разделе 7 [RFC3339]. Раскрытие сведений о календарной системе или выбранном языке может давать больше информации о создателе временной метки, чем разрешает принцип минимизации данных [DATA-MINIMIZATION]. В более общем смысле создателям временных меток IXDTF нужно рассмотреть уместность раскрытия информации во временных метках получателям и принять решение о минимизации такого раскрытия, если получатели меток не находятся под контролем их создателя.

7.2. Уязвимости реализаций формата данных

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

7.3. Работа с несогласованными данными

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

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

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

[BCP175] Best Current Practice 175, <https://www.rfc-editor.org/info/bcp175>. На момент написания этого документа: Lear, E. and P. Eggert, «Procedures for Maintaining the Time Zone Database», BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <https://www.rfc-editor.org/info/rfc6557>.

[BCP178] Best Current Practice 178, <https://www.rfc-editor.org/info/bcp178>. На момент написания этого документа: Saint-Andre, P., Crocker, D., and M. Nottingham, «Deprecating the «X-» Prefix and Similar Constructs in Application Protocols», BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.

[BCP26] Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>. На момент написания этого документа: Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

[RFC3339] Klyne, G. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

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

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

[CLDR] Unicode CLDR, «Unicode CLDR Project», <https://cldr.unicode.org>.

[CLDR-LINKS] Unicode CLDR, «Stable Links Info», <https://cldr.unicode.org/stable-links-info>.

[DATA-MINIMIZATION] Arkko, J., «Emphasizing data minimization among protocol participants», Work in Progress, Internet-Draft, draft-arkko-iab-data-minimization-principle-05, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-arkko-iab-data-minimization-principle-05>.

[ICAO-PA] International Civil Aviation Organization, «Annex 10 to the Convention on International Civil Aviation: Aeronautical Telecommunications; Volume II Communication Procedures including those with PANS status», 7th ed., July 2016, <https://store.icao.int/annex-10-aeronautical-telecommunications-volume-ii-communication-procedures-including-those-with-pans-status>.

[IERS] IERS, «International Earth Rotation Service Bulletins», <https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html>.

[ISO8601-1:2019] ISO, «Date and time — Representations for information interchange — Part 1: Basic rules», ISO 8601-1:2019, February 2019, <https://www.iso.org/standard/70907.html>.

[ISO8601:1988] ISO, «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO 8601:1988, June 1988, <https://www.iso.org/standard/15903.html>. Also available from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf>.

[ISO8601:2000] ISO, «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO 8601:2000, December 2000, <https://www.iso.org/standard/26780.html>.

[ITU-R-TF.460-6] ITU-R, «Standard-frequency and time-signal emissions», ITU-R Recommendation TF.460-6, February 2002, <https://www.itu.int/rec/R-REC-TF.460/en>.

[JAVAZDT] Oracle, «Class DateTimeFormatter: ISO_ZONED_DATE_TIME», <https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.

[RFC1305] Mills, D., «Network Time Protocol (Version 3) Specification, Implementation and Analysis», RFC 1305, DOI 10.17487/RFC1305, March 1992, <https://www.rfc-editor.org/info/rfc1305>.

[RFC2822] Resnick, P., Ed., «Internet Message Format», RFC 2822, DOI 10.17487/RFC2822, April 2001, <https://www.rfc-editor.org/info/rfc2822>.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[TR35] Davis, M., Ed., «Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML)», <https://www.unicode.org/reports/tr35/#UnicodeCalendarIdentifier>.

[TZDB] IANA, «Time zone and daylight saving time data», <https://data.iana.org/time-zones/tz-link.html>.

[TZDB-NAMING] IANA, «Theory and pragmatics of the tz code and data», <https://data.iana.org/time-zones/theory.html>.

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

Эта спецификация использует результаты ECMA TC39, в частности для предложения Temporal (временное).

Richard Gibson и Justin Grant внесли редакторские улучшения. Руководители рабочей группы SEDATE Chairs Mark McFadden и Bron Gondwana (последний также был руководителем CALEXT) помогли организовать структуры, нужные для работы в среде с несколькими SDO. John Klensin критически отнёсся к разработке этой спецификации, что привело к её существенному улучшению. Авторы особенно признательны Francesca Palombini за её общее руководство и рецензию AD.

Участник работы

Justin Grant
Email: justingrant.ietf.public@gmail.com

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

Ujjwal Sharma
Igalia, S.L.
Bugallal Marchesi, 22, 1º
15008 A Coruña
Spain
Email: ryzokuken@igalia.com
 
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9567 DNS Error Reporting

Internet Engineering Task Force (IETF)                         R. Arends
Request for Comments: 9567                                     M. Larson
Category: Standards Track                                          ICANN
ISSN: 2070-1721                                               April 2024

DNS Error Reporting

Отчёты об ошибках DNS

rfc9567

Аннотация

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

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

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

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

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

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

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

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

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

1. Введение

При обслуживании полномочным сервером устаревшей зоны с подписью DNSSEC криптографические подписи для наборов записей о ресурсах (resource record set или RRset) могут теряться и проверяющий распознаватель не сможет подтвердить эти записи. Аналогичная ситуация возникает и при несоответствии записей подписавшего делегирование (Delegation Signer или DS) в родительской зоне ключу подписи в дочерней зоне.

Эти два случая отказов могут в течение некоторого времени оставаться незаметными для оператора зоны.

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

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

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

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

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

В документе применяется терминология DNS из BCP 219 [RFC9499], а также определён ряд терминов.

Reporting resolver — информирующий распознаватель

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

Report query — запрос отчета

Запрос DNS, применяемый для отчёта об ошибке. Этот запрос относится к типу записей о ресурсах DNS TXT. Содержимое отчёта кодируется в QNAME запроса DNS к агенту мониторинга.

Monitoring agent — агент мониторинга

Полномочный сервер, получающий запросы отчётов и отвечающий на них. Агент указывается доменным именем (домен агента).

Agent domain — домен агента

Доменное имя, возвращаемое в опции EDNS0 Report-Channel и указывающее, куда распознаватели DNS могут направлять отчёты об ошибках.

4. Обзор

Полномочный сервер указывает поддержку отчётов об ошибках DNS включением в отклик опции EDNS0 Report-Channel с OPTION-CODE=18 и домена агента. Агент указывается полным доменным именем без сжатия в формате передачи DNS. Полномочному серверу недопустимо включать эту опцию в отклик, если имя домена агента пусто или указано null-меткой (указывает корень DNS). Полномочный сервер включает опцию EDNS0 Report-Channel без её запроса, т. е. независимо от наличия этой опции в запросе.

Если полномочный сервер указал поддержку отчётов об ошибках DNS и имеется проблема, о которой можно сообщить с помощью расширенных ошибок DNS, сообщающий распознаватель кодирует отчёт об ошибке в QNAME запроса отчёта. Отвечающий распознаватель создаёт QNAME путём конкатенации метки _er, QTYPE, QNAME, вызвавшего отказ, расширенного кода ошибки DNS (в соответствии с [RFC8914]), ещё одной метки _er и домена агента. Пример представлен в параграфе 4.1, а спецификация — в параграфе 6.1.1. Отметим, что обычный код RCODE не включается, поскольку он не относится к расширенным кодам ошибок DNS. Полученный в результате запрос передаётся отвечающим распознавателем как стандартный запрос DNS для записи TXT.

Запрос отчёта в конечном счёте поступает к агенту мониторинга, возвращающему отклик, который может кэшироваться отвечающим распознавателем. Это кэширование очень важно, поскольку оно снижает число запросов отчётов, передаваемых отвечающим распознавателем для одной и той же проблемы (т. е. при кэшировании отправляется лишь 1 запрос в интервале TTL). Число запросов отчётов об ошибках может быть снижено путём оптимизаций, пдобных описанным в [RFC8020] и [RFC8198].

В этом документе не даётся рекомендаций по содержимому RDATA в записях TXT.

4.1. Пример

Отвечающий распознаватель передаёт для имени broken.test. запрос тип A. Домен test. размещён на нескольких полномочных серверах, один из которых обслуживает устаревшую версию зоны (test.). На этом сервере задан домен агента a01.agent-domain.example. При получении этим сервером запроса для broken.test. он будет передавать отклик с опцией EDNS0 Report-Channel и доменным именем a01.agent- domain.example.

Отвечающий распознаватель не сможет проверить broken.test. RRset для типа A (тип 1 для RR), поскольку запись RRSIG является просроченной. Распознаватель создаёт QNAME _er.1.broken.test.7._er.a01.agent-domain.example. и распознает это имя. QNAME указывает расширенную ошибку DNS 7, возникшую при попытке подтвердить broken.test. для типа A (тип 1 для RR).

При получении этого запроса агентом мониторинга (оператор полномочного сервера для a01.agent-domain.example.) агент может определить, что зона test. содержит просроченную подпись (расширенная ошибка DNS 7) для типа A применительно к имени broken.test.. Агент мониторинга может связаться с операторами test. для исправления ошибки.

5. Спецификация опции EDNS0

Метод использует опцию EDNS0 [RFC6891] для указания домена агента в откликах DNS, как показано на рисунке.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION-CODE = 18       |       OPTION-LENGTH           |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/                         AGENT DOMAIN                          /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

OPTION-CODE

2-октетный код EDNS0, используемый в опции EDNS0 для индикации поддержки отчётов об ошибках. Этот код опции EDNS0 называется Report-Channel.

OPTION-LENGTH

2-октетное значение размера поля AGENT DOMAIN в октетах.

AGENT DOMAIN

Полное доменное имя [RFC9499] в формате передачи DNS без сжатия.

6. Спецификация отчётов об ошибках DNS

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

Класс DNS не указывается в отчётах об ошибках.

6.1. Спецификация отвечающего распознавателя

Следует соблюдать осторожность, если требуется дополнительное распознавание DNS для распознавания QNAME с отчётом об ошибке. Такое распознавание может само по себе вызывать создание ещё одного отчёта об ошибке. Для предотвращения каскада ошибок должно устанавливаться ограничение максимального расхода или глубины.

В запросы недопустимо включать опцию EDNS0 Report-Channel.

Отвечающему распознавателю недопустимо использовать отчёт об ошибках DNS, если полномочный сервер вернул пустое поле AGENT DOMAIN в опции EDNS0 Report-Channel.

Чтобы агент мониторинга имел большую уверенность в достоверности отчёта, отвечающему распознавателю следует передавать отчёты об ошибках по протоколу TCP [RFC7766] или иному протоколу с явным соединением, а также следует использовать DNS Cookie [RFC7873]. Это затруднит подмену адреса источника.

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

6.1.1. Создание запроса отчёта

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

  • Метка, содержащая строку _er.

  • QTYPE из запроса, вызвавшего расширенную ошибку DNS, в виде десятичного значения в одной метке DNS. При наличии в запросе дополнительных QTYPE, как описано в [MULTI-QTYPES], они представляются уникальными упорядоченными десятичными значениями через дефис (-). Например при наличии в запросе QTYPE A и AAAA они представляются как метка 1-28.

  • Список непустых меток, представляющих имя запроса, вызвавшего отчёт об ошибке DNS.

  • Расширенный код ошибки DNS, представленный десятичным значением в одной метке DNS.

  • Метка, содержащая строку _er.

  • Домен агента, полученный в опции EDNS0 Report-Channel от полномочного сервера.

Передача запроса отчёта с QNAME размером более 255 октетов недопустима.

Метки _er позволяют агенту мониторинга отличать домен агента и имя в вызвавшем ошибку запросе. Если домен агента указан пустым именем или null-меткой (несмотря на запрет этого данной спецификацией), запрос отчёта будет иметь _er в качестве домена верхнего уровня, а не домен верхнего уровня из вызвавшего ошибку запроса. Назначение первой метки _er состоит в индикации получения полного запроса отчёта (а не сокращённого путём минимизации).

6.2. Спецификация полномочного сервера

Полномочному серверу недопустимо включать в отклик более одной опции EDNS0 Report-Channel. Полномочный сервер включает в отклики опцию EDNS0 Report-Channel без запроса. Наличие EDNS0 Report-Channel в запросах не требуется.

6.3. Спецификация агента мониторинга

Полномочному серверу для домена агента рекомендуется возвращать позитивный отклик (без NODATA и NXDOMAIN) с записью TXT.

Агенту мониторинга следует отвечать на запросы без DNS Cookie, полученные по протоколу UDP, откликом с битом отсечки (TC), чтобы предложить распознавателю передать запрос по протоколу TCP.

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

Агентство IANA выделило указанный в таблице 1 код в реестре DNS EDNS0 Option Codes (OPT).

Таблица .

 

Значение

Имя

Статус

Документ

18

Report-Channel

Standard

RFC 9567

 

Агентство IANA выделило указанный в таблице 2 код в реестре Underscored and Globally Scoped DNS Node Names.

Таблица .

 

Тип RR

Имя узла

Документ

TXT

_er

RFC 9567

 

8. Вопросы эксплуатации

8.1. Выбор домена агента

Имя домена агента рекомендуется делать достаточно коротким, чтобы в запрос отчёта можно было включить более длинное значение QNAME. В качестве домена агента недопустимо указывать поддомен домена, для которого передаются отчёты. Например, если полномочный сервер обслуживает домен foo.example, недопустимо использовать домен агента с суффиксом foo.example.

8.2. Управление оптимизацией кэширования

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

Если агент мониторинга возвращает NXDOMAIN (ошибка имени), в соответствии с [RFC8020] любое имя в этом домене или его иерархии считается недоступным и негативное кэширование будет предотвращать последующие запросы для всего, что находится в этом домене или его иерархии, на время, определяемое TTL негативного отклика [RFC2308]. Поскольку агент мониторинга может не знать содержимого всех зон, для которых он служит агентом, ему недопустимо передавать NXDOMAIN для отслеживаемых доменов, поскольку это может препятствовать последующим запросам. Одним из методов предотвращения NXDOMAIN является использование шаблонного имени домена [RFC4592] в зоне для домена агента.

При подписанном домене агента распознаватель может использовать интенсивное негативное кэширование (см. [RFC8198]). Эта оптимизация использует записи NSEC и NSEC3 (без opt-out) и позволяет распознавателю синтезировать шаблонные имена. В таких случаях распознаватель не передаёт последующих запросов, поскольку может синтезировать отклик из кэшированных сведений.

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

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

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

Отчёты об ошибках DNS следует выполнять с использованием минимизации имён в запросах DNS [RFC9156] для повышения уровня приватности.

Отчёты DNS выполняются без какой-либо проверки подлинности между отвечающим распознавателем и полномочным сервером домена агента.

Распознавателям следует передавать отчёты об ошибках по протоколу TCP [RFC7766] или использовать DNS Cookie [RFC7873]. Это осложнит подмену адреса отправителя. Агенту мониторинга следует отвечать на полученные по протоколу UDP запросы без DNS Cookie откликом с установленным битом отсечки (TC), чтобы предложить распознавателю передавать запросы по протоколу TCP.

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

Агентам мониторинга, получающим отчёты об ошибках по протоколу UDP, следует учитывать, что адрес отправителя и сам отчёт могут быть поддельными.

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

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

Хотя этот документ не задаёт содержимого RDATA в записях TXT, при записи содержимого RDATA в системный журнал агент мониторинга должен предполагать возможную вредоносность этого содержимого и принимать соответствующие меры для предотвращения использования такого содержимого. Одним из решений является запись в журнал в шестнадцатеричном формате, что позволяет предотвратить возможность исполнения кода, представленного строками, как в уязвимости, описанной в [CVE-2021-44228].

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

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

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

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

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

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

[CVE-2021-44228] CVE, «CVE-2021-44228», 26 November 2021, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228>.

[MULTI-QTYPES] Bellis, R., «DNS Multiple QTYPEs», Work in Progress, Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-multi-qtypes-00>.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/info/rfc4592>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.

[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, «DNS Transport over TCP — Implementation Requirements», RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.

[RFC7873] Eastlake 3rd, D. and M. Andrews, «Domain Name System (DNS) Cookies», RFC 7873, DOI 10.17487/RFC7873, May 2016, <https://www.rfc-editor.org/info/rfc7873>.

[RFC8020] Bortzmeyer, S. and S. Huque, «NXDOMAIN: There Really Is Nothing Underneath», RFC 8020, DOI 10.17487/RFC8020, November 2016, <https://www.rfc-editor.org/info/rfc8020>.

[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, «Aggressive Use of DNSSEC-Validated Cache», RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.

[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, «Extended DNS Errors», RFC 8914, DOI 10.17487/RFC8914, October 2020, <https://www.rfc-editor.org/info/rfc8914>.

[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, «DNS Query Name Minimisation to Improve Privacy», RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/info/rfc9156>.

[RFC9499] Hoffman, P. and K. Fujiwara, «DNS Terminology», BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/info/rfc9499>.

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

Этот документ основан на идее Roy Arends и David Conrad. Авторы благодарны Peter van Dijk, Stephane Bortzmeyer, Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst, Benno Overeinder, Paul Wouters, Petr Spacek за их вклад в работу.

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

Roy Arends
ICANN
Email: roy.arends@icann.org
 
Matt Larson
ICANN
Email: matt.larson@icann.org

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

nmalykh@protokols.ru


1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий