RFC 8199 YANG Module Classification

Internet Engineering Task Force (IETF)                     D. Bogdanovic
Request for Comments: 8199                          Volta Networks, Inc.
Category: Informational                                        B. Claise
ISSN: 2070-1721                                                C. Moberg
                                                     Cisco Systems, Inc.
                                                               July 2017

YANG Module Classification

Классификация модулей YANG

PDF

Тезисы

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

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

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

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

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

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

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

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

Авторские права (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. Введение

IESG активно поощряет рабочие группы IETF к использования языка моделирования данных YANG [RFC7950] и протокола NETCONF4 [RFC6241] для целей управления конфигурацией (особенно в уставах новых рабочих групп [IESG-Statement]).

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

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

В этом документе представлен набор понятий и терминов для формирования таксономии согласованной классификации модулей YANG в двух аспектах:

  • уровни модулей на основе абстракций;

  • тип происхождения модуля на основе его природы и назначения.

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

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

Этот документ должен помочь трем категориям, указанным ниже.

  • Во-первых, общая таксономия поможет в дискуссиях между SDO и отраслевыми консорциумами, цели которых определяются соответствующими областями работы.

  • Во-вторых, операторы могут рассмотреть уровни абстракции модулей YANG, чтобы понять, какие модули YANG для сетевого сервиса и элементов сети доступны при организации сервиса. Сложно определить тип модуля без проверки самого модуля YANG. Имя модуля может включать полезную информацию, но не является определенным ответом. Например, модуль YANG L2VPN5 может быть модулем сетевого сервиса, готовым для использования сетевым оператором в качестве модели сервиса. Однако он может быть и модулем YANG для элемента сети, который содержит определения данных L2VPN, требуемые для настройки конфигурации отдельного устройства.

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

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

Приведенные ниже термины определены в [RFC7950].

data model — модель данных

Модель данных описывает представление данных и доступ к ним.

module — модуль

Модуль YANG определяет иерархии узлов схемы. Со своими и импортированными или включенными из любого источника определениями модуль является самодостаточным и «компилируемым».

2. Уровни абстракции модулей YANG

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

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

Для разделения по уровням документ предлагает классифицировать модули YANG на 2 разных уровня абстракции.

  • Модули элементов сети (Network Element YANG Module) описывают конфигурацию, данные состояния, операции и уведомления конкретных технологий или функций, связанных с устройством.

  • Модули сетевого сервиса (Network Service YANG Module) описывают конфигурацию, данные состояния, операции и уведомления абстрактного представления сервиса, реализованного в одном или множестве элементов сети.

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

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

Например, опыт IETF показывает, что создание полезных модулей Network Element YANG (например, для протоколов маршрутизации или коммутации) требует команд, включающих разработчиков с опытом реализации таких протоколов.

                +--------------------------+
                |     Системы поддержки    |
                |     операция и бизнеса   |
                |         (OSS и BSS)      |
                +--------------------------+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Модули YANG для сетевого сервиса

     +------------+      +-------------+      +-------------+
     |            |      |             |      |             |
     |  - L2VPN   |      |   - L2VPN   |      |    L3VPN    |
     |  - VPWS    |      |   - VPLS    |      |             |
     |            |      |             |      |             |
     +------------+      +-------------+      +-------------+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Модули YANG для элементов сети

+------------+  +------------+  +-------------+  +------------+
|            |  |            |  |             |  |            |
|    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
|            |  |            |  |             |  |            |
+------------+  +------------+  +-------------+  +------------+

  L2VPN - виртуальная частная сеть L2
  L3VPN - виртуальная частная сеть L3
  VPWS - виртуальный частный провод
  VPLS - виртуальная частная ЛВС

Рисунок 1. Абстрактные уровни модулей YANG.


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

2.1. Модули YANG для сетевого сервиса

Модули YANG для сетевого сервиса описывают характеристики сервиса, согласуемые с потребителями услуг. Сервисный модуль не раскрывает детально параметры конфигурации всех участвующих элементов и функций, но описывает абстрактную модель, которая позволяет разобрать экземпляр сервиса на экземпляры данных по модулям Network Element YANG участвующих в сервисе элементов сети. Декомпозиция сервиса по элементам является отдельным процессом, детали которого зависят от выбранной оператором реализации услуг. В этом документе системы, реализующие такой процесс, называются оркестраторами (orchestrator).

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

YANG позволяет использовать разные шаблоны для описания сетевого сервиса — от монолитных до компонентных.

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

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

Например, сервис L2VPN может быть организован на основе множества технологий транспортных сетей, включая MPLS и Carrier Ethernet. Компонентный подход позволит применять определения интерфейсов между пользователем и сетью (UNI9), такие как MEF UNI или MPLS, независимо от базовой транспортной сети. При монолитном подходе нужно будет разрабатывать модули для конкретной комбинации транспорта и определений интерфейсов.

Пример модуля Network Service YANG содержится в [RFC8049], где представлена абстрактная модель конфигурации сервиса L3 IP VPN. Этот модуль включает концепцию доступа сайта в сеть (site-network-access) для представления параметров физического соединения. Оркестратор принимает операции над экземплярами сервиса в соответствии с модулем сервиса и разбирает данные в параметры конфигурации в соответствии с модулями Network Element YANG для настройки участвующих в сервисе элементов сети. В случае L3VPN параметры site-network-access будут транслироваться в параметры модулей Network Element YANG для соответствующих элементов.

2.2. Модули YANG для элементов сети

Модули Network Element YANG описывают характеристики сетевых устройств в соответствии с определениями производителей этих устройств. Модули обычно структурированы по функциям устройства. Например, конфигурация интерфейсов [RFC7223], конфигурация OSPF [OSPF-YANG], конфигурация ACL10 [ACL-YANG].

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

3. Происхождение модуля YANG

Документ предлагает классифицировать модули YANG по типу их происхождения — стандартные (Standard) модули, фирменные (Vendor-Specific) модули и расширения, пользовательские (User-Specific) модули и расширения.

Предложенная классификация применима как для модулей Network Element YANG так и для Network Service YANG.

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

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

+----------------+
|Пользовательские|
|   расширения   |
+-------+--------+
    Дополнения
+-------+--------+  +----------------+  +----------------+
|   Фирменные    |  |Пользовательские|  |Пользовательские|
|   расширения   |  |   расширения   |  |   расширения   |
+-------+--------+  +-------+--------+  +-------+--------+
   Дополнения         Дополнения          Дополнения
+-------+-------------------+--------+  +-------+--------+  +----------------+
|            Стандартные             |  |   Фирменные    |  |Пользовательские|
|              модули                |  |     модули     |  |     модули     |
+------------------------------------+  +----------------+  +----------------+

Рисунок 2. Варианты происхождения модулей YANG.

3.1. Стандартные модули YANG

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

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

Примерами SDO в сетевой отрасли могут служить IETF и IEEE.

3.2. Фирменные модули YANG и расширения

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

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

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

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

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

3.3. Пользовательские модули YANG и расширения

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

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

Жизненный цикл таких модулей обычно связан с изменениями в инфраструктуре.

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

Документ не связан с какими-либо вопросами безопасности.

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

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

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

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

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

[RFC7223] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>.

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

[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8049, DOI 10.17487/RFC8049, February 2017, <http://www.rfc-editor.org/info/rfc8049>.

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

[ACL-YANG] Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, «Network Access Control List (ACL) YANG Data Model», Work in Progress, draft-ietf-netmod-acl-model-1111, June 2017.

[IESG-Statement] «Writable MIB Module IESG Statement», <https://www.ietf.org/iesg/statement/writable-mib-module.html>.

[OSPF-YANG] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, «Yang Data Model for OSPF Protocol», Work in Progress, draft-ietf-ospf-yang-0812, July 2017.

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

Спасибо David Ball и Jonathan Hansford за отклики и предложения.

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

Dean Bogdanovic

Volta Networks, Inc.

Email: dean@voltanet.io

Benoit Claise

Cisco Systems, Inc.

De Kleetlaan 6a b1

1831 Diegem

Belgium

Phone: +32 2 704 5622

Email: bclaise@cisco.com

Carl Moberg

Cisco Systems, Inc.

Email: camoberg@cisco.com

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

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

nmalykh@protocols.ru

1Standards development organization.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

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

5Layer 2 Virtual Private Network — виртуальная частная сеть L2.

6Operations Support System — система поддержки операций.

7Business Support System — система поддержки бизнеса.

8VPN Routing and Forwarding — маршрутизация и пересылка VPN.

9User-Network Interface.

10Access control list — список управления доступом.

11Доступна более свежая версия документа — https://tools.ietf.org/html/draft-ietf-netmod-acl-model-21. Прим. перев.

12Доступна более свежая версия документа — https://tools.ietf.org/html/draft-ietf-ospf-yang-21. Прим. перев.




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. Дополнительную информацию о стандартах Internet можно найти в разделе 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 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 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). Прим. перев.