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

RFC 6996 Autonomous System (AS) Reservation for Private Use

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

Internet Engineering Task Force (IETF)                       J. Mitchell
Request for Comments: 6996                         Microsoft Corporation
BCP: 6                                                         July 2013
Updates: 1930
Category: Best Current Practice
ISSN: 2070-1721

Резервирование автономных систем (AS) для частных приложений

Autonomous System (AS) Reservation for Private Use

PDF

Аннотация

В этом документе описано резервирование номеров автономных систем (ASN¹), предназначенных лишь для частного применения (Private Use), которые называют Private Use ASN, и приведены рекомендации по их использованию. Документ расширяет пространство Private Use ASN, задавая выделение второго, более крупного блока и обновляет RFC 1930 путем замены раздела 10 в нем.

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

Документ относится к категории Internet Best Current Practice (обмен опытом).

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

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

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

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

1. Введение

Исходное резервирование агентством IANA номеров автономных систем (ASN) для частных приложений включало блок из 1023 ASN. Это резервирование было документировано IETF в разделе 10 [RFC1930]. Поскольку за время, прошедшее с момента этого резервирования, область использования протокола BGP⁴ [RFC4271] существенно расширилась, потребовалось расширение пространства AS для частного использования.

Документ «BGP Support for Four-Octet Autonomous System (AS) Number Space» [RFC6793] существенно расширил общий размер пространства ASN. В результате расширилось и пространство, доступное сетевым операторам для использования в частных приложениях. Имеющееся пространство ASN для частного использования применяется достаточно широко и возможность изменения этого ресурса в существующих сетях невозможно скоординировать, поскольку эти ASN по определению не регистрируются. Поэтому данный RFC документирует имеющееся резервирование Private Use ASN, добавляя к нему более крупный блок, который также может использоваться.

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

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

3. Частное использование ASN

Для обеспечения возможности расширения использования протокола BGP в новых сетевых приложениях с приватными ASN, в разделе 5 зарезервированы два диапазона ASN. Первый является частью исходного диапазона 16-битовых номеров AS, который уже был определен в [RFC1930], а второй, более крупный блок взят из пространства 4-октетных номеров AS[RFC6793].

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

Если используются частные ASN и из этих AS анонсируются префиксы, Private Use ASN должны удаляться из атрибутов пути AS (включая AS4_PATH при использовании 4-октетных номеров AS) до анонсирования в глобальную сеть Internet. Операторам следует обеспечивать на всех узлах EBGP⁵ поддержку расширений [RFC6793] и определяемые реализацией функции, которые распознают обновление Private Use ASN и понимают оба диапазона, прежде чем начать использование частных ASN в пространстве 4-октетных номеров AS. Некоторые из имеющихся реализаций, которые удаляют частные ASN из AS_PATH, не удаляют Private Use ASN, если AS_PATH содержит комбинацию приватных и публичных ASN. Если такая реализация не будет обновлена для поддержки нового блока частных ASN и в AS4_PATH будут присутствовать старые и новые частные ASN, реализация скорей всего не удалит никакие Private Use ASN из атрибутов пути AS. Может также использоваться обычная фильтрация путей AS для предотвращения анонсов из частных ASN в глобальную сеть Internet.

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

Агентство IANA зарезервировало для частных применений (Private Use) непрерывный блок из 1023 номеров автономных систем из реестра 16-bit Autonomous System Numbers, а именно номера 64512 — 65534, включительно.

Агентство IANA также зарезервировало для частных применений непрерывный блок из 94 967 295 номеров AS из реестра 32-bit Autonomous System Numbers, а именно номера 4200000000 — 4294967294 включительно.

Эти зарезервированные номера включены в реестр IANA «Autonomous System (AS) Numbers» [IANA.AS].

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

С частными номерами AS не связано особых проблем безопасности. В результате ненадлежащего использования номеров могут возникать потери связности, особенно при использовании номеров за пределами сети организации, поскольку эти номера не уникальны в глобальном масштабе. Эти проблемы возникают в рамках организации, использующей частные ASN некорректно или без учета информации, представленной в разделе 4. Общие вопросы безопасности BGP рассмотрены в [RFC4271] и [RFC4272]. Идентификация источника маршрута с Private Use ASN в пути AS может быть выполнена путем отслеживания маршрута а направлении соседней AS с публичным номером или путем проверки других атрибутов.

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

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

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

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

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, December 2012.

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

[IANA.AS] IANA, «Autonomous System (AS) Numbers», <http://www.iana.org/assignments/as-numbers/>.

[RFC1930] Hawkinson, J. and T. Bates, «Guidelines for creation, selection, and registration of an Autonomous System (AS)», BCP 6, RFC 1930, March 1996.

[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, January 2006.

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

Автор благодарит Christopher Morrow, Jason Schiller и John Scudder за их советы по части способа представления этих изменений. Автор также признателен Brian Dickson, David Farmer, Jeffrey Haas, Nick Hilliard, Joel Jaeggli, Warren Kumari, и Jeff Wheeler за их комментарии и предложения.

Адрес автора

Jon Mitchell

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

USA

EMail: Jon.Mitchell@microsoft.com

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

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

nmalykh@gmail.com

1Autonomous System Number.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

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

5External Border Gateway Protocol — внешний BGP.

Рубрика: RFC | Комментарии отключены

RFC 6991 Common YANG Data Types

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

Internet Engineering Task Force (IETF)             J. Schoenwaelder, Ed.
Request for Comments: 6991                             Jacobs University
Obsoletes: 6021                                                July 2013
Category: Standards Track
ISSN: 2070-1721

Common YANG Data Types

Типы данных YANG общего назначения

PDF

Аннотация

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

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

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

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

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

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

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

1. Введение

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

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

Этот документ добавляет определения новых типов данных и отменяет действие [RFC6021]. Подробности приведены в операторах revision модулей YANG (разделы 3 и 4), а различия между документами описаны в Приложении A.

2. Обзор

В этом разделе представлен краткий обзор типов данных, определённых в последующих разделах, и их эквивалентов в SMIv2⁴ [RFC2578][RFC2579]. Тип данных YANG считается эквивалентным типу данных SMIv2, если их семантика и набор значений эквивалентны.

В таблице 1 перечислены типы данных, определённые в модуле ietf-yang-types, и соответствующие типы SMIv2 (- указывает отсутствие соответствующего типа в SMIv2).

Таблица 1. Модуль ietf-yang-types.

Тип YANG	Эквивалентный тип SMIv2 (модуль)
counter32	Counter32 (SNMPv2-SMI)
zero-based-counter32	ZeroBasedCounter32 (RMON2-MIB)
counter64	Counter64 (SNMPv2-SMI)
zero-based-counter64	ZeroBasedCounter64 (HCNUM-TC)
gauge32	Gauge32 (SNMPv2-SMI)
gauge64	CounterBasedGauge64 (HCNUM-TC)
object-identifier	—
object-identifier-128	OBJECT IDENTIFIER
yang-identifier	—
date-and-time	—
timeticks	TimeTicks (SNMPv2-SMI)
timestamp	TimeStamp (SNMPv2-TC)
phys-address	PhysAddress (SNMPv2-TC)
mac-address	MacAddress (SNMPv2-TC)
xpath1.0	—
hex-string	—
uuid	—
dotted-quad	—

В таблице 2 перечислены типы данных, определённые в модуле ietf-inet-types, и соответствующие типы SMIv2 (если они имеются).

Таблица 2. Модуль ietf-inet-types.

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

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

Модуль YANG ietf-yang-types ссылается на [IEEE802], [ISO9834-1], [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502], [RFC6020], [XPATH], [XSD-TYPES].

   <CODE BEGINS> file "ietf-yang-types@2013-07-15.yang"

   module ietf-yang-types {

     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
     prefix "yang";

     organization
      "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
      "WG Web:   <http://tools.ietf.org/wg/netmod/> 
       WG List:  <mailto:netmod@ietf.org> 

       WG Chair: David Kessens <mailto:david.kessens@nsn.com> 
       WG Chair: Juergen Schoenwaelder
                 <mailto:j.schoenwaelder@jacobs-university.de> 

       Editor:   Juergen Schoenwaelder
                 <mailto:j.schoenwaelder@jacobs-university.de>"; 

     description
      "Этот модуль содержит набор производных типов данных YANG 
       общего назначения.

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

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

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

     revision 2013-07-15 {
       description
        "В этом выпуске добавлены новые типы данных:
         - yang-identifier
         - hex-string
         - uuid
         - dotted-quad";
       reference
        "RFC 6991: Common YANG Data Types";
     }

     revision 2010-09-24 {
       description
        "Исходный выпуск.";
       reference
        "RFC 6021: Common YANG Data Types";
     }

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

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

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

         Набор значений и семантика этого типа эквивалентны типу
         Counter32 в SMIv2.";
       reference
        "RFC 2578: Structure of Management Information Version 2
                   (SMIv2)";
     }
     typedef zero-based-counter32 {
       type yang:counter32;
       default "0";
       description
        "Тип zero-based-counter32 представляет counter32 с начальным
         значением 0. Узел схемы этого типа будет устанавливаться в 0
         при создании и далее будет монотонно расти до максимального 
         значения 2^32-1 (десятичное число 4294967295), затем 
         обращаться в 0 с последующим монотонным ростом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

         Этот тип является надмножеством типа SMIv2 OBJECT IDENTIFIER,
         поскольку не ограничен пределом в 128 субидентификаторов.
         Поэтому данный тип НЕ СЛЕДУЕТ применять для представления 
         SMIv2 OBJECT IDENTIFIER, взамен СЛЕДУЕТ использовать тип
         object-identifier-128.";
       reference
        "ISO9834-1: Information technology -- Open Systems
         Interconnection -- Procedures for the operation of OSI
         Registration Authorities: General procedures and top
         arcs of the ASN.1 Object Identifier tree";
     }

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

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

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

          Идентификаторам YANG НЕДОПУСТИМО начинаться с символов
          xml в любой комбинации строчных и прописных букв.";
       reference
         "RFC 6020: YANG - A Data Modeling Language for the Network
                    Configuration Protocol (NETCONF)";
     }

     /*** Набор типов, связанных с датами и временем ***/
     typedef date-and-time {
       type string {
         pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
               + '(Z|[\+\-]\d{2}:\d{2})';
       }
       description
        "Тип date-and-time является профилем стандарта ISO 8601
         для представления дат и времени с использованием григорианского
         календаря. Профиль определён date-time в параграфе 5.6 RFC 3339.

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

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

         (b) В типа date-and-time time-offset -00:00 указывает 
             неизвестный часовой пояс (RFC 3339), тогда как -00:00, 
             +00:00 и Z представляют такой же часовой пояс в dateTime.

         (c) Канонический формат (см. ниже) значений date-and-time 
             отличается от канонического формата типа dateTime XML,
             которые требует указания времени в UTC с использованием
             смещения 'Z'.

         Этот тип не эквивалентен текстовому соглашению DateAndTime 
         в SMIv2, поскольку RFC 3339 использует другой разделитель 
         между full-date и full-time, а также обеспечивает большую
         точность time-secfrac.
         Канонический формат для значений date-and-time с известным
         часовым поясом использует сдвиг часового пояса, который
         рассчитывается с использованием настроенного в устройстве 
         смещения от UTC. Смена смещения в устройстве меняет значение
         date-and-time должным образом. Такие изменения могут быть
         периодическими в результате перехода на летнее время (DST).
         Канонический формат для значений  date-and-time с
         неизвестным часовым поясом (обычно это называют местным
         временем) использует смещение -00:00.";
       reference
        "RFC 3339: Date and Time on the Internet: Timestamps
         RFC 2579: Textual Conventions for SMIv2
         XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
     }

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

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

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

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

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

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

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

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

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

     /*** Набор относящихся к XML типов ***/
     typedef xpath1.0 {
       type string;
       description
        "Этот тип представляет выражение XPATH 1.0.

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

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

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

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

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

4. Связанные с Internet производные типы

Модуль YANG ietf-inet-types ссылается на [RFC0768], [RFC0791], [RFC0793], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2460], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], [RFC4960], [RFC5017], [RFC5890], [RFC5952], [RFC6793].

   <CODE BEGINS> file "ietf-inet-types@2013-07-15.yang"

   module ietf-inet-types {

     namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
     prefix "inet";

     organization
      "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
      "WG Web:   <http://tools.ietf.org/wg/netmod/> 
       WG List:  <mailto:netmod@ietf.org> 

       WG Chair: David Kessens <mailto:david.kessens@nsn.com> 

       WG Chair: Juergen Schoenwaelder
                 <mailto:j.schoenwaelder@jacobs-university.de> 

       Editor:   Juergen Schoenwaelder
                 <mailto:j.schoenwaelder@jacobs-university.de>"; 

     description
      "Этот модуль содержит набор производных типов данных YANG 
       для адресов Internet и связанных элементов.

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

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

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

     revision 2013-07-15 {
       description
        "В этом выпуске добавлены новые типы данных:
         - ip-address-no-zone
         - ipv4-address-no-zone
         - ipv6-address-no-zone";
       reference
        "RFC 6991: Common YANG Data Types";
     }

     revision 2010-09-24 {
       description
        "Исходный выпуск.";
       reference
        "RFC 6021: Common YANG Data Types";
     }

     /*** Набор типов, связанных с протокольными полями ***/
     typedef ip-version {
       type enumeration {
         enum unknown {
           value "0";
           description
            "Неизвестная или не указанная версия протокола IP.";
         }
         enum ipv4 {
           value "1";
           description
            "Протокол IPv4 в соответствии с RFC 791.";
         }
         enum ipv6 {
           value "2";
           description
            "Протокол IPv6 в соответствии с RFC 2460.";
         }
       }
       description
        "Это значение представляет версию протокола IP.

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

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

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

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

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

     typedef port-number {
       type uint16 {
         range "0..65535";
       }
       description
        "Тип port-number представляет 16-битовый номер порта протоколов
         транспортного уровня Internet, таких как UDP, TCP, DCCP, SCTP.
         Номера портов распределяются IANA. Текущий список выделенных
         портов доступен на сайте <http://www.iana.org/>. 

         Отметим, что номер 0 зарезервирован IANA.  В ситуациях, где
         нулевое значение не имеет смысла, оно может быть исключено
         путём создания субтипа для port-number без 0. 
         Набор значений и семантика для этого типа эквивалентны 
         текстовому соглашению InetPortNumber в SMIv2.";
       reference
        "RFC  768: User Datagram Protocol
         RFC  793: Transmission Control Protocol
         RFC 4960: Stream Control Transmission Protocol
         RFC 4340: Datagram Congestion Control Protocol (DCCP)
         RFC 4001: Textual Conventions for Internet Network Addresses";
     }

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

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

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

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

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

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

          Каноническим форматом для индекса зоны является числовой
          формат.";
     }

     typedef ipv6-address {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(%[\p{N}\p{L}]+)?';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(%.+)?';
       }
       description
        "Тип ipv6-address представляет адрес IPv6 в полной, смешанной
         сокращённой или сокращённой смешанной нотации. Адрес IPv6
         может включать индекс зоны, отделённый символом %.
         Индекс зоны служит для того, чтобы различать идентичные
         значения адресов. Для адресов link-local индексом зоны
         обычно служит индекс или имя интерфейса. Если индекса зоны
         нет, будет применяться принятая по умолчанию зона устройства.

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

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

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

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

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

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

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

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

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

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

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

     /*** Набор типов для доменных имён и URI ***/
     typedef domain-name {
       type string {
         pattern
           '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
         + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
         + '|\.';
         length "1..253";
       }
       description
        "Тип domain-name представляет доменные имена DNS.
         По возможности СЛЕДУЕТ применять полные имена (FQDN⁵). 

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

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

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

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

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

     typedef uri {
       type string;
       description
        "Тип uri представляет идентификаторы URI⁶, определённые в STD 66.

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

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

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

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

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

   }

   <CODE ENDS>

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

Этот документ регистрирует два URI в реестре IETF XML [RFC3688]. В соответствии с форматом RFC 3688 были сделаны приведённые ниже регистрации.

     URI: urn:ietf:params:xml:ns:yang:ietf-yang-types
     Registrant Contact: The NETMOD WG of the IETF.
     XML: N/A, запрошенный URI является пространством имен XML.

     URI: urn:ietf:params:xml:ns:yang:ietf-inet-types
     Registrant Contact: The NETMOD WG of the IETF.
     XML: N/A, запрошенный URI является пространством имен XML.

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

     name:         ietf-yang-types
     namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-types
     prefix:       yang
     reference:    RFC 6991

     name:         ietf-inet-types
     namespace:    urn:ietf:params:xml:ns:yang:ietf-inet-types
     prefix:       inet
     reference:    RFC 6991

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

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

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

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

Andy Bierman (Brocade)
Martin Bjorklund (Tail-f Systems)
Balazs Lengyel (Ericsson)
David Partain (Ericsson)
Phil Shafer (Juniper Networks)

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

Редактор благодарит за полезные замечания к разным версиям этого документа Andy Bierman, Martin Bjorklund, Benoit Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman и Dan Romascanu.

Работу Juergen Schoenwaelder частично финансировал проект Flamingo в рамках Network of Excellence (ICT-318488), поддерживаемый Европейской комиссией по программе Seventh Framework.

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

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

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

[RFC3339] Klyne, G., Ed. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, July 2002.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, «IPv6 Scoped Address Architecture», RFC 4007, March 2005.

[RFC4122] Leach, P., Mealling, M., and R. Salz, «A Universally Unique IDentifier (UUID) URN Namespace», RFC 4122, July 2005.

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

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, October 2010.

[XPATH] Clark, J. and S. DeRose, «XML Path Language (XPath) Version 1.0», World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.

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

[IEEE802] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std. 802-2001, 2001.

[ISO9834-1] ISO/IEC, «Information technology — Open Systems Interconnection — Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree», ISO/IEC 9834-1:2008, 2008.

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, «DoD Internet host table specification», RFC 952, October 1985.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC1930] Hawkinson, J. and T. Bates, «Guidelines for creation, selection, and registration of an Autonomous System (AS)», BCP 6, RFC 1930, March 1996.

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

[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, December 1998.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2780] Bradner, S. and V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, March 2000.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, «Textual Conventions for Additional High Capacity Data Types», RFC 2856, June 2000.

[RFC3289] Baker, F., Chan, K., and A. Smith, «Management Information Base for the Differentiated Services Architecture», RFC 3289, May 2002.

[RFC3305] Mealling, M. and R. Denenberg, «Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations», RFC 3305, August 2002.

[RFC3595] Wijnen, B., «Textual Conventions for IPv6 Flow Label», RFC 3595, September 2003.

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

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

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, March 2006.

[RFC4502] Waldbusser, S., «Remote Network Monitoring Management Information Base Version 2», RFC 4502, May 2006.

[RFC4960] Stewart, R., «Stream Control Transmission Protocol», RFC 4960, September 2007.

[RFC5017] McWalter, D., «MIB Textual Conventions for Uniform Resource Identifiers (URIs)», RFC 5017, September 2007.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[RFC5952] Kawamura, S. and M. Kawashima, «A Recommendation for IPv6 Address Text Representation», RFC 5952, August 2010.

[RFC6021] Schoenwaelder, J., «Common YANG Data Types», RFC 6021, October 2010.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, December 2012.

[XSD-TYPES] Biron, P. and A. Malhotra, «XML Schema Part 2: Datatypes Second Edition», World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

Приложение A. Отличия от RFC 6021

В этой версии добавлены новые определения типов для модулей YANG. Ниже перечислены типы, добавленные в модуль ietf-yang-types.

yang-identifier
hex-string
uuid
dotted-quad

Ниже перечислены типы, добавленные в модуль ietf-inet-types.

ip-address-no-zone
ipv4-address-no-zone
ipv6-address-no-zone

Адрес автора

Juergen Schoenwaelder (редактор)

Jacobs University

EMail: j.schoenwaelder@jacobs-university.de

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

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

nmalykh@proto k ols.ru

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

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

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

4Structure of Management Information Version 2 — структура данных управления, версия 2.

5Fully qualified domain name.

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

Рубрика: RFC | Комментарии отключены

RFC 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension

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

Отменен RFC 8446

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

RFC 6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library

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

Internet Engineering Task Force (IETF)                           W. Wang
Request for Comments: 6956                 Zhejiang Gongshang University
Category: Standards Track                                  E. Haleplidis
ISSN: 2070-1721                                     University of Patras
                                                                K. Ogawa
                                                         NTT Corporation
                                                                   C. Li
                                                         Hangzhou DPtech
                                                              J. Halpern
                                                                Ericsson
                                                               June 2013

Библиотека логических функциональных блоков ForCES

Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library

PDF

Аннотация

Этот документ определяет базовые классы для логических функциональных блоков (LFB¹) используемых в ForCES². Базовые классы LFB определяются в соответствии с моделью элемента пересылки ForCES (FE³) и спецификацией протокола ForCES. Они привязаны к выполнению типовых функций маршрутизации и образуют базовую библиотеку LFB для ForCES. Библиотека включает описания LFB и определения XML.

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

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

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

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

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

1. Введение

[RFC3746] определяет модель разделения элементов управления и пересылки ForCES. В этой модели элементы управления CE (Control Element) настраивают и поддерживают один или множество элементов пересылки FE (Forwarding Element) внутри сетевого элемента NE (Network Element) с помощью протокола ForCES, спецификация которого приведена в [RFC5810]. Модель элемента пересылки определена в [RFC5812]. В этой модели ресурсы FE описываются классами логических функциональных блоков LFB. Модель FE определяет структуру и абстрактную семантику LFB, а также предоставляет схему XML для определения LFB.

Этот документ соответствует спецификации модели FE [RFC5812] и задает детальные определения классов LFB, включая подробные XML-определения LFB. Эти LFB формируют базовую библиотеку LFB для ForCES. Предполагается, что LFB в базовой библиотеке комбинируются для формирования топологии LFB в типовом маршрутизаторе для реализации пересылки IP. Следует подчеркнуть, что LFB является абстракцией функций и не включает деталей реализации. Целью определения LFB является представление функций для обеспечения взаимодействия между различными элементами CE и FE.

В будущем могут быть разработаны новые классы LFB с новыми функциями, которые будут документированы IETF. Производители также могут создавать фирменные LFB, как описано в модели FE [RFC5812].

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

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

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

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

Этот документ следует терминологии, определенной протоколом ForCES в [RFC5810] и моделью ForCES FE в [RFC5812]. Ниже определения терминов повторены для удобства.

Control Element (CE) — элемент управления

Логический объект, который реализует протокол ForCES и инструктирует один или множество FE по части обработки пакетов. Функциональность CE включает исполнение протоколов управления и сигнализации.

Forwarding Element (FE) — элемент пересылки

Логический элемент, реализующий протокол ForCES. Элементы FE используют базовое оборудование для обработки каждого пакета и управляются (контролируются) одним или множеством CE по протоколу ForCES.

ForCES Network Element (NE) — элемент сети ForCES

Объект, состоящий из одного или множества CE и одного или множества FE. Для внешних наблюдателей NE представляется единой точкой управления и скрывает свою внутреннюю структуру от внешних наблюдателей.

Logical Function Block (LFB) — логический функциональный блок

Базовый блок, с которым работает протокол ForCES. LFB — это четко определенный, логически разделяемый функциональный блок, который размещается в FE и управляется CE по протоколу ForCES. LFB может размещаться в пути данных FE и обрабатывать потоки, а может быть чистым объектом управления и настройки FE, с которым работает CE. Отметим, что LFB является функционально точной абстракцией возможностей обработки FE, а не точным аппаратным представлением реализации FE.

FE Model — модель FE

Модель FE разработана для представления логических функций обработки элемента FE, как определено в модели ForCES FE [RFC5812]. Предложенная в этом документе модель FE включает три компоненты — модели LFB для отдельных блоков LFB (модель LFB), логических соединений между LFB (топология LFB) и атрибутов уровня FE, включая возможности FE. Модель FE обеспечивает основу для определения информационных элементов, передаваемых между CE и FE по протоколу ForCES [RFC5810].

FE Topology — топология FE

Представление соединений между множеством FE в одном NE. Иногда это называют внешней топологией FE, чтобы отличать от внутренней топологии FE (т. е. топологии LFB).

LFB Class and LFB Instance — класс и экземпляр LFB

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

LFB Meta Data — метаданные LFB

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

LFB Component — компонента LFB

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

LFB Topology — топология LFB

Представление логических связей между экземплярами LFB и их размещения в пути данных внутри одного элемента FE. Иногда используется термин «внутренняя топология FE», но не следует путать ее с топологией соединений между FE (inter-FE topology).

Data Path — путь (передачи) данных

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

ForCES Protocol — протокол ForCES

Хотя в рамках архитектуры ForCES может применяться множество протоколов, термины «протокол ForCES» и «протокол» относятся к опорным точкам Fp в модели ForCES [RFC3746]. Этот протокол не применяется к взаимодействиям между элементами CE, а также между элементами FE или между менеджерами FE и CE. В базовом варианте протокол ForCES работает в режиме «ведущий-ведомый» (master-slave), где элементы FE являются ведомыми, а CE — ведущими.

Physical Port — физический порт

Входной или выходной порт FE, соединенный с физической средой передачи. Физическим портам обычно назначаются идентификаторы, обозначаемые в форме PHYPortID. В этом документе в основном рассматриваются физические порты Ethernet.

Logical Port — логический порт

Виртуальный порт на канальном (L2) или сетевом (L3) уровне. Логическим портам обычно назначаются идентификаторы, обозначаемые LogicalPortID. Логические порты могут быть разделены по уровням L2 и L3. Логическому порту L2 может быть назначен идентификатор вида L2PortID, а логическому порту L3 — L3PortID. Порты VLAN уровня MAC относятся к логическим портам уровня L2.

LFB Port — порт LFB

Точка соединения, в которой один блок LFB может соединяться в другим внутри FE. Как указано в [RFC5812], элемент CE может соединять LFB между собой путем организации соединения между выходным портом одного экземпляра LFB и входным портом другого экземпляра. Более подробно это описано в параграфе 3.2 [RFC5812].

Singleton Port — одиночный порт

Именованный входной или выходной порт LFB. Такие порты указываются по именам. Когда контекст это позволяет, термин «одиночный» (singleton) используется для указания одиночного порта.

Group Port — групповой порт

Именованный набор входных или выходных портов LFB. Групповые порты указываются по именам. Групповой порт состоит из множества экземпляров портов, которые указываются комбинацией имени и индекса (номера).

LFB Class Library — библиотека классов LFB

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

3. Обзор

3.1. Область действия библиотеки

Предполагается, что описанные здесь классы LFB предназначены для выполнения функций типичного маршрутизатора. В [RFC1812] указано, что типичный маршрутизатор должен выполнять перечисленные ниже функции.

Интерфейс в пакетные сети и реализацию функций, требуемых этими сетями. Эти функции обычно включают:

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

Соответствие протоколам Internet, включая IP (IPv4 и/или IPv6), ICMP⁷ и другие требуемые протоколы.
Прием и пересылка дейтаграмм IP управлением буферами, контролем перегрузки и беспристрастностью.

Распознавание ошибок и генерация сообщений ICMP и другой информации при необходимости.
Отбрасывание дейтаграмм с истекшим сроком жизни (TTL = 0).
Фрагментирование дейтаграмм при необходимости в соответствии со значением MTU на следующем канале или интерфейсе.

Выбор следующего интервала (next-hop) на пути к адресату для каждой дейтаграммы IP на основе данных из таблицы маршрутов.
Обычно поддержка протокола IGP⁸ для поддержки распределенной маршрутизации и алгоритмов определения доступности с другими маршрутизаторами в своей автономной системе. В дополнение к этому некоторые маршрутизаторы должны поддерживать протокол EGP⁹ для обмена топологической информацией с другими автономными системами. Для всех маршрутизаторов важна возможность поддержки таблицы статических маршрутов.
Поддержка сетевого управления и системных функций, включая загрузку, отладку, отчеты о состоянии, запросы статистики, отчеты об исключительных ситуациях и управление.

Классический маршрутизатор IP, использующий схему ForCES, представляет собой CE, на котором работает управляющая функция IGP и/или EGP или некий набор статических маршрутов, а FE реализуются с помощью LFB, соответствующих спецификации модели FE [RFC5812]. CE в соответствии с протоколом ForCES [RFC5810] и моделью FE [RFC5812] указывает блокам LFB в FE способы обработки принимаемых и передаваемых пакетов.

Пакеты в маршрутизаторах IP принимаются и передаются в физическую среду через устройство, обычно называемое портом. Разные физические среду используют разные способы для инкапсуляции исходящих кадров и декапсуляции входящих. У различных сред будут также разные атрибуты, влияющие на поведение среды и инкапсуляцию-декапсуляцию кадров. В этом документе рассматриваются лишь физические среды Ethernet, а в будущем могут быть описаны и другие варианты. В этом документе портом называется также абстракция, включающая физический уровень (PHY) и уровень MAC¹⁰, которые описываются LFB EtherPHYCop, EtherMACIn и EtherMACOut.

Пакеты IP выходят из портов LFB и затем обрабатываются проверочными LFB до пересылки следующему LFB. После проверки пакет передается блоку LFB, где принимается решение о пересылке IP. В LFB пересылки IP применяются Longest Prefix Match LFB для поиска информации о получателе в пакете и выбора следующего интервала (next-hop) пересылки в направлении адресата. Блок next-hop LFB использует метаданные next-hop для создания нужного заголовка пакета IP и передачи пакета в нужный выход. Отметим, что рассмотрение обработки пакета IP в этом документе основано на модели «слабого хоста» (weak-host) [RFC1122], поскольку она лучше всего подходит для обработки пакетов в NE.

3.2. Обзор классов LFB в библиотеке

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

3.2.1. Варианты устройства LFB

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

Если функцию можно реализовать в одном или нескольких LFB, выбирался вариант с несколькими LFB для повышения уровня гибкости.
В LFB следует максимально использовать независимость и минимальные привязки к другим LFB. Связывание LFB может задаваться определениями атрибутов, а также физическими реализациями.
При отсутствии явных различий в функциональности аналогичную обработку пакетов не следует представлять одновременно в нескольких LFB базовой библиотеки. Например, не следует определять два разных LFB для одной обработки next-hop, поскольку это будет осложнять совместимость и взаимодействие реализаций.

3.2.2. Группировки классов LFB

Этот документ определяет группы LFB в соответствии с потребностями типового маршрутизатора.

Группа LFB для обработки Ethernet определяется для абстрагирования обработки пакетов в средах Ethernet. Поскольку Ethernet является наиболее распространенным типом сред передачи с широкими возможностями обработки, эта группа LFB является логичным и естественным выбором. Определения обработки для портов иных типов сред, таких как POS¹¹ и ATM¹² могут быть добавлены в будущую версию документа или в отдельные документы. Для обработки Ethernet определены несколько LFB:

EtherPHYCop (параграф 5.1.1)
EtherMACIn (параграф 5.1.2)
EtherClassifier (параграф 5.1.3)
EtherEncap (параграф 5.1.4)
EtherMACOut (параграф 5.1.5)

Определена группа LFB для проверки пакетов IP:

IPv4Validator (параграф 5.2.1)
IPv6Validator (параграф 5.2.2)

Определена группа LFB для абстрагирования пересылки IP:

IPv4UcastLPM (параграф 5.3.1)
IPv4NextHop (параграф 5.3.2)
IPv6UcastLPM (параграф 5.3.3)
IPv6NextHop (параграф 5.3.4)

Определена группа LFB для абстрагирования перенаправления, т. е. пересылки пакетов между CE и FE:

RedirectIn (параграф 5.4.1)
RedirectOut (параграф 5.4.2)

Определена группа LFB для абстрагирования некоторых операций обработки общего назначения, которые обычно выполняются во многих местах топологии FE LFB:

BasicMetadataDispatch (параграф 5.5.1)
GenericScheduler (параграф 5.5.2)

3.2.3. Sample LFB Class Application

Хотя в разделе 7 будут представлены примеры использования LFB, определенных в этом документе, этот параграф также содержит простой пример использования класса LFB.

На рисунке 1 показан простой блок LFB для пути обработки пакетов Ethernet, приходящих из физических портов.

+-----+                +------+
|     |EtherPHYIn      |      |            от LFB, создающих
|     |<---------------|Ether |<---------- пакеты Ethernet
|     |                |MACOut|            
|     |                | LFB  |
|Ether|                +------+
|PHY  |                +------+
|Cop  |                |      |
|LFB  |EtherPHYOut     | Ether|            в LFB, которые  могут
|     |--------------->| MACIn|----------> классифицировать пакеты
|     |                |  LFB |            Ethernet и выполнять
|     |                |      |            обработку IP
+-----+                +------+

Рисунок 1. Простой пример использования Sample LFB.

На этом рисунке пакеты Ethernet из внешних сетей приходят через EtherPHYCop LFB (параграф 5.1.1), описывающий свойства электрического интерфейса Ethernet (такие, как скорость) на физическом уровне. После обработки на физическом уровне пакеты Ethernet доставляются в EtherMACIn LFB (параграф 5.1.2) для описания функций обработки MAC-уровня (таких, как проверка локальности). После EtherMACIn LFB может потребоваться дополнительная обработка пакетов для реализации различных функций (таких, как пересылка IP), поэтому за EtherMACIn LFB в топологии могут следовать другие LFB, выполняющие такие функции.

Пакеты, созданные теми или иными LFB, может потребоваться передавать во внешние физические сети. Процесс описан на рисунке блоками EtherMACOut LFB (параграф 5.1.5) уровня MAC и EtherPHYCop LFB физического уровня.

3.3. Структура документа

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

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

Классы LFB окончательно определяются в XML со спецификациями и схемами, заданными в модели ForCES FE [RFC5812]. Раздел 6 содержит полные определения базовой библиотеки классов LFB.

В разделе 7 рассматриваются примеры реализации некоторых функций типового маршрутизатора на основе определенной в этом документе базовой библиотеки LFB.

4. Базовые типы

Модель FE [RFC5812] задает предопределенные (встроенные) неделимые (atomic) типы данных: char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], string, byte[N], boolean, octetstring[N], float16, float32 и float64.

Отметим, что в отличие от информационной модели SNMP¹³, называемой SMI¹⁴ [RFC2578], модель FE не определяет конкретных неделимых типов данных для целей учета. Для описания элементов LFB, относящихся к статистике пакетов, которым обычно нужны счетчики пакетов, приспособлены целые числа без знака, такие как uint32 или uint64. Этот документ указывает, что любой элемент LFB, определенный для целей подсчета, монотонно возрастает до достижения максимального значения, затем сбрасывается в 0 и снова монотонно возрастает. В документе также указано, что способы поддержки целочисленных элементов без знака может поддерживаться в случае разрыва или сброса счетчика определяются реализацией. Если предполагается, что CE придает значениям счетчиков больше смысла, чем указано выше, может потребоваться частное определение элемента между CE и FE.

На основе неделимых (atomic) типов данных можно определять типы кадров с пакетами, типы метаданных и новые типы данных с использованием элементов определения типов в схеме XML модели FE.

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

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

   <load library="BaseTypeLibrary" location="..."/>

4.1. Типы данных

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

4.1.1. Atomic

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

Имя	Описание
IPv4Addr	Адрес IPv4
IPv6Addr	Адрес IPv6
IEEEMAC	Адрес IEEE MAC
LANSpeedType	Скорость ЛВС
DuplexType	Режим дуплекса
PortStatusType	Возможные типы состояния порта (административного и рабочего)
VlanIDType	Идентификатор VLAN
VlanPriorityType	Приоритет VLAN
SchdDisciplineType	Дисциплина планирования

4.1.2. Структуры

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

Имя	Описание
EtherDispatchEntryType	Тип записи для таблицы диспетчеризации Ethernet
VlanInputTableEntryType	Тип записи для входной таблицы VLAN
EncapTableEntryType	Тип записи для таблицы инкапсуляции Ethernet
MACInStatsType	Тип статистики для EtherMACIn LFB
MACOutStatsType	Тип статистики для EtherMACOut LFB
EtherClassifyStatsType	Тип записи для таблицы статистики в EtherClassifier LFB
IPv4PrefixInfoType	Тип записи для таблицы префиксов IPv4
IPv6PrefixInfoType	Тип записи для таблицы префиксов IPv6
IPv4NextHopInfoType	Тип записи для таблицы next-hop IPv4
IPv6NextHopInfoType	Тип записи для таблицы next-hop IPv6
IPv4ValidatorStatsType	Тип статистики в IPv4validator LFB
IPv6ValidatorStatsType	Тип статистики в IPv6validator LFB
IPv4UcastLPMStatsType	Тип статистики в IPv4UcastLPM LFB
IPv6UcastLPMStatsType	Тип статистики в IPv6UcastLPM LFB
QueueStatsType	Тип записи для таблицы глубины очередей
MetadataDispatchType	Тип записи для таблицы диспетчеризации метаданных

4.1.3. Массивы

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

Имя	Описание
EtherClassifyStatsTableType	Тип для таблицы статистики классификатора Ethernet
EtherDispatchTableType	Тип для таблицы диспетчеризации Ethernet
VlanInputTableType	Тип для входной таблицы VLAN
EncapTableType	Тип для таблицы инкапсуляции Ethernet
IPv4PrefixTableType	Тип для таблицы префиксов IPv4
IPv6PrefixTableType	Тип для таблицы префиксов IPv6
IPv4NextHopTableType	Тип для таблицы next-hop IPv4
IPv6NextHopTableType	Тип для таблицы next-hop IPv6
MetadataDispatchTableType	Тип записи для таблицы глубины очередей
QueueStatsTableType	Тип записи для таблицы диспетчеризации метаданных

4.2. Типы кадров

В соответствии с моделью FE [RFC5812] типы кадров применяются в определениях LFB для задания пакетов, которые LFB ожидает на входных портах и передает в выходной. Для определения новых типов кадров служит элемент <frameDef> модели FE.

Определенные в базовой библиотеке типы кадров перечислены в таблице.

Имя	Описание
EthernetII	Кадр Ethernet II
ARP	Кадр с пакетом ARP
IPv4	Кадр с пакетом IPv4
IPv6	Кадр с пакетом IPv6
IPv4Unicast	Кадр с индивидуальным пакетом IPv4
IPv4Multicast	Кадр с групповым пакетом IPv4
IPv6Unicast	Кадр с индивидуальным пакетом IPv6
IPv6Multicast	Кадр с групповым пакетом IPv6
Arbitrary	Кадр с пакетом произвольного типа

4.3. Типы метаданных

Метаданные LFB служат для передачи связанных с пакетом состояний из одного блока LFB в другой. Для определения типов метаданных служит элемент <metadataDef> модели FE.

Определенные в базовой библиотеке типы метаданных перечислены в таблице.

Имя	Идентификатор	Описание
PHYPortID	1	Метаданные, указывающие идентификатор физического порта
SrcMAC	2	Метаданные, указывающие MAC-адрес отправителя
DstMAC	3	Метаданные, указывающие MAC-адрес получателя
LogicalPortID	4	Метаданные, указывающие идентификатор логического порта
EtherType	5	Метаданные, указывающие тип Ethernet
VlanID	6	Метаданные, указывающие идентификатор VLAN
VlanPriority	7	Метаданные, указывающие приоритет VLAN
NextHopIPv4Addr	8	Метаданные, указывающие адрес следующего интервала IPv4
NextHopIPv6Addr	9	Метаданные, указывающие адрес следующего интервала IPv6
HopSelector	10	Метаданные, указывающие селектор интервала
ExceptionID	11	Метаданные типов исключительных случаев при обработке LFB
ValidateErrorID	12	Метаданные типов ошибок при прохождении пакетом процесса проверки
L3PortID	13	Метаданные, указывающие идентификатор логического порта L3
RedirectIndex	14	Метаданные, которые CE передает в RedirectIn LFB, указывая пакет, связанный с индексом выходной группы портов LFB
MediaEncapInfoIndex	15	Ключ пакета при поиске в таблице LFB для выбора типа инкапсуляции

4.4. XML для библиотеки базовых типов

<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     provides="BaseTypeLibrary">
   <frameDefs>
      <frameDef>
         <name>EthernetAll</name>
         <synopsis>Пакет с любым типом Ethernet</synopsis>
      </frameDef>
      <frameDef>
         <name>EthernetII</name>
         <synopsis>Пакет типа Ethernet II</synopsis>
      </frameDef>
      <frameDef>
         <name>ARP</name>
         <synopsis>Пакет ARP</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv4</name>
         <synopsis>Пакет IPv4</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv6</name>
         <synopsis>Пакет IPv6</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv4Unicast</name>
         <synopsis>Индивидуальный пакет IPv4</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv4Multicast</name>
         <synopsis>Групповой пакет IPv4</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv6Unicast</name>
         <synopsis>Индивидуальный пакет IPv6</synopsis>
      </frameDef>
      <frameDef>
         <name>IPv6Multicast</name>
         <synopsis>Групповой пакет IPv6</synopsis>
      </frameDef>
      <frameDef>
         <name>Arbitrary</name>
         <synopsis>Любой тип пакета</synopsis>
      </frameDef>
   </frameDefs>
   <dataTypeDefs>
      <dataTypeDef>
         <name>IPv4Addr</name>
         <synopsis>Адрес IPv4</synopsis>
         <typeRef>byte[4]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6Addr</name>
         <synopsis>Адрес IPv6</synopsis>
         <typeRef>byte[16]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
         <name>IEEEMAC</name>
         <synopsis>Адрес IEEE MAC</synopsis>
         <typeRef>byte[6]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>LANSpeedType</name>
        <synopsis>Скорость ЛВС</synopsis>
        <atomic>
         <baseType>uint32</baseType>
         <specialValues>
           <specialValue value="0x00000000">
            <name>LAN_SPEED_NONE</name>
            <synopsis>Ничего не подключено</synopsis>
           </specialValue>
           <specialValue value="0x00000001">
            <name>LAN_SPEED_10M</name>
            <synopsis>10M Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000002">
            <name>LAN_SPEED_100M</name>
            <synopsis>100M Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000003">
            <name>LAN_SPEED_1G</name>
            <synopsis>1G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000004">
            <name>LAN_SPEED_10G</name>
            <synopsis>10G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000005">
            <name>LAN_SPEED_40G</name>
            <synopsis>40G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000006">
            <name>LAN_SPEED_100G</name>
            <synopsis>100G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000007">
            <name>LAN_SPEED_400G</name>
            <synopsis>400G Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000008">
            <name>LAN_SPEED_1T</name>
            <synopsis>1T Ethernet</synopsis>
           </specialValue>
           <specialValue value="0x00000009">
            <name>LAN_SPEED_OTHER</name>
            <synopsis>Другие скорости ЛВС</synopsis>
           </specialValue>
           <specialValue value="0x0000000A">
            <name>LAN_SPEED_AUTO</name>
            <synopsis>Автоматическое согласование скорости ЛВС</synopsis>
           </specialValue>
         </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>DuplexType</name>
        <synopsis>Тип режима дуплекса</synopsis>
        <atomic>
         <baseType>uint32</baseType>
         <specialValues>
           <specialValue value="0x00000001">
            <name>Auto</name>
            <synopsis>Автоматическое согласование</synopsis>
           </specialValue>
           <specialValue value="0x00000002">
            <name>HalfDuplex</name>
            <synopsis>Полудуплекс</synopsis>
           </specialValue>
           <specialValue value="0x00000003">
            <name>FullDuplex</name>
            <synopsis>Полный дуплекс</synopsis>
           </specialValue>
         </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>PortStatusType</name>
        <synopsis>
          Тип для состояния порта (административного и рабочего).
        </synopsis>
        <atomic>
         <baseType>uchar</baseType>
         <specialValues>
           <specialValue value="0">
            <name>Disabled</name>
            <synopsis>Порт отключен</synopsis>
           </specialValue>
           <specialValue value="1">
            <name>Up</name>
            <synopsis>Порт активен</synopsis>
           </specialValue>
           <specialValue value="2">
            <name>Down</name>
            <synopsis>Порт не активен</synopsis>
           </specialValue>
         </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>MACInStatsType</name>
         <synopsis>
           Тип данных для статистики в EtherMACIn LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>NumPacketsReceived</name>
               <synopsis>Число принятых пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>NumPacketsDropped</name>
               <synopsis>Число отброшенных пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>MACOutStatsType</name>
         <synopsis>
           Тип данных для статистики в EtherMACOut LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>NumPacketsTransmitted</name>
               <synopsis>Число переданных пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>NumPacketsDropped</name>
               <synopsis>Число отброшенных пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherDispatchEntryType</name>
         <synopsis>
           Тип данных для записи таблицы диспетчеризации Ethernet
           в EtherClassifier LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>LogicalPortID</name>
               <synopsis>Идентификатор логического порта</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>EtherType</name>
               <synopsis>Тип Ethernet в пакете Ethernet.</synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="3">
               <name>Reserved</name>
               <synopsis>
               Пространство резервных битов в основном для 
               заполнения и эффективной упаковки.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="4">
               <name>LFBOutputSelectIndex</name>
                <synopsis>
                  Индекс пакета для выбора экземпляра в группе 
                  выходных портов EtherClassifier LFB для вывода.
                </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherDispatchTableType</name>
         <synopsis>
           Тип данных, определенный для таблицы диспетчеризации Ethernet
           в EtherClassifier LFB. Таблица является массивом записей 
           с типом данных EtherDispatchEntryType.
         </synopsis>
         <array type="variable-size">
           <typeRef>EtherDispatchEntryType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>VlanIDType</name>
         <synopsis>Тип данных для VLAN ID</synopsis>
         <atomic>
         <baseType>uint16</baseType>
           <rangeRestriction>
              <allowedRange min="0" max="4095"/>
            </rangeRestriction>
         </atomic>
       </dataTypeDef>
      <dataTypeDef>
         <name>VlanPriorityType</name>
         <synopsis>Тип данных для приоритета VLAN</synopsis>
         <atomic>
         <baseType>uchar</baseType>
           <rangeRestriction>
              <allowedRange min="0" max="7"/>
           </rangeRestriction>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>VlanInputTableEntryType</name>
         <synopsis>
           Тип данных для записи входной таблицы VLAN в EtherClassifier
           LFB. Каждая запись содержит идентификатор входного порта,
           VLAN ID и идентификатор логического порта. Каждому входящему
           пакету назначается идентификатор логического порта в соответствии
           идентификатором входного порта и VLAN ID.
           </synopsis>
         <struct>
            <component componentID="1">
               <name>IncomingPortID</name>
               <synopsis>Идентификатор входного порта</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>VlanID</name>
               <synopsis>Идентификатор VLAN</synopsis>
               <typeRef>VlanIDType</typeRef>
            </component>
            <component componentID="3">
               <name>Reserved</name>
               <synopsis>
               Пространство резервных битов в основном для 
               заполнения и эффективной упаковки.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="4">
               <name>LogicalPortID</name>
               <synopsis>Идентификатор логического порта</synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>VlanInputTableType</name>
         <synopsis>
           Тип данных для входной таблицы VLAN в EtherClassifier LFB. 
           Таблица является массивом записей VlanInputTableEntryType.
         </synopsis>
         <array type="variable-size">
           <typeRef>VlanInputTableEntryType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherClassifyStatsType</name>
         <synopsis>
           Тип данных для записи таблицы статистики в EtherClassifier LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>EtherType</name>
               <synopsis>Тип Ethernet для пакета Ethernet.</synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="2">
               <name>Reserved</name>
               <synopsis>
               Пространство резервных битов в основном для 
               заполнения и эффективной упаковки.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="3">
               <name>PacketsNum</name>
               <synopsis>Число пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>EtherClassifyStatsTableType</name>
         <synopsis>
           Тип данных для таблицы статистики в EtherClassifier LFB.
         </synopsis>
         <array type="variable-size">
           <typeRef>EtherClassifyStatsType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4ValidatorStatsType</name>
         <synopsis>
           Тип данных для статистики в IPv4validator LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>badHeaderPkts</name>
               <synopsis>Число пакетов с непригодным заголовком</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>badTotalLengthPkts</name>
               <synopsis>
                 Число пакетов с некорректным общим размером
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>badTTLPkts</name>
               <synopsis>Число пакетов с некорректным TTL</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="4">
               <name>badChecksumPkts</name>
               <synopsis>Число пакетов с ошибкой контрольной суммы</synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6ValidatorStatsType</name>
         <synopsis>
           Тип данных для статистики в IPv6validator LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>badHeaderPkts</name>
               <synopsis>Число пакетов с непригодным заголовком</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>badTotalLengthPkts</name>
               <synopsis>
                  Число пакетов с некорректным общим размером
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>badHopLimitPkts</name>
               <synopsis>
               Число пакетов с некорректным TTL hop limit.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4PrefixInfoType</name>
         <synopsis>Тип данных для записей префиксов IPv4 в таблице
          IPv4UcastLPM LFB. Адрес получателя IPv4 в каждом входном
          пакете служит ключом поиска в таблице для определения
          селектора следующего интервала пересылки.</synopsis>
         <struct>
            <component componentID="1">
               <name>IPv4Address</name>
               <synopsis>Адрес IPv4 для получателя</synopsis>
               <typeRef>IPv4Addr</typeRef>
            </component>
            <component componentID="2">
               <name>Prefixlen</name>
               <synopsis>Размер префикса</synopsis>
               <atomic>
                  <baseType>uchar</baseType>
                  <rangeRestriction>
                     <allowedRange min="0" max="32"/>
                  </rangeRestriction>
               </atomic>
            </component>
            <component componentID="3">
               <name>ECMPFlag</name>
               <synopsis>Флаг ECMP</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>
                         ECMP false указывает, что для маршрута
                         нет множества next hop.
                        </synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>
                          ECMP true указывает наличие для 
                          маршрута множества next hop.
                        </synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>
            <component componentID="4">
               <name>DefaultRouteFlag</name>
               <synopsis>Флаг заданного по умолчанию маршрута</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>
                          Default route false указывает, что маршрут
                          не является принятым по умолчанию.
                        </synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>
                          Default route true указывает, что маршрут
                          является принятым по умолчанию.
                        </synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>
            <component componentID="5">
               <name>Reserved</name>
               <synopsis>
                  Пространство резервных битов в основном для 
                  заполнения и эффективной упаковки.
               </synopsis>
               <typeRef>uchar</typeRef>
            </component>
            <component componentID="6">
               <name>HopSelector</name>
               <synopsis>
                 HopSelector для префикса, соответствующего LFB,
                 который будет выдаваться в нисходящий LFB для 
                 нахождения информации next-hop.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4PrefixTableType</name>
         <synopsis>
           Тип данных для таблицы префиксов IPv4 в IPv4UcastLPM LFB, 
           используемой для поиска максимального совпадения. Записи
           таблицы имеют тип данных IPv4PrefixInfoType.
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv4PrefixInfoType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4UcastLPMStatsType</name>
         <synopsis>
          Тип данных для статистики в IPv4UcastLPM LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>InRcvdPkts</name>
               <synopsis>Число принятых на входе пакетов.</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>FwdPkts</name>
               <synopsis>Число пересланных пакетов.</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>NoRoutePkts</name>
               <synopsis>
                Число пакетов с ненайденным маршрутом.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6PrefixInfoType</name>
         <synopsis>Тип данных для таблицы префиксов IPv6 в 
          IPv6UcastLPM LFB, служащей для поиска максимального совпадения. 
          Адрес получателя IPv6 служит ключом при поиске в таблице 
          селектора следующего интервала (next-hop).</synopsis>
         <struct>
            <component componentID="1">
               <name>IPv6Address</name>
               <synopsis>Адрес получателя IPv6</synopsis>
               <typeRef>IPv6Addr</typeRef>
            </component>
            <component componentID="2">
               <name>Prefixlen</name>
               <synopsis>Размер префикса</synopsis>
               <atomic>
                  <baseType>uchar</baseType>
                  <rangeRestriction>
                     <allowedRange min="0" max="128"/>
                  </rangeRestriction>
               </atomic>
            </component>
            <component componentID="3">
               <name>ECMPFlag</name>
               <synopsis>Флаг ECMP</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>ECMP не используется</synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>ECMP используется</synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>
            <component componentID="4">
               <name>DefaultRouteFlag</name>
               <synopsis>Флаг принятого по умолчанию маршрута</synopsis>
               <atomic>
                  <baseType>boolean</baseType>
                  <specialValues>
                     <specialValue value="false">
                        <name>False</name>
                        <synopsis>Маршрут не используется по умолчанию</synopsis>
                     </specialValue>
                     <specialValue value="true">
                        <name>True</name>
                        <synopsis>Маршрут используется по умолчанию</synopsis>
                     </specialValue>
                  </specialValues>
               </atomic>
            </component>
            <component componentID="5">
               <name>Reserved</name>
               <synopsis>
                  Пространство резервных битов в основном для 
                  заполнения и эффективной упаковки.
               </synopsis>
               <typeRef>uchar</typeRef>
            </component>
            <component componentID="6">
               <name>HopSelector</name>
               <synopsis>
                 HopSelector для префикса, соответствующего LFB,
                 который будет выдаваться в нисходящий LFB для 
                 нахождения информации next-hop.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6PrefixTableType</name>
         <synopsis>
           Тип данных для таблицы префиксов IPv6 в IPv6UcastLPM LFB, 
           используемой для поиска максимального совпадения. Записи
           таблицы имеют тип данных IPv6PrefixInfoType.
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv6PrefixInfoType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6UcastLPMStatsType</name>
         <synopsis>Тип данных для статистики в IPv6UcastLPM LFB</synopsis>
         <struct>
            <component componentID="1">
               <name>InRcvdPkts</name>
               <synopsis>Число принятых на входе пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="2">
               <name>FwdPkts</name>
               <synopsis>Число пересланных пакетов</synopsis>
               <typeRef>uint64</typeRef>
            </component>
            <component componentID="3">
               <name>NoRoutePkts</name>
               <synopsis>
                Число пакетов с ненайденным маршрутом.
               </synopsis>
               <typeRef>uint64</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4NextHopInfoType</name>
         <synopsis>
           Тип данных для записей таблицы IPv4 next-hop в IPv4NextHop LFB.
           Таблица использует селектор, полученный от восходящего LFB, в
           качестве ключа для поиска индекса в таблице next-hop.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>L3PortID</name>
               <synopsis>
                Идентификатор логического выходного порта для передачи
                нисходящему LFB, указывающий, какой порт к соседу
                определен уровнем L3.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>MTU</name>
               <synopsis>
                Максимальный передаваемый блок (MTU) для выходного порта
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>NextHopIPAddr</name>
               <synopsis>Адрес next-hop IPv4</synopsis>
               <typeRef>IPv4Addr</typeRef>
            </component>
            <component componentID="4">
               <name>MediaEncapInfoIndex</name>
               <synopsis>
                 Индекс для передачи в нисходящий LFB инкапсуляции,
                 используемый в качестве ключа для поиска других
                 данных инкапсуляции.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="5">
               <name>LFBOutputSelectIndex</name>
                <synopsis>
                  Индекс для IPv4NextHop LFB, применяемый при выборе
                  экземпляра в группе выходных портов LFB для вывода.
                </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv4NextHopTableType</name>
         <synopsis>
           Тип данных для таблицы IPv4 next-hop в IPv4NextHop LFB.
           Записи таблицы имеют тип IPv4NextHopInfoType.
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv4NextHopInfoType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6NextHopInfoType</name>
         <synopsis>
           Тип данных для записей таблицы IPv6 next-hop в IPv6NextHop LFB.
           Таблица использует селектор, полученный от восходящего LFB, в
           качестве ключа для поиска индекса в таблице next-hop.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>L3PortID</name>
               <synopsis>
                Идентификатор логического выходного порта для передачи
                нисходящему LFB, указывающий, какой порт к соседу
                определен уровнем L3.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>MTU</name>
               <synopsis>
                Максимальный передаваемый блок (MTU) для выходного порта
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>NextHopIPAddr</name>
               <synopsis>Адрес next-hop IPv6</synopsis>
               <typeRef>IPv6Addr</typeRef>
            </component>
            <component componentID="4">
               <name>MediaEncapInfoIndex</name>
               <synopsis>
                 Индекс для передачи в нисходящий LFB инкапсуляции,
                 используемый в качестве ключа для поиска других
                 данных инкапсуляции.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="5">
               <name>LFBOutputSelectIndex</name>
                <synopsis>
                  Индекс для IPv6NextHop LFB, применяемый при выборе
                  экземпляра в группе выходных портов LFB для вывода.
                </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>IPv6NextHopTableType</name>
         <synopsis>
           Тип данных для таблицы IPv6 next-hop в IPv6NextHop LFB.
           Записи таблицы имеют тип IPv6NextHopInfoType.
         </synopsis>
         <array type="variable-size">
           <typeRef>IPv6NextHopInfoType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>EncapTableEntryType</name>
         <synopsis>
           Тип данных для записи таблицы инкапсуляции Ethernet в 
           EtherEncap LFB. LFB использует MediaEncapInfoIndex от
           восходящего LFB в качестве индекса для поиска в таблице
           инкапсуляционной информации для каждого пакета.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>DstMac</name>
               <synopsis>
                 MAC-адрес получателя для Ethernet-инкапсуляции пакета.
               </synopsis>
               <typeRef>IEEEMAC</typeRef>
            </component>
            <component componentID="2">
               <name>SrcMac</name>
               <synopsis>
                 MAC-адрес отправителя для Ethernet-инкапсуляции пакета.
               </synopsis>
               <typeRef>IEEEMAC</typeRef>
            </component>
            <component componentID="3">
               <name>VlanID</name>
               <synopsis>VLAN ID для пакета</synopsis>
               <typeRef>VlanIDType</typeRef>
            </component>
             <component componentID="4">
               <name>Reserved</name>
               <synopsis>
                  Пространство резервных битов в основном для 
                  заполнения и эффективной упаковки.
               </synopsis>
               <typeRef>uint16</typeRef>
            </component>
            <component componentID="5">
               <name>L2PortID</name>
               <synopsis>
                 Идентификатор логического порта L2 для пакета.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>EncapTableType</name>
         <synopsis>
           Тип данных для таблицы инкапсуляции Ethernet в EtherEncap
           LFB. Записи таблицы имеют тип данных EncapTableEntryType.
         </synopsis>
         <array type="variable-size">
           <typeRef>EncapTableEntryType</typeRef>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>MetadataDispatchType</name>
         <synopsis>
           Тип данных для записи таблицы метаданных диспетчеризации 
           в BasicMetadataDispatch LFB. The LFB использует значение 
           метаданных как ключ поиска индекса в LFB группы портов
           для вывода пакета.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>MetadataValue</name>
               <synopsis>Значение метаданных диспетчеризации</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>OutputIndex</name>
               <synopsis>
                 Индекс группы выходных портов для исходящих пакетов.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>MetadataDispatchTableType</name>
         <synopsis>
           Тип данных для таблицы метаданных диспетчеризации
           в BasicMetadataDispatch LFB. Значение метаданных
           определено также как поле ключа содержимого.
         </synopsis>
         <array type="variable-size">
           <typeRef>MetadataDispatchType</typeRef>
           <contentKey contentKeyID="1">
           <contentKeyField>MetadataValue</contentKeyField>
           </contentKey>
         </array>
      </dataTypeDef>
      <dataTypeDef>
         <name>SchdDisciplineType</name>
         <synopsis>Тип дисциплины планирования</synopsis>
         <atomic>
            <baseType>uint32</baseType>
            <specialValues>
               <specialValue value="1">
                  <name>RR</name>
                  <synopsis>
                    Дисциплина планирования с круговым перебором
                  </synopsis>
               </specialValue>
            </specialValues>
         </atomic>
      </dataTypeDef>
      <dataTypeDef>
         <name>QueueStatsType</name>
         <synopsis>
           Тип данных для таблицы статистики очередей в GenericScheduler LFB.
         </synopsis>
         <struct>
            <component componentID="1">
               <name>QueueID</name>
               <synopsis>Идентификатор входной очереди ID</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
               <name>QueueDepthInPackets</name>
               <synopsis>Глубина текущей очереди в пакетах</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3">
               <name>QueueDepthInBytes</name>
               <synopsis>Глубина текущей очереди в байтах</synopsis>
               <typeRef>uint32</typeRef>
            </component>
         </struct>
      </dataTypeDef>
      <dataTypeDef>
         <name>QueueStatsTableType</name>
         <synopsis>
           Тип данных для таблицы статистики очередей в GenericScheduler
           LFB. Записи таблицы имеют тип QueueStatsType.
         </synopsis>
         <array type="variable-size">
           <typeRef>QueueStatsType</typeRef>
         </array>
      </dataTypeDef>
   </dataTypeDefs>
   <metadataDefs>
      <metadataDef>
         <name>PHYPortID</name>
         <synopsis>
            Метаданные, указывающие идентификатор физического порта
         </synopsis>
         <metadataID>1</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>SrcMAC</name>
         <synopsis>Метаданные, указывающие MAC-адрес отправителя</synopsis>
         <metadataID>2</metadataID>
         <typeRef>IEEEMAC</typeRef>
      </metadataDef>
      <metadataDef>
         <name>DstMAC</name>
         <synopsis>
           Метаданные, указывающие MAC-адрес получателя.
         </synopsis>
         <metadataID>3</metadataID>
         <typeRef>IEEEMAC</typeRef>
      </metadataDef>
      <metadataDef>
         <name>LogicalPortID</name>
         <synopsis>Метаданные идентификатора логического порта</synopsis>
         <metadataID>4</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>EtherType</name>
         <synopsis> Метаданные, указывающие тип Ethernet</synopsis>
         <metadataID>5</metadataID>
         <typeRef>uint16</typeRef>
      </metadataDef>
      <metadataDef>
         <name>VlanID</name>
         <synopsis>Метаданные VLAN ID</synopsis>
         <metadataID>6</metadataID>
         <typeRef>VlanIDType</typeRef>
      </metadataDef>
      <metadataDef>
         <name>VlanPriority</name>
         <synopsis> Метаданные VLAN priority</synopsis>
         <metadataID>7</metadataID>
         <typeRef>VlanPriorityType</typeRef>
      </metadataDef>
      <metadataDef>
         <name>NextHopIPv4Addr</name>
         <synopsis>
           Метаданные, представляющие адрес next-hop IPv4
         </synopsis>
         <metadataID>8</metadataID>
         <typeRef>IPv4Addr</typeRef>
      </metadataDef>
      <metadataDef>
         <name>NextHopIPv6Addr</name>
         <synopsis>
           Метаданные, представляющие адрес next-hop IPv6
         </synopsis>
         <metadataID>9</metadataID>
         <typeRef>IPv6Addr</typeRef>
      </metadataDef>
      <metadataDef>
         <name>HopSelector</name>
         <synopsis>Метаданные, указывающие селектор интервала</synopsis>
         <metadataID>10</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>ExceptionID</name>
         <synopsis>
           Метаданные, указывающие тип исключения для исключительных
           случаев в процессе обработки пакета.
         </synopsis>
         <metadataID>11</metadataID>
         <atomic>
            <baseType>uint32</baseType>
            <specialValues>
                <specialValue value="0">
                  <name>AnyUnrecognizedExceptionCase</name>
                  <synopsis>Любые не распознанные исключения</synopsis>
                  </specialValue>
                <specialValue value="1">
                  <name>ClassifyNoMatching</name>
                  <synopsis>
                   Исключительный случай - нет соответствия в таблице
                   EtherClassifier LFB.
                  </synopsis>
                </specialValue>
                <specialValue value="2">
                  <name>MediaEncapInfoIndexInvalid</name>
                  <synopsis>
                   Исключительный случай - значение MediaEncapInfoIndex 
                   в пакете не приемлемо и не может быть назначено для
                   EncapTable в EtherEncap LFB.
                  </synopsis>
                </specialValue>
                <specialValue value="3">
                  <name>EncapTableLookupFailed</name>
                  <synopsis>
                   Исключительный случай - не удалось найти пакет в таблице
                   EncapTable блока EtherEncap LFB, хотя значение
                   MediaEncapInfoIndex корректно.
                  </synopsis>
                </specialValue>
                <specialValue value="4">
                  <name>BadTTL</name>
                  <synopsis>
                   Исключительный случай - пакет с просроченным TTL
                  </synopsis>
                </specialValue>
                <specialValue value="5">
                  <name>IPv4HeaderLengthMismatch</name>
                  <synopsis>
                   Исключительный случай - пакет с заголовком более 5 слов.
                  </synopsis>
                </specialValue>
                <specialValue value="6">
                   <name>RouterAlertOptions</name>
                   <synopsis>
                    Исключительный случай - пакет с опцией router alert 
                    в заголовке IP.
                   </synopsis>
                </specialValue>
                <specialValue value="7">
                   <name>IPv6HopLimitZero</name>
                   <synopsis>
                    Исключительный случай - пакет с нулевым значением hop limit.
                   </synopsis>
                </specialValue>
                <specialValue value="8">
                   <name>IPv6NextHeaderHBH</name>
                   <synopsis>
                    Исключительный случай - пакет с next header = Hop-by-Hop.
                   </synopsis>
                </specialValue>
                <specialValue value="9">
                   <name>SrcAddressException</name>
                   <synopsis>
                      Исключительный случай - пакет с исключительный адресом
                      отправителя.
                   </synopsis>
                </specialValue>
                <specialValue value="10">
                   <name>DstAddressException</name>
                   <synopsis>
                      Исключительный случай - пакет с исключительный адресом
                      получателя.
                   </synopsis>
                </specialValue>
                <specialValue value="11">
                   <name>LPMLookupFailed</name>
                   <synopsis>
                    Исключительный случай - отказ при поиске LPM для пакета
                    в LFB сопоставления префикса.
                   </synopsis>
                </specialValue>
                <specialValue value="12">
                   <name>HopSelectorInvalid</name>
                   <synopsis>
                    Исключительный случай - непригодное значение HopSelector 
                    для пакета.
                   </synopsis>
                </specialValue>
                <specialValue value="13">
                   <name>NextHopLookupFailed</name>
                   <synopsis>
                    Исключительный случай - отказ при поиске next-hop для
                    пакета при корректном HopSelector.
                   </synopsis>
                </specialValue>
                <specialValue value="14">
                   <name>FragRequired</name>
                   <synopsis>
                    Исключительный случай - требуется фрагментация пакета
                   </synopsis>
                </specialValue>
                <specialValue value="15">
                   <name>MetadataNoMatching</name>
                   <synopsis>
                    Исключительный случай - ничего не найдено при поиске
                    в таблице метаданных диспетчеризации в
                    BasicMetadataDispatch LFB.
                   </synopsis>
                </specialValue>
             </specialValues>
          </atomic>
      </metadataDef>
      <metadataDef>
          <name>ValidateErrorID</name>
          <synopsis>
            Метаданные, указывающие типы ошибок при проверке пакета.
          </synopsis>
          <metadataID>12</metadataID>
          <atomic>
             <baseType>uint32</baseType>
             <specialValues>
                <specialValue value="0">
                   <name>AnyUnrecognizedValidateErrorCase</name>
                   <synopsis>Нераспознанная ошибка при проверке.
                   </synopsis>
                </specialValue>
                <specialValue value="1">
                   <name>InvalidIPv4PacketSize</name>
                   <synopsis>
                    Ошибка - указанный канальным уровнем размер пакета 
                    меньше 20 байтов.</synopsis>
                </specialValue>
                <specialValue value="2">
                   <name>NotIPv4Packet</name>
                   <synopsis>
                    Ошибка - пакет не относится к протоколу IP версии 4</synopsis>
                </specialValue>
                <specialValue value="3">
                   <name>InvalidIPv4HeaderLengthSize</name>
                   <synopsis>
                    Ошибка - в поле заголовка указан размер заголовка менее 5 слов.
                   </synopsis>
                </specialValue>
                <specialValue value="4">
                   <name>InvalidIPv4LengthFieldSize</name>
                   <synopsis>
                    Ошибка - пакет со значением общего размера менее 20 байтов.
                   </synopsis>
                </specialValue>
                <specialValue value="5">
                   <name>InvalidIPv4Checksum</name>
                   <synopsis>
                    Ошибка - пакет с ошибкой контрольной суммы.
                    </synopsis>
                </specialValue>
                <specialValue value="6">
                   <name>InvalidIPv4SrcAddr</name>
                   <synopsis>
                    Ошибка - пакет с некорректным адресом отправителя IPv4.
                   </synopsis>
                </specialValue>
                <specialValue value="7">
                   <name>InvalidIPv4DstAddr</name>
                   <synopsis>
                    Ошибка - пакет с некорректным адресом получателя IPv4.
                   </synopsis>
                </specialValue>
                <specialValue value="8">
                   <name>InvalidIPv6PacketSize</name>
                   <synopsis>
                    Ошибка - размер пакета меньше 40 байтов.
                   </synopsis>
                </specialValue>
                <specialValue value="9">
                   <name>NotIPv6Packet</name>
                   <synopsis>
                    Ошибка - пакет не относится к протоколу IP версии 6.
                    </synopsis>
                </specialValue>
                <specialValue value="10">
                   <name>InvalidIPv6SrcAddr</name>
                   <synopsis>
                    Ошибка - пакет с некорректным адресом отправителя IPv6.
                   </synopsis>
                </specialValue>
                <specialValue value="11">
                   <name>InvalidIPv6DstAddr</name>
                   <synopsis>
                    Ошибка - пакет с некорректным адресом получателя IPv6.
                   </synopsis>
                </specialValue>
             </specialValues>
          </atomic>
      </metadataDef>
      <metadataDef>
         <name>L3PortID</name>
         <synopsis>
           Метаданные, указывающие идентификатор логического порта L3.
         </synopsis>
         <metadataID>13</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>RedirectIndex</name>
         <synopsis>
           Метаданные, которые CE передает RedirectIn LFB для указания индекса
           LFB группы выходных портов.
         </synopsis>
         <metadataID>14</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
         <name>MediaEncapInfoIndex</name>
         <synopsis>
           Ключ, применяемый для поиска в таблице с целью выбора инкапсуляции.
         </synopsis>
         <metadataID>15</metadataID>
         <typeRef>uint32</typeRef>
      </metadataDef>
   </metadataDefs>
</LFBLibrary>

5. Описания классов LFB

В соответствии со спецификациями ForCES логический функциональный блок LFB представляет собой четко определенный, логически выделенный функциональный блок, который размещается в FE и является функционально точной абстракцией функций обработки в FE. Класс (тип) LFB — это шаблон, представляющий детализированный, логически отделяемый аспект обработки в FE. Большинство LFB относятся к обработке пакетов в пути данных. Классы LFB являются базовыми блоками для построения модели FE. Отметим, что в [RFC5810] уже определен FE Protocol LFB, представляющий собой логический модуль в каждом FE для управления протоколом ForCES. В [RFC5812] определен FE Object LFB, где представлена такая информация, как FE Name, FE ID, FE State, LFB Topology для FE.

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

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

Следует также отметить, что в принятом по умолчанию для модели FE предложении [RFC5812] все метаданные, создаваемые восходящими LFB будут по умолчанию проходить через все нисходящие LFB без указания входных или выходных портов. LFB будет использовать (потреблять) лишь те метаданные, которые явно указаны на входе LFB как ожидаемые. Например, в нисходящем LFB блока LFB физического уровня даже при отсутствии конкретных ожиданий, метаданные типа PHYPortID, создаваемые LFB физического уровня, всегда будут проходить через все нисходящие LFB независимо от того, ожидаются ли они блоками LFB.

5.1. LFB для обработки Ethernet

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

Существуют разные варианты формата Ethernet, такие как Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP, а также разные технологии ЛВС Ethernet, такие как VLAN, MACinMAC и т. д. Определенные здесь LFB для обработки Ethernet предназначены для работы со всеми вариантами технологии Ethernet.

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

5.1.1. EtherPHYCop

EtherPHYCop LFB обеспечивает абстракцию физического уровня Ethernet для электрических кабелей.

5.1.1.1. Обработка данных

Этот LFB является интерфейсом в физическую среду Ethernet. LFB обрабатывает кадры Ethernet приходящие в FE и передаваемые из FE. Принимаемые и передаваемые кадры Ethernet включают все пакеты, инкапсулированные с разными вариантами протокола Ethernet, такими как Ethernet V2, 802.3 RAW, IEEE 802.3/802.2 и IEEE 802.3/802.2 SNAP, включая пакеты, инкапсулированные с использованием различных технологий ЛВС на базе Ethernet, таких как VLAN, MACinMAC и т. п. Поэтому в XML включен тип кадров EthernetAll.

Кадры Ethernet принимаются из физического порта и передаются нисходящим LFB, таким как EtherMACIn LFB, через одиночный выход EtherPHYOut. Метаданные PHYPortID, указывающие физический порт, через который был принят кадр извне, передаются вместе с кадром.

Пакеты Ethernet принимаются этим LFB от восходящих LFB, таких как EtherMacOut LFB, через одиночный вход EtherPHYIn для отправки вовне.

5.1.1.2. Компоненты

Компонента AdminStatus определена для CE с целью административного управления состоянием LFB. CE может включать и отключать LFB, меняя AdminStatus. По умолчанию установлено значение Down (отключено).

OperStatus фиксирует рабочее состояние физического порта. Определено событие PHYPortStatusChanged, что позволяет LFB информировать CE об изменении рабочего состояния физического порта.

PHYPortID служит для однозначного указания физического порта. Идентификаторы доступны только для чтения (read-only, устанавливается CE). Значения идентификаторов определяются FE. Компонента используется для создания метаданных PHYPortID на выходе LFB и связывания с каждым пакетом Ethernet, полученным LFB. Метаданные обрабатываются нисходящими LFB для использования PHYPortID.

Определена группа компонент для управления скоростью канала. AdminLinkSpeed используется CE для настройки скорости порта, а OperLinkSpeed позволяет CE запросить реальную скорость работы порта. По умолчанию для AdminLinkSpeed устанавливается автоматическое согласование скорости (auto-negotiation).

Определена группа компонент для управления режимом дуплекса. AdminDuplexMode используется CE для настройки режима порта, а OperDuplexMode позволяет CE запросить рабочий режим. По умолчанию для AdminDuplexMode устанавливается автоматическое согласование скорости (auto-negotiation).

CarrierStatus фиксирует состояние несущей и указывает реальное состояние канала на порту. По умолчанию CarrierStatus имеет значение false (нет сигнала).

5.1.1.3. Возможности

Информация о возможностях этого LFB включает скорости, поддерживаемые FE (SupportedLinkSpeed), а также режимы дуплекса (SupportedDuplexMode).

5.1.1.4. События

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

Другое событие фиксирует смену рабочей скорости соединения (LinkSpeedChanged) и уведомляет CE об изменении скорости, указывая новое согласованное значение рабочей скорости.

Еще одно событие связано с изменением режима дуплекса (DuplexModeChanged) и уведомляет CE о смене режима, указывая новый согласованный режим работы порта.

5.1.2. EtherMACIn

EtherMACIn LFB обеспечивает абстракцию порта Ethernet на канальном уровне MAC и описывает функции обработки Ethernet, такие как проверку местоположения MAC-адреса, принятие решения об использовании функций моста, управление потоком данных на уровне Ethernet и т. п.

5.1.2.1. Обработка данных

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

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

Первый одиночный выход называется NormalPathOut и обычно выводит пакеты Ethernet в тот или иной LFB, такой как EtherClassifier LFB, для последующего процесса пересылки L3 вместе с метаданными PHYPortID, указывающими физический порт, принявший пакет.

Второй одиночный выход называется L2BridgingPathOut. Хотя библиотека LFB в этом документе рассчитана в основном на типичные маршрутизаторы, она пытается обеспечить совместимость с функциями будущих маршрутизаторов. Выход L2BridgingPathOut определен для выполнения требований функций мостов L2, которые могут одновременно поддерживать функции обработки L3 и некоторые L2 LFB, которые могут быть определены в будущем. Если FE поддерживает функции моста L2, CE сможет включать или отключать эти функции с помощью компоненты L2BridgingPathEnable в FE. При включенной функции создаются также некоторые экземпляры L2 LFB, следующие за L2BridgingPathOut, и FE будет выполнять функции моста L2. Выход L2BridgingPathOut будет выводить пакеты как и NormalPathOut.

Этот LFB может работать в неразборчивом (promiscuous) режиме, позволяющем всем пакетам проходить через LFB без отбрасывания. В обычном режиме выполняется проверка локальности MAC-адресов и все пакеты, которые не прошли эту проверку, будут отбрасываться.

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

5.1.2.2. Компоненты

Компоента AdminStatus определена для CE с целью административного управления состоянием LFB. CE может административно запустить или отключить LFB, меняя значение AdminStatus. По умолнанию задано значение Down.

LocalMACAddresses задает локальные MAC-адреса по которым выполняется проверка местоположения. Это массив MAC-адресов с правами доступа для чтения и записи (read-write).

L2BridgingPathEnable указывает, установлен ли блок LFB для работы в качестве моста L2. FE, не поддерживающий функции моста, будет внутренними средствами устанавливать для этого флага значение false, а также устанавливать для него доступ лишь на чтение (read-only). По умолчанию устанавливается значение false.

PromiscuousMode указывает, установлен ли блок LFB для работы в неразборчивом (promiscuous) режиме. По умолчанию задано значение false.

TxFlowControl указывает, выполняет ли LFB управление потоком данных при передаче пакетов (по умолчанию false). Отметим что эта компонента указана как необязательная (optional). Если FE не реализует ее, а CE пытается настроить, FE может сообщить CE об ошибке с кодом 0x09 (E_COMPONENT_DOES_NOT_EXIST) или 0x15 (E_NOT_SUPPORTED), в зависимости от обработки FE. Подробности приведены в [RFC5810].

RxFlowControl указывает, выполняет ли LFB управление потоком данных при получении пакетов (по умолчанию false). Компонента помечена как необязательная (optional).

Структурная компонента MACInStats определяет набор параметров статистики для этого LFB, включая число принятых и отброшенных пакетов. Отметим, что компонента не является обязательной для реализации. Если CE пытается запросить эту компоненту, а она не реализована, возвращается ошибка 0x09 (E_COMPONENT_DOES_NOT_EXIST) или 0x15 (E_NOT_SUPPORTED) в зависимости от реализации FE.

5.1.2.3. Возможности

У этого LFB нет списка возможностей.

5.1.2.4. События

Этот LFB не задает каких-либо событий.

5.1.3. EtherClassifier

EtherClassifier LFB является абстракцией процесса декапсуляции пакетов Ethernet и последующей их классификации.

5.1.3.1. Обработка данных

LFB описывает процесс декапсуляции пакетов Ethernet и их классификации в соответствии с информацией из заголовок пакета Ethernet.

Предполагается, что LFB принимает все типы пакетов Ethernet (через отдельный вход EtherPktsIn), которые обычно выводятся восходящим LFB, таким как EtherMACIn LFB. Этот вход также поддерживает мультиплексирование, позволяющее подключать множество восходящих LFB. Например, при включенной функции моста L2 в EtherMACIn LFB могут применяться некоторые LFB мостов L2. В этом случае после обработки L2 некоторые пакеты Ethernet могут попадать на вход EtherClassifier LFB для классификации, тогда как пакетам, напрямую выходящим из EtherMACIn тоже может потребоваться вход в этот LFB. Данный вход способен обрабатывать такие случаи. Обычно все ожидаемые пакеты Ethernet будут связаны с метаданными PHYPortID, указывающими физический порт, из которого поступил пакет. В некоторых случаях (например, MACinMAC) может предполагаться связывание метаданных LogicalPortID с пакетом Ethernet для дополнительного указания логического порта, к которому относится пакет Ethernet. Отметим, что метаданные PHYPortID предполагаются всегда, а метаданные LogicalPortID являются необязательными.

В LFB определены два выходных порта.

Первый выход является групповым портом ClassifyOut. Типы пакетов протоколов сетевого уровня выводятся в экземпляры группы портов. Поскольку может быть много разных типов протоколов на выходных портах, создаваемый выходной кадр определяется как произвольный с возможностью расширения определения в будущем. Метаданные, для передачи вместе с пакетом создаются в этом LFB для использования нисходящими LFB. Передаваемые вниз метаданные включают PHYPortID, а также информацию о типе Ethernet, MAC-адреса отправителя и получателя и идентификатор логического порта. Если исходный пакет является пакетом VLAN и содержит значения идентификатора и приоритета, эти значения также передаются в метаданных в нисходящем направлении. В результате эти метаданные VLAN ID определены как условные (conditional).

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

не найдено соответствия при классификации пакета.

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

5.1.3.2. Компоненты

Массив EtherDispatchTable определен в LFB для диспетчеризации каждого пакета Ethernet в выходную группу в соответствии с идентификатором логического порта, назначенным VlanInputTable для пакета, и типом Ethernet в заголовке. Каждая строка массива является структурой, содержащей идентификатор логического порта, EtherType и индекс выхода. При настройке таблицы диспетчеризации со стороны CE можно ожидать, что LFB будет классифицировать пакеты разных протоколов сетевого уровня и выводить их в разные выходные порты. Предполагается, что LFB будет классифицировать пакеты по протоколам, таким как IPv4, IPv6, MPLS, ARP, ND¹⁵ и т. п.

Массив VlanInputTable определен в LFB для классификации пакетов VLAN Ethernet. Каждая строка массива является структурой, включающей идентификатор входного порта, VLAN ID и идентификатор логического порта. В соответствии со спецификацией IEEE VLAN все пакеты Ethernet могут распознаваться как относящиеся к VLAN путем назначения пакетов без инкапсуляции VLAN к VLAN 0. Каждому входному пакету назначается новый LogicalPortID в соответствии и идентификатором входного порта и VLAN ID. Идентификатор входного порта определяется как идентификатор логического порта, если с пакетом связан логический порт, или как идентификатор физического порта, если логический порт не привязан к пакету. VLAN ID берется из пакета или назначается VLAN 0, если в пакете нет тега. Отметим, что идентификатор логического порта для пакета может быть изменен при обработке VlanInputTable.

Отметим, что упомянутые выше идентификаторы логического и физического порта изначально задаются CE и являются глобальными в рамках ForCES NE (элемент сети). Чтобы не путать идентификаторы логических и физических портов в поле идентификатора входного порта VlanInputTable, значения идентификаторов физических и логических портов должны назначаться из разных числовых диапазонов.

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

5.1.3.3. Возможности

У этого LFB нет списка возможностей.

5.1.3.4. События

Этот LFB не задает каких-либо событий.

5.1.4. EtherEncap

EtherEncap LFB является абстракцией процесса замены заголовков Ethernet и добавления в пакет новых заголовков.

5.1.4.1. Обработка данных

LFB абстрагирует процесс встраивания (инкапсуляции) заголовков Ethernet в полученные пакеты. Инкапсуляция основана на передаче метаданных. Предполагается, что LFB принимает пакеты IPv4 и IPv6 через отдельный входной порт EncapIn, который может быть соединен с восходящим LFB типа IPv4NextHop, IPv6NextHop, BasicMetadataDispatch или иным LFB, которому нужно выводить пакеты для инкапсуляции Ethernet. LFB всегда ждет от восходящих LFB метаданные MediaEncapInfoIndex, которые служат ключом поиска в таблице инкапсуляции EncapTable. Входной пакет может также иметь метаданные VLAN priority, указывающие исходный приоритет для пакета. Значение приоритета может быть установлено в пакете снова при инкапсуляции. По умолчанию для приоритета VLAN задано значение 0.

Для LFB определены два отдельных выходных порта.

Первый одиночный выход называется SuccessOut. При успешном поиске в таблице MAC-адреса отправителя и получателя, а также логический порт среды (L2PortID) находятся в соответствующей записи таблицы. CE может установить VlanID в случае использования VLAN. По умолчанию применяется запись с VlanID 0 в соответствии с правилами IEEE [IEEE.802-1Q]. Независимо от значения VlanID, если во входных метаданных значение VlanPriority отлично от 0, пакет получает тен VLAN. Если VlanPriority и VlanID равны 0, тег VLAN не назначается пакету. После замены или добавления подходящих заголовков Ethernet пакет передается на выход SuccessOut для нисходящего экземпляра LFB вместе с метаданными L2PortID.

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

значение MediaEncapInfoIndex в пакете недействительно и отсутствует в EncapTable;
пакет не найден в таблице EncapTable, хотя значение MediaEncapInfoIndex действительно.

Восходящий LFB может программироваться CE для передачи вместе с MediaEncapInfoIndex, которого нет в EncapTable. Это позволит при необходимости распознавать заголовки на уровне инкапсуляции L2 через ARP или ND (или иной метод в зависимости от технологии канального уровня) при отсутствии записи в таблице.

Для распознания соседского заголовка L2 (исключение table miss) обрабатывающий LFB может передать пакет CE через LFB перенаправления, программу FE или другой экземпляр LFB. В таких случаях для обработки исключения передаются также метаданные NextHopIPv4Addr или NextHopIPv6Addr, генерируемые next-hop LFB. Такой адрес IP может применяться для выполнения таких операций, как ARP или ND, в обработчике, которому передан пакет.

Результатом распознавания L2 служит обновление EncapTable, а также next-hop LFB, чтобы для последующих пакетов поиск в EncapTable не завершался отказом. EtherEncap LFB не делает предположений о способе обновления EncapTable элементом CE (а также использовании ARP/ND или статического отображения).

Экземпляры нисходящих LFB могут иметь тип EtherMACOut или BasicMetadataDispatch. Если финальная обработка пакета L2 выполняется по портам сред, относящимся к разным FE, или нужно распознавание заголовка L2, модели имеет смысл принять BasicMetadataDispatch LFB для ответвления в разные экземпляры LFB. Если имеется прямой выходной порт, имеет смысл применение в качестве экземпляра нисходящего LFB блока EtherMACOut.

5.1.4.2. Компоненты

Этот LFB имеет единственную компоненту EncapTable, определенную как массив. Каждая строка массива является структурой, содержащей MAC-адреса получателя и отправителя, VLAN ID (по умолчанию 0) и идентификатор выходного логического порта L2.

5.1.4.3. Возможности

У этого LFB нет списка возможностей.

5.1.4.4. События

Этот LFB не задает каких-либо событий.

5.1.5. EtherMACOut

EtherMACOut LFB абстрагирует порт Ethernet на уровне MAC и описывает процесс вывода пакетов Ethernet. Выходные функции Ethernet тесно связаны со входными, поэтому многие компоненты этого LFB являются псевдонимами компонент EtherMACIn LFB.

5.1.5.1. Обработка данных

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

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

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

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

5.1.5.2. Компоненты

AdminStatus служит для того, чтобы CE мог административно управлять состоянием LFB, включая и выключая его путем установки значения AdminStatus (по умолчанию Down — отключено). Отметим, что эта компонента определена как псевдоним AdminStatus в EtherMACIn LFB. Это предполагает, что EtherMACOut LFB обычно сосуществует с EtherMACIn LFB и оба используют одинаковое административное управление состоянием со стороны CE. Свойства псевдонима, как определено в модели ForCES FE [RFC5812], будут применяться CE для задания целевой компоненты, к которой относится псевдоним, указывая целевой класс LFB, идентификаторы экземпляров, а также путь к целевой компоненте.

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

Необязательная компонента TxFlowControl указывает, выполняется ли этим LFB управление потоком данных при передаче пакетов (по умолчанию false). Отметим, что эта компонента определена как псевдоним компоненты TxFlowControl в EtherMACIn LFB.

Необязательная компонента RxFlowControl указывает, выполняется ли этим LFB управление потоком данных на приеме (по умолчанию false). Отметим, что эта компонента определена как псевдоним компоненты RxFlowControl в EtherMACIn LFB.

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

5.1.5.3. Возможности

У этого LFB нет списка возможностей.

5.1.5.4. События

Этот LFB не задает каких-либо событий.

5.2. LFB для проверки пакетов IP

Определены LFB для абстрагирования проверки пригодности пакетов IP — IPv4Validator LFB для IPv4 и IPv6Validator LFB для IPv6.

5.2.1. IPv4Validator

IPv4Validator LFB выполняет проверку пригодности пакетов IPv4.

5.2.1.1. Обработка данных

Этот LFB выполняет проверку пригодности пакетов IPv4 в соответствии с [RFC1812] и последующими обновлениями. Пакет IPv4 будет выводиться в соответствующий порт LFB, указывающий, относится пакет к индивидуальным или групповым и были ли отказы или исключительные ситуации при проверке.

Этот LFB всегда ожидает на входе пакеты, классифицированные как IPv4 восходящим LFB, таким как EtherClassifier LFB. Конкретные метаданные на входе LFB не ожидаются.

Для LFB определены 4 выходных порта.

Все прошедшие проверку индивидуальные пакеты IPv4 будут выводиться в одиночный порт IPv4UnicastOut, а групповые — в одиночный порт IPv4MulticastOut.

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

Пакеты с нулевым TTL.
Пакеты с размером заголовка более 5 слов.
Пакеты с заголовком, включающим опцию router alert.
Пакеты с исключительным адресом отправителя.
Пакеты с исключительным адресом получателя.

Отметим, что проверка TTL выполняется в этом LFB, но операции с TTL (например, декремент) выполняются нисходящим LFB пересылки.

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

размер пакета меньше 20 байтов;
версия пакета отличается от IPv4;
размер заголовка в пакете меньше 5 слов;
поле общего размера пакета имеет значение меньше 20;
ошибка контрольной суммы;
недействительный адрес отправителя;
недействительный адрес получателя.

5.2.1.2. Компоненты

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

5.2.1.3. Возможности

У этого LFB нет списка возможностей.

5.2.1.4. События

Этот LFB не задает каких-либо событий.

5.2.2. IPv6Validator

IPv6Validator LFB выполняет проверку пригодности пакетов IPv6.

5.2.2.1. Обработка данных

Этот LFB выполняет проверку пригодности пакетов IPv6 в соответствии с [RFC2460] и последующими обновлениями. Пакет IPv6 будет выводиться в соответствующий порт LFB, указывающий, относится пакет к индивидуальным или групповым и были ли отказы или исключительные ситуации при проверке.

Этот LFB всегда ожидает на входе пакеты, классифицированные как IPv6 восходящим LFB, таким как EtherClassifier LFB. Конкретные метаданные на входе LFB не ожидаются.

Как и в IPv4validator LFB для этого LFB определены 4 выходных порта, в которые пакеты передаются в соответствии с результатом проверки.

Все прошедшие проверку индивидуальные пакеты IPv6 будут выводиться в одиночный порт IPv6UnicastOut, а групповые — в одиночный порт IPv6MulticastOut.

Пакеты с нулевым hop limit.
Пакеты с next header установленным в hop-by-hop.
Пакеты с исключительным адресом отправителя.
Пакеты с исключительным адресом получателя.

размер пакета меньше 40 байтов;
версия пакета отличается от IPv6;
недействительный адрес отправителя;
недействительный адрес получателя.

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

5.2.2.2. Компоненты

Этот LFB имеет единственную структурную компоненту IPv6ValidatorStatisticsType, определяющую параметры статистики для процесса проверки пригодности, включая число пакетов с некорректными заголовками, некорректным размером, непригодным значением hop limit. Эта компонента не обязательна для реализации.

5.2.2.3. Возможности

У этого LFB нет списка возможностей.

5.2.2.4. События

Этот LFB не задает каких-либо событий.

5.3. LFB для пересылки IP

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

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

На основе абстракции пересылки IP определены два типовых блока индивидуальной пересылки IP — LFB для поиска LPM¹⁶ и LFB для применения next-hop. Оба LFB имеют варианты для протоколов IPv4 и IPv6.

5.3.1. IPv4UcastLPM

IPv4UcastLPM LFB абстрагирует процесс поиска LPM для индивидуальных адресов IPv4.

LFB также обеспечивает средства для упрощения маршрутизации по множеству равноценных путей (ECMP¹⁷) и пересылки по обратному пути (RPF¹⁸). Однако сам LFB не обеспечивает ECMP или RPF. Для реализации их будут определены специальные LFB, например ECMP LFB и RPF LFB.

5.3.1.1. Обработка данных

LFB выполняет поиск индивидуальных адресов IPv4 в таблице LPM. На входе всегда предполагаются индивидуальные пакеты IPv4 из одиночного входного порта PktsIn. LFB использует адрес получателя IPv4 в каждом пакете как ключ поиска в таблице префиксов IPv4 и создает селектор интервала (hop) в соответствии с результатом. Селектор передается как метаданные пакета нисходящим LFB и обычно служит в качестве поискового индекса для поиска дополнительной информации о следующем интервале (next-hop).

В LFB определены три одиночных выходных порта.

Первый одиночный порт NormalOut выводит индивидуальные пакеты IPv4, для которых найден LPM (и селектор интервала). Селектор связывается с пакетом как метаданные. Нисходящим для LPM LFB обычно является LFB следующего интервала пересылки, такой как IPv4NextHop LFB.

Второй одиночный порт ECMPOut определен для поддержки пользователей, желающих реализовать ECMP.

Флаг ECMP определен в таблице LPM для поддержки в LFB маршрутизации ECMP. Если этот флаг установлен для записи в таблице, это указывает, что запись предназначена лишь для ECMP. Пакеты, соответствующие такой записи, всегда будут выводиться через порт ECMPOut, а селектор интервала будет указывать результат поиска. Выходом обычно является нисходящий LFB для обработки ECMP, где селектор интервала позволяет создать одно или несколько значений next-hop для использования алгоритмами ECMP.

Флаг маршрута по умолчанию определен в таблице LPM для поддержки в LFB принятого по умолчанию маршрута, а также управления пересылкой RPF. При установленном флаге запись таблицы считается принятым по умолчанию маршрутом с запретом пересылки RPF. Если пользователь хочет реализовать RPF в FE, нужно определить конкретный блок RPF LFB. В таком RPF LFB может быть определена компонента, являющаяся псевдонимом компоненты IPv4PrefixTable в этом LFB, которая описана ниже.

Последний одиночный порт ExceptionOut в IPv4UcastLPM LFB определен для вывода пакетов с исключительными ситуациями при обработке вместе с метаданными ExceptionID, указывающими причину. Определена одна причина:

не найдено соответствия при поиске LPM в таблице префиксов.

Восходящим для этого LFB обычно служит IPv4Validator LFB. При использовании RPF это может быть RPF LFB, когда он будет определен.

Нисходящим LFB обычно является IPv4NextHop LFB. При использовании ECMP это может быть ECMP LFB, когда он будет определен.

5.3.1.2. Компоненты

Этот LFB имеет две компоненты.

IPv4PrefixTable является массивом, каждая строка которого содержит адрес IPv4, размер префикса, селектор интервала, флаги ECMP и маршрута по умолчанию. LFB использует адрес получателя IPv4 в каждом входящем пакете как ключ поиска в этой таблице для извлечения селектора next-hop. Флаг ECMP в LFB служит для поддержки ECMP, а флаг маршрута по умолчанию для поддержки такого маршрута и управления RPF.

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

5.3.1.3. Возможности

У этого LFB нет списка возможностей.

5.3.1.4. События

Этот LFB не задает каких-либо событий.

5.3.2. IPv4NextHop

Этот LFB абстрагирует процесс выбора IPv4 next-hop.

5.3.2.1. Обработка данных

LFB абстрагирует процесс применения данных о следующем интервале к пакетам IPv4. Он получает пакеты IPv4 с идентификатором следующего интервала (HopSelector) и применяет этот идентификатор как индекс таблицы для поиска подходящего выходного порта LFB.

LFB ожидает приема индивидуальных пакетов IPv4 через одиночный порт PktsIn вместе с метаданными HopSelector, которые служат индексом для поиска в таблице NextHop. Обработка данных включает уменьшение TTL и расчет контрольной суммы IP.

В LFB определены два выходных порта.

Первый порт является групповым и называется SuccessOut. При успешной обработке данных пакет передается из группового порта LFB в соответствии со значением LFBOutputSelectIndex, соответствующим записи в таблице. Пакет передается в нисходящий LFB с метаданными L3PortID и MediaEncapInfoIndex.

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

HopSelector для пакета не пригоден.
Отказ при поиске в таблице next-hop при корректном HopSelector.
MTU выходного интерфейса меньше размера пакета.

Экземпляры нисходящих LFB могут иметь тип BasicMetadataDispatch (параграф 5.5.1), используемый для распределения по разным экземплярам LFB, или связанный с инкапсуляций в среду тип, такой как EtherEncap или RedirectOut (параграф 5.4.2). Например при наличии Ethernet или другой туннельной инкапсуляции BasicMetadataDispatch LFB может использовать метаданные L3PortID (параграф 5.3.2.2) для диспетчеризации пакетов разным инкапсуляторам.

5.3.2.2. Компоненты

Этот LFB имеет одну компоненту — массив IPv4NextHopTable. Полученное значение HopSelector служит индексом массива IPv4NextHopTable для поиска строки с информацией next-hop. Структура строк массива описана ниже.

Идентификатор логического порта L3PortID, который передается экземпляру нисходящего LFB. Этот идентификатор указывает тип инкапсулирующего порта, который должен использовать сосед. Эта информация, полученная от L3, влияет на обработку L2 и поэтому должна основываться на метаданных, передаваемых между LFB. Обычно этот идентификатор применяется для LFB следующего интервала, чтобы различать пакеты, которым нужна разная инкапсуляция L2. Например, некоторым пакетам может требоваться базовая инкапсуляция Ethernet, а другим — туннельная инкапсуляция того или иного типа. В таких случаях пакетам назначаются разные L3PortID, которые передаются в виде метаданных нисходящему LFB. Блок BasicMetadataDispatch LFB (параграф 5.5.1) может служить таким нисходящим LFB для диспетчеризации пакетов экземплярам LFB с разной инкапсуляцией в соответствии с L3PortID.
MTU — максимальный размер блока на выходном порту.
NextHopIPAddr — адрес IPv4.
MediaEncapInfoIndex передается нисходящему LFB инкапсуляции и служит ключом поиска в таблице (обычно связанной с инкапсуляцией для разных сред). Отметим, что экземпляр LFB инкапсуляции, использующий эти метаданные, может не следовать непосредственно за данным LFB в процессе обработки. Метаданные MediaEncapInfoIndex добавляются к пакету и передаются через промежуточные LFB, пока не будут применены экземпляром LFB инкапсуляции. В зависимости от реализации CE может устанавливать для MediaEncapInfoIndex, передаваемого в нисходящем направлении, значение, которое будет приводить к отказу при поиске в целевом LFB инкапсуляции. Это будет говорить о том, что нужно дополнительное распознавание. Пример этого показан в параграфе 7.2, где обсуждается протокол ARP.
LFBOutputSelectIndex является индексом группового выходного порта LFB для выбора порта нисходящего LFB. Это значение указывает конкретный порт группы SuccessOut, через который будет выводиться пакет с найденной информацией next-hop.

5.3.2.3. Возможности

У этого LFB нет списка возможностей.

5.3.2.4. События

Этот LFB не задает каких-либо событий.

5.3.3. IPv6UcastLPM

IPv6UcastLPM LFB абстрагирует процесс поиска LPM для индивидуальных адресов IPv6. Определение этого LFB похоже на определение IPv4UcastLPM LFB, но адреса IP в нем относятся к IPv6.

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

5.3.3.1. Обработка данных

LFB выполняет поиск индивидуальных адресов IPv6 в таблице LPM. На входе всегда предполагаются индивидуальные пакеты IPv6 из одиночного входного порта PktsIn. LFB использует адрес получателя IPv6 в каждом пакете как ключ поиска в таблице префиксов IPv6 и создает селектор интервала (hop) в соответствии с результатом. Селектор передается как метаданные пакета нисходящим LFB и обычно служит в качестве поискового индекса для поиска дополнительной информации о следующем интервале (next-hop).

В LFB определены три одиночных выходных порта.

Первый одиночный порт NormalOut выводит индивидуальные пакеты IPv6, для которых найден LPM (и селектор интервала). Селектор связывается с пакетом как метаданные. Нисходящим для LPM LFB обычно является LFB следующего интервала пересылки, такой как IPv6NextHop LFB.

Второй одиночный порт ECMPOut определен для поддержки пользователей, желающих реализовать ECMP.

Флаг маршрута по умолчанию определен в таблице LPM для поддержки в LFB принятого по умолчанию маршрута, а также управления пересылкой RPF. При установленном флаге запись таблицы считается принятым по умолчанию маршрутом с запретом пересылки RPF. Если пользователь хочет реализовать RPF в FE, нужно определить конкретный блок RPF LFB. В таком RPF LFB может быть определена компонента, являющаяся псевдонимом компоненты IPv6PrefixTable в этом LFB, которая описана ниже.

Последний одиночный порт ExceptionOut в IPv6UcastLPM LFB определен для вывода пакетов с исключительными ситуациями при обработке вместе с метаданными ExceptionID, указывающими причину. Определена одна причина:

не найдено соответствия при поиске LPM в таблице префиксов.

Восходящим для этого LFB обычно служит IPv6Validator LFB. При использовании RPF это может быть RPF LFB, когда он будет определен.

Нисходящим LFB обычно является IPv6NextHop LFB. При использовании ECMP это может быть ECMP LFB, когда он будет определен.

5.3.3.2. Компоненты

Этот LFB имеет две компоненты.

IPv6PrefixTable является массивом, каждая строка которого содержит адрес IPv6, размер префикса, селектор интервала, флаги ECMP и маршрута по умолчанию. Флаг ECMP в LFB служит для поддержки ECMP, а флаг маршрута по умолчанию для поддержки такого маршрута и управления RPF, как описано выше.

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

5.3.3.3. Возможности

У этого LFB нет списка возможностей.

5.3.3.4. События

Этот LFB не задает каких-либо событий.

5.3.4. IPv6NextHop

Этот LFB абстрагирует процесс выбора IPv6 next-hop.

5.3.4.1. Обработка данных

LFB абстрагирует процесс применения данных о следующем интервале к пакетам IPv6. Он получает пакеты IPv6 с идентификатором следующего интервала (HopSelector) и применяет этот идентификатор как индекс таблицы для поиска подходящего выходного порта LFB.

LFB ожидает приема индивидуальных пакетов IPv6 через одиночный порт PktsIn вместе с метаданными HopSelector, которые служат индексом для поиска в таблице next-hop.

В LFB определены два выходных порта.

HopSelector для пакета не пригоден.
Отказ при поиске в таблице next-hop при корректном HopSelector.
MTU выходного интерфейса меньше размера пакета.

Экземпляры нисходящих LFB могут иметь тип BasicMetadataDispatch, используемый для распределения по разным экземплярам LFB, или связанный с инкапсуляций в среду тип, такой как EtherEncap или RedirectOut. Например при наличии Ethernet или другой туннельной инкапсуляции BasicMetadataDispatch LFB может использовать метаданные L3PortID (см. ниже) для диспетчеризации пакетов разным инкапсуляторам.

5.3.4.2. Компоненты

Этот LFB имеет одну компоненту — массив IPv6NextHopTable. Полученное значение HopSelector служит индексом массива IPv6NextHopTable для поиска строки с информацией next-hop. Структура строк массива описана ниже.

Идентификатор логического порта L3PortID, который передается экземпляру нисходящего LFB. Этот идентификатор указывает тип инкапсулирующего порта, который должен использовать сосед. Эта информация, полученная от L3, влияет на обработку L2 и поэтому должна основываться на метаданных, передаваемых между LFB. Обычно этот идентификатор применяется для LFB следующего интервала, чтобы различать пакеты, которым нужна разная инкапсуляция L2. Например, некоторым пакетам может требоваться базовая инкапсуляция Ethernet, а другим — туннельная инкапсуляция того или иного типа. В таких случаях пакетам назначаются разные L3PortID, которые передаются в виде метаданных нисходящему LFB. Блок BasicMetadataDispatch LFB (параграф 5.5.1) может служить таким нисходящим LFB для диспетчеризации пакетов экземплярам LFB с разной инкапсуляцией в соответствии с L3PortID.
MTU — максимальный размер блока на выходном порту.
NextHopIPAddr — адрес IPv6.
MediaEncapInfoIndex передается нисходящему LFB инкапсуляции и служит ключом поиска в таблице (обычно связанной с инкапсуляцией для разных сред). Отметим, что экземпляр LFB инкапсуляции, использующий эти метаданные, может не следовать непосредственно за данным LFB в процессе обработки. Метаданные MediaEncapInfoIndex добавляются к пакету и передаются через промежуточные LFB, пока не будут применены экземпляром LFB инкапсуляции. В зависимости от реализации CE может устанавливать для MediaEncapInfoIndex, передаваемого в нисходящем направлении, значение, которое будет приводить к отказу при поиске в целевом LFB инкапсуляции. Это будет говорить о том, что нужно дополнительное распознавание. Пример этого показан в параграфе 7.2, где обсуждается протокол ARP.
LFBOutputSelectIndex является индексом группового выходного порта LFB для выбора порта нисходящего LFB. Это значение указывает конкретный порт группы SuccessOut, через который будет выводиться пакет с найденной информацией next-hop.

5.3.4.3. Возможности

У этого LFB нет списка возможностей.

5.3.4.4. События

Этот LFB не задает каких-либо событий.

5.4. LFB для перенаправления

LFB для перенаправления абстрагируют процесс транспортировки пакетов между CE и FE. Часть пакетов из некоторых LFB может доставляться в CE для дополнительной обработки, а некоторые пакеты, создаваемые CE, могут доставляться FE и далее в конкретные LFB пути обработки данных. В соответствии с [RFC5810] пакеты данных и связанные с ними метаданные инкапсулируются в сообщение ForCES (redirect) для транспортировки между CE и FE. Здесь определяются два LFB для абстрагирования этого процесса RedirectIn LFB и RedirectOut LFB. Обычно в топологии LFB элемента FE имеется один экземпляр RedirectIn LFB и один экземпляр RedirectOut LFB.

5.4.1. RedirectIn

RedirectIn LFB абстрагирует процесс вставки элементом CE пакетов данных в путь данных FE.

5.4.1.1. Обработка данных

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

Единственный выходной порт LFB определен как групповой порт с именем PktsOut. Пакеты из этого порта могут иметь произвольный тип кадров, выбираемый CE, который создает эти пакеты. Эти кадры могут содержать пакеты протоколов IPv4, IPv6 или ARP. CE может связать с типом кадра те или иные метаданные, а также связать с пакетом метаданные, содержащие различную информацию о пакете. Среди них должны присутствовать метаданные RedirectIndex, которые указывают целочисленный индекс. Когда CE передает метаданные с пакетом в RedirectIn LFB, этот LFB будет выводить пакет в один из выходных портов группы в соответствии с индексом порта, указанным RedirectIndex. Все остальные метаданные будут передаваться в неизменном виде вместе с полученным от CE пакетом нисходящему LFB. Это означает, что метаданные RedirectIndex от CE будут «поглощаться» RedirectIn LFB без передачи нисходящему LFB. Отметим, что пакеты от CE без метаданных RedirectIndex будут отбрасываться этим LFB. Все метаданные, видимые LFB, должны быть глобальными и контролируются IANA. Пространства идентификаторов метаданных описаны в разделе 8 с указанием идентификаторов выделенных производителям и для частного применения.

5.4.1.2. Компоненты

Для сбора статистики числа принятых этим LFB от CE пакетов определена необязательная компонента. Других компонент этот LFB в текущей версии не имеет.

5.4.1.3. Возможности

У этого LFB нет списка возможностей.

5.4.1.4. События

Этот LFB не задает каких-либо событий.

5.4.2. RedirectOut

RedirectOut LFB абстрагирует процесс для LFB в FE, которые служат для доставки пакетов в CE.

5.4.2.1. Обработка данных

RedirectOut LFB абстрагирует процесс для LFB в FE, которые служат для доставки пакетов в CE. С точки зрения топологии LFB блок RedirectOut LFB действует как точка сбора пакетов данных, идущих в CE, поэтому RedirectOut LFB определен с одним входным портом и без выходных портов.

RedirectOut LFB имеет единственный одиночный вход PktsIn, но может получать пакеты от множества LFB с помощью мультиплексирования на этом порту. На входе принимаются любые типы кадров, поэтому тип может быть указан как произвольный. Принимаются также все типы метаданных. Все связанные с пакетом метаданные созданные (но не поглощенные) предыдущими LFB, следует доставлять CE в сообщения ForCES redirect [RFC5810]. CE может выбирать способ обработки пакета в соответствии со связанными метаданными. Например, пакет может быть перенаправлен из FE в CE в результате неспособности EtherEncap LFB распознать информацию L2. Метаданные ExceptionID, созданные EtherEncap LFB, передаются вместе с пакетом и элементу CE их должно быть достаточно для требуемой обработки и распознавания нужной записи L2. Отметим, что все метаданные, видимы LFB, должны быть глобальными и контролируемыми IANA. Пространства идентификаторов метаданных описаны в разделе 8 с указанием идентификаторов выделенных производителям и для частного применения.

5.4.2.2. Компоненты

Для сбора статистики числа переданных этим LFB элементу CE пакетов определена необязательная компонента. Других компонент этот LFB в текущей версии не имеет.

5.4.2.3. Возможности

У этого LFB нет списка возможностей.

5.4.2.4. События

Этот LFB не задает каких-либо событий.

5.5. LFB общего назначения

5.5.1. BasicMetadataDispatch

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

5.5.1.1. Обработка данных

BasicMetadataDispatch LFB имеет единственный одиночный вход PktsIn. С каждым пакетом следует связывать метаданные, которые LFB будет применять для диспетчеризации. Этот LFB содержит идентификатор метаданных и таблицу диспетчеризации MetadataDispatchTable, настраиваемые элементом CE. Идентификатор указывает метаданные, которые будут служить для диспетчеризации пакета. таблица MetadataDispatchTable содержит записи со значениями метаданных и OutputIndex, указывающим в какой экземпляр группы выходных портов этого LFB нужно передать пакет с таким значением метаданных.

В LFB определены два выходных порта.

Групповой порт PktsOut служит для передачи пакетов, по значению метаданных которых был найден OutputIndex, в порт с соответствующим индексом.

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

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

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

В настоящее время BasicMetadataDispatch LFB поддерживает в таблице диспетчеризации лишь целочисленные 32-битовые значения метаданных. В будущих версиях библиотеки могут быть определены более сложные метаданные. В этом LFB может поддерживаться множество наборов метаданных для диспетчеризации пакетов.

5.5.1.2. Компоненты

LFB имеет две компоненты — MetadataID и MetadataDispatchTable. Каждая запись таблицы диспетчеризации является структурой, содержащей значение метаданных и OutputIndex. Отметим, что в настоящее время поддерживаются лишь целочисленные 32-битовые значения метаданных. Значение метаданных служит также ключом содержимого таблицы, как указано в модели ForCES FE [RFC5812]. С помощью ключей содержимого CE может манипулировать таблицей, используя конкретное значение метаданных, а не только индекс таблицы. Информация о ключах содержимого и работе с ними приведена в модели ForCES FE [RFC5812] и спецификации протокола ForCES [RFC5810].

5.5.1.3. Возможности

У этого LFB нет списка возможностей.

5.5.1.4. События

Этот LFB не задает каких-либо событий.

5.5.2. GenericScheduler

Это предварительный LFB базового планировщика для процессов расписания.

5.5.2.1. Обработка данных

Имеется множество стратегий планирования с разными реализациями. Являясь базовой библиотекой, данный документ определяет лишь предварительный базовый планировщик для абстрагирования простого расписания. Пользователи могут применять этот LFB в качестве базы для создания более сложных LFB планировщиков с помощью «наследования», описанного в [RFC5812].

Пакеты с произвольным типом кадров принимаются групповым входом PktsIn без ожидания дополнительных метаданных. Групповой вход поддерживает множество экземпляров входных портов, каждый из которых может быть соединен со своим выходом восходящего LFB. Внутри LFB каждый входной порт абстрактно соединен с очередью, имеющей идентификатор, значение которого совпадает с индексом соответствующего экземпляра входного порта. Ко всем очередям и пакетам в них применяются дисциплины планирования. Свойство группового входного порта PortGroupLimits в ObjectLFB, определенное в модели ForCES FE [RFC5810], обеспечивает CE возможность запросить общее число очередей, поддерживаемых планировщиком. Затем CE может решить, сколько очередей может применяться при планировании.

Пакеты выводятся по расписанию через одиночный выходной порт PktsOut без соответствующих метаданных.

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

5.5.2.2. Компоненты

SchedulingDiscipline используется CE для задания дисциплины планирования данного LFB. В настоящее время поддерживается лишь стратегия циклического перебора (RR¹⁹), которая и применяется по умолчанию.

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

5.5.2.3. Возможности

В настоящее время для GenericScheduler определена единственная возможность:

предельный размер для каждой очереди.

5.5.2.4. События

Этот LFB не задает каких-либо событий.

6. XML для библиотеки LFB

<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     provides="BaseLFBLibrary">
   <load library="BaseTypeLibrary"/>
   <LFBClassDefs>
      <LFBClassDef LFBClassID="3">
         <name>EtherPHYCop</name>
         <synopsis>
           EtherPHYCop LFB описывает интерфейс Ethernet, который
           ограничивает физические среды электрическими кабелями.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>EtherPHYIn</name>
               <synopsis>
                 Входной порт EtherPHYCop LFB, принимающий все типы
                 кадров Ethernet.
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>EtherPHYOut</name>
               <synopsis>
                 Выходной порт EtherPHYCop LFB. Выходной пакет имеет
                 тот же тип кадре Ethernet, который был у входного 
                 пакета, связанного с метаданными, указывающими 
                 идентификатор физического порта.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-only">
               <name>PHYPortID</name>
               <synopsis>Идентификация физического порта</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2" access="read-write">
               <name>AdminStatus</name>
               <synopsis>
                 Запрошенный административно статус порта
               </synopsis>
               <typeRef>PortStatusType</typeRef>
               <defaultValue>2</defaultValue>
            </component>
            <component componentID="3" access="read-only">
               <name>OperStatus</name>
               <synopsis>Реальное рабочее состояние порта</synopsis>
               <typeRef>PortStatusType</typeRef>
            </component>
            <component componentID="4" access="read-write">
               <name>AdminLinkSpeed</name>
               <synopsis>
                 Административно запрошенная скорость порта
               </synopsis>
               <typeRef>LANSpeedType</typeRef>
               <defaultValue>LAN_SPEED_AUTO</defaultValue>
            </component>
            <component componentID="5" access="read-only">
               <name>OperLinkSpeed</name>
               <synopsis>Реальная рабочая скорость порта</synopsis>
               <typeRef>LANSpeedType</typeRef>
            </component>
            <component componentID="6" access="read-write">
               <name>AdminDuplexMode</name>
               <synopsis>
                 Запрошенный административно режим дуплекса
               </synopsis>
               <typeRef>DuplexType</typeRef>
               <defaultValue>Auto</defaultValue>
            </component>
            <component componentID="7" access="read-only">
               <name>OperDuplexMode</name>
               <synopsis>Реальный рабочий режим дуплекса</synopsis>
               <typeRef>DuplexType</typeRef>
            </component>
            <component componentID="8" access="read-only">
               <name>CarrierStatus</name>
               <synopsis>Состояние несущей на порту</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
         </components>
         <capabilities>
            <capability componentID="30">
               <name>SupportedLinkSpeed</name>
               <synopsis>Список поддерживаемых портом скоростей</synopsis>
               <array>
                  <typeRef>LANSpeedType</typeRef>
               </array>
            </capability>
            <capability componentID="31">
               <name>SupportedDuplexMode</name>
               <synopsis>
                 Список поддерживаемых портом режимов дуплекса
               </synopsis>
               <array>
                  <typeRef>DuplexType</typeRef>
               </array>
            </capability>
         </capabilities>
         <events baseID="60">
            <event eventID="1">
               <name>PHYPortStatusChanged</name>
               <synopsis>
                 Событие, указывающее смену рабочего состояния
                 физического порта.
               </synopsis>
               <eventTarget>
                  <eventField>OperStatus</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperStatus</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="2">
               <name>LinkSpeedChanged</name>
               <synopsis>
                 Событие, указывающее смену рабочей скорости 
                 на физическом порту.
               </synopsis>
               <eventTarget>
                  <eventField>OperLinkSpeed</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperLinkSpeed</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="3">
               <name>DuplexModeChanged</name>
               <synopsis>
                 Событие, указывающее смену режима дуплекса
                 на физическом порту.
               </synopsis>
               <eventTarget>
                  <eventField>OperDuplexMode</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperDuplexMode</eventField>
                  </eventReport>
               </eventReports>
            </event>
         </events>
      </LFBClassDef>
      <LFBClassDef LFBClassID="4">
         <name>EtherMACIn</name>
         <synopsis>
           EtherMACIn LFB описывает порт Ethernet на уровне MAC.
           LFB описывает функции обработки Ethernet при проверке
           местоположения MAC-адреса, принятии решения о применении
           функций моста Ethernet, управления потоком данных на
           уровне Ethernet и т. п.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>EtherPktsIn</name>
               <synopsis>
                 Входной порт EtherMACIn LFB. Предполагаются любые
                 типы кадров Ethernet.
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalPathOut</name>
               <synopsis>
                 Выходной порт EtherMACIn LFB. Выводит пакеты Ethernet
                 в нисходящий LFB для обычной обработки, такой как 
                 классификация Ethernet и обработка L3 IP.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>L2BridgingPathOut</name>
               <synopsis>
                 Выходной порт EtherMACIn LFB. Выводит пакеты
                 Ethernet в нисходящие LFB для выполнения функций 
                 моста L2. Этот порт включается и отключается
                 флагом L2BridgingPathEnable в LFB.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>
                  Административно запрошенное состояние LFB, имеющее такой
                  же тип данных как статус порта. По умолчанию Down.
               </synopsis>
               <typeRef>PortStatusType</typeRef>
               <defaultValue>2</defaultValue>
            </component>
            <component componentID="2" access="read-write">
               <name>LocalMACAddresses</name>
               <synopsis>
                 Локальные MAC-адреса порта Ethernet, представленного LFB.
               </synopsis>
               <array>
                  <typeRef>IEEEMAC</typeRef>
               </array>
            </component>
            <component componentID="3" access="read-write">
               <name>L2BridgingPathEnable</name>
               <synopsis>
                 Флаг, указывающий состояние выходного порта LFB L2 
                 BridgingPath. По умолчанию порт выключен.
               </synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="4" access="read-write">
               <name>PromiscuousMode</name>
               <synopsis>
                 Флаг, указывающий состояние неразборчивого режима
                 LFB. По умолчанию выключен.
               </synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="5" access="read-write">
               <name>TxFlowControl</name>
               <synopsis>
                 Флаг, указывающий состояние управления потоком 
                 данных на выходе. По умолчанию выключено.
               </synopsis>
               <optional/>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="6" access="read-write">
               <name>RxFlowControl</name>
               <synopsis>
                 Флаг, указывающий состояние управления потоком 
                 данных на входе. По умолчанию выключено.
               </synopsis>
               <optional/>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="7" access="read-reset">
               <name>MACInStats</name>
               <synopsis>Статистика EtherMACIn LFB</synopsis>
               <optional/>
               <typeRef>MACInStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="5">
         <name>EtherClassifier</name>
         <synopsis>
           EtherClassifier LFB описывает процесс декапсуляции пакетов
           Ethernet и их классификации по протоколам сетевого уровня
           в соответствии с заголовками Ethernet. Предполагается, что
           LFB классифицирует пакеты IPv4, IPv6, MPLS, ARP, ND и т. п.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>EtherPktsIn</name>
               <synopsis>
                 Входной порт пакетов Ethernet. Метаданные PHYPortID 
                 предполагаются всегда, а LogicalPortID - опциональны
                 для входящих пакетов Ethernet.
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                     <ref dependency="optional" defaultValue="0">
                        LogicalPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>ClassifyOut</name>
               <synopsis>
                 Групповой порт для вывода результатов классификации 
                 Ethernet.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                     <ref>SrcMAC</ref>
                     <ref>DstMAC</ref>
                     <ref>EtherType</ref>
                     <ref availability="conditional">VlanID</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Отдельный порт для вывода всех пакетов Ethernet с 
                 отказом при классификации. Метаданные ExceptionID 
                 указывают причину отказа.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>EtherDispatchTable</name>
               <synopsis>
                 Элемент массива EtherDispatchTable, определенного в
                 LFB для диспетчеризации каждого пакета Ethernet в 
                 выходные порты по идентификатору логического порта
                 назначенному VlanInputTable в LFB и типу Ethernet в
                 заголовке пакета Ethernet.
               </synopsis>
               <typeRef>EtherDispatchTableType</typeRef>
            </component>
            <component access="read-write" componentID="2">
               <name>VlanInputTable</name>
               <synopsis>
                 Элемент массива VlanInputTable, определенного в LFB для
                 классификации пакетов VLAN Ethernet. Каждому входному
                 пакету назначается новый LogicalPortID в соответствии
                 с идентификатором входного порта и VLAN ID.
               </synopsis>
               <typeRef>VlanInputTableType</typeRef>
            </component>
            <component access="read-reset" componentID="3">
               <name>EtherClassifyStats</name>
               <synopsis>
                 Таблица статистики процесса классификации Ethernet
                 в LFB.
               </synopsis>
               <optional/>
               <typeRef>EtherClassifyStatsTableType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="6">
         <name>EtherEncap</name>
         <synopsis>
           EtherEncap LFB абстрагирует процесс инкапсуляции заголовков
           Ethernet в принятые пакеты на основе полученных метаданных.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>EncapIn</name>
               <synopsis>
                 Входной порт, получающий пакеты IPv4 и/или IPv6 для
                 инкапсуляции. Ожидаются метаданные MediaEncapInfoIndex 
                 для каждого пакета и могут присутствовать метаданные 
                 приоритета VLAN.
               </synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4</ref>
                  <ref>IPv6</ref>
               </frameExpected>
               <metadataExpected>
                  <ref>MediaEncapInfoIndex</ref>
                  <ref dependency="optional" defaultValue="0">
                  VlanPriority</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>SuccessOut</name>
               <synopsis>
                 Выходной порт для пакетов, в которых найдена информация 
                 Ethernet L2 и которые успешно инкапсулированы в пакеты 
                 Ethernet. Для каждого выходного пакета создаются 
                 метаданные L2PortID.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L2PortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Выходной порт для пакетов с отказом при инкапсуляции в 
                 LFB. метаданные ExceptionID указывают причину отказа.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                     <ref>MediaEncapInfoIndex</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>EncapTable</name>
               <synopsis>
                 Таблица для поиска данных инкапсуляции Ethernet, каждая 
                 строка которой содержит MAC-адреса отправителя и
                 получателя, VLAN ID, и идентификатор выходного 
                 логического порта L2.
               </synopsis>
               <typeRef>EncapTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="7">
         <name>EtherMACOut</name>
         <synopsis>
           EtherMACOut LFB абстрагирует порт Ethernet на уровне MAC и
           описывает обработку пакетов Ethernet для вывода в физический
           порт. Нисходящим LFB обычно является физический Ethernet 
           LFB, такой как EtherPHYCop LFB. Отметим, что выходные функции
           Ethernet тесно связаны со входными, поэтому некоторые 
           компоненты этого LFB являются псевдонимами компонент EtherMACIn.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>EtherPktsIn</name>
               <synopsis>
                 Входной порт EtherMACOut LFB. Принимает все типы
                 кадров Ethernet.
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>EtherPktsOut</name>
               <synopsis>
                 Порт для вывода всех пакетов Ethernet, каждый из
                 которых имеет метаданные, указывающие идентификатор
                 физического порта, через который пакет должен пройти.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>
                 Административно запрошенное состояние LFB, совпадающее
                 по типу данных с состоянием порта. Компонента 
                 определена как псевдоним AdminStatus из EtherMACIn LFB.
               </synopsis>
               <alias>PortStatusType</alias>
            </component>
            <component componentID="2" access="read-write">
               <name>MTU</name>
               <synopsis>максимальный передаваемый блок (MTU) </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3" access="read-write">
               <name>TxFlowControl</name>
               <synopsis>
                 Флаг, указывающий применение контроля потока данных при
                 передаче. Определен как псевдоним TxFlowControl из
                 EtherMACIn LFB.
               </synopsis>
               <optional/>
               <alias>boolean</alias>
            </component>
            <component componentID="4" access="read-write">
               <name>RxFlowControl</name>
               <synopsis>
                 Флаг, указывающий применение контроля потока данных на
                 приеме. Определен как псевдоним RxFlowControl из
                 EtherMACIn LFB.
               </synopsis>
               <optional/>
               <alias>boolean</alias>
            </component>
            <component componentID="5" access="read-reset">
               <name>MACOutStats</name>
               <synopsis>Статистика EtherMACOut LFB</synopsis>
               <optional/>
               <typeRef>MACOutStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="8">
         <name>IPv4Validator</name>
         <synopsis>
          Этот LFB проверяет пакеты IPv4 в соответствии с RFC 1812 и
          обновлениями. Пакет IPv4 будет выводиться в соответствующий 
          порт LFB, показывающий, является пакет индивидуальным или
          групповым и возникли ли исключительные ситуации или отказы
          при проверке.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>ValidatePktsIn</name>
               <synopsis>Входной порт для проверяемых пакетов</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>IPv4UnicastOut</name>
               <synopsis>
                 Выходной порт для прошедших проверку индивидуальных пакетов IPv4
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>IPv4MulticastOut</name>
               <synopsis>
                 Выходной порт для прошедших проверку групповых пакетов IPv4
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Multicast</ref>
                  </frameProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>ExceptionOut</name>
               <synopsis>
                 Выходной порт для всех пакетов с исключительными случаями
                 при проверке. Метаданные ExceptionID указывают тип
                 исключительного случая.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>FailOut</name>
               <synopsis>
                 Выходной порт для пакетов с отказом при проверке.
                 Метаданные ValidateErrorID указывают тип или причину отказа.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ValidateErrorID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv4ValidatorStats</name>
               <synopsis>Статистика для процесса проверки в LFB.</synopsis>
               <optional/>
               <typeRef>IPv4ValidatorStatsType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="9">
         <name>IPv6Validator</name>
         <synopsis>
          Этот LFB проверяет пакеты IPv6 в соответствии с RFC 2460 и
          обновлениями. Пакет IPv6 будет выводиться в соответствующий 
          порт LFB, показывающий, является пакет индивидуальным или
          групповым и возникли ли исключительные ситуации или отказы
          при проверке.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>ValidatePktsIn</name>
               <synopsis>Входной порт для проверяемых пакетов</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>IPv6UnicastOut</name>
               <synopsis>
                 Выходной порт для прошедших проверку индивидуальных пакетов IPv6
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>IPv6MulticastOut</name>
               <synopsis>
                 Выходной порт для прошедших проверку групповых пакетов IPv6
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Multicast</ref>
                  </frameProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>ExceptionOut</name>
               <synopsis>
                 Выходной порт для всех пакетов с исключительными случаями
                 при проверке. Метаданные ExceptionID указывают тип
                 исключительного случая.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>FailOut</name>
               <synopsis>
                 Выходной порт для пакетов с отказом при проверке.
                 Метаданные ValidateErrorID указывают тип или причину отказа.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ValidateErrorID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv6ValidatorStats</name>
               <synopsis>
               <synopsis>Статистика для процесса проверки в LFB.</synopsis>
               </synopsis>
               <optional/>
               <typeRef>IPv6ValidatorStatsType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="10">
         <name>IPv4UcastLPM</name>
         <synopsis>
           IPv4UcastLPM LFB абстрагирует процесс IPv4 поиска LPM. 
           LFB поддерживает реализации маршрутизации ECMP и
           пересылки по обратному пути (RPF).
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>
                 Порт для получения обрабатываемых пакетов.
                 Предполагаются индивидуальные пакеты IPv4.
               </synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4Unicast</ref>
               </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalOut</name>
               <synopsis>
                 Порт для вывода индивидуальных пакетов IPv4, прошедших
                 поиск LPM. Создаются метаданные HopSelector для
                 привязки каждого выходного пакета в нисходящему LFB
                 для действия next-hop.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ECMPOut</name>
               <synopsis>
                 Порт для вывода пакетов, требующих дополнительной
                 обработки ECMP. За этим портом обычно следует 
                 нисходящий LFB обработки ECMP. Если ECMP не требуется,
                 к порту не подключаться нисходящий LFB.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Порт для вывода всех пакетов с исключительными случаями
                 в процессе LPM. Метаданные ExceptionID указывают
                 причину исключения.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>IPv4PrefixTable</name>
               <synopsis>
                 Таблица для максимального соответствия префикса IPv4 
                 (LPM). Адрес получателя IPv4 каждого входного пакета 
                 служит ключом поиска в таблице селектора next-hop.
               </synopsis>
               <typeRef>IPv4PrefixTableType</typeRef>
            </component>
            <component componentID="2" access="read-reset">
               <name>IPv4UcastLPMStats</name>
               <synopsis>
                 Статистика процесса LPM для индивидуальных адресов IPv4.
               </synopsis>
               <optional/>
               <typeRef>IPv4UcastLPMStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="11">
         <name>IPv6UcastLPM</name>
         <synopsis>
           IPv6UcastLPM LFB абстрагирует процесс поиска наиболее 
           длинного префикса (LPM) для индивидуального адреса IPv6. 
           LFB поддерживает реализацию ECMP и RPF.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>
                 Порт для ввода пакетов на обработку.
                 Предполагаются индивидуальные пакеты IPv6.
               </synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv6Unicast</ref>
               </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalOut</name>
               <synopsis>
                 Порт для вывода индивидуальных пакетов IPv6, прошедших
                 поиск LPM. Создаются метаданные HopSelector для
                 привязки каждого выходного пакета в нисходящему LFB
                 для действия next-hop.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ECMPOut</name>
               <synopsis>
                 Порт для вывода пакетов, требующих дополнительной
                 обработки ECMP. За этим портом обычно следует 
                 нисходящий LFB обработки ECMP. Если ECMP не требуется,
                 к порту не подключаться нисходящий LFB.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Порт для вывода всех пакетов с исключительными случаями
                 в процессе LPM. Метаданные ExceptionID указывают
                 причину исключения.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>IPv6PrefixTable</name>
               <synopsis>
                 Таблица для максимального соответствия префикса IPv6 
                 (LPM). Адрес получателя IPv6 каждого входного пакета 
                 служит ключом поиска в таблице селектора next-hop.
               </synopsis>
               <typeRef>IPv6PrefixTableType</typeRef>
            </component>
            <component componentID="2" access="read-reset">
               <name>IPv6UcastLPMStats</name>
               <synopsis>
                 Статистика процесса LPM для индивидуальных адресов IPv6.
               </synopsis>
               <optional/>
               <typeRef>IPv6UcastLPMStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="12">
         <name>IPv4NextHop</name>
         <synopsis>
           IPv4NextHop LFB абстрагирует процесс обработки next-hop
           применительно к пакетам IPv4. Он получает пакеты IPv4 с
           идентификатором next-hop (HopSelector) и использует 
           идентификатор в качестве индекса для поиска в таблице 
           next-hop подходящего выходного порта. Обработка также 
           включает декремент TTL и пересчет контрольной суммы IP.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>
                 Порт для ввода индивидуальных пакетов IPv4 с
                 метаданными HopSelector.
               </synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4Unicast</ref>
               </frameExpected>
               <metadataExpected>
                  <ref>HopSelector</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>SuccessOut</name>
               <synopsis>
                 Порт для вывода пакетов с найденным next-hop. С каждым
                 пакетом связаны те или иные метаданные.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L3PortID</ref>
                     <ref>NextHopIPv4Addr</ref>
                     <ref availability="conditional">
                     MediaEncapInfoIndex</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Выходной порт для пакетов с исключительными случаями.
                 ExceptionID указывает причину исключения.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1">
               <name>IPv4NextHopTable</name>
               <synopsis>
                 Компонента IPv4NextHopTable. HopSelector служит для
                 сопоставления с индексом таблицы при поиске строки,
                 содержащей информацию next-hop.
               </synopsis>
               <typeRef>IPv4NextHopTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="13">
         <name>IPv6NextHop</name>
         <synopsis>
           Этот LFB абстрагирует процесс обработки next-hop
           применительно к пакетам IPv6. Он получает пакеты IPv6 с
           идентификатором next-hop (HopSelector) и использует 
           идентификатор в качестве индекса для поиска в таблице 
           next-hop подходящего выходного порта. 
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>
                 Порт для ввода индивидуальных пакетов IPv6 с
                 метаданными HopSelector.
                </synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv6Unicast</ref>
               </frameExpected>
               <metadataExpected>
                  <ref>HopSelector</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>SuccessOut</name>
               <synopsis>
                 Порт для вывода пакетов с найденным next-hop. С каждым
                 пакетом связаны те или иные метаданные.
                </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L3PortID</ref>
                     <ref>NextHopIPv6Addr</ref>
                     <ref availability="conditional">
                     MediaEncapInfoIndex</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Выходной порт для пакетов с исключительными случаями.
                 ExceptionID указывает причину исключения.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1">
               <name>IPv6NextHopTable</name>
               <synopsis>
                 Компонента IPv6NextHopTable. HopSelector служит для
                 сопоставления с индексом таблицы при поиске строки,
                 содержащей информацию next-hop.
               </synopsis>
               <typeRef>IPv6NextHopTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="14">
         <name>RedirectIn</name>
         <synopsis>
           RedirectIn LFB абстрагирует для ForCES CE процесс
           вставки пакетов в ForCES FE LFB.
         </synopsis>
         <version>1.0</version>
         <outputPorts>
            <outputPort group="true">
               <name>PktsOut</name>
               <synopsis>
                 Выходной порт RedirectIn LFB, являющийся групповым.
                 С точки зрения топологии LFB этот порт служит точкой
                 входа пакетов данных от CE, поэтому LFB определен с
                 одним выходным портом и не имеет входных портов.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1">
               <name>NumPacketsReceived</name>
               <synopsis>Число пакетов, принятых от CE.</synopsis>
               <optional/>
               <typeRef>uint64</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="15">
         <name>RedirectOut</name>
         <synopsis>
           RedirectOut LFB абстрагирует в LFB процесс передачи пакетов
           из ForCES FE в ForCES CE.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>
                 Входной порт RedirectOut LFB. С точки зрения топологии 
                 LFB блок RedirectOut LFB служит точкой сбора пакетов
                 данных, идущих в CE, поэтому RedirectOut LFB определен
                 с одним входным портом (без выходных).
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <components>
            <component componentID="1">
               <name>NumPacketsSent</name>
               <synopsis>Число пакетов, переданных CE.</synopsis>
               <optional/>
               <typeRef>uint64</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="16">
         <name>BasicMetadataDispatch</name>
         <synopsis>
           BasicMetadataDispatch LFB определен как абстракция процесса
           диспетчеризации пакетов в разные выходные пути на основе
           метаданных. В настоящее время этот LFB поддерживает лишь
           32-битовые целочисленные значения метаданных.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>PktsIn</name>
               <synopsis>
                 Входной порт для диспетчеризации пакетов. Каждый входной
                 пакет должен быть связан с метаданными, которые будет 
                 применяться LFB для диспетчеризации.
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>Arbitrary</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>PktsOut</name>
               <synopsis>
                 Групповой выходной порт для вывода результатов
                 диспетчеризации. Пакет со связанными метаданными,
                 для которого найден OutputIndex в таблице
                 диспетчеризации, будет выведен в экземпляр группового
                 порта в соответствии с индексом.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>
                 Выходной порт для пакетов с отказом при обработке.
                 Метаданные ExceptionID указывают причину исключения.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>MetadataID</name>
               <synopsis>
                 Идентификатор метаданных для использования 
                 при диспетчеризации пакетов.
               </synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component access="read-write" componentID="2">
               <name>MetadataDispatchTable</name>
               <synopsis>
                 Компонента MetadataDispatchTable, содержащая значение
                 метаданных и выходной индекс, указывающие, что пакет
                 с таким значением метаданных нужно передать через порт
                 с найденным индексом группового выходного порта LFB.
               </synopsis>
               <typeRef>MetadataDispatchTableType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="17">
         <name>GenericScheduler</name>
         <synopsis>
           Предварительный базовый планировщик, абстрагирующий 
           простой процесс планирования, который может служить
           базовым LFB для создания более сложных планировщиков.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="true">
               <name>PktsIn</name>
               <synopsis>
                 Групповой входной порт LFB. Внутри LFB каждый
                 экземпляр группового порта соединен с очередью,
                 идентификатор которой совпадает с индексом экземпляра.
               </synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>PktsOut</name>
               <synopsis>
                 Выходной порт для вывода пакетов из планировщика.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>SchedulingDiscipline</name>
               <synopsis>
                 SchedulingDiscipline применяется CE для указания
                 LFB дисциплины планирования.
               </synopsis>
               <typeRef>SchdDisciplineType</typeRef>
               <defaultValue>1</defaultValue>
            </component>
            <component access="read-only" componentID="2">
               <name>QueueStats</name>
               <synopsis>
                 QueueStats позволяет CE запросить статистику 
                 каждой очереди в планировщике.
               </synopsis>
               <optional/>
               <typeRef>QueueStatsTableType</typeRef>
            </component>
         </components>
         <capabilities>
            <capability componentID="30">
               <name>QueueLenLimit</name>
               <synopsis>
                 Возможность QueueLenLimit указывает максимальный
                 размер каждой очереди в байтах.
               </synopsis>
               <typeRef>uint32</typeRef>
            </capability>
         </capabilities>
       </LFBClassDef>
   </LFBClassDefs>
</LFBLibrary>

7. Примеры использования классов LFB

В этом разделе приведены примеры использования классов LFB, определенной в разделе 6 базовой библиотеки LFB, для реализации некоторых типовых функций маршрутизации, включая:

пересылку IPv4;
обработку ARP.

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

Рассмотренные здесь случаи являются просто примерами и не могут считаться единственным вариантом реализации функций маршрутизатора из LFB. На основе возможностей FE элемент CE должен быть способен выразить различные варианты реализации NE.

7.1. Пересылка IPv4

На рисунке 2 показан типичный путь обработки при пересылке индивидуальных пакетов IPv4 в среде с интерфейсами Ethernet на основе базовых классов LFB. Отметим, что на этом рисунке не показаны некоторые входы и выходы, не относящиеся напрямую к функции пересылки IPv4. Например, EtherClassifier LFB обычно имеет два выходных порта — групповой ClassifyOut и одиночный ExceptionOut, при этом групповой порт имеет множество разных экземпляров выходных портов в соответствии с классификацией пакетов (параграф 5.1.3). На рисунке показаны лишь выходные порты для пакетов IPv4 и IPv6, чтобы лучше проиллюстрировать функцию пересылки IPv4.

+-----+                +------+
|     |                |      |
|     |<---------------|Ether |<----------------------------+
|     |                |MACOut|                             |
|     |                |      |                             |
|Ether|                +------+                             |
|PHY  |                                                     |
|Cop  |            +---+                                    |
|#1   |  +-----+   |   |-----> Пакеты IPv6                  |
|     |  |     |   |   |                                    |
|     |  |Ether|   |   | Пакеты IPv4                        |
|     |->|MACIn|-->|   |-+  +----+                          |
+-----+  |     |   |   | |  |    |---> Групповые пакеты     |
         +-----+   +---+ |  |    |        +-----+  +---+    |
                   Ether +->|    |------->|     |  |   |    |
   .           Classifier|  |    |Индивид.|IPv4 |  |   |    |
   .                     |  |    |пакеты  |Ucast|->|   |--+ |
   .                     |  +----+        |LPM  |  |   |  | |
                   +---+ |   IPv4         +-----+  +---+  | |
         +-----+   |   | |   Validator              IPv4  | |
         |     |   |   | |                         NextHop| |
+-----+  |Ether|   |   |-+ Пакеты IPv4                    | |
|     |->|MACIn|-->|   |                                  | |
|     |  |     |   |   |-----> Пакеты IPv6                | |
|Ether|  +-----+   +---+                                  | |
|PHY  |           Ether               +----+              | |
|Cop  |           Classifier          |    |   +-------+  | |
|#n   |                +------+       |    |   |Ether  |  | |
|     |                |      |       |    |<--|Encap  |<-+ |
|     |                |      |<------|    |   |       |    |
|     |<---------------|Ether |    ...|    |   +-------+    |
|     |                |MACOut|   +---|    |                |
|     |                |      |   |   +----+                |
+-----+                +------+   | BasicMetadataDispatch   |
                                  +----------->-------------+

Рисунок 2. Пример использования LFB для пересылки IPv4.

В этом примере использования LFB множество экземпляров EtherPHYCop LFB (параграф 5.1.1) служит для описания функций физического уровня в портах. Метаданные PHYPortID создаются EtherPHYCop LFB и применяется всеми последующими нисходящими LFB. Блок EtherMACIn LFB (параграф 5.1.2), описывающий обработку на уровне MAC, следует за каждым EtherPHYCop LFB. Блок EtherMACIn LFB может проверять местоположение MAC-адресов, если CE настроит соответствующую компоненту EtherMACIn LFB.

Пакеты Ethernet из EtherMACIn LFB передаются в EtherClassifier LFB (параграф 5.1.3) для декапсуляции и классификации по протоколам сетевого уровня (IPv4, IPv6, ARP и т. п.). В приведенном примере каждый физический интерфейс Ethernet связан с одним интерфейсом Classifier. Здесь это не показано, но желательно связать все физические интерфейсы с единственным экземпляром Ethernet Classifier.

EtherClassifier использует метаданные PHYPortID, тип Ethernet из входящего пакета и VlanID (при наличии) для определения типа сетевого уровня и выходного порта LFB к нисходящему LFB. Блок EtherClassifier LFB также задает новые метаданные с идентификатором логического порта для последующего использования. EtherClassifier может создавать для каждого пакета дополнительные метаданные, включая EtherType, SrcMAC, DstMAC, LogicPortID и т. п., потребляемые нисходящими LFB.

Если пакет классифицирован как IPv4, он передается нисходящему IPv4Validator LFB (параграф 5.2.1) для проверки, где пакеты IPv4 просматриваются на предмет пригодности и классифицируются как индивидуальные или групповые. Индивидуальные пакеты передаются в нисходящий IPv4UcastLPM LFB (параграф 5.3.1).

В IPv4UcastLPM LFB находится самый длинный совпадающий префикс и выбирается next-hop. Метаданные с идентификатором next-hop создаются IPv4UcastLPM LFB и потребляются IPv4NextHop LFB (параграф 5.3.2).

IPv4NextHop LFB использует идентификатор метаданных для определения выходного порта, типа инкапсуляции в среду и т. п. IPv4NextHop LFB создает метаданные L3PortID , служащие для идентификации выходного физического или логического порта для данного next-hop. В примере выходной порт следующего интервала имеет тип Ethernet, поэтому пакет и метаданные идентификатора порта L3 передаются нисходящему EtherEncap LFB (параграф 5.1.4).

EtherEncap LFB инкапсулирует входящий пакет в кадр Ethernet. Блок BasicMetadataDispatch LFB (параграф 5.5.1) следует за EtherEncap LFB и выполняет окончательную диспетчеризацию пакетов по физическим или логическим портам на основе полученных метаданных L3PortID.

7.2. Обработка ARP

На рисунке 3 показан процесс обработки пакета ARP для случая функций реализации обработки ARP в CE. Это не единственный вариант обработки ARP, которая может выполняться и в FE, но это выходит за рамки документа.

      +---+                             +---+
      |   | Пакеты ARP                  |   |
      |   |-------------->---------+--->|   | В CE
...-->|   | .                      |    |   |
      |   | .                      |    +---+
      |   | .                      |   RedirectOut
      +---+                        ^
      Ether     EtherEncap         | Пакеты IPv4 без информации
    Classifier   +---+             | ARP
                 |   |             |
Пакеты, требующие|   |--------->---+
    ...--------->|   |
 инкапсуляции L2 |   |
      +---+      |   |                     +------+
      |   |  +-->|   |--+   +---+          |Ether |
      |   |  |   +---+  |   |   |--------->|MACOut|-->...
 От CE|   |--+          +-->|   | .        +------+
      |   |Пакеты ARP       |   | .
      |   |от CE            |   | .        +------+
      |   |                 |   |--------> |Ether |-->...
      +---+                 +---+          |MACOut|
   RedirectIn            BasicMetadata     +------+
                         Dispatch

Рисунок 3. Пример использования LFB для ARP.

Имеется два пути запуска обработки ARP в CE, как показано на рисунке 3:

пакеты ARP, приходящие извне NE;
пакеты IPV4, не распознанные в FE.

Пакеты ARP от сетевых интерфейсов фильтруются EtherClassifier LFB. Классифицированные пакеты ARP и связанные с ними метаданные передаются нисходящему RedirectOut LFB (параграф 5.4.2) для пересылки CE.

EtherEncap LFB (параграф 5.1.4) получает пакеты, которым нужна инкапсуляция Ethernet L2. Когда EtherEncap LFB не может найти нужной информации L2 для инкапсуляции пакета, он выводит пакет в свой порт ExceptionOut LFB. Портом нисходящего для EtherEncap LFB блока ExceptionOut LFB является RedirectOut LFB, который передает пакет CE (параграф 5.1.4).

Для решения этой задачи CE нужно генерировать запросы и отклики ARP, а также передавать их во внешние сети (за пределы NE). Пакеты запросов и откликов ARP от CE передаются в FE с помощью RedirectIn LFB (параграф 5.4.1).

Как и в примере с пересылкой пакетов IPv4, исходящие пакеты ARP инкапсулируются в формат Ethernet блоком EtherEncap LFB, а затем диспетчеризуются по разным интерфейсам с помощью BasicMetadataDispatch LFB на основе метаданных L3PortID, включенных в каждый пакет ARP, переданный от CE.

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

Агентство IANA организовало реестр имен и идентификаторов ForCES LFB с размещением класса ForCES LFB в соответствии с правилами использования пространства имен.

Этот документ регистрирует уникальные имена и числовые идентификаторы LFB, перечисленные в разделе 8.1. Помимо этого документ определяет перечисленные ниже пространства имен.

Metadata ID (параграфы 4.3 и 4.4).
Exception ID (параграф 4.4).
Validate Error ID (параграф 4.4).

8.1. Имена и идентификаторы классов LFB

Классы LFB, определенные в этом документе, относятся к классам, определенным Standards Track RFC. В соответствии с правилами IANA используется процедура Standards Action для значений 0 — 65535 и First Come First Served для значений больше 65535.

Таблица 1. Имена и идентификаторы классов LFB.

Идентификатор класса LFB	Имя класса LFB	Описание	Документ
3	EtherPHYCop	Определяет абстракцию порта Ethernet на физическом уровне.	параграф 5.1.1
4	EtherMACIn	Определяет входной порт Ethernet на уровне MAC.	параграф 5.1.2
5	EtherClassifier	Задает процесс декапсуляции Ethernet и классификации пакетов.	параграф 5.1.3
6	EtherEncap	Определяет процесс инкапсуляции пакетов IP в Ethernet.	параграф 5.1.4
7	EtherMACOut	Определяет выходной порт Ethernet на уровне MAC.	параграф 5.1.5
8	IPv4Validator	Выполняет проверку пригодности пакетов IPv4.	параграф 5.2.1
9	IPv6Validator	Выполняет проверку пригодности пакетов IPv6.	параграф 5.2.2
10	IPv4UcastLPM	Выполняет поиск самого длинного совпадающего префикса IPv4.	параграф 5.3.1
11	IPv6UcastLPM	Выполняет поиск самого длинного совпадающего префикса IPv6.	параграф 5.3.3
12	IPv4NextHop	Определяет процесс выбора действия IPv4 next-hop.	параграф 5.3.2
13	IPv6NextHop	Определяет процесс выбора действия IPv6 next-hop.	параграф 5.3.4
14	RedirectIn	Определяет процесс вставки CE пакетов данных в топологию LFB.	параграф 5.4.1
15	RedirectOut	Определяет процесс для LFB в FE по доставке пакетов CE.	параграф 5.4.2
16	BasicMetadata	Диспетчеризует пакеты по выходным портам на базе метаданных.	параграф 5.5.1
17	GenericScheduler	Определяет процесс предварительного базового планирования.	параграф 5.5.2

8.2. Идентификаторы метаданных

Пространство имен Metadata ID имеет размер 32 бита. Рекомендации по распределению значений даны ниже.

Metadata ID из диапазона 0x00000001-0x7FFFFFFF выделяются по процедуре Specification Required [RFC5226] и должны быть документированы в RFC или других постоянно доступных документах.

Таблица 2. Идентификаторы метаданных.

Значение	Имя	Документ
0x00000000	Reserved	RFC 6956
0x00000001	PHYPortID	RFC 6956, параграф 4.4
0x00000002	SrcMAC	RFC 6956, параграф 4.4
0x00000003	DstMAC	RFC 6956, параграф 4.4
0x00000004	LogicalPortID	RFC 6956, параграф 4.4
0x00000005	EtherType	RFC 6956, параграф 4.4
0x00000006	VlanID	RFC 6956, параграф 4.4
0x00000007	VlanPriority	RFC 6956, параграф 4.4
0x00000008	NextHopIPv4Addr	RFC 6956, параграф 4.4
0x00000009	NextHopIPv6Addr	RFC 6956, параграф 4.4
0x0000000A	HopSelector	RFC 6956, параграф 4.4
0x0000000B	ExceptionID	RFC 6956, параграф 4.4
0x0000000C	ValidateErrorID	RFC 6956, параграф 4.4
0x0000000D	L3PortID	RFC 6956, параграф 4.4
0x0000000E	RedirectIndex	RFC 6956, параграф 4.4
0x0000000F	MediaEncapInfoIndex	RFC 6956, параграф 4.4
0x80000000-0xFFFFFFFF	Резерв для приватного использования	RFC 6956

8.3. Exception ID

Пространство имен Exception ID имеет размер 32 бита. Рекомендации по распределению значений даны ниже.

Exception ID из диапазона 0x00000001-0x7FFFFFFF выделяются по процедуре Specification Required [RFC5226] и должны быть документированы в RFC или других постоянно доступных документах.

Таблица 3. Идентификаторы исключительных ситуаций.

Значение	Имя	Документ
0x00000000	AnyUnrecognizedExceptionCase	параграф 4.4
0x00000001	ClassifyNoMatching	параграф 4.4
0x00000002	MediaEncapInfoIndexInvalid	параграф 4.4
0x00000003	EncapTableLookupFailed	параграф 4.4
0x00000004	BadTTL	параграф 4.4
0x00000005	IPv4HeaderLengthMismatch	параграф 4.4
0x00000006	RouterAlertOptions	параграф 4.4
0x00000007	IPv6HopLimitZero	параграф 4.4
0x00000008	IPv6NextHeaderHBH	параграф 4.4
0x00000009	SrcAddressException	параграф 4.4
0x0000000A	DstAddressException	параграф 4.4
0x0000000B	LPMLookupFailed	параграф 4.4
0x0000000C	HopSelectorInvalid	параграф 4.4
0x0000000D	NextHopLookupFailed	параграф 4.4
0x0000000E	FragRequired	параграф 4.4
0x0000000F	MetadataNoMatching	параграф 4.4
0x80000000-0xFFFFFFFF	Резерв для приватного использования	RFC 6956

8.4. Validate Error ID

Пространство имен Validate Error ID имеет размер 32 бита. Рекомендации по распределению значений даны ниже.

Validate Error ID из диапазона 0x00000000-0x7FFFFFFF из диапазона 0x00000001-0x7FFFFFFF выделяются по процедуре Specification Required [RFC5226] и должны быть документированы в RFC или других постоянно доступных документах.

Таблица 4. Идентификаторы ошибок при проверке пригодности.

Значение	Имя	Документ
0x00000000	AnyUnrecognizedValidateErrorCase	параграф 4.4
0x00000001	InvalidIPv4PacketSize	параграф 4.4
0x00000002	NotIPv4Packet	параграф 4.4
0x00000003	InvalidIPv4HeaderLengthSize	параграф 4.4
0x00000004	InvalidIPv4LengthFieldSize	параграф 4.4
0x00000005	InvalidIPv4Checksum	параграф 4.4
0x00000006	InvalidIPv4SrcAddr	параграф 4.4
0x00000007	InvalidIPv4DstAddr	параграф 4.4
0x00000008	InvalidIPv6PacketSize	параграф 4.4
0x00000009	NotIPv6Packet	параграф 4.4
0x0000000A	InvalidIPv6SrcAddr	параграф 4.4
0x0000000B	InvalidIPv6DstAddr	параграф 4.4
0x80000000-0xFFFFFFFF	Резерв для приватного использования	RFC 6956

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

Документ, определяющий схему ForCES [RFC3746], содержит рассмотрение вопросов безопасности всей архитектуры ForCES. Например, подлинность элементов протокола ForCES должна проверяться в соответствии с требованиями ForCES до предоставления им доступа к информационным элементам, описанным в этом документе, по протоколу ForCES. Спецификация ForCES [RFC5810] включает полное описание механизмов защиты, которые реализации должны поддерживать. Основанный на SCTP уровень транспортного отображения (TML) для протокола ForCES [RFC5811] задает механизмы защиты для этого транспортного отображения ForCES. Определенные здесь LFB похожи на другие LFB модели FE [RFC5812] и имеют такие же проблемы безопасности. Поэтому вопросы безопасности протокола ForCES, рассмотренные в [RFC5810], применимы и к этому документу.

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

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

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

[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, «Forwarding and Control Element Separation (ForCES) Protocol Specification», RFC 5810, March 2010.

[RFC5811] Hadi Salim, J. and K. Ogawa, «SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol», RFC 5811, March 2010.

[RFC5812] Halpern, J. and J. Hadi Salim, «Forwarding and Control Element Separation (ForCES) Forwarding Element Model», RFC 5812, March 2010.

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

[IEEE.802-1Q] IEEE, «IEEE Standard for Local and metropolitan area networks — Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks», IEEE Standard 802.1Q, 2011.

[RFC1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1812] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

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

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, «Forwarding and Control Element Separation (ForCES) Framework», RFC 3746, April 2004.

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

Приложение A. Благодарности

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

Edward Crabbe
Adrian Farrel
Rong Jin
Bin Zhuge
Ming Gao
Jingjing Zhou
Xiaochun Wu
Derek Atkins
Stephen Farrell
Meral Shirazipour
Jari Arkko
Martin Stiemerling
Stewart Bryant
Richard Barnes

Приложение B. Участники работы

Авторы признательны Jamal Hadi Salim, Ligang Dong и Fenggen Jia за основной вклад в создание документа. Ligang Dong и Fenggen Jia были авторами ранних документов, ставших предшественниками данного документа.

Jamal Hadi Salim

Mojatatu Networks

Ottawa, Ontario

Canada

EMail: hadi@mojatatu.com

Ligang Dong

Zhejiang Gongshang University

18 Xuezheng Str., Xiasha University Town

Hangzhou 310018

P.R. China

EMail: donglg@zjsu.edu.cn

Fenggen Jia

National Digital Switching Center (NDSC)

Jianxue Road

Zhengzhou 452000

P.R. China

EMail: jfg@mail.ndsc.com.cn

Authors’ Addresses

Weiming Wang

Zhejiang Gongshang University

18 Xuezheng Str., Xiasha University Town

Hangzhou 310018

P.R. China

Phone: +86 571 28877751

EMail: wmwang@zjsu.edu.cn

Evangelos Haleplidis

University of Patras

Department of Electrical & Computer Engineering

Patras 26500

Greece

EMail: ehalep@ece.upatras.gr

Kentaro Ogawa

NTT Corporation

Tokyo

Japan

EMail: ogawa.kentaro@lab.ntt.co.jp

Chuanhuang Li

Hangzhou DPtech

6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District

Hangzhou 310051

P.R. China

EMail: chuanhuang_li@zjsu.edu.cn

Joel Halpern

Ericsson

P.O. Box 6049

Leesburg, VA 20178

USA

Phone: +1 703 371 3043

EMail: joel.halpern@ericsson.com

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

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

nmalykh@gmail.com

1Logical Function Block.

2Forwarding and Control Element Separation — разделение элементов пересылки и управления.

3Forwarding Element.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Maximum Transmission Unit — максимальный размер передаваемого блока.

7Internet Control Message Protocol — протокол управляющих сообщений Internet.

8Interior gateway protocol — протокол внутреннего шлюза.

9Exterior gateway protocol — протокол внешнего шлюза.

10Media Access Control — контроль доступа к среде.

11Packet over SONET — пакеты в SONET.

12Asynchronous Transfer Mode — асинхронный режим передачи.

13Simple Network Management Protocol — простой протокол сетевого управления.

14Structure of Management Information — структура управляющей информации.

15Neighbor Discovery — обнаружение соседей.

16Longest Prefix Match — наиболее длинное совпадение префикса.

17Equal-cost multipath.

18Reverse path forwarding.

19Round Robin.

Рубрика: RFC | Комментарии отключены

RFC 6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)

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

Internet Engineering Task Force (IETF)                       R. Gagliano
Request for Comments: 6916                                 Cisco Systems
BCP: 182                                                         S. Kent
Category: Best Current Practice                         BBN Technologies
ISSN: 2070-1721                                                S. Turner
                                                              IECA, Inc.
                                                              April 2013

Процедура смены алгоритма для RPKI

Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)

PDF

Аннотация

В этом документе описан процесс, которому должны следовать удостоверяющие центры (CA¹) и зависимые от них стороны (RP²), участвующие в инфраструктуре открытых ключей ресурсов (RPKI³), для перехода к новому (и возможно более криптостойкому) набору алгоритмов. Предполагается, что этот процесс займет несколько лет. Следовательно, какого-либо экстренного перехода не задается. Описанная здесь процедура поддерживает только миграцию «сверху вниз» (сначала переходят родители, а затем потомки).

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

Этот документ относится к категории «Обмен опытом» (Internet Best Current Practice).

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

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

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

1. Введение

Инфраструктура открытых ключей ресурсов (RPKI⁶) должна приспосабливаться к переходам между открытыми ключами, используемыми удостоверяющими центрами (CA или УЦ). Переходы этого типа обычно называют «сменой ключей» (key rollover). Плановые замены ключей будут происходить регулярно в течение работы RPKI, поскольку каждый CA меняет свои открытые без координации с другими УЦ (это означает, что момент смены ключей в каждом УЦ определяется локальными условиями и не координируется в масштабе RPKI). Более того, поскольку смена ключей может быть вызвана предполагаемой компрометацией секретного ключа, предполагать координацию таких замен на всех УЦ в масштабе RPKI просто не реально. При вынужденной (аварийной) замене ключа старый сертификат отзывается и выпускается сертификат с новым ключом. Механизмы замены ключей в RPKI (плановой или аварийной) при использовании общего криптографического набора описаны в [RFC6489].

В этом документе описывается механизм смены ключей в RPKI по причине перехода к новому набору алгоритмов подписи. Документ определяет процесс, которому CA и RP, участвующие в RPKI, должны будут следовать для перехода на новый (возможно, более криптостойкий) набор алгоритмов. Предполагается, что процесс перехода может занимать месяцы и даже годы. Следовательно, экстренных мер перехода не задается. Определенная в документе процедура перехода только миграцию «сверху вниз» (сначала переходят родители, а затем потомки).

Набор алгоритмов подписи включает собственно алгоритм подписи (с заданным диапазоном размеров ключей) и необратимую хэш-функцию. Предполагается, что RPKI будет с течением времени требовать обновления размера ключей и/или замены набора алгоритмов. В этом документе рассматривается принятие нового алгоритма хэширования с сохранением текущего алгоритма подписи и необходимостью смены ключей в CA. Переход к новому набору алгоритмов может диктоваться требованиями поддержки необходимого уровня криптографической защиты и обеспечения целостности сертификатов, списков отзыва (CRL) и подписанных объектов в RPKI. Все структуры данных в RPKI явно указывают используемые алгоритмы подписи и хэширования. Однако опыт показывает, что возможность представить идентификаторы алгоритмов не достаточно для обеспечения возможности перехода к новому набору алгоритмов (algorithm agility — обновление алгоритма). Требуется обеспечить переход от одного набора алгоритмов к другому также на уровне протоколов, элементов инфраструктуры и рабочих процедур. Предполагается, что переход к другим алгоритмам будет происходить очень редко и будет требовать поддержки «текущего» и «будущего» набора алгоритмов в течение долгого срока (возможно, нескольких лет).

В этом документе определяется процедура запланированной в RPKI смены ключей CA при замене набора алгоритмов. Описание включает действия CA, операторов репозиториев и RP. Описаны требования к поведению CA и RP для обеспечения работы RPKI в процессе смены ключей, а также использование системы репозиториев RPKI для поддержки смены ключей.

Этот документ не задает какого-либо конкретного набора алгоритмов. Политика сертификации (CP⁷) RPKI [RFC6484] требует использования в CA и RP алгоритмов, определенных в [RFC6485]. При инициировании смены алгоритмов документ [RFC6485] должен быть обновлен (см. параграф 4.1 настоящего документа) для переопределения требуемых CP алгоритмов в совместимых со спецификацией RPKI CA и RP. Политика CP не меняется в результате смены алгоритмов и, таким образом, идентификатор OID для нее в сертификатах RPKI остается прежним.

Для каждой смены алгоритма должен публиковаться дополнительный документ (расписание перехода) в серии BCP для определения даты каждой вехи перехода. Такой документ будет определять фазы перехода в соответствии с приведенными в разделе 4 описаниями. Документ также будет описывать как сообщество RPKI будет оценивать готовность CA и RP к переходу в каждую фазу. В процессе перехода CA публикуют сертификаты, списки CRL и другие подписанные объекты с использованием нового набора алгоритмов. Это обеспечит видимость развертывания нового набора алгоритмов и позволит сообществу оценить процесс перехода. Процедура перехода позволяет CA удалять старые сертификаты, списки CRL и подписанные объекты после определенной («сумеречной» — twilight) даты, что позволит наблюдать и оценивать вывод из обращения старого набора алгоритмов. Таким образом, фазы, определенные в этом документе, позволят сообществу оценить процесс перехода. Документ с расписанием также будет определять изменение расписания при возникновении проблем, связанных с реализацией заключительных фаз перехода. Документы с расписанием рекомендуется разрабатывать представителям сообщества RPKI — например, IANA, регистраторам Internet, сетевым операторам.

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

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

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

В этом документе предполагается, что читатель знаком с терминологией и концепциями документов Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [RFC5280], X.509 Extensions for IP Addresses and AS Identifiers [RFC3779] и A Profile for Resource Certificate Repository Structure [RFC6481]. Дополнительные термины и соглашения, используемые в примерах, приведены ниже.

Algorithm migration — смена алгоритмов

Запланированный переход от одного алгоритма подписи и хэширования к другому.

Algorithm Suite A — набор алгоритмов A

«Текущий» алгоритм хэширования и подписи (термин используется в примерах).

Algorithm Suite B — набор алгоритмов B

«Следующий» алгоритм хэширования и подписи (термин используется в примерах).

CA X — УЦ X

CA, выпустивший сертификат CA Y (т. е. «родитель» CA Y) (термин используется в примерах).

CA Y — УЦ Y

CA, не являющийся «листом» дерева (термин используется в примерах).

CA Z — УЦ Z

CA, являющийся «потомком» CA Y (термин используется в примерах).

Correspond — соответствие

Два сертификата, выпущенные с использованием разных наборов алгоритмов, соответствуют один другому, если они выпущены одним и тем же элементом одного CA и привязаны к идентичным ресурсам INR⁸ для этого элемента. Два CRL соответствуют друг другу, если они выпущены одним CA и перечисляют соответствующие сертификаты. Два подписанных объекта (не манифесты) соответствуют друг другу, если они проверены с использованием соответствующих сертификатов EE⁹ и содержат одинаковое инкапсулированное поле Context Info. Два манифеста соответствуют друг другу, если они охватывают соответствующие сертификаты, ROA¹⁰, CRL и другие подписываемые объекты (по отношению к подписанным результатам (продукции) RPKI в качестве синонима используется термин «эквивалентны»).

Leaf CA — CA-лист (оконечный)

CA, выдающий только сертификаты EE.

Non-Leaf CA — CA, не являющийся «листом»

CA, выдающий сертификаты другим CA.

PoP (proof of possession) — подтверждение обладания

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

ROA

Полномочия «порождения» маршрута в соответствии с определением [RFC6482].

Signed product set (set или product set) — набор подписанных результатов (продукции)

Набор сертификатов, подписанных объектов, CRL и манифест, связанные проверяемостью с использованием одного и того же сертификата родительского CA.

4. Этапы смены ключей при переходе на другой алгоритм

«Текущий» набор алгоритмов RPKI (Suite A) определяется в документе RPKI CP со ссылкой на [RFC6485]. Когда возникает необходимость замены набора алгоритмов RPKI, первым шагом должно быть обновление [RFC6485] для задания нового набора алгоритмов. Должен также быть опубликован документ (в серии BCP) с расписанием (графиком) перехода для информирования сообщества о датах, выбранных вехами переходного процесса, как описано в параграфе 4.1.

4.1. Основные определения

CA Ready Algorithm B Date — дата готовности CA к алгоритму B

После этой даты все non-leaf CA должны быть готовы к обработке запросов от дочерних CA на выпуск сертификатов с использованием Algorithm Suite B. Все УЦ, публикующие [RFC6490] TAL¹¹ для Algorithm Suite A, должны также опубликовать соответствующие TAL для Algorithm Suite B.

CA Go Algorithm B Date — дата перехода CA на алгоритм B

После этой даты все CA должны заново выпустить все комплекты своей продукции с использованием Algorithm Suite B.

RP Ready Algorithm B Date — дата готовности RP к алгоритму B

После этой даты все RP должны быть готовы обрабатывать материалы, подписанные с помощью Algorithm Suite B.

Twilight Date — дата «сумерек»

После этой даты CA могут прекращать выпуск продукции, подписанной с использованием Algorithm Suite A, а RP могут отказаться от проверки пригодности материалов, подписанных с использованием Algorithm Suite A.

End-Of-Life (EOL) Date — дата завершения

После этой даты использование Algorithm Suite A должно быть прекращено в соответствии с процедурой, описанной в разделе 10, а все TAL набора алгоритмов A должны быть удалены из мест их публикации.

4.2. Обзор процесса

Процесс перехода, описанный в этом документе, включает последовательность этапов, которые должны быть пройдены (выполнены) CA и RP в хронологическом порядке. Единственной вехой, на которой CA и RP одновременно выполняют действия, является дата завершения (EOL Date). Децентрализованная природа RPKI предполагает протяженность процесса смены алгоритмов в несколько лет.

Для облегчения перехода CA будут начинать выпуск сертификатов с использованием набора алгоритмов B в иерархическом порядке «сверху-вниз». В нашем примере CA Y будет выпускать сертификаты с использованием набора алгоритмов B только после того, как это начнет делать CA X (CA Y Ready Algorithm B Date > CA X Ready Algorithm B Date). Такой упорядоченный переход предотвращает выпуск «смеси» сертификатов CA — например, сертификат CA, подписанный с использованием алгоритмов A, который будет содержать ключ из набора B. В RPKI удостоверяющим центрам CA недопустимо подписывать сертификаты CA, содержащие ключ субъекта, который соответствует набору алгоритмов, отличающемуся от используемого для подписывания сертификата (X.509 приспосабливается к таким сертификатам со смешением алгоритмов, но этот процесс предотвращается за счет использования описанного подхода). Модель перехода, отличающаяся от «сверху-вниз», будет требовать применения таких смешанных сертификатов и приведет к экспоненциальному росту размера репозиториев RPKI. Кроме того, поскольку RPKI CP требует PoP для запросов сертификатов, для CA невозможно запросить сертификат для набора алгоритмов B, пока родительский CA не поддерживает этот набор (см. раздел 5).

Описанная здесь модель смены алгоритмов не запрещает CA выпуск сертификатов EE с использованием открытого ключа субъекта из другого набора алгоритмов, если этот сертификат не применяется для проверки пригодности объектов в репозитории. Это исключение из правила запрета сертификатов со смешением алгоритмов сделано потому, что сертификаты EE не используются при проверке пригодности объектов репозитория и препятствуют RP загружать и проверять пригодность содержимого репозитория. Как отмечено выше, каждый CA в RPKI должен выполнять проверку PoP для открытого ключа субъекта при выпуске сертификата. В общем случае субъект не может предполагать, что CA может поддерживать разные алгоритмы. Однако у субъектов, тесно связанных с CA, есть основания предположить возможность выяснить способен ли CA поддержать запрос на выпуск сертификата EE, содержащего конкретный иной алгоритм открытого ключа. Данный документ не задает способа, с помощью которого субъект может узнать о способности CA выпускать смешанные сертификаты EE, поскольку возможность выдачи таких сертификатов предполагается лишь в контексте, где субъект и CA достаточно тесно связаны между собой (например, ISP, выпускающий сертификаты для управляемых им устройств).

На рисунке приведен обзор процесса смены набора алгоритмов.

Процесс в RPKI CA
      Фаза 0   Фаза 1    Фаза 2              Фаза 4   Фаза 0
   --x--------x---------x-------------------x--------x---------
     ^        ^         ^                   ^        ^
     |        |         |                   |        |
    (1)      (2)       (3)                 (5)      (6)
Процесс в RPKI RP
               Фаза 0               Фаза 3    Фаза 4   Фаза 0
   -------------------------------x---------x--------x---------
     ^                            ^         ^        ^
     |                            |         |        |
    (1)                          (4)       (5)      (6)

документ по алгоритму RPKI обновлен и выпущен документ с расписанием перехода к новому алгоритму;
дата готовности CA к алгоритму B;
дата перехода CA на алгоритм B;
дата готовности RP к алгоритму B;
дата «сумерек»;
дата завершения (EOL).

Каждая из этих вех процесса рассмотрена в последующих параграфах при обсуждении фаз переходного процесса.

Были отмечены две ситуации, являющиеся мотивами для приостановки или отката назад процесса перехода. Первая ситуация возникает, если сообщество RPKI еще не готово к переходу. Например, множество УЦ может оказаться не подготовленным к выпуску сертификатов с набором B или многие RP окажутся не готовыми к обработке продукции набора B. В таких случаях расписание перехода должно выпускаться заново с переносом даты соответствующей фазы и сдвигом дат последующих фаз. Другая ситуация связана с обнаружением в процессе перехода серьезных проблем в безопасности алгоритмов набора B. Это будет служить мотивом остановки перехода и возврата к набору A. В таких случаях расписание перехода должно быть опубликовано заново, а документ по алгоритмам RPKI должен быть заменен. В описании фаз перехода при необходимости упоминаются обе эти ситуации.

4.3. Фаза 0

Фаза 0 является стационарной частью процесса, на которой Algorithm Suite A является единственным поддерживаемым в RPKI набором алгоритмов. Фаза 0 является устойчивым состоянием RPKI.

В фазе 0, удостоверяющие центры (CA) X, Y и Z должны генерировать подписанную продукцию, используя только Algorithm Suite A. RP также должны проверять пригодность подписанной продукции, используя только Algorithm Suite A.

На рисунке ниже приведен пример структуры подписанного объекта в репозитории, показывающий используемые наборы алгоритмов и отношения между CA (X, Y, Z), которые формируют цепочку сертификации. Размещение по вертикали показывает объекты, подписанные одним CA с использованием одного секретного ключа. Сдвиг по горизонтали представляет использование разных точек публикации для объектов, подписанных разными УЦ. Символы |-> использованы для визуализации связей при подписывании и изменения точек публикации. Например, объекты CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A и CA-X-Signed-Objects-Algorithm-Suite-A подписаны с использованием секретного ключа, соответствующего CA-X-Certificate-Algorithm-Suite-A, и опубликованы в точке CA X.

   CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                           |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

Примечание. Cert-XA представляет сертификат для CA X, подписанный с использованием Algorithm Suite A.

4.3.1. Веха 1

Первая веха инициирует процесс перехода. При этом обновляется [RFC6485] с приведенными ниже определениями для RPKI:

Algorithm Suite A;
Algorithm Suite B.

Кроме того, должен быть опубликован документ с расписанием перехода на новый алгоритм, содержащий следующую информацию:

CA Ready Algorithm B Date (дата готовности CA к алгоритму B);
CA Go Algorithm B Date (дата перехода CA на алгоритм B);
RP Ready Algorithm B Date (дата готовности RP к алгоритму B);
Twilight Date (дата «сумерек»);
EOL Date (дата завершения);
Параметры оценки готовности CA и RP для каждой фазы.

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

4.4. Фаза 1

Фаза 1 начинается с даты готовности CA к переходу на Algorithm B. В этой фазе все УЦ, не являющиеся «листьями» (non-leaf CA), должны быть готовы обрабатывать запросы дочерних CA на выдачу и отзыв сертификатов с использованием Algorithm Suite B. Если окажется, что достаточно много CA не готовы к переходу, должен быть выпущен новый документ с расписанием перехода, как отмечено в параграфе 4.2. Однако CA, способные выдавать сертификаты с использованием набора B, могут продолжать делать это при получении запросов от своих дочерних УЦ. Поскольку эта фаза не требует от RP обработки объектов, подписанных с помощью набора B, а продукцию набора B следует сохранять в независимых точках публикации, это не оказывает неблагоприятного воздействия на RP. Если алгоритм набора B будет признан непригодным, документы с расписанием смены алгоритма и спецификацией нового алгоритма должны быть заменены, а использование Algorithm Suite B должно быть отменено с использованием процедуры, описанной в разделе 10.

Поскольку переход будет происходить в иерархическом порядке «сверху-вниз», дочерние CA смогут выпускать сертификаты с использованием Algorithm Suite B только после того, как их родительские CA выпустят свои сертификаты. Протокол поддержки RPKI может определить способность родительского CA выпускать сертификаты с использованием Algorithm Suite B, а также может идентифицировать соответствующий набор алгоритмов в каждом запросе подписи сертификата CSR¹² (см. раздел 5). В течение большей части этой фазы дерево продукции набора B будет неполным, т. е. не все CA будут выпускать продукцию с использованием набора B. По этой причине для обеспечения работы RP должны получать и проверять только продукцию набора A. Продукцию набора B следует получать и обрабатывать только в целях тестирования.

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

   CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                           |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

   CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
           |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
                   |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-B
           |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
           |-> CA-X-Signed-Objects-Algorithm-Suite-B

4.5. Фаза 2

Фаза 2 начинается с даты перехода CA на алгоритм B. В начале этой фазы все подписанная продукция должна быть доступна с использованием обоих наборов алгоритмов A и B. Таким образом, до начала этой фазы каждый CA должен гарантировать наличие продукции набора B для всей продукции набора A, выпущенной данным CA. В течение этой фазы каждый CA должен поддерживать такое соответствие. В течение этой фазы RP должны быть готовы проверять пригодность продукции, выпущенной с использованием Algorithm Suite A и могут быть готовы для проверки пригодности с использованием Algorithm Suite B.

Если обнаруживается отсутствие готовности существенного числа CA, документ с расписанием перехода должен быть выпущен заново, как описано в параграфе 4.2 (поскольку для обработки в RP указан уровень требований «может», возникновение у RP проблем с продукцией Suite B, не требует отсрочки фазы 2, но может служить основанием для задержки начала фазы 3). УЦ, способные публиковать продукцию Suite B, могут продолжать это. Фаза 2, подобно фазе 1, не требует какой-либо обработки в RP объектов Suite B. Продукцию Suite B следует сохранять в независимых точках публикации, чтобы не оказывать негативного влияния на RP, которые не готовы обрабатывать продукцию Suite B (см. раздел 9). Если алгоритм B будет сочтен неприменимым, документы с расписанием перехода и спецификацией алгоритма должны быть заменены, а использование Algorithm Suite B должно быть отменено с использованием процесса, описанного в разделе 10.

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

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

   CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                           |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

   CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
           |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
                   |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
                           |-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-B
                   |-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-B
           |-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
           |-> CA-X-Signed-Objects-Algorithm-Suite-B

4.6. Фаза 3

Фаза 3 начинается с даты готовности RP к алгоритму B. В этой фазе все подписанные наборы продукции доступны с использованием обоих наборов алгоритмов и все RP должны быть способны проверить их пригодность (соответствие между продукцией Suite A и Suite B, требовалось в фазе 2 и будет поддерживаться на данной фазе с сохранением означенных выше требований). В процессе подготовки к фазе RP рекомендуется в первую очередь получать и обрабатывать продукцию Suite B и отдавать ей предпочтение при проверке пригодности в этой фазе. Таким образом, RP следует сначала предпринимать попытку проверки подписанной продукции из репозитория Algorithm Suite B.

Если значительное число RP не способны обрабатывать наборы продукции, подписанные с использованием Suite B, документ с расписанием перехода должен быть выпущен заново со сдвигом дат для этой и последующих вех, как описано в параграфе 4.2. Поскольку продукцию Suite B следует публиковать в независимых точках, предполагается, что RP, не способные обрабатывать продукцию Suite B вернуться к обработке продукции Suite A, которая сохраняется в этой фазе. Если алгоритм B будет сочтен неприменимым, документы с расписанием перехода и спецификацией алгоритма должны быть заменены, а использование Algorithm Suite B должно быть отменено с использованием процесса, описанного в разделе 10.

Поведение CA на этой фазе не меняется.

4.7. Фаза 4

Фаза 4 начинается с даты «сумерек» (Twilight Date), когда алгоритм A помечается, как «старый» (old), а алгоритм B становится «текущим» (current).

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

Если значительное число RP не способны обрабатывать наборы продукции, подписанные с использованием Suite B, документ с расписанием перехода должен быть выпущен заново со сдвигом дат для этой и следующих вех. Документ должен от CA сохранение наборов продукции Suite A, если эта фаза задерживается. Если алгоритм B будет сочтен неприменимым, документы с расписанием перехода и спецификацией алгоритма должны быть заменены, а использование Algorithm Suite B должно быть отменено с использованием процесса, описанного в разделе 10, при этом для CA недопустимо удалять наборы продукции Suite A. На этой стадии RP сохраняют возможность обработки подписанной продукции Suite A и функционирование RPKI не нарушается.

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

   CA-X-Certificate-Algorithm-Suite-A (Cert-XA)
           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

   CA-X-Certificate-Algorithm-Suite-B (Cert-XB)
           |-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
                   |-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
                           |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-B
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-B
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
           |-> CA-X-Signed-Objects-Algorithm-Suite-B

4.8. Возврат к фазе 0

Дата завершения (EOL) инициирует возврат к фазе 0 (стабильное состояние). В этот момент старый набор алгоритмов — Algorithm Suite A должен быть выведен из обращения с помощью процесса, описанного в разделе 10.

Эта фаза завершает цикл, поскольку новый набор алгоритмов (Algorithm Suite B) становится единственным, требуемым в RPKI. В этого момента данный набор алгоритмов уже будет называться Algorithm Suite A.

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

5. Поддержка множества алгоритмов в протоколе обеспечения RPKI

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

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

Протокол обеспечения RPKI [RFC6492] поддерживает множество наборов алгоритмов путем реализации разных классов ресурсов для каждого набора. Несколько разных классов ресурсов могут использоваться для одного набора алгоритмов с разными наборами ресурсов.

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

Организовать сеанс протокола обеспечения со своим родительским CA.
Выполнить команду list в соответствии с параграфом 3.3.1 в [RFC6492].
Из поля Payload в классе ресурса list response извлечь issuer’s certificate для каждого класса. Набор алгоритмов для каждого класса будет соответствовать набору алгоритмов, использованному для выпуска соответствующего issuer’s certificate (указан в поле SubjectPublicKeyInfo этого сертификата).

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

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

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

6. Проверка пригодности множества подписанных экземпляров

В фазах 1 — 4 в инфраструктуре RPKI будут пригодны для использования одновременно два набора алгоритмов. В этом разделе описано поведение RP при проверке пригодности подписанной продукции, для которой использованы разные наборы алгоритмов.

В фазе 1 для продукции может существовать два экземпляра, один из которых подписан с использованием Algorithm Suite A, другой — Algorithm Suite B. Как было отмечено в параграфе 4.4, на этой фазе отдается предпочтение продукции Suite A. Вся продукция доступна для Suite A и лишь часть продукции может быть доступна для Suite B. Для работы RP может получать и проверять пригодность только продукции Suite A. Продукцию Suite B следует получать и проверять на пригодность лишь с целью тестирования. Если набор продукции имеется для обоих алгоритмов, результаты для них должны быть эквивалентными (прямое сравнение продукции Suite A и Suite B невозможно, поскольку сертификаты, CRL и манифесты будут различаться синтаксически; однако результаты процесса, т. е. данные ROA — номера автономных систем и адресные префиксы должны (SHOULD) соответствовать)

На фазах 2 и 3 для RP должны быть доступны два соответствующих друг другу экземпляра всей подписанной продукции. Как отмечено в параграфе 4.5, при при поддержке RP нового алгоритма в фазе 2 рекомендуется получать и проверять пригодность продукции Suite B. Если RP сталкивается с проблемой при проверке пригодности продукции Suite B, ему следует вернуться к продукции Suite A. RP, поддерживающие Suite B, могут получать оба варианта продукции и сравнивать результаты (например, выход ROA) с целью тестирования.

В фазе 3 все RP должны поддерживать Suite B и должны получать наборы продукции Suite B. Если RP сталкивается с проблемой при проверке пригодности продукции Suite B, ему можно вернуться к продукции Suite A. RP, столкнувшемуся с такой проблемой, следует связаться с держателями соответствующих репозиториев (например, с помощью механизма, определенного в [RFC6493]) для информирования о проблеме.

В фазе 4 для всех элементов RPKI требуется лишь наличие продукции Suite B, как отмечено в параграфе 4.7. Таким образом, RP следует получать и проверять на пригодность только эти наборы продукции. Получение продукции Suite A может приводить к неполноте набора подписанной продукции и по этой причине не рекомендуется.

7. Отзыв сертификатов

Процесс смены алгоритма требует поддержки двух параллельных и эквивалентных иерархий сертификации в фазах 2 и 3 этого процесса. На протяжении этих фаз CA должны отзывать и запрашивать отзыв сертификатов согласованно для обоих наборов алгоритмов. Когда не происходит смены ключа (key rollover), как описано в разделе 8, CA, запрашивающий отзыв своего сертификата во время этих двух фаз перехода, должен сделать запрос для обоих наборов алгоритмов (A и B). Не являющимся оконечными (non-leaf) CA не следует проверять соответствие дочерних CA этому требованию. Отметим, что CA должен запрашивать отзыв своего сертификата применительно к конкретному набору алгоритмов с использованием механизма, описанного в разделе 5.

В течение фазы 1 CA, отзывающему свой сертификат для Suite A, следует отозвать соответствующий сертификат для Suite B, если такой существует. В течение фазы 4 CA, отзывающему свой сертификат для Suite B, следует отзывать и соответствующий сертификат для Suite A, если такой существует.

В течение фазы 1 CA может отозвать сертификаты для Suite B, не отзывая сертификатов для Suite A, поскольку продукция Suite B предназначена лишь для тестирования. В течение фазы CA может отозвать сертификаты для Suite A, не отзывая сертификатов для Suite B, поскольку продукция Suite A выводится из обращения.

8. Смена ключа

Смена ключа (без замены алгоритмов) выполняется независимо для каждого набора алгоритмов и должна происходить в соответствии с [RFC6489].

9. Структура репозитория

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

10. Отказ от использования алгоритма

Для отказа от использования (запрета) набора алгоритмов на каждом CA в RPKI должны быть выполнены перечисленные ниже операции.

Все CA должны прекратить выпуск сертификатов с использованием этого набора. Это означает, что любой запрос сертификата CA от дочерних УЦ будет отвергаться (например, путем отправки сообщения error_response с кодом ошибки «request — no such resource class», как описано в [RFC6492]).
Все CA должны прекратить создание подписанной продукции для этого набора кроме CRL и манифестов.
Все CA должны отозвать сертификаты EE для всей продукции, подписанной с использованием данного набора. CA следует удалить эту продукцию из своих точек публикации для предотвращения загрузки и обработки этой продукции RP.
Все CA должны отозвать все сертификаты CA, выпущенные с использованием данногонабора.
Всем CA следует удалить все сертификаты CA, выпущенные с использованием данногонабора.
Все CA, публикующие TAL для данного данного набора, должны удалить их из пункта публикации TAL.
Всем CA следует поддерживать точку публикации для данного набора по крайней мере до наступления срока CRL nextUpdate. Эти точки публикации должны содержать только CRL и манифест для данной точки. Такое поведение обеспечивает временные рамки, в которых RP могут узнать состояние отзыва подписанной продукции, которая была удалена.
Все RP должны удалить любые TAL, опубликованные для данного набора алгоритмов.

CA в иерархии RPKI могут узнавать об отказе от использования набора алгоритмов в разное время и, следовательно, будут выполнять перечисленные выше процедуры асинхронно. Так, например, CA может запросить отзыв своего сертификата лишь для того, чтобы узнать, что он уже был отозван его эмитентом. Отзыв сертификата CA делает выпущенные им с использованием этого сертификата CRL и манифест непроверяемыми на пригодность. Асинхронное выполнение указанных выше процедур явно будет создавать временную «несогласованность» между точками публикации для отменяемого набора алгоритмов. Однако даже во время такой несогласованности следует давать «отказоустойчивые» результаты (. е. RP следует отвергать продукцию, подписанную с использованием отмененного набора алгоритмов).

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

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

Этот документ не описывает «аварийных» механизмов для процесса смена алгоритмов. По причине распределенной природы RPKI, а также огромного числа CA и RP, авторы не считают возможной разработку такого механизма.

Если CA не завершает переход к новому набору алгоритмов, как описано в этом документе (после EOL продолжает использовать «старый» набор), подписанная им продукция становится не пригодной. Следовательно, в RPKI в конце фазы 4 может сократиться объем пригодной к использованию подписанной продукции по сравнению с началом перехода. RP, которые не выполняют описанные здесь процесс, теряют возможность проверять подписанную с использованием нового набора алгоритмов продукцию. В результате неполное представление маршрутной информации из RPKI (как результат неполного перехода CA или RP) может приводить к некоторому снижению эффективности маршрутизации в Internet.

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

Авторы хотели бы отметить работу сопредседателей рабочей группы SIDR (Sandra Murphy, Chris Morrow, Alexey Melnikov), а также вклад Geoff Huston, Arturo Servin, Brian Weis, Terry Manderson, Brian Dickson, David Black и Danny McPherson.

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

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

[RFC3779] Lynn, C., Kent, S., and K. Seo, «X.509 Extensions for IP Addresses and AS Identifiers», RFC 3779, June 2004.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, «A Profile for Resource Certificate Repository Structure», RFC 6481, February 2012.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, «A Profile for Route Origin Authorizations (ROAs)», RFC 6482, February 2012.

[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, «Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)», BCP 173, RFC 6484, February 2012.

[RFC6485] Huston, G., «The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)», RFC 6485, February 2012.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, «Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)», BCP 174, RFC 6489, February 2012.

[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, «Resource Public Key Infrastructure (RPKI) Trust Anchor Locator», RFC 6490, February 2012.

[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, «A Protocol for Provisioning Resource Certificates», RFC 6492, February 2012.

[RFC6493] Bush, R., «The Resource Public Key Infrastructure (RPKI) Ghostbusters Record», RFC 6493, February 2012.

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

Roque Gagliano

Cisco Systems

Avenue des Uttins 5

Rolle 1180

Switzerland

EMail: rogaglia@cisco.com

Stephen Kent

BBN Technologies

10 Moulton St.

Cambridge, MA 02138

USA

EMail: kent@bbn.com

Sean Turner

IECA, Inc.

3057 Nutley Street, Suite 106

Fairfax, VA 22031

USA

EMail: turners@ieca.com

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

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

nmalykh@gmail.com

1Certification Authority.

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

3Resource Public Key Infrastructure.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Resource Public Key Infrastructure.

7Certificate Policy.

8Internet Number Resource — числовые ресурсы (номера) Internet.

9End-entity — конечный элемент.

10Route Origination Authorization — полномочия «порождения» маршрутов.

11Trust Anchor Locator — расположение доверенных привязок.

12Certificate Signing Request.

Рубрика: RFC | Комментарии отключены

RFC 6891 Extension Mechanisms for DNS (EDNS(0))

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

Internet Engineering Task Force (IETF)                          J. Damas
Request for Comments: 6891                         Bond Internet Systems
STD: 75                                                         M. Graff
Obsoletes: 2671, 2673
Category: Standards Track                                       P. Vixie
ISSN: 2070-1721                              Internet Systems Consortium
                                                              April 2013

Extension Mechanisms for DNS (EDNS(0))

Механизмы расширения для DNS (EDNS(0))

PDF

Аннотация

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

Документ обновляет спецификацию механизмов расширения для DNS (EDNS(0)) и отменяет действие RFC 2671 с учетом опыта использования некоторых реализаций. Документ также отменяет RFC 2673 (Binary Labels in the Domain Name System) и добавляет рассмотрение использования расширенных меток в DNS.

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

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

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

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

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

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

1. Введение

Протокол DNS [RFC1035] задает формат сообщений, а также стандартные форматы для опций кодирования, ошибок и сжатия имен в таких сообщениях. Максимальный размер сообщения DNS для передачи по протоколу UDP без использования предложенных здесь расширений составляет 512 байтов. Многие из предельных значений для протокола DNS, такие как максимальный размер при передаче по протоколу UDP), слишком малы для эффективной поддержки дополнительной информации, которая может передаваться DNS (например, несколько адресов IPv6 или подписи DNSSEC⁴). Кроме того, RFC 1035 не определяет каких-либо способов анонсирования возможностей другим участникам протокола.

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

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

EDNS является поэтапным (hop-by-hop) расширением DNS. Это означает, что использование EDNS согласуется между каждой парой хостов в процессе распознавания (resolution) DNS, например, оконечным распознавателем (stub resolver), взаимодействующим с рекурсивным распознавателем, или рекурсивным распознавателем, взаимодействующим с полномочным сервером.

В [RFC2671] заданы расширенные типы меток. Единственным таким типом был предложенный в [RFC2673] тип «Bit-String Label» или «Binary Labels» (второй вариант стал общепринятым). По разным причинам добавление новых типов меток оказалось слишком сложным и документ [RFC2673] получил статус экспериментального (Experimental). Данный документ отменяет [RFC2673] и двоичные метки (Binary Labels). Расширенные метки сохраняются, но их применение не рекомендуется из-за практических сложностей при развертывании. Их использование в будущем следует выбирать лишь после тщательной оценки препятствий к развертыванию.

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

Запрашивающей (Requestor) называется сторона, передающая запрос, а ответчиком (Responder) — полномочный рекурсивный распознаватель или другой элемент DNS, отвечающий на вопросы. Остальные термины определены в RFC, упоминаемых в этом документе.

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

3. Требование поддержки EDNS

EDNS обеспечивает механизм улучшения расширяемости DNS, позволяя сделать применение DNS в Internet более разнообразным. Это делается путем обеспечения возможности использовать для DNS транспорт UDP с сообщениями, размер которых превышает заданный в RFC 1035 предел, а также предоставления дополнительного пространства для флагов и кодов возврата (RCODE). Однако опыт развертывания показывает, что добавления новых значений RCODE следует избегать по причине сложности обновления установленных систем. Флаги следует применять только в случае их необходимости для преобразования DNS.

Для многих приложений может оказаться предпочтительным EDNS Option Code.

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

С учетом роста размера откликов DNS при включении крупных элементов данных, таких как записи AAAA, информация DNSSEC (например, RRSIG или DNSKEY) и большие записи TXT, дополнительное пространство данных UDP, обеспечиваемое EDNS, может помочь в плане расширяемости DNS без широкого использования TCP в качестве транспорта DNS.

4. Изменение сообщений DNS

4.1. Заголовок сообщения

Второе полное 16-битовое слово заголовка сообщения DNS делится на 4-битовые поля OPCODE и RCODE, а также множество 1-битовых флагов (см. параграф 4.1.1 в [RFC1035]). Некоторые из флагов были зарезервированы на будущее и сейчас уже почти все флаги распределены. Большинство значений RCODE также занято. Псевдо-RR OPT, описанные ниже, содержат расширения для поля RCODE, а также дополнительные биты флагов.

4.2. Типы меток

Первые 2 бита в формате передачи (wire format) метки домена используются для обозначения типа метки. В [RFC1035] выделено 2 из 4 возможных типов, а 2 оставшихся зарезервированы. В [RFC2671] были определены дополнительные типы меток. Использование 2-битовой комбинации, определенной в [RFC2671], для идентификации расширенных типов меток остается в силе. Однако опыт показал, что развертывание новых типов меток оказалось значительно сложнее и поэтому оно рекомендуется лишь после внимательной оценки вариантов и требований разворачиваемой системы.

4.3. Размер сообщений UDP

Традиционные сообщения DNS ограничены размером 512 байтов при передаче по протоколу UDP [RFC1035]. Рост объема данных, которые могут передаваться в сообщениях DNS, сделал ограничение в 512 байтов неудобным. Например, включение записей DNSSEC зачастую создает отклики, размер которых значительно больше 512 байтов.

EDNS(0) указывает способ анонсирования дополнительных возможностей (включая увеличенный размер сообщений), которые предназначены для предотвращения отсечки откликов UDP, приводившей к необходимости использовать транспорт TCP. Расширение обеспечивает возможность доставки более крупных сообщений без перехода на TCP.

5. Расширенные типы меток

Первый октет представления метки DNS при передаче (on-the-wire) указывает тип метки. Базовая спецификация DNS [RFC1035] выделяет для этого 2 старших бита данного октета.

В [RFC2671] определен тип 0b01 для индикации расширенных меток DNS. Конкретный расширенный тип метки указывается 6 младшими битами первого октета. Таким образом, типы расширенных меток указываются значениями 64 — 127 (0b01xxxxxx) в первом октете метки.

Расширенные типы меток оказались очень сложны для развертывания по причине отсутствия поддержки в клиентах и промежуточных шлюзах, как описано в [RFC3363], который перевел [RFC2673] в статус экспериментального (Experimental), и [RFC3364], где описаны «про и контра» для этого. Таким образом, приложениям, планирующим применять расширенные метки, следует взвесить стоимость развертывания и возможность реализации другими способами.

В заключение отметим, что реализациям недопустимо генерировать двоичные метки (Binary Labels), поскольку они признаны устаревшими.

6. Псевдо-RR OPT

6.1. Определение записи OPT

6.1.1. Базовые элементы

Псевдо-RR OPT (иногда говорят мета-RR) может быть добавлена в раздел дополнительных данных запроса.

OPT RR имеет тип 41.

При наличии записи OPT в запросе соответствующие спецификации распознаватели должны включать запись OPT в свой отклик.

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

OPT RR может размещаться в любом месте раздела дополнительных данных. При наличии OPT RR в любом сообщении DNS, она должна быть единственной такой записью в сообщении. При получении запроса с множеством OPT RR должна возвращаться ошибка FORMERR (RCODE=1). Гибкость размещения OPT RR не отменяет необходимости для записи TSIG или SIG(0) RR быть последней в дополнительном разделе, если такая запись имеется.

6.1.2. Формат передачи

OPT RR имеет фиксированную часть и набор опций переменного размера в форме пар {attribute, value}. Фиксированная часть содержит некоторые метаданные DNS, а также небольшой набор базовых элементов расширений, которые предполагаются достаточно популярными и будут расходовать излишнее пространство при кодировании в форме {attribute, value}.

Структура фиксированной части OPT RR показана в таблице ниже.

Формат OPT RR.

Имя поля	Тип поля	Описание
NAME	domain name	Должно быть 0 (корневой домен)
TYPE	u_int16_t	OPT (41)
CLASS	u_int16_t	Размер данных UDP запрашивающей стороны
TTL	u_int32_t	Расширенный код RCODE и флаги
RDLEN	u_int16_t	Размер всех RDATA
RDATA	octet stream	Пары {attribute,value}

Переменная часть OPT RR может содержать множество (возможно пустое) опций в RDATA. Каждая опция должна трактоваться как битовое поле. Кодирование опций показано ниже.

              +0 (MSB)                            +1 (LSB)
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |                          OPTION-CODE                          |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: |                         OPTION-LENGTH                         |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: |                                                               |
   /                          OPTION-DATA                          /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

OPTION-CODE

Назначается по процедуре Expert Review, как определено рабочей группой DNSEXT и IESG.

OPTION-LENGTH

Размер OPTION-DATA в октетах.

OPTION-DATA

Зависит от OPTION-CODE. Должно рассматриваться как битовое поле.

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

Любые значения OPTION-CODE, не понятные ответчику или запрашивающей стороне, должны игнорироваться. Спецификации опций могут пожелать включения сигналов подтверждения. Например, спецификация опции может указывать, что при распознании и поддержке ответчиком опции XYZ, он должен включать опцию XYZ в свой отклик.

6.1.3. Использование поля OPT Record TTL

Расширенные значения RCODE и флаги, которые OPT хранит в поле RR TTL⁵, имеют показанную ниже структуру.

              +0 (MSB)                            +1 (LSB)
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |         EXTENDED-RCODE        |            VERSION            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO|                           Z                               |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

EXTENDED-RCODE

Формирует старшие 8 битов расширенного 12-битового значения RCODE (вместе с 4 битами, определенными в [RFC1035]). Отметим, что EXTENDED-RCODE = 0 указывает применение обычных RCODE (от 0 до 15).

VERSION

Указывает уровень реализации установщика. Полное соответствие данной спецификации указывается версией 0. Запрашивающим настоятельно рекомендуется указывать в этом поле наименьший уровень реализации, способный выразить транзакцию, для минимизации нагрузки на ответчик и сеть при определении наибольшего общего уровня реализации, поддерживаемого запрашивающим и ответчиком. Стратегия нумерации версий запрашивающей стороны в идеале может быть настраиваемой в процессе работы. Если ответчик не реализует запрошенный уровень VERSION, он должен отвечать с RCODE=BADVERS. Все ответчики должны быть ограничены по формату уровнем VERSION в запросе, но в поле VERSION каждого отклика следует указывать высший уровень реализации ответчика. В результате вызывающая сторона будет узнавать уровень реализации ответчика как дополнительный результат каждого отклика, включая отклики с ошибками и RCODE=BADVERS.

6.1.4. Флаги

Бит DNSSEC OK, как определено в [RFC3225].

Устанавливается в 0 отправителями и игнорируется получателями, пока не будет изменено последующей спецификацией.

6.2. Поведение

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

Записи OPT недопустимо кэшировать.

6.2.2. Откат к старой версии

Если запрашивающий видит, что удаленная сторона не поддерживает EDNS(0), он может передавать запросы без записи OPT. Эта информация может кэшироваться на короткое время для предотвращения запоздалого отката в будущем. Однако если нужно расширение DNSSEC или какая-либо будущая опция, которой требуется EDNS, откат к старой версии выполнять не следует, поскольку такие опции сигнализируются лишь с помощью EDNS. Если реализация видит, что некоторые серверы для зоны поддерживают EDNS(0), а другие требуют использования TCP для получения всех данных, предпочтение может быть отдано серверам EDNS(0). Разработчикам следует анализировать этот выбор и его влияние на обеих сторонах.

6.2.3. Размер данных запрашивающей стороны

Размер данных UDP запрашивающей стороны (представляется полем RR CLASS) — это число октетов наибольшего поля данных UDP, который может быть собран и доставлен сетевым стеком запрашивающего. Отметим, что это значение может превышать path MTU (с фрагментацией или без нее).

Значения меньше 512 должны трактоваться как 512.

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

Отметим, что при 512 октетах данных UDP для сборки IP требуется буфер в 576 октетов. Выбор значений от 1280 до 1410 байтов для IP (v4 или v6) в сети Ethernet будет разумным.

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

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

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

6.2.4. Размер данных ответчика

Максимальный размер данных ответчика может изменяться с течением времени, но разумно считать, что он не будет меняться для двух близко расположенных транзакций (например, произвольная операция QUERY для определения максимального размера данных UDP у ответчика, за которой следует операция UPDATE, использующая этот размер). Это считается предпочтительным по сравнению с использованием TCP для запросов большого размера, если есть основания предполагать, что ответчик реализует EDNS, а запрос не будет помещаться в используемый по умолчанию размер данных 512 байтов.

6.2.5. Выбор размера данных

В связи с издержками транзакций не рекомендуется анонсировать архитектурное ограничение в качестве максимального размера данных UDP. Даже в системных стеках, способных собирать дейтаграммы размером 64 Кбайт, использование памяти на нижних уровнях системы будет играть роль. Хорошим компромиссом может быть использование максимального размера данных EDNS 4096 октетов в качестве стартовой точки.

Запрашивающая сторона может реализовать откат к меньшим анонсируемым размерам для работы в среде с межсетевыми экранами или при наличии иных сетевых ограничений. Запрашивающему следует выбирать применение механизма отката, начиная с большого размера, такого как 4096. Если это вызовет отказ, следует попытаться использовать значения 1280-1410 байтов, поскольку они имеют высокий шанс передачи в одном кадре Ethernet. Если отказ произойдет и в этом случае, запрашивающая сторона может выбрать размер 512 октетов, который в большинстве случаев может потребовать использования транспорта TCP.

Значения меньше 512 должны трактоваться как 512.

6.2.6. Поддержка на промежуточных устройствах

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

Соответствующим спецификации промежуточным устройствам недопустимо ограничивать размер сообщений DNS по протоколу UDP до 512 байтов.

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

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

Более глубокое рассмотрение такого оборудования и вопросов его взаимодействия с трафиком DNS приведено в [RFC5625].

7. Транспорт

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

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

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

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

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

Минимальный отклик должен включать заголовок DNS, раздел вопроса (question) и запись OPT. Такой вариант должен применяться также при возврате усеченного отклика (с битом TC в заголовке DNS).

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

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

Анонсирование слишком большого буфера UDP может приводить к отбрасыванию сообщений DNS промежуточными устройствами (параграф 6.2.6). Это вызовет повторы передачи без надежды на успех. Известно, что некоторые устройства отбрасывают фрагментированные пакеты UDP.

Анонсирование слишком малых буферов UDP может вызывать откат к протоколу TCP с соответствующим влиянием на работу серверов DNS. Это особенно важно для DNSSEC, где ответы могут быть большими.

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

Агентство IANA выделило код типа RR 41 для записей OPT.

В [RFC2671] задано множество субреестров IANA в реестре «DOMAIN NAME SYSTEM PARAMETERS»:

DNS EDNS(0) Options;
EDNS Version Number;
EDNS Header Flags.

В дополнение к этому добавлены записи в имеющиеся реестры:

EDNS Extended Label Type в реестр DNS Label Types;
Bad OPT Version в реестр DNS RCODES.

Агентство IANA заменило в этих реестрах и субреестрах ссылки на [RFC2671] ссылками на этот документ.

В [RFC2671] был создан реестр DNS Label Types, который сохраняется открытым.

Для реестра DNS Label Types используется регистрационная процедура Standards Action.

Этот документ выделяет код опции 65535 в реестре DNS EDNS0 Options как резервный (Reserved for future expansion).

Текущее состояние реестра IANA для кодов опций EDNS на момент публикации документа имеет вид:

0-4 выделены с указанными в реестре ссылками;
5-65000 доступны для распределения;
65001-65534 для локального применения и экспериментов (Local/Experimental);
65535 зарезервирован для будущего расширения.

В [RFC2671] размер значений RCODE увеличен с 4 до 12 битов. Это позволяет использовать более 16 разных значений RCODE, разрешенных в [RFC1035]. Для добавления кодов применяется процедура IETF Review.

Этот документ выделяет значение EDNS Extended RCODE 16 для кода «BADVERS» в реестре DNS RCODES.

В [RFC2671] предложено записывать назначение расширенных типов меток 0bxx111111 как «резерв для будущих расширенных типов меток» (Reserved for future extended label types», в настоящее время реестр IANA содержит запись «резерв для будущих расширений» (Reserved for future expansion). Это предложение предполагало запрос на создание нового реестра расширенных типов меток, но по причине возможной путаницы вместо этого новые регистрации вносились в общий реестр DNS Label Types, содержащий также изначально определенные в [RFC1035] типы. В результате реестр Extended Label Types не был создан и все типы регистрируются в реестре DNS Label Types.

Этот документ отменяет Binary Labels. Поэтому статус регистрации DNS Label Types для «Binary Labels» меняется на «Historic».

Для назначения новых флагов EDNS(0) требуется процедура IETF Standards Action. Флаги следует применять только в тех случаях, когда они требуются для преобразования (resolution) DNS. Во многих случаях лучше использовать EDNS Option Code.

Для создания новых записей в реестре EDNS Version Number требуется процедура IETF Standards Action. Выделение значения EDNS Option Code выполняется по процедуре Expert Review. В соответствии с этим документом IANA поддерживает реестр для EDNS Option Code.

9.1. Изменение названия реестра DNS EDNS0 Option Code⁷

Этот документ меняет название имеющегося реестра DNS EDNS0 Options на DNS EDNS0 Option Codes (OPT) и процедуру регистрации новых значений на Expert Review.

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

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

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

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

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

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC3225] Conrad, D., «Indicating Resolver Support of DNSSEC», RFC 3225, December 2001.

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

[RFC2673] Crawford, M., «Binary Labels in the Domain Name System», RFC 2673, August 1999.

[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, «Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)», RFC 3363, August 2002.

[RFC3364] Austein, R., «Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)», RFC 3364, August 2002.

[RFC5625] Bellis, R., «DNS Proxy Implementation Guidelines», BCP 152, RFC 5625, August 2009.

Приложение A. Отличия от RFC 2671 и 2673

Ниже приведен список существенных отличий от RFC 2671 и RFC 2673.

Поддержка записей OPT стала обязательной.
Типы расширенных меток остались, но их применение не рекомендуется в качестве общего решения, поскольку наблюдались значительные трудности с их развертыванием в Internet, как показала работа с типом «Binary Labels».
RFC 2673 с определением «Binary Labels» переведен в статус Experimental и запрошен перевод в «Historic».
Внесены изменения в выбор размера буферов EDNS и приведены рекомендации по таком выбору.

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

Joao Damas

Bond Internet Systems

Av Albufera 14

S.S. Reyes, Madrid 28701

Phone: +1 650.423.1312

EMail: joao@bondis.org

Michael Graff

EMail: explorer@flame.org

Paul Vixie

Internet Systems Consortium

950 Charter Street

Redwood City, California 94063

Phone: +1 650.423.1301

EMail: vixie@isc.org

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

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

nmalykh@protokols.ru

1Domain Name System — система доменных имен.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4DNS Security — защита DNS.

5Time to Live — время жизни.

6Denial-of-service — отказ в обслуживании.

7В исходном документе название и содержимое параграфа были иными. См. https://www.rfc-editor.org/errata/eid3604. Прим. перев.

Рубрика: RFC | Метки: DNS, EDNS | Комментарии отключены

RFC 6890 Special-Purpose IP Address Registries

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

Internet Engineering Task Force (IETF)                         M. Cotton
Request for Comments: 6890                                     L. Vegoda
BCP: 153                                                           ICANN
Obsoletes: 4773, 5156, 5735, 5736                         R. Bonica, Ed.
Category: Best Current Practice                         Juniper Networks
ISSN: 2070-1721                                              B. Haberman
                                                                     JHU
                                                              April 2013

Special-Purpose IP Address Registries

Реестры адресов IP специального назначения

PDF

Аннотация

В этом документе заново объявлено выделение блока адресов IPv4 192.0.0.0/24 агенству IANA. Документ также поручает IANA реструктурировать реестры адресов специального назначения IPv4 и IPv6. После реструктуризации упомянутые реестры будут включать все блоки адресов специального назначения и поддерживать для них одинаковые наборы параметров.

Документ отменяет RFC 4773, 5156, 5735 и 5736.

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

Этот документ относится к категории «Обмен опытом» (Internet Best Current Practice).

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

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

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

1. Введение

Для поддержки новых протоколов и практики IETF иногда резервирует блоки адресов специального назначения. Например, [RFC1122] резервирует блок адресов IPv4 (0.0.0.0/8) для представления местной (т. е. «данной») сети. Аналогично в [RFC4291] зарезервирован блок адресов IPv6 (fe80::/10) для представления индивидуальных адресов на канале.

Периодически IETF публикует RFC с каталогом адресных блоков специального назначения. В данный момент [RFC5735] содержит все адресные блоки специального назначения IPv4, а [RFC5156] — IPv6.

[RFC5736] выделяет блок адресов IPv4 192.0.0.0/24 агентству IANA и указывает IANA выделять из этого блока адреса специального назначения. В [RFC5736] также даны инструкции IANA по созданю реестра IPv4 Special-Purpose Address Registry с записями выделенных из этого блока адресов. Однако [RFC5736] не указывает IANA регистрировать в IPv4 Special-Purpose Address Registry резервирование адресных блоков специального назначения из блоков за пределами вышеупомянутого диапазона.

Аналогично [RFC2928] выделяет блок адресов IPv6 2001:0000::/23 агенству IANA и поручает IANA выделять из этого блока адреса специального назначения. [RFC4773] поручает IANA создать реестр IPv6 Special-Purpose Address Registry с записью выделения адресов из этого блока. Однако [RFC4773] не запрашивает у IANA записи резервирования адресов специального назначения из других блоков в реестр IPv6 Special-Purpose Address Registry.

В этом документе заново объявлено выделение блока адресов IPv4 192.0.0.0/24 агенству IANA. Документ также поручает IANA реструктурировать реестры адресов специального назначения IPv4 и IPv6. В частности, документ поручает IANA записывать все блоки адресов в указанные реестры. Это включает адреса IPv4 из блока 192.0.0.0/24 и адреса IPv6 из блока 2001:0000::/23, но не ограничивается ими. Кроме того, этот документ определяет:

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

Когда вышеупомянутые реестры включат все блоки адресов специального назначения, [RFC5735] и [RFC5156] с реестрами станут избыточными, поэтому данный документ отменяет [RFC5735] и [RFC5156]. Поскольку этот документ заново выделяет IANA блок адресов 192.0.0.0/24 и реструктурирует реестр IPv4 Special-Purpose Address Registry, от отменяет также [RFC5736]. Поскольку документ реструктурирует IPv6 Special-Purpose Address Registry, он отменяет [RFC4773].

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

2.1. Выделение блока адресов IPv4 агентству IANA

В таблице 7 записано выделение IANA блока адресов IPv4 192.0.0.0/24 для назначения протоколам IETF. Это выделение адресов IANA нацелено на поддержку назначения адресов протоколам IETF. Более общее понимание роли IANA в части выделения адресов приведено в параграфах 4.1 и 4.3 [RFC2860].

IANA выделяет блоки адресов специального назначения в соответствии с [RFC2860].

2.2. Реструктуризация реестров адресов специального назначения IPv4 и IPv6

Агентство IANA реструктурировало реестры:

IPv4 Special-Purpose Address Registry;
IPv6 Special-Purpose Address Registry.

В реестр IPv4 Special-Purpose Address Registry записана все адреса IPv4 специального назначения. Эти резервирования включают блок 192.0.0.0/24, не ограничиваясь им. Реестр IPv6 Special-Purpose Address Registry содержит все адреса специального назначения IPv6, в том числе блок 2001:0000::/23 (не ограничиваясь им).

В следующем параграфе этого документа описана информация, поддерживаемая в каждой записи реестра. Исходно агентство IANA заполнило реестр IPv4 Special-Purpose Address Registry в соответствии с параграфом 2.2.2 этого документа и IPv6 Special-Purpose Address Registry — в соответствии с параграфом 2.2.3.

IANA будет обновлять упомянутые реестры в соответствии с разделами IANA Considerations документов, прошедших процедуру IETF Review [RFC5226]. Раздел IANA Considerations должен включать все сведения, указанные в параграфе 2.2.1 этого документа.

2.2.1. Требования к информации

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

Address Block — блок адресов

Блок адресов IPv4 или IPv6, зарегистрированных для особых целей.

Name — имя

Описательное имя блока адресов специального назначения.

RFC

RFC, в котором был запрошен блок адресов.

Allocation Date — дата выделения

Дата выделения блока.

Termination Date — дата прекращения действия

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

Source — источник

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

Destination — получатель

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

Forwardable — пересылаемый

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

Global — глобальный

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

Reserved-by-Protocol — зарезервирован протоколом

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

При Destination = FALSE, поля Forwardable и Global также должны иметь значение FALSE.

2.2.2. Записи реестра адресов специального назначения IPv4

В таблицах 1-16 приведены записи, изначально заполненные IANA в реестре IPv4 Special-Purpose Address Registry.

Таблица 1. Данный хост данной сети.

Атрибут	Значение
Блок адресов	0.0.0.0/8
Имя	«This host on this network»
RFC	[RFC1122], параграф 3.2.1.3
Дата выделения	Сентябрь 1981
Дата прекращения действия	Неприменимо
Источник	True
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

Таблица 2. Хост частной сети.

Атрибут	Значение
Блок адресов	10.0.0.0/8
Имя	Private-Use
RFC	[RFC1918]
Дата выделения	Февраль 1996
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 3. Общее пространство адресов.

Атрибут	Значение
Блок адресов	100.64.0.0/10
Имя	Shared Address Space
RFC	[RFC6598]
Дата выделения	Апрель 2012
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 4. Петлевые интерфейсы (Loopback).

Атрибут	Значение
Блок адресов	127.0.0.0/8
Имя	Loopback
RFC	[RFC1122], параграф 3.2.1.3
Дата выделения	Сентябрь 1981
Дата прекращения действия	Неприменимо
Источник	False³
Получатель	False¹
Пересылаемый	False¹
Глобальный	False¹
Зарезервирован протоколом	True

Таблица 5. Локальный канал (Link Local).

Атрибут	Значение
Блок адресов	169.254.0.0/16
Имя	Link Local
RFC	[RFC3927]
Дата выделения	Май 2005
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

Таблица 6. Частные сети.

Атрибут	Значение
Блок адресов	172.16.0.0/12
Имя	Private-Use
RFC	[RFC1918]
Дата выделения	Февраль 1996
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 7. Назначения протоколов IETF.

Атрибут	Значение
Блок адресов	192.0.0.0/24⁴
Имя	IETF Protocol Assignments
RFC	параграф 2.1 of this document
Дата выделения	Январь 2010
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

Таблица 8. DS-Lite.

Атрибут	Значение
Блок адресов	192.0.0.0/29
Имя	DS-Lite
RFC	[RFC6333]
Дата выделения	Июнь 2011
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 9. TEST-NET-1.

Атрибут	Значение
Блок адресов	192.0.2.0/24
Имя	Documentation (TEST-NET-1)
RFC	[RFC5737]
Дата выделения	Январь 2010
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

Таблица 10. 6to4 Relay Anycast.

Атрибут	Значение
Блок адресов	192.88.99.0/24
Имя	6to4 Relay Anycast
RFC	[RFC3068]
Дата выделения	Июнь 2001
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	True
Зарезервирован протоколом	False

Таблица 11. Частные сети.

Атрибут	Значение
Блок адресов	192.168.0.0/16
Имя	Private-Use
RFC	[RFC1918]
Дата выделения	Февраль 1996
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 12. Адреса для тестирования производительности устройств соединения сетей.

Атрибут	Значение
Блок адресов	198.18.0.0/15
Имя	Benchmarking
RFC	[RFC2544]
Дата выделения	Март 1999
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 13. TEST-NET-2.

Атрибут	Значение
Блок адресов	198.51.100.0/24
Имя	Documentation (TEST-NET-2)
RFC	[RFC5737]
Дата выделения	Январь 2010
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

Таблица 14. TEST-NET-3.

Атрибут	Значение
Блок адресов	203.0.113.0/24
Имя	Documentation (TEST-NET-3)
RFC	[RFC5737]
Дата выделения	Январь 2010
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

Таблица 15. Резерв на будущее.

Атрибут	Значение
Блок адресов	240.0.0.0/4
Имя	Reserved
RFC	[RFC1112], параграф 4
Дата выделения	Август 1989
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

Таблица 16. Ограниченное широковещание.

Атрибут	Значение
Блок адресов	255.255.255.255/32
Имя	Limited Broadcast
RFC	[RFC0919], параграф 7
Дата выделения	Октябрь 1984
Дата прекращения действия	Неприменимо
Источник	False
Получатель	True
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

2.2.3. Записи реестра адресов специального назначения IPv6

В таблицах 17-28 приведены записи, изначально заполненные IANA в реестре IPv6 Special-Purpose Address Registry.

Таблица 17. Петлевые интерфейсы (Loopback).

Атрибут	Значение
Блок адресов	::1/128
Имя	Loopback Address
RFC	[RFC4291]
Дата выделения	Февраль 2006
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

Таблица 18. Незаданный адрес.

Атрибут	Значение
Блок адресов	::/128
Имя	Unspecified Address
RFC	[RFC4291]
Дата выделения	Февраль 2006
Дата прекращения действия	Неприменимо
Источник	True
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

Таблица 19. Адрес трансляции IPv4-IPv6.

Атрибут	Значение
Блок адресов	64:ff9b::/96
Имя	IPv4-IPv6 Translat.
RFC	[RFC6052]
Дата выделения	Октябрь 2010
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	True
Зарезервирован протоколом	False

Таблица 20. Адрес трансляции IPv4-Mapped.

Атрибут	Значение
Блок адресов	::ffff:0:0/96
Имя	IPv4-mapped Address
RFC	[RFC4291]
Дата выделения	Февраль 2006
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

Таблица 21. Префикс Discard-Only.

Атрибут	Значение
Блок адресов	100::/64
Имя	Discard-Only Блок адресов
RFC	[RFC6666]
Дата выделения	Июнь 2012
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 22. Назначения протоколов IETF.

Атрибут	Значение
Блок адресов	2001::/23
Имя	IETF Protocol Assignments
RFC	[RFC2928]
Дата выделения	Сентябрь 2000
Дата прекращения действия	Неприменимо
Источник	False⁵
Получатель	False¹
Пересылаемый	False¹
Глобальный	False¹
Зарезервирован протоколом	False

Таблица 23. TEREDO.

Атрибут	Значение
Блок адресов	2001::/32
Имя	TEREDO
RFC	[RFC4380]
Дата выделения	Январь 2006
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 24. Сравнительные тесты.

Атрибут	Значение
Блок адресов	2001:2::/48
Имя	Benchmarking
RFC	[RFC5180]
Дата выделения	Апрель 2008
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 25. Документация.

Атрибут	Значение
Блок адресов	2001:db8::/32
Имя	Documentation
RFC	[RFC3849]
Дата выделения	Июль 2004
Дата прекращения действия	Неприменимо
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

Таблица 26. ORCHID.

Атрибут	Значение
Блок адресов	2001:10::/28
Имя	ORCHID
RFC	[RFC4843]
Дата выделения	Март 2007
Дата прекращения действия	Март 2014
Источник	False
Получатель	False
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	False

Таблица 27. 6to4.

Атрибут	Значение
Блок адресов	2002::/16⁶
Имя	6to4
RFC	[RFC3056]
Дата выделения	Февраль 2001
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	Неприменимо¹
Зарезервирован протоколом	False

Таблица 28. Unique-Local.

Атрибут	Значение
Блок адресов	fc00::/7
Имя	Unique-Local
RFC	[RFC4193]
Дата выделения	Октябрь 2005
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	True
Глобальный	False
Зарезервирован протоколом	False

Таблица 29. Индивидуальные адреса на канале.

Атрибут	Значение
Блок адресов	fe80::/10
Имя	Linked-Scoped Unicast
RFC	[RFC4291]
Дата выделения	Февраль 2006
Дата прекращения действия	Неприменимо
Источник	True
Получатель	True
Пересылаемый	False
Глобальный	False
Зарезервирован протоколом	True

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

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

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

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

Авторы благодарят Geoff Huston и Randy Bush за их полезные замечания. Спасибо также анонимному дарителю, без которого не удалось бы написать этот документ.

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

[RFC0919] Mogul, J., «Broadcasting Internet Datagrams», STD 5, RFC 919, October 1984.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, August 1989.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, March 1999.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, June 2000.

[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, «Initial IPv6 Sub-TLA ID Assignments», RFC 2928, September 2000.

[RFC3056] Carpenter, B. and K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, February 2001.

[RFC3068] Huitema, C., «An Anycast Prefix for 6to4 Relay Routers», RFC 3068, June 2001.

[RFC3849] Huston, G., Lord, A., and P. Smith, «IPv6 Address Prefix Reserved for Documentation», RFC 3849, July 2004.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, May 2005.

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

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

[RFC4379] Kompella, K. and G. Swallow, «Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures», RFC 4379, February 2006.

[RFC4380] Huitema, C., «Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)», RFC 4380, February 2006.

[RFC4773] Huston, G., «Administration of the IANA Special Purpose IPv6 Address Block», RFC 4773, December 2006.

[RFC4843] Nikander, P., Laganier, J., and F. Dupont, «An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)», RFC 4843, April 2007.

[RFC5156] Blanchet, M., «Special-Use IPv6 Addresses», RFC 5156, April 2008.

[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, «IPv6 Benchmarking Methodology for Network Interconnect Devices», RFC 5180, May 2008.

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

[RFC5735] Cotton, M. and L. Vegoda, «Special Use IPv4 Addresses», RFC 5735, January 2010.

[RFC5736] Huston, G., Cotton, M., and L. Vegoda, «IANA IPv4 Special Purpose Address Registry», RFC 5736, January 2010.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, January 2010.

[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, «Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)», RFC 5884, June 2010.

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, «IPv6 Addressing of IPv4/IPv6 Translators», RFC 6052, October 2010.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, «Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion», RFC 6333, August 2011.

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, «IANA-Reserved IPv4 Prefix for Shared Address Space», BCP 153, RFC 6598, April 2012.

[RFC6666] Hilliard, N. and D. Freedman, «A Discard Prefix for IPv6», RFC 6666, August 2012.

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

Michelle Cotton

Internet Corporation for Assigned Names and Numbers (ICANN)

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

USA

Phone: +310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.icann.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers (ICANN)

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

USA

Phone: +310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.icann.org/

Ronald P Bonica (редактор)

Juniper Networks

2251 Corporate Park Drive

Herndon, VA 20171

USA

EMail: rbonica@juniper.net

Brian Haberman

Johns Hopkins University (JHU) Applied Physics Lab

11100 Johns Hopkins Road

Laurel, MD 20723-6099

USA

EMail: brian@innovationslab.net

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Для некоторых протоколов имеются исключения. См. [RFC4379] и [RFC5884].

4Не применимо, пока нет более конкретного резервирования.

5Пока не разрешено более конкретным назначением.

6См. [RFC3056].

Рубрика: RFC | Комментарии отключены

RFC 6887 Port Control Protocol (PCP)

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

Internet Engineering Task Force (IETF)                      D. Wing, Ed.
Request for Comments: 6887                                         Cisco
Category: Standards Track                                    S. Cheshire
ISSN: 2070-1721                                                    Apple
                                                            M. Boucadair
                                                          France Telecom
                                                                R. Penno
                                                                   Cisco
                                                              P. Selkirk
                                                                     ISC
                                                              April 2013

Протокол управления портом (PCP)

Port Control Protocol (PCP)

PDF

Аннотация

Протокол управления портом (PCP) позволяет хостам IPv6 или IPv4 управлять трансляцией и пересылкой входящих пакетов IPv6 или IPv4 на устройствах NAT¹ или простых межсетевых экранах (МСЭ), а также оптимизировать свои исходящие сообщения NAT keepalive.

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

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

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

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

1 Введение

Протокол PCP обеспечивает механизм контроля за пересылкой входящих пакетов устройствами восходящего направления (upstream) типа NAT64⁴, NAT44⁵ и межсетевых экранов IPv6 и IPv4, а также механизм снижения трафика keepalive от приложений. Протокол PCP разработан для реализации в контексте CGN⁶ и небольших NAT (например, домашних), а также маршрутизаторов CPE⁷ с поддержкой протоколов IPv6/IPv4 или только IPv6 и всех существующих в настоящее время сценариев перехода к маршрутизаторам CPE с поддержкой только IPv6. PCP позволяет хостам поддерживать серверы, работающие достаточно долго (например, видеокамера с сетевым подключением) или в течение короткого времени (например, сеанс игры или телефонный звонок) при нахождении за устройством NAT, включая устройства CGN у провайдера Internet или МСЭ IPv6, встроенные в маршрутизаторы CPE.

PCP позволяет приложениям создавать отображения внешних адресов IP, протоколов и портов на внутренние адреса IP, протоколы и порты. Эти отображения нужны для входящих соединений с машинами, расположенными за устройством NAT или МСЭ.

После организации отображения для входящих соединений необходимо сообщить удаленным компьютерам адрес IP, протокол и порт для входящих соединений. Обычно такое оповещение зависит от приложения. Например, компьютерная игра может использовать специальный рандеву-сервер, обслуживающий эту игру (или поддерживаемый ее разработчиком), телефон SIP будет использовать SIP-прокси, а клиент обнаружения служб на базе DNS⁸ [RFC6763] будет применять [RFC2136] [RFC3007]. PCP не поддерживает функций «сводника». Такие функции могут работать с протоколом IPv4, IPv6 или поддерживать оба протокола. В зависимости от этого, а также от поддержки приложениями IPv4 или IPv6, клиенту PCP может потребоваться отображение для IPv4, IPv6 или обоих протоколов.

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

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

2 Сфера применения

2.1 Сценарии развертывания

PCP может использоваться в разных сценариях, включая:

базовую трансляцию NAT [RFC3022];
трансляцию сетевых адресов и портов [RFC3022], широко используемую в домашних устройствах NAT;
операторские NAT [RFC6888];
DS-Lite [RFC6333];
NAT с поддержкой уровня 2 [L2NAT];
Dual-Stack Extra Lite [RFC6619]
NAT64 без учета [RFC6145] и с учетом [RFC6146] состояния;
управление МСЭ IPv4 и IPv6 [RFC6092];
трансляцию сетевых префиксов IPv6-IPv6 (NPTv6) [RFC6296].

2.2 Поддерживаемые протоколы

Коды операций PCP (Opcode), определенные в данном документе, разработаны для поддержки протоколов транспортного уровня с 16-битовой нумерацией портов (например, TCP, UDP, SCTP¹⁰ [RFC4960] и DCCP¹¹ [RFC4340]). Протоколы, которые не пользуются номерами портов (например, RSVP¹², ESP¹³ [RFC4303], ICMP, ICMPv6) поддерживаются для межсетевых экранов IPv4 и IPv6, а также NPTv6, но не входят в сферу действия функций NAT.

2.3 Пользовательская сеть с одним подключением

В PCP предполагается модель адресации IP с однодомным подключением. Т. е., для данного адреса IP существует только один принятый по умолчанию маршрут для доступа к другим хостам Internet с данного IP-адреса. Это важно, поскольку после организации отображения PCP, изменения входящих пакетов (например, TCP SYN) и их доставки хосту, исходящие отклики (например, TCP SYNACK) будут идти по тому же (обратному) пути, на котором пройдут через то же устройство NAT, которое сможет соответствующим образом изменить исходящие пакеты. Это ограничение связано с тем, что в противном случае потребовалось бы поддерживающее PCP устройство NAT для каждого исходящего пути (поскольку хост не может достоверно знать исходящий путь), а клиент должен будет организовать одинаковые отображения «внешний-внутренний» для каждого шлюза NAT, что в общем случае не представляется возможным (поскольку на других устройствах NAT требуемый внешний порт уже может быть отображен на другой хост).

3 Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с «Key words for use in RFCs to Indicate Requirement Levels» [RFC2119].

Internal Host — внутренний хост

Хост, обслуживаемый шлюзом NAT или защищенный МСЭ. Это хост, который будет получать входящий трафик в результате запроса на отображение PCP, или хост, инициировавший динамическое исходящее отображение (например, передал TCP SYN) через межсетевой экран или NAT.

Remote Peer Host — удаленный хост-партнер

Хост, с которым обменивается данными внутренний хост. Это может быть другой (или даже тот же самый) внутренний хост, в этом случае при использовании NAT устройство NAT должно будет «заворачивать» трафик назад [RFC4787].

Internal Address — внутренний адрес

Адрес внутреннего хоста, обслуживаемого шлюзом NAT или защищенного МСЭ.

External Address — внешний адрес

Адрес внутреннего хоста с точки зрения других внешних партнеров в Internet, с которыми данный хост взаимодействует после трансляции во всех устройствах NAT на пути. Внешний адрес в общем случае является глобально маршрутизируемым (т. е., не приватным). Если внутренний хост защищен только МСЭ и на пути нет трансляции адресов, внешний адрес будет совпадать с внутренним.

Endpoint-Dependent Mapping (EDM) — зависящее от конечной точки отображение

Операция NAT, в которой для неявного отображения, организуемого исходящим трафиком (например, TCP SYN) от одного внутреннего адреса, протокола и порта к удаленным партнерам и портам, могут выделяться разные внешние порты, а при следующем запросе отображения PCP для данного внутреннего адреса, протокола и порта может быть выделен еще один внешний порт. Эта операция может применяться для отображений, зависящих от адреса (Address-Dependent Mapping) или адреса и порта (Address and Port-Dependent Mapping) [RFC4787].

Endpoint-Independent Mapping (EIM) — независимое от конечной точки отображение

Операция NAT, при которой для всех отображений от одного внутреннего адреса, протокола и порта выделяется один внешний адрес ии порт.

Remote Peer Address — адрес удаленного партнера

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

Third Party — третья сторона

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

В некоторых случаях устройство может организовывать отображения от имени других устройств, которые не поддерживают PCP, — присутствие опции THIRD_PARTY в запросе MAP говорит, что в качестве внутреннего адреса следует использовать указанный адрес вместо IP-адреса отправителя в запросе PCP.

Mapping, Port Mapping, Port Forwarding — отображение, отображение портов, перенаправление портов

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

Mapping Types — типы отображений

Имеется три критерия для классификации типов отображений: способ организации (явный/неявный), основное назначение (входное/выходное) и способ удаления (динамические/статические). Неявные отображения являются «побочным» результатом некоторых других операций, явные создаются с помощью специального механизма. Выходные отображения служат прежде всего для поддержки исходящих соединений, а входные — для входящих вызовов. Динамические отображения автоматически удаляются по истечении срока существования, а статические сохраняются до тех пор, пока не будут удалены пользователем.

Неявные динамические отображения организуются, как «побочный» эффект исходящего трафика типа пакетов TCP SYN или UDP. Такие пакеты изначально не направлены на создание состояния в NAT (или МСЭ), но они могут вызывать такой эффект при прохождении через устройство NAT (или МСЭ). Неявные динамические отображения обычно существуют в течение ограниченного срока, хотя этот срок в общем случае не известен использующему отображение клиенту.
Явные динамические отображения создаются в результате PCP-запросов MAP и PEER. Подобно аренде адресов DHCP явные динамические отображения имеют ограниченное время жизни и это время сообщается клиенту. Как и для DHCP клиент, желающий сохранять отображение, должен время от времени обновлять его, чтобы время жизни не истекло. Если клиент PCP «уходит», все созданные им отображения автоматически удаляются по истечении времени их жизни.
Явные статические отображение организуются путем настройки конфигурации (например, с помощью команд или графического интерфейса) и существуют до тех пор, пока пользователь не изменит данную конфигурацию.

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

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

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

Выходные отображения существуют, прежде всего, для поддержки исходящих соединений. Например, когда хост вызывает функцию connect() для организации исходящего соединения, шлюз NAT будет создавать неявное динамическое отображение для поддержки такого соединения.
Входные отображения существуют, прежде всего, для обеспечения серверам возможности приема входящих соединений. В общем случае, когда хост вызывает функцию listen() для прослушивания входящих соединений, устройство NAT будет неявно создавать отображение для поддержки входящих соединений. Для явного создания динамического входного отображения может использоваться запрос PCP MAP.

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

PCP Client — клиент PCP

Программный экземпляр PCP для отправки запросов PCP серверу PCP. На одном хосте может быть одновременно запущено несколько клиентов PCP. В одной локальной сети может размещаться несколько клиентов PCP. Клиент PCP может делать запросы PCP от имени другого устройства, предоставившего ему такие полномочия. Примером клиента PCP могут служить сетевые функции устройств UPnP IGDv1¹⁴ [IGDv1]. Сервер PCP на шлюзе NAT, который сам по себе является клиентом другого шлюза NAT (вложенная трансляция), может быть PCP-клиентом восходящего NAT.

PCP-Controlled Device — управляемое PCP устройство

Устройство NAT или МСЭ, которое контролирует и изменяет потоки пакетов между внутренними хостами и их удаленными партнерами. Протокол PCP управляет отображениями на этом устройстве.

PCP Server — сервер PCP

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

Subscriber — абонент (подписчик)

Субъект коммерческого учета ISP. Подписчик может получать от коммерческого ISP один адрес IP (этот адрес может совместно использоваться множеством хостов, расположенных за шлюзом NAT, которые с точки зрения ISP будут выглядеть, как один хост) или множество таких адресов. В любом случае предоставленные коммерческим ISP адреса IP могут впоследствии транслироваться шлюзом CGN на стороне ISP.

4 Отношения сервера PCP с его устройствами, управляемыми PCP

Сервер PCP получает запросы PCP и выдает отклики на них. Серверы PCP обычно совмещаются с устройствами NAT или МСЭ, как показано на рисунке 1. Функциональность PCP может также обеспечиваться неким другим устройством, которое взаимодействует с устройством(ами) NAT или МСЭ на основе фирменного (proprietary) механизма. С точки зрения клиента PCP такое «расщепленное» устройство не отличимо от интегрированного.

                      +-----------------+
+------------+        |   NAT или МСЭ   |
| Клиент PCP |-<сеть>-+    с сервером   +---<Internet>
+------------+        |       PCP       |
                      +-----------------+

Рисунок 1. Межсетевой экран или устройство NAT с поддержкой PCP.

Устройство NAT или МСЭ между клиентом PCP и сетью Internet может реализовать простой или расширенный набор функций МСЭ. Как дополнительный эффект используемой технологии (например, транслятор адресов и портов обычно будет требовать организации соединений из внутренней сети в направлении Internet просто в силу того, что при трансляции изменяются номера портов) или в соответствии с явно заданными правилами незапрошенный трафик из Internet будет отвергаться. Некоторые МСЭ отвергают часть незапрошенного трафика из Internet (например, для большинства портов TCP и UDP), принимая другую его часть (например, UDP 500 и IP ESP) [RFC6092]. Рассмотрение используемой по умолчанию фильтрации выходит за рамки PCP. Если клиентское устройство хочет получать трафик и поддерживает PCP, но не знает заранее принятой по умолчанию политики фильтрации, ему следует использовать PCP для запроса отображения, позволяющего получать желаемый трафик.

5 Адреса фиксированного размера

Для простоты генерации и разбора пакетов с запросами и откликами PCP всегда использует 128-битовые адреса IP как для IPv6, так и для IPv4.

При работе с IPv6 128-битовые поля адресов IP просто содержат адреса IPv6 без каких-либо изменений.

Для IPv4 адреса IPv4 отображаются на адреса IPv6 в соответствии с [RFC4291] (::ffff:0:0/96). Первые 80 битов имеют нулевые значения, следующие 16 битов — 1, а в последних 32 битах размещается адрес IPv4. Это позволяет однозначно идентифицировать естественные адреса IPv6, поскольку отображенные на IPv4 адреса IPv6 [RFC4291] не будут корректными для отображения.

При проверке отображенных на IPv4 адресов IPv6 должны проверяться все первые 96 битов, недостаточно убедиться в том, что биты 81-96 имеют значение 1.

Адрес all-zeros IPv6 должен представляться заполнением всего 128-битового поля адреса IP нулями (::).

Адрес all-zeros IPv4 должен содержать 80 битов нулей, 16 битов единиц и снова 32 бита нулей (::ffff:0:0).

6 Устройство протокола

PCP можно рассматривать, как протокол «запрос-отклик», он похож на другие протоколы такого типа, работающие на основе транспорта UDP и может быть реализован столь же хорошо. Можно рассматривать протокол и как взаимодействие вида «намек-уведомление» (hint/notification), что может упростить реализацию.

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

от клиента к серверу передается поток «намеков», в которых клиент показывает серверу, какое отображение он хотел бы получить;
поток уведомлений от сервера PCP, в которых сервер информирует клиента о созданных отображениях.

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

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

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

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

Сказанное выше помогает понять, почему в запросах и откликах PCP нет идентификаторов транзакций. Эти идентификаторы просто не нужны и будут вносить неоправданные ограничения в работу протокола, а также осложнять его реализацию. Отклик сервера PCP (т. е., уведомление) является самодостаточным и полным. Он включает внутренний и внешний адрес, протокол и порты для отображения, а также указывает время жизни отображения. Если клиенту нужно такое отображение, он просто обновляет свое состояние на основе полученных данных. Если отображение не нужно клиенту, он может просто игнорировать полученное сообщение. При получении незапрошенных уведомлений клиент не обязан выполнять какие-либо действия. В современных сетях шлюзы NAT могут использовать статические отображения, о которых клиент не имеет явных сведений и не может как-то влиять на них. Клиентское устройство может быть напрямую подключено к сети Internet с глобально маршрутизируемым адресом IP и в таком случае он имеет «отображение» для всех прослушиваемых им портов. Такое устройство само несет ответственность за свою безопасность и не может предполагать, что какое-то иное устройство в сети блокирует входящие пакеты.

7 Общий формат заголовков запросов и откликов

Все сообщения PCP передаются по протоколу UDP с максимальным размером поля данных UDP в 1100 октетов. Сообщения PCP содержат заголовок запроса или отклика, включающий код операции Opcode, относящиеся к операции данные (Opcode-specific information) и может также включать одну или несколько опций. Все числовые значения, размер которых превышает 1 октет (например, коды результата, время жизни, время Epoch и т. п.) используют сетевой порядок IETF (т. е., сначала передается старший октет). Нечисловые значения представляются как на всех платформах без перестановки байтов (например, адреса IP и номера портов размещаются в сообщениях PCP так же, как это делается в заголовках IP или TCP).

Схема пакета использует общий заголовок, операции клиентов и серверов PCP описаны ниже. Приведенная в данном разделе информация применима для всех операций (Opcode). Операции, определенные в данном документе, описаны в разделах 10, 11 и 12.

7.1 Заголовок запроса

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version = 2  |R|   Opcode    |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Requested Lifetime (32 бита)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            PCP Client's IP Address (128 битов)                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:         (не обязательно) Opcode-specific information          :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:              (не обязательно) PCP Options                     :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат запроса.

Формат запросов показан на рисунке 2.

Version — версия

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

R — запрос/отклик

Указывает запрос (0) или отклик (1).

Opcode — код операции

7-битовое значение, указывающее код выполняемой операции. Коды операций MAP и PEER определены в разделах 11 и 12.

Reserved — резерв

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

Requested Lifetime — запрошенное время жизни

32-битовое целое число без знака, определяющее срок жизни отображения в секундах (0 — 2³²-1). Это значение используется определенными в данном документе операциями MAP и PEER.

PCP Client’s IP Address — IP-адрес клиента PCP

Адрес отправителя IPv4 или IPv6 в заголовке IP, использованном клиентом PCP при передаче данного запроса PCP. Адреса IPv4 отображаются на адреса IPv6. Поле PCP Client’s IP Address из заголовка сообщения PCP используется для обнаружения неожиданных устройств NAT на пути между клиентом PCP и управляемым PCP устройством NAT или МСЭ (см. параграф 8.1).

Opcode-specific information – специфические для операции данные

Дополнительные данные для Opcode. Размер данных определяется значением Opcode.

PCP Options — опции PCP

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

7.2 Заголовок отклика

Формат откликов показан на рисунке 3.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Version = 2  |R|   Opcode    |   Reserved    |  Result Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Lifetime (32 бита)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Epoch Time (32 бита)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      Reserved (96 битов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:         (не обязательно) Opcode-specific information          :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:              (не обязательно) PCP Options                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Формат отклика.

Version — версия

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

R — запрос/отклик

Указывает запрос (0) или отклик (1). Во всех откликах должно использоваться значение 1. Устанавливается сервером.

Opcode — код операции

7-битовое значение, указывающее код выполняемой операции. Сервер копирует это значение из запроса.

Reserved — резерв

8 резервных битов. При передаче должны устанавливаться в 0, а при получении должны игнорироваться. Устанавливаются сервером.

Result Code — код результата

Код результата для данного отклика. Возможные значения описаны в параграфе 7.4. Устанавливается сервером.

Lifetime — время жизни

32-битовое целое число без знака, определяющее срок жизни отображения в секундах (0 — 2³²-1). В откликах об ошибках это значение указывает предполагаемое время, в течение которого ошибка на сервере PCP при повторении запроса также будет повторяться. При успешном выполнении запроса для кодов, создающих отображение (MAP и PEER), поле Lifetime указывает срок жизни отображения. Устанавливается сервером.

Epoch Time

Значение параметра Epoch Time на сервере (см. параграф 8.5). Устанавливается сервером.

Reserved — резерв

96 резервных битов. Для запросов, которые были успешно разобраны все биты должны иметь значение 0 (устанавливается сервером) и игнорироваться при получении. Если разобрать запрос не удалось, сервер копирует последние 96 битов поля PCP Client’s IP Address из соответствующего запроса.

Opcode-specific information – специфические для операции данные

Дополнительные данные для Opcode. Размер данных определяется значением Opcode.

PCP Options — опции PCP

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

7.3 Опции

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

Опции используют формат TLV¹⁵, показанный ниже:


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Code  |  Reserved     |       Option Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                  (не обязательно) Data                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Заголовок опций.

Option Code – код опции

8 битов. Старший бит кода показывает является обработка этой опции обязательной (0) или не обязательной (1).

Reserved — резерв

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

Option Length — размер опции

16 битов. Указывает размер поля данных опции в октетах. Данные опции могут иметь нулевой размер (0). Если размер опции не кратен 4, в нее включается от 1 до 3 октетов заполнения со значениям 0 для выравнивания опции по 4-октетной границе. В поле Option Length указывается истинный размер опции без учета заполнения.

Data — данные

Данные опции.

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

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

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

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

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

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

Для разных кодов (Opcode) корректны различные опции. Например,

опция THIRD_PARTY применима для кодов MAP и PEER;
опция FILTER корректна только для MAP Opcode (для PEER Opcode она просто не имеет смысла);
опция PREFER_FAILURE применима только для MAP (для PEER аналогичная семантика применяется автоматически).

7.4 Коды результата

Перечисленные ниже коды результатов могут возвращаться для любых кодов Opcode, полученных сервером PCP. Единственным кодом успешного выполнения операции является 0, а все остальные значения говорят о тех или иных ошибках. Если сервер PCP сталкивается с множеством ошибок в процессе выполнения запроса, ему следует возвращать наиболее специфичный код ошибки. Каждый из приведенных ниже кодов связан с продолжительной или краткосрочной ошибкой и эту информацию разработчики серверов PCP могут использовать в качестве значения поля Lifetime в сообщениях об ошибках. Рекомендуется использовать для краткосрочных ошибок срок в 30 секунд, а для долгосрочных — 30 минут.

0 SUCCESS — успешное выполнение

Операция выполнена без ошибок.

1 UNSUPP_VERSION — неподдерживаемая версия

Номер версии, указанный в начале заголовка PCP Request, не распознан данным сервером PCP. Эта ошибка относится к долгосрочным. Данный документ описывает PCP версии 2.

2 NOT_AUTHORIZED — нет полномочий

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

3 MALFORMED_REQUEST — некорректный по форме запрос

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

4 UNSUPP_OPCODE — неподдерживаемая операция

Операция с указанным Opcode не поддерживается. Эта ошибка относится к долгосрочным.

5 UNSUPP_OPTION — неподдерживаемая опция

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

6 MALFORMED_OPTION — некорректный формат опции

Ошибка в формате опции (например, избыточные повторы, некорректный размер). Ошибка является долгосрочной.

7 NETWORK_FAILURE — отказ в сети

Сервер PCP или управляемое им устройство столкнулись с тем или иным отказом в сети (например, внешний адрес IP еще не был получен). Эта ошибка относится к краткосрочным.

8 NO_RESOURCES — недостаточно ресурсов

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

9 UNSUPP_PROTOCOL — неподдерживаемый протокол

Неподдерживаемый транспортный протокол (например, SCTP для устройства NAT, которое обслуживает лишь UDP и TCP). Эта ошибка относится к долгосрочным.

10 USER_EX_QUOTA — превышение квоты пользователем

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

11 CANNOT_PROVIDE_EXTERNAL — невозможно предоставить внешний порт или адрес

Предложенный внешний порт и/или адрес не может быть предоставлен. Код должен возвращаться только для:

запросов MAP с опцией PREFER_FAILURE (обычные запросы MAP возвращают доступный внешний порт);
запросов MAP для протокола SCTP (подразумевается PREFER_FAILURE);
запросов PEER.

Описание опции PREFER_FAILURE дано в параграфе 13.2. Длительность ошибки зависит от причины отказа.

12 ADDRESS_MISMATCH — несоответствие адресов

IP-адрес отправителя в пакете с запросом не соответствует содержимому поля PCP Client’s IP Address по причине наличия не ожидаемого устройства NAT на пути между клиентом PCP и управляемым PCP устройством NAT или МСЭ. Эта ошибка относится к долгосрочным.

13 EXCESSIVE_REMOTE_PEERS

Сервер PCP не способен создать фильтры для данного запроса. Этот код должен возвращаться только для запросов MAP с опцией FILTER, описанной в параграфе 13.3. Эта ошибка относится к долгосрочным.

8 Функционирование PCP

Сообщения PCP должны передаваться по протоколу UDP [RFC0768]. На каждый запрос PCP создается по крайней мере один отклик, поэтому протоколу PCP не требуется транспорт с гарантированной доставкой.

При получении множества идентичных запросов сервер PCP обычно будет генерировать идентичные отклики за исключением тех случаев, когда состояние сервера PCP меняется между запросами в результате иных действий. Примером такой смены состояния может служить получение запроса в то время, когда управляемое PCP устройство не имеет доступных отображений и сервер PCP генерирует отклик с сообщением об ошибке. Если отображение становится доступным и поступает другая копия того же запроса (возможно в результате дублирования в сети), сервер PCP будет создавать отображение и возвращать отклик без ошибки. Клиент PCP должен обрабатывать такие обновленные отклики для всех своих запросов (прежде всего с целью поддержки быстрого восстановления, описанного в параграфе 14). Дополнительная информация о работе протокола приведена в разделе 6 Устройство протокола.

8.1 Клиент PCP — генерация запроса

В этом параграфе рассматриваются действия клиента PCP для всех значений Opcode. Процедуры для операции MAP описаны в разделе 11, а для операции PEER — в разделе 12.

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

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

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

С известным адресом сервера PCP клиент генерирует свой запрос PCP. Этот запрос включает общий заголовок PCP, PCP Opcode и данные, а также может включать опции. Как для любых программных клиентов UDP во всех операционных системах при наличии на хосте нескольких независимых клиентов PCP каждый из них будет использовать свой порт-источник, чтобы запросы и соответствующие им отклики не путались. Номер порта-источника для клиентов PCP следует генерировать случайным образом [RFC6056].

Клиент PCP должен включать IP-адрес отправителя сообщения PCP в свой запрос PCP. Обычно это будет IP-адрес клиента; представление адреса описано в параграфе 16.4. Наличие этого адреса позволяет определить наличие неожиданных устройств NAT на пути между клиентом PCP и управляемым PCP устройством NAT или МСЭ для того, чтобы предотвратить затрату ресурсов управляемого PCP устройства NAT на создание неработающих отображений. При обнаружении такого внутреннего устройства NAT, не поддерживающего PCP, сначала требуется создать с использованием неких иных средств отображение на внутреннем устройстве NAT, а потом с учетом этого отображения создавать соответствующее отображение на внешнем устройстве NAT, поддерживающем PCP. Получив с помощью того или иного метода отображение на внутреннем NAT, клиенту PCP следует использовать внешний адрес этого внутреннего устройства NAT в качестве клиентского адреса IP, чтобы сообщить внешнему устройству NAT под управлением PCP о том, что клиенту известно наличие промежуточного устройства NAT и приняты меры по созданию соответствующего отображения на этом устройстве, а полученное от внешнего устройства NAT отображение не станет бессмысленным.

8.1.1 Повтор запроса клиентом

Клиент PCP сам отвечает за доставку запросов PCP. Если клиент PCP не получает ожидаемого отклика от сервера, он должен повторить передачу своего сообщения. При повторе должно использоваться то же значение Mapping Nonce (см. параграфы 11.1 и 12.1). Клиент начинает обмен сообщениями с передачи сообщения серверу. Обмен продолжается до тех пор, пока у клиента сохраняется потребность в отображении и прерывается, когда транзакция PCP становится ненужной клиенту (например, запросившей отображение программе это отображение больше не требуется) или (опционально) принимается решение о возникновении отказа при обмене сообщениями в соответствии с описанными ниже правилами.

Поведение клиента при повторе передач управляется и описывается следующими переменными:

RT — тайм-аут повтора передачи, рассчитываемый в соответствии с приведенным ниже описанием;

IRT — изначальный интервал повтора (следует устанавливать 3 секунды);

MRC — максимальное число повторов (следует устанавливать значение 0 — неограниченное число повторов);

MRT — максимальный интервал повтора (следует устанавливать 1024 секунды);

MRD — максимальная продолжительность повторов (следует устанавливать 0 — неограниченное время);

RAND — случайный коэффициент, рассчитываемый в соответствии с приведенным ниже описанием.

При каждой передаче или повторе сообщения клиент устанавливает значение RT в соответствии с приведенными ниже правилами. Если RT истекает до получения отклика, клиент повторяет передачу и рассчитывает новое значение RT.

Каждый расчет нового значения RT включает новый случайный коэффициент (RAND), который представляет собой случайное значение выбранное из однородного распределения в диапазоне от -0,1 до +0,1. Случайный коэффициент служит для рассинхронизации сообщений, передаваемых клиентами PCP. К алгоритму выбора случайного значения не предъявляется криптографических требований. Алгоритму следует создавать разные последовательности случайных чисел для каждого вызова клиента PCP.

Начальное значение RT задается на основе IRT:

      RT = (1 + RAND) * IRT

Для каждой последующей передачи сообщения значение RT базируется на предшествующем значении тайм-аута с учетом верхней границы RT, заданной значением MRT. Если MRT = 0, это означает отсутствие верхней границы для RT (MRT трактуется как «бесконечность»). Новое значение RT вычисляется по формуле (RTprev — текущее значение RT):

      RT = (1 + RAND) * MIN (2 * RTprev, MRT)

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

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

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

После того, как клиент PCP получит отклик об успешном завершении операции от сервера PCP на данном интерфейсе, он устанавливает для RT случайное значение из диапазона 1/2 — 5/8 от времени жизни отображения, как описано в параграфе 11.2.1 Обновление отображения и передает последующие запросы PCP для отображений тому же серверу.

Примечание. Если состояние сервера меняется в интервале между повторами сообщений, а отклик сервера задерживается или теряется, состояния сервера и клиента PCP могут оказаться рассинхронизированными. Это не является особенностью PCP и случается также в других протоколах (например, TCP). Если такая маловероятная рассинхронизация происходит, PCP «излечивается» самостоятельно по истечении времени жизни отображения.

8.2 Сервер PCP — обработка запроса

В этом параграфе более подробно рассматриваются операции на сервере PCP. Обработку следует выполнять в описанном ниже порядке.

Сервер PCP должен принимать только нормальные (не THIRD_PARTY) запросы PCP от клиента на том же интерфейсе, через который он обычно получает пакеты от данного клиента, и должен без уведомлений игнорировать запросы PCP на любом другом интерфейсе. Например, домашний шлюз NAT принимает запросы PCP только на внутреннем (LAN) интерфейсе и игнорирует без уведомлений все запросы PCP на внешнем (WAN) интерфейсе. Сервер PCP, поддерживающий запросы THIRD_PARTY, может быть настроен на восприятие запросов THIRD_PARTY на других интерфейсах (см. описание опции THIRD_PARTY в параграфе 13.1).

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

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

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

Все отклики (как при успехе, так и в случае ошибки) содержат Opcode из запроса, но с установленным битом R.

Все сообщения об ошибках имеют отличный от 0 код результата и создаются путем:

копирования всех данных UDP или 1100 октетов (если данных больше) и дополнения нулями для выравнивания по 4-октетной границе (при необходимости);
установки бита R;
установки кода результата;
установки значений полей Lifetime, Epoch Time и Reserved;
обновления других полей отклика, для которых в описании поля указано «устанавливается сервером».

Отклик об успешном завершении имеет нулевой код результата и создается путем:

копирования 4-х первых октетов заголовка пакета с запросом;
установки бита R;
установки кода результата в 0;
установки значений полей Lifetime, Epoch Time и Reserved;
установки связанных с опциями данных в тех случаях, когда это требуется;
добавления опций обработки отклика.

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

Если в запросе установлен бит R, сообщение отбрасывается без уведомления.

Если в первом октете (версия) указан не поддерживаемый номер версии, генерируется отклик с кодом результата UNSUPP_VERSION, после чего выполняются действия по согласованию версии, описанные в разделе 9.

Если версия поддерживается, но полученное сообщение короче 24 октетов, оно отбрасывается без уведомления.

Если сервер перегружен запросами (от данного клиента или от всех клиентов), он может просто отбрасывать запросы без уведомлений, поскольку клиенты PCP будут повторять запросы, или генерировать отклики NO_RESOURCES.

Если размер сообщения превышает 1100 октетов, не кратен 4 октетам или слишком мал для указанного Opcode, он считается недопустимым и сервер генерирует отклик MALFORMED_REQUEST, уменьшая размер сообщения до 1100 октетов.

Сервер PCP сравнивает адрес IP (из IP-заголовка принятого пакета) с полем PCP Client IP Address. Если адреса не совпадают, должен генерироваться отклик ADDRESS_MISMATCH. Это делается для обнаружения и предотвращения случайного использования PCP в тех случаях, когда на пути между клиентом и сервером имеется не поддерживающее PCP устройство NAT. Если клиент PCP хочет получить отображение в такой ситуации, он должен обеспечить соответствие поля PCP адресу IP, который будет видеть сервер PCP.

8.3 Клиент PCP — обработка отклика

Клиент PCP получает отклик и проверяет соответствие IP-адреса отправителя и номера порта серверу PCP, которому был отправлен запрос PCP. При обнаружении несоответствия отклик отбрасывается без уведомления.

При получении отклика PCP размером менее 4 октетов такой отклик отбрасывается без уведомления.

Если бит R в отклике не установлен, такой отклик отбрасывается без уведомления.

Если в отклике указан код результата UNSUPP_VERSION, выполняется согласование версий, описанное в разделе 9.

Отклики, размер которых меньше 24 октетов, больше 1100 или не кратен 4, являются некорректными и игнорируются.

Далее клиент PCP проверяет соответствие значения Opcode отправленному ранее запросу PCP. Если отклик не соответствует отправленному запросу PCP, он игнорируется. После этого проводится сравнение специфических для Opcode полей данных в запросе и отклике в соответствии с описанием обработки для данного Opcode. При наличии расхождений отклик игнорируется.

После успешного завершения проверок клиент PCP просматривает поле Epoch Time (см. параграф 8.5) для определения потребности в обновлении своего состояния на сервере PCP. Клиенту PCP следует быть готовым к получению множества откликов от сервера PCP в любой момент после отправки одного запроса. Это позволяет серверу PCP информировать клиента о таких изменениях отображений, как обновление или удаление. Например, сервер PCP может передать отклик SUCCESS, а потом в результате изменения своей конфигурации, передать отклик NOT_AUTHORIZED. Клиент PCP должен быть готов к получению откликов на запросы, которых он не передавал (они могли быть переданы предшествующим экземпляром PCP на этом же хосте, другим хостом, который использовал такой же адрес IP, или атакующим систему злоумышленником) — такие сообщения просто игнорируются.

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

Во всех откликах возвращается поле времени жизни (Lifetime). Значение этого поля показывает продолжительность интервала, в течение которого клиенту следует считать данных отклик действующим (при позитивном отклике это будет время действия созданного отображения, при отказах — время сохранения условий, вызвавших ошибку). Клиенту PCP следует ограничивать сверху значение времени жизни (для предотвращения абсурдно больших значений) в соответствии с параграфом 15 Срок действия и удаление отображений.

Если код результата имеет значение 0 (SUCCESS), запрос завершился успешно.

Отличный от 0 код результата говорит о возникновении отказа и клиенту PCP не следует повторять передачу того же запроса в течение указанного полем Lifetime срока (с учетом ограничений, описанных в разделе 15).

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

8.4 Множественные интерфейсы

Хосты, которым требуется отображение PCP, могут иметь множество интерфейсов (логических и/или физических). На практике хост может использовать несколько адресов IPv4 (например, Wi-Fi и Ethernet) или адреса IPv4 и IPv6. Эти адреса могут иметь разные области видимости (например, IPv6 с глобальной в случае GUA¹⁶ [RFC3587] или ограниченной в случае ULA¹⁷ [RFC4193] доступностью).

Адреса IPv6 с глобальной доступностью (например, GUA) следует использовать в качестве адреса отправителя при генерации запроса PCP. Адреса IPv6 без глобальной доступности (например, ULA) не следует применять в качестве исходного интерфейса при генерации запроса PCP. Если для отображений PCP применялся приватный адрес IPv6 [RFC4941], потребуется новый запрос PCP в случае изменения приватного адреса IPv6. Такой запрос PCP следует передавать непосредственно с приватного адреса IPv6. Клиентам рекомендуется удалять отображения для предыдущего приватного адреса после того, как потребность в них отпадет.

По причине повсеместного использования IPv4 NAT, адреса IPv4 с ограниченной доступностью (например, приватные адреса [RFC1918]) могут использоваться в качестве адреса источника при генерации запросов PCP.

8.5 Эпоха

Каждый отклик PCP, передаваемый сервером PCP, включает поле Epoch Time. Значение этого параметра на сервере инкрементируется каждую секунду. Аномалии в полученном клиентом значении Epoch Time подсказывают клиенту, что состояние на сервере PCP могло быть потеряно. Клиенты отвечают на такую подсказку быстрым запросом обновления для данного отображения, что позволяет без промедления восстановить потерянное состояние на сервере PCP.

Если сервер PCP сбрасывает или теряет состояние для явного динамического отображения (т. е., отображения, созданного по запросу PCP) в результате перезагрузки, сбоя по питанию или по иной причине, он должен сбросить свое значение Epoch Time к первоначальному (обычно 0), чтобы обеспечить подсказку своим клиентам PCP. После сброса параметра Epoch Time сервер PCP продолжает инкрементировать это значение каждую секунду.

Аналогично, при смене внешнего адреса IP на устройстве NAT (контролируемом сервером PCP) значение поля Epoch Time должно быть сброшено. Сервер PCP может поддерживать одно значение Epoch для всех клиентов PCP, а может установить разные значения Epoch Time (например, по клиентам, интерфейсам или иным критериям); решение этого вопроса отдано разработчикам.

При получении отклика PCP клиент проверяет значение в соответствии с описанной ниже процедурой, используя целочисленную арифметику.

Если это первый отклик, полученный клиентом PCP от данного сервера PCP, значение Epoch Time трактуется, как обязательно корректное. В остальных случаях:
- Если значение Epoch Time для текущего сервера PCP (curr_server_time) меньше предыдущего значения Epoch Time (prev_server_time) более, чем на 1 секунду, клиент трактует значение Epoch Time, как явно некорректное (время не может уменьшаться). Разница значений Epoch Time не более 1 секунды, считается допустимой, и такое незначительное нарушение порядка доставки на пути между сервером и клиентом PCP не вызовет каскада ненужных обновлений отображений. Если значение Epoch Time проходит описанную проверку, выполняются следующие операции:
  - Клиент вычисляет разницу между локальным текущим временем (curr_client_time) и временем получения предыдущего отклика от данного сервера PCP (prev_client_time):
```
            client_delta = curr_client_time - prev_client_time;
```
  - Клиент вычисляет разницу между текущим значением Epoch Time сервера PCP (curr_server_time) и предшествующим значением Epoch Time (prev_server_time):
```
            server_delta = curr_server_time - prev_server_time;
```
  - Если client_delta+2 < server_delta — server_delta/16 or server_delta+2 < client_delta — client_delta/16, клиент считает значение Epoch Time недопустимым.
Клиент сохраняет значение текущего времени для использования в будущих сравнениях:
```
prev_client_time = curr_client_time
prev_server_time = curr_server_time
```

Если клиент PCP счел полученное значение Epoch Time недопустимым, он предполагает, что сервер PCP мог потерять состояние и быстро обновляет все свои активные отображения в соответствии с процедурой, описанной в параграфе 16.3.1.

Примечания.

Время на часах клиента должно монотонно возрастать. Если curr_client_time < prev_client_time, это говорит о наличии ошибки на стороне клиента. Обработка таких ошибок зависит от реализации клиента.
Приведенные выше расчеты позволят определять значения client_delta и server_delta, как целые числа.
«+2» в приведенном выше расчете служит для компенсации возможных погрешностей квантования у клиента и сервера (возможна погрешность до 1 секунды на каждой из сторон).
Деление на 16 (/16) в приведенном выше расчете служит для компенсации погрешностей часов в дешевых устройствах. Это позволяет компенсировать расхождение в 1/16 (6,25%) рассматривать, как погрешность (например, если на одной стороне часы спешат на 3%, а на другой отстают на 3%), не считая его аномалией или свидетельством перезапуска. Это допущение достаточно строго для того, чтобы перезагрузки эффективно детектировались и достаточно мягко, чтобы не возникало ложных срабатываний.

9 Согласование версий

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

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

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

Клиент отправляет первый запрос с указанием наибольшего (т. е., лучшего) поддерживаемого номера версии.
Если сервер поддерживает эту версию, он возвращает обычный отклик.
Если сервер не поддерживает указанную клиентом версию, он генерирует отклик с кодом результата UNSUPP_VERSION и указывает в нем ближайший поддерживаемый номер версии (если сервер поддерживает версии с номером больше указанного клиентом, он возвращает наименьший из поддерживаемых номеров, если же номера поддерживаемых сервером версий меньше указанного клиентом, он возвращает наибольший из поддерживаемых номеров).
Если клиент получает отклик с кодом UNSUPP_VERSION и поддерживаемым им номером версии, он записывает этот факт для использования указанного номера при последующих контактах с данным сервером PCP (пока от этого сервера вновь не будет получен отклик UNSUPP_VERSION в результате его обновления). Если в отклике UNSUPP_VERSION указан номер версии 0, это означает, что сервер NAT-PMP [RFC6886] и клиент могут взаимодействовать по устаревшему протоколу NAT-PMP, как описано в Приложении A.
Если клиент получает отклик с кодом UNSUPP_VERSION и неподдерживаемым им номером версии, клиенту следует перейти к использованию ближайшего меньшего номера версии из числа поддерживаемых и повторить запрос. Попытки снижения номера версии могут повторяться до тех пор, пока не будет достигнут номер 2. Если попытка использования версии 2 завершилась отказом, клиент может сгенерировать для пользователя сообщение о невозможности работы с данным сервером. Клиенту также следует установить для таймера повтора меньшее из значение 30 минут или возвращенное сервером значение Lifetime. Автоматический повтор через 30 служит для ситуаций, когда согласовать версии не удается по причине происходящего обновления сервера PCP.

10 Операции MAP и PEER

В данном документе определены четыре случая использования операций с кодами MAP и PEER:

хост-сервер, желающий принимать входящие соединения (параграф 10.1);
хост, использующий один порт в качестве клиента и сервера (параграф 10.2);
хост-клиент, желающий оптимизировать пользовательский трафик keepalive (параграф 10.3);
хост-клиент, желающий восстановить утраченное состояние в NAT (параграф 10.4).

Эти варианты описаны ниже и показаны на (ненормативной) диаграмме состояний в параграфе 16.5.

При работе в качестве сервера (см. параграфы 10.1 и 10.2) клиент PCP знает, какие адреса он будет прослушивать из Internet — IPv4, IPv6 или оба типа. Клиент PCP также знает о наличии адресов IPv4 и IPv6 на своих интерфейсах. На основе этой информации клиент принимает решение о выборе серверов PCP для отправки запросов (например, запрос адреса IPv4 или IPv6) и числе (1 или 2) запросов MAP для каждого из своих интерфейсов (например, если клиент PCP имеет только адрес IPv4, но хочет прослушивать IPv6 и IPv4, он отправляет запрос MAP, содержащий адрес IPv6 «все нули» в поле Suggested External Address, и запрос MAP с адресом IPv4 «все нули» в поле Suggested External Address). Если клиент PCP имеет адреса IPv4 и IPv6, но хочет прослушивать лишь IPv4, он отправляет один запрос MAP со своего адреса IPv4 (если сервер PCP поддерживает NAT44 или IPv4 МСЭ) или один запрос MAP со своего адреса IPv6 (если сервер PCP поддерживает NAT64). Клиент PCP может просто запросить желаемое отображение для того, чтобы определить поддерживает ли сервер PCP это отображение. Это будут полезно для приложений, которые включают адреса IP в поля данных (например, FTP или SIP), поскольку позволяет избавиться от трансляции адресов между разными семействами.

Запросы MAP и PEER включают поле Suggested External IP Address. Некоторые устройства, контролируемые PCP, в частности, CGN, а также многодомные сети NPTv6 имеют пул публично-доступных адресов IP. PCP позволяет клиенту указать, нужно ли ему отображение на конкретный или любой из адресов данного пула. У некоторых приложений (например, FTP в активном режиме) могут возникать проблемы при создании отображений на другой адрес IP, поэтому таким приложениям следует принимать во внимание последствия использования такой возможности. Для такого внутреннего адреса могут существовать статические отображения (например, созданные командой на сервере PCP или управляемом PCP устройстве) на некие внешние адреса и, если предложен внешний адрес «все нули» IPv4 или IPv6, PCP следует организовать отображение на тот же адрес, поскольку это позволит приложению использовать комбинацию статических и созданных PCP отображений. С другой стороны, если предложен ненулевой адрес IP, серверу PCP следует организовать отображение на этот внешний адрес даже если для других отображений с того же внутреннего адреса используются иные внешние адреса. Когда для внутреннего адреса нет неявного или явного динамического отображения в управляемом PCP устройстве, для последующего явного или неявного отображения данного адреса может использоваться другой внешний адрес. Как правило, переназначение будет происходить в тех случаях, когда устройство CGN с балансировкой нагрузки вновь увидит эти внутренние адреса для своего пула внешних адресов.

В приведенной ниже таблице показано использование адресов IPv6 и IPv4 в типовых реализациях PCP.

Внутренний адрес «неявно» совпадает с IP-адресом отправителя запроса PCP за исключением случаев использования опции THIRD_PARTY.

Внешний адрес указывается в поле Suggested External Address запросов MAP и PEER, а семейство, к которому он относится, обычно совпадает с семейством внутреннего адреса, за исключением случаев использования технологий типа NAT64.

Адресом удаленного партнера PCP является IP-адрес удаленного партнера в запросе PEER или опции FILTER запроса MAP и всегда относится к тому же семейству, что и внутренний адрес (даже при использовании NAT64). В NAT64 клиент IPv6 PCP может быть не осведомлен о NAT64 или реальном адресе удаленного партнера IPv4, поэтому он выражает адрес IPv6 со своей точки зрения, как показано на рисунке 5.

	Внутрен. адрес	Внешний адрес	Адрес удаленного партнера PCP	Реальный адрес удаленного партнера
IPv4 МСЭ	IPv4	IPv4	IPv4	IPv4
IPv6 МСЭ	IPv6	IPv6	IPv6	IPv6
NAT44	IPv4	IPv4	IPv4	IPv4
NAT46	IPv4	IPv6	IPv4	IPv6
NAT64	IPv6	IPv4	IPv6	IPv4
NPTv6	IPv6	IPv6	IPv6	IPv6

Рисунок 5. Семейства адресов в MAP и PEER.

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

10.1 Для сервера

Хост-сервер (например, сервер web) прослушивает трафик на определенном порту, но никогда не инициирует трафик через этот порт. Для работы через NAT или МСЭ хосту нужно (a) организовать динамическое отображение с публичного адреса IP, протокола и порта на самого себя, используя операцию MAP, как описано в параграфе 11, (b) опубликовать адрес IP, протокол и номер порта через тот или иной рандеву-сервер (например, DNS, сообщение SIP или фирменный протокол) и (c) обеспечить отсутствие препятствий в передаче трафика со стороны промежуточных устройств, не поддерживающих PCP (например, МСЭ или NAT). Публикация адреса IP и номера порта выходит за рамки данной спецификации. Для выполнения п. (a) хост должен следовать инструкциям данного параграфа.

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

Приведенный ниже псевдокод показывает применение PCP для организации доступа к серверу.

    /* запуск прослушивания локального порта на сервере */
    int s = socket(...);
    bind(s, ...);
    listen(s, ...);
    getsockname(s, &internal_sockaddr, ...);
    bzero(&external_sockaddr, sizeof(external_sockaddr));
    while (1)
        {
        /* Примечание. Проверка time_to_send_pcp_request() включает:
         * 1. Передачу первого запроса.
         * 2. Повтор запроса в результате потери пакета.
         * 3. Повтор запроса в связи с завершением срока аренды.
         * 4. Повтор запроса по причине потери состояния на сервере.
         * Во всех 4 случаях передаются идентичные пакеты PCP и с точки 
         * зрения сервера PCP это будет одной операцией.
         * Предлагаемые внешний адрес и порт могут изменяться в течение
         * срока существования отображения. Остальные поля сохраняются
         * неизменными.
         */
        if (time_to_send_pcp_request())
            pcp_send_map_request(internal_sockaddr.sin_port,
                internal_sockaddr.sin_addr,
                &external_sockaddr, /* 0 для первого раза */
                requested_lifetime, &assigned_lifetime);
        if (pcp_response_received())
            update_rendezvous_server("Client Ident", external_sockaddr);
        if (received_incoming_connection_or_packet())
            process_it(s);
        if (other_work_to_do())
            do_it();
        /* ... */
        block_until_we_need_to_do_something_else();
        }

Рисунок 6. Псевдокод использования PCP для работы сервера.

10.2 Для сервера-клиента

Хост, использующий один порт для работы в качестве клиента и сервера (например, Symmetric RTP [RFC4961] или SIP rport¹⁸ [RFC3581]), организует локальное прослушивание порта, (обычно) передает локальный и публичный адрес IP, протокол и порт службе «рандеву» (выходит за рамки данного документа) и инициирует исходящее соединение с указанного адреса и порта. Для решения этой задачи хост должен следовать описанным ниже процедурам.

Приложение, которое использует один и тот же порт для входящих и исходящих соединений, должно сначала обозначить свою работу в качестве сервера, используя операцию MAP, как описано в разделе 11, и получить позитивный отклик PCP до начала передачи каких-либо пакетов через этот порт.

Обсуждение. В общем случае клиент PCP заранее не знает, что он находится за устройством NAT или МСЭ. При обнаружении подключения к сети клиент PCP может попытаться запросить отображение с помощью PCP. В случае успеха клиент будет знать отображение адресов. Если после нескольких попыток отклик не будет получен, возможны два варианта — клиент не находится за устройством NAT/МСЭ или это устройство не поддерживает PCP (подключение клиента может сохраняться на основе созданного пользователем вручную отображения). Повтор запросов PCP перед принятием решения в таких случаях увеличивает задержку. Инициирование исходящего соединения TCP без ожидания PCP позволяет избавиться от этой задержки и будет работать, если поведение устройства NAT не зависит от конечной точки (EIM¹⁹), но может приводить к отказу, если отображение NAT зависит от конечной точки (EDM²⁰). Достаточно долгое ожидание, позволяющее создать явное отображение PCP MAP (если оно возможно) обеспечивает использование того же внешнего порта для всех последующих неявных динамических отображений (например, TCP SYN) для указанного внутреннего адреса, протокола и порта. PCP поддерживает устройства NAT как EIM, так и EDM, поэтому клиенты могут предполагать работу с EDM NAT. В этом случае организация соединения для клиента будет более гарантированной, если он попытается использовать запросы PCP MAP до попытки организации исходящих соединений TCP для данного адреса и порта. Дополнительная информация об использовании PCP с устройствами EDM NAT приведена в параграфе 16.1.

Приведенный ниже псевдокод показывает использование PCP для работы в режиме сервера и клиента.

    /* запуск прослушивания локального порта на сервере */
    int s = socket(...);
    bind(s, ...);
    listen(s, ...);
    getsockname(s, &internal_sockaddr, ...);
    bzero(&external_sockaddr, sizeof(external_sockaddr));
    while (1)
        {
        /* Примечание. Проверка time_to_send_pcp_request() включает:
         * 1. Передачу первого запроса.
         * 2. Повтор запроса в результате потери пакета.
         * 3. Повтор запроса в связи с завершением срока аренды.
         * 4. Повтор запроса по причине потери состояния на сервере.
         */
        if (time_to_send_pcp_request())
            pcp_send_map_request(internal_sockaddr.sin_port,
                internal_sockaddr.sin_addr,
                &external_sockaddr, /* 0 для первого раза */
                requested_lifetime, &assigned_lifetime);
        if (pcp_response_received())
            update_rendezvous_server("Client Ident", external_sockaddr);
        if (received_incoming_connection_or_packet())
            process_it(s);
        if (need_to_make_outgoing_connection())
            make_outgoing_connection(s, ...);
        if (data_to_send())
            send_it(s);
        if (other_work_to_do())
            do_it();
        /* ... */
        block_until_we_need_to_do_something_else();
        }

Рисунок 7. Псевдокод использования PCP для работы в режиме клиента и сервера.

10.3 Снижение вспомогательного трафика

Хост-клиент (например, XMPP, SIP) передает передает пакеты в порт и может получать на них отклики, но никогда не воспринимает на этом порту входящих соединений от других удаленных партнеров. Такому хосту требуется предотвращать прерывание потока данных между ним и удаленным партнером (в результате отсутствия активности) через устройство NAT или МСЭ. Для решения этой задачи приложения используют описанную здесь процедуру.

Промежуточным устройствам (NAT или МСЭ) в общем случае нужно видеть тот или иной трафик, иначе они будут разрывать сессии (удалять состояние) и это приведет к отказу приложения. Для предотвращения этого многие приложения генерируют вспомогательный трафик keepalive (сохранение жизненности) с основной (или единственной) целью — сохранить состояние на промежуточном устройстве. Такие приложения могут снизить объем трафика keepalive, используя PCP.

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

Для использования PCP с целью снижения уровня вспомогательного трафика приложение сначала обычным способом соединяется с сервером. После этого приложение генерирует запрос PCP с кодом операции PEER (см. раздел 12) для определения срока жизни созданного отображения.

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

    /* организация исходящего соединения с сервером */
    int s = socket(...);
    connect(s, &remote_peer, ...);
    getsockname(s, &internal_sockaddr, ...);
    bzero(&external_sockaddr, sizeof(external_sockaddr));
    while (1)
        {
        /* Примечание. Проверка time_to_send_pcp_request() включает:
         * 1. Передачу первого запроса.
         * 2. Повтор запроса в результате потери пакета.
         * 3. Повтор запроса в связи с завершением срока аренды.
         * 4. Повтор запроса по причине потери состояния на сервере.
         */
        if (time_to_send_pcp_request())
            pcp_send_peer_request(internal_sockaddr.sin_port,
                internal_sockaddr.sin_addr,
                &external_sockaddr, /* 0 для первого раза */
                remote_peer, requested_lifetime, &assigned_lifetime);
        if (data_to_send())
            send_it(s);
        if (received_incoming_data())
            process_it(s);
        if (other_work_to_do())
            do_it();
        /* ... */
        block_until_we_need_to_do_something_else();
        }

Рисунок 8. Псевдокод использования PCP с динамическим сокетом.

10.4 Восстановление утраченного состояния для неявного отображения TCP

После потери состояния NAT (например, в результате ошибки или отказа питания) клиентам полезно восстанавливать отображения TCP в устройстве NAT. Это позволяет серверам Internet видеть трафик клиента с тем же адресом IP и портом, что позволяет восстановить сессию в точке обрыва. Это может оказаться полезным для долгоживущих соединений (например, чат-системы) или соединений с большим объемом данных (например, FTP). Этого можно достигнуть путем обычной организации соединения TCP с последующей передачей запросов/откликов PEER и запоминанием внешнего адреса и порта. Позднее при потере состояния NAT клиент может передать запрос PEER с сохраненными для предыдущей сессии адресом и номером порта, что позволит создать в NAT отображение, соответствующее неявному динамическому отображению. После этого клиент может продолжить сессию TCP с сервером.

Примечание. Эта процедура хорошо работает для TCP, если:

NAT создает новое неявное динамическое исходящее отображение только для исходящих сегментов TCP с установленным битом SYN (т. е., перезагруженное устройство NAT без уведомления отбросит исходящие сегменты, если в NAT нет активного отображения для них;
перезагруженное устройство NAT не передает сегментов TCP RST в ответ на получение неожиданных входящих сегментов TCP.

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

11 Операция MAP

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

MAP:

Создает явное динамическое отображение между внутренними и внешними парами (адрес + порт).

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

Отображения, создаваемые запросами PCP MAP, по определению не зависят от конечных точек (EIM), включая независимость фильтрации от конечной точки (EIF²¹) (пока не используется опция FILTER), даже на устройствах NAT, которые обычно создают зависимые от конечной точки отображения (EDM) или фильтры (EDF²²) для исходящих соединений, поскольку целью отображения MAP (без фильтров) является получение входящего трафика от любой удаленной точки, а не только от указанной конкретно.

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

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

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

Обработка операций с кодом MAP описана ниже.

11.1 Формат пакетов MAP

Пакеты запросов и откликов MAP имеют похожую структуру. Если выделенные внешний адрес IP и порт в отклике PCP всегда совпадают с внутренним адресом IP и портом в запросе PCP, в устройстве реализована только функциональность МСЭ, в противном случае устройство является транслятором адресов (NAT) и может также реализовать функции МСЭ.

На рисунке 9 показан формат специфических для операции данных в запросе MAP.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 битов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 бита)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Suggested External Port    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           Suggested External IP Address (128 битов)           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Запрос MAP.

Requested lifetime (в обычном заголовке) — запрошенное время жизни

Запрошенное время жизни отображения в секундах. Значение 0 служит для удаления отображения.

Mapping Nonce

Случайное значение, выбранное клиентом PCP (см. параграф 11.2 Генерация запроса MAP). Это поле может иметь нулевое значение (появление такого значения маловероятно — 1 раз примерно на 2⁹⁶ запросов).

Protocol — протокол

Протокол вышележащего уровня, связанный с данным Opcode. Значения поля берутся из реестра протоколов IANA [proto_numbers]. Например, поле будет содержать значение 6 (TCP), если операция предназначена для создания отображения TCP или 17 (UDP), если создается отображение UDP. Значение 0 означает «все протоколы».

Reserved — резерв

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

Internal Port — внутренний порт

Номер внутреннего порта для отображения. Значение 0 указывает «все порты» и допустимо для запросов с нулевым временем жизни (удалить отображение), если протокол не использует 16-битовых номеров портов или клиент запрашивает «все порты». Если для протокола указано значение 0 (все протоколы), номер внутреннего порта должен иметь нулевое значение при передаче и должен игнорироваться на приемной стороне.

Suggested External Port предложенный внешний порт

Предлагаемый для отображения внешний порт. Это полезно при обновлении отображений, особенно в случае потери состояния на сервере PCP. Если клиент не знает внешний порт или не имеет предпочтений, он должен указать 0.

Suggested External IP Address — предложенный внешний адрес

Предлагаемый внешний адрес IPv4 или IPv6. Это полезно при обновлении отображений, особенно в случае потери состояния на сервере PCP. Если клиент не знает внешний адрес или не имеет предпочтений, он должен указать адрес «все нули» для соответствующего семейства (см. раздел 5).

Внутренним адресом для запроса является IP-адрес отправителя запроса PCP, если не используется опция THIRD_PARTY.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 битов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 бита)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Assigned External Port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            Assigned External IP Address (128 битов)           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Отклик MAP.

На рисунке 10 показан формат специфических для операции данных в отклике MAP.

Lifetime (в обычном заголовке):

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

Mapping Nonce

Копируется из запроса.

Protocol — протокол

Копируется из запроса.

Reserved — резерв

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

Internal Port — внутренний порт

Копируется из запроса.

Assigned External Port — выделенный внешний порт

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

Assigned External IP Address — выделенный внешний адрес

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

11.2 Генерация запроса MAP

В этом параграфе описаны действия клиента PCP при передаче запросов с кодом MAP.

Запрос может содержать значения в полях Suggested External Port и Suggested External IP Address. Это позволяет клиенту PCP попытаться заново организовать потерянное состояние на сервере PCP, что повышает шансы сохранения существовавших соединений и позволяет клиенту PCP избавиться от необходимости изменения данных, поддерживаемых им на сервере rendezvous. Действия других элементов сети (например, запросы других пользователей или смена адресов в сети) могут воспрепятствовать предоставлению сервером PCP запрошенного внешнего адреса IP, протокола и порта. В таких случаях сервер будет выделять другой внешний адрес IP и порт.

Клиент PCP должен записать полученные данные, поскольку он может никогда не получить запрошенный внешний порт. В случае восстановления состояния после перезапуска шлюза NAT, предлагая полученный ранее внешний порт, клиент с большей вероятностью сможет получить его для продолжения использования. В остальных случаях клиент должен предполагать, что вероятность выделения ему запрошенного внешнего порта достаточно мала. Например, если множество абонентов пользуются общим шлюзом CGN, популярные порты 80, 443, 8080 будут пользоваться высоким спросом. Каждый из таких портов для каждого из внешних адресов IP может быть предоставлен только одному клиенту, а остальные получат динамически распределяемые внешние порты. На практике некоторые ISP могут (в соответствии со своей политикой) не предоставлять такие внешние порты ни одному из своих абонентов.

Если протокол не использует 16-битовых номеров портов (например, RSVP, протокол IP 46), для номера порта должно указываться значение 0. Это обеспечит отображение для всего трафика данного протокола.

Если клиент хочет получить отображение для всех протоколов, он использует протокол 0 и внутренний порт 0.

Значение Mapping Nonce клиент PCP выбирает случайным образом, следуя принятой политике генерации непредсказуемых случайных чисел [RFC4086], и использует это значение для проверки откликов PCP (см. ниже), а также обновленных отображений от сервера PCP. Клиент должен использовать разные значения Mapping Nonce для каждого сервера PCP, с которым он взаимодействует, рекомендуется также выбирать новое случайное значение Mapping Nonce при каждой инициализации клиента PCP. Клиент может использовать разные значения Mapping Nonce для каждого отображения.

11.2.1 Обновление отображения

Срок жизни существующего отображение клиенту PCP следует продлять, если потребность в отображении сохраняется. Для продления срока клиент PCP отправляет новый запрос MAP, указывающий внутренний порт. В запрос PCP MAP следует также включать текущий присвоенный внешний адрес IP и номер порта в полях Suggested External IP Address и Suggested External Port, чтобы в случае потери состояния сервер PCP мог восстановить утраченное отображение с теми же параметрами.

Клиенту PCP следует обновлять отображение до завершения его срока жизни, иначе оно будет удалено сервером PCP (см. раздел 15 Срок действия и удаление отображений). Для снижения риска случайной синхронизации запросов на обновление следует включать флуктуацию (jitter) со случайным значением. Клиентам PCP рекомендуется передавать один пакет с запросом обновления в момент времени определяемый случайно выбранным значением из диапазона от 1/2 до 5/8 срока действия отображения. Если отклик SUCCESS на этот запрос не был получен, следующий запрос передается в интервале от 3/4 до 3/4 + 1/16, потом в интервале от 7/8 до 7/8 + 1/32 и т. д., с учетом того что интервал между запросами менее 4 секунд недопустим (клиентам PCP недопустимо передавать «лавину» часто повторяющихся запросов в течение последних нескольких секунд срока действия отображения).

11.3 Обработка запроса MAP

В этом параграфе описаны действия сервера PCP при обработке запроса с кодом операции MAP. Обработку следует выполнять в описанном ниже порядке.

Значения полей Protocol, Internal Port и Mapping Nonce из запроса MAP копируются в отклик MAP. Если опция THIRD_PARTY присутствует в запросе и обрабатывается сервером PCP, она тоже копируется в отклик MAP.

Если запрашиваемое время жизни отлично от нуля выполняются перечисленные ниже действия.

Если значение полей протокола и внутреннего порта отличны от 0, это указывает на запрос для создания отображения или продления срока действия существующего отображения. Если сервер PCP или управляемое PCP устройство не поддерживает протокол, должен возвращаться код ошибки UNSUPP_PROTOCOL.
Если значение поля протокола отлично от нуля, а внутренний порт равен 0, это указывает запрос на создание или продление срока действия отображения для всего входящего трафика указанного протокола. Если запрос не может быть выполнен полностью, должна возвращаться ошибка UNSUPP_PROTOCOL.
Если поля протокола и внутреннего порта имеют значение 0, это указывает запрос на создание или продление срока действия отображения для всего входящего трафика любых протоколов (DMZ-хост). Если запрос не может быть выполнен полностью, должна возвращаться ошибка UNSUPP_PROTOCOL.
Если поле протокола имеет значение0, а внутренний порт отличен от нуля, запрос является недопустимым и сервер PCP должен возвратить клиенту отклик с кодом ошибки MALFORMED_REQUEST.

Если запрошенное время жизни равно 0, это указывает запрос на удаление существующего отображения.

Дальнейшая обработка значений времени жизни описана в разделе 15 Срок действия и удаление отображений.

При работе в рамках простой модели угроз (Simple Threat Model — параграф 18.1), если внутренний порт, протокол и адрес соответствуют имеющемуся явному динамическому отображению, но Mapping Nonce не соответствует, запрос должен отбрасываться с кодом ошибки NOT_AUTHORIZED и указанием в поле lifetime срока жизни существующего отображения. Серверу PCP требуется помнить лишь одно значение Mapping Nonce для каждого явного динамического отображения. В данной спецификации не задается требований к Mapping Nonce для расширенной модели угроз.

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

Если имеется опция со значением меньше 128 (т. е, обязательная для обработки), но эта опция не имеет смысла (например, PREFER_FAILURE в запросе с lifetime=0), запрос считается недопустимым и возвращается ошибка MALFORMED_OPTION

Если управляемое PCP устройство не поддерживает информации о состоянии (т. е., не организует состояний для потоков или просто меняет адрес и/или порт по заданному алгоритму, включая отсутствие изменений), сервер PCP просто отвечает индикацией внешнего адреса IP и порта, выделенного алгоритмической трансляцией без поддержки состояния. Это позволяет клиенту PCP узнать свой внешний адрес IP и порт, которые видят удаленные партнеры. Примерами трансляторов без поддержки состояний могут служить NAT64, 1:1 NAT44, NPTv6 [RFC6296], которые меняют адреса, не меняя номеров портов, а также МСЭ, которые не меняют ни адресов, ни портов.

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

Если запрос MAP включает опцию PREFER_FAILURE, а предложенные внешний адрес и порт не соответствуют существующим отображениям, сервер PCP должен возвращать CANNOT_PROVIDE_EXTERNAL.
Если существующее отображение является статическим (создано без участия PCP), сервер PCP должен возвращать в отклике адрес и порт существующего отображения, следует также указывать время жизни 2³²-1, независимо от предложенных в запросе внешнего адреса и порта.
Если существующее отображение является явным динамическим (создано предшествующим запросом MAP), сервер PCP должен возвращать в отклике внешний адрес и порт из этого отображения, независимо от предложенного в запросе внешнего адреса и порта. Кроме того, сервер PCP должен обновить время жизни существующего отображения в соответствии с разделом 15 Срок действия и удаление отображений.
Если существующее отображение является динамическим исходящим (создано исходящим трафиком или предшествующим запросом PEER), серверу PCP следует создать новое явное входное отображение, реплицируя порт и адрес из существующего исходящего отображения (это отображение сохраняется и продолжает существовать даже после удаления явного входного отображения).

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

предложенные внешний адрес, протокол и порт уже выделены для явного или неявного отображения (т.е., уже используются для пересылки трафика на некоторый внутренний адрес и порт;
предложенный внешний адрес, протокол и порт уже используются шлюзом NAT для своих целей (например, порт TCP 80 для web-интерфейса управления шлюзом NAT или порты UDP 5350 и 5351 для протокола PCP); серверам PCP недопустимо создавать отображения для своих внешних портов UDP 5350 и 5351;
предложенный внешний адрес, протокол и порт запрещены для использования политикой сервера PCP;
предложенный внешний адрес, протокол и порт являются недопустимыми или образуют недопустимую комбинацию (например, внешний адрес 127.0.0.1, ::1, групповой адрес или недопустимый для протокола порт);
предложенный внешний адрес не принадлежит шлюзу NAT;
предложенный внешний адрес не предназначен для использования в качестве внешнего адреса шлюза NAT или МСЭ.

Если сервер PCP не может выделить предложенный адрес, протокол и порт:

Для запросов с опцией PREFER_FAILURE сервер PCP должен возвращать CANNOT_PROVIDE_EXTERNAL.
Если запрос включает опции PREFER_FAILURE и сервер PCP может выделить некий другой внешний адрес и порт для заданного протокола, сервер должен выделить эти значения и возвратить их клиенту в отклике. Ни при каких условиях клиент не наказывается за «неверный» выбор предложенного внешнего адреса и порта. Предлагаемые клиентом адрес и порт помогают серверу при выборе присваиваемых для клиента значений, но ни при каких обстоятельствах не являются препятствием для выделения отличных от предложенных внешнего адреса и порта. Присутствие в запросе отличных от нуля значений предлагаемого внешнего адреса и порта служат лишь намеком серверу и не могут наносить какого-либо вреда.

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

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

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

11.4 Обработка отклика MAP

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

После выполнения обычной обработки PCP отклик сравнивается с переданным ранее запросом MAP на предмет соответствия внутреннего адреса IP (адрес получателя в отклике PCP или иной адрес, заданный через опцию THIRD_PARTY), протокола, внутреннего порта и nonce. Остальные поля не сравниваются, поскольку их значения задает сервер PCP. При изменении отображения (например, в результат смены адресов IP) сервер PCP будет передавать Mapping Update (параграф 14.2).

Если код результата имеет значение NO_RESOURCES, а запрос был передан для создания или обновления отображения, клиенту PCP не следует передавать новых запросов на отображения в течение указанного сервером PCP (ограниченного) срока (lifetime). Если код результата имеет значение NO_RESOURCES и запрашивалось удаление отображения, клиенту PCP не следует передавать каких-либо запросов данному серверу PCP в течение указанного сервером PCP (ограниченного) срока (lifetime).

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

После получения отклика о создании отображения (success) до того момента клиент PCP должен организовать таймер или иной способ уведомления о необходимости обновить отображение до завершения срока его действия. Обновление отображений выполняется путем передачи запроса MAP, как описано в параграфе 11.2, но в качестве предлагаемого внешнего адреса и порта следует указывать значения, полученные в отклике для действующего отображения. С точки зрения сервера PCP запрос MAP на обновление идентичен MAP-запросу на организацию отображения и обрабатывается так же. Действительно, при потере сервером состояния запрос клиента PCP на обновление отображения будет восприниматься сервером, как запрос на создание нового отображения, с предложенным внешним адресом и портом (которые сервер PCP выделил этому клиенту до потери состояния). Дополнительная информацию по части обновлений приведена в параграфе 16.3.1 Повторная организация отображений.

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

11.5 Изменение адреса

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

Когда внутренний хост меняет свой внутренний адрес IP (например, получает другой адрес от сервера DHCP), устройство NAT (или МСЭ) будет продолжать передачу пакетов по старому адресу. Обычно в таких случаях хост не получает такой трафик. Если хост хочет по-прежнему получать этот трафик, он должен организовать новое отображение для своего нового адреса IP. По всей вероятности прежнее значение Suggested External Port не будет принято сервером PCP, поскольку он продолжает передавать пакеты по старому адресу IP. Таким образом для нового отображения будет скорей всего выделен другой внешний порт и/или адрес IP. Отметим, что такая смена адресов не предполагается частой, поскольку большинство хостов будет продлять аренду DHCP (или запрашивать тот же адрес после перезагрузки) и большинство серверов DHCP смогут обеспечить хосту использованный ранее адрес.

На хосте могут добавляться или удаляться интерфейсы во время действия отображений (например, подключение или отключение кабеля Ethernet, подключение или отключение сети WiFi). В силу этого, если клиент PCP передает запрос PCP для поддержки состояния на сервере PCP, ему следует обеспечивает привязку запросов PCP к тому же интерфейсу (например, при обновлении отображения). Если клиент PCP передает запрос PCP для создания нового отображения на сервере PCP, он может использовать другой интерфейс-источник или иной адрес отправителя.

11.6 Самостоятельное определение внешнего адреса IP

NAT-PMP [RFC6886] включает механизм, который позволяет клиентам самостоятельно определить внешний адрес IP без запроса отображения. Протокол NAT-PMP был разработан для домашних шлюзов NAT, где такая операция имеет смысл, поскольку домашний шлюз NAT имеет лишь один внешний адрес IP. Сфера применения PCP шире и включает также устройства CGN, у которых может быть множество внешних адресов IP. Клиенту не может быть выделено ни одного внешнего адреса IP из такого пула, пока он не организует хотя бы одно (неявное, явное или статическое) отображение (и в этом случае адрес будет доступен лишь в течение срока действия отображения). Клиентское приложение, которое просто хочет показать пользователю внешний адрес IP (в косметических целях), может просто запросить кратковременное отображение (например для службы Discard — TCP/9 или UDP/9 или другого порта) и вывести для пользователя полученный внешний адрес IP. Однако по завершении срока действия такого отображения любое последующее отображение (явное или неявное) может дать другой внешний адрес IP.

12 Операция PEER

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

PEER

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

Использование операции описано в данном разделе.

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

Поскольку отображения, создаваемые и поддерживаемые операцией PEER, ведут себя практически так же, как исходящие неявные динамические отображения, создаваемые по исходящим от хостов пакетам (например, TCP SYN), отображения PCP PEER могут быть независимыми (EIM) или зависимыми (EDM) от конечной точки с независимой (EIF) или зависимой (EDF) от конечной точки фильтрацией, в соответствии с поведением шлюза NAT или МСЭ по отношению к неявным исходящим отображениям, которые создаются по факту получения исходящего трафика от внутренних хостов.

12.1 Форматы пакетов PEER

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

На рисунке показана структура пакетов операции PEER. Формат запросов и откликов PEER организован так, чтобы связанные логически поля имели одинаковое положение в пакетах.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 битов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 бита)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Suggested External Port    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           Suggested External IP Address (128 битов)           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Remote Peer Port        |     Reserved (16 битов)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Remote Peer IP Address (128 битов)              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Запрос PEER.

Requested Lifetime (в общем заголовке) — срок действия

Запрашиваемое время действия отображения в секундах. Отметим, что с помощью запросов PEER невозможно сократить срок действия отображения (или удалить его с помощью lifetime=0).

Mapping Nonce — случайный идентификатор отображения

Случайное значение, выбираемое клиентом (см. параграф 12.2 Генерация запроса PEER). Допустимо использование значения 0 (вероятность его появления составляет примерно 2^-96).

Protocol — протокол

Протокол вышележащего уровня, связанный с этой операцией. Значения поля берутся из реестра протоколов IANA [proto_numbers]. Например, это поле будет содержать значение 6 (TCP), если операция связана с отображением для протокола TCP или 17 (UDP), если операция связана с отображением для UDP. Недопустимо использовать значение 0.

Reserved — резерв

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

Internal Port — внутренний порт

Внутренний порт для отображения (нулевое значение недопустимо).

Suggested External Port — предлагаемый внешний порт

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

Suggested External IP Address — предлагаемый внешний адрес

Предлагаемый для отображения внешний адрес IP. Если клиент PCP не знает внешнего адреса или этот адрес не имеет значения, он должен использовать адрес «все нули», соответствующего семейства (см. раздел 5).

Remote Peer Port — порт удаленного партнера

Порт удаленного партнера для данного отображения (значение 0 недопустимо).

Reserved — резерв

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

Remote Peer IP Address — адрес удаленного партнера

IP-адрес удаленного партнера с точки зрения клиента PCP. Это позволяет клиенту PCP не задумываться о наличии на пути преобразований NAT64 или NAT46, которые приводят к тому, что представляемый клиентом адрес IP отличается от реального IP-адреса удаленного хоста. Это поле позволяет избавиться от неоднозначностей, связанных с наличием множества соединений с одного порта внутреннего хоста с разными серверами. Адреса IPv6 в этом поле представляются напрямую, а адреса IPv4 с использованием синтаксиса IPv4-mapped (раздел 5).

При попытке восстановления утраченного отображения в качестве предлагаемых внешнего адреса и порта устанавливаются значения External IP Address и Port, полученные в предшествующем отклике PEER от сервера PCP. В первоначальном запросе PEER для внешнего адреса IP и порта устанавливаются значения 0.

Отметим, что для запросов PEER автоматически предполагается семантика, похожая на семантику опции PREFER_FAILURE. Если поле Suggested External IP Address или Suggested External Port отлично от нуля, а сервер PCP не может выделить предложенный внешний адрес IP, протокол или порт, сервер должен возвратить отклик об ошибке CANNOT_PROVIDE_EXTERNAL. Опция PREFER_FAILURE не нужна и не разрешена в запросах PEER и, если сервер PCP получает запрос PEER с опцией PREFER_FAILURE, он должен возвратить отклик MALFORMED_REQUEST.

На рисунке показана структура поле отклика PEER.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Mapping Nonce (96 битов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved (24 бита)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Internal Port          |    Assigned External Port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|            Assigned External IP Address (128 битов)           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Remote Peer Port        |     Reserved (16 битов)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Remote Peer IP Address (128 битов)              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. Отклик PEER.

Lifetime (в общем заголовке) — срок действия

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

Mapping Nonce — случайный идентификатор отображения

Копируется из запроса.

Protocol — протокол

Копируется из запроса.

Reserved — резерв

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

Internal Port — внутренний порт

Копируется из запроса.

Assigned External Port — выделенный внешний порт

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

Assigned External IP Address — выделенный внешний адрес

При успешном завершении показывает выделенный для отображения внешний адрес IPv4 или IPv6, в случае ошибки значение поля копируется из запроса.

Remote Peer Port — порт удаленного партнера

Копируется из запроса.

Reserved — резерв

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

Remote Peer IP Address — адрес удаленного партнера

Копируется из запроса.

12.2 Генерация запроса PEER

В этом параграфе описаны действия клиента при генерации сообщения с кодом операции PEER.

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

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

Если сообщение передается после организации соединения, оно позволяет клиенту PCP узнать адрес IP, порт и срок действия имеющегося неявного динамического отображения и продлить срок действия отображения (для снижения объема сообщений keepalive, как описано в параграфе 10.3).

Запросы PEER полезны также при восстановлении отображений после потери состояния отображений в NAT 9например, в результате перезапуска устройства).

Значение Mapping Nonce случайным образом выбирается клиентом в соответствии с рекомендациями по генерации случайных чисел [RFC4086] и применяется в процессе проверки откликов PCP (см. ниже) клиентом и проверки при обновлении отображений на сервере PCP. Клиент должен использовать свое значение nonce для каждого сервера PCP, с которым он взаимодействует и рекомендуется также выбирать новое значение nonce при каждой инициализации клиента PCP. Клиент может использовать разные значения mapping nonce для каждого отображения.

Сообщение PEER включает поле Remote Peer Address, адрес в котором указывается с точки зрения клиента PCP. Отметим, что в тех случаях, когда управляемое PCP устройство меняет семейство адресов (трансляция NAT46 или NAT64), адрес удаленного партнера с точки зрения клиента PCP отличается от адреса, который виден с другой стороны устройства-транслятора.

12.3 Обработка запроса PEER

В этом параграфе описаны действия сервера при получении запросов с кодом операции PEER. Операции следует выполнять в порядке приведенного здесь описания.

Поля запроса PEER Protocol, Internal Port, Remote Peer IP Address, Remote Peer Port и Mapping Nonce копируются из запроса в отклик.

При создании неявных динамических отображений некоторые устройства NAT и МСЭ проверяют адреса получателей и не будут создавать неявных динамических отображений для недопустимых адресов (например, 127.0.0.1). Если управляемое PCP устройство выполняет такую проверку для неявных динамических отображений, ему следует также проверять допустимость полей удаленного адреса, протокола и порта для создаваемых операцией PEER явных динамических отображений. Если при проверке адреса удаленного партнера в запросе PEER обнаружена его недопустимость, отображение не создается и клиенту возвращается отклик с кодом ошибки MALFORMED_REQUEST.

При получении запроса PEER сервер PCP проверяет свою таблицу отображений на предмет наличия отображения для {Protocol, Internal Address, Internal Port, Remote Peer Address, Remote Peer Port}.

Если соответствующего отображения не обнаружено в таблице, а предложенные внешний адрес и порт имеют значение 0 или могут быть выделены для указанного значения Protocol, создается новое отображение. За счет создания таких отображений с помощью PEER мы избегаем «соперничества» между отправкой PEER и прибытием на устройство NAT или МСЭ первого исходящего пакета, а также обеспечиваем возможность использования операции PEER для восстановления утраченных исходящих динамических отображений (см. 16.3.1 Повторная организация отображений). После этого созданное с помощью операции PEER отображение трактуется, как неявное динамическое исходящее отображение (например, созданное в результате передачи клиентом пакета TCP SYN) и возвращается срок действия такого отображения (отметим, что на многих устройствах NAT и МСЭ время жизни таких отображений весьма мало и они удаляются после завершения двухстороннего трафика через NAT или МСЭ).

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

Если соответствующее отображение найдено в таблице, но для него не зафиксировано успешной обработки PEER, значения полей Suggested External Address и Port в запросе игнорируются, срок жизни отображения устанавливается в соответствии приведенным ниже описанием и клиенту возвращается информация об имеющемся отображении. Это позволяет клиенту явно продлить срок действия отображения и/или узнать текущие значения для внешнего адреса, порта и срока действия отображения. Значение mapping_nonce для отображения сервер запоминает.

Если используется простая модель угроз (параграф 18.1) и отображение для внутреннего порта, протокола и внутреннего адреса уже организовано, но значение mapping nonce не соответствует (т. е., был обработан предшествующий запрос PEER), запрос должен быть отвергнут с возвратом клиенту кода ошибки NOT_AUTHORIZED и указанием в поле lifetime срока действия имеющегося отображения. Серверу PCP требуется лишь запоминать значения Mapping Nonce для каждого отображения. В данной спецификации не предъявляется требований к обработке Mapping Nonce для расширенной модели угроз.

Обработка значения Lifetime из PEER Opcode описана в разделе 15 Срок действия и удаление отображений. Отправка запросов PEER с очень малым сроком действия может применяться для запроса срока действия существующих отображений. Для того, чтобы клиенты PCP могли сократить частоту своих сообщений keepalive устройствам NAT и МСЭ, рекомендуется делать срок действия отображений, созданных или продленных с помощью PEER, больше срока действия неявно созданных отображений.

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

Если созданное или поддерживаемое с помощью PEER отображение не обновляется с применением PEER, оно возвращается к обычному для NAT поведению неявных отображений. Например, продолжающийся исходящий трафик будет сохранять отображение в соответствии с политикой NAT или МСЭ. Созданные или поддерживаемые с помощью PEER отображения могут быть прерваны в любой момент действиями клиента или сервера TCP (например, передачей TCP FIN или TCP RST), а также политикой NAT или МСЭ.

12.4 Обработка отклика PEER

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

После обычной обработки отклика PCP отклик дополнительно сопоставляется с незавершенным запросом PEER путем сравнения внутреннего адреса IP (адрес получателя сообщения PCP или иной адрес IP, заданный опцией THIRD_PARTY), протокола, внутреннего порта, адреса и порта удаленного партнера и nonce отображения. Остальные поля не сравниваются, поскольку сервер PCP устанавливает эти поля для предоставления информации об отображении, созданном Opcode. Сервер PCP будет передавать Mapping Update (параграф 14.2) при смене отображения (например, в результате изменения адреса IP).

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

При успешном отклике приложение может использовать выделенное значение Lifetime для снижения частоты сообщений keepalive от приложения для данного отображения NAT. Естественно, у приложения могут быть свои причины использовать более высокую частоту отправки keepalive. Например, назначенное PCP время жизни может составлять 1 час, а приложение может желать указывать состояние своего сервера (например, busy или away) более часто. Если отклик указывает неожиданный адрес IP или порт (например, в результате смены IP), клиент PCP захочет заново организовать соединение с удаленным сервером.

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

Примечание. Реализации должны ожидать, что сообщение PEER может содержать внешний адрес IP из другого семейства, нежели адрес удаленного партнера, например, при использовании NAT64 или NAT46.

13 Опции MAP и PEER

В этом разделе описаны опции для операций MAP и PEER. Эти опции недопустимо применять с другими Opcode, если это явно не указано для соответствующего Opcode.

13.1 Опция THIRD_PARTY для MAP и PEER

Эта опция применяется, когда клиент PCP хочет контролировать отображение на другой внутренний хост. Опция используется с кодами MAP и PEER.

По причине проблем безопасности, связанных с THIRD_PARTY, эту опцию недопустимо реализовать или применять, если сеть, в которой передаются сообщения PCP, не является полностью доверенной. Например, если у клиента PCP установлены списки контроля доступа (ACL²³), в соответствии с которыми разрешается доступ лишь к серверу PCP и сети между клиентом и сервером PCP.

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

Ниже показан формат опции THIRD_PARTY.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code=1 |  Reserved     |   Option Length=16            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                Internal IP Address (128 битов)                |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Опция THIRD_PARTY.

Internal IP Address

Внутренний IP-адрес для этого отображения.

Имя опции

THIRD_PARTY

Номер

Назначение

Указывает, что запрос MAP или PEER сделан не для того хоста, который передает опцию PCP.

Действительна для Opcode

MAP и PEER.

Размер

16 октетов

Может указываться

В запросах. В отклике может присутствовать лишь при наличии опции в соответствующем запросе.

Максимальное число экземпляров

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

Сервер PCP можно настроить на разрешение или запрет использования опции THIRD_PARTY. Если эта опция разрешена, корректно уполномоченные клиенты могут выполнять эти операции от имени других хостов. Если опция запрещена и сервер PCP получает запрос PCP MAP с опцией THIRD_PARTY, он должен вернуть отклик UNSUPP_OPTION.

На абонентском оборудовании, реализующем сервер PCP, рекомендуется настроить по умолчанию запрет на отображения для других хостов. В таком случае, если пользователь хочет создать отображение для другого хоста, ему нужно взаимодействовать по отдельному каналу (out-of-band) с абонентским маршрутизатором (например, через административный интерфейс HTTP).

Провайдерским устройствам NAT и МСЭ, реализующим функции сервера PCP, рекомендуется разрешать опцию THIRD_PARTY, переданную корректно уполномоченным хостом. Если пакет приходит от неуполномоченного хоста, сервер PCP должен генерировать ошибку UNSUPP_OPTION.

Следует отметить, что опция THIRD_PARTY не требуется в распространенном современном варианте, когда ISP предоставляет клиенту один адрес IP и клиент применяет NAT для совместного использования данного адреса, поскольку в этом случае все хосты клиента с точки зрения ISP будут одним хостом.

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

13.2 Опция PREFER_FAILURE для MAP

Эта опция может применяться лишь с MAP Opcode.

Эта опция указывает, что серверу PCP не следует создавать отображение, если он не способен отобразить сразу предложенный внешний порт и предложенный внешний адрес. Без опции отображение будет создаваться.

PREFER_FAILURE никогда не требуется клиенту PCP для управления своими отображениями, а ее применение требует дополнительной работы клиента и сервера PCP. Опция служит для взаимодействия с протоколами отображения, не поддерживающими PCP, которые применяют отличную от PCP семантику (например, UpnP IGDv1 [PNP-IGD-PCP], где семантика UPnP IGDv1 позволяет клиенту UPnP IGDv1 лишь задать отображение конкретного порта), или отдельными системами распределения портов между клиентами (например, доступный клиентам web-портал, который управляется тем же ISP что и сервер PCP). Сервер PCP может поддерживать эту опцию, если его разработчики считают нужным поддерживать такие нисходящие устройства или отдельные системы распределения портов. Серверы PCP, не предназначенные для взаимодействия с такими системами, могут не поддерживать опцию. Клиентам PCP, отличным от клиентов взаимодействия с UPnP IGDv1 или отдельных систем распределения портов, не следует применять эту опцию, поскольку она ведет к неэффективной работе и нет уверенности в том, что все серверы PCP будут реализовать опцию. Ожидается, что в будущем опция будет отменена, поскольку все больше клиентов будут естественным путем поддерживать PCP.

Формат опции PREFER_FAILURE показн на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code=2 |  Reserved     |   Option Length=0             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Опция PREFER_FAILURE.

Имя опции

PREFER_FAILURE

Номер

Назначение

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

Действительна для Opcode

MAP

Размер

Может указываться

В запросах. В отклике может присутствовать лишь при наличии опции в соответствующем запросе.

Максимальное число экземпляров

Если предложенные внешний адрес, протокол и порт не могут быть отображены, возвращается код CANNOT_PROVIDE_EXTERNAL. Это может быть в результате того, что внешний порт уже отдан динамическому выходному или входному или статическому отображению другого хоста или тот же внутренний адрес, протокол и порт уже имеют выходное динамическое отображение на другой внешний порт. Это может возникать также в результате того, что внешний адрес утратил доступность (например, в результате смены адресов). Сервер может указать в отклике оставшийся срок действия конфликтующего отображения + TIME_WAIT [RFC0793] с округлением до целого числа секунд в большую сторону.

Если запрос PCP включает опцию PREFER_FAILURE, а в поле Suggested External Port указан 0, запрос будет недействительным. Сервер PCP должен отвергнуть сообщение с возвратом кода ошибки MALFORMED_OPTION.

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

Может возникать конкуренция между MAP Opcode с опцией PREFER_FAILURE и Mapping Update (параграф 14.2). например, предыдущий хост локальной сети мог ранее использовать тот же внутренний адрес с отображением на тот же внутренний порт. Примерно в одно время с отправкой текущим хостом запроса MAP с опцией PREFER_FAILURE сервер PCP может передать спонтанное сообщение Mapping Update для старого отображения в результате внешнего изменения конфигурации, которое может выглядеть откликом на запрос нового отображения. По этой причине клиент PCP должен проверить свои внешний адрес IP, протокол, порт и nonce в отклике об успешном отображении на предмет совпадения со значениями, предложенными в запросе. Несоответствие говорит о том, что сообщение Mapping Update было передано до обработки запроса MAP.

13.3 Опция FILTER для MAP

Эта опция может применяться лишь с MAP Opcode.

Опция указывает желательность фильтрации входящих пакетов. Фильтруемый протокол указывается полем Protocol в запросе MAP Request, а IP-адрес и порт удаленного партнера в опции FILTER указывают разрешенные адрес и порт отправителя для пакетов из Internet (остальной трафик блокируется). Размер префикса удаленного партнера указывает значимые биты IP-адреса удаленного партнера, это позволяет с помощью одной опции разрешить пакеты из всей подсети. После обработки запроса MAP с опцией FILTER и генерации отклика об успехе управляемое PCP устройство будет отбрасывать пакеты на своем внешнем интерфейсе, если они не совпадают с полями фильтра. Если политика безопасности разрешат, управляемое PCP устройство после отбрасывания пакета может передавать сообщение ICMP об ошибке.

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

Формат опции FILTER показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code=3 |  Reserved     |   Option Length=20            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   | Prefix Length |      Remote Peer Port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|               Remote Peer IP address (128 битов)              |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Схема опции FILTER.

Reserved

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

Prefix Length

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

Remote Peer Port

Номер порта удаленного партнера (0 — все порты).

Remote Peer IP address

IP-адрес удаленного партнера.

Имя опции

FILTER

Номер

Назначение

Задает фильтрацию входящих пакетов.

Действительна для Opcode

MAP

Размер

20 октетов

Может указываться

В запросах. В отклике может присутствовать лишь при наличии опции в соответствующем запросе.

Максимальное число экземпляров

Число фильтров ограничивается размером сообщения PCP.

Prefix Length указывает число битов адреса, учитываемых фильтром. Для адресов IPv4 (представляются в формате IPv4-mapped — ::FFFF:0:0/96) размер префикса может составлять от 97²⁴ до 128 битов, включительно, т. е. к реальному размеру префикса IPv4 добавляется 96. Для адресов IPv6 размер префикса может составлять от 1¹ до 128 битов, включительно. Значения, выходящие за указанные пределы заставят сервер PCP вернуть код MALFORMED_OPTION.

При включении множества опций FILTER в запрос MAP они обрабатываются в порядке получения (как при обычной обработке опций PCP) и запрошенные фильтры могут перекрываться. Если отображение уже есть (с фильтром или без него) и сервер получает запрос MAP с опцией FILTER, указанные в новой опции фильтры добавляются к имеющимся. Если для запроса MAP указан срок действия 0 и в нем имеется опция FILTER, возвращается код ошибки MALFORMED_OPTION.

Если при обработке какой-либо из опций FILTER в пакете запроса возник отказ, возвращается код ошибки (например, MALFORMED_OPTION, если одна из опций имеет некорректный формат) и (как для других ошибок PCP) состояние сервера PCP или управляемого PCP устройства не меняется.

Для удаления всех фильтров применяется Prefix Length=0. В полях Remote Peer Port и Remote Peer IP Address должно устанавливаться значение 0, а при получении они должны игнорироваться²⁵. Механизмов удаления отдельных фильтров нет.

Для изменения имеющегося фильтра клиент PCP передает запрос MAP с двумя опциями FILTER, первая из которых указывает префикс размера 0 (удаление всех фильтров), а вторая задает новый адрес, протокол и порт удаленного партнера. Если нужно указать множество партнеров, в запрос PCP включаются дополнительные опции FILTER.

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

Все серверы PCP должны поддерживать хотя бы один фильтр на отображение MAP.

14 Быстрое восстановление

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

Функция быстрого восстановления PCP позволяет пользователям, например, подключиться к удаленной машине по протоколу ssh, а затем перезагрузить свое устройство NAT или МСЭ (и даже заменить его физически на другое устройство) без потери соединения ssh.

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

Имеется два механизма быстрого восстановления, описанных ниже. Неспособность реализовать и развернуть механизм быстрого восстановления заставляет разработчиков приложений чаще обновлять состояние PCP, нежели это требуется, что ведет к росту сетевого трафика. Поэтому сервер PCP, который может потерять состояние (например, при перезагрузке) или изменить отображение (например, в результаты смены адресов IP), должен реализовать механизм Announce Opcode или Mapping Update и следует реализовать оба.

14.1 Код операции ANNOUNCE

Этот механизм быстрого восстановления использует ANNOUNCE Opcode. Когда сервер PCP теряет свое состояние (например, при перезагрузке), он сбрасывает время Epoch в исходное стартовое значение (обычно 0) и передает отклик ANNOUNCE с групповым адресом в рамках канала (link-scoped, см. ниже), если на локальном интерфейсе имеется сеть с групповой адресацией, или при настройке на нем адресов IP и портов клиентов PCP передает индивидуальные сообщения ANNOUNCE в эти адреса и порты. Это означает, что сообщения ANNOUNCE могут быть доступны не всей сети (например, для сети без групповой адресации на канале между сервером и клиентами PCP). Кроме того, запрос ANNOUNCE может быть передан (индивидуально) клиентом PCP, желающим получить индивидуальный отклик ANNOUNCE, подобно любому другому Opcode.

При получении пакетов отклика PCP с аномальным значением Epoch клиенты узнают, что сервер PCP потерял состояние и восстанавливают свои утраченные отображения.

14.1.1 Операция ANNOUNCE

Запросы и отклики PCP ANNOUNCE Opcode не имеют специфического для этого кода содержимого (т. е. размер связанных с Opcode данных равен 0). Поле Requested Lifetime в запросах и поле Lifetime в откликах имеют значения 0 при передаче и игнорируются получателем.

Если сервер PCP получает запрос ANNOUNCE, он сначала анализирует его и генерирует отклик SUCCESS при успешном разборе и обработке ANNOUNCE. Если поле IP Address для клиента не совпадает с адресом отправителя пакета или в пакете имеется иная ошибка форматирования, например, размер пакета меньше 24 октетов, сервер возвращает ошибку. Отметим, что в будущем для PCP ANNOUNCE Opcode могут быть добавлены опции, поэтому клиентам и серверам PCP нужно быть готовыми принимать опции с ANNOUNCE Opcode.

Обсуждение. Сообщения с запросами от клиента к серверу передаются из любого порта клиента в порт UDP 5351 на сервере, групповые уведомления клиентам от сервера передаются из серверного порта UDP (5351) в порт UDP 5350 на стороне клиента. Причина использования разных портов на приемной стороне заключается в том, что устройство может одновременно выступать в нескольких ролях. Например, многофункциональный домашний шлюз может предоставлять услуги NAT (сервер PCP), а также совместный доступ к принтеру (клиент PCP) или домашний компьютер (клиент PCP) может обеспечивать совместный доступ в Internet (NAT), для чего он должен быть сервером PCP. Такие устройства выступают в качестве клиента и сервера одновременно и серверная программа PCP на устройстве может использовать не те компоненты, которые реализует клиент PCP. Серверным программам PCP нужно прослушивать индивидуальные пакеты с запросами клиентов, а клиентским — групповые анонсы перезапуска. Во многих сетевых API сложно или невозможно иметь 2 независимых клиента, прослушивающих одновременно индивидуальные и групповые пакеты на одном порту. Поэтому применяется два разных порта.

14.1.2 Генерация и обработка запрошенных сообщений ANNOUNCE

PCP ANNOUNCE Opcode может передавать клиент PCP (по индивидуальному адресу). Значение Requested Lifetime должно быть 0.

Когда сервер PCP получает ANNOUNCE Opcode, успешно анализирует и обрабатывает его, он генерирует отклик SUCCESS с нулевым временем жизни.

Эта функциональность позволяет клиенту PCP определить значение Epoch на сервере или убедиться в работоспособности сервера без изменения состояния сервера.

14.1.3 Генерация и обработка незапрошенных сообщений ANNOUNCE

При передаче незапрошенных откликов ANNOUNCE Opcode они должны иметь нулевой код результата (SUCCESS), а пакет должен передаваться с индивидуального адреса IP и из порта UDP, через который принимаются запросы PCP (чтобы описанная в параграфе 8.3 обработка откликов PCP воспринимала сообщение). Эти сообщения обычно передаются по групповому адресу, но могут быть и индивидуальными. Групповые анонсы перезапуска PCP передаются по адресу 224.0.0.1:5350 и/или [ff02::1]:5350, как описано ниже. Передача анонсов перезапуска PCP по индивидуальному адресу требует от сервера PCP знать IP-адреса и порты своих слушающих клиентов, поэтому такая передача анонсов перезапуска применима лишь для тех серверов PCP, которые сохраняют адреса и порты своих клиентов даже после потери и восстановления своего состояния.

Когда серверное устройство PCP перезагружается, перезапускает свою машину NAT или иначе меняет свое состояние с потерей данных отображения из своего предшествующего состояния (или входит в состояние где даже неизвестно о наличии предыдущего состояния, которое было потеряно), сервер должен информировать клиентов PCP об этом факте путем индивидуальной или групповой передачи беспричинных пакетов откликов PCP ANNOUNCE Opcode, как показано ниже, через пути, по которым сервер принимает запросы PCP. Если передается групповое сообщение ANNOUNCE, серверное устройство PCP, которое воспринимает запросы PCP по протоколу IPv4 передает Restart Announcement по групповому адресу 224.0.0.1:5350 (групповой адрес для всех хостов — All Hosts), а устройство, воспринимающее запросы PCP по протоколу IPv6 передает Restart Announcement по групповому адресу IPv6 [ff02::1]:5350 (все хосты локального сегмента). Серверное устройство, воспринимающее запросы PCP по протоколам IPv4 и IPv6 передает пару сообщений Restart Announcements — по одному в каждый из указанных адресов. При передаче индивидуальных сообщений ANNOUNCE отклики направляются по адресам IP и портам клиентов PCP. Для компенсации потери пакетов серверное устройство PCP может передать такие пакеты (или пары пакетов) до 10 раз (с подходящим значением Epoch Time в каждом, отражающим время между отправкой сообщения) при этом интервал между первыми двумя сообщениями должен быть не менее 250 мсек, а затем как минимум удваивался для каждого последующего сообщения.

Клиент, который передает запросы PCP серверу PCP по пути с поддержкой групповой адресации, реализует функцию Restart Announcement и хочет получать эти анонсы, должен слушать эти PCP Restart Announcement (беспричинные пакеты откликов PCP ANNOUNCE Opcode) на подходящих интерфейсах с поддержкой групповой адресации, в которые он передает запросы PCP, и может также слушать индивидуальные анонсы от сервера (используя порт UDP, который он применяет для отправки индивидуальных запросов PCP и для приема индивидуальных откликов от этого сервера PCP). Клиентское устройство PCP, которое передает запросы PCP, используя IPv4, слушает пакеты IPv4, переданные по групповому адресу 224.0.0.1:5350. Клиентское устройство PCP, которое передает запросы PCP, используя IPv6, слушает пакеты IPv6, переданные по групповому адресу [ff02::1]:5350. Клиентское устройство PCP, которое передает запросы PCP, используя IPv4 и IPv6, слушает оба типа Restart Announcement. Следует использовать опцию сокета SO_REUSEPORT или эквивалент для группового порта UDP, если ОС хоста требует множества независимых экземпляров для прослушивания одного группового порта UDP.

При получении индивидуального или группового пакета с откликом PCP ANNOUNCE Opcode клиент PCP должен (как и для всех полученных откликов PCP) проверить адрес отправителя анонса и если значение Epoch Time выходит за пределы ожидаемого для этого сервера, клиент должен выждать случайное время от 0 до 5 секунд (для предотвращения синхронизации всех клиентов PCP), а затем передать новые запросы PCP для всех отображений на этом сервере, чтобы восстановить утраченные состояния. Использование полей Suggested External IP Address и Suggested External Port fields в запросах на обновление позволяет клиенту напомнить перезагруженному серверному устройству PCP свои прежние отображения, что позволяет во многих случаях воссоздать их. Для серверных устройств PCP, которые перезагружаются сравнительно быстро, обычно можно восстановить потерянные состояния отображения достаточно быстро, чтобы существующие соединения TCP и обмен UDP не столкнулись с тайм-аутом и продолжили работать без сбоев. Если в откликах PCP значение Epoch Time находится внутри ожидаемого диапазона, клиент PCP не создает своих отображений заново. Как и для всех откликов PCP, после получения и проверки сообщения ANNOUNCE клиент обновляет свое значение Epoch для сервера, как описано в параграфе 8.5.

14.2 Обновление отображений PCP

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

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

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

Для управляемых PCP отображений следует обновить внешний IP-адрес и порт подходящими доступными значениями для каждого серверного устройства PCP, а затем передать индивидуальные отклики PCP MAP или PEER (что подходит для отображения), чтобы информировать клиента PCP о новом внешнем адресе IP и номере порта. Такие незапрошенные отклики MAP или PEER обычно возвращаются в ответ на клиентский запрос MAP или PEER с новыми значениями External IP Address и External Port и передаются в тот же IP-адрес и порт клиента, которые сервер PCP использовал при предшествующем отклике для того же отображения. Если предшествующий связанный запрос включал опцию THIRD_PARTY, эта опция должна быть указана в Mapping Update, поскольку она требуется клиенту PCP для устранения неоднозначности отклика. Если предшествующий связанный запрос включал опцию PREFER_FAILURE, но прежние внешний адрес IP, протокол и порт не могут быть предоставлены, следует возвращать ошибку CANNOT_PROVIDE_EXTERNAL. Если предшествующий связанный запрос включал опцию FILTER, фильтры переносятся в новое отображение и опция FILTER передается в отклике Mapping Update. Необязательные опции не следует передавать в отклике Mapping Update.

Обсуждение. Можно было бы сделать так — сервер PCP (1) передает ANNOUNCE Opcode клиенту PCP, клиент отвечает на это (2) отправкой нового запроса MAP и (3) получает отклик MAP. Вместо этого сервер использует более рациональный вариант, просто отправляя сообщение, которое он передал бы в (3).

Для компенсации потери пакетов серверному устройству PCP следует передавать такие пакеты 3 раза с соответствующей корректировкой значений Epoch Time в каждом пакете для учета прошедшего времени. Интервал между первым и вторым уведомлением должен быть не менее 250 мсек, между вторым и третьим — не менее 500 мсек. После получения сервером PCP обновленного состояния для этого отображения серверу следует прекратить повтор передачи этих отображений, поскольку этого больше не требуется.

При получении таких обновленных откликов MAP или PEER клиент PCP использует информацию из откликов для настройки сервера rendezvous или повторного подключения к серверу, соответственно. Для MAP это будет означать, что записи DNS и другие данные об адресах и портах записаны с каким-то зависящим от приложения сервером rendezvous. Для откликов PEER, указывающих ошибку CANNOT_PROVIDE_EXTERNAL, это обычно означает организацию новых соединений с серверами. При каждом изменении внешнего адреса или порта имеющиеся соединения TCP и UDP будут теряться — PCP не может это предотвратить, но пытается обеспечить механизм уведомлений для снижения негативного влияния.

15 Срок действия и удаление отображений

Клиент PCP запрашивает определенный срок действия отображений, а сервер PCP отвечает назначенным сроком действия. Сервер PCP может предоставить срок действия, отличающийся от запрошенного. Серверу PCP следует поддерживать возможность настройки максимального и минимального срока действия и в качестве минимального следует устанавливать срок 120 секунд. В качестве максимального срока следует устанавливать оставшееся время действия IP-адреса, назначенного клиенту, если эта информация доступна (например, от сервера DHCP), половину от срока выделения IP-адресов в данной сети, если оставшийся срок действия адреса недоступен, или 24 часа. Слишком большой срок действия может приводить к неоправданному расходу портов, если внутренним хостам уже не требуется получение трафика или они отключились от сети. Эти рекомендации не являются строгими и администраторам следует оценить компромиссы для выбора минимального и максимального срока действия отображения (Lifetime) в их сети.

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

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

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

Для оказания помощи в очистке состояний PCP при размещении управляемого PCP устройства вместе с сервером назначения адресов (DHCP), что типично для домашних CPE, рекомендуется следующее поведение — если адрес IP недействителен (например, завершение аренды DHCP или отправка клиентом DHCP явного сообщения DHCP RELEASE), управляемому PCP устройству следует отбросить динамические отображения, связанные с этим адресом.

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

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

Наконец, для снижения уровня нежелательного трафика и повреждения данных TCP и UDP назначенный внешний порт (с помощью MAP Opcode или PEER Opcode) не следует повторно выделять в течение интервала, равного ограничению времени повторного использования в NAT для неявных динамических отображений (обычно, максимальное время жизни сегмента TCP — 2 минуты [RFC0793]). Кроме того, для подавления атак с захватом портов выделенный внешний порт не следует снова использовать до истечения интервала, равного времени, в течение которого управляемое PCP устройство может обычно поддерживать бездействующие (нет трафика) неявные динамические отображения (например, 2 минуты для UDP [RFC4787] и 124 минуты для TCP [RFC5382]). Однако в этом интервале серверу PCP следует разрешать повторное заявление порта тем же клиентом (тот же в данном случае означает совпадение внутреннего адреса IP, внутреннего порта и nonce для отображения).

15.1 Обработка срока действия для MAP

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

Если поля протокола и внутреннего порта отличны от 0, это означает запрос незамедлительного удаления указанного отображения.
Если поле протокола отлично от нуля, а внутренний порт имеет значение 0, это означает запрос на удаление предыдущего «шаблонного» (все порты) отображения для этого протокола. Значение nonce должно совпадать с указанным при создании «шаблонного» отображения nonce.
Если поля протокола и внутреннего порта имеют значение 0, это указывает запрос на удаление предыдущего отображения DMZ host (весь входящий трафик для всех протоколов). Значение nonce должно совпадать с указанным при создании отображения DMZ host.
Если поле протокола имеет значение 0, а внутренний порт — ненулевое значение, это говорит о недействительности запроса и сервер PCP должен вернуть клиенту код ошибки MALFORMED_REQUEST.

В запросах, где Lifetime = 0, поля Suggested External Address и Suggested External Port должны устанавливаться в 0 при передаче и должны игнорироваться принимающей стороной. В поле Suggested External Address должен быть указан подходящий адрес, содержащий только нули, в зависимости от того, запрашивается удаление для внешнего адреса IPv4 или IPv6. Значения поле Suggested External Address и Suggested External Port копируются в поля назначенных внешнего адреса и внешнего порта в отклике²⁶.

Запросы PCP MAP могут удалять или сокращать срок действия лишь для отображений, созданных с помощью MAP. Если клиент PCP пытается удалить статическое (т. е. созданное за пределами PCP) или исходящее (неявное или PEER) отображение, сервер PCP должен возвращать NOT_AUTHORIZED. Если клиент PCP пытается удалить отсутствующее отображение, возвращается код SUCCESS (это требуется ля того, чтобы PCP возвращал один отклик для повторов или дубликатов запроса). Если запрос на удаление сформирован корректно и успешно обработан, создается отклик SUCCESS с полями протокола и внутреннего порта из запроса и сроком действия 0. Для входящих отображения (т. е. статических или динамически созданных MAP) недопустимо снижение срока действия с помощью сообщений транспортного протокола (например, TCP RST, TCP FIN). Отметим, что опций THIRD_PARTY (параграф 13.1), если она разрешена, также может удалять созданные PCP отображения MAP.

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

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

16.1 Реализация MAP с EDM Port-Mapping NAT

Для неявных динамических отображений поведение некоторых устройств NAT не зависит от конечных точек (EIM²⁷), тогда как поведение других зависит (EDM²⁸). Устройства NAT с поведением EIM не подвержены описанной здесь проблеме. IETF настоятельно рекомендует поведение EIM [RFC4787][RFC5382].

В устройствах EDM NAT один внешний порт может применяться для входящего и исходящего динамических отображений (для одного или разных внутренних хостов). Это осложняет взаимодействие с MAP Opcode. Для таких устройств NAT предусмотрено два способа, описанных ниже.

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

16.2 Срок действия явных и неявных динамических отображений

Независимо от режима NAT EIM или EDM, возможно, что одно (или несколько) выходных отображений, использующих тот же внутренний порт на внутреннем хосте, могут быть созданы до или после запроса MAP. В таких случаях важно соблюдение NAT срока действия, указанного в отклике MAP. В частности при создании входного отображения с помощью MAP Opcode реализация должна гарантировать, что прерывание выходного отображения (например, с помощью TCP FIN) не нарушит созданное MAP входное отображение.

16.3 Восстановление при отказах PCP

Если происходит событие, в результате которого сервер PCP теряет состояние динамических отображений (например, отказ или потеря питания), созданные PCP отображения теряются. Случайные потери состояния могут быть неизбежными в домашних устройствах NAT, которые не записывают временные данные в энергонезависимую память. Предполагается, что в средах сервис-провайдеров потери состояния будут редкими (резервное питание, запись данных на диск и т. п.). Конечно при полном отказе оборудования сервис-провайдера (например, программный сбой) состояние все равно может теряться.

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

Дополнительный анализ сценариев отказа PCP планируется рассмотреть в отдельном документе [PCP-FAIL].

16.3.1 Повторная организация отображений

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

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

16.3.2 Поддержка отображений

Клиент PCP обновляет отображение путем передачи нового запроса PCP с информацией, полученной из прежнего отклика PCP. Сервер PCP будет отвечать с указанием нового срока действия. В результате перенастройки или отказа сервера PCP может смениться внешний адрес IP и/или внешний порт, а также сам сервер PCP (по причине нового маршрута к другому серверу PCP). Такие события редки и не являются ошибкой. Сервер PCP будет просто возвращать клиенту новый внешний адрес и/или порт, а клиенту следует записать новый внешний адрес и порт для своей службы rendezvous. Для более быстрого обнаружения таких событий сервер, которому нужна максимально возможная доступность, может предпочесть указание более коротких сроков действия в запросах PCP, чтобы взаимодействие с этим сервером происходило чаще. Это технический компромисс, основанный на учете (i) приемлемого времени простоя для соответствующей службы, (ii) ожидаемой вероятности потери состояния устройствами NAT или МСЭ и (iii) приемлемого уровня служебного трафика PCP.

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

Если клиент PCP меняет свой внутренний адрес IP (например, при перемещении внутреннего хоста в другую сеть) и хочет по-прежнему получать входящий трафик, ему нужно создать новое отображение для этого адреса. Обычно новое отображение требует также обновления связанного с приложением сервера rendezvous, если внешний адрес и порт отличаются от прежних значений (см. параграфы 10.1 и 11.5).

16.3.3 SCTP

Хотя SCTP использует номера портов как TCP и UDP, протокол SCTP работает иначе при расположении за устройством NAT с общим адресом, поскольку номера портов SCTP не меняются [SCTPNAT]. Исходящее динамическое отображение SCTP использует тег проверки ассоциации вместо номеров порта локального и удаленного партнера. Как и в TCP, явные исходящие отображения могут создаваться для снижения интервалов keepalive, а явные входные отображения могут создаваться пассивными слушателями для приема новых ассоциаций на внешнем порту.

Поскольку поддерживающие SCTP устройства NAT (в настоящее время) не меняют номера портов SCTP, они не могут назначать внешний порт, отличающийся от внутреннего порта клиента. Клиент PCP, делающий запрос MAP для SCTP, должен учитывать это ограничение. Клиенту PCP следует делать запрос SCTP MAP как для случая TCP MAP — в начальном запросе PCP MAP следует указать 0 для внешнего адреса и порта, а в последующих запросах обновления следует указывать назначенный внешний адрес и порт. Однако с учетом того, что современные устройства SCTP NAT могут назначать только совпадающий с внутренним внешний порт, оно может оказаться неспособным назначить внешний порт, поскольку он уже выделен другому клиенту PCP. Такое событие вероятно при наличии в локальной сети нескольких экземпляров данного сервиса SCTP, поскольку два экземпляра могут прослушивать один общеизвестный порт SCTP на соответствующих хостах, но они не смогут использовать один порт на внешнем адресе шлюза NAT. Определенный внешний порт может оказаться недоступным и по иным причинам, таким как использование самим устройством NAT или запрет политикой, как указано в параграфе 11.3 Обработка запроса MAP. Если внешний порт, совпадающий с внутренним, не может быть назначен (и SCTP NAT не меняет порты SCTP), устройство SCTP NAT должно возвращать клиенту ошибку CANNOT_PROVIDE_EXTERNAL. Отметим, что это ограничение создает дополнительную нагрузку на сервер SCTP, чьи запросы MAP отвергаются, поскольку он должен закрыть имеющийся приемный сокет и пытаться применить другой порт, пока не будет найден подходящий, которые свободен снаружи.

Описанные сложности SCTP связаны с совместным использованием адреса, которого можно избежать (например, с помощью отображения 1:1 в NAT или МСЭ).

16.4 Репликация адреса отправителя в заголовок PCP

Все запросы PCP повторяют IP-адрес клиента PCP в заголовке PCP. Это служит для обнаружения неожиданного изменения адреса (NAT) в пути между клиентом и сервером PCP. В ОС с поддержкой API сокетов клиентам PCP рекомендуется выполнять указанные ниже действия для вставки корректного адреса в заголовки PCP.

Создать сокет UDP.
Вызвать функцию connect на этом сокете UDP, используя адрес и порт нужного сервера PCP.
Вызвать функцию getsockname() для получения sockaddr с адресом отправителя, который ядро будет указывать в пакетах UDP, передаваемых через этот сокет.
Если адрес относится к IPv4, он кодируется в IPv4-mapped адрес IPv6. Адрес IPv4-mapped или естественный адрес IPv6 помещается в поле клиентского адреса IP в заголовке PCP.
Запрос PCP передается с использованием подключенного сокета UDP.

16.5 Диаграмма состояний

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

  CLOSE_MSG или
 (NO_TRAFFIC и EXPIRY)     +---------+  NO_TRAFFIC и EXPIRY
           +-------------->|         |<------------+
           |               |NO_ENTRY |             |
           |   +-----------|         |---------+   |
           |   |           +---------+         |   |
           |   |              ^  |             |   |
           |   |   NO_TRAFFIC |  |             |   |
           |   |          или |  |             |   |
           |   |   CLOSE_MSGS |  |             |   |
           |   |              |  |             |   |
           |   | запрос PEER  |  | запрос MAP  |   |
           |   V              |  |             V   |
        +---------+           |  |         +---------+
    +-->|  "P",   |           |  |    M-R  |  "M",   |<--+
P-R |   | отображ.|-----------|--|-------->| отображ.|   | M-R или
    +---| PEER    |           |  |         | MAP     |---+ P-R или
        +---------+           |  |         +---------+  CLOSE_MSGS
           |   ^              |  |             ^   |
           |   |отображ. PEER |  | отображ. MAP|   |
           |   |              |  |             |   |
           |   |              |  |             |   |
           |   |              |  |             |   |
           |   |              |  | исходящее   |   |
           |   |              |  | TRAFFIC     |   |
           |   |              |  V             |   |
           |   |           +---------+         |   |
           |   +-----------| "I",    |---------+   |
           |               | неявное |             |
           +-------------->| отображ.|<------------+
       TRAFFIC и EXPIRY    +---------+  TRAFFIC и EXPIRY

Рисунок 16. Диаграмма состояний PCP.

NO_ENTRY

Недействительное состояние представляет отсутствующую запись (Entry) и является единственным при старте.

M-R

Запрос MAP.

P-R

Запрос PEER.

Запись отображения при создании по запросу MAP.

Запись отображения, созданная/поддерживаемая отображением PEER.

Неявное отображение, созданное исходящим пакетом от клиента (например, TCP SYN), или состояние, когда срок действия созданного PCP истек, но сохраняется активный трафик.

EXPIRY

Закончился срок действия отображения PEER или MAP.

TRAFFIC

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

NO_TRAFFIC

Указывает отсутствие трафика (TRAFFIC).

CLOSE_MSG

Протокольные сообщения от клиента или сервера для завершения сессии (например, TCP FIN или TCP RST) в соответствии с обработкой таких протокольных сообщений устройством NAT или МСЭ.

Примечания к рисунку.

«И» указывает, что для перехода нужно выполнение условий по обе стороны «и», «или» указывает, что достаточно любого из событий.
Переход из состояния M в состояние I зависит от реализации.

17 Вопросы развертывания

17.1 Фильтрация на входе

Как и неявные динамические отображения, создаваемые исходящими пакетами TCP SYN, явные динамические отображения PCP используют IP-адрес отправителя пакета в качестве внутреннего адреса для отображения. Поэтому следует применять входную фильтрацию [RFC2827] на пути между внутренним хостом и сервером PCP для предотвращения вставки обманных пакетов.

17.2 Квотирование отображений

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

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

Целью PCP является расширение возможности конечных узлов управлять своим состоянием NAT, более эффективная обработка и контроль ошибок отображений NAT по сравнению с имеющимися механизмами неявного отображения в устройствах NAT и МСЭ с учетом состояния. Защитной целью протокола PCP является ограничение возможности организации новых атак, нацеленных на отказ в обслуживании (DoS²⁹) и несанкционированное изменение состояния отображений. Одним из наиболее серьезных следствий несанкционированного изменения отображений является кража трафика. Все отображения, которые конкретный хост может создать с помощью неявных механизмов, считаются полномочными. Конфиденциальность отображений не является обязательной даже в случаях передачи сообщений PCP по путям, которые не будут использоваться отображенным трафиком.

18.1 Простая модель угроз

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

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

В простой модели угроз (Simple Threat Model) сервер PCP защищен, если он ограничен так, что не создает явных отображений, которые он будет настраивать неявно. В большинстве случаев это означает, что серверы PCP на устройствах NAT и МСЭ с учетом состояния, поддерживающие запросы PEER и MAP могут быть защищены в этой модели угроз, если (1) все их хосты находятся в одном административном домене (или могут быть безопасно распределены по разным административным доменам, как в случае DS-Lite B4), (2) явные отображения создаются с таким же сроком действия, как у неявных и (3) опция THIRD_PARTY не поддерживается. Серверы PCP могут также безопасно поддерживать MAP Opcode в этой модели угроз, если политика безопасности устройства, где работает сервер PCP, разрешает независимую от конечных точек фильтрацию неявных отображений.

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

18.1.1 Предполагаемые атаки

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

18.1.2 Примеры развертывания для простой модели угроз

В этом параграфе приведены два примера поддержки Simple Threat Model в реальных системах.

18.1.2.1 Развертывание домашнего шлюза

Аналогию со многими современными домашними шлюзами может обеспечить использование сервера PCP с ограничениями, описанными в параграфе 18.1.

18.2 Расширенная модель угроз

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

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

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

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

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

18.3 Остаточные угрозы

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

18.3.1 Отказ в обслуживании

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

Атакующий на пути между клиентом и сервером PCP может отбрасывать запросы и/или отклики PCP, или вводить фиктивные ошибки PCP — все это фактически создает DoS-атаку. Из-за таких действий клиент PCP может не узнать, что сервер PCP в действительности обработал запрос PCP. Передавая ошибку NO_RESOURCES, атакующий может вынудить клиента PCP некоторое время не передавать сообщений этому серверу. Для таких атак нет путей смягчения.

18.3.2 Фильтрация на входе

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

18.3.3 Захват отображения

В интервале между потерей состояния сервером PCP и получением значения Epoch Time меньше ожидаемого клиентом PCP возможен захват отображений клиента PCP другим хостом (с помощью явного или неявного динамического отображения). Это означает передачу входящего трафика другому хосту («кража»). Быстрое восстановление уменьшает этот интервал, но не предотвращает кражи совсем. Клиент PCP может уменьшит интервал, используя сравнительно короткий срок действия, однако это повышает объем трафика PCP. Данная угроза снижается использованием постоянного хранилища явных динамических отображения на сервере PCP (в результате не будет теряться состояние явных динамических отображений) или за счет предотвращения назначения прежнего внешнего адреса IP, протокола и порта другому хосту (например, путем использования другого пула адресов IP).

18.3.4 Атаки на обнаружение серверов

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

19 Согласование с IANA

Агентство IANA выполняет указанные ниже действия.

19.1 Номер порта

PCP использует порты 5350 и 5351, ранее выделенные IANA для NAT-PMP [RFC6886]. Сейчас эти порты переназначены PCP.

19.2 Коды операций

Агентство IANA создало реестр PCP Opcode с номерами 0-127 и начальными значениями, указанными в таблице.

Значение	Opcode
0	ANNOUNCE
1	MAP
2	PEER
3 — 31	Standards Action [RFC5226]	Стандартизация
32 — 63	Specification Required [RFC5226]	Нужна спецификация
96 — 126	Reserved for Private Use [RFC5226]	Резерв для приватного использования
127	Reserved, Standards Action [RFC5226]	Резерв для стандартизации

Значение 127 зарезервировано и может быть назначено по процедуре Standards Action [RFC5226]. Значения 3-31 могут быть назначены по процедуре Standards Action [RFC5226], 32-63 — по процедуре Specification Required [RFC5226], а 96-126 предназначены для приватного использования (Private Use) [RFC5226].

19.3 Коды результатов

Агентство IANA создало новый реестр для кодов результата PCP со значениями 0-255, начальные значения которого взяты из параграфа 7.4. Значение 255 зарезервировано и может быть назначено по процедуре Standards Action [RFC5226].

Значения 14-127 могут быть назначены по процедуре Standards Action [RFC5226], 128-191 — по процедуре Specification Required [RFC5226], а 191-254 предназначены для приватного использования [RFC5226].

19.4 Опции

Агентство IANA создало новый реестр для опций PCP со значениями 0-255, для каждого из которых имеется мнемоническое обозначение. Значения 0-127 обязательны для обработки, а 128-255 необязательны. Начальные значения опция для реестра взяты из раздела 13. Коды 0, 127 и 255 зарезервированы и могут быть назначены по процедуре Standards Action [RFC5226].

Дополнительные коды опций PCP 4-63 и 128-191 могут быть назначены по процедуре Standards Action [RFC5226], 64-95 и 192-223 — по процедуре Specification Required [RFC5226], а 96-126 и 224-254 оставлены для приватного использования [RFC5226].

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

Имя опции: <мнемоника>

Номер: <число>

Назначение: <текстовое описание>

Пригодность для Opcode: <список Opcode>

Размер: <правила для размера опции>

Может включаться в: <запрос/отклик/оба>

Максимальное число экземпляров: <значение>

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

Спасибо Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani, Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins, Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda Costa, Amit Jain и Wim Henderickx за их комментарии и рецензии.

Спасибо Simon Perreault за то, что он выделил взаимодействие динамических соединений с созданными PCP отображениями, а также за множество других комментариев.

Спасибо Francis Dupont за тщательное рецензирование спецификации, которое существенно улучшило протокол.

Спасибо T. S. Ranganathan за диаграмму состояний.

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

Спасибо Margaret Wasserman и Sam Hartman за написание раздела «Вопросы безопасности».

Спасибо авторам DHCPv6 за текст о повторах передачи.

21 Литература

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

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

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

[RFC2827] Ferguson, P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, May 2000.

[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

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

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

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

[RFC6056] Larsen, M. and F. Gont, «Recommendations for Transport-Protocol Port Randomization», BCP 156, RFC 6056, January 2011.

[proto_numbers] IANA, «Protocol Numbers», 2011, <http://www.iana.org/assignments/protocol-numbers>.

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

[IGDv1] UPnP Gateway Committee, «WANIPConnection:1», November 2001, <http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf>.

[L2NAT] Miles, D. and M. Townsley, «Layer2-Aware NAT», Work in Progress, March 2009.

[PCP-FAIL] Boucadair, M., Dupont, F., and R. Penno, «Port Control Protocol (PCP) Failure Scenarios», Work in Progress, August 2012.

[PNP-IGD-PCP] Boucadair, M., Penno, R., and D. Wing, «Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function», Work in Progress³⁰, December 2012.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3022] Srisuresh, P. and K. Egevang, «Traditional IP Network Address Translator (Traditional NAT)», RFC 3022, January 2001.

[RFC3581] Rosenberg, J. and H. Schulzrinne, «An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing», RFC 3581, August 2003.

[RFC3587] Hinden, R., Deering, S., and E. Nordmark, «IPv6 Global Unicast Address Format», RFC 3587, August 2003.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, March 2006.

[RFC4787] Audet, F. and C. Jennings, «Network Address Translation (NAT) Behavioral Requirements for Unicast UDP», BCP 127, RFC 4787, January 2007.

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

[RFC4960] Stewart, R., «Stream Control Transmission Protocol», RFC 4960, September 2007.

[RFC4961] Wing, D., «Symmetric RTP / RTP Control Protocol (RTCP)», BCP 131, RFC 4961, July 2007.

[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, «NAT Behavioral Requirements for TCP», BCP 142, RFC 5382, October 2008.

[RFC6092] Woodyatt, J., «Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service», RFC 6092, January 2011.

[RFC6145] Li, X., Bao, C., and F. Baker, «IP/ICMP Translation Algorithm», RFC 6145, April 2011.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, «Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers», RFC 6146, April 2011.

[RFC6296] Wasserman, M. and F. Baker, «IPv6-to-IPv6 Network Prefix Translation», RFC 6296, June 2011.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, «Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion», RFC 6333, August 2011.

[RFC6619] Arkko, J., Eggert, L., and M. Townsley, «Scalable Operation of Address Translators with Per-Interface Bindings», RFC 6619, June 2012.

[RFC6763] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», RFC 6763, February 2013.

[RFC6886] Cheshire, S. and M. Krochmal, «NAT Port Mapping Protocol (NAT-PMP)», RFC 6886, April 2013.

[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, «Common Requirements for Carrier-Grade NATs (CGNs)», BCP 127, RFC 6888, April 2013.

[SCTPNAT] Stewart, R., Tuexen, M., and I. Ruengeler, «Stream Control Transmission Protocol (SCTP) Network Address Translation», Work in Progress, February 2013.

Приложение A Переход от NAT-PMP

Протокол PCP является преемником протокола отображения портов NAT-PMP³¹ [RFC6886] и использует близкую семантику, концепции и форматы пакетов. Протоколы NAT-PMP и PCP работают через одинаковые порты и применяют средства согласования версий NAT-PMP и PCP для определения используемой версии. В этом приложении описано, как можно реализовать упорядоченный переход от NAT-PMP к PCP.

Клиенту, поддерживающему NAT-PMP и PCP, следует передавать свои запросы в формате PCP, которые будут приниматься сервером NAT-PMP или PCP. Сервер NAT-PMP будет возвращать отклик UNSUPP_VERSION, как указано в спецификации NAT-PMP [RFC6886], который заставит клиента вернуться к протоколу NAT-PMP и повторить запрос в формате NAT-PMP. Сервер PCP будет передавать отклик в соответствии с этим документом и обработка будет продолжаться как обычно.

Сервер PCP, поддерживающий одновременно NAT-PMP и PCP, может обслуживать запросы в любом формате. Первый октет в пакете указывает NAT-PMP (0) или PCP (не 0).

Шлюз, поддерживающий лишь PCP, при получении запроса NAT-PMP (0 в первом октете) будет считать этот запрос несоответствием версий. Обычная обработка PCP выдает отклики PCP, совместимые с NAT-PMP, без какой-либо специальной обработки на сервере PCP.

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

Dan Wing (editor)

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, California 95134

USA

EMail: dwing@cisco.com

Stuart Cheshire

Apple Inc.

1 Infinite Loop

Cupertino, California 95014

USA

Phone: +1 408 974 3207

EMail: cheshire@apple.com

Mohamed Boucadair

France Telecom

Rennes 35000

France

EMail: mohamed.boucadair@orange.com

Reinaldo Penno

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, California 95134

USA

EMail: repenno@cisco.com

Paul Selkirk

Internet Systems Consortium

950 Charter Street

Redwood City, California 94063

USA

EMail: pselkirk@isc.org

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

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

nmalykh@gmail.com

1Network Address Translator — транслятор сетевых адресов.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Network Address Translator IPv6/IPv4 — транслятор адресов IPv6/IPv4.

5Network Address Translator IPv4/IPv4 — транслятор адресов IPv4/IPv4.

6Carrier-Grade NAT — транслятор адресов операторского уровня.

7Customer Premises Equipment — пользовательское оборудование.

8DNS-Based Service Discovery.

9Application Layer Gateway.

10Stream Control Transmission Protocol.

11Datagram Congestion Control Protocol.

12Resource Reservation Protocol.

13IP Encapsulating Security Payload.

14Universal Plug and Play Internet Gateway Device.

15Type-Length-Value — тип-размер-значение.

16Global Unicast Address — глобальный индивидуальный адрес.

17Unique Local Address — уникальный локальный адрес.

18Symmetric Response Routing — симметричная маршрутизация откликов.

19Endpoint-independent mapping — независимое от конечной точки отображение.

20Endpoint-dependent mapping — зависящее от конечной точки отображение.

21Endpoint-independent filtering.

22Endpoint-dependent filtering.

23Access control list.

24В оригинале ошибочно указано 96 и 0. См. https://www.rfc-editor.org/errata/eid3891. Прим. перев.

25В оригинале это предложение отсутствует. См. https://www.rfc-editor.org/errata/eid3891. Прим. перев.

26В оригинале этот абзац был сформулирован нечетко. См. https://www.rfc-editor.org/errata/eid3621. Прим. перев.

27Endpoint-independent mapping — независимое от конечной точки отображение.

28Endpoint-dependent mapping — зависимое от конечной точки отображение.

29Denial-of-service — отказ в обслуживании.

30Работа опубликована в RFC 6970. Прим. перев.

31NAT Port Mapping Protocol.

Рубрика: RFC | Комментарии отключены

Архитектура eBPF

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

Архитектура eBPF

PDF

Приведенный ниже включаемый файл (include) с переведенными на русский язык комментариями содержит определения пакета ebpf в одноименной модели. Файл ebpf.p4 размещается в каталоге p4include пакета p4c и доступен по ссылке.

/*
Copyright 2013-present Barefoot Networks, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0 

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

#ifndef _EBPF_MODEL_P4_
#define _EBPF_MODEL_P4_

#include <core.p4>

/**
   Массив счетчиков представляет собой плотный (dense) или разреженный 
   (sparse) массив 32-битовых целых чисел без знака, видимый плоскости
   управления как отображение EBPF (массив или хэш). Каждый счетчик 
   адресуется 32-битовым индексом. Счетчики могут инкрементироваться
   лишь плоскостью данных, но могут считываться и сбрасываться 
   плоскостью управления.
 */
extern CounterArray {
    /** Выделяется массив счетчиков.
     * @param max_index  Максимальный поддерживаемый индекс счетчика.
     * @param sparse     Массив счетчиков считается разреженным. */
    CounterArray(bit<32> max_index, bool sparse);
    /** Инкрементирование счетчика с заданным индексом. */
    void increment(in bit<32> index);
    /** Увеличение значения счетчика с заданным индексом. */
    void add(in bit<32> index, in bit<32> value);
}

/*
 Каждая таблица должна иметь свойство реализации array_table или hash_table.
*/

/**
 Свойство реализации таблиц, показывающее, что таблицу нужно реализовать с 
 использованием отображения в массив EBPF. Однако для таблиц с сопоставлением
 LPM свойство реализации служит лишь для размера и используемая таблица 
 является префиксным деревом LPM (trie).
*/
extern array_table {
    /// @param size Максимальное число записей в таблице.
    array_table(bit<32> size);
}

/**
 Свойство реализации для таблиц, показывающее, что таблицу нужно реализовать с 
 использованием отображения в хэш EBPF.
*/
extern hash_table {
    /// @param size: maximum number of entries in table
    hash_table(bit<32> size);
}

/* Архитектурная модель для архитектуры фильтрации пакетов EBPF */

parser parse<H>(packet_in packet, out H headers);
control filter<H>(inout H headers, out bool accept);

package ebpfFilter<H>(parse<H> prs,
                      filter<H> filt);

#endif

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

nmalykh@protocols.ru

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

RFC 6824 TCP Extensions for Multipath Operation with Multiple Addresses

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

Заменен RFC 8684.

Рубрика: RFC | Комментарии отключены