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

RFC 9937 Proportional Rate Reduction (PRR)

Опубликовано 21.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                         M. Mathis
Request for Comments: 9937                                              
Obsoletes: 6937                                              N. Cardwell
Category: Standards Track                                       Y. Cheng
ISSN: 2070-1721                                             N. Dukkipati
                                                            Google, Inc.
                                                           December 2025

Proportional Rate Reduction (PRR)

Пропорциональное снижение скорости

PDF

Аннотация

В этом документа описана стандартная (Standards Track) версия алгоритма пропорционального снижения скорости (Proportional Rate Reduction или PRR), которая отменяет экспериментальную версию, опубликованную в RFC 6937. PRR регулирует объем данных, передаваемых по протоколу TCP или иному транспортному протоколу в процессе ускоренного восстановления (fast recovery). PRR точно регулирует размер находящихся в сети данных (flight size) в процессе восстановления так, что в конце процесса быть как можно ближе к порогу замедленного старта (start threshold или ssthresh), заданному алгоритмом контроля перегрузок.

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

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

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

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

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

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

1. Введение

Принцип сохранения пакетов Ван Якобсона (Van Jacobson) [Jacobson88] задаёт процесс самосинхронизации, где N сегментов данных, доставленных получателю, вызывают генерацию подтверждения, которое отправитель данных использует для синхронизации отправки в сеть других N пакетов данных.

Алгоритмы контроля перегрузок, такие как Reno [RFC5681] и CUBIC [RFC9438], работают на основе такого процесса самосинхронизации. Они контролируют процесс передачи в транспортном соединении, используя окно перегрузки (congestion window или cwnd) для ограничения объёма находящихся в сети (inflight) данных в текущий момент. Кроме того, эти алгоритмы требуют от транспортного соединения снижения cwnd в ответ на потерю пакетов. Алгоритм быстрого восстановления (fast recovery, см. [RFC5681] и [RFC6675]) управляет снижением cwnd на основе обратной связи в виде подтверждений. Заявленная цель состоит в поддержке самосинхронизации отправителя на основе возвращаемых ему в процессе восстановления пакетов ACK для отправки в сеть большего объёма данных. Без пропорционального снижения скорости (PRR) механизм быстрого восстановления обычно регулирует окно, ожидая, пока пройдёт значительная часть времени кругового обхода (RTT) (половина RTT из ACK для Reno [RFC5681] или 30% RTT для CUBIC [RFC9438]) перед отправкой в сеть каких-либо данных.

[RFC6675] делает быстрое восстановление выполняется по селективным подтверждениям (Selective Acknowledgment или SACK) [RFC2018] более точным за счёт оценки отправителем числа байтов, остающихся в сети. В [RFC6675] быстрое восстановление реализуется отправкой данных по мере необходимости в каждом пакете ACK, что обеспечивает возможность увеличения числа остающихся в сети байтов до размера, соответствующего ssthresh — целевому размеру окна для быстрого восстановления, заданному алгоритмом контроля перегрузок. Это предотвращает тайм-ауты быстрого восстановления во многих случаях высокого уровня потерь. Однако [RFC6675] имеет два существенных недостатка. Во-первых, этот механизм вызывает большое мультипликативное сокращение cwnd в начале быстрого восстановления, что может вызывать тайм-аут при потере всей второй половины окна или пакетов ACK. Во-вторых, один пакет ACK с опцией SACK, подразумевающей потерю большого объёма данных, может приводить к ступенчатому разрыву оценки объёма остающихся в сети данных и активировать механизм Fast Retransmit для передачи большого объёма данных.

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

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

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

Когда inflight < ssthresh, PRR адаптивно выбирает один из режимов сокращения (Reduction Bound) для ограничения общего сокращения окна всеми механизмами, включая временные остановки приложений и потери. В качестве базы при сильных перегрузках PRR из осторожности использует консервативное снижение (Conservative Reduction Bound или CRB), которое строго сохраняет пакеты. Когда восстановление представляется проходящим успешно, PRR использует режим снижения замедленного старта (Slow Start Reduction Bound или SSRB), что является более агрессивным по сравнению с PRR-CRB (максимум на 1 сегмент на ACK). PRR-CRB соответствует строгому сохранению пакетов (Strong Packet Conservation Bound), как описано в Приложении A. Однако при использовании в реальных сетях как единственного механизма он работает не так хорошо, как алгоритм, описанный в [RFC6675], который во многих случаях оказывается более агрессивным. PRR-SSRB предлагает компромисс, позволяя в некоторых случаях передавать в соединение 1 дополнительный сегмент на ACK по сравнению с PRR-CRB. Хотя механизм PRR-SSRB менее агрессивен чем [RFC6675] (передаёт меньше сегментов или более медленно), он обеспечивает большую производительность за счёт снижения вероятности дополнительных потерь в процессе восстановления.

В исходном определении принципа сохранения [Jacobson88] пакетов, которые предполагались потерянными (например, помеченные как кандидаты на повтор передачи), считались остающимися в сети. Эта идея отражена в используемой PRR системе оценки остающихся в сети пакетов, но она отличается от Strong Packet Conservation Bound (Приложение A), где оценка выполняется исключительно на основе прибывших к получателю данных.

В этом документе указано несколько основных изменений в исходной версии PRR [RFC6937]. Во-первых, вводится новая адаптивная эвристика взамен настройки вручную параметров, определяющих уровень консервативности PRR при inflight меньше ssthresh (как для PRR-CRB, так и для PRR-SSRB). Во-вторых, алгоритм задаёт поведение соединений без SACK (не согласовавших поддержку SACK [RFC2018] через опцию SACK-permitted). В-третьих, алгоритм обеспечивает сглаженный процесс доставки даже если отправитель часто переупорядочивает данные и начинает восстановление после того, как для значительной части пространства номеров были получены SACK. Кроме того, в документе дополнительно обсуждается интеграция PRR с алгоритмами контроля перегрузок и обнаружения потерь.

Для PRR имеется значительный опыт внедрения в разных реализациях TCP с начала широкого внедрения реализации TCP PRR в 2011 г. [First_TCP_PRR].

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

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

3. Определения

Приведённые ниже термины, параметры и переменные состояния используются в соответствии с определениями предыдущих документов

SND.UNA

