RFC 8307 Well-Known URIs for the WebSocket Protocol

Internet Engineering Task Force (IETF)                        C. Bormann
Request for Comments: 8307                       Universitaet Bremen TZI
Updates: 6455                                               January 2018
Category: Standards Track
ISSN: 2070-1721

Общеизвестные URI для протокола WebSocket

Well-Known URIs for the WebSocket Protocol

PDF

Тезисы

В RFC 5785 определен префикс пути /.well-known/, который может использоваться общеизвестными идентификаторами URI. Префикс был определен для URI-схем http и https. Данный документ формально обновляет RFC 6455, где определены схемы URI для протокола WebSocket, с целью расширения использования этих общеизвестных URI на соответствующие схемы URI.

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

Этот документ является проектом стандарта (Internet Standards Track).

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

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

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

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

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

Оглавление

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

1. Введение

[RFC5785] определяет префикс пути /.well-known, который может применяться в общеизвестных URI. Там же задан реестр IANA для суффиксов URI, которые будут применяться с этим префиксом пути для создания общеизвестных URI.

В [RFC5785] этот механизм определен конкретно для схем http и https (не определены в [RFC7230]). С тех пор этот механизм начали применять и другие схемы типа coap и coaps [RFC7252], используя реестр суффиксов URI, определенных для HTTP(S).

[RFC6455], в котором определены схемы URI для протокола WebSocket (ws и wss), не задает применения общеизвестных URI для этих схем URI.

Настоящий документ формально обновляет [RFC6455], добавляя использование общеизвестных URI [RFC5785] для схем ws и wss.

Общеизвестные URI для ws и wss используют реестр суффиксов URI, созданный [RFC5785], не требуя от IANA внесения изменений в этот реестр.

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

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

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

Раздел «Вопросы безопасности» [RFC5785] применим и должен приниматься во внимание для общеизвестных URI.

Всегда имеется возможность создать ws и wss URI так, что они юудут отображаться на общеизвестные HTTP(S) URI при использовании процедуры из раздела 4 [RFC6455]. Формальное определение механизма общеизвестных URI для схем ws и wss не меняет состояния безопасности.

Однако доступность общеизвестных URI для протокола WebSocket требует от приложений, которые хотят определить общеизвестные суффиксы URI конкретно для WebSocket, учитывать не будут ли ресурсы, которые становятся доступными через эквивалентные HTTP(S) URI, формируемые в соответствии с разделом 4 [RFC6455] приводить к раскрытию информации или иным проблемам безопасности.

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

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

[RFC5785] Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs)”, RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.

[RFC6455] Fette, I. and A. Melnikov, “The WebSocket Protocol”, RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.

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

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, “The Constrained Application Protocol (CoAP)”, RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

Адрес автора

Carsten Bormann

Universitaet Bremen TZI

Postfach 330440

Bremen D-28359

Germany

Phone: +49-421-218-63921

Email: cabo@tzi.org


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

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

Семантика SMTP local-part на почтовых серверах Google

С некоторых пор на мой адрес в домене google.com стал сыпаться адресованный некому Александру  спам, связанный с получением “быстрых кредитов”. Поскольку я Александром никогда себя не называл и традиционно пользуюсь данным родителями именем, решил копнуть поглубже и посмотреть заголовки, благо интерфейс позволяет сделать это. И что же я увидел?

Тут самое время сказать ¨Wow¨ – в заголовке локальная часть адреса совсем не моя, хоть и похожа несказанно.

И разница совсем не велика – всего лишь отсутствующая в моем адресе точечка после буквы n. Не правда ли, мелочь совсем не значимая. Однако с точки зрения программ (серверов) строки символов nmalykh и n.malykh совершенно не совпадают и даже длиной различаются. В RFC 5321 сказано:

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

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

Любопытная трактовка, не правда ли?

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

RFC 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests

Internet Engineering Task Force (IETF)                       M. Reynolds
Request for Comments: 8209                                          IPSw
Updates: 6487                                                  S. Turner
Category: Standards Track                                          sn3rd
ISSN: 2070-1721                                                  S. Kent
                                                                     BBN
                                                          September 2017

Профиль для сертификатов маршрутизаторов BGPsec, списков отзыва и запросов сертификатов

A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests

PDF

Тезисы

Этот документ определяет стандартный профиль для сертификатов X.509, используемых для обеспечения возможности проверки путей AS1 в протоколе BGP2, с помощью расширения, названного BGPsec. BGP является стандартным протоколом междоменной маршрутизации в Internet, собирая, по сути дела, Internet в единое целое. Расширение BGPsec было разработано, как одна из компонент решения по обеспечению защиты BGP. Целью BGPsec является обеспечение полной проверки пути AS на основе использования строгих криптографических примитивов. Сертификаты конечных элементов (EE3), задаваемые этим профилем, выпускаются для маршрутизаторов внутри AS. Каждый из таких сертификатов выпускается с сертификатом удостоверяющего центра (УЦ или CA4) инфраструктуры открытых ключей ресурсов (RPKI5). Сертификаты УЦ и EE содержат расширение AS Resource. Сертификат EE этого типа подтверждает, что маршрутизатор или маршрутизаторы, владеющие соответствующим секретным ключом (private key), уполномочены выпускать защищенные анонсы маршрутов от имени AS, указанных в сертификате. В этом документе описан также профиль формата запросов сертификата и заданы процедуры проверки пути сертификации трансляторов (RP6) для этих сертификатов EE. Данный документ расширяет RPKI и, следовательно, служит обновлением профиля RPKI Resource Certificates Profile (RFC 6487).

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

Этот документ является проектом стандарта (Internet Standards Track).

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

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

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

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

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

Оглавление

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

1. Введение

Этот документ определяет профиль для сертификатов X.509 конечных элементов (EE) [RFC5280] с целью использования в контексте сертификации путей AS в протоколе BGPsec. Эти сертификаты получили название BGPsec Router Certificate (сертификат маршрутизатора BGPsec). Держатель секретного ключа, связанного с BGPsec Router Certificate, уполномочен передавать защищенные анонсы маршрутов (BGPsec UPDATE) от имени автономных систем, указанных в сертификате. Маршрутизатор, владеющий секретным ключом, уполномочен передавать (своим партнерам) защищенные анонсы маршрутов, указывающие номер автономной системы маршрутизатора (ASN9) в качестве источника анонсов. Обеспечиваемые BGPsec свойства (владение ключом) позволяют каждой AS на пути AS убедиться в том, что другие AS на этом пути уполномочены анонсировать данный маршрут (в следующую AS на пути AS).

Этот документ основан на [RFC6487], а тот, в свою очередь, – на [RFC5280]. Документ служит обновлением для [RFC6487]. Он устанавливает требования, предъявляемые к Resource Certificate, используемому в качестве BGPsec Router Certificate, т. е. задает ограничения для полей сертификата и расширения, приемлемые в этом контексте. Документ также описывает запросы, используемые для приобретения BGPsec Router Certificate. Кроме того, документ задает для этих сертификатов процедуру проверки пути сертификации Relying Party (RP).

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

Предполагается знакомство читателя с терминами и концепциями, описанными в A Profile for X.509 PKIX Resource Certificates [RFC6487], BGPsec Protocol Specification [RFC8205], A Border Gateway Protocol 4 (BGP-4) [RFC4271], BGP Security Vulnerabilities Analysis [RFC4272], Considerations in Validating the Path in BGP [RFC5123] и Capabilities Advertisement with BGP-4 [RFC5492].

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

2. Описание ресурсов в сертификатах

+---------+   +------+
| CA Cert |---| IANA |
+---------+   +------+
         \
      +---------+   +-----+
      | CA Cert |---| RIR |
      +---------+   +-----+
              \
             +---------+   +-----+
             | CA Cert |---| ISP |
             +---------+   +-----+
              / |            | |
   +-----+   /  |            | |   +-----+
   | CRL |--+   |            | +---| ROA |
   +-----+      |            |     +-----+
                |            |   +----------+
       +----+   |            +---| Manifest |
     +-| EE |---+                +----------+
     | +----+
     +-----+

Рисунок 1


На рисунке 1 показаны некоторые элементы инфраструктуры открытых ключей ресурсов (RPKI), а также некоторые объекты, генерируемые RPKI элементами. Агентство IANA выпускает сертификат удостоверяющего центра (CA) для каждого регионального регистратора RIR10. В свою очередь RIR выпускает сертификаты CA для провайдеров (ISP11). ISP выпускают сертификаты EE для себя, чтобы обеспечить возможность проверки подписей объектов RPKI. CA также создают списки отзыва сертификатов (CRL12). Эти сертификаты CA и EE называют сертификатами ресурсов, для них используются профили [RFC6487]. [RFC6480] предусматривает использование сертификатов ресурсов для обеспечения проверки манифестов [RFC6486] и полномочий источника маршрута (ROA13) [RFC6482]. ROA и манифесты включают сертификаты ресурсов, используемые для их проверки.

В этот документе определяется другой тип сертификата ресурса, названный сертификатом маршрутизатора BGPsec. Цель введения этих сертификатов описана в разделе 1 и попадает в область действия, определенную в [RFC6484]. Введение сертификатов BGPsec Router оказывает минимальное влияние на RPKI CA, поскольку профильсертификатов RPKI CA и CRL не изменяется (т. е. соответствует заданному в [RFC6487]). Кроме того, алгоритмы, используемые для генерации сертификатов RPKI CA, которые служат для эмиссии сертификатов BGPsec Router и CRL, которые требуются для проверки пригодности сертификатов BGPsec Router, остаются неизменными (т. е. соответствуют спецификации [RFC7935]). Единственное влияние заключается в том, что от RPKI CA требуется возможность обработки профилированных запросов сертификатов (см. параграф 3.2), подписанных с использованием алгоритмов [RFC8208]. Сертификаты BGPsec Router используются лишь для проверки подписи в запросе сертификата BGPsec (их обрабатывают только CA) и подписи в сообщениях BGPsec UPDATE [RFC8205] (их обрабатывают только маршрутизаторы BGPsec). Сертификаты BGPsec Router не применяются для обработки манифестов и ROA, а также для проверки подписей в сертификатах и CRL.

В этом документе перечислены лишь различия между данным профилем и [RFC6487]. Отметим, что сертификаты BGPsec Router являются сертификатами EE и поэтому не влияют на процедуру смены алгоритма, описанную в [RFC6916].

3. Обновления RFC 6487

3.1. Поля сертификата BGPsec Router

Сертификат BGPsec Router согласуется с профилем [RFC6487] с учетом изменений, приведенных в этом разделе. Таким образом, это приемлемый сертификат открытого ключа X.509, соответствующий профилю PKIX [RFC5280]. Различия между этим профилем и профилем [RFC6487] указаны в этом разделе.

3.1.1. Subject

Поддерживаемыми вариантами представления общего имени (common name) являются printableString и UTF8String. Для сертификатов BGPsec Router рекомендуется в качестве общего имени применять строку «ROUTER-», за которой следует 32-битовое значение ASN [RFC3779], представленное восемью 16-ричными цифрами, а в качестве атрибута порядкового номера — 32-битовое значение BGP Identifier [RFC4271] (т. е. ID) в форме восьми 16-ричных цифр. Если имеется не один номер ASN, выбор включаемого в общее имя значения отдается на откуп эмитенту (Issuer). Если один и тот же сертификат выпускается для множества маршрутизаторов (и, следовательно, все эти маршрутизаторы используют общий секретный ключ), выбор значения ID, используемого в общем имени также определяет эмитент.

3.1.2. Subject Public Key Info

См. параграф 3.1 в [RFC8208].

3.1.3. Поля расширений BGPsec Router Certificate версии 3

3.1.3.1. Базовые ограничения

Узлы BGPsec являются конечными элементами (EE), следовательно, расширение Basic Constraints присутствовать не должно, как указано в [RFC6487].

3.1.3.2. Расширение EKU

Сертификаты BGPsec Router должны включать расширение EKU14. Как указано в [RFC6487], это расширение не должно обозначаться критическим. Данный документ определяет одно расширение EKU для сертификатов BGPsec Router.

     id-kp OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) kp(3) }

     id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }

Маршрутизатор BGPsec должен требовать наличия расширения EKU в полученном сертификате BGPsec Router. При наличии множества значений KeyPurposeId маршрутизатору BGPsec не требуется распознавать все эти значения, если присутствует требуемое значение KeyPurposeId. Маршрутизаторы BGPsec должны отвергать сертификаты без расширения BGPsec Router EKU даже при наличии в них anyExtendedKeyUsage OID, определенного в [RFC5280].

3.1.3.3. Subject Information Access

Это расширение не применяется в сертификатах BGPsec Router и должно быть опущено.

3.1.3.4. IP Resources

Это расширение не применяется в сертификатах BGPsec Router и должно быть опущено.

3.1.3.5. AS Resources

Кажый сертификат BGPsec Router должен включать расширение AS Resources в соответствии с параграфом 4.8.11 [RFC6487]. Расширение AS Resources должно включать один или множество номеров ASN, а задание «наследуемых» элементов недопустимо.

3.2. Профиль запроса сертификата BGPsec Router

Соответствует разделу 6 в [RFC6487]. Различия между данным профилем и [RFC6487] перечислены ниже.

  • Расширение Basic Constraints.

    При наличии этого расширения CA недопустимо принимать во внимание установленное значение cA = TRUE.

  • Расширение EKU.

    При наличии этого расширения должно присутствовать id-kp-bgpsec-router (см. параграф 3.1.3.2), а CA должен выполнять запрос для id-kp-bgpsec-router.

  • Расширение SIA15.

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

  • Поле SubjectPublicKeyInfo задано в [RFC8208].

  • Запрос подписывается по алгоритму, заданному в [RFC8208].

3.3. Проверка пригодности сертификата BGPsec Router

Проверка пригодности сертификатов BGPsec Router идентичная процедуре валидации, описанной в разделе 7 [RFC6487] (и всех RFC, обновляющих эту процедуру), с перечисленными ниже изменениями. Например, на этапе 3 (критерий, указанный в параграфе 7.2 [RFC6487]) слова «сертификат содержит все поля, которые должны присутствовать» отностся к полям, требуемым этой спецификацией.

Ниже перечислены различия:

  • сертификаты BGPsec Router должны включать расширение BGPsec Router EKU, определенное в параграфе 3.1.3.2;

  • в сертификаты BGPsec Router недопустимо включать расширение SIA;

  • в сертификаты BGPsec Router недопустимо включать расширение IP Resources;

  • сертификаты BGPsec Router должны включать расширение AS Resources;

  • сертификаты BGPsec Router должны включать поле subjectPublicKeyInfo, описанное в [RFC8208].

Примечание. BGPsec RP будут требоваться для поддержки алгоритмов [RFC8208], которые используются для проверки пригодности подписей BGPsec, а также алгоритмов [RFC7935], которые требуются для проверки пригодности подписей сертификатов BGPsec, сертификатов RPKI CA и списков отзыва RPKI CRL.

3.4. Сертификаты маршрутизаторов и функции подписи в RPKI

Как указано в разделе 1, основное применение сертификатов BGPsec Router в RPKI происходит в контексте сертификации путей AS в протоколе BGPsec.

Секретный ключ, связанные с сертификатом EE маршрутизатора, может использоваться многократно для генерации подписей во множестве экземпляров Signature Segment атрибута BGPsec_PATH [RFC8205]. Т. е. сертификат BGPsec Router используется для проверки пригодности множества подписей.

Сертификаты BGPsec Router сохраняются в репозитории CA-эмитента и репозитории, соответствующие [RFC6481], должны использовать для сертификатов файлы с расширением имени .cer.