Самый старый из неподтвержденных номеров (параграф 3.4 в [RFC9293].

SND.NXT

Следующий номер для передачи (параграф 3.4 в [RFC9293].

duplicate ACK

Подтверждение считается «дубликатом» в описанных здесь алгоритмах, если (a) получатель ACK имеет остающиеся для передачи данные, (b) входящее подтверждение не содержит каких-либо данных, (c) оба флага SYN и FIN сброшены, (d) номер подтверждения равен или превышает значение наибольшего номера подтверждения, полученного в данном соединении (SND.UNA) и (e) анонсируемое во входящем подтверждении окно равно окну, анонсированному в последнем входящем подтверждении (раздел 2 в [RFC5681]).

FlightSize

Количество данных, которые уже переданы, но ещё не подтверждены кумулятивно (раздел 2 в [RFC5681]).

Receiver Maximum Segment Size (RMSS)

RMSS — размер максимального сегмента, который желает принимать получатель. Это значение задаётся в опции MSS, передаваемой получателем при организации соединения (см. параграф 3.7.1 в [RFC9293]). Если опция MSS при организации соединения не была задана, используется значение 536 байтов для IPv4 и 1220 байтов для IPv6 (см. параграф 3.7.1 в [RFC9293]). Размер не включает заголовков и опций TCP/IP. Определение RMSS дано в разделе 2 [RFC5681] и параграфе 3.8.6.3 [RFC9293].

Sender Maximum Segment Size (SMSS)

SMSS представляет собой размер самого большого сегмента, который может быть передан отправителем. Это значение может определяться на основе максимального блока данных, передаваемого через сеть (Maximum Transmission Unit или MTU), алгоритма определения Path MTU [RFC1191] [RFC8201] [RFC4821], RMSS и других факторов. Размер не включает заголовков и опций TCP/IP (раздел 2 в [RFC5681]).

Receiver Window (rwnd)

Последнее анонсированное значение размера окна принимающей стороны в байтах. В любой момент через соединение недопустимо передавать данные с порядковым номером больше SND.UNA + rwnd (раздел 2 в [RFC5681]).

Congestion Window (cwnd)

Переменная состояния TCP, которая ограничивает количество данных, разрешённых протоколу для передачи. В любой момент недопустимо передавать данные, если объем находящихся в сети данных (см. ниже) не меньше cwnd (раздел 2 в [RFC5681]).

Slow Start Threshold (ssthresh)

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

В PRR определяются дополнительные переменные и термины, указанные ниже.

Delivered Data (DeliveredData)

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

In-Flight Data (inflight)

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

Recovery Flight Size (RecoverFS)

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

SafeACK

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

SndCnt

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

Voluntary window reductions — произвольное сокращение окна

Решение не передавать данные в ответ на некоторые ACK с целью сокращения окна передачи и скорости отправки.

4. Отличия от RFC 6937

Самым большим изменением с момента выпуска [RFC6937] является введение новой эвристики которая использует течение процесса восстановления (для TCP, когда последний пакет ACK достигает SND.UNA и не указывает потерю предшествующего ускоренного повтора передачи) для выбора режима сокращения (PRR-CRB или PRR-SSRB). В [RFC6937] выбор режима сокращения оставлен за разработчиками, но рекомендовано по умолчанию применять PRR-SSRB. Для всех сред, рассмотренных в предшествующих исследованиях PRR новая эвристика соответствует этой рекомендации.

В статье «An Internet-Wide Analysis of Traffic Policing» [Flach2016policing] отмечена критическая ситуация, которая не исследовалась ранее, когда оба варианта сокращения работают очень плохо, но по разным причинам. Во многих конфигурациях системы организации трафика на основе маркеров (token bucket) могут внезапно начать отбрасывание значительной части трафика при исчерпании маркеров без выдачи предупреждений конечным системам. Система транспортного контроля перегрузок не имеет возможности измерять скорость расхода маркеров и устанавливает ssthresh на основе ранее наблюдавшейся производительности пути. Такое значение ssthresh может привести к значительному превышению скорости данных над скоростью пополнения маркеров, что приведёт к высоким потерям. В таких условиях оба режима сокращения работают очень плохо. Метод PRR-CRB слишком мягок, что иногда ведёт к очень долгому восстановлению при меньших, чем требуется окнах, а PRR-SSRB слишком агрессивен и часто ведёт к потере множества повторно переданных пакетов в течение нескольких интервалов кругового обхода. Оба случая приводят к длительному восстановлению, ухудшающему задержки в приложениях и/или производительность.

Изучение этих сред привело к разработке эвристики SafeACK для динамического переключения режима сокращения. По умолчанию применяется консервативный метод PRR-CRB, а переключение на PRR-SSRB происходит лишь при указании пакетами ACK успешного хода восстановления (SND.UNA продвигается без новых потерь). Эвристика SafeACK была опробована в сети доставки содержимого Google (Content Delivery Network или CDN) [Flach2016policing] и реализована в Linux TCP с 2015 г.

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

Другое изменение PRR улучшает процесс передачи, когда отправитель переходит к восстановлению после того, как большая часть пространства номеров была подтверждена SACK. Такая ситуация может возникать при предшествующем обнаружении отправителем нарушения порядка доставки, например, с помощью [RFC8985]. В прежней версии PRR переменная RecoverFS некорректно учитывала диапазоны номеров, подтверждённые SACK до начала быстрого восстановления, что вызывало слишком медленную отправку в PRR. Изменение PRR корректно учитывает диапазоны порядковых номеров, подтверждённые SACK до начала быстрого восстановления.

Ещё одно изменение заключается в принудительном повторе передачи по первому пакету ACK, запустившему восстановления. Ранее механизм PRR мог, в зависимости от ситуации с потерями, не разрешать быстрый повтор передачи (т. е. SndCnt = 0) по первому пакету ACK при быстром восстановлении. Форсирование ускоренного повтора передачи важно для поддержки синхронизации ACK и предотвращения возможных тайм-аутов при повторе (retransmission timeout или RTO). Форсированный ускоренный повтор передачи выполняется лишь один раз в процессе восстановления и не нарушает принципов сохранения пакетов PRR. Эта эвристика внедрена в первой широко распространённой реализации TCP PRR в 2011 г. [First_TCP_PRR].

В соответствии с другим изменением, отправитель устанавливает cwnd = ssthresh при выходе из процедуры восстановления. Это важно для отказоустойчивости. Без установки cwnd = ssthresh в конце восстановления, а также с учётом отправителей с ограничениями и некоторых картин потерь, cwnd в конце восстановления может быть ниже ssthresh, что ведёт к снижению производительности. В некоторых случаях производительность может быть ниже, чем при восстановлении [RFC6675], где просто устанавливается cwnd = ssthresh в начале восстановления. Установка cwnd = ssthresh в конце восстановления была внедрена в первой широко распространённой реализации TCP PRR в 2011 г. [First_TCP_PRR] и это похоже на [RFC6675], где устанавливается cwnd = ssthresh в начале восстановления.

С момента публикации [RFC6937] механизм PRR был адаптирован для мультипликативного сокращения окна в алгоритмах контроля перегрузки, не основанных на потерях, таких как явное уведомление о перегрузке (Explicit Congestion Notification или ECN) [RFC3168]. Это можно сделать, используя некоторые части конечного автомата восстановления потерь (в частности, RecoveryPoint [RFC6675]) для вызова обработки PRR ACK ровно на один интервал кругового обхода из ACK. Однако могут существовать взаимосвязи между применением PRR и подходами с активным управлением очередями (Active Queue Management или AQM) и ECN. Рекомендации по разработке и внедрению механизмов контроля перегрузки приведено в [RFC9743].

5. Взаимодействие с другими стандартами

PRR можно применять в сочетании с любым алгоритмом контроля перегрузок, предназначенным для мультипликативного снижения скорости передачи данных в течение примерно одного интервала кругового обхода при условии, что текущий объём находящихся в сети данных ограничен размером окна перегрузки (cwnd) и целевой объём остающихся в сети данных в процессе сокращения является фиксированным значением, заданным ssthresh. В частности, PRR может работать с контролем перегрузок Reno [RFC5681] и CUBIC [RFC9438]. PRR описывается как модификация «A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP» [RFC6675]. Механизм наиболее точен в сочетании с SACK [RFC2018], но не требует наличия SACK.

PRR можно применять в сочетании с широким спектром алгоритмов обнаружения потерь. Это обусловлено независимостью PRR от деталей определения доставленных и потерянных пакетов механизмом обнаружения потерь. При получении каждого пакета ACK механизму PRR просто нужен алгоритм обнаружения потерь для информирования о числе пакетов, помеченных как доставленные и потерянные. Таким образом, PRR можно применять в сочетании с алгоритмами обнаружения потерь, заданными или описанными в Reno [RFC5681], NewReno [RFC6582], SACK [RFC6675], Forward Acknowledgment (FACK) [FACK], Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]. Благодаря свойствам RACK-TLP, включая устойчивость к потерям данных, нарушению порядке и потерям при повторной передаче рекомендуется реализовать PRR в сочетании с восстановлением потерь RACK-TLP [RFC8985].

Эвристика SafeACK является результатом отказоустойчивого обнаружения потерь при повторе передачи (Lost Retransmission Detection) при разработке раннего предшественника [RFC8985]. Без такого обнаружения системы управления трафиком (policer), ведущие к значительному уровню потерь, имеют очень высокий риск возникновения тайм-аутов при повторе передачи, поскольку в Reno [RFC5681], CUBIC [RFC9438] и [RFC6675] повторы возможны со значительным превышением скорости, заданной системой управления трафиком.

6. Алгоритм

6.1. Этапы инициализации

В начале эпизода реагирования на перегрузку, вызванного алгоритмом контроля отправитель, применяющий PRR, должен инициализировать состояние PRR. Момент начала реагирования на перегрузку полностью определяется алгоритмом контроля перегрузки и может, например, совпадать с запуском быстрого восстановления или однократным (за интервал кругового обхода) сокращением при обнаружении потери исходно или повторно переданных пакетов уже после начала быстрого восстановления. Инициализация PRR позволяет использовать алгоритм контроля перегрузок CongCtrlAlg(), который может установить для ssthresh значение, отличное от FlightSize/2 (включая , например, CUBIC [RFC9438]).

Ключевым этапом инициализации PRR является расчёт RecoverFS (число байтов, которые по оценке отправителя могут быть доставлены в течение эпизода PRR). Это можно представить как сумму установленных в начале эпизода значений объёма данных, остающихся в сети, числа байтов, кумулятивно подтверждённых запустившим восстановление пакетом ACK, числа байтов, подтверждённых SACK в пакете ACK, запустившим восстановление, и числа байтов между SND.UNA и SND.NXT, помеченных как потерянные. Значение RecoverFS включает потери, поскольку они маркируются с использованием эвристики, и некоторые пакеты, отмеченные как потерянные, могут быть всё-таки доставлены (без повтора передачи) в процессе восстановления. PRR использует RecoverFS для расчёта сглаженной скорости отправки. В начале быстрого восстановления PRR использует RecoverFS и это значение остаётся неизменным в течение данного эпизода быстрого восстановления.

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

ssthresh = CongCtrlAlg() // Параметры восстановления     
// Целевое значение остающихся в сети данных      
prr_delivered = 0
// Общее число байтов, доставленных при восстановлении 
prr_out = 0
// Общее число байтов, переданных при восстановлении
RecoverFS = SND.NXT - SND.UNA
// Байты, подтверждённые SACK до начала восстановления,
// не будут маркироваться в процессе восстановления
RecoverFS -= (bytes SACKed in scoreboard)
// Включает (распространённый) случай селективно
// подтверждённых ACK байтов
RecoverFS += (bytes newly SACKed)
// Включает (редкий) случай кумулятивно подтверждённых байтов
RecoverFS += (bytes newly cumulatively acknowledged)

6.2. Действия при получении ACK

При получении каждого пакета ACK в начале и в процессе восстановления (за исключением завершения завершения эпизода PRR) выполняет описанные ниже действия.

Сначала отправитель рассчитывает DeliveredData (оценка отправителем общего числа байтов, доставку которых подтверждает текущий пакет ACK, после предшествующего ACK). При наличии SACK значение DeliveredData можно рассчитать точно как изменение SND.UNA плюс изменение (со знаком) объёма данных, помеченных SACK в таблице результатов. Таким образом, в частном случае отсутствия в таблице результатов подтверждённых SACK диапазонов или после ACK, значение DeliveredData будет указано изменением SND.UNA. При восстановлении без SACK значение DeliveredData оценивается как 1 SMSS на каждый полученный дубликат ACK (т. е. SND.UNA не меняется). При увеличении SND.UNA (т. е. полное или частичное подтверждение ACK) значением DeliveredData будет изменение SND.UNA за вычетом SMSS на каждый принятый дубликат ACK. При отсутствии SACK некорректно работающий получатель, возвращающий лишние дубликаты ACK (см. [Savage99]), может попытаться искусственно завысить значение DeliveredData. В качестве меры предосторожности при отсутствии SACK механизм PRR запрещает увеличение DeliveredData, если общее число байтов, доставленных в эпизоде PRR, превышает оценку объёма данных, остававшихся в сети на момент начала восстановления (RecoverFS).

Затем отправитель вычисляет inflight. Для расчёта в соединениях с поддержкой SACK и обнаружением потерь [RFC6675] можно использовать алгоритм pipe, как указано в [RFC6675]. В соединениях с SACK и RACK-TLP [RFC8985] или иным алгоритмом обнаружения потерь расчёт должен начинаться с SND.NXT — SND.UNA, из которого (по таблице результатов) вычитаются байты, подтверждённые SACK и потерянные байты, затем добавляются байты, переданные повторно с момента их последней маркировки как потерянных. Для соединений без SACK вместо вычитания подтверждённых SACK байтов из таблицы результатов отправитель должен вычитать меньшее из значений RecoverFS и (1 SMSS для каждого предшествующего дубликата ACK в последнем эпизоде восстановления). Функция min() с RecoverFS служит для защиты от некорректно работающих получателей [Savage99].

Далее отправитель определяет SafeACK — локальную логическую переменную, указывающую, что текущий пакет ACK сообщил об успешном ходе восстановления. SafeACK имеет значение true лишь в том случае, когда ACK кумулятивно подтверждает новые данные и не указывает дополнительных потерь. Например, пакет ACK, вызывающий «аварийный» (rescue) повтор передачи (раздел 4 в [RFC6675], NextSeg(), условие 4) может указывать дополнительные потери. Оба условия указывают на успешный ход восстановления и отправитель может передавать более агрессивно, увеличивая при необходимости inflight.

В заключение отправитель использует DeliveredData, inflight, SafeACK и другие переменные состояния PRR для расчёта SndCnt (локальная переменная, точно показывающая сколько байтов следует передать в ответ на каждый пакет ACK), а затем использует SndCnt для обновления cwnd.

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

if (DeliveredData is 0)
   Return

prr_delivered += DeliveredData
inflight = (оценка остающихся в сети данных)
SafeACK = (SND.UNA растёт и новых потерь не указано)
if (inflight > ssthresh) {
   // Пропорциональное снижение скорости
   // Используется целочисленное деление с округлением вверх:
   #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
   out = DIV_ROUND_UP(prr_delivered * ssthresh, RecoverFS)
   SndCnt = out - prr_out
} else {
   // PRR-CRB применяется по умолчанию
   SndCnt = MAX(prr_delivered - prr_out, DeliveredData)
   if (SafeACK) {
      // PRR-SSRB при успешном ходе
      SndCnt += SMSS
   }
   // Попытка наверстать упущенное
   SndCnt = MIN(ssthresh - inflight, SndCnt)
}

if (prr_out is 0 AND SndCnt is 0) {
   // Форсирование быстрого повтора в начале восстановления
   SndCnt = SMSS
}
cwnd = inflight + SndCnt

После расчёта отправителем SndCnt и использования его для обновления cwnd отправитель передаёт больше данных. Отметим, что выбор данных для отправки (например, повтор или новые данные) выходит за рамки документа.

6.3. Этапы передачи

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

      prr_out += (переданные данные)

6.4. Завершающие действия

Эпизод PRR заканчивается завершением процедуры быстрого восстановления или перед началом нового эпизода PRR в результате нового отклика на возникновение перегрузки. При завершении эпизода PRR устанавливается

      cwnd = ssthresh

Отметим, что установка cwnd = ssthresh в некоторых случаях может приводить к всплеску отправляемых в сеть сегментов. Реализациям рекомендуется регулировать такие всплески трафика данных. Эта рекомендация соответствует современной практике сглаживания пиков (например, [PACING]), включая регулирование отправки после перезапуска из состояния бездействия.

7. Свойства

Перечисленные ниже свойства являются общими для PRR-CRB и PRR-SSRB, за исключениям отмеченных случаев.

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

При низких потерях PRR будет сходиться точно к целевому окну, выбранному алгоритмом контроля перегрузок. Отметим, что по мере приближения отправителя к завершению восстановления, значение prr_delivered будет стремиться к RecoverFS, а значение SndCnt будет рассчитываться так, что prr_out будет стремиться к ssthresh.

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

При пиках потерь раннее сокращение окна может быть отменено путём отправки дополнительных сегментов данных в ответ на пакеты ACK, приходящие позже в процессе восстановления. Отметим, что пока не будут отменены некоторые сокращения окна и приложения не будет заторможено, финальное значение inflight будет совпадать с ssthresh.

Используя любую из методов сокращения, PRR улучшает ситуацию, когда приложение тормозится, например, передающее приложение недостаточно быстро помещает данные в очередь передачи или получатель перестаёт продвигать окно приёма. Если приложение тормозится в начале восстановления, prr_out будет отставать от суммарного объёма передачи, разрешённого SndCnt. Упущенные из-за задержки возможности отправки данных рассматриваются как отложенные сокращения, в частности, они делают разность prr_delivered — prr_out существенно положительной. Если приложение синхронизируется, пока отправитель ещё находится в состоянии восстановления, отправитель передаст всплеск (burst) для увеличения inflight, что бы достичь того состояния, которое было бы при отсутствии торможения. Хотя такой всплеск может негативно влиять на данный поток или другие потоки в «канале», именно это происходит всякий раз, когда приложение тормозится на часть RTT не в процессе восстановления. PRR делает такое торможение более однородным во всех состояниях. Изменение такого поведения выходит за рамки этого документа.

Метод PRR с привязкой сокращения менее чувствителен к ошибкам при оценке inflight. При восстановлении inflight по сути является оценкой на основе неполных сведений о потере или нарушении порядка данных, не указанных в SACK. В некоторых случаях inflight может включать существенные ошибки, например, значение недооценивается, если всплеск переупорядоченных данных будет сочтён потерей и промаркирован для повтора передачи. Если передача регулируется напрямую значением inflight, как в [RFC6675], разрывы в оценке inflight вызывают всплеск данных, который невозможно отменить после корректировки inflight новыми пакетами ACK. В части динамики PRR, inflight просто определяет, какой алгоритм, PRR или вариант сокращения применяется для расчёта SndCnt из DeliveredData. Несмотря на недооценку Winflight, алгоритмы различаются не более чем на 1 сегмент на ACK. После обновления оценки inflight они сходятся к одному размеру окна в конце восстановления.

При любых условиях и последовательности событий в процессе восстановления PRR-CRB строго ограничивает передачу данных, чтобы она не превысила объем данных, доставленных адресату. Strong Packet Conservation Bound (строгая привязка к сохранению пакетов) — это наиболее агрессивный алгоритм, не вызывающий дополнительных потерь в некоторых средах. Это обусловлено тем, что при наличии сохраняющейся очереди передачи в узком месте без кросс-трафика размер очереди в процессе восстановления будет меняться не более чем на +1/-1 из-за различий времени прибытия и выхода. Подробно этот вопрос рассматривается в Приложении A.

Хотя строгая привязка сохранения пакетов по многим причинам очень привлекательно, измерения (см. раздел 6 в [RFC6675]) показывают, что этот метод менее агрессивен и работает не так хорошо, как [RFC6675], где разрешены пики данных во время всплесков потерь. PRR-SSRB является компромиссом, позволяющим отправителю передать 1 дополнительный сегмент на ACK сверх Packet Conserving Bound (привязка сохранения пакетов), когда ACK показывает хороший ход восстановления без добавочных потерь. С точки зрения строгой привязки, PRR-SSRB открывает окно возможностей в процессе восстановления, однако при всплеске потерь этот метод менее агрессивен, чем [RFC6675].

8. Примеры

Этот раздел иллюстрирует поведение алгоритмов PRR и [RFC6675] демонстрируя различия в поведении для двух случаев: соединения с 1 потерей и всплеском из 15 последовательных потерь. В обоих случаях передаётся большой объем данных (без пауз в приложениях), применяется контроль перегрузок Reno [RFC5681], и установлено cwnd = FlightSize = inflight = 20 сегментов, поэтому в начале восстановления будет значение ssthresh = 10. В обоих случаях применяется ускоренный повтор (Fast Retransmit) [RFC5681] и ограниченная передача (Limited Transmit) [RFC3042], поэтому отправитель передаёт 2 сегмента, после чего следует 1 повтор в ответ на первые 3 дубликата ACK после потерь.

На рисунках ниже показаны отклики на пакет ACK за первый круговой обход для двух алгоритмов восстановления при потере нулевого сегмента. Верхняя строка (ack#) показывает номер переданного сегмента, вызвавшего пакеты ACK, где X указывает потерянный сегмент. Строки cwnd и inflight указывают значения соответствующих переменных для алгоритмов после обработки каждого возвращённого пакета ACK, но до последующей передачи (повтора). Строка sent указывает число новых (N) или повторённых (R) данных, которые были переданы. Алгоритмы выбора данных для передачи выходят за рамки этого документа.

RFC 6675
   a X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
   c   20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
   i   19 19 18 18 17 16 15 14 13 12 11 10  9  9  9  9  9  9  9  9  9  9
   s    N  N  R                             N  N  N  N  N  N  N  N  N  N

PRR
   a X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
   c   20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
   i   19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10  9  9
   s    N  N  R     N     N     N     N     N     N     N     N     N  N

   a: ack#;  c: cwnd;  i: inflight;  s: sent

Рисунок .1

В первом примере ACK#1 — ACK#19 содержат SACK для исходной отправки данных, в ACK#20 и ACK#21 содержатся SACK для ограниченной передачи, вызванной первым и вторым сегментами, подтверждёнными SACK, а ACK#22 содержит полное кумулятивное подтверждение ACK, охватывающее все данные вплоть до ограниченной передачи. ACK#22 завершает эпизод восстановления и, следовательно, — эпизод PRR.

Отметим, что оба алгоритма суммарно передают одинаковый объем данных и завершают эпизод восстановление с cwnd, соответствующим ssthresh = 20. В [RFC6675] возникает «половина окна тишины», а PRR распределяет сокращение окна по всему интервалу RTT.

Далее рассматривается случай с такими же начальными условиями, где теряется 15 первых пакетов (0-14). В результате прохождения оставшейся части пути отправителю возвращается лишь 5 пакетов 5 ACK.

RFC 6675
   a X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  15 16 17 18 19
   c                                              20 20 10 10 10
   i                                              19 19  4  9  9
   s                                               N  N 6R  R  R

PRR
   a X  X  X  X  X  X  X  X  X  X  X  X  X  X  X  15 16 17 18 19
   c                                              20 20  5  5  5
   i                                              19 19  4  4  4
   s                                               N  N  R  R  R

   a: ack#;  c: cwnd;  i: inflight;  s: sent

Рисунок 2

В этой ситуации алгоритм [RFC6675] более агрессивен, поскольку при запуске Fast Retransmit (по ACK для сегмента 17) отправитель сразу передаёт повторно данные, достаточные для увеличения inflight до cwnd. Измерения (см. раздел 6 в [RFC6675]) показали, что [RFC6675] значительно превосходит version PRR [RFC6937] с использованием лишь PRR-CRB и некоторые похожие консервативные алгоритмы, которые тестировались. Это показывает, что фактические потери обычно превышают сокращение cwnd, определяемое алгоритмом контроля перегрузок.

При столь значительных потерях в первом интервале кругового обхода при восстановлении PRR использует PRR-CRB в соответствии с принципом сохранения пакетов. Поскольку общие потери ведут к тому, что inflight становится ниже ssthresh, данные передаются так, что общий объем отправки (prr_out) соответствует общему объёму доставленных получателю данных, сообщённому пакетами ACK. Передача контролируется пределом отправки (prr_delivered — prr_out).

Хотя на рисунке это не показано, после того, как ускоренные повторы по ACK#17 доставлены и вызвали пакеты ACK, увеличивающие SND.UNA, PRR переходит в режим PRR-SSRB и увеличивает окно ровно на 1 сегмент по каждому ACK, пока inflight не достигнет значения ssthresh в процессе восстановления. При больших потерях, когда значение cwnd велико, PRR-SSRB восстанавливает потери в разы быстрее, чем PRR-CRB. Хотя увеличение окна в процессе восстановления представляется разумным, важно помнить, что на деле это менее агрессивно, нежели разрешает [RFC6675], где передаётся тот же объем дополнительных данных в одном всплеске как отклик на пакет ACK, вызвавший Fast Retransmit.

При меньших потерях (суммарно меньше FlightSize — ssthresh) PRR-CRB и PRR-SSRB не вызываются, поскольку PRR остаётся в режиме пропорционального снижения скорости.

9. Адаптация PRR к другим транспортным протоколам

Основной алгоритм PRR и привязки сокращения можно адаптировать для любого транспорта, поддерживающего [RFC6675]. В одной из основных реализаций (Linux TCP) PRR является алгоритмом быстрого восстановления для принятых по умолчанию и поддерживаемых модулей контроля перегрузок с 2011 г. [First_TCP_PRR].

Эвристику SafeACK можно обобщить как любое подтверждение (ACK) повторной передачи, которое не ведёт к маркировке какого-либо другого сегмента для повторной передачи.

10. Измерения

Для [RFC6937] в документе [IMC11] проведены оценки [RFC3517] и экспериментальных версий PRR в рамках крупномасштабных измерений. На момент публикации этого документа использованные в исследовании устаревшие алгоритмы были уже исключены из реестров, что затрудняет сравнение без использования их. Интересующимся результатами измерений читателям следует обратиться к разделу 5 в [RFC6937] и статье IMC [IMC11].

11. Эксплуатационные вопросы

11.1. Поэтапное внедрение

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

11.2. Беспристрастность

Механизм PRR предназначен для обеспечения беспристрастности алгоритма контроля перегрузок, с которым он применяется. PRR работает лишь во время отклика контроля перегрузок, такого как быстрое восстановление, или при постепенном снижении cwnd в результате реакции TCP ECN [RFC3168], и принимает только краткосрочные решения на основе приёма подтверждений для плавной регулировки объёма остающихся в сети данных в течение эпизода так, чтобы в конце эпизода значение cwnd было как можно ближе к порогу замедленного старта, заданному алгоритмом контроля перегрузок. PRR не меняет механизмов изменения cwnd алгоритмом контроля перегрузок вне эпизодов отклика на перегрузку.

11.3. Защита сети от избыточных очередей и потери пакетов

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

В краткосрочном масштабе механизм PRR предназначен для снижения скорости потери пакетов по сравнению с прежними подходами, например, [RFC6675]. На высоком уровне механизм PRR основан на принципе сохранения пакетов и опирается на процесс самосинхронизации, насколько это возможно. В отличие от этого, в [RFC6675] один пакет ACK с опцией SACK, подразумевающий отсутствие большого объёма данных, может вызвать разрыв в оценке остающихся в сети данных, который может активировать механизм ускоренного повтора (Fast Retransmit) для отправки пикового объёма данных, значительно превышающего объем доставленных данных. PRR позволяет избежать таких всплесков, принимая решение о передаче на основе объёма доставленных, а не потерянных данных. Кроме того, как отмечено выше, PRR-SSRB менее агрессивен, чем [RFC6675] (передаёт меньше сегментов или делает это медленней), и обладает большей производительностью из-за снижения вероятности дополнительных потерь при восстановлении.

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

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

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

PRR не изменяет профилей рисков транспортных протоколов

Разработчики, переводящие PRR с подсчёта байтов на подсчёт сегментов, должны быть осторожны в отношении атак с расщеплением ACK [Savage99], когда получатель подтверждает частичные сегменты с целью запутать отправителя при обработке перегрузки.

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

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

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[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>.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

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

[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, «The NewReno Modification to TCP’s Fast Recovery Algorithm», RFC 6582, DOI 10.17487/RFC6582, April 2012, <https://www.rfc-editor.org/info/rfc6582>.

[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, «A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP», RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.

[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>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., «Path MTU Discovery for IP version 6», STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, «The RACK-TLP Loss Detection Algorithm for TCP», RFC 8985, DOI 10.17487/RFC8985, February 2021, <https://www.rfc-editor.org/info/rfc8985>.

[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>.

[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed., «CUBIC for Fast and Long-Distance Networks», RFC 9438, DOI 10.17487/RFC9438, August 2023, <https://www.rfc-editor.org/info/rfc9438>.

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

[FACK] Mathis, M. and J. Mahdavi, «Forward Acknowledgment: Refining TCP Congestion Control», SIGCOMM ’96: Conference Proceedings on Applications, Technologies, Architectures, and Protocols for Computer Communications, pp. 281-291, DOI 10.1145/248156.248181, August 1996, <https://dl.acm.org/doi/10.1145/248156.248181>.

[First_TCP_PRR] «Proportional Rate Reduction for TCP.», commit a262f0cdf1f2916ea918dc329492abb5323d9a6c, August 2011, <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>.

[Flach2016policing] Flach, T., Papageorge, P., Terzis, A., Pedrosa, L., Cheng, Y., Karim, T., Katz-Bassett, E., and R. Govindan, «An Internet-Wide Analysis of Traffic Policing», SIGCOMM ’16: Proceedings of the 2016 ACM SIGCOMM Conference, pp. 468-482, DOI 10.1145/2934872.2934873, August 2016, <https://doi.org/10.1145/2934872.2934873>.

[Hoe96Startup] Hoe, J., «Improving the Start-up Behavior of a Congestion Control Scheme for TCP», SIGCOMM ’96: Conference Proceedings on Applications, Technologies, Architectures, and Protocols for Computer Communications, pp. 270-280, DOI 10.1145/248156.248180, August 1996, <https://doi.org/10.1145/248156.248180>.

[IMC11] Dukkipati, N., Mathis, M., Cheng, Y., and M. Ghobadi, «Proportional Rate Reduction for TCP», IMC ’11: Proceedings of the 2011 ACM SIGCOMM Conference on Internet Measurement Conference, pp. 155-170, DOI 10.1145/2068816.2068832, November 2011, <https://doi.org/10.1145/2068816.2068832>.

[Jacobson88] Jacobson, V., «Congestion Avoidance and Control», Symposium proceedings on Communications architectures and protocols (SIGCOMM ’88), pp. 314-329, DOI 10.1145/52325.52356, August 1988, <https://doi.org/10.1145/52325.52356>.

[PACING] Welzl, M., Eddy, W., Goel, V., and M. Tüxen, «Pacing in Transport Protocols», Work in Progress, Internet-Draft, draft-welzl-iccrg-pacing-03, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-welzl-iccrg-pacing-03>.

[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, «Enhancing TCP’s Loss Recovery Using Limited Transmit», RFC 3042, DOI 10.17487/RFC3042, January 2001, <https://www.rfc-editor.org/info/rfc3042>.

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

[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, «A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP», RFC 3517, DOI 10.17487/RFC3517, April 2003, <https://www.rfc-editor.org/info/rfc3517>.

[RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, «Proportional Rate Reduction for TCP», RFC 6937, DOI 10.17487/RFC6937, May 2013, <https://www.rfc-editor.org/info/rfc6937>.

[RFC9743] Duke, M., Ed. and G. Fairhurst, Ed., «Specifying New Congestion Control Algorithms», BCP 133, RFC 9743, DOI 10.17487/RFC9743, March 2025, <https://www.rfc-editor.org/info/rfc9743>.

[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, «TCP Congestion Control with a Misbehaving Receiver», ACM SIGCOMM Computer Communication Review, vol. 29, no. 5, pp. 71-78, DOI 10.1145/505696.505704, October 1999, <https://doi.org/10.1145/505696.505704>.

[TCP-RH] Mathis, M., Mahdavi, J., and J. Semke, «The Rate-Halving Algorithm for TCP Congestion Control», Work in Progress, Internet-Draft, draft-mathis-tcp-ratehalving-00, 30 August 1999, <https://datatracker.ietf.org/doc/html/draft-mathis-tcp-ratehalving-00>.

Приложение A. Строгая привязка к сохранению пакетов

Привязка PRR-CRB основана на консервативной, философски чистой и эстетически привлекательной строгой привязке к сохранению пакетов (Strong Packet Conservation Bound), описанной здесь. Хотя механизм основан на принципе сохранения пакетов [Jacobson88], он отличается трактовкой пакетов, которые отсутствуют или считаются потерянными. При любых условиях и вариантах событий в процессе восстановления PRR-CRB строго ограничивает отправляемые данные — не больше объёма данных, доставленных получателю. Отметим, что последствия предполагаемых потерь учитываются при расчёте inflight, но не влияют на результат PRR-CRB, если inflight падает ниже ssthresh.

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

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

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

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

Отметим, что алгоритм контроля перегрузок более широко трактует оптимальность, включая надлежащее распределение пропускной способности сети. Типичные протоколы контроля перегрузок, будут, вероятно, сокращать объем передаваемых данных по сравнению с ограничением сохранения пакетов, применяемым в PRR, что приведёт к сокращению фактического окна TCP до величины ssthresh.

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

Этот документ частично основан на работе Janey C. Hoe (см. «Recovery from Multiple Packet Losses» в параграфе 3.2 [Hoe96Startup]), Matt Mathis, Jeff Semke и Jamshid Mahdavi [TCP-RH], а также обсуждениях с John Heffner.

Monia Ghobadi и Sivasankar Radhakrishnan помогли с анализом экспериментов. Ilpo Jarvinen проанализировал начальную реализацию. Mark Allman, Richard Scheffenegger, Markku Kojo, Mirja Kuehlewind, Gorry Fairhurst, Russ Housley, Paul Aitken, Daniele Ceccarelli, Mohamed Boucadair улучшили документ своими рецензиями и предложениями.

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

Matt Mathis

Email: matt.mathis@gmail.com

Neal Cardwell

Google, Inc.

Email: ncardwell@google.com

Yuchung Cheng

Google, Inc.

Email: ycheng@google.com

Nandita Dukkipati

Google, Inc.

Email: nanditad@google.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9847 IANA Registry Updates for TLS and DTLS

Опубликовано 18.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        J. Salowey
Request for Comments: 9847                                      CyberArk
Updates: 8447                                                  S. Turner
Category: Standards Track                                          sn3rd
ISSN: 2070-1721                                            December 2025

IANA Registry Updates for TLS and DTLS

Обновление реестров IANA для TLS и DTLS

PDF

Аннотация

Этот документ обновляет изменения в реестрах TLS и DTLS IANA, внесённые RFC 8447. Добавлено новое значение D (discouraged — не рекомендуется) в столбец Recommended некоторых реестров TLS и столбец Comment (комментарий) во все активные реестры, где его не было. Также обновлены инструкции для запросов на регистрацию.

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

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

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

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

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

1. Введение

Этот документ предписывает IANA внести множество изменений в реестры, относящиеся к защите транспортного уровня (Transport Layer Security или TLS) и защите транспортного уровня дейтаграмм (Datagram Transport Layer Security или DTLS). Изменения обновляют данные, внесённые [RFC8447].

Спецификация добавляет новое значение D (discouraged — не рекомендуется) для столбца Recommended в некоторых реестрах TLS и столбца Comment в реестры, где его ещё нет.

Спецификация также обновляет инструкции для запросов регистрации.

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

3. Обновление значений столбца Recommended

Этот документ обновляет столбец Recommended (рекомендовано), добавленный [RFC8447], значением D, указывающим что строка (значение) не рекомендуется. Возможные значения описаны ниже.

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

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

Указывает, что данный элемент не рекомендуется применять. Это может использоваться для указания механизмов, при использовании которых могут возникать проблемы (например, слабая криптография или проблемы функциональной совместимости при внедрении). При указании статуса D с колонке Reference или Comment должны быть достаточные сведения о причинах такой маркировки. Разработчикам и пользователям следует ознакомиться с этими сведениями для понимания условий, при которых элемент не следует или недопустимо использовать.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов (Expert Review) или IESG Approval [RFC8126]. Не все элементы, заданные в Standards Track RFC требуют установки статуса Y или D. Для всех элементов с неуказанным статусом предполагается N. Столбец не заполняется для резервных и невыделенных значений, пока не появится соответствующая спецификация.

3.1. Примечание для столбца Recommended

В имеющихся реестрах есть примечания о значении столбца Recommended. Для описанных ниже реестров эти примечания обновлены описанием значения D, как показано ниже.

Примечание. Если в столбце Recommended указано значение N, это необязательно говорит о недостатках. Скорее это указывает, что элемент не прошёл продедуру согласования IETF, имеет ограниченную применимость или предназначен лишь для конкретных случаев. Если в столбце Recommended указно D, данный элемент не рекомендуется и его не следует или недопустимо применять (в зависимости от ситуации). Для лучшего понимания следует обратиться к приведённым ссылкам.

4. Реестр типов расширений TLS

С учётом изменений в столбце Recommended агентство IANA обновило реестр TLS ExtensionType Values:

Скорректирована процедура регистрации в части значения столбца Recommended:

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
Обновлён столбец Recommended, как показано ниже. В записи со значениями Y и N лишь добавлена ссылка на этот документ.

Таблица .

Значение	Имя расширения	Рекомендовано
4	truncated_hmac	D
40	Reserved	D
46	Reserved	D
53	connection_id(deprecated)	D

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.
Для truncated_hmac добавлена ссылка https://www.iacr.org/archive/asiacrypt2011/70730368/70730368.pdf в столбец Reference.
Для показанных в таблице строк Reserved добавлена ссылка https://mailarchive.ietf.org/arch/msg/tls-reg-review/5BD62HBFjo_AsW-Y8ohVuWEe1gI/ в столбец Reference.

5. Реестр шифров TLS

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

Наборы с пометкой EXPORT используют слабые шифры и не рекомендуются для TLS 1.1 [RFC4346].

Наборы с пометкой anon не обеспечивают аутентификации и уязвимы к атакам в пути, поэтому не рекомендуются для TLS 1.1 [RFC4346].

Шифр RC4 признан слабым и не рекомендуется [RFC7465]. DES и IDEA³ не считаются безопасными для общего пользования и не рекомендуются [RFC5469]. Алгоритмы MD5 и SHA-1 также признаны небезопасными для общего пользования и не рекомендуются [RFC9155].

В соответствии с изменениями столбца Recommended агентство IANA обновило реестр TLS Cipher Suites.

Скорректирована процедура регистрации в части значения столбца Recommended:

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
Обновлён столбец Recommended, как показано ниже. В записи со значениями Y и N лишь добавлена ссылка на этот документ. Данный документ не меняет значений в столбце DTLS-OK.

Таблица .

Значение	Описание	Рекомендовано
0x00,0x1E	TLS_KRB5_WITH_DES_CBC_SHA	D
0x00,0x20	TLS_KRB5_WITH_RC4_128_SHA	D
0x00,0x21	TLS_KRB5_WITH_IDEA_CBC_SHA	D
0x00,0x22	TLS_KRB5_WITH_DES_CBC_MD5	D
0x00,0x24	TLS_KRB5_WITH_RC4_128_MD5	D
0x00,0x25	TLS_KRB5_WITH_IDEA_CBC_MD5	D
0x00,0x26	TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA	D
0x00,0x27	TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA	D
0x00,0x28	TLS_KRB5_EXPORT_WITH_RC4_40_SHA	D
0x00,0x29	TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5	D
0x00,0x2A	TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5	D
0x00,0x2B	TLS_KRB5_EXPORT_WITH_RC4_40_MD5	D
0x00,0x2C	TLS_PSK_WITH_NULL_SHA	D
0x00,0x8A	TLS_PSK_WITH_RC4_128_SHA	D
0x00,0xB0	TLS_PSK_WITH_NULL_SHA256	D
0x00,0xB1	TLS_PSK_WITH_NULL_SHA384	D
0xC0,0x06	TLS_ECDHE_ECDSA_WITH_NULL_SHA	D
0xC0,0x07	TLS_ECDHE_ECDSA_WITH_RC4_128_SHA	D
0xC0,0x10	TLS_ECDHE_RSA_WITH_NULL_SHA	D
0xC0,0x11	TLS_ECDHE_RSA_WITH_RC4_128_SHA	D
0xC0,0x33	TLS_ECDHE_PSK_WITH_RC4_128_SHA	D
0xC0,0x39	TLS_ECDHE_PSK_WITH_NULL_SHA	D
0xC0,0x3A	TLS_ECDHE_PSK_WITH_NULL_SHA256	D
0xC0,0x3B	TLS_ECDHE_PSK_WITH_NULL_SHA384	D
0xC0,0xB4	TLS_SHA256_SHA256	D
0xC0,0xB5	TLS_SHA384_SHA384	D

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

6. Реестр поддерживаемых групп TLS

В соответствии с изменениями столбца Recommended агентство IANA обновило реестр TLS Supported Groups.

Скорректирована процедура регистрации в части значения столбца Recommended:

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
Обновлён столбец Recommended, как показано ниже. В записи со значениями Y и N лишь добавлена ссылка на этот документ.

Таблица .

Значение	Описание	Рекомендовано
1	sect163k1	D
2	sect163r1	D
3	sect163r2	D
4	sect193r1	D
5	sect193r2	D
6	sect233k1	D
7	sect233r1	D
8	sect239k1	D
15	secp160k1	D
16	secp160r1	D
17	secp160r2	D
18	secp192k1	D
19	secp192r1	D
20	secp224k1	D
21	secp224r1	D

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.
Удалено примечание Elliptic curve groups (группы эллиптических кривых) из таблицы процедур регистрации.
Для приведённых выше записей добавлена сслыка https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-rfc8447bis-00 в столбец Comment.

7. Реестр меток экспортёров TLS

Этот документ одновляет процедуру регистрации в реестре TLS Exporter Labels и выделение столбца Recommended.

Процедура регистрации Specification Required заменена процедурой Expert Review.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.
Обновлена роль рецензии экспертов, как указано ниже.

Примечание. Роль назначенных экспертов описана в разделе 17 [RFC8447]. Хотя данный реестр не требует спецификации, [RFC8126] настоятельно рекомендует претендентам на регистрацию указывать ссылку на публично доступную спецификацию, в качестве каковой подходят Internet-Draft (размещён, но не опубликован как RFC), документ другого органа стандартизации, отраслевого консорциума, университета и т. п. Эксперты могут представить более глубокие обзоры, но их одобрение не следует считать одобрением метки экспортёра. Эксперты также проверяют, что метка представляет собой строку печатаемых символов ASCII, начинающуюся с EXPORTER. Агентство IANA должно убедиться, что метка не является префиксом какой-либо другой метки. Например, запрещены метки key и master secretary.

Столбец Note переименован в Comment.

8. Реестр типов сертификатов TLS

В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS Certificate Types.

Скорректирована процедура регистрации в части значения столбца Recommended.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

9. Реестр алгоритмов хэширования TLS

TLS 1.0 и TLS 1.1 признаны устаревшими [RFC8996], TLS 1.2 будет применяться ещё некоторое время. В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS HashAlgorithm.

Скорректирована процедура регистрации в части значения столбца Recommended.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В реестр TLS HashAlgorithm добавлен столбец Recommended, как показано ниже.

Таблица .

Значение	Описание	Рекомендовано
0	none	Y
1	md5	D
2	sha1	D
3	sha224	D
4	sha256	Y
5	sha384	Y
6	sha512	Y
8	Intrinsic	Y

Добавлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

10. Реестр алгоритмов подписи TLS

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В реестр TLS SignatureAlgorithm добавлен столбец Recommended, как показано ниже.

Таблица .

Значение	Описание	Рекомендовано
0	anonymous	N
1	rsa	Y
2	dsa	N
3	ecdsa	Y
7	ed25519	Y
8	ed448	Y
64	gostr34102012_256	N
65	gostr34102012_512	N

Добавлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

11. Рееестр идентификаторв типа сертификата клиента TLS

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В реестр TLS ClientCertificateType Identifiers добавлен столбец Recommended, как показано ниже.

Таблица .

Значение	Описание	Рекомендовано
1	rsa_sign	Y
2	dss_sign	N
3	rsa_fixed_dh	N
4	dss_fixed_dh	N
5	rsa_ephemeral_dh_RESERVED	D
6	dss_ephemeral_dh_RESERVED	D
20	fortezza_dms_RESERVED	D
64	ecdsa_sign	Y
65	rsa_fixed_ecdh	N
66	ecdsa_fixed_ecdh	N
67	gost_sign256	N
68	gost_sign512	N

Добавлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

12. Реестр режимов обмена ключами TLS PskKeyExchangeMode

В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS PskKeyExchangeMode.

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

13. Реестр схем подписи TLS

В соответствии с изменением для столбца Recommended агентство IANA обновило реестр TLS SignatureScheme.

Обновлена процедура регистрации.

Установка и изменение значения Y или D в столбце Recommended выполняется по процедуре IETF Standards Action с рецензией экспертов или по процедуре IESG Approval [RFC8126].
Добавлена ссылка на данный документ.
В записях со значениями Y и N столбец Recommended не изменён.

Обновлено примечание к столбцу Recommended в соответствии с параграфом 3.1.

14. Добавление столбца Comment

Агентство IANA добавило столбец Comment в указанные ниже реестры.

TLS ExtensionType Values
TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
TLS CachedInformationType Values
TLS Certificate Compression Algorithm IDs
TLS ClientCertificateType Identifiers
TLS Cipher Suites
TLS ContentType
TLS EC Point Formats
TLS EC Curve Types
TLS Supplemental Data Formats (SupplementalDataType)
TLS UserMappingType Values
TLS SignatureAlgorithm
TLS HashAlgorithm
TLS Authorization Data Formats
TLS Heartbeat Message Types
TLS Heartbeat Modes
TLS SignatureScheme
TLS PskKeyExchangeMode
TLS KDF Identifiers
TLS SSLKEYLOGFILE Labels

В этом списке приведены все реестры, где ещё не было столбца Comment или Note, не отменённые TLS 1.3.

15. Рецензия экспертов на документы IETF и IRTF

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

16. Регистрационные запросы

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

Отправки по адресу iana@iana.org; в поле subject следует указывать цель (например, Request to register value in TLS bar registry).
Путём заполнения формы на странице https://www.iana.org/form/protocol-assignment.

Запросы по процедуре Specification Required [RFC8126] регистрируются после трехнедельного рассмотрения по рекомендации одного или нескльких назначенных экспертов. Для обеспечения возможности выделения значений до публикации назначенные эксперты могут одобрить регистрацию, как только убедятся, что спецификация будет опубликована.

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

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

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

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

Этот документ целиком посвящён изменениям связанных с TLS реестров IANA.

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

[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>.

[RFC4346] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1», RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.

[RFC5469] Eronen, P., Ed., «DES and IDEA Cipher Suites for Transport Layer Security (TLS)», RFC 5469, DOI 10.17487/RFC5469, February 2009, <https://www.rfc-editor.org/info/rfc5469>.

[RFC7465] Popov, A., «Prohibiting RC4 Cipher Suites», RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.

[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>.

[RFC8447] Salowey, J. and S. Turner, «IANA Registry Updates for TLS and DTLS», RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

[RFC8996] Moriarty, K. and S. Farrell, «Deprecating TLS 1.0 and TLS 1.1», BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.

[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, «Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2», RFC 9155, DOI 10.17487/RFC9155, December 2021, <https://www.rfc-editor.org/info/rfc9155>.

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

Joe Salowey

CyberArk

Email: joe@salowey.net

Sean Turner

sn3rd

Email: sean@sn3rd.com

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

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

nmalykh@protokols.ru

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

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

3International Data Encryption Algorithm — международный алгоритм шифрования данных.

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

RFC 9911 Common YANG Data Types

Опубликовано 13.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)               J. Schönwälder, Ed.
Request for Comments: 9911                        Constructor University
Obsoletes: 6991                                            December 2025
Category: Standards Track                                               
ISSN: 2070-1721

Common YANG Data Types

PDF

Аннотация

Этот документ вводит набор типов данных общего назначения для использования в языке моделирования данных YANG. Он включает несколько определений новых типов и отменяет RFC 6991.

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

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

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

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

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

1. Введение

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

В этом документе представлен набор производных типов данных общего назначения, выведенных из встроенных в YANG типов данных. Производные типы рассчитаны на применение в моделировании всех типов данных управления. Определения типов организованы в несколько модулей YANG. Модуль ietf-yang-types содержит типы данных общего назначения, а в модуле ietf-inet-types содержатся определения, относящиеся к стеку протоколов Internet.

Этот документ определяет набор типов данных общего назначения. Определения представлены в форме двух модулей YANG:

модуль ietf-yang-types определяет типы данных общего назначения, такие как счётчики и измерители (датчики), типы, связанные с датами и временем, а также типы для строковых значений (например, UUID, числа, разделённые точками, таги языка);
модуль ietf-inet-types определяет типы данных, связанные со стеком протоколов Internet, такие как адреса IP, доменные имена, имена хостов, URI, адреса электронной почты и типы для базовых полей протоколов (например, номера портов).

Первая версия этих модулей YANG была представлена в [RFC6021]. При пересмотре [RFC6021] в [RFC6991] были добавлены несколько определений типов. Данный пересмотр добавляет определения новых типов и решает проблемы, отмеченные в Erratum ID 4076 [Err4076] и 5105 [Err5105]. Кроме того, определение yang-identifier приведено в соответствие с YANG 1.1 [RFC7950], а также улучшены некоторые операторы pattern. Дополнительные сведения приведены в операторах revision модулей YANG разделов 3 и 4. Краткий обзор всех представленных в этом документе типов дан в разделе 2. В будущем могут быть добавлены новые определения типов путём представления предложений в рабочую группу NETMOD.

В документе используется терминология YANG, определённая в разделе 3 [RFC7950].

2. Обзор

В таблицах 1 и 2 перечислены типы, определённые в модулях YANG ietf-yang-types и ietf-inet-types. Для каждого тпа указано имя, базовый тип и RFC, где данный тип был определён.

Таблица . Типы, определённые в модуле ietf-yang-types.

Тип	Базовый тип	Документ
counter32	uint32	RFC 6021
zero-based-counter32	uint32	RFC 6021
counter64	uint64	RFC 6021
zero-based-counter64	uint64	RFC 6021
gauge32	uint32	RFC 6021
gauge64	uint64	RFC 6021
object-identifier	string	RFC 6021
object-identifier-128	object-identifier	RFC 6021
date-and-time	string	RFC 6021
date	string	RFC 9911
date-no-zone	string	RFC 9911
time	string	RFC 9911
time-no-zone	string	RFC 9911
hours32	int32	RFC 9911
minutes32	int32	RFC 9911
seconds32	int32	RFC 9911
centiseconds32	int32	RFC 9911
milliseconds32	int32	RFC 9911
microseconds32	int32	RFC 9911
microseconds64	int64	RFC 9911
nanoseconds32	int32	RFC 9911
nanoseconds64	int64	RFC 9911
timeticks	int32	RFC 6021
timestamp	timeticks	RFC 6021
phys-address	string	RFC 6021
mac-address	string	RFC 6021
xpath1.0	string	RFC 6021
hex-string	string	RFC 6991
uuid	string	RFC 6991
dotted-quad	string	RFC 6991
language-tag	string	RFC 9911
yang-identifier	string	RFC 6991

Таблица . Типы, определённые в модуле ietf-inet-types.

Тип	Базовый тип	Документ
ip-version	enum	RFC 6021
dscp	uint8	RFC 6021
ipv6-flow-label	uint32	RFC 6021
port-number	uint16	RFC 6021
protocol-number	uint8	RFC 9911
upper-layer-protocol-number	protocol-number	RFC 9911
as-number	uint32	RFC 6021
ip-address	union	RFC 6021
ipv4-address	string	RFC 6021
ipv6-address	string	RFC 6021
ip-address-no-zone	union	RFC 6991
ipv4-address-no-zone	ipv4-address	RFC 6991
ipv6-address-no-zone	ipv6-address	RFC 6991
ip-address-link-local	union	RFC 9911
ipv4-address-link-local	ipv4-address	RFC 9911
ipv6-address-link-local	ipv6-address	RFC 9911
ip-prefix	union	RFC 6021
ipv4-prefix	string	RFC 6021
ipv6-prefix	string	RFC 6021
ip-address-and-prefix	union	RFC 9911
ipv4-address-and-prefix	string	RFC 9911
ipv6-address-and-prefix	string	RFC 9911
domain-name	string	RFC 6021
host-name	domain-name	RFC 9911
host	union	RFC 6021
uri	string	RFC 6021
email-address	string	RFC 9911

Некоторые типы имеют эквиваленты в Structure of Management Information Version 2 (SMIv2) [RFC2578] [RFC2579]. Тип данных YANG является эквивалентным типу SMIv2, если оба типа имеют эквивалентные значения и их семантику.

В таблице 3 указаны типы из модуля ietf-yang-types и соответствующие типы SMIv2, а в таблице 4 — типы из ietf-inet-types и соответствующие типы SMIv2.

Таблица . Типы ietf-yang-types и их эквиваленты в SMIv2.

Тип YANG	Эквивалентный тип SMIv2 (модуль)
counter32	Counter32 (SNMPv2-SMI)
zero-based-counter32	ZeroBasedCounter32 (RMON2-MIB)
counter64	Counter64 (SNMPv2-SMI)
zero-based-counter64	ZeroBasedCounter64 (HCNUM-TC)
gauge32	Gauge32 (SNMPv2-SMI)
gauge64	CounterBasedGauge64 (HCNUM-TC)
object-identifier-128	OBJECT IDENTIFIER
centiseconds32	TimeInterval (SNMPv2-TC)
timeticks	TimeTicks (SNMPv2-SMI)
timestamp	TimeStamp (SNMPv2-TC)
phys-address	PhysAddress (SNMPv2-TC)
mac-address	MacAddress (SNMPv2-TC)
language-tag	LangTag (LANGTAG-TC-MIB)

Таблица . Типы ietf-inet-types и их эквиваленты в SMIv2.

Тип YANG	Эквивалентный тип SMIv2 (модуль)
ip-version	InetVersion (INET-ADDRESS-MIB)
dscp	Dscp (DIFFSERV-DSCP-TC)
ipv6-flow-label	IPv6FlowLabel (IPV6-FLOW-LABEL-MIB)
port-number	InetPortNumber (INET-ADDRESS-MIB)
as-number	InetAutonomousSystemNumber (INET-ADDRESS-MIB)
uri	Uri (URI-TC-MIB)

3. Базовые производные типы YANG

Модуль YANG ietf-yang-types ссылается на [IEEE-802-2024], [ISO-8601], [ISO-9834-1], [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4502], [RFC5131], [RFC5646], [RFC7950], [RFC9557], [RFC9562], [XPATH], [XSD-TYPES].

   <CODE BEGINS> file "ietf-yang-types@2025-12-22.yang"
   module ietf-yang-types {
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
     prefix yang;

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

        Editor:   Jürgen Schönwälder
                  <mailto:jschoenwaelder@constructor.university>"; 
     description
       "Этот модуль содержит набор производных типов данных YANG 
        общего назначения.

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

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

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

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

     revision 2025-12-22 {
       description
         "Этот выпуск документа добавляет указанные ниже типы данных:
          - yang:date
          - yang:date-no-zone
          - yang:time
          - yang:time-no-zone
          - yang:hours32
          - yang:minutes32
          - yang:seconds32
          - yang:centiseconds32
          - yang:milliseconds32
          - yang:microseconds32
          - yang:microseconds64
          - yang:nanoseconds32
          - yang:nanoseconds64
          - yang:language-tag
          Определение yang-identifier приведено в соответствие с YANG
          1.1 и типами, представляющими время с високосными секундами.
          Представление часовых поясов приведено в соответствие с RFC 
          9557. Улучшены некоторые операторы description и pattern.";
       reference
         "RFC 9911: Common YANG Data Types";
     }
     revision 2013-07-15 {
       description
         "Этот выпуск документа добавляет указанные ниже типы данных:
          - yang:yang-identifier
          - yang:hex-string
          - yang:uuid
          - yang:dotted-quad";
       reference
         "RFC 6991: Common YANG Data Types";
     }
     revision 2010-09-24 {
       description
         "Исходный выпуск.";
       reference
         "RFC 6021: Common YANG Data Types";
     }

     /*** Набор типов для счётчиков и датчиков ***/

     typedef counter32 {
       type uint32;
       description
         "Тип counter32 представляет неотрицательные целые числа,
          которые монотонно растут до максимального значения
          2^32-1 (десятичное число 4294967295), затем счёт 
          повторяется с нуля.

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

          Тип counter32 не следует применять для конфигурационных 
          узлов схемы. НЕ СЛЕДУЕТ применять оператор default вместе
          с типом counter32.

          Набор значений и семантика этого типа эквивалентны типу
          Counter32 в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef zero-based-counter32 {
       type counter32;
       default "0";
       description
         "Тип zero-based-counter32 представляет counter32 с начальным
          значением 0. 
          
          Узел схемы этого типа будет устанавливаться в 0  при создании
          и далее будет монотонно расти до максимального значения 2^32-1
          (десятичное число 4294967295), затем обращаться в 0 с 
          последующим монотонным ростом.

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

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению ZeroBasedCounter32 в SMIv2.";
       reference
         "RFC 4502: Remote Network Monitoring Management Information
                    Base Version 2";
     }

     typedef counter64 {
       type uint64;
       description
         "Тип counter64 представляет неотрицательные целые числа,
          которые монотонно растут до максимального значения
          2^64-1 (десятичное число 18446744073709551615), затем 
          счёт повторяется с нуля.

          Для счётчиков не определены начальные значения, поэтому
          одиночное значение счётчика (обычно) не имеет смысла.
          Разрывы в монотонном росте значений счётчиков обычно
          связаны с реинициализацией системы управления или другими
          событиями, указанными в описании узла схемы, применяющего
          этот тип. Если не связанные с инициализацией события
          возможны, при создании счётчиков типа  counter64 не в
          процессе инициализации следует определить соответствующий
          узел схемы подходящего типа для указания последнего 
          разрыва счётчика.
 
          Тип counter64 не следует применять для конфигурационных 
          узлов схемы. НЕ СЛЕДУЕТ применять оператор default вместе
          с типом counter64.

          Набор значений и семантика этого типа эквивалентны типу
          Counter64 в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef zero-based-counter64 {
       type counter64;
       default "0";
       description
         "Тип zero-based-counter64 представляет counter64 с 
          начальным значением 0.

          Узел схемы этого типа будет устанавливаться в 0 при создании
          и далее будет монотонно расти до максимального значения
          2^64-1 (десятичное число 18446744073709551615), затем 
          обращаться в 0 с последующим монотонным ростом.

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

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению ZeroBasedCounter64 в SMIv2.";
       reference
         "RFC 2856: Textual Conventions for Additional High Capacity
                    Data Types";
     }

     typedef gauge32 {
       type uint32;
       description
         "Тип gauge32 представляет неотрицательное целое число,
          которое может расти и уменьшаться, не переходя максимального
          и минимального значения. Максимальное значение не может быть
          больше 2^32-1 (десятичное число 4294967295), а минимальное -
          меньше 0. Значение gauge32 достигает максимума, когда 
          моделируемые данные не меньше максимума, а минимума - когда
          моделируемые данные не больше минимального значения. Если
          моделируемые затем данные снижаются (растут) ниже максимума 
          (выше минимума) значение gauge32 также снижается (растёт).

          Набор значений и семантика этого типа эквивалентны типу
          Gauge32 в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef gauge64 {
       type uint64;
       description
         "Тип gauge64 представляет неотрицательное целое число,
          которое может расти и уменьшаться, не переходя максимального
          и минимального значения. Максимальное значение не может быть
          больше 2^64-1 (десятичное число 18446744073709551615), а 
          минимальное - меньше 0. Значение gauge32 достигает максимума, 
          когда моделируемые данные не меньше максимума, а минимума - 
          когда моделируемые данные не больше минимального значения. Если
          моделируемые затем данные снижаются (растут) ниже максимума 
          (выше минимума) значение gauge64 также снижается (растёт).

          Набор значений и семантика этого типа эквивалентны текстовому
          соглашению CounterBasedGauge64 SMIv2, определённому в RFC 2856";
       reference
         "RFC 2856: Textual Conventions for Additional High Capacity
                    Data Types";
     }

     /*** Набор типов, связанных с идентификаторами ***/

     typedef object-identifier {
       type string {
         pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9][0-9]*))))'
               + '(\.(0|([1-9][0-9]*)))*';
       }
       description
         "Тип object-identifier представляет административно 
          назначаемые имена в дереве registration-hierarchical-name.

          Значения этого типа представляются последовательностью
          числовых неотрицательных значений субидентификаторов, каждое
          ДОЛЖНО быть не более 2^32-1 (десятичное число 4294967295).
          Субидентификаторы разделяются одним символом точки без
          промежуточных пробельных символов.

          Стандарт ASN.1 ограничивает пространство значений первого
          субидентификатора цифрами 0, 1 и 2. Кроме того, диапазон
          второго субидентификатора ограничен значениями от 0 до 39,
          если первый субидентификатор равен 0 или 1. В дополнение 
          стандарт ASN.1 требует наличия в идентификаторе объекта не
          менее 2 субидентификаторов. Шаблон соответствует этим
          ограничениям.

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

          Этот тип является надмножеством типа SMIv2 OBJECT IDENTIFIER,
          поскольку не ограничен пределом в 128 субидентификаторов.
          Поэтому данный тип НЕ СЛЕДУЕТ применять для представления 
          SMIv2 OBJECT IDENTIFIER, взамен СЛЕДУЕТ использовать тип
          object-identifier-128.";
       reference
         "ISO 9834-1: Information technology -- Procedures for the
          operation of object identifier registration authorities --
          Part 1: General procedures and top arcs of the international
          object identifier tree";
     }

     typedef object-identifier-128 {
       type object-identifier {
         pattern '[0-9]*(\.[0-9]*){1,127}';
       }
       description
         "Этот тип представляет идентификаторы объектов, содержащие
          не более 128 субидентификаторов.

          Набор значений и семантика этого типа эквивалентны типу
          OBJECT IDENTIFIER в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     /*** Набор типов для дат и времени ***/

     typedef date-and-time {
       type string {
         pattern
           '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'
         + 'T(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)'
         + '(\.[0-9]+)?'
         + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
       }
       description
         "Тип date-and-time является профилем стандарта ISO 8601
          для представления дат и времени с использованием григорианского
          календаря. Профиль определён date-time в параграфе 5.6 RFC 3339
          и обновлён в разделе 2 RFC 9557. Значение 60 допускается лишь в
          в случае високосных секунд.

          Тип date-and-time совместим с типом dateTime схемы XML с учётом
          приведённых ниже исключений.

          (a) date-and-time не разрешает отрицательные значения лет.

          (b) Значение time-offset Z указывает, что date-and-time
              задано в UTC и локальный часовой пояс не известен.
              Значение time-offset +00:00 указывает, что date-and-time
              задано в UTC и локальным часовым поясом тоже служит UTC
              (см. раздел 2 в RFC 9557).

          Этот тип не эквивалентен текстовому соглашению DateAndTime 
          в SMIv2, поскольку RFC 3339 использует другой разделитель 
          между full-date и full-time, а также обеспечивает большую
          точность time-secfrac.

          Канонический формат для значений date-and-time с известным
          часовым поясом использует сдвиг часового пояса, который
          рассчитывается с использованием настроенного в устройстве 
          смещения от UTC. Смена смещения в устройстве меняет значение
          date-and-time должным образом. Такие изменения могут быть
          периодическими в результате перехода на летнее время (DST).
          В каноническом формате значений date-and-time в UTC с
          неизвестным часовым поясом СЛЕДУЕТ использовать 
          time-offset Z и МОЖНО MAY применять -00:00 для совместимости
          с прежними версиями.";
       reference
         "ISO 8601: Data elements and interchange formats -- Information
                    interchange -- Representation of dates and times
          RFC 3339: Date and Time on the Internet: Timestamps
          RFC 9557: Date and Time on the Internet: Timestamps
                    with Additional Information
          RFC 2579: Textual Conventions for SMIv2
          XSD-TYPES: XML Schema Definition Language (XSD) 1.1
                     Part 2: Datatypes";
     }

     typedef date {
       type string {
         pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'
               + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
       }
       description
         "Тип данных date представляет временной интервал в сутках (24
          24 часа) и может включать часовой пояс.

          Тип date совместим с типом date в схеме XML с приведёнными 
          ниже ограничениями:

          (a) Тип date не допускает отрицательные значения лет.

          (b) Значение time-offset Z указывает, что date задано в UTC 
              и локальный часовой пояс не известен. Значение time-offset 
              +00:00 указывает, что date задано в UTC и локальным 
              часовым поясом тоже служит UTC (см. раздел 2 в RFC 9557).

          Канонический формат для значений date с известным часовым
          поясом использует сдвиг часового пояса, который рассчитывается
          с использованием настроенного в устройстве смещения от UTC. 
          Смена смещения в устройстве меняет значение date должным 
          образом. Такие изменения могут быть периодическими в результате 
          перехода на летнее время (DST). В каноническом формате значений 
          date в UTC с неизвестным часовым поясом использзуется
          time-offset Z.";
       reference
         "RFC 3339: Date and Time on the Internet: Timestamps
          RFC 9557: Date and Time on the Internet: Timestamps
                    with Additional Information
          XSD-TYPES: XML Schema Definition Language (XSD) 1.1
                     Part 2: Datatypes";
     }

     typedef date-no-zone {
       type date {
         pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])';
       }
       description
         "Тип date-no-zone представляет дату без часового пояса.";
     }

     typedef time {
       type string {
         pattern
           '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)'
         + '(\.[0-9]+)?'
         + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
       }
       description
         "Тип time представляет момент времени, повторяющийся каждый
          день, и может включать часовой пояс. Значение 60 допускается
          только для високосных секунд.

          Тип time совместим с типом time схемы XML с одним исключением:

          (a) Значение time-offset Z указывает, что time задано в UTC 
              и локальный часовой пояс не известен. Значение time-offset 
              +00:00 указывает, что time задано в UTC и локальным 
              часовым поясом тоже служит UTC (см. раздел 2 в RFC 9557).

          Канонический формат для значений time с известным часовым
          поясом использует сдвиг часового пояса, который рассчитывается
          с использованием настроенного в устройстве смещения от UTC. 
          Смена смещения в устройстве меняет значение time должным 
          образом. Такие изменения могут быть периодическими в результате 
          перехода на летнее время (DST). В каноническом формате значений 
          time в UTC с неизвестным часовым поясом использзуется
          time-offset Z.";
       reference
         "RFC 3339: Date and Time on the Internet: Timestamps
          RFC 9557: Date and Time on the Internet: Timestamps
                    with Additional Information
          XSD-TYPES: XML Schema Definition Language (XSD) 1.1
                     Part 2: Datatypes";
     }

     typedef time-no-zone {
       type time {
         pattern
           '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)'
         + '(\.[0-9]+)?';
       }
       description
         "Тип time-no-zone представляет время без часового пояса.";
     }

     typedef hours32 {
       type int32;
       units "hours";
       description
         "Период времени, заданный в часах.

          Допустимые значения лежат в диапазоне [-89478485 дней 
          08:00:00 часов - 89478485 дней 07:00:00 часов].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";
     }

     typedef minutes32 {
       type int32;
       units "minutes";
       description
         "Период времени, заданный в минутах.

          Допустимые значения лежат в диапазоне [-1491308 дней 2:08:00 - 
          1491308 дней 2:07:00].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";
     }

     typedef seconds32 {
       type int32;
       units "seconds";
       description
         "Период времени, заданный в секундах.

          Допустимые значения лежат в диапазоне [-24855 дней 03:14:08 - 
          24855 дней 03:14:07].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";
     }

     typedef centiseconds32 {
       type int32;
       units "centiseconds";
       description
         "Период времени, заданный в сотых долях секунды.

          Допустимые значения лежат в диапазоне [-248 дней 13:13:56 - 
          248 дней 13:13:56].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef milliseconds32 {
       type int32;
       units "milliseconds";
       description
         "Период времени, заданный в миллисекундах.

          Допустимые значения лежат в диапазоне [-24 дня 20:31:23 - 
          24 дня 20:31:23].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef microseconds32 {
       type int32;
       units "microseconds";
       description
         "Период времени, заданный в микросекундах.

          Допустимые значения лежат в диапазоне [-00:35:47 to 00:35:47].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef microseconds64 {
       type int64;
       units "microseconds";
       description
         "Период времени, заданный в микросекундах.

          Допустимые значения лежат в диапазоне [-106751991 дней 04:00:54
          - 106751991 дней 04:00:54].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef nanoseconds32 {
       type int32;
       units "nanoseconds";
       description
         "Период времени, заданный в наносекундах.

          Допустимые значения лежат в диапазоне [-00:00:02 to 00:00:02].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef nanoseconds64 {
       type int64;
       units "nanoseconds";
       description
         "Период времени, заданный в наносекундах.

          Допустимые значения лежат в диапазоне [-106753 дней 23:12:44 -
          106752 дней 0:47:16].

          Для этого типа следует ограничивать диапазон, если приемлемы
          только неотрицательные интервалы (0..max).";     
     }

     typedef timeticks {
       type uint32;
       description
         "Тип timeticks представляет неотрицательные целые числа,
          которые указывают по модулю 2^32 (десятичное число
          4294967296) время в сотых долях секунды между двумя эпохами.
          При определении узла схемы, использующего этот тип, описание
          узла указывает обе опорных эпохи.

          Набор значений и семантика этого типа эквивалентны типу
          TimeTicks в SMIv2.";
       reference
         "RFC 2578: Structure of Management Information Version 2
                    (SMIv2)";
     }

     typedef timestamp {
       type timeticks;
       description
         "Тип timestamp представляет значение связанного с ним узла
          схемы timeticks, где происходит конкретное вхождение,
          которое должно быть определено в описании каждого узла схемы,
          определённого с использованием этого типа. Когда конкретное
          вхождение происходит до того, как связанный атрибут timeticks
          в последний раз был равен нулю, timestamp = 0. 

          Отметим, что это требует сброса в 0 всех значений timestamp,
          когда значение связанного атрибута timeticks превышает 497
          дней и переходит через 0.

          Связанный узел схемы timeticks должен быть задан в описании
          любого узла схемы, использующего этот тип.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению TimeStamp в SMIv2.";
       reference
         "RFC 2579: Textual Conventions for SMIv2";
     }

     /*** Набор базовых типов для адресов ***/

     typedef phys-address {
       type string {
         pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
       }
       description
         "Представляет адрес среды или физического уровня в форме 
          последовательности октетов, каждый из которых указывается
          двумя шестнадцатеричными цифрами. В каноническом 
          представлении используются строчные буквы (нижний регистр).

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению PhysAddress в SMIv2.";
       reference
         "RFC 2579: Textual Conventions for SMIv2";
     }

     typedef mac-address {
       type string {
         pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
       }
       description
         "Тип mac-address представляет адрес IEEE 802 MAC.
          В каноническом представлении используются строчные буквы.
          Отметим, что этот тип не может представлять адреса с рахмером,
          отличным от IEEE 802 MAC и для них можно применять тип
          phys-address.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению MacAddress в SMIv2.";
       reference
         "IEEE 802: IEEE Standard for Local and Metropolitan Area
                    Networks: Overview and Architecture
          RFC 2579: Textual Conventions for SMIv2";
     }

     /*** Тип, связанный с XML ***/

     typedef xpath1.0 {
       type string;
       description
         "Этот тип представляет выражение XPATH 1.0.

          Когда определяется узел схемы, использующий этот тип, 
          описание узла ДОЛЖНО указывать контекст XPath, в котором
          вычисляется выражение XPath.";
       reference
         "XPATH: XML Path Language (XPath) Version 1.0";
     }

     /*** Строковые типы ***/

     typedef hex-string {
       type string {
         pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
       }
       description
         "Шестнадцатеричная строка с октетами, представленными двумя
          шестнадцатеричными цифрами, разделёнными двоеточием. В 
          каноническом варианте применяются строчные буквы.";
     }

     typedef uuid {
       type string {
         pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
               + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
       }
       description
         "Глобально уникальный идентификатор (UUID) в строковом 
          представлении, определённом в RFC 4122. В каноническом варианте 
          применяются строчные буквы.

          Ниже приведён пример строкового представления UUID 
          f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
       reference
         "RFC 9562: Universally Unique IDentifiers (UUIDs)";
     }

     typedef dotted-quad {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
       }
       description
         "32-битовое целое число без знака, представленное 4 десятичными
          числами, разделёнными точками (full stop).";
     }

     typedef language-tag {
       type string;
       description
         "Тег языка в соответствии с RFC 5646 (BCP 47). В каноническом
          представлении применяются строчные буквы.

          Значения этого типа должны быть корректно сформированными
          тегами языка в соответствии с BCP 47. Реализации МОГУТ 
          дополнительно ограничивать принимаемые значения 'проверяющим'
          процессором, как указано в BCP 47.

          Каноническое представление значений этого типа соответствует
          тектовому соглашению SMIv2 LangTag с учётом ограничений по
          длине, принятых для LangTag.";
       reference
         "RFC 5646: Tags for Identifying Languages
          RFC 5131: A MIB Textual Convention for Language Tags";
     }

     /*** Набор типов, связанных с YANG ***/

     typedef yang-identifier {
       type string {
         length "1..max";
         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
       }
       description
         "Строка идентификатора YANG в соответствии с правилом 
          'identifier' раздела 14 в RFC 7950. Идентификатор должен
          начинаться с буквы или символа подчёркивания, за которым
          следует произвольный набор букв, цифр, символов подчёркивания,
          дефисов и точек.

          Это определение соответствует YANG 1.1 (RFC 7950). В RFC 6991
          определение исключало строки, начинающиеся с xml (в любой
          комбинации регистров), как было задано для YANG 1 в RFC 6020. 
          Если данный тип применяется в контекте YANG 1, следует
          соблюдать данное ограничение.";
       reference
         "RFC 7950: The YANG 1.1 Data Modeling Language
          RFC 6991: Common YANG Data Types
          RFC 6020: YANG - A Data Modeling Language for the
                    Network Configuration Protocol (NETCONF)";
     }
   }
   <CODE ENDS>

4. Типы для стека протоколов Internet

Модуль YANG ietf-inet-types ссылается на [RFC0768], [RFC0791], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2317], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC3927], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], [RFC4592], [RFC5017], [RFC5322], [RFC5890], [RFC5952], [RFC6532], [RFC6793], [RFC8200], [RFC9260], [RFC9293], [RFC9499].

   <CODE BEGINS> file "ietf-inet-types@2025-12-22.yang"
   module ietf-inet-types {
     namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
     prefix inet;

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

        Editor:   Jürgen Schönwälder
                  <mailto:jschoenwaelder@constructor.university>"; 
     description
       "Этот модуль содержит набор производных типов данных YANG 
        для адресов Internet и связанных элементов.

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

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

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

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

     revision 2025-12-22 {
       description
         "В этом выпуске добавлены указанные ниже типы данных:
          - inet:ip-address-and-prefix
          - inet:ipv4-address-and-prefix
          - inet:ipv6-address-and-prefix
          - inet:protocol-number
          - inet:upper-layer-protocol-number
          - inet:host-name
          - inet:email-address
          - inet:ip-address-link-local
          - inet:ipv4-address-link-local
          - inet:ipv6-address-link-local
          Определение inet:host было изменено с использованием
          inet:host-name вместо inet:domain-name. Улучшены некоторые 
          операторы pattern.";
       reference
         "RFC 9911: Common YANG Data Types";
     }
     revision 2013-07-15 {
       description
         "В этом выпуске добавлены типы данных:
          - inet:ip-address-no-zone
          - inet:ipv4-address-no-zone
          - inet:ipv6-address-no-zone";
       reference
         "RFC 6991: Common YANG Data Types";
     }
     revision 2010-09-24 {
       description
         "Исходный выпуск.";
       reference
         "RFC 6021: Common YANG Data Types";
     }

     /*** Набор типов для полей протоколов ***/

     typedef ip-version {
       type enumeration {
         enum unknown {
           value 0;
           description
             "An unknown or unspecified version of the Internet
              Protocol.";
         }
         enum ipv4 {
           value 1;
           description
             " Протокол IPv4 в соответствии с RFC 791.";
         }
         enum ipv6 {
           value 2;
           description
             " Протокол IPv6 в соответствии с RFC 8200.";
         }
       }
       description
         "Это значение представляет версию протокола IP.

          По набору значений и семантике этот тип эквивалентен
          текстовому соглашению InetVersion в SMIv2.";
       reference
         "RFC  791: Internet Protocol
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification
          RFC 4001: Textual Conventions for Internet Network Addresses";
     }

     typedef dscp {
       type uint8 {
         range "0..63";
       }
       description
         "Тип dscp представляет коды дифференцированного обслуживания,
          которые могут применяться для маркировки пакетов в потоке.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению Dscp в SMIv2.";
       reference
         "RFC 3289: Management Information Base for the Differentiated
                    Services Architecture
          RFC 2474: Definition of the Differentiated Services Field
                    (DS Field) in the IPv4 and IPv6 Headers
          RFC 2780: IANA Allocation Guidelines For Values In
                    the Internet Protocol and Related Headers";
     }

     typedef ipv6-flow-label {
       type uint32 {
         range "0..1048575";
       }
       description
         "Тип ipv6-flow-label представляет идентификатор или метку 
          потока в заголовке пакета IPv6, которые могут служить для 
          различения потоков трафика.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению IPv6FlowLabel в SMIv2.";
       reference
         "RFC 3595: Textual Conventions for IPv6 Flow Label
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
     }

     typedef port-number {
       type uint16 {
         range "0..65535";
       }
       description
         "Тип port-number представляет 16-битовый номер порта протоколов
          транспортного уровня Internet, таких как UDP, TCP, DCCP, SCTP.

          Номера портов распределяются IANA. Текущий список выделенных
          портов доступен на сайте <http://www.iana.org/>. 

          Отметим, что номер 0 зарезервирован IANA.  В ситуациях, где
          нулевое значение не имеет смысла, оно может быть исключено
          путём создания субтипа для port-number без 0. 

          Набор значений и семантика для этого типа эквивалентны 
          текстовому соглашению InetPortNumber в SMIv2.";

       reference
         "RFC  768: User Datagram Protocol
          RFC 9293: Transmission Control Protocol (TCP)
          RFC 9260: Stream Control Transmission Protocol
          RFC 4340: Datagram Congestion Control Protocol (DCCP)
          RFC 4001: Textual Conventions for Internet Network Addresses";
     }

     typedef protocol-number {
       type uint8;
       description
         "Тип protocol-number представляет 8-битовый номер протокола 
          Internet, передаваемый в поле protocol заголовка IPv4 или в
          поле next header заголовка IPv6.
          Номера протоколов выделяются IANA. Текущий список номеров
          доступен по ссылке <https://www.iana.org/>."; 
       reference
         "RFC  791: Internet Protocol
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
     }

     typedef upper-layer-protocol-number {
       type protocol-number;
       description
         "Поле upper-layer-protocol-number представляет протокол 
          вышележащего уровня в пакете IP. Для пакетов IPv6 с заголовками
          расширения этот номер передаётся в последнем поле next header
          цепочки заголовков расширения IPv6.";
       reference
         "RFC  791: Internet Protocol
          RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
     }

     /*** Набор типов, связанных с автономными системами ***/

     typedef as-number {
       type uint32;
       description
         "Тип as-number представляет номера автономных систем (AS). 
          AS образует набор маршрутизаторов с общим техническим
          администрированием, использующих протокол внутренней
          маршрутизации и общую метрику внутри AS, а также протокол
          внешней маршрутизации для пересылки пакетов в другие AS. IANA 
          поддерживает пространство номеров AS, передав большую часть
          блоков AS для распределения региональным регистраторам.

          Номера AS исходно были 16-битовыми, но расширения BGP
          увеличили размер пространства номеров AS до 32 битов.
          Поэтому данный тип использует базовый тип uint32 без 
          ограничения диапазона для поддержки полного пространства.

          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению InetAutonomousSystemNumber в SMIv2.";
       reference
         "RFC 1930: Guidelines for creation, selection, and registration
                    of an Autonomous System (AS)
          RFC 4271: A Border Gateway Protocol 4 (BGP-4)
          RFC 4001: Textual Conventions for Internet Network Addresses
          RFC 6793: BGP Support for Four-Octet Autonomous System (AS)
                    Number Space";
     }

     /*** Набор типов для адресов IP и имён хостов ***/

     typedef ip-address {
       type union {
         type ipv4-address;
         type ipv6-address;
       }
       description
         "Тип ip-address представляет адрес IP независимо от версии IP.
          Формат текстового представления подразумевает версию IP. 
          Этот тип поддерживает ограниченные (scoped) адреса, разрешая
          указывать идентификаторы зон в формате адресов.";
       reference
         "RFC 4007: IPv6 Scoped Address Architecture";
     }

     typedef ipv4-address {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
         + '(%.+)?';
       }
       description
         "Тип ipv4-address представляет адрес IPv4 в десятичной
          нотации с разделением точками. Адрес IPv4 может включать
          индекс зоны, отделённый символом %. Если в системе применяются
          имена зон, не представляемые символами UTF-8, реализации нужно
          иметь механизм преобразования локального имени в UTF-8. 
          Задание такого механизма выходит за рамки этого документа.

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

          Каноническим для индекса зоны является числовой формат.";
     }
     typedef ipv6-address {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(%.+)?';
       }
       description
         "Тип ipv6-address представляет адрес IPv6 в полной, сокращённой
          или сокращённой смешанной нотации. Адрес IPv6 может включать 
          индекс зоны, отделённый символом %. Если в системе применяются
          имена зон, не представляемые символами UTF-8, реализации нужно
          иметь механизм преобразования локального имени в UTF-8. 
          Задание такого механизма выходит за рамки этого документа.

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

          Канонический формат адреса IPv6 использует текстовое
          представление, определённое в разделе 4 RFC 5952. 
          Для индекса зоны каноническим является числовой
          формат, описанный в параграфе 11.2 RFC 4007.";
       reference
         "RFC 4291: IP Version 6 Addressing Architecture
          RFC 4007: IPv6 Scoped Address Architecture
          RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     typedef ip-address-no-zone {
       type union {
         type ipv4-address-no-zone;
         type ipv6-address-no-zone;
       }
       description
         "Тип ip-address-no-zone представляет адрес IP независимо от
          версии IP. Формат текстового представления подразумевает
          версию IP. Этот тип не поддерживает ограниченные (scoped)
          адреса, поскольку он не включает идентификатор зоны.";
       reference
         "RFC 4007: IPv6 Scoped Address Architecture";
     }

     typedef ipv4-address-no-zone {
       type ipv4-address {
         pattern '[0-9\.]*';
       }
       description
         "Адрес IPv4 без индекса зоны. Этот тип, производный от 
          ipv4-address, может применяться в ситуациях, где индекс зоны
          известен из контекста и поэтому не требуется.";
     }

     typedef ipv6-address-no-zone {
       type ipv6-address {
         pattern '[0-9a-fA-F:\.]*';
       }
       description
         "Адрес IPv6 без индекса зоны. Этот тип, производный от 
          ipv6-address, может применяться в ситуациях, где индекс зоны
          известен из контекста и поэтому не требуется.";
       reference
         "RFC 4291: IP Version 6 Addressing Architecture
          RFC 4007: IPv6 Scoped Address Architecture
          RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     typedef ip-address-link-local {
       type union {
         type ipv4-address-link-local;
         type ipv6-address-link-local;
       }
       description
         "Тип ip-address-link-local представляет адрес link-local 
          независимо от версии IP. Формат текстового представления
          подразумевает версию IP.";
     }

     typedef ipv4-address-link-local {
       type ipv4-address {
         pattern '169\.254\..*';
       }
       description
         "Тип ipv4-address-link-local представляет адрес link-local IPv4
          в префиксе 169.254.0.0/16, как указано в параграфе 2.1 
          RFC 3927.";
       reference
         "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses";
     }

     typedef ipv6-address-link-local {
       type ipv6-address {
         pattern '[fF][eE][89aAbB][0-9a-fA-F]:.*';
       }
       description
         "Тип ipv6-address-link-local представляет адрес link-local IPv6
          в префиксе fe80::/10, как указано в параграфе 2.4 RFC 4291.";
       reference
         "RFC 4291: IP Version 6 Addressing Architecture";
     }

     typedef ip-prefix {
       type union {
         type ipv4-prefix;
         type ipv6-prefix;
       }
       description
         "Тип ip-prefix представляет префикс IP независимо от версии IP.
          Формат текстового представления подразумевает версию IP.";
     }

     typedef ipv4-prefix {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
         + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
       }
       description
         "Тип ipv4-prefix представляет адресный префикс IPv4. Размер 
          префикса указывается числом после знака / и должен
          быть не больше 32.
   
          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.

          Канонический формат префикса IPv4 имеет значение 0 во всех
          битах адреса IPv4, не являющихся частью префикса IPv4.";

          Определение ipv4-prefix не требует установки значения 0 для
          битов, не являющихся частью префикса. Однако реализации должны
          возвращать значения в каноническом формате, который требует
          установки таких битов в 0. Это означает, что префикс 
          192.0.2.1/24 должен восприниматься как корректный, но
          преобразовываться в каноническое значение 192.0.2.0/24.";
     }

     typedef ipv6-prefix {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(/.+)';
       }
       description
         "Тип ipv6-prefix представляет адресный префикс IPv6. Размер 
          префикса указывается числом после знака / и должен
          быть не больше 128.

          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.

          В адресе IPv6 все биты, не относящиеся к префиксу, следует
          устанавливать в 0.

          Канонический формат префикса IPv6 имеет значение 0 во всех
          битах адреса IPv6, не являющихся частью префикса IPv6. 
          Кроме того, адреса IPv6 представляется в соответствии 
          с разделом 4 RFC 5952.";

          Определение ipv6-prefix не требует установки значения 0 для
          битов, не являющихся частью префикса. Однако реализации должны
          возвращать значения в каноническом формате, который требует
          установки таких битов в 0. Это означает, что префикс 
          2001:db8::1/64 должен восприниматься как корректный, но
          преобразовываться в каноническое значение 2001:db8::/64.";
       reference
         "RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     typedef ip-address-and-prefix {
       type union {
         type ipv4-address-and-prefix;
         type ipv6-address-and-prefix;
       }
       description
         "Тип ip-address-and-prefix представляет адрес IP и префикс 
          независимо от версии IP. Формат текстового представления
          подразумевает версию IP.";
     }

     typedef ipv4-address-and-prefix {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
         + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
       }
       description
         "Тип ipv4-address-and-prefix представляет адрес IPv4 и
          связанный с ним префикс IPv4. Размер префикса указывается
          число после символа / и не может быть больше 32.

          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.
     }

     typedef ipv6-address-and-prefix {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(/.+)';
       }
       description
         "Тип ipv6-address-and-prefix представляет адрес IPv6 и
          связанный с ним префикс IPv6. Размер префикса указывается
          число после символа / и не может быть больше 128.

          Размер префикса n соответствует маске адреса IP, где
          n старших битов подряд имеют значение 1, а остальные - 0.

          Канонический формат требует представления адреса IPv6 
          в соответствии с разделом 4 в RFC 5952.";
       reference
         "RFC 5952: A Recommendation for IPv6 Address Text
                    Representation";
     }

     /*** Набор типов для доменных имён и URI ***/

     typedef domain-name {
       type string {
         length "1..253";
         pattern
           '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
         + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
         + '|\.';
       }
       description
         "Тип domain-name представляет доменные имена DNS.
          По возможности СЛЕДУЕТ применять полные имена (FQDN⁴). Этот
          тип не поддерживает шаблоны (wildcards, см. RFC 4592) и
          бесклассовое делегирование in-addr.arpa (см. RFC 2317).

          Доменные имена Internet не заданы жёстко. Параграф 3.5 в
          RFC 1034 задаёт рекомендуемый синтаксис (изменён в
          параграфе 2.1 RFC 1123). Показанный выше шаблон рассчитан
          на современную практику применения доменных имён и 
          возможные расширения. Отметим, что имена хостов Internet
          имеют более строгий синтаксис (см. RFC 952), чем рекомендации 
          DNS в RFC 1034 и 1123. Узлам схемы, представляющим имена
          хостов, следует применять тип host-name взамен domain-type.

          Размер имён DNS в протоколе DNS ограничен 255 символами.
          Поскольку в кодировании применяются метки с префиксом, 
          задающим размер в байтах, и завершающим NULL-байтом, 
          максимальный размер текстовой части метки составляет 253.

          Раздел описания узлов схемы, использующих тип domain-name,
          ДОЛЖЕН указывать, когда и как эти имена преобразуются в адреса
          IP. Отметим, что для преобразования значений domain-name может
          потребоваться запрос множества записей DNS (например, A для 
          IPv4 и AAAA для IPv6). Порядок преобразования и приоритет 
          записей DNS могут указываться явно или определятся 
          конфигурацией распознавателя (resolver).

          Значения доменных имён используют кодировку US-ASCII со 
          строчными буквами US-ASCII для канонического формата. Имена на 
          других языках ДОЛЖНЫ быть A-метками в соответствии с RFC 5890";
       reference
         "RFC  952: DoD Internet Host Table Specification
          RFC 1034: Domain Names - Concepts and Facilities
          RFC 1123: Requirements for Internet Hosts -- Application
                    and Support
          RFC 2317: Classless IN-ADDR.ARPA delegation
          RFC 2782: A DNS RR for specifying the location of services
                    (DNS SRV)
          RFC 4592: The Role of Wildcards in the Domain Name System
          RFC 5890: Internationalized Domain Names in Applications
                    (IDNA): Definitions and Document Framework
          RFC 9499: DNS Terminology";
     }

     typedef host-name {
       type domain-name {
         length "2..max";
         pattern '[a-zA-Z0-9\-\.]+';
       }
       description
         "Тип host-name представляет полное доменное имя хоста. Размер
          имени должен быть не менее 2 символов (см. RFC 952), которыми
          могут быть буквы, цифры и символы дефиса, разделённые точками
          (см. RFC 1123 и 952).";
       reference
         "RFC  952: DoD Internet Host Table Specification
          RFC 1123: Requirements for Internet Hosts -- Application
                    and Support";
     }

     typedef host {
       type union {
         type ip-address;
         type host-name;
       }
       description
        "Тип host представляет адрес IP или доменное имя (FQDN).";
     }

     typedef uri {
       type string {
         pattern '[a-z][a-z0-9+.-]*:.*';
       }
       description
         "Тип uri представляет идентификаторы URI⁵, заданные в STD 66.

          Объекты, использующие тип uri, ДОЛЖНЫ указываться в кодировке 
          ASCII и ДОЛЖНЫ нормализоваться в соответствии с параграфами 
          6.2.1, 6.2.2.1 и 6.2.2.2 в RFC 3986. Все необязательные 
          %-представления заменяются символами, для независимых от 
          регистра символов устанавливается нижний регистр, за 
          исключением шестнадцатеричных цифр, которые нормализуются в 
          верхний регистр как указано в параграфах 6.2.2.1 RFC 3986.

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

          Объекты, использующие тип uri, могут ограничивать разрешённые
          схемы. Например, схемы data: и urn: могут не подойти.

          URI нулевого размера не являются пригодными. Они могут служить
          для указания отсутствия URI при необходимости.
          Набор значений и семантика этого типа эквивалентны 
          текстовому соглашению Uri SMIv2, определённому в RFC 5017.";
       reference
         "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
          RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
                    Group: Uniform Resource Identifiers (URIs), URLs,
                    and Uniform Resource Names (URNs): Clarifications
                    and Recommendations
          RFC 5017: MIB Textual Conventions for Uniform Resource
                    Identifiers (URIs)";
     }

     typedef email-address {
       type string {
         pattern '.+@.+';
       }
       description
         "Тип email-address представляет адреса электронной почты 
          в международном формате (internationalized).

          Формат адресов электронной почты задан правилом addr-spec
          ABNF в параграфе 3.4.1 RFC 5322. Этот формат был расширен в
          RFC 6532 для поддержки адресов на других языках. Реализации
          ДОЛЖНЫ поддерживать расшинения интернационализации RFC 6532.
          Поддержка устаревших obs-local-part, obs-domain, obs-qtext 
          из RFC 5322 не требуется.

          В доменной части могут применяться метки A и U (см RFC 5890).
          В каноническом формате доменной части используются символы
          нижнего регистра и метки U (RFC 5890), когда это применимо.";
       reference
         "RFC 5322: Internet Message Format
          RFC 5890: Internationalized Domain Names in Applications
                    (IDNA): Definitions and Document Framework
          RFC 6532: Internationalized Email Headers";
     }
   }
   <CODE ENDS>

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

В этом документе используются URI для ietf-yang-types и ietf-inet-types в реестре IETF XML Registry [RFC3688].

В соответствии с этим документом агентство IANA обновило реестр YANG Module Names с указанием данного вместо [RFC6991] для модулей ietf-yang-types и ietf-inet-types. В соответствии с форматом [RFC6020] эти представления имеют вид:

   Name:  ietf-yang-types
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-yang-types
   Prefix:  yang
   Reference:  RFC 9911

   Name:  ietf-inet-types
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-inet-types
   Prefix:  inet
   Reference:  RFC 9911

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

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

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

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

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

[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>.

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

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, «IPv6 Scoped Address Architecture», RFC 4007, DOI 10.17487/RFC4007, March 2005, <https://www.rfc-editor.org/info/rfc4007>.

[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>.

[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>.

[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>.

[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>.

[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>.

[RFC9557] Sharma, U. and C. Bormann, «Date and Time on the Internet: Timestamps with Additional Information», RFC 9557, DOI 10.17487/RFC9557, April 2024, <https://www.rfc-editor.org/info/rfc9557>.

[RFC9562] Davis, K., Peabody, B., and P. Leach, «Universally Unique IDentifiers (UUIDs)», RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/info/rfc9562>.

[XPATH] Clark, J., Ed. and S. DeRose, Ed., «XML Path Language (XPath) Version 1.0», W3C Recommendation, 16 November 1999, <http://www.w3.org/TR/xpath-10>.

[XSD-TYPES] Peterson, D., Ed., Gao, S., Ed., Malhotra, A., Ed., Sperberg-McQueen, C., Ed., and H. S. Thompson, Ed., «W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes», W3C Recommendation, 5 April 2012, <https://www.w3.org/TR/xmlschema11-2/>.

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

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, «DoD Internet host table specification», RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1930] Hawkinson, J. and T. Bates, «Guidelines for creation, selection, and registration of an Autonomous System (AS)», BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, <https://www.rfc-editor.org/info/rfc1930>.

[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, «Classless IN-ADDR.ARPA delegation», BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <https://www.rfc-editor.org/info/rfc2579>.

[RFC2780] Bradner, S. and V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <https://www.rfc-editor.org/info/rfc2780>.

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

[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, «Textual Conventions for Additional High Capacity Data Types», RFC 2856, DOI 10.17487/RFC2856, June 2000, <https://www.rfc-editor.org/info/rfc2856>.

[RFC3289] Baker, F., Chan, K., and A. Smith, «Management Information Base for the Differentiated Services Architecture», RFC 3289, DOI 10.17487/RFC3289, May 2002, <https://www.rfc-editor.org/info/rfc3289>.

[RFC3305] Mealling, M., Ed. and R. Denenberg, Ed., «Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations», RFC 3305, DOI 10.17487/RFC3305, August 2002, <https://www.rfc-editor.org/info/rfc3305>.

[RFC3595] Wijnen, B., «Textual Conventions for IPv6 Flow Label», RFC 3595, DOI 10.17487/RFC3595, September 2003, <https://www.rfc-editor.org/info/rfc3595>.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/info/rfc3927>.

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, «Textual Conventions for Internet Network Addresses», RFC 4001, DOI 10.17487/RFC4001, February 2005, <https://www.rfc-editor.org/info/rfc4001>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.

[RFC4502] Waldbusser, S., «Remote Network Monitoring Management Information Base Version 2», RFC 4502, DOI 10.17487/RFC4502, May 2006, <https://www.rfc-editor.org/info/rfc4502>.

[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>.

[RFC5017] McWalter, D., Ed., «MIB Textual Conventions for Uniform Resource Identifiers (URIs)», RFC 5017, DOI 10.17487/RFC5017, September 2007, <https://www.rfc-editor.org/info/rfc5017>.

[RFC5131] McWalter, D., Ed., «A MIB Textual Convention for Language Tags», RFC 5131, DOI 10.17487/RFC5131, December 2007, <https://www.rfc-editor.org/info/rfc5131>.

[RFC5322] Resnick, P., Ed., «Internet Message Format», RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[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>.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.

[RFC5952] Kawamura, S. and M. Kawashima, «A Recommendation for IPv6 Address Text Representation», RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.

[RFC6021] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6021, DOI 10.17487/RFC6021, October 2010, <https://www.rfc-editor.org/info/rfc6021>.

[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>.

[RFC6532] Yang, A., Steele, S., and N. Freed, «Internationalized Email Headers», RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.

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

[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>.

[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, «Stream Control Transmission Protocol», RFC 9260, DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/info/rfc9260>.

[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>.

[ISO-8601] ISO/IEC, «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO/IEC 8601:2000, December 2008, <https://www.iso.org/standard/26780.html>.

[ISO-9834-1] ISO/IEC, «Information technology — Procedures for the operation of object identifier registration authorities — Part 1: General procedures and top arcs of the international object identifier tree», ISO/IEC 9834-1:2012, 2012, <https://www.iso.org/standard/58055.html>.

[IEEE-802-2024] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2024, DOI 10.1109/IEEESTD.2025.10935844, March 2025, <https://doi.org/10.1109/IEEESTD.2025.10935844>.

[Err4076] RFC Errata, Erratum ID 4076, RFC 6991, <https://www.rfc-editor.org/errata/eid4076>.

[Err5105] RFC Errata, Erratum ID 5105, RFC 6991, <https://www.rfc-editor.org/errata/eid5105>.

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

В создании исходного документа, опубликованного как [RFC6021] приняли участие: Andy Bierman, Martin Björklund, Balazs Lengyel, David Partain, Phil Shafer.

Полезные замечания к черновым вариантам этого документа представили: Andy Bierman, Martin Björklund, Benoît Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman, Dan Romascanu.

Адрес автора

Jürgen Schönwälder (editor)

Constructor University

Email: jschoenwaelder@constructor.university

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

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

nmalykh@protokols.ru

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

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

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

4Fully qualified domain name.

5Uniform Resource Identifier — унифицированный идентификатор ресурса.

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

RFC 9900 Updates to NETCONF Transport Port Numbers

Опубликовано 02.12.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 9900                                        Orange
Category: Standards Track                                  December 2025
ISSN: 2070-1721

Updates to NETCONF Transport Port Numbers

Обновление номеров транспортных портов NETCONF

PDF

Аннотация

Этот документ освобождает выделенные IANA номера портов для служб, связанных с протокол конфигурации сетей (Network Configuration Protocol или NETCONF), которые не использовались в работающих сетях.

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

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

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

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

1. Введение

В реестр Service Name and Transport Protocol Port Number Registry [IANA-SERVICE] внесено несколько назначений портов имен служб, связанных с NETCONF, таких как порт 830 для работы NETCONF по протоколу SSH (Secure Shell) [RFC6242], 831 для NETCONF по протоколу BEEP (Blocks Extensible Exchange Protocol) [RFC4744], 832 для NETCONF по протоколу SOAP (Simple Object Access Protocol) [RFC4743], 4334 для NETCONF по протоколу Call Home [RFC8071] и 6513 для NETCONF по протоколу TLS (Transport Layer Security) [RFC7589] [NETCONF-over-TLS]. Однако три из этих назначений (831, 832, 833) относятся к протоколам, которые не были внедрены, а соответствующие RFC ([RFC4743] и [RFC4744]) признаны устаревшими (Historic). Таким образом, эти назначения стали ненужными.

Данный документ отменяет назначение неиспользуемых номеров портов. В соответствии с параграфом 8.2 в [RFC6335] документ не отменяет имена служб.

2. Эксплуатационные вопросы

Не известно реализаций и внедрений протоколов, которые полагаются на освобождаемые этим документом номера портов. Существующие конфигурации (при наличии), связывающие освобождаемые номера портов со службами netconf-beep или netconfsoaphttp, нужно пересмотреть и обновить в соответствии с разделом 4. Других требований, связанных с эксплуатацией или управляемостью, данный документ не содержит.

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

Этот документ не описывает какой-либо протокол, поэтому не может открывать какие-либо уязвимости в безопасности.

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

В соответствии с этим документом агентство IANA обновило реестр Service Name and Transport Protocol Port Number Registry [IANA-SERVICE], как указано в последующих параграфах. Отменённые назначения помечены в соответствии с параграфом 8.2 в [RFC6335]. Далее эти действия не повторяются.

4.1. NETCONF на основе BEEP

Таблица . Прежние назначения.

Имя службы	Номер порта	Транспортный протокол	Описание	Документ
netconf-beep	831	tcp	NETCONF over BEEP	[RFC4744]
netconf-beep	831	udp	NETCONF over BEEP	[RFC4744]

Таблица . Новое назначение.

Имя службы	Номер порта	Транспортный протокол	Описание	Документ
netconf-beep			NETCONF over BEEP	[RFC4744] RFC 9900

К номеру 831 добавлено примечание, указывающее, что номер был выделен для NETCONF over BEEP, но освобождён RFC 9900.

4.2. NETCONF на основе SOAP

Таблица . Прежние назначения.

Имя службы	Номер порта	Транспортный протокол	Описание	Документ
netconfsoaphttp	832	tcp	NETCONF for SOAP over HTTPS	[RFC4743]
netconfsoaphttp	832	udp	NETCONF for SOAP over HTTPS	[RFC4743]
netconfsoapbeep	833	tcp	NETCONF for SOAP over BEEP	[RFC4743]
netconfsoapbeep	833	udp	NETCONF for SOAP over BEEP	[RFC4743]

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

Имя службы	Номер порта	Транспортный протокол	Описание	Документ
netconfsoaphttp			NETCONF for SOAP over HTTPS	[RFC4743] RFC 9900
netconfsoapbeep			NETCONF for SOAP over BEEP	[RFC4743] RFC 9900

К номерам 832 и 833 добавлены примечания, указывающие, что номер был выделен для NETCONF over SOAP, но освобождён RFC 9900.

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

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

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

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

[IANA-SERVICE] IANA, «Service Name and Transport Protocol Port Number Registry», <https://www.iana.org/assignments/service-names-port-numbers>.

[NETCONF-over-TLS] Turner, S. and R. Housley, «Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication», Work in Progress, Internet-Draft, draft-ietf-netconf-over-tls13-04, 18 January 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-tls13-04>.

[RFC4743] Goddard, T., «Using NETCONF over the Simple Object Access Protocol (SOAP)», RFC 4743, DOI 10.17487/RFC4743, December 2006, <https://www.rfc-editor.org/info/rfc4743>.

[RFC4744] Lear, E. and K. Crozier, «Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)», RFC 4744, DOI 10.17487/RFC4744, December 2006, <https://www.rfc-editor.org/info/rfc4744>.

[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>.

[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, «Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication», RFC 7589, DOI 10.17487/RFC7589, June 2015, <https://www.rfc-editor.org/info/rfc7589>.

[RFC8071] Watsen, K., «NETCONF Call Home and RESTCONF Call Home», RFC 8071, DOI 10.17487/RFC8071, February 2017, <https://www.rfc-editor.org/info/rfc8071>.

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

Спасибо Amanda Baber и Zahed Sarker за руководство, Tom Petch — за комментарии.

Спасибо Kent Watsen за рецензию Shepherd, Mahesh Jethanandani за рецензию AD, Bernie Volz за рецензию INTDIR, Roni Even за рецензию Gen-ART, Barry Leiba за рецензию ARTART, Dhruv Dhody за рецензию OPSDIR, Michael Tüxen за рецензию TSVART и Joe Touch на порт.

Спасибо Gorry Fairhurst за рецензию IESG.

Адрес автора

Mohamed Boucadair

Orange

Email: mohamed.boucadair@orange.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9875 HTTP Cache Groups

Опубликовано 23.10.2025 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 9875                                    Cloudflare
Category: Standards Track                                   October 2025
ISSN: 2070-1721

HTTP Cache Groups

Группы кэша HTTP

PDF

Аннотация

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

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

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

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

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

1. Введение

Кэширование HTTP [HTTP-CACHING] работает на уровне одного ресурса и свежесть одного сохранённого отклика не влияет на свежесть других. Такая гранулярность может повысить эффективность кэширования, например, в случае включения в страницу нескольких ресурсов с разными требованиями к кэшированию.

Однако в некоторых случаях связи между сохранёнными откликами могут повышать эффективность кэширования. Например, часто возникает необходимость аннулировать (invalidate) набор связанных ресурсов. Это может быть связано с побочным влиянием запроса на изменение состояния на другие ресурсы или задано для удобства администрирования (например, аннулировать некую часть сайта). Группировка ресурсов обеспечивает способ выразить такие взаимосвязи вместо того, чтобы полагаться на такие вещи, как структура URL.

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

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

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

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

1.1. Уровни требований и терминология

В спецификации применяются термины, определённые в [STRUCTURED-FIELDS]: List, String, Parameter.

2. Поле Cache-Groups в заголовке отклика

Поле Cache-Groups в заголовке отклика содержит список строк (List of Strings, параграфы 3.1 и 3.3.3 в [STRUCTURED-FIELDS]). Каждый элемент списка является значением, идентифицирующим группу, к которой отклик относится. Строки «непрозрачны» (opaque) и не имеют никакого смысла для создавшего их сервера, кэш не знает их структуру и содержимое, кроме однозначной идентификации группы.

   HTTP/1.1 200 OK
   Content-Type: application/javascript
   Cache-Control: max-age=3600
   Cache-Groups: "scripts"

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

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

2.1. Идентификация сгруппированных откликов

Два отклика, хранящиеся в одном кэше, считаются относящимися к одной группе при выполнении двух условий:

оба отклика включают поле заголовка Cache-Groups с одинаковым значением (в любой позиции списка) при посимвольном сравнении с учётом регистра;
в обоих откликах совпадают URI источника (параграф 4.3.1 в [HTTP]).

2.2. Поведение кэша

2.2.1. Аннулирование

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

Расширения кэша могут усиливать это требование. Например, поле заголовка управления целевым кэшем [TARGETED] может указывать на то, что при обработке кэшей следует аннулировать такие отклики.

3. Поле Cache-Group-Invalidation в заголовке отклика

Поле Cache-Group-Invalidation в заголовке отклика является списком строк (параграфы 3.1 и 3.3.3 в [STRUCTURED-FIELDS]). Каждый элемент списка является значением, указывающим группу, отклики из которой аннулируются в соответствии с параграфом 2.2.1.

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

   HTTP/1.1 200 OK
   Content-Type: text/html
   Cache-Group-Invalidation: "eurovision-results", "australia"

Поле Cache-Group-Invalidation должно игнорироваться в откликах на запросы, использующие безопасный метод (например, GET, см. параграф 9.2.1 в [HTTP]).

Кэш, получивший отклик на небезопасный запрос с полем Cache-Group-Invalidation в заголовке, может аннулировать любые сохранённые отклики той же группы (параграф 2.1) для любой из указанных в списке групп.

Расширения кэша могут усиливать это требование. Например, поле заголовка управления целевым кэшем [TARGETED] может указывать, что обрабатывающие его кэши должны учитывать сигнал Cache-Group-Invalidation.

Порядок указания в списке не имеет значения. Нераспознанные параметры игнорируются.

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

Агентство IANA добавило в реестр Hypertext Transfer Protocol (HTTP) Field Name Registry приведённые ниже сведения.

   Field Name:  Cache-Groups
   Status:  permanent
   Reference:  RFC 9875

   Field Name:  Cache-Group-Invalidation
   Status:  permanent
   Reference:  RFC 9875

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

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

Совместно используемые хосты могут смягчить эти риски путём контроля доступа к описанным здесь полям заголовков.

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

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

[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «HTTP Semantics», STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[HTTP-CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «HTTP Caching», STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.

[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>.

[STRUCTURED-FIELDS] Nottingham, M. and P. Kamp, «Structured Field Values for HTTP», RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/info/rfc9651>.

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

[TARGETED] Ludin, S., Nottingham, M., and Y. Wu, «Targeted HTTP Cache Control», RFC 9213, DOI 10.17487/RFC9213, June 2022, <https://www.rfc-editor.org/info/rfc9213>.

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

Спасибо Stephen Ludin за рецензию и предложения.

Адрес автора

Mark Nottingham

Cloudflare

Melbourne

Australia

Email: mnot@mnot.net

URI: https://www.mnot.net/

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

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

nmalykh@protokols.ru

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

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

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

RFC 9620 Guidelines for Human Rights Protocol and Architecture Considerations

Опубликовано 08.09.2024 автором Nikolai Malykh

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 и публикуется для информации.

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

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

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

К документу применимы права и ограничения, указанные в 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. Общение с экспертами

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

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

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)

Опубликовано 26.07.2024 автором Nikolai Malykh

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.

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

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

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

К документу применимы права и ограничения, перечисленные в 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], требуется использовать уникальный идентификатор. В протоколах NETCONF³ [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.

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

не следует иметь имена YANG без назначенного SID;
именам 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 поделён, как показано ниже.

Значения от 0 до 999 (размер 1000) выделяются по процедуре IESG Approval, заданной в параграфе 4.10 и RFC 8126 [BCP26], при этом значение 0 зарезервировано для реализаций, указывающих отсутствие SID, и не применяется в обмене.
Значения от 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]).
Значения от 60000 до 99999 (размер 40000) зарезервированы для экспериментальных модулей YANG. Этот диапазон недопустимо использоваться в рабочих системах, поскольку SID из него не являются глобально уникальными и их функциональная совместимость ограничена. Для выделения значений применяется процедура IANA Experimental Use (параграф 4.2 в RFC 8126 [BCP26]).
Диапазон от 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>.

[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 следует автоматизировать. Рекомендуемый процесс приведён ниже.

Инструмент извлекает элементы, заданные в конкретном модуле YANG.
Элементы сортируются по алфавиту с размещением записей namespace в порядке убывания, а identifier — в порядке возрастания. Формат namespace и identifier описан в модуле YANG ietf-sid-file, заданном в разделе 4.
Значения SID выделяются последовательно от начальной точки до максимального значения в зарегистрированном диапазоне SID. Этот подход рекомендуется для минимизации издержек на сериализацию, (delta) между опорным и текущим SID используется протоколами, нацеленными на снижение размера сообщений.
Если число элементов превышает размер диапазона SID, выделенного модулю YANG, добавляется ещё один диапазон для назначения.
В элементе списка 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

Опубликовано 30.06.2024 автором Nikolai Malykh

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.

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

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

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

К документу применимы права и ограничения, перечисленные в 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.

Организация аутентифицированного защищённого соединения с распознавателем DNS.
Реализация локальной проверки 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>.

[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>.

[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

Опубликовано 30.06.2024 автором Nikolai Malykh

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.

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

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

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

К документу применимы права и ограничения, перечисленные в 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

Опубликовано 30.06.2024 автором Nikolai Malykh

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 и публикуется для информации.

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

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

1. Введение

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

Квантовый метод быстрого согласования в Византийских переговорах³ [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), таких как pBFT⁴, а также иных функций распределенного вычисления, использующих византийское согласование.

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]) без использования запутанности работают, как описано ниже.

Квантовый узел A кодирует классические биты в кубиты. Узел A генерирует две строки случайных классических битов X и Y. Строка X служит для выбора базы, Y — для выбора состояния, соответствующего выбранной базе. Например, при X=0 в случае использования протокола BB84 Алиса готовит состояние в базе {|0>, |1>}, иначе — в базе {|+>, |->}. При Y=0 Алиса готовит кубит как |0> или |+> (в зависимости от X), а при Y =1 — как |1> или |->.
Квантовый узел A передаёт кубиты квантовому узлу B по квантовому каналу.
Квантовый узел B принимает кубиты и измеряет каждый из них в одной из двух баз, выбранной случайно.
Квантовый узел B информирует квантовый узел A о своём выборе базы для каждого кубита.
Квантовый узел A сообщает квантовому узлу B, какие из случайно выбранных баз были верны.
Оба узла отбрасывают все биты измерений с отличающейся квантовой базой, а оставшиеся биты могут служить секретным ключом. Перед генерацией финального секретного ключа выполняется процедура пост-обработки через аутентифицированные классические каналы. Эта процедура может делиться на 3 этапа — оценка параметров, исправление ошибок и повышение приватности. На этапе оценки параметров Алиса и Боб используют некоторые из битов для оценки канальных ошибок. Если число ошибок превышает некий порог, протокол прерывается, иначе выполняется корректировка ошибок. Если подслушивающий попытается перехватить и прочитать кубиты, переданные от A к B, он будет обнаружен в соответствии с теоремой квантовой механики об энтропийной неопределённости. Как часть процедуры пост-обработки оба узла обычно выполняют сверку (reconciliation) информации [Elkouss] для эффективного исправления ошибок и/или проводят усиление приватности [Tang] для генерации окончательных ключей на основе теории информации.
Процедура пост-обработки должна выполняться по аутентифицированному классическому каналу. Иными словами, квантовым узлам A и B нужно убедиться в подлинности классического канала, чтобы быть уверенными в отсутствии на пути подслушивающих или атакующих. Проверка выполняется по протоколам аутентификации, иаким как [Kiktenko]. В соответствии с [Kiktenko] подлинность классического канала проверяется в самом конце процедуры пост-обработки вместо того, чтобы делать это для каждого классического сообщения передаваемого по каналу между квантовыми узлами A и B.

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

Имеются усовершенствованные протоколы QKD, основанные на [BB84]. Например, был обнаружен ряд брешей, связанных с несовершенством измерительных устройств, и имеются решения, учитывающие такие атаки, например, независимое от измерительных устройств решение QKD [Zheng2019]. Эти улучшенные протоколы QKD могут работать иначе, нежели описанные этапы протокола BB84 [BB84].
Для крупномасштабных QKD, требуются сети QKD (QKD Network или QKDN), которые можно считать частью Quantum Internet. QKDN может включать прикладной, сетевой и канальный уровень QKD [Qin]. Между квантовыми узлами A и B может находиться один или несколько ретрансляторов QKD [Zhang2018], соединённых через QKDN. Как вариант, QKDN может работать на основе распространения запутанности и основанных на запутанности протоколов QKD. В результате для крупномасштабных QKD будут требоваться квантовые повторители и/или маршрутизаторы вместо доверенных ретрансляторов QKD. Для распределения запутанности может применяться обмен запутанностью.
QKD обеспечивает основанные на теории информации общие секретные ключи для двух сторон (передатчик и приёмник) при наличии подслушивания. Однако это верно в теории, которая в значительной мере оторвана от практики. Используя несовершенство детекторов, Ева может получить сведения об общем ключе [Xu]. Для предотвращения таких атак через побочные каналы в [Lo] исследователи предложили протокол QKD, названный независимым от измерительных устройств (Measurement Device-Independent или MDI) QKD, где два пользователя (передатчик Алиса и приёмник Боб) могут безопасно взаимодействовать даже если используемое ими (измерительное) оборудование подменено (захвачено) злоумышленником и перестало быть доверенным. Это достигается путём измерения корреляция между сигналами от Алисы и Боба вместо измерения самих сигналов.
Протоколы QKD, основанные на QKD с непрерывной переменной (Continuous Variable QKD или CV-QKD), вызывают в последнее время большой интерес, поскольку для их реализации достаточно легко доступного и широко распространённого телекоммуникационного оборудования. Этот тип технологии потенциально обеспечит высокопроизводительный метод защищённого распространения ключей на ограниченных расстояниях. Недавние демонстрации CV-QKD показали совместимость с классическими схемами когерентного детектирования, которые широко применяются в классических широкополосных системах связи [Grosshans]. Отметим, что до сих пор нет квантовых повторителей для систем с непрерывными переменными, поэтому этот тип QKD пригоден лишь для коротких расстояний или сетей QKD с доверенными ретрансляторами.
Распространение секретов может применяться для распределения секретного ключа между множеством узлов, позволяя каждому узлу знать долю или часть секретного ключа, но не предоставляя всего ключа ни одному из узлов. Секретный ключ можно восстановить лишь при совместной работе достаточного числа узлов. Квантовым обменом секретами (Quantum Secret Sharing или QSS) обычно называют сценарий, где секретный ключ обобществляется на основе квантовых состояний, а не классических битов. QSS позволяет разделять (splitting) и обобществлять (sharing) такие квантовые состояния между множеством узлов.
Имеются основанные на запутанности протоколы 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. Квантовые расчёты вслепую

Квантовыми расчётами вслепую называют описанный ниже сценарий.

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

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

Как новая вычислительная модель клиент-сервер, квантовые расчёты вслепую (Blind Quantum Computation или BQC) в целом позволяет выполнить представленный ниже процесс.

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

В этом процессе сервер не может восстановить исходные кубиты из преобразованных. Прямое и обратное (для результатов) преобразование кубитов не требует от клиента значительных усилий. Один из первых протоколов BQC (например, описанный в [Childs]) следует этому процессу, но у клиента требуется наличие некоторого объёма квантовой памяти, подготовка и измерение кубитов, а также их передача. Основанные на измерениях квантовые вычисления выходят за рамки этого документа, а более подробные сведения приведены в [Jozsa2005].

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

Протокол BQC из [Childs] — это основанная на устройстве модель BQC, где клиент реализует лишь простую квантовую схему, а сервер выполняет цепочку квантовых логических операций. Кубиты передаются туда и обратно между клиентом и сервером.
Universal BQC (UBQC) из [Broadbent] — это основанная на измерениях модель BQC, где выполняются квантовые измерения с использованием запутанных состояний. Принцип UBQC основан на том, что квантовая трансформация плюс измерение Белла с поворотом (базы) реализуют квантовые вычисления, которые могут повторяться для реализации расчётной цепочки. В этом случае клиент сначала готовит преобразованные кубиты, затем передаёт их серверу, а тому нужно сначала подготовить запутанные состояния из всех принятых кубитов. Далее между клиентом и сервером выполняется множество раундов взаимодействия и измерения:
1. клиент передаёт серверу новые инструкции по измерению или его адаптации;
2. сервер выполняет измерения в соответствии с полученными инструкциями для получения результатов (в кубитах или классических битах);
3. клиент получает результаты измерения и преобразует их в окончательные результаты.
В [Zhang2009] предложен гибридный вариант UBQC, где сервер реализует квантовые устройства (схемы), подобно показанным в [Childs], и квантовые измерения, похожие на показанные в [Broadbent], для снижения числа требуемых запутанных состояний [Broadbent]. Клиент в этом случае много проще, нежели в [Childs]. Этот гибридный вариант BQC является сочетанием моделей BQC на основе схемы и измерений.
В идеальном случае клиент BQC является чисто классическим и ему требуется лишь взаимодействие с сервером по классическим каналам. В [Huang] продемонстрирован такой подход, где клиент использует два запутанных сервера для выполнения BQC в предположении невозможности взаимодействия между этими серверами (в противном случае расчёты вслепую и приватность клиента не гарантируются). Продемонстрированный в [Huang] сценарий, по сути, является примером BQC с несколькими серверами.
Проверка соответствия выполненного сервером запросам и ожиданиям клиента важна для многих протоколов BQC, называемых верифицируемыми. В [Fitzsimons] обсуждается этот вопрос и сравниваются протоколы BQC.

На рисунке 2 Quantum Internet включает квантовые каналы и квантовые повторители и/или квантовые маршрутизаторы для передачи кубитов на большие расстояния [RFC9340].

+----------------+     /--------\     +-------------------+
|                |--->( Quantum  )--->|                   |
|  Терминальный  |    ( Internet )    | Удалённый узел    |
|  узел          |     \--------/     | квантовых расчётов|
|  (например     |                    | (например,        |
|  небольшой     |     /--------\     | удалённый         |
|  квантовый     |    ( Classical)    | квантовый         |
|  компьютер     |<-->( Internet )<-->| мэйнфрейм)        |
+----------------+     \--------/     +-------------------+

Рисунок . Квантовые расчёты вслепую.

4.3. Распределённые квантовые расчёты

Существует два способа распределенных квантовых расчётов [Denchev].

Использование квантовой механики для улучшений классических распределенных расчётов. Например, можно использовать запутанные квантовые состояния для улучшения выбора лидера в классических распределенных расчётах путём простого измерения запутанных квантовых состояний на каждой стороне (например, на узле или устройстве) без каких-либо классических коммуникаций между разнесёнными сторонами [Pal]. Обычно сначала нужно организовать между сторонами предварительную запутанность, а затем выполнить операции LOCC на каждой стороне. При этом обычно не нужно передавать кубиты между сторонами.
Распределение функций квантовых вычислений между разнесёнными квантовыми компьютерами. Задача или функция квантовых расчётов (например, квантовые вентили) расщепляется и распределяется между множеством физически разделённых квантовых компьютеров. При этом может потребоваться передача кубитов (входных или выходных) между этими распределенными компьютерами. Для поддержки таких распределенных задач требуются и фактически применяются запутанные состояния.
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] для выполнения квантовой телепортации.

Квантовый компьютер A генерирует некие кубиты конфиденциальных данных для телепортирования в B.
Организуется общая запутанность A и B (т. е. имеется два запутанных кубита — q1 на A и q2 на B). Например, квантовый компьютер A может создать два запутанных кубита (q1 и q2) и передать q2 квантовому компьютеру B, используя квантовую связь.
Компьютер A выполняет измерение Белла для запутанного кубита q1 и кубита конфиденциальных данных.
Результат измерения Белла кодируется в 2 классических бита, которые передаются по классическому каналу квантовому компьютеру B.
На основе полученных 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).
Сети с подготовкой и измерением (Этап 2).
Сети распределения запутанности (Этап 3).
Сети квантовой памяти (Этап 4).
Устойчивые к отказам сети из нескольких кубитов (Этап 5).
Сети квантовых вычислений (Этап 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 | Оставить комментарий