4. Замечания по устройству

Профиль сертификатов BGPsec Router основан на профиле Resource Certificate, определенном в [RFC6487]. В результате многие из описанных здесь вариантов выбора являются отражением выбора, сделанного в предшествующей работе. Для более полного понимания вариантов выбора читателю рекомендуется обратиться к [RFC6484].

Удостоверяющие центры CA требуются политикой сертификации (CP16) [RFC6484] для выпуска подобающим образом сформированных сертификатов BGPsec Router независимо от того, что присутствует в запросе сертификата, обеспечивая этим запросам некоторую гибкость.

  • Сертификаты BGPsec Router всегда являются сертификатами EE, следовательно, запрос на выпуск сертификата CA приводит к выпуску сертификата EE;

  • Сертификаты BGPsec Router всегда являются сертификатами EE, следовательно, запрос для расширения Key Usage значений keyCertSign и cRLSign будет выдавать сертификаты без обоих значений;

  • Сертификаты BGPsec Router всегда включают значение BGPsec Router EKU, следовательно, запросы без этого значения будут возвращать сертификаты со значением;

  • Сертификаты BGPsec Router никогда не включают расширение SIA, следовательно, запросы сертификата с таким расширением будут возвращать сертификаты без расширения.

Отметим, что такое поведение аналогично включению удостоверяющим центром CA расширения AS Resources в выпускаемые сертификаты BGPsec Router, несмотря на то, что это расширение не указано в запросах.

5. Вопросы реализации

Этот документ разрешает оператору включать список ASN в сертификат BGPsec Router. В данном случае сертификат маршрутизатора станет неприемлемым если любой из номеров ASN удаляется из сертификата любого «вышестоящего» (superior) CA на пути к доверенной привязке. Операторы могут предотвратить такую возможность, выпуская свой сертификат BGPsec Router для каждого отличающегося номера ASN так, что сертификаты маршрутизаторов для ASN, сохранившихся в вышестоящем CA, будут сохраняться действующими.

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

Для данного документа применимы вопросы безопасности, рассмотренные в [RFC6487].

Сертификат BGPsec Router не пройдет проверку пригодности RPKI, определенную в [RFC6487] по причине использования разных криптографических алгоритмов. Следовательно, RP требуется идентифицировать EKU для определения подходящего ограничения Validation.

Сертификат BGPsec Router является расширением RPKI [RFC6480] для работы с маршрутизаторами. Он является основой построения BGPsec и применяется для проверки пригодности подписей происхождения BGPsec Signature Segment в подписанных сегментах пути [RFC8205]. Таким образом, его важной защитной функцией является защищенная привязка одного или множества номеров ASN к открытому ключу, согласованная с иерархией выделения/присваивания RPKI.

Функции хэширования [RFC8208] применяются при генерации двух расширений идентификаторов ключей (т. е. Subject Key Identifier и Issuer Key Identifier), включаемых в сертификаты BGPsec. Однако, как отмечено в [RFC6818], устойчивость к коллизиям не является требуемым свойством односторонних хэш-функций при их использовании для генерации идентификаторов ключей. Несмотря на то, что коллизии возникают редко, они остаются возможными и оператора следует предупреждать о возникновении такого конфликта. Коллизия значений Subject Key Identifier может приводить к выбору из кэша неподходящего сертификата и последующему отказу при проверке подписи.

7. Согласование с IANA

Этот документ использует два значения OID из реестра SMI для PKIX. Одно значение служит для модуля ASN.1 [X680] [X690] в Приложении A и берется из реестра IANA «SMI Security for PKIX Module Identifier» (id-mod-bgpsec-eku). Другое применяется для BGPsec Router EKU, определенного в параграфе 3.1.3.2 и Приложении A и берется из реестра IANA «SMI Security for PKIX Extended Key Purpose» (id-kp-bgpsec-router). Эти значения OID были выделены до того, как управление PKIX Arc было передано IANA. Ссылки в этих реестрах были обновлены в соответствии с данным документом.

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

[RFC3779] Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers”, RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.

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

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

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, “A Profile for Resource Certificate Repository Structure”, RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, “Manifests for the Resource Public Key Infrastructure (RPKI)”, RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, “A Profile for X.509 PKIX Resource Certificates”, RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC7935] Huston, G. and G. Michaelson, Ed., “The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure”, RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.

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

[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., “BGPsec Protocol Specification”, RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC8208] Turner, S. and O. Borchert, “BGP Algorithms, Key Formats, and Signature Formats”, RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.

[X680] ITU-T, “Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation”, ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.

[X690] 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, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.

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

[RFC4272] Murphy, S., “BGP Security Vulnerabilities Analysis”, RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.

[RFC5123] White, R. and B. Akyol, “Considerations in Validating the Path in BGP”, RFC 5123, DOI 10.17487/RFC5123, February 2008, <https://www.rfc-editor.org/info/rfc5123>.

[RFC5492] Scudder, J. and R. Chandra, “Capabilities Advertisement with BGP-4”, RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.

[RFC6480] Lepinski, M. and S. Kent, “An Infrastructure to Support Secure Internet Routing”, RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, “A Profile for Route Origin Authorizations (ROAs)”, RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, “Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)”, BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.

[RFC6818] Yee, P., “Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 6818, DOI 10.17487/RFC6818, January 2013, <https://www.rfc-editor.org/info/rfc6818>.

[RFC6916] Gagliano, R., Kent, S., and S. Turner, “Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)”, BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.

Приложение A. Модуль ASN.1

   BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) }

     DEFINITIONS EXPLICIT TAGS ::=
     BEGIN
     -- EXPORTS ALL --
     -- IMPORTS NOTHING --
     -- OID Arc --
     id-kp  OBJECT IDENTIFIER  ::= {
       iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) kp(3) }
     -- BGPsec Router Extended Key Usage --
     id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
     END

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

Авторы выражают свою признательность Geoff Huston, George Michaelson и Robert Loomans за их работу над [RFC6487], послужившим базой. Кроме того, в подготовке этой работы важную роль сыграли усилия Matt Lepinski. Спасибо также Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra Murphy и Sam Weiler за их рецензии и комментарии.

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

Mark Reynolds

Island Peak Software

328 Virginia Road

Concord, MA 01742

United States of America

Email: mcr@islandpeaksoftware.com

Sean Turner

sn3rd

Email: sean@sn3rd.com

Stephen Kent

Raytheon BBN Technologies

10 Moulton St.

Cambridge, MA 02138

United States of America

Email: kent@alum.mit.edu


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

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

nmalykh@gmail.com

1Autonomous System — автономная система.

2Border Gateway Protocol — протокол граничного шлюза.

3End entity.

4Certification Authority — орган сертификации.

5Resource Public Key Infrastructure.

6Relying Party — зависимая сторона.

7Internet Engineering Task Force.

8Internet Engineering Steering Group.

9AS number.

10Regional Internet Registry.

11Internet Service Provider.

12Certificate Revocation List.

13Route Origin Authorization.

14Extended Key Usage — расширенное использование ключа

15Subject Information Access — доступ к информации субъекта.

16Certificate Policy.

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

RFC 8238 Data Center Benchmarking Terminology

Internet Engineering Task Force (IETF)                        L. Avramov
Request for Comments: 8238                                        Google
Category: Informational                                          J. Rapp
ISSN: 2070-1721                                                   VMware
                                                             August 2017

Терминология для оценки работы ЦОД

Data Center Benchmarking Terminology

PDF

Тезисы

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

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

Документ не является спецификацией стандарта (Internet Standards Track) и публикуется с информационными целями.

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

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

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

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

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

Оглавление

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

1. Введение

Картина трафика в ЦОД неоднородна и постоянно меняется. Это обусловлено характером и разнообразием применяемых в ЦОД приложений. Это могут быть большие потоки «запад-восток» («горизонтальные» потоки между серверами одного ЦОД) в одном центре и большие потоки «север-юг» («вертикальные» потоки из внешнего источника к серверу ЦОД) в другом, а также разные комбинации направлений потоков. Картины трафика по своей природе содержат пики (всплески) и включают потоки «многие к одному» «многие ко многим», «один ко многим». Потоки могут быть небольшими и чувствительными к задержками или большими и чувствительными к пропускной способности, а также включать смесь трафика UDP и TCP. Все перечисленное может существовать в одном кластере и поток может проходить через одно сетевое устройство. Тесты производительности сетевых устройств используются достаточно давно и описаны в [RFC1242], [RFC2432], [RFC2544], [RFC2889] и [RFC3918]. Эти тесты в основном привязаны к параметрам задержки и максимальной пропускной способности тестируемого устройства (DUT3). Эти стандарты хороши для измерения теоретической максимальной пропускной способности, скорости пересылки и задержки в условиях теста, но не соответствуют реальным картинам трафика, который может проходить через сетевые устройства. Сетевые устройства ЦОД включают маршрутизаторы и коммутаторы.

Ниже перечислены основные характеристики типичных сетевых устройств.

  • Высокая плотность портов(не менее 48).

  • Высокая скорость (вплоть до 100 Гбит/с на порт).

  • Высокая пропускная способность (суммарная линейная скорость всех портов для уровня 2 и/или 3).

  • Малые задержки (микросекунды или наносекунды).

  • Незначительный объем буферов (мегабайты в объеме всего устройства).

  • Пересылка на уровнях 2 и 3 (уровень 3 не обязателен).

В этом документе приведены определения, метрические параметры и новая терминология, включая случаи перегрузки и анализа буферов в коммутаторах, а также заново определены некоторые базовые компоненты с учетом широкого спектра картин трафика. Методология тестирования определена в [RFC8239].

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

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

1.2. Формат определений

  • Определяемый термин (например, задержка).

  • Определение — конкретное определение термина

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

  • Единицы измерения — методология измерения и единицы, используемые для значения, если это применимо.

2. Задержка

2.1. Определение

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

Интервал задержки можно оценивать между разными комбинациями событий, независимо от типа коммуникационного устройства (побитовая или сквозная пересылка — cut-through или с промежуточной буферизацией – store-and-forward). В [RFC1242] задержка определяется по разному для каждого типа устройств.

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

  • FILO (First In Last Out — первый вошел – последний вышел)

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

  • FIFO (First In First Out — первый вошел – первый вышел)

    Временной интервал начинается при поступлении во входной порт конца первого бита входящего кадра и заканчивается в тот момент, когда начало первого бита выходного кадра становится видно на выходном порту. Этот вариант применяется для определенной в [RFC1242]) задержки устройств с побитовой пересылкой.

  • LILO (Last In Last Out — последний вошел – последний вышел)

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

  • LIFO (Last In First Out — последний вошел – первый вышел)

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

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

  • FILO это FL (первый бит — последний бит).

  • FIFO это FF (первый бит — первый бит).

  • LILO это LL (последний бит — последний бит).

  • LIFO это LF (последний бит — первый бит).

Это определение в контексте оценки производительности коммутаторов ЦОД используется взамен определения «задержки», приведенного в параграфе 3.8 RFC 1242 и процитированного ниже.

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

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

Для обеспечения соответствия обоим типам сетевых устройств и двум вновь возникшим гибридным типам измерение задержки в коммутаторах в соответствии с данным документом должно основываться на событиях FILO. Этот вариант будет включать задержку в коммутаторе, а также задержку на преобразование кадра в последовательную форму (serialization delay). Это представляет «полную» задержку при прохождении через DUT. Для чувствительных к задержке приложений, которые могут работать, начиная с первых битов кадра, можно использовать события FIFO (для определение RFC 1242 для задержки в устройствах с промежуточной буферизацией). В любом случае комбинация событий, используемая для определения задержки должна указываться в отчете.

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

Как было отмечено в параграфе 2.1, FILO является наиболее значимым определением для процесса измерения.

Не все устройства DUT относятся к «чистым» типам cut-through или store-and-forward. В ЦОД используются DUT, которые часто используют промежуточную буферизацию для мелких пакетов и сквозную пересылку пакетов крупнее некого заданного размера. Размер пакета, при котором поведение изменяется, может быть настраиваемым (это зависит от производителя DUT). Определение FILO подходит как для сквозной коммутации, так и для случая промежуточной буферизации. Порог смены типа поведения не оказывает влияния на оценку работы, поскольку FILO подходит для обоих вариантов.

Механизм LIFO подходит для коммутаторов store-and-forward, но не работает при сквозной коммутации, поскольку в этом случае он будет показывать отрицательную задержку для больших пакетов за счет того, что не учитывается преобразование в последовательный формат (serialization delay). Следовательно, этот механизм недопустимо использовать при сравнении задержки разных DUT.

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

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

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

  2. FIFO может использоваться для некоторых приложений, способных обрабатывать данные с момента поступления первого бита — например, FPGA (Field-Programmable Gate Array).

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

3. Вариации задержки (Jitter)

3.1. Определение

В контексте ЦОД термин jitter является синонимом термина delay variation (вариации задержки). Они определяются путем многократного измерения задержки в одном направлении, как описано в RFC 3393. Обязательным для использования определением delay variation является PDV4, определенная в параграфе 4.2 [RFC5481]. При рассмотрении потока пакетов задержки все пакетов задержки всех пакетов вычитаются из минимальной задержки всех пакетов в потоке. Это упрощает оценку диапазона вариаций задержки (Max – Min) или высокого процентиля PDV (99-й для устойчивости к постороннему трафику).

При использовании для измерения задержки временных меток First-bit – Last-bit, вариации задержки должны измеряться с применением пакетов или кадров одинакового размера, поскольку определение задержки включает время преобразования каждого пакета в последовательный формат (serialization time). В остальных случаях, если используется First-bit – First-bit, ограничений на размер не накладывается.

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

В дополнение к диапазону PDV и/или высокому процентилю PDV могут использоваться межпакетные вариации задержки (IPDV5), определенные в параграфе 4.1 [RFC5481] (разность между двумя последовательными пакетами) для целей определения вариаций межпакетных интервалов (например, является поток пакетов сравнительно однородным или в нем возникают пики). Однако не следует использовать абсолютные значения IPDV, поскольку в них «сколлапсированы» пиковые и распределенные варианты потока.

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

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

4. Калибровка на физическом уровне

4.1. Определение

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

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

  • Тип устройства, используемого для генерации/измерения трафика.

  • Тип линейных карт, используемых в генераторе трафика.

  • Тип трансиверов в генераторе трафика.

  • Тип трансиверов в DUT.

  • Типы кабелей.

  • Длины кабелей.

  • Название и номер версии программ генерации трафика и DUT.

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

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

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

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

Рекомендуется применять для тестирования кабели (1) одного типа и длины, (2) произведенные (по возможности) одной компанией. Указанные в параграфе 4.1 параметры кабелей должны включаться в отчет вместе с результатами. В отчете необходимо указать, вычитались ли задержки в кабелях из приведенных в отчете значений. Должна указываться точность измерений генератора трафика (для современного тестового оборудования обычно около 20 нсек).

5. Скорость в линии

5.1. Определение

Синхронизация передачи или максимальная скорость передачи управляется «часами передачи» (transmit clock) в DUT. Синхронизация приема (максимальная скорость на входе) определяется синхронизацией передачи подключенного интерфейса.

Скорость в линии или скорость передачи кадров на физическом уровне — это максимальная «емкость» передачи в линию кадров заданного размера с частотой синхронизации передачи устройства DUT.

Термин «номинальная скорость в линии» (nominal value of line rate) определяет максимальную скорость передачи для данного порта — например, 1 GE, 10 GE, 40 GE, 100 GE (в Гбит/с – GE8).

Частота (скорость часов – clock rate) синхронизации передачи в любой паре соединенных интерфейсов никогда не будет в точности совпадать, следовательно требуется некий допуск. Этот допуск выражается значением PPM9. Стандарты IEEE опускают определенные отклонения частоты синхронизации передачи и сети Ethernet рассчитаны на наличие незначительных расхождений между часами соединенных интерфейсов. Это приводит к некоторым допускам линейной скорости трафика, генерируемого тестовым оборудованием для DUT.

Скорость в линии следует измерять числом кадров в секунду (FPS10).

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

Для синхронизации передачи большинство коммутаторов Ethernet использует «модуль часов» (clock module), называемый также «модулем синхронизации» (oscillator module), который представляет собой герметичный блок с внутренней температурной стабилизацией и обеспечивает очень высокую точность. Выходная частота такого модуля не настраивается, поскольку в этом нет необходимости. Однако в тестовом оборудовании зачастую имеется программная подстройка скорости передачи. Такую юстировку следует применять для «компенсации» скорости тестового оборудования, чтобы не передавать устройству DUT данные со скоростью, превышающей скорость линии.

Для допуска незначительных отклонений в скорости коммерчески доступных модулей синхронизации и других кварцевых генераторов стандарты Ethernet задают максимальные отклонения частоты синхронизации ±100 PPM от расчетного значения частоты. Следовательно, устройства DUT должны быть способны воспринимать кадры с отклонениями скорости ±100 PPM в соответствии со стандартами.

Очень мало устройств обеспечивает идеальную точность ±0,0 PPM в силу перечисленных ниже обстоятельств.

  1. Стандарты Ethernet разрешают отклонение частоты не более ±100 PPM с течением времени. Следовательно, для опорных генераторов будет нормальным незначительное изменение частоты с течением времени и при изменении температуры, а также в результате воздействия других факторов.

  2. Кристаллы кварца или модули часов обычно характеризуются некоторым отклонением, которое существенно меньше ±100 PPM. Зачастую эти вариации составляют не более ±30 PPM, чтобы устройство считалось «измерительным средством» (certification instrument).

При тестировании пропускной способности коммутаторов Ethernet на «скорости линии» любой конкретный коммутатор будет вносить свои вариации опорной частоты. Если тест выполняется с частотой +1 PPM по сравнению с частотой тестируемого коммутатора и тест происходит с установившейся скоростью линии, можно наблюдать постепенный рост задержки и, возможно, отбрасывание пакетов при переполнении буферов в коммутаторе. В зависимости от разницы вариаций частоты в двух соединенных устройствах можно заметить по истечении нескольких сотен микросекунд, нескольких миллисекунд или секунд с начала передачи трафика. Малую задержку и отсутствие потери пакетов можно продемонстрировать, установив для теста скорость чуть меньше чем при 100%-ой загрузке линии. Обычно загрузка в 99 % процентов показывает малую задержку и отсутствие потери пакетов. Ни в одном коммутаторе или маршрутизаторе Ethernet вы не увидите опорного генератора с отклонением опорной частоты в точности ±0,0 PPM. Очень мало (если есть) тестового оборудование обеспечивает точность ±0,0 PPM.

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

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

«Скорость линии» (Line rate) измеряется числом кадров в единицу времени (frame rate):

   Frame Rate = Transmit-Clock-Frequency /
      (Frame-Length*8 + Minimum_Gap + Preamble + Start-Frame Delimiter)

Minimum_Gap представляет интервал между кадрами. Эта формула «масштабируется вверх и вниз» для скоростей 1 GE, 10 GE и т. д.

Пример для скорости 1 GE и кадров размером 64 байта приведен ниже.

      Frame Rate = 1000000000 / (64*8 + 96 + 56 + 8)
                 = 1000000000 / 672
                 = 1488095,2 FPS

С учетом допустимого отклонения ±100 PPM, коммутатор может «законно» передавать трафик со скоростью от 1487946,4 FPS до 1488244 FPS. Отклонение частоты на 1 PPM будет менять скорость на 1,488 FPS.

В реальной сети крайне маловероятно столкнуться с точной скоростью линии в течение очень короткого интервала времени. Различий в отбрасывании пакетов при скорости в 99% и 100% от скорости линии не наблюдается.

Скорость линии можно измерять при 100% с настройкой отклонения частоты -100 PPM.

Скорость линии следует измерять при 99,98% с отклонением 0 PPM.

Постройку PPM следует применять только при измерении скорости линии.

6. Буферизация

6.1. Буфер

6.1.1. Определение

Buffer Size — размер буфера

Термин «размер буфера» (buffer size) представляет общий объем памяти устройства DUT, служащей для буферизации кадров. Размер выражается в байтах (B), килобайтах (KB), мегабайтах (MB) или гигабайтах (GB). При указании размера буфера необходимо указывать также размер MTU (максимальный блок передачи) при тестировании, а также CoS (класс обслуживания) или DSCP (код дифференцированного обслуживания), поскольку распределение буферов зачастую определяется реализацией качества обслуживания. Дополнительную информацию можно найти в разделе 3 [RFC8239].

Пример. Значение Buffer Size устройства DUT при передаче кадров размером 1518 байтов составляет 18 MB.

Port Buffer Size — размер буфера в расчете на порт

Это размер в расчете на один порт для входного буфера, выходного буфера или относящейся к одному порту комбинации входного и выходного буфера. Отмечены три варианта размещения буферов, поскольку схема буферизации DUT может быть не известна или не проверена, поэтому информация о месте буферизации может прояснить архитектуру буферов и, следовательно, общий размер буфера. Значение Port Buffer Size является информационным и может предоставляться производителем DUT. Эти значения не тестируются при определении производительности, для оценки которой служит методология Maximum Port Buffer Size или Maximum Buffer Size.

Maximum Port Buffer Size — максимальный размер буфера на порту

Во многих случаях это совпадает с Port Buffer Size. В коммутаторах с архитектурой SoC11 имеется буфер порта и общая для всех портов буферная емкость. Maximum Port Buffer Size в контексте буферизации SoC представляет собой сумму размера буфера порта и максимального размера общего буфера, выделяемого для этого порта, и выражается в байтах (B), килобайтах (KB), мегабайтах (MB) или гигабайтах (GB). Значение Maximum Port Buffer Size требуется указывать вместе со значением MTU, использованным при измерении, и установленным для теста значением CoS или DSCP.

Пример. Тестирование DUT показало наличие буфера порта размером 3 KB для кадров размером 1518 байтов и общего буфера с максимальным размером 4,7 MB для кадров размером 1518 байтов и CoS = 0.

Maximum DUT Buffer Size — максимальный размер буфера в устройстве

Это общий размер буфера, который может иметь DUT. Скорей всего, он отличается от Maximum Port Buffer Size. Обычно он отличается и от суммы значений Maximum Port Buffer Size. Значение Maximum Buffer Size должно указываться вместе с использованным при измерении значением MTU, а также значением CoS или DSCP.

Пример. В DUT было определено наличие буфера порта размером 3 KB для кадров размером 1518 байтов и максимальный размер общего буфера 4,7 MB для кадров того же размера. Для этого DUT значение Maximum Buffer Size составляет 18 MB при MTU 1500 B и CoS = 0.

Burst — пик, всплеск

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

Microburst – микропик

Микропик представляет собой тип пика, для которого возникает отбрасывание пакетов при отсутствии установившейся или заметной перегрузки (насыщения) линии или устройства. Одной из характеристик микропика является отсутствие равномерного распределения в интервале T и интервалы меньше C (C — среднее время между двумя последовательными пакетами).

Intensity of Microburst — интенсивность микропика

Это процентное значение из диапазона 1 100% показывает уровень микропика. Чем больше значение, тем интенсивней микропик.

      I=[1-[ (Tp2-Tp1)+(Tp3-Tp2)+....(TpN-Tp(n-1) ] / Sum(packets)]]*100

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

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

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

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

При измерении буферов в DUT:

  • должен определяться размер буфера;

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

  • должен измеряться максимальный размер буфера порта;

  • должен измеряться максимальный размер буфера DUT;

  • при тестировании микропиков может быть указана их интенсивность;

  • следует указывать значение CoS или DSCP в процессе тестирования.

6.2. Инкаст

6.2.1. Определение

Термин Incast широко применяется в контексте ЦОД для обозначения картин трафика «многие в один» (many-to-one) или «многие во многие» (many-to-many). Как определено в этом параграфе инкаст является мерой числа входных и выходных портов, а также процента синхронизации между ними. Обычно в ЦОД это относится ко множеству разных входных портов сервера (many), передающих трафик в общий восходящий канал (many-to-one) или множество восходящих каналов (many-to-many). Эта картина обобщается для сети, как множество входящих портов, передающих трафик в один или несколько восходящих каналов.

Synchronous arrival time — синхронное прибытие

Когда два или более кадров размера L1 и L2 приходят на соответствующий входной порт или множество входных портов и время прибытия перекрывается для любого из битов кадров, кадры L1 и L2 называют прибывшими синхронно. Это называется инкастом, независимо от картины many-to-one (проще) или many-to-many.

Asynchronous arrival time — асинхронное прибытие

К этому типу относятся все случаи, когда не наблюдается «синхронного прибытия» кадров.

Percentage of synchronization — процент синхронизации

Это значение определяет степень перекрытия (число битов) между кадрами размеров L1, L2, .., Ln.

Пример. Два 64-байтовых кадра протяженностью L1 и L212 приходят на входные порты 1 и 2 устройства DUT. Имеется перекрытие времени прибытия кадров L1 и L2 на 6,4 байта. Следовательно, уровень синхронизации составляет 10%.

Stateful traffic — трафик с учетом состояния

Трафик пакетов, обмен которыми осуществляется по протоколу с поддержкой состояния соединения типа TCP.

Stateless traffic — трафик без учета состояния

Трафик пакетов, обмен которыми осуществляется по протоколу без поддержки состояния соединения типа UDP.

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

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

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

Синхронное прибытие нескольких кадров на устройство DUT рассматриваются, как формирование Incast.

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

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

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

7. Пропускная способность для приложений

7.1. Определение

В ЦОД сбалансированность сети определяется максимальной пропускной способностью при минимальных потерях. Это описывается параметром Goodput [TCP-INCAST], определяющим пропускную способность на прикладном уровне. Для стандартных приложений TCP очень малые потери могут оказывать значительное влияние на пропускную способность приложений. Определение Goodput представлено в [RFC2647], а применяемая здесь трактовка является вариантом этого определения.

Goodput выражается числом битов за единицу времени, пересылаемых на нужный выходной интерфейс DUT, за вычетом битов, переданных повторно.

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

При оценке пропускной способности ЦОД goodput представляет собой параметр, который следует измерять. Это дает реалистичное представление об использовании доступной пропускной способности. Одной из целей для ЦОД является максимизация goodput при минимизации потерь.

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

Goodput (G) определяется формулой:

      G = (S/F) * V
  • S представляет число байтов информации (payload) без учета заголовков пакетов и TCP;

  • F – размер кадров;

  • V скорость среды в байт/сек.

Пример. Передача файла по протоколу HTTP с использованием транспорта TCP в среде 10 Гбит/с.

Файл не может быть передан через среду Ethernet в форме одного непрерывного потока. Он должен разбиваться на множество кадров размером 1500 байтов при использовании стандартного значения MTU. Каждому пакету требуется 20 байтов для заголовка IP и 20 байтов для заголовка TCP, следовательно для передачи содержимого файла в пакете остается 1460 байтов. Системы на базе Linux вносят дополнительное ограничение до 1448 B, поскольку они дополнительно передают 12 байтов временной метки. Поскольку в этом примере данные передаются через сеть Ethernet к размеру пакета добавляется 26 байтов заголовка и результирующий кадр имеет размер 1526 байтов.

      G = 1460/1526 * 10 Гбит/с, что дает в результате 9,567 Гбит/с или 1,196 Гбайт/с.

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

При измерении Goodput следует документировать в дополнение в перечисленным в параграфе 4.1 данным также:

  • используемые стеки TCP;

  • версии OS;

  • Модель и номер версии микрокода сетевого адаптера (NIC).

Например, стеки TCP в Windows и разных версиях Linux могут влиять на результаты тестов на базе протокола TCP.

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

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

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

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

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

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

Этот документ не требует каких-либо действий со стороны IANA.

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

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

[RFC1242] Bradner, S., “Benchmarking Terminology for Network Interconnection Devices”, RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

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

[RFC2544] Bradner, S. and J. McQuaid, “Benchmarking Methodology for Network Interconnect Devices”, RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.

[RFC5481] Morton, A. and B. Claise, “Packet Delay Variation Applicability Statement”, RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.

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

[RFC8239] Avramov, L. and J. Rapp, “Data Center Benchmarking Methodology”, RFC 8239, DOI 10.17487/RFC8239, August 2017, <https://www.rfc-editor.org/info/rfc8239>.

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

[RFC2432] Dubray, K., “Terminology for IP Multicast Benchmarking”, RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>.

[RFC2647] Newman, D., “Benchmarking Terminology for Firewall Performance”, RFC 2647, DOI 10.17487/RFC2647, August 1999, <https://www.rfc-editor.org/info/rfc2647>.

[RFC2889] Mandeville, R. and J. Perser, “Benchmarking Methodology for LAN Switching Devices”, RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>.

[RFC3918] Stopp, D. and B. Hickman, “Methodology for IP Multicast Benchmarking”, RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>.

[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, “Understanding TCP Incast and Its Implications for Big Data Workloads”, April 2012, <http://yanpeichen.com/professional/usenixLoginIncastReady.pdf>.

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

Авторы благодарны Al Morton, Scott Bradner, Ian Cox и Tim Stevenson за рецензии и отклики.

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


Lucien Avramov

Google

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States of America

Email: lucien.avramov@gmail.com

Jacob Rapp

VMware

3401 Hillview Ave.

Palo Alto, CA 94304

United States of America

Email: jhrapp@gmail.com

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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Device Under Test.

4Packet Delay Variation — вариации задержки пакетов.

5Inter-Packet Delay Variation.

6Link Layer Discovery Protocol — протокол обнаружения канального уровня.

7Spanning Tree Protocol – протокол остовного дерева.

8Gigabit Ethernet.

9Parts Per Million — число долей на миллион.

10Frames per second.

11Switch on chip — однокристальный коммутатор (микросхема). Прим. перев.

12Так в оригинале. Прим. перев.

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

RFC 8200 Internet Protocol, Version 6 (IPv6) Specification

Internet Engineering Task Force (IETF)                        S. Deering
Request for Comments: 8200                                       Retired
STD: 86                                                        R. Hinden
Obsoletes: 2460                                     Check Point Software
Category: Standards Track                                      July 2017
ISSN: 2070-1721

Спецификация протокола IPv6

Internet Protocol, Version 6 (IPv6) Specification

PDF

Тезисы

Этот документ является спецификацией протокола IP версии 6 (IPv6) и отменяет RFC 2460.

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

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

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

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

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

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

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

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

Оглавление

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

1. Введение

Протокол IP версии 6 (IPv6) представляет собой новую версию протокола Internet (IP3), разработанную для замены предшествующего протокола IP версии 4 (IPv4) [RFC791]. Основные отличия IPv6 от IPv4 можно разделить на несколько категорий.

  • Расширенные возможности адресации

    IPv6 расширяет размер адресов IP с 32 до 128 битов для поддержки большего числа уровней иерархии адресов, многократного увеличения числа адресуемых устройств и упрощения процесса автоматической настройки адресов. Масштабируемость групповой маршрутизации повышается за счет добавления поля scope (область действия) в групповые адреса. Определен новый тип адресов — anycast, используемых для передачи пакета одному (любому) узлу из группы.

  • Упрощение формата заголовков

    Некоторые поля заголовков IPv4 в новой версии протокола не используются или не обязательны. Это позволяет сократить издержки на обработку пакетов и расход полосы пропускания каналов на передачу заголовков IPv6.

  • Улучшенная поддержка расширений и опций

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

  • Поддержка меток потоков

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

  • Поддержка аутентификации и приватности

    В IPv6 добавлены расширения для поддержки проверки подлинности (аутентификации), контроля целостности и (опционально) конфиденциальности данных.

В этом документе приведена спецификация базового заголовка IPv6, а также изначально определенных расширений и опций заголовков IPv6. Рассмотрены также вопросы, связанные с размером пакетов, семантика меток потоков и классов трафика, а также влияние IPv6 на вышележащие протоколы. Формат и семантика адресов IPv6 рассмотрены в отдельном документе [RFC4291]. Версия ICMP для протокола IPv6, которую должны включать все реализации IPv6, описана в [RFC4443].

Порядок передачи данных для IPv6 совпадает с порядком передачи данных IPv4, определенным в Приложении B к [RFC791].

Примечание. Поскольку этот документ заменяет собой [RFC2460], во всех упомянутых здесь документах ссылки на RFC 2460 следует считать ссылками на данный документ.

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

node – узел

Устройство, реализующее IPv6.

router – маршрутизатор

Узел, пересылающий пакеты IPv6, не адресованные явно ему4.

host – хост

Любой узел, не являющийся маршрутизатором2.

upper layer – вышележащий уровень

Протокольный уровень, расположенный непосредственно над IPv6. Примерами такого уровня являются транспортные протоколы типа TCP и UDP, протоколы управления типа ICMP, протоколы маршрутизации типа OSPF, а также протоколы, «туннелируемые» через IPv6 (т. е., инкапсулированные в пакеты IPv6) типа IPX5, AppleTalk или самого IPv6.

link – канал

Коммуникационный объект или среда, посредством которых узлы могут взаимодействовать на канальном уровне (уровне, расположенном непосредственно под IPv6). Примерами могут служить сети Ethernet (с мостами или без них), каналы PPP, сети X.25, Frame Relay или ATM, а также туннели сетевого или вышележащих уровней (например, туннели IPv4 или IPv6).

neighbors – соседи

Узлы, подключенные к одному каналу.

interface – интерфейс

Подключение узла к каналу.

address – адрес

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

packet – пакет

Заголовок IPv6 и данные (payload).

link MTU – максимальный передаваемый блок для канала

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

path MTU – максимальный передаваемый блок для пути

Минимальное значение link MTU среди всех каналов на пути от отправителя к получателю.

3. Формат заголовка IPv6

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version – версия

4-битовое значение номера версии протокола IP (6).

Traffic Class – класс трафика

8-битовое поле классификатора трафика (см. раздел 7).

Flow Label – метка потока

20-битовая метка потока (см. раздел 6).

Payload Length – размер данных

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

Next Header – следующий заголовок

8-битовый селектор, указывающий тип заголовка, следующего сразу после заголовка IPv6. Для этого поля используются те же значения, которые определены для поля Protocol в заголовке IPv4 [IANA-PN].

Hop Limit – предельное число пересылок

8-битовое целое число без зака. Значение поля уменьшается на 1 каждым узлом, пересылающим пакет. При получении пакета с Hop Limit = 0 или достижении полем Hop Limit нулевого значения после декрементирования пакет отбрасывается. Узлу, который является конечным получателем пакета, не следует отбрасывать пакеты с Hop Limit = 0, ему следует обрабатывать такие пакеты обычным способом.

Source Address – адрес отправителя

128-битовый адрес инициатора пакета (см. [RFC4291]).

Destination Address – адрес получателя

128-битовый адрес получателя пакета (возможно, не конечного, если присутствует заголовок Routing). См. документ [RFC4291] и параграф 4.4.

4. Заголовки расширений IPv6

В IPv6 необязательная информация сетевого уровня представляется в виде отдельных заголовков, которые могут размещаться в пакете между заголовком IPv6 и заголовком вышележащего уровня. Определено несколько таких заголовков, идентифицируемых значением поля Next Header.

Заголовки расширения нумеруются из реестра IANA IP Protocol Numbers [IANA-PN] с использованием одинаковых значений для IPv4 и IPv6. При обработке последовательности значений Next Header в пакете первый элемент, не являющийся заголовком расширения [IANA-EH], показывает что следующий элемент в пакете относится к заголовку вышележащего уровня. Если такого заголовка нет, применяется специальное значение No Next Header.

Как показано в примерах, приведенных ниже, пакет IPv6 может не включать расширенных заголовков или содержать один или несколько таких заголовков, каждый из которых идентифицируется полем Next Header предшествующего заголовка.

   +---------------+------------------------
   | Заголовок IPv6| Заголовок TCP и данные
   |               |
   | Next Header = |
   |      TCP      |
   +---------------+------------------------


   +---------------+-----------------+------------------------
   | Заголовок IPv6|Заголовок Routing| Заголовок TCP и данные
   |               |                 |
   | Next Header = |  Next Header =  |
   |    Routing    |      TCP        |
   +---------------+-----------------+------------------------

   +---------------+-----------------+------------------+-----------------
   | Заголовок IPv6|Заголовок Routing|Заголовок Fragment| Фрагмент 
   |               |                 |                  | заголовка TCP 
   | Next Header = |  Next Header =  |  Next Header =   | и данные
   |    Routing    |    Fragment     |       TCP        |
   +---------------+-----------------+------------------+-----------------

 

Заголовки расширения (за исключением Hop-by-Hop Options) не обрабатываются, не добавляются и не удаляются узлами на пути доставки пакета, пока он не достигнет узла (или группы узлов в случае групповой адресации), указанного полем Destination Address в заголовке IPv6.

Заголовок Hop-by-Hop Options не добавляется и не удаляется промежуточными узлами, но может быть проверен и обработан любым узлом на пути до того, как достигнет узла (или группы узлов в случае групповой адресации), указанного полем Destination Address в заголовке IPv6. При наличии заголовка Hop-by-Hop Options он должен помещаться непосредственно после заголовка IPv6. Его присутствие указывается нулевым значением поля Next Header в заголовке IPv6.

Примечание. Хотя [RFC2460] требует от всех узлов проверки и обработки заголовка Hop-by-Hop Options, сейчас предполагается, что промежуточные узлы будут проверять и обрабатывать Hop-by-Hop Options только в тех случаях, коггда это явно задано в их конфигурации.

На узле-получателе обычное демультиплексирование поля Next Header в заголовке IPv6 вызывает модуль для обработки первого заголовка расширения или заголовка вышележащего уровня при отсутствии заголовков расширения. В зависимости от содержимого и семантики заголовка расширения выполняется (или не выполняется) обработка следующего заголовка. Следовательно, заголовки расширения должны обрабатываться строго в порядке их размещения в пакете – получателю недопустимо сканировать пакет для поиска определенного заголовка расширения и обработки этого заголовка до обработки его предшественников.

Если по результату обработки заголовка получателю требуется обработать следующий заголовок, но значение Next Header в текущем заголовке не распознано, пакет следует отбросить и передать его отправителю сообщение ICMP Parameter Problem с ICMP Code = 1 (unrecognized Next Header type encountered) и полем ICMP Pointer, указывающим смещение непонятного значения в исходном пакете. Такие же действия следует выполнять в случае нулевого значения поля Next Header в любом заголовке за исключением базового заголовка IPv6.

Размер каждого заголовка расширения кратен 8 для выравнивания последующих заголовков по границе 8 октетов. Многооктетные поля в каждом заголовке расширения выравниваются по их естественным границам (т. е., поле размером n октетов размещается со смещением от начала заголовка, кратным n для значений n = 1, 2, 4 или 8).

Полная реализация IPv6 включает поддержку следующих заголовков расширения:

Hop-by-Hop Options;
Fragment;
Destination Options;
Routing;
Authentication;
Encapsulating Security Payload.

Первые 4 типа заголовков описаны в этом документе, а два оставшихся в [RFC4302] и [RFC4303], соответственно. Действующий список заголовков расширения IPv6 можно найти в [IANA-EH].

4.1. Порядок заголовков расширения

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

заголовок IPv6;
заголовок Hop-by-Hop Options;
заголовок Destination Options6;
заголовок Routing;
заголовок Fragment;
заголовок Authentication7;
заголовок Encapsulating Security Payload2;
заголовок Destination Options8;
заголовок вышележащего уровня.

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

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

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

Узлы IPv6 должны воспринимать и пытаться обрабатывать заголовки расширения при любом порядке и числе вхождений однотипных заголовков расширения в одном пакете. Исключением является заголовок Hop-by-Hop Options, который может присутствовать только непосредственно после заголовка IPv6. Тем не менее, источникам пакетов IPv6 настоятельно рекомендуется включать заголовки расширения в указанном выше порядке, если он не будет изменен последующими спецификациями.

4.2. Опции

Два из определенных в настоящее время заголовков расширения (Hop-by-Hop Options и Destination Options) могут содержать переменное число опций, представленных в формате TLV9, как показано ниже.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Option Type – тип опции

8-битовый идентификатор типа опции.

Opt Data Len – размер данных опции

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

Option Data – данные опции

Поле переменного размера, определяемое типом опции.

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

Идентификаторы Option Type представляются таким образом, что два старших бита задают действие, которое должен выполнить узел IPv6, если значение Option Type ему не известно:

00 пропустить опцию и продолжить обработку заголовка;

01 отбросить пакет;

10 отбросить пакет и, независимо от того, указывает ли поле Destination Address групповой адрес, передать сообщение ICMP Parameter Problem с кодом 2 (нераспознанное значение Option Type) по адресу отправителя (Source Address);

11 отбросить пакет и, если поле Destination Address не содержит групповой адрес, передать сообщение ICMP Parameter Problem с кодом 2 (нераспознанное значение Option Type) по адресу отправителя (Source Address).

Третий по старшинству бит Option Type указывает, может ли поле Option Data изменяться на пути к адресату. При наличии в пакете заголовка Authentication для любой опции, данные которой могут меняться в пути, значение поля Option Data должно считаться нулевым при расчете и проверке контрольной суммы пакета (authenticating value).

0 – Option Data не меняется в пути;

1 – Option Data может меняться в пути.

Три описанных выше старших бита считаются частью поля Option Type, но не являются независимыми от типа опции (т. е. конкретная опция идентифицируется всеми 8 битами поля Option Type, а не только 5 младшими битами этого поля).

Заголовки Hop-by-Hop Options и Destination Options используют общее пространство значений Option Type. Однако спецификация конкретной опции может ограничивать применение типа только одним из этих двух заголовков.

Для отдельных опций могут использоваться специфические требования по выравниванию, чтобы многооктетные поля в Option Data выравнивались по естественным границам. Требования по выравниванию для опций задаются с использованием нотации xn+y, показывающей, что поле Option Type должно представлять собой целое число, размер которого в октетах кратен x, со смещением y октетов от начала заголовка. Например,

2n указывает 2-октетное значение с произвольным смещением от начала заголовка;

8n+2 указывает 8-октетное значение со смещением 2 октета.

Имеется для варианта, которые можно применять при возникновении необходимости выравнивания опций путем заполнения до границы, кратной 8 октетам. Эти варианты заполнения должны поддерживаться всеми реализациями IPv6.

Pad1 (требований по выравниванию нет)

      +-+-+-+-+-+-+-+-+
      |       0       |
      +-+-+-+-+-+-+-+-+

Опция Pad110 используется для вставки одного октета заполнения в область Options заголовка. Если требуется заполнить более одного октета, следует использовать описанную ниже опцию PadN, а не последовательность опций Pad1.

PadN (требований по выравниванию нет)

Опция PadN используется для вставки в область Options заголовка двух или более октетов заполнения. Для N октетов заполнения поле Opt Data Len содержит значение N-2, а поле Option Data – N-2 октетов c нулевым значением.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |       1       |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Рекомендации по формату новых опций приведены в Приложении A.

4.3. Заголовок Hop-by-Hop Options

Заголовок Hop-by-Hop Options используется для передачи дополнительной информации, которая может проверяться и обрабатываться на каждом узле по пути доставки пакета. Заголовок Hop-by-Hop Options идентифицируется значением Next Header = 0 в заголовке IPv6 и использует формат, показанный на рисунке.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header – следующий заголовок

8-битовый селектор, определяющий тип заголовка, следующего непосредственно за Hop-by-Hop Options. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].

Hdr Ext Len – размер заголовка расширения

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

Options – опции

Поле переменного размера, содержащее одну или множество опций в формате TLV, как описано в параграфе 4.2. Общий размер заголовка Hop-by-Hop Options должен быть кратным 8 октетам.

В этом документе для данного заголовка расширения определены только опции Pad1 и PadN (параграф 4.2).

4.4. Заголовок Routing

Заголовок Routing используется источником пакетов IPv6 для указания одного или множества промежуточных узлов, которые пакет должен «посетить» на пути к адресату. Функционально этот заголовок очень похож на опции Loose Source и Record Route в заголовках IPv4. Заголовок Routing идентифицируется значением Next Header = 43 в предшествующем ему заголовке и имеет показанный на рисунке формат.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       type-specific data                      .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header – следующий заголовок

8-битовый селектор, определяющий тип заголовка, следующего непосредственно за Routing. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].

Hdr Ext Len – размер заголовка расширения

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

Routing Type – тип маршрутизации

8-битовый идентификатор конкретного варианта заголовка Routing.

Segments Left – число оставшихся сегментов

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

type-specific data – данные

Поле переменного размера, формат которого определяется значением поля Routing Type. Размер этого поля должен быть таким, чтобы полный размер заголовка Routing был кратен 8 октетам.

Если при обработке полученного пакета узел встречает заголовок Routing с неизвестным значением поля Routing Type, поведение узла определяется значением поля Segments Left, как описано ниже:

если Segments Left = 0, узел должен игнорировать заголовок Routing и перейти к обработке следующего заголовка в пакете, тип которого указан полем Next Header в заголовке Routing;

если значение поля Segments Left отлично от нуля, узел должен отбросить пакет и передать сообщение ICMP Parameter Problem с кодом 0 (указывает на нераспознанное значение Routing Type) по адресу Source Address.

Если после обработки заголовка Routing получивший пакет узел определяет, что пакет будет пересылаться в канал, для которого значение MTU меньше размера пакета, этот узел должен отбросить пакет и передать сообщение ICMP Packet Too Big по адресу Source Address.

Определенные в настоящее время заголовки IPv6 Routing и их статус описаны в [IANA-RH]. Рекомендации по распределения значений для IPv6 Routing Header даны в [RFC5871].

4.5. Заголовок Fragment

Заголовок Fragment используется отправителем IPv6 для передачи пакетов, размер которых превышает значение path MTU для получателя11. Заголовок Fragment идентифицируется значением Next Header = 44 в непосредственно предшествующем заголовке и имеет формат, показанный на рисунке.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header – тип фрагментируемой части

8-битовый селектор, определяющий исходный тип заголовка фрагментируемой части (Fragmentable Part) исходного пакета (см. определение ниже). Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].

Reserved – резерв

8-битовое резервное поле. При передаче это поле заполняется нулями, а на приемной стороне игнорируется.

Fragment Offset – смещение фрагмента

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

Res

2-битовое резервное поле. При передаче это поле заполняется нулями, а на приемной стороне игнорируется.

Флаг M

1 – есть еще фрагменты; 0 – последний фрагмент.

Identification – идентификация

32 бита (см. описание ниже).

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

Для каждого пакета, который будет фрагментироваться, узел-источник генерирует значение Identification. Это значение для фрагментированного пакета должно отличаться от значений для фрагментированных пакетов, переданных «недавно»12 с такими же значениями полей Source Address и Destination Address. При наличии заголовка Routing для фрагментированных пакетов Destination Address трактуется, как адрес конечного получателя.

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

   +------------------+-------------------------+---//----------------+
   |  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
   |    Headers       |       Headers           |      Part           |
   +------------------+-------------------------+---//----------------+

Часть Per-Fragment должна состоять из заголовка IPv6 и всех заголовков расширения, которые должны обрабатываться узлами на пути к получателю, т. е. всех заголовков вплоть до Routing (при его наличии) или Hop-by-Hop Options (при его наличии), включительно. Если ни одного из двух упомянутых заголовков нет, эта часть не включает заголовков расширения.

Следующая часть включает все оставшиеся заголовки расширения, которые не вошли в Per-Fragment headers. При этом заголовки ESP13 не считаются заголовками расширения. Заголовком вышележащего уровня (Upper-Layer header) является первый заголовок вышележащего уровня, не являющийся заголовком расширения IPv6. Примерами такого заголовка могут быть заголовки TCP, UDP, IPv4, IPv6, ICMPv6 и, как отмечено выше, ESP.

Fragmentable Part представляет оставшуюся часть пакета после заголовка вышележащего уровня или любого другого заголовка (например, основного заголовка IPv6 или заголовка расширения, в котором поле Next Header имеет значение No Next Header.

Fragmentable Part исходного пакета разбивается на фрагменты. Размеры фрагментов следует выбирать так, чтобы размеры полученных в результате пакетов не превышали значения MTU на пути к адресату (адресатам). Каждый фрагмент, за исключением последнего (самого правого) имеет размер, кратный 8 октетам.

Фрагменты передаются в отдельных «фрагментированных пакетах», как показано ниже.

Исходный пакет

   +-----------------+-----------------+--------+--------+-//-+--------+
   |  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
   |    Headers      |    Headers      |fragment|fragment|....|fragment|
   +-----------------+-----------------+--------+--------+-//-+--------+

Фрагментированные пакеты

   +------------------+---------+-------------------+----------+
   |  Per-Fragment    |Fragment | Ext & Upper-Layer |  first   |
   |    Headers       | Header  |   Headers         | fragment |
   +------------------+---------+-------------------+----------+
   +------------------+--------+-------------------------------+
   |  Per-Fragment    |Fragment|    second                     |
   |    Headers       | Header |   fragment                    |
   +------------------+--------+-------------------------------+
                         o
                         o
                         o
   +------------------+--------+----------+
   |  Per-Fragment    |Fragment|   last   |
   |    Headers       | Header | fragment |
   +------------------+--------+----------+

Пакет с первым фрагментом состоит из 4 частей, показанных ниже.

  1. Заголовки Per-Fragment исходного пакета с полем Payload Length в исходном заголовке IPv6, измененным в соответствии с размером данного фрагмента (без учета самого заголовка IPv6), и полем Next Header в последнем заголовке Per-Fragment, содержащим значение 44.

  2. Заголовок Fragment, содержащий перечисленные ниже поля.

Next Header со значением, идентифицирующим первый заголовок после заголовков Per-Fragment в исходном пакете.

Fragment Offset, указывающее смещение фрагмента (в 8-октетных блоках) от начала Fragmentable Part исходного пакета. В первом (самом левом) фрагменте Fragment Offset = 0.

Флаг M со значением 1, поскольку это первый фрагмент.

Значение Identification, созданное для исходного пакета.

  1. Заголовки расширения (если они есть) и заголовок вышележащего уровня. Эти заголовки должны включаться в первый фрагмент14.

  2. Первый фрагмент.

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

  1. Заголовки Per-Fragment исходного пакета с полем Payload Length в исходном заголовке IPv6, указывающим размер данного фрагмента (без учета самого заголовка IPv6), и полем Next Header в последнем заголовке Per-Fragment со значением 44.

  2. Заголовок Fragment содержащий перечисленные ниже поля.

Next Header со значением, идентифицирующим первый заголовок после заголовков Per-Fragment исходного пакета.

Fragment Offset, указывающее смещение фрагмента (в 8-октетных блоках) от начала Fragmentable Part исходного пакета.

Флаг M со значением 0 для последнего (самого правого) фрагмента и 1 — для остальных.

Значение Identification, созданное для исходного пакета.

  1. Сам фрагмент.

При фрагментировании пакета перекрытие фрагментов недопустимо.

На приемной стороне фрагменты пакета собираются заново в исходный нефрагментированный пакет, как показано на рисунке.

   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |     Headers     |frag data|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

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

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

Заголовки Per-Fragment собранного пакета включают все заголовки вплоть (но не включая) до заголовка Fragment пакета с первым фрагментом (т. е. пакета с Fragment Offset = 0), с учетом указанных ниже изменений.

Поле Next Header последнего заголовка Per-Fragment берется из поля Next Header в заголовке Fragment в пакете с первым фрагментом.

Значение поля Payload Length в собранном пакете вычисляется на основе размера заголовков Per-Fragment, а также размера и смещения последнего фрагмента. Ниже приведена формула для расчета.

PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

где

PL.orig  =  поле Payload Length собранного пакета.
PL.first =  поле Payload Length первого фрагмента.
FL.first =  размер фрагмента, следующего после заголовка Fragment в пакете первого фрагмента.
FO.last  =  поле Fragment Offset заголовка Fragment в пакете последнего фрагмента.
FL.last  =  размер фрагмента, следующего после заголовка Fragment в пакете последн. фрагмента.

Fragmentable Part собираемого пакет складывается из фрагментов, следующих за заголовком Fragment в каждом из фрагментированных пакетов. Размер каждого фрагмента вычисляется путем вычитания из значения поля Payload Length размера всех заголовков, содержащихся между заголовком IPv6 и самим фрагментом, относительное расположение Fragmentable Part определяется на основе значения Fragment Offset.

Заголовок Fragment в собранном пакете не присутствует.

Если фрагмент является полной дейтаграммой (т. е. Fragment Offset = 0 и флаг M сброшен), он не требует какой-либо сборки и его следует обрабатывать, как полностью собранный пакет (т. е., скорректировать значения Next Header и Payload Length, удалить заголовок Fragment и т. д.). Любый другие фрагмент, соответствующие этому пакету (т. е. с такими же значениями IPv6 Source Address, IPv6 Destination Address и Fragment Identification), следует обрабатывать независимо.

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

  • Если в течение 60 секунд с момента приема первого фрагмента получены не все фрагменты, требуемые для сборки, сборка должна быть прервана, а все полученные фрагменты – отброшены. Если первый фрагмент (т. е. пакет со значением Fragment Offset = 0) был получен, отправителю этого фрагмента следует передать сообщение ICMP Time Exceeded (Fragment Reassembly Time Exceeded15).

  • Если размер фрагмента, определенный из значения поля Payload Length в заголовке пакета с фрагментом, не кратен 8 октетам, а флаг M имеет значение 1, этот фрагмент должен отбрасываться, а отправителю фрагмента следует передать сообщение ICMP Parameter Problem с кодом 0, указывающее на поле Payload Length пакета с фрагментом.

  • Если значения размера и смещения для фрагмента таковы, что значение поля Payload Length собранного из фрагментов пакета будет превышать 65 535 октетов, этот фрагмент должен быть отброшен, а его отправителю следует передать сообщение ICMP Parameter Problem с кодом 0, указывающее на поле Fragment Offset в пакете с фрагментом.

  • Если первый фрагмент не включает всех заголовков до заголовка Upper-Layer, фрагмент следует отбросить, а его отправителю передать сообщение ICMP Parameter Problem с кодом 3 и полем Pointer = 0.

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

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

Ниже перечислены ситуации, которые представляются достаточно редкими, но не считаются ошибками.

Число и содержимое заголовков, предшествующих заголовку Fragment в разных фрагментах одного исходного пакета могут различаться. Независимо от того, какие заголовки присутствуют в каждом фрагменте перед заголовком Fragment, они обрабатываются до того, как фрагменты будут помещены в очередь на сборку. В собранном пакете остаются лишь заголовки из фрагментированного пакета с Offset = 0.

Значения Next Header в заголовках Fragment различных фрагментов одного исходного пакета могут различаться. Для сборки фрагментов используется только значение из пакета, содержащего фрагмент с Offset = 0.

Другие поля в заголовке IPv6 также могут изменяться в процессе сборки фрагментов. Спецификации, использующие такие поля могут включать дополнительные инструкции, если базового механизма с использованием значений лишь из фрагмента с Offset = 0 не достаточно. Например, в параграфе 5.3 [RFC3168] описано, как комбинируются биты ECN из разных фрагментов для получения ECN в собранном пакете.

4.6. Заголовок Destination Options

Заголовок Destination Options используется для передачи дополнительной информации, которая будет просматриваться только на конечном узле(ах). Заголовок Destination Options идентифицируется значением Next Header = 60 в предшествующем непосредственно заголовке и имеет формат, показанный на рисунке.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header – следующий заголовок

8-битовый селектор, определяющий тип заголовка, следующего непосредственно за Destination Options. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].

Hdr Ext Len – размер заголовка расширения

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

Options – опции

Поле переменной длины, такой, что полный размер заголовка Destination Options кратен 8 октетам. Поле опций содержит одну или множество опций в формате TLV, как описано в параграфе 4.2.

В этом документе определены только две опции получателя (Pad1 и PadN), описанные в параграфе 4.2.

Отметим, что существует два возможных способа представления дополнительной информации для получателя в пакетах IPv6 – в виде опции заголовка Destination Options или в виде отдельного заголовка расширения. Примерами второго варианта могут служить заголовки Fragment и Authentication. Выбор конкретного варианта зависит от того, какие действия желательны на узле-адресате в случае непонимания дополнительной информации.

  • Если желательным действием является отбрасывание пакета получателем и передача (в случае, если адрес получателя не является групповым) отправителю сообщения ICMP Unrecognized Type, дополнительная информация может быть представлена в отдельном заголовке или в опции заголовка Destination Options со значением 11 в двух старших битах поля Option Type. Выбор конкретного варианта может определяться размером опции, более эффективным выравниванием или разбором.

  • Если желательно иное действие, дополнительная информация должна представляться в виде опции заголовка Destination Options, для которого два старших бита поля Option Type имеют значение 00, 01 или 10, задающее требуемое действие (см. параграф 4.2).

4.7. Нет следующего заголовка

Значение 59 в поле Next Header заголовка IPv6 или любого заголовка расширения говорит об отсутствии последующих заголовков в пакете. Если поле Payload Length в заголовке IPv6 показывает наличие октетов после завершения заголовка, в котором Next Header = 59, эти октеты должны игнорироваться и пересылаться без изменений.

4.8. Определение новых расширений заголовка и опций

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

Примечание. Новые заголовки расширения, требующие поэтапной (hop-by-hop) обработки, добавлять недопустимо, поскольку, как отмечено в разделе 4 данного документа, заголовок Hop-by-Hop Options является единственным заголовком расширения с поэтапной обработкой.

Создавать новые опции с поэтапной (hop-by-hop) обработкой не рекомендуется, поскольку на узлах может быть задано игнорирование заголовка Hop-by-Hop Options, отбрасывание пакетов с таким заголовком или направление таких пакетов по пути медленной обработки. Разработчикам, предполагающим определить новые опции hop-by-hop, следует принимать это во внимание. Следует четко обосновать необходимость любой новой опции с поэтапной обработкой до того, как она будет стандартизована.

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

Если новые заголовки расширения все-таки определяются, они должны использовать показанный ниже формат.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                  Header-Specific Data                         .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header – следующий заголовок

8-битовый селектор, определяющий тип заголовка, следующего непосредственно после заголовка расширения. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].

Hdr Ext Len – размер заголовка расширения

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

Header Specific Data

Поле переменного размера в зависимости от расширения заголовка.

5. Размер пакетов

IPv6 требует, чтобы каждый канал в сети Internet имел значение MTU не менее 1280 октетов. Это называется минимальным MTU канала IPv6. Для всех каналов, которые не поддерживают передачу пакетов размером 1280 октетов, должна обеспечиваться фрагментация и сборка на уровне ниже IPv6.

Каналы с настраиваемым значением MTU (например, PPP [RFC-1661]) должны настраиваться на использование значений MTU не менее 1280 октетов. Рекомендуется устанавливать значение MTU не менее 1500 октетов для обеспечения возможности инкапсуляции (например, туннелирования) без фрагментации на уровне IPv6.

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

Для узлов IPv6 настоятельно рекомендуется поддержка механизма Path MTU Discovery [RFC8201] для обнаружения и использования преимуществ MTU > 1280 октетов. Однако минимальные реализации IPv6 (например, в загрузочных ПЗУ) могут ограничиваться передачей пакетов, размер которых не превышает 1280 октетов и не поддерживать Path MTU Discovery.

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

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

6. Метки потоков

20-битовое поле Flow Label в заголовке IPv6 используется отправителем для обозначения последовательности пакетов, которую в сети следует считать единым потоком.

Текущее определение IPv6 Flow Label приведено в [RFC6437].

7. Классы трафика

8-битовое поле Traffic Class в заголовке IPv6 используется в сети для управления трафиком. Значения битов Traffic Class в принятом пакете или фрагменте могут отличаться от установленных отправителем.

Использование поля Traffic Class для дифференцированных услуг (Differentiated Services) и явного уведомления о перегрузке (ECN16) задано в [RFC2474] и [RFC3168].

8. Протоколы вышележащего уровня

8.1. Контрольные суммы

Любой транспортный протокол или иной протокол вышележащего уровня, который включает адреса из заголовка IP в расчет контрольной суммы, должен быть изменен для использования с протоколом IPv6, в котором применяются 128-битовые адреса IPv6 взамен 32-битовых адресов IPv4. Приведенный рисунок показывает «псевдозаголовок» TCP и UDP для IPv6.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upper-Layer Packet Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      zero                     |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Исли пакет IPv6 включает заголовок Routing, поле Destination Address, используемое в псевдозаголовке, указывает конечного получателя. На узле-источнике этот адрес будет последним элементом в заголовке Routing, на приемной стороне этот адрес будет указан в поле Destination Address заголовка IPv6.

  • Значение Next Header в псевдозаголовке указывает протокол вышележащего уровня (например, 6 для протокола TCP или 17 для UDP). Оно будет отличаться от значения Next Header в заголовке IPv6, если между этим заголовком и заголовком вышележащего уровня имеются заголовки расширения.

  • Поле Upper-Layer Packet Length в псевдозаголовке содержит размер заголовка и данных вышележащего уровня (например, заголовка и данных TCP). Некоторые протоколы вышележащего уровня поддерживают собственную информацию о размере (например, поле Length в заголовке UDP); для таких протоколов это будет размер, указанный в псевдозаголовке. Другие протоколы (такие, как TCP) не поддерживают собственных данных о размере и в этом случае размер, указанный в псевдозаголовке, будет значением поля Payload Length из заголовка IPv6 за вычетом размера всех заголовков расширения между заголовками IPv6 и вышележащего уровня.

  • В отличие от IPv4, поле контрольной суммы для пакетов UDP, порождаемых узлом IPv6, не является опциональным. Т. е. при генерации пакета UDP узел IPv6 должен рассчитать контрольную сумму UDP для пакета и псевдозаголовка и при получении нулевого значения контрольной суммы заменить его значением FFFF для включения в заголовок UDP. Получатель IPv6 должен отбрасывать пакеты UDP с нулевым значением контрольной суммы и этот факт следует записывать в системный журнал.

  • Как исключение для принятого по умолчанию поведения, протоколы, использующие UDP для туннельной инкапсуляции, могут разрешить нулевые значения контрольной суммы (zero-checksum mode) для конкретного порта или набора портов при отправке и/или приеме пакетов. Каждый узел, поддерживающий режим zero-checksum, должен следовать рекомендациям документа «Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums» [RFC6936].

Протокол ICMP для IPv6 [RFC4443] включает описанный выше псевдозаголовок в расчет контрольной суммы (в отличие от протокола ICMP для IPv4, где псевдозаголовок не учитывается в контрольной сумме). Это сделано для защиты ICMP от ошибочной доставки или повреждения тех полей в заголовках IPv6, от которых зависит ICMP и которые, в отличие от IPv4, не учитывается в контрольной сумме сетевого уровня. Поле Next Header в псевдозаголовке для ICMP содержит значение 58, идентифицирующее версию IPv6 протокола ICMP.

8.2. Максимальный срок жизни пакета

В отличие от IPv4, узлы IPv6 не обязаны соблюдать максимальное время жизни пакетов. По этой причине поле «Time to Live» (TTL) протокола IPv4 переименовано в «максимальное число интервалов» (Hop Limit) в IPv6. На практике очень немногие реализации IPv4 соответствуют требованиям по ограничению времени жизни пакетов, поэтому внесенное в протокол изменение не имеет существенного практического значения. Любой протокол вышележащего уровня, который опирается на сетевой уровень (неважно, IPv4 или IPv6) для ограничения времени жизни пакетов, должен быть обновлен для обеспечения собственных механизмов детектирования и отбрасывания устаревших пакетов.

8.3. Максимальный размер данных вышележащего уровня

При расчете максимального размера данных, доступного протоколу вышележащего уровня, этот протокол должен принимать во внимание больший размер заголовков IPv6 по сравнению с IPv4. Например, в IPv4 опция TCP MSS17 рассчитывается, как максимальный размер пакета (принятое по умолчанию или полученное от механизма Path MTU Discovery значение) за вычетом 40 октетов (20 октетов минимального заголовка IPv4 и 20 октетов минимального заголовка TCP). При использовании TCP с протоколом IPv6 значение MSS должно рассчитываться, как максимальный размер пакета за вычетом 60 октетов, поскольку размер минимального заголовка IPv6 (без заголовков расширения) на 20 октетов превышает минимальный размер заголовка IPv4.

8.4. Отклики на пакеты с заголовками Routing

Когда протокол вышележащего уровня шлет один или множество пакетов в ответ на принятый пакет с заголовком Routing, в пакеты откликов недопустимо включать заголовок Routing, который будет создаваться автоматически путем «обращения» полученного заголовка Routing, пока не будет проверена целостность и подлинность поля Source Address и заголовка Routing (например, путем использования заголовка Authentication из полученного пакета). Иными словами, в ответ на полученные пакеты с заголовком Routing можно передавать только следующие типы пакетов:

  • пакеты отклика без заголовков Routing;

  • пакеты отклика с заголовками Routing, которые не были получены обращением заголовка Routing из принятого пакета (например, с заголовком Routing, определяемым локальной конфигурацией);

  • пакеты отклика с заголовками Routing, полученными путем обращения заголовка Routing из принятого пакета тогда и только тогда, когда поле Source Address и заголовок Routing в полученном пакете были проверены отвечающей стороной.

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

В RFC 2460 указано множество реестров IANA, включая перечисленные ниже:

  • Internet Protocol Version 6 (IPv6) Parameters [IANA-6P]

  • Assigned Internet Protocol Numbers [IANA-PN]

  • ONC RPC Network Identifiers (netids) [IANA-NI]

  • Network Layer Protocol Identifiers (NLPIDs) of Interest [IANA-NL]

  • Protocol Registries [IANA-PR]

Агентство IANA обновило эти реестры ссылками на данный документ.

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

IPv6 с точки зрения базового формата и передачи пакетов имеет параметры безопасности похожие на IPv4. Основные проблемы безопасности перечислены ниже.

  • Перехват — элементы сети на пути передачи могут видеть целиком (включая содержимое и метаданные) каждую дейтаграмму IPv6.

  • Повторное использование (Replay) — атакующий может сохранить перехваченные пакеты и повторно передать их тому же адресату.

  • Вставка пакетов — атакующий может подделать пакеты, придав им нужные свойства, и отправить их в сеть.

  • Удаление пакетов — атакующий может удалить пакеты из канала передачи.

  • Изменение пакетов — атакующий может извлечь пакет из канала передачи, изменить его и заново передать в сеть.

  • MITM-атаки18 – атакующий может разорвать путь передачи, представившись отправителю получателем, а получателю отправителем.

  • DoS-атаки19 – атакующий передает большие объемы легитимного трафика адресату с целью перегрузки последнего.

Пакеты IPv6 можно защитить от просмотра, повторного использования, вставки, изменения и MITM-атак с помощью «Security Architecture for the Internet Protocol» [RFC4301]. В дополнение к этому можно применять протоколы типа TLS20 или SSH21 cдля защиты трафика приложений, передаваемого на основе IPv6.

Не существует механизма для защиты от DoS-атак. Методы защиты от атак на службы выходят за рамки этого документа.

Адреса IPv6 существенно длиннее адресов IPv4 и это значительно осложняет сканирование адресного пространства Internet или даже одной сети (например, ЛВС). Дополнительная информация приведена в [RFC7707].

Предполагается, что адреса узлов IPv6 станут «более видимыми» в сети Internet по сравнению с адресами IPv4, поскольку технологии трансляции адресов будут применяться реже. Это создает некоторые добавочные проблемы приватности за счет упрощения идентификации конечных точек. Дополнительная информация приведена в [RFC7721].

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

Данная версия спецификации IPv6 снимает множество проблем безопасности, присущих прежней версии спецификации IPv6 [RFC2460]. Эти проблемы перечислены ниже.

  • Пересмотрен текст по обработке фрагментов, являющихся полными дейтаграммами (Fragment Offset = 0 и M = 0). При получении такого пакета его следует трактовать, как собранный из фрагментов. Все остальные соответствующие фрагменты следует обрабатывать независимо. Процент фрагментации был изменен для предотвращения фрагментов, являющихся полными дейтаграммами (Fragment Offset = 0 и M = 0). Дополнительная информация представлена в [RFC6946] и [RFC8021].

  • Из раздела 5 исключен параграф, требовавший включения заголовка Fragment в исходящие пакеты при получении сообщения ICMP Packet Too Big с информацией о том, что Next-Hop MTU < 1280. Дополнительная информация приведена в [RFC6946].

  • Изменен текст, относящийся к перекрытию фрагментов IPv6 и узлам теперь недопустимо создавать такие фрагменты. Введено требование отбрасывания (без уведомления) дейтаграммы целиком, если в процессе сборки обнаружилось наложение фрагментов. Добавлено разъяснение, что передавать сообщение ICMP в таких случаях не следует. Дополнительная информация приведена в [RFC5722].

  • Пересмотрен текст в части фрагментации заголовков и сейчас все заголовки вплоть до первого заголовка вышележащего уровня должны помещаться в первый фрагмент. Дополнительная информация приведена в [RFC7112].

  • Учтены обновления из [RFC5095] и [RFC5871] в части удаления текста с описанием заголовков Routing типа 0 (RH0), с указанием того, что рекомендации по этим заголовка приведены в RFC 5871, а тип RH0 удален из списка требуемых заголовков расширений.

Вопросы безопасности, относящиеся к отдельным частям IPv6, включая адресацию, ICMPv6, Path MTU Discovery и т. п., рассмотрены в соответствующих спецификациях.

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

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

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

[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, <http://www.rfc-editor.org/info/rfc2474>.

[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, <http://www.rfc-editor.org/info/rfc3168>.

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

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

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, “IPv6 Flow Label Specification”, RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.

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

[Err2541] RFC Errata, Erratum ID 2541, RFC 2460.

[Err4279] RFC Errata, Erratum ID 4279, RFC 2460.

[Err4657] RFC Errata, Erratum ID 4657, RFC 2460.

[Err4662] RFC Errata, Erratum ID 4662, RFC 2460.

[IANA-6P] IANA, “Internet Protocol Version 6 (IPv6) Parameters”, <https://www.iana.org/assignments/ipv6-parameters>.

[IANA-EH] IANA, “IPv6 Extension Header Types”, <https://www.iana.org/assignments/ipv6-parameters>.

[IANA-NI] IANA, “ONC RPC Network Identifiers (netids)”, <https://www.iana.org/assignments/rpc-netids>.

[IANA-NL] IANA, “Network Layer Protocol Identifiers (NLPIDs) of Interest”, <https://www.iana.org/assignments/nlpids>.

[IANA-PN] IANA, “Protocol Numbers”, <https://www.iana.org/assignments/protocol-numbers>.

[IANA-PR] IANA, “Protocol Registries”, <https://www.iana.org/protocols>.

[IANA-RH] IANA, “Routing Types”, <https://www.iana.org/assignments/ipv6-parameters>.

[RFC1661] Simpson, W., Ed., “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <http://www.rfc-editor.org/info/rfc1661>.

[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.

[RFC4302] Kent, S., “IP Authentication Header”, RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.

[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, “Deprecation of Type 0 Routing Headers in IPv6”, RFC 5095, DOI 10.17487/RFC5095, December 2007, <http://www.rfc-editor.org/info/rfc5095>.

[RFC5722] Krishnan, S., “Handling of Overlapping IPv6 Fragments”, RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.

[RFC5871] Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the IPv6 Routing Header”, RFC 5871, DOI 10.17487/RFC5871, May 2010, <http://www.rfc-editor.org/info/rfc5871>.

[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, “A Uniform Format for IPv6 Extension Headers”, RFC 6564, DOI 10.17487/RFC6564, April 2012, <http://www.rfc-editor.org/info/rfc6564>.

[RFC6936] Fairhurst, G. and M. Westerlund, “Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.

[RFC6946] Gont, F., “Processing of IPv6 “Atomic” Fragments”, RFC 6946, DOI 10.17487/RFC6946, May 2013, <http://www.rfc-editor.org/info/rfc6946>.

[RFC7045] Carpenter, B. and S. Jiang, “Transmission and Processing of IPv6 Extension Headers”, RFC 7045, DOI 10.17487/RFC7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.

[RFC7112] Gont, F., Manral, V., and R. Bonica, “Implications of Oversized IPv6 Header Chains”, RFC 7112, DOI 10.17487/RFC7112, January 2014, <http://www.rfc-editor.org/info/rfc7112>.

[RFC7707] Gont, F. and T. Chown, “Network Reconnaissance in IPv6 Networks”, RFC 7707, DOI 10.17487/RFC7707, March 2016, <http://www.rfc-editor.org/info/rfc7707>.

[RFC7721] Cooper, A., Gont, F., and D. Thaler, “Security and Privacy Considerations for IPv6 Address Generation Mechanisms”, RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.

[RFC7739] Gont, F., “Security Implications of Predictable Fragment Identification Values”, RFC 7739, DOI 10.17487/RFC7739, February 2016, <http://www.rfc-editor.org/info/rfc7739>.

[RFC8021] Gont, F., Liu, W., and T. Anderson, “Generation of IPv6 Atomic Fragments Considered Harmful”, RFC 8021, DOI 10.17487/RFC8021, January 2017, <http://www.rfc-editor.org/info/rfc8021>.

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

Приложение A. Рекомендации по формату опций

В этом приложении приведены некоторые рекомендации по расположению полей в новых опциях для использования с заголовками расширения Hop-by-Hop Options и Destination Options, как описано в параграфе 4.2. Рекомендации базируются на следующих допущениях:

  • желательно выравнивать многооктетные поля в Option Data по их естественным границам – т. е. поля размером n октетов следует размещать с кратным n смещением от начала заголовка Hop-by-Hop Options или Destination Options (для n = 1, 2, 4, 8);

  • желательно минимизировать размер заголовков Hop-by-Hop Options и Destination Options с учетом того, что размер заголовка должен быть кратным 8 октетам;

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

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

Пример 1

Если для опции X требуется два поля данных, размером 8 и 4 октета, их следует расположить, как показано на рисунке.

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         8-октетное поле                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Выравнивание должно быть выполнено по формуле 8n+2, чтобы 8-октетное поле начиналось со смещением от начала содержащего опцию заголовка, кратным 8. Схема полного заголовка Hop-by-Hop Options или Destination Options, содержащего эту опцию, показана на рисунке.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         8-октетное поле                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Пример 2

Если опция Y включает три поля размером 4, 2 и 1 октет, они будут располагаться следующим образом.

                                                   +-+-+-+-+-+-+-+-+
                                                   | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Выравнивание осуществляется по формуле 4n+3, чтобы 4-октетное поле имело смещение от начала содержащего опцию заголовка, кратное 4. Схема полного заголовка Hop-by-Hop Options или Destination Options, содержащего эту опцию, показана на рисунке.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN Option=1 |Opt Data Len=2 |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Пример 3

Заголовок Hop-by-Hop Options или Destination Options с опциями X и Y из примеров 1 и 2 будет иметь один из приведенных ниже форматов в зависимости от порядка расположения опций:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         8-октетное поле                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN Option=1 |Opt Data Len=1 |       0       | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN Option=1 |Opt Data Len=2 |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN Option=1 |Opt Data Len=4 |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |       0       | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         8-октетное поле                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Приложение B. Отличия от RFC 2460

Ниже перечислены отличия данного документа от RFC 2460.

  • Удалено упоминание IP Next Generation в тезисах (Abstract).

  • В раздел 1 добавлен текст, указывающий, что порядок передачи данных совпадает с определенным для протокола IPv4 в RFC 791.

  • Уточнен текст раздела 3 в части декрементирования Hop Limit.

  • Добавлено разъяснение, что заголовки расширения (кроме Hop-by-Hop Options) не обрабатываются, не добавляются и не удаляются узлами на пути доставки пакетов.

  • Требование по обработке заголовка Hop-by-Hop Options заменено на «может» и добавлено примечание, указывающее ожидания в части заголовка Hop-by-Hop Options.

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

  • В конце раздела 4 добавлена ссылка на реестр IANA «IPv6 Extension Header Types».

  • Включены обновления из RFC 5095 и RFC 5871 с целью удалить описание RH0 и указать, что рекомендации по части заголовков Routing указаны в RFC 5871, а тип RH0 удален из списка требуемых заголовков расширения.

  • Пересмотрен параграф 4.5 в части фрагментации IPv6 с учетом обновлений из RFC 5722, RFC 6946, RFC 7112 и RFC 8021.

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

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

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

    • Обновлен текст в части обработки заголовков Fragment для случая точного совпадения фрагментов.

    • Обновлен текст описания заголовка Fragment в части включения AH22 и случая No Next Header.

    • Вместо термина Unfragmentable Headers используется термин Per-Fragment headers в тексте, посвященном заголовку Fragment.

    • Из раздела 5 удален абзац, требовавший включения заголовка Fragment в исходящие пакеты ICMP Packet Too Big с информацией о том, что Next-Hop MTU < 1280.

    • Изменен текст, проясняющий ограничение MTU и 8-байтовые ограничения, а также отмечающий ограничения для заголовокв в первом фрагменте.

  • В параграф 4.5 добавлен текст, поясняющий, что некоторые поля в заголовке IPv6 могут изменяться в процессе сборки фрагментов, а также возможность задания дополнительных инструкций по сборке в других спецификациях. См., например, параграф 5.3 в [RFC3168].

  • Включено обновление из RFC 6564 в форме нового параграфа 4.8 с рекомендациями по определению новых заголовков расширения и опций.

  • В раздел 5 добавлен текст, определяющий минимальное значение IPv6 MTU для канала.

  • Упрощен текст раздела 6, относящийся к меткам потоков (Flow Label) и удалено Приложение A (« Семантика и применение поля Flow Label»). Вместо прежнего текста добавлена ссылка на действующую спецификацию поля IPv6 Flow Label в [RFC6437] и поля Traffic Class в [RFC2474] и [RFC3168].

  • В раздел 8 включено обновление из RFC 6935 (IPv6 and UDP Checksums for Tunneled Packets). Добавлено исключение из принятого по умолчанию поведения при обработке пакетов UDP с нулевой контрольной суммой для туннелей.

  • В разделе 9. Взаимодействие с IANA ссылки на RFC 2460 заменены ссылками на данный документ.

  • Пересмотре и расширен раздел 10. Вопросы безопасности.

  • В раздел «Благодарности» добавлен текст с благодарностями авторам обновленных дкументов.

  • Обновлены ссылки с указанием действующих документов и проведено разделение ссылок на нормативные и информационные.

  • Внесены изменения, обусловленные информацией об ошибках RFC 2460.

    Erratum ID 2541 [Err2541] — в этом сообщении было отмечен, что RFC 2460 не обновляет RFC 2205, где размер метки потока был изменен на 24 бита с 20, заданных RFC 1883. Эта проблема была решена в RFC 6437, где определены метки потоков. Данная спецификация упоминает RFC 6437. Других изменений не требуется

    Erratum ID 4279 [Err4279] — в этом сообщении отмечено, что в спецификации не описано поведение пересылающего узла при получении пакетов с Hop Limit. В разделе 3 данной спецификации проблема устранена.

    Erratum ID 4657 [Err4657] – в этом сообщении предложено отказаться от добавления заголовков расширения на всех узлах, кроме источника пакета. Вопрос решен в разделе 4. Заголовки расширений IPv6.

    Erratum ID 4662 [Err4662] — в этом сообщении предложено отказаться от проверки, обработки, изменения, добавления и удаления заголовков расширения (с единственным исключением) на промежуточных узлах в пути доставки. Вопрос решен в разделе 4. Заголовки расширений IPv6.

    Erratum ID 2843 — это сообщение отвергнуто (Rejected) и никаких изменений не внесено.

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

Авторы выражают свою признательность за многочисленные предложения членам рабочей группы Ipng, исследовательской группы End-to-End Protocols и всему сообществу Internet.

Авторы также признательным авторам обновленных RFC, которые были включены в этот документ для получения спецификацией IPv6 статуса Internet Standard. Это Joe Abley, Shane Amante, Jari Arkko, Manav Bhatia, Ronald P. Bonica, Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Savola, Magnus Westerlund и James Woodyatt.

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

Stephen E. Deering

Retired

Vancouver, British Columbia

Canada

Robert M. Hinden

Check Point Software

959 Skyway Road

San Carlos, CA 94070

United States of America

Email: bob.hinden@gmail.com


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

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

nmalykh@gmail.com


1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Internet Protocol.

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

5Internetwork Packet Exchange.

6Для опций, которые будут обрабатываться первым получателем, указанным в поле IPv6 Destination Address, плюс получатели, указанные далее в заголовке Routing.

7Дополнительные требования к относительному порядку заголовков Authentication и Encapsulating Security Payload приведены в [RFC4303].

8Для опций, обрабатываемых только адресатом пакета.

9Type-length-value – тип-размер-значение.

10Формат опции Pad1 отличается от обычного TLV – опция не включает полей размера и значения.

11В отличие от IPv4 фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами на пути доставки (см. раздел 5).

12«Недавно» означает «в пределах максимального вероятного времени жизни пакета, включая время передачи от отправителя к получателю и время ожидания сборки фрагментов». Однако узел-источник не обязан знать максимальное время жизни пакета. Вместо этого предполагается, что требование может быть удовлетворено за счет использования алгоритма, обеспечивающего низкую частоту повторного использования значений. Примеры таких алгоритмов описаны в [RFC7739].

13Encapsulating Security Payload — инкапсуляция защищенных данных.

14Это ограничивает размер заголовков (с учетом заголовка Upper-Layer) величиной MTU на пути к адресату (адресатам).

15Истекло время сборки фрагментов.

16Explicit Congestion Notification.

17Максимальный размер сегмента TCP.

18Man-in-the-middle – перехват и изменение пакетов с участием человека.

19Denial-of-service — атака, нацеленная на отказ в обслуживании.

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

21Secure Shell.

22Authentication Header — заголовок аутентификации.

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

RFC 8203 BGP Administrative Shutdown Communication

Internet Engineering Task Force (IETF)                       J. Snijders
Request for Comments: 8203                                           NTT
Updates: 4486                                                   J. Heitz
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                               J. Scudder
                                                                 Juniper
                                                               July 2017

Сообщения BGP Shutdown Communication

BGP Administrative Shutdown Communication

PDF

Тезисы

Этот документ дополняет субкоды Administrative Shutdown и Administrative Reset сообщенийBGP Cease NOTIFICATION для операторов с целью передачи коротких сообщений в свободном формате для описания причин сброса или разрыва сессий BGP. Документ служит обновлением RFC 4486.

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

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

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

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

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

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

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

Оглавление

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

 

1. Введение

Для оператора может оказаться сложным сопоставление разрыва сессии BGP-4 [RFC4271] в сети с уведомлением, переданным по отдельному «каналу» (например, по электронной почте или телефону). Этот документ обновляет [RFC4486] путем задания механизма передачи короткого сообщения в кодировке UTF-8 [RFC3629] со свободным форматом в составе сообщений Cease NOTIFICATION [RFC4271] для информирования партнера о причине разрыва сессии BGP.

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

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

2. Поле Shutdown Communication

Если узел BGP решает разовать сессию со своим BGP-соседом и передает сообщение NOTIFICATION с кодом ошибки (Error Code) Cease и субкодом (Error Subcode) Administrative Shutdown или Administrative Reset [RFC4486], он может включить в сообщение строку в кодировке UTF-8. Содержимое этой строки оператор определяет самостоятельно.

Формат сообщения Cease NOTIFICATION с полем Shutdown Communication показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code 6  |    Subcode    |    Length     |     ...       \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
\                                                               \
/                 ... Shutdown Communication ...                /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1


Subcode

Значение Error Subcode должно быть 2 (Administrative Shutdown) или 4 (Administrative Reset).

Length

8-битовое поле, представляющее размер строки Shutdown Communication в октетах. Поле размера может принимать значение от 0 до 128 включительно. Нулевое размер говорит об отсутствии поля Shutdown Communication.

Shutdown Communication

Для поддержки разных языков поле Shutdown Communication должно представляться в кодировке UTF-8. Принимающему узлу BGP недопустимо интерпретировать неприемлемые последовательности UTF-8. Отметим, что при включении в Shutdown Communication символой, представляемых не одним байтом, число символов строки будет меньше значения поля Length. NUL-символ в конце строки не используется.

Механизмы передачи операторам информации из Shutdown Communication зависят от реализации, но следует включать в число таких механизмов запись в Syslog [RFC5424].

3. Практическое применение

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

«[TICKET-1-1438367390] обновление программ; восстановление в течение 2 часов»

«[TICKET-1-1438367390]» представляет собой ссылку на «квитанцию», которая имеет понятна обеим сторонам, за которой следует краткое и понятное человеку сообщение о причине разрыва сессии BGP с информацией о продолжительности срока обслуживания. Получатель может воспользоваться строкой TICKET-1-1438367390 для поиска более подробной информации в своем архиве электронной почты.

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

Если поле Shutdown Communication имеет некорректный размер или неверную последовательность символов UTF-8, в системный журнал от этом следует уведомить оператора. Можно в таких случаях также записывать в системный журнал шестнадцатеричный дамп всего поля Shutdown Communication.

5. Согласование с IANA

IANA указывает этот документ (в дополнение к [RFC4486]) для субкодов Administrative Shutdown (2) и Administrative Reset (4) в реестре Cease NOTIFICATION message subcodes для группы параметров Border Gateway Protocol (BGP) Parameters.

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

Этот документ указывает использование кодировки UTF-8 для Shutdown Communication. С кодировкой Unicode связано множество проблем безопасности. Разработчикам и операторам рекомендуется прочесть отчет Unicode Technical Report #36 [UTR36] для получения информации об этих проблемах. Требуется применять UTF-8 Shortest Form для защиты от технических проблем, указанных в [UTR36].

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

Пользователям этого механизма следует принимать во внимание, что при отсутствии на транспортном уровне защиты целостности для сеансов BGP сообщения Shutdown Communication можно подделать. Если транспортный уровень не обеспечивает защиту конфиденциальности, злоумышленник может создавать обманные сообщения Shutdown Communication. Эта проблема относится ко всем сообщениям BGP, но может вызывать повышенный интерес в контексте данного предложения, поскольку передаваемая в сообщениях информация обычно предназначена для прочтения людьми. Аналогичные вопросы рассмотрены в [RFC4271] и [RFC4272].

Пользователям этого механизма следует рассмотреть вопрос минимизации передаваемых в сообщениях данных, как описано в параграфе 6.1 [RFC6973], поскольку принятые сообщения Shutdown Communication могут использоваться по усмотрению получателя.

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, <http://www.rfc-editor.org/info/rfc2119>.

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

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

[RFC4486] Chen, E. and V. Gillet, “Subcodes for BGP Cease Notification Message”, RFC 4486, DOI 10.17487/RFC4486, April 2006, <http://www.rfc-editor.org/info/rfc4486>.

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

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

[RFC4272] Murphy, S., “BGP Security Vulnerabilities Analysis”, RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.

[RFC5424] Gerhards, R., “The Syslog Protocol”, RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.

[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, <http://www.rfc-editor.org/info/rfc6973>.

[UTR36] Davis, M., Ed. and M. Suignard, Ed., “Unicode Security Considerations”, Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/>.

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

Авторы выражают свою признательность Tom Scholl, David Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Saku Ytti, Lou Berger, Alvaro Retana и Adam Roach.

Авторы благодарят Enke Chen и Vincent Gillet за их работу [RFC4486] и предоставление относящихся к ней прав IETF Trust в соответствии с BCP 78.

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

Job Snijders

NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net

Jakob Heitz

Cisco

170 West Tasman Drive

San Jose, CA 95134

United States of America

Email: jheitz@cisco.com

John Scudder

Juniper Networks

1194 N. Mathilda Ave

Sunnyvale, CA 94089

United States of America

Email: jgs@juniper.net

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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Полужирными в переводах. Прим. перев.

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

RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies

Internet Engineering Task Force (IETF)                          J. Mauch
Request for Comments: 8212                                        Akamai
Updates: 4271                                                J. Snijders
Category: Standards Track                                            NTT
ISSN: 2070-1721                                               G. Hankins
                                                                   Nokia
                                                               July 2017

Распространение маршрутов EBGP без политики

Default External BGP (EBGP) Route Propagation Behavior without Policies

PDF

Тезисы

Этот документ обновляет RFC 4271, определяя принятое по умолчанию поведение поведение узлов BGP при отсутствии политики импорта или экспорта, связанной с сессией External BGP.

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

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

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

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

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

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

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

Оглавление

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

1. Введение

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

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

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

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

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

В [RFC4271] описана информационная база правил (PIB3), содержащая локальные правила, применяемые к информации из базы маршрутных данных RIB4. Данный документ разделяет типы правил (политики) на основе их применения.

Политика импорт — локальные правила, применяемые к информации, содержащейся в Adj-RIBs-In. Как описано в параграфе 3.2 [RFC4271], Adj-RIBs-In содержит информацию, полученную от других узлов BGP и применение этой политики дает в результате маршруты, которые будут учитываться в процессе принятия решений (Decision Process) данным узлом BGP.

Политика экспорта применяется при выборе информации, содержащейся в Adj-RIBs-Out. Как указано в параграфе 3.2 [RFC4271], Adj-RIBs-Out содержит информацию, выбранную для анонсирования другим узлам BGP.

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

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

3. Отличия от RFC 4271

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

Приведенный ниже абзац добавляется в параграф 9.1 «Процесс выбора маршрутов (Decision Process)» после пятого абзаца, который заканчивается словами «объединение маршрутов и снижение объема маршрутной информации»5.

Маршруты из Adj-RIB-In, связанные с данным партнером EBGP, не следует рассматривать, как желательные (eligible) в Decision Process, если к ним не была явно применена политика импорта (Import Policy).

Приведенный ниже абзац добавляется в параграф 9.1.3 «Фаза 3: Распространение маршрутов (Route Dissemination)» после третьего абзаца, который заканчивается словами «с помощью сообщения UPDATE (см. параграф 9.2)».

Маршруты не следует добавлять в Adj-RIB-Out, связанную с данным партнером EBGP, если к ним не была явно применена политика экспорта.

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

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

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

Вопросы безопасности, рассмотренные в [RFC4271], и анализ уязвимостей в [RFC4272] применимы и к данному документу.

5. Согласование с IANA

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

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

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

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

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

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

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

[RFC4272] Murphy, S., “BGP Security Vulnerabilities Analysis”, RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.

[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, “Problem Definition and Classification of BGP Route Leaks”, RFC 7908, DOI 10.17487/RFC7908, June 2016, <http://www.rfc-editor.org/info/rfc7908>.

Приложение A. Вопросы перехода для разработчиков BGP

Это приложение не является нормативным.

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

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

A.1. Стратегия N+1 N+2

Разработчики могут использовать модель, описанную, как стратегия выпуска «N+1 и N+2». В выпуске N+1 вводятся новые конфигурационные параметры, используемые по умолчанию для индикации работы узла BGP в небезопасном режиме (ebgp insecure-mode). Кроме добавление нового параметра разработчики могут добавить выдачу оператору предупреждений о том, что в некоторых частях конфигурация не полна. В выпуске N+1 операторы такой реализации BGP будут знать, что имеется возможность настройки конфигурации и могут соответствующим образом ее сделать. В выпуске N+2 или позднее может быть введен используемый по умолчанию параметр, с обратным по отношение к N+1 смыслом.

В результате новые инсталяции выпуска N+2 будут соответствовать данному документу. Инсталяции выпуска N+1 будут следовать прежнему, незащищенному поведению, если конфигурационный параметр ebgp insecure-mode не будет изменен.

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

Авторы благодарны за рецензии, комментарии и поддержку Shane Amante, Christopher Morrow, Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald Smith, Alvaro Retana, John Scudder b Dale Worley.

Участники

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

Jakob Heitz
Cisco
Email: jheitz@cisco.com

Ondrej Filip
CZ.NIC
Email: ondrej.filip@nic.cz

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

Jared Mauch
Akamai Technologies
8285 Reese Lane
Ann Arbor Michigan 48103
United States of America
Email: jared@akamai.com

Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The Netherlands
Email: job@ntt.net

Greg Hankins
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: greg.hankins@nokia.com


Перевод на русский язык
Николай Малых
nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Policy Information Base.

4Routing Information Base — база данных о маршрутизации.

5Это последний абзац параграфа, п c). Прим. перев.

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

RFC 8164 Opportunistic Security for HTTP/2

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 8164
Category: Experimental                                        M. Thomson
ISSN: 2070-1721                                                  Mozilla
                                                                May 2017

Подходящая защита для HTTP/2

Opportunistic Security for HTTP/2

PDF

Тезисы

В этом документе описано, как можно обеспечить доступ к http URI с использованием защищенного транспорта TLS1 и HTTP/2 для подавления всеобъемлющего мониторинга. Этот механизм не является заменой https URI и уязвим для активных атак.

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

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

Документ определяет экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

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

Оглавление

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

1. Введение

Документ описывает применение дополнительных служб HTTP [RFC7838] для отвязывания схемы URI от использования и настройки шифрования на нижележащих уровнях. Он обеспечивает возможность доступа к http URI [RFC7230] с использованием HTTP/2 и TLS [RFC5246] с Opportunistic Security [RFC7435].

В этом документе описана модель, посредством которой сайты могут обслуживать http URI через TLS, избегая проблемы обслуживания «смешанного содержимого (Mixed Content), описанной в [W3C.CR-mixed-content-20160802], с сохранением защиты от пассивных атак.

Модель «подходящей (уместной) защиты» (OS4) не обеспечивает таких же гарантий, как использование TLS с https URI, поскольку она уязвима к активным атакам, и не меняет контекста защиты соединения. Обычно пользователи просто не будут замечать ее применение (не будет значка блокировки – lock icon).

1.1. Цели

Непосредственной целью является повышение устойчивости HTTP к всеобъемлющему пассивному мониторингу [RFC7258].

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

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

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

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

2. Использование HTTP URI «поверх» TLS

Сервер-источник, поддерживающий преобразование http URI, может указать поддержку данной спецификации, путем анонсирования дополнительных услуг [RFC7838] для идентификатора протокола, который использует TLS (например, h2 [RFC7540]). Такой протокол должен включать явную индикацию схемы для ресурса. Это исключает HTTP/1.1 — клиентам HTTP/запрещено включать абсолютную форму URI в запросы к серверам-источникам (см. параграф 5.3.1 в [RFC7230]).

Клиент, получивший такой анонс, может делать будущие запросы к соответствующему источнику [RFC6454] с учетом этого сервиса (как указано в [RFC7838]), при условии выбора дополнительной услуги в соответствии с параграфом 2.1.

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

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

Клиентские сертификаты не имеют смысла для URL в схеме http, следовательно, клиентам, организующим новые соединения TLS с дополнительными службами в соответствии с данной спецификацией, недопустимо представлять эти сертификаты. Серверы, которые поддерживают ресурсы https на том же порту, могут запросить сертификат в процессе согласования TLS, но им недопустимо прерывать согласование, если клиент не представил сертификат.

2.1. Alternative Server Opt-In

По разным причинам сервер может перепутать в запрашиваемом URL схемы http и https (см. параграф 4.4). Для гарантии того, что дополнительные будут предлагаться при обработке http URL с использованием TLS, клиенты должны выполнять дополнительные проверки до отправки запросов http.

Клиентам недопустимо передавать запросы http через защищенные соединения, пока выбранный дополнительный сервис не представил корректный сертификат источника, как определено в [RFC2818]. Использование аутентифицированного дополнительного сервиса обеспечивает «разумные гарантии» для целей [RFC7838]. В дополнение к аутентификации сервера клиент должен иметь действительный отклик http-opportunistic от источника (как указано в параграфе 2.3), полученный с использованием аутентифицированного соединения. Исключение для последнего правила делается для запросов http-opportunistic от общеизвестных URI.

Предположим, например, что запрос выполняется через соединение TLS, которое аутентифицировано для этого источника. В этом случае можно передать запросы и отклики для источников http://www.example.com и http://example.com через защищенное соединение.

   HEADERS
     + END_STREAM
     + END_HEADERS
       :method = GET
       :scheme = http
       :authority = example.com
       :path = /.well-known/http-opportunistic

   HEADERS
       :status = 200
       content-type = application/json
   DATA
     + END_STREAM
   [ "http://www.example.com", "http://example.com" ]

В этом документе для удобства указывается несколько источников. Только запрос, выполненный для источника (через аутентифицированное соединение) может использоваться для получения ресурса http-opportunistic от этого источника. Таким образом, для нашего примера запрос к http://example.com не позволяет предполагать представления ресурса http-opportunistic также для http://www.example.com.

2.2. Взаимодействие с https URI

Клиентам недопустимо передавать запросы http и https через одно соединение. Аналогично, клиентам недопустимо передавать через одно соединение запросы http для разных источников.

2.3. Общеизвестные http-opportunistic URI

Данная спецификация определяет общеизвестные http-opportunistic URI [RFC5785]. Клиент может считать, что у него имеется приемлемый отклик http-opportunistic для данного источника, при выполнении перечисленных ниже условий.

  • Клиент запросил общеизвестный URI у источника через аутентифицированное соединение и получил отклик с кодом 200 (OK);

  • этот отклик является свежим [RFC7234] (возможно через повторную проверку [RFC7232]);

  • отклик имеет тип среды application/json;

  • данные отклика при разборе как JSON [RFC7159] содержат массив в качестве корня;

  • массив содержит строку, которая с учетом регистра посимвольно совпадает с запрашиваемым источником при последовательном представлении в кодировке Unicode, как описано в параграфе 6.1 [RFC6454].

Клиент может трактовать ресурс http-opportunistic, как неприемлемый, если его значения отличны от строк.

Этот документ не определяет семантики ресурсов http-opportunistic на источниках https и в тех случаях, когда ресурс содержит источники https.

Разрешение клиентам кэшировать ресурс http-opportunistic означает, что все дополнительные службы должны быть способны отвечать на запросы для ресурсов http. Клиентам разрешено использовать использовать дополнительный сервис без «приобретения» ресурса http-opportunistic от этого сервиса.

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

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

3. Согласование с IANA

Данная спецификация регистрирует перечисленные ниже общеизвестные (well-known) URI [RFC5785]:

  • URI Suffix: http-opportunistic

  • Change Controller: IETF

  • Specification Document(s): Section 2.3 of RFC 8164

  • Related Information:

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

4.1. Индикаторы защиты

Пользовательским агентам недопустимо выводить какие-либо специальные индикаторы защищенности, когда ресурс http «обретен» с использованием TLS. В частности, недопустимо использовать такие же индикаторы защищенности (например, lock device), как для https.

4.2. Атаки со снижением требований

Возможны атаки, нацеленные на снижение требований при согласовании TLS.

Например, поскольку поле заголовка Alt-Svc [RFC7838] скорей всего будет присутствовать в неаутентифицированном и нешифрованном канале, оно может использоваться для атак. В простейшем варианте атакующий, который пытается принудить к организации нешифрованного соединения, может просто удалить из откликов поле заголовка Alt-Svc.

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

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

4.4. Возможная путаница со схамой запроса

В реализациях и приложениях HTTP иногда применяются внешние сигналы для определения запросов, относящихся к ресурсам https (например, поиск TLS в стеке или порта 443 на сервере).

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

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

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

4.5. Управление сервером

Данная спецификация требует, чтобы сервер передавал анонс дополнительных услуг в общеизвестное место для того, чтобы можно было передавать запросы HTTP через TLS. Серверам следует принять надлежащие меры по обеспечению контроля за содержимым общеизвестных ресурсов. Аналогично, в результате применения поля заголовка Alt-Svc для описания политики источника в целом, серверам не следует разрешать пользователю устанавливать или изменять значение этого заголовка.

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

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

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

[RFC2818] Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

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

[RFC5785] Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs)”, RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.

[RFC6454] Barth, A., “The Web Origin Concept”, RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.

[RFC7159] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, “HTTP Alternative Services”, RFC 7838, DOI 10.17487/RFC7838, April 2016, <http://www.rfc-editor.org/info/rfc7838>.

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

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

[RFC7435] Dukhovni, V., “Opportunistic Security: Some Protection Most of the Time”, RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.

[W3C.CR-mixed-content-20160802] West, M., “Mixed Content”, World Wide Web Consortium CR CR-mixed-content-20160802, August 2016, <https://www.w3.org/TR/2016/CR-mixed-content-20160802>.

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

Mike Bishop предоставил текст существенной части этого документа.

Спасибо Patrick McManus, Stefan Eissing, Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla, Julian Reschke, Kari Hurtta и Richard Barnes за их отклики и предложения.

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

Mark Nottingham

Email: mnot@mnot.net

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

Martin Thomson

Mozilla

Email: martin.thomson@gmail.com


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

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

nmalykh@gmail.com

1Transport Layer Security — защита транспортного уровня.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Opportunistic Security.

5Man-in-the-middle – перехват данных в возможностью их изменения при участии человека.

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

RFC 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 8174                           Huawei Technologies
BCP: 14                                                         May 2017
Updates: 2119
Category: Best Current Practice
ISSN: 2070-1721

Неоднозначность использования заглавных букв в ключевых словах RFC 2119

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

PDF

Тезисы

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

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

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

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

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

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

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

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

Оглавление

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

1. Введение

В RFC 2119 указаны ключевые слова общего назначения типа MUST, SHOULD и MAY, которые могут применяться в спецификациях протоколов. Там сказано, что ключевые слова «часто выделяются заглавными буквами» и это приводило к неоднозначности трактовки слов типа must и should без заглавных букв.

Данный документ обновляет RFC 2119, разъясняя, что только слова, набранные заглавными буквами, имеют указанное в документе значение. Документ является частью BCP 14.

2. Разъяснение по использованию заглавных букв в ключевых словах

Ниже показаны изменения, вносимые в [RFC2119]:

=== Старый текст ===

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

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 21195.

=== Новый текст ===

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

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

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

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

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

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here6.

=== Конец изменений ===

3. Согласование с IANA

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

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

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

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

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

Адрес автора

Barry Leiba

Huawei Technologies

Phone: +1 646 827 0648

Email: barryleiba@computer.org

URI: http://internetmessagingtechnology.org/


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

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

nmalykh@gmail.com

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

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4В переводах на сайте www.protocols.ru используется выделение жирным шрифтом. Прим. перев.

5Ключевые слова необходимо, недопустимо, требуется, нужно, не нужно, следует, не следует, рекомендуется, не рекомендуется, возможно, необязательно в данном документе должны интерпретироваться в соответствии с требованиями RFC 2119.

6Ключевые слова необходимо, недопустимо, требуется, нужно, не нужно, следует, не следует, рекомендуется, не рекомендуется, возможно, необязательно в данном документе должны интерпретироваться в соответствии с требованиями BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они полностью набраны заглавными буквами, как показано здесь.

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

RFC 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

 

Internet Engineering Task Force (IETF)                           O. Sury
Request for Comments: 8080                                        CZ.NIC
Category: Standards Track                                     R. Edmonds
ISSN: 2070-1721                                                   Fastly
                                                           February 2017

Алгоритм EdDSA для DNSSEC

Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

PDF

Тезисы

В этом документе описано, как задать ключи и подписи EdDSA1 для защиты DNS (DNSSEC2). Алгоритм EdDSA может применяться с кривыми Ed25519 и Ed448.

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

Этот документ является проектом стандарта (Internet Standards Track).

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

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

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

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

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

Оглавление

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

1. Введение

Механизмы DNSSEC, описанные в [RFC4033], [RFC4034] и [RFC4035], используют криптографические ключи и цифровые подписи для проверки подлинности данных DNS. В настоящее время наиболее популярным алгоритмом защиты является RSA. Стандартизована также заданная GOST [RFC5933] и NIST криптография на основе эллиптических кривых [RFC6605].

В [RFC8032] описана система подписи на основе эллиптических кривых (EdDSA) и рекомендованы две кривые – Ed25519 и Ed448.

В этом документе определяется использование в DNSSEC записей о ресурсах (RR5) DS, DNSKEY и RRSIG с новым алгоритмом подписи EdDSA и предложены на выбор две кривые – Ed25519 и Ed448.

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

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

3. Записи DNSKEY

Открытый ключ Ed25519 представляет собой 32-октетное значение, помещаемое в поле Public Key записей DNSKEY в форме простой битовой строки. Генерация открытого ключа описана в параграфе 5.1.5 [RFC8032].

Открытый ключ Ed448 представляет собой 57-октетное значение, помещаемое в поле Public Key записей DNSKEY в форме простой битовой строки. Генерация открытого ключа описана в параграфе 5.1.5 [RFC8032].

4. Записи RRSIG

Подпись Ed25519 представляет собой 64-октетное значение, помещаемое в поле Signature записей RRSIG в форме простой битовой строки. Алгоритм и проверка подписи Ed25519 описаны в параграфах 5.1.6 и 5.1.7 [RFC8032], соответственно.

Подпись Ed448 представляет собой 114-октетное значение, помещаемое в поле Signature записей RRSIG в форме простой битовой строки. Алгоритм и проверка подписи Ed448 писаны в параграфах 5.1.6 и 5.1.7 [RFC8032], соответственно.

5. Номер алгоритма для записей DS, DNSKEY и RRSIG

Для алгоритма Ed25519 в записях DS, DNSKEY и RRSIG выделен номер 15. Для алгоритма Ed448 в записях DS, DNSKEY и RRSIG выделен номер 16. Эта регистрация полностью определена в разделе «Согласование с IANA».

6. Примеры

6.1. Примеры Ed25519

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 3613 example.com. (
             Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj
             H5GaMWeG96GUVZu6ECKOQmemHDg== )

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 35217 example.com. (
             5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+
             oip9ayUGjY9T/rL4rN3bOuESGDA== )

6.2. Примеры Ed448

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 9713 example.com. (
             Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3
             9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0
             SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA )

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 38353 example.com. (
             +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg
             5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp
             vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA )

7. Согласование с IANA

Этот документ обновляет реестр IANA Domain Name System Security (DNSSEC) Algorithm Numbers. В реестр добавляются две записи, показанные в таблице.

Номер

15

16

Описание

Ed25519

Ed448

Обозначение

ED25519

ED448

Подпись зоны

+

+

Защита транзакций

*

*

Документ

RFC 8080

RFC 8080

* Стандартизация использования этого алгоритма для защиты транзакций не определена

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

Вопросы безопасности, рассмотренные в [RFC8032] и [RFC7748], сохраняются для использования алгоритмов Ed25519 и Ed448 в DNSSEC.

Алгоритм Ed25519 предназначен для работы с уровнем защиты 128 битов, Ed448 — с уровнем защиты 224 бита. Взломать такую защиту способны достаточно большие квантовые компьютеры. Разумные оценки возможностей традиционных компьютеров говорят о полной безопасности Ed25519. Алгоритм Ed448 предназначен для приложений, где требования к производительности менее высоки и имеется желание обеспечить защиту от аналитических атак на эллиптические кривые.

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

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

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

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

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

[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, <http://www.rfc-editor.org/info/rfc4033>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions”, RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions”, RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, “Elliptic Curves for Security”, RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.

[RFC8032] Josefsson, S. and I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA)”, RFC 8032, DOI 10.17487/RFC8032, January 2017, <http://www.rfc-editor.org/info/rfc8032>.

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

[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, “Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC”, RFC 5933, DOI 10.17487/RFC5933, July 2010, <http://www.rfc-editor.org/info/rfc5933>.

[RFC6605] Hoffman, P. and W. Wijngaards, “Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC”, RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.


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

Some of the material in this document is copied liberally from [RFC6605].

The authors of this document wish to thank Jan Vcelak, Pieter Lexis, Kees Monshouwer, Simon Josefsson, Paul Hoffman, and others for a review of this document.

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


Ondrej Sury

CZ.NIC

Milesovska 1136/5

Praha 130 00

Czech Republic

Email: ondrej.sury@nic.cz

Robert Edmonds

Fastly

Atlanta, Georgia

United States of America

Email: edmonds@mycre.ws


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

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

nmalykh@gmail.com

1Edwards-curve Digital Security Algorithm.

2DNS Security.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Resource record.

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