RFC 9587 YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)

Internet Engineering Task Force (IETF)                         A. Lindem
Request for Comments: 9587                       LabN Consulting, L.L.C.
Category: Standards Track                                      S. Palani
ISSN: 2070-1721                                                Microsoft
                                                                   Y. Qu
                                                  Futurewei Technologies
                                                               June 2024

YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)

Модель данных YANG для расширенных анонсов LSA в OSPFv3

PDF

Аннотация

В этом документе определена модель данных YANG, дополняющая модель IETF OSPF YANG (RFC 9129) для поддержки расширяемости анонсов состояния каналов (Link State Advertisement или LSA) в OSPFv3, определённой в RFC 8362. OSPFv3 Extended LSA обеспечивают на основе TLV расширения типов LSA, определённых в RFC 5340.

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

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

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

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

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

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

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

1. Обзор

Язык определения данных YANG [RFC7950] служит для задания содержимого концептуального хранилища данных, которое позволяет управлять сетевыми устройствами с помощью NETCONF [RFC6241]. YANG подходит и для других ситуаций, таких как привязка к другим интерфейсам (например, RESTCONF [RFC8040]) и отличное от XML кодирование (например, JSON). Кроме того, модели данных YANG могут служить основой для реализации таких интерфейсов, как командный (Command-Line Interface или CLI) или программный API.

В этом документе задана модель данных YANG, дополняющая модель IETF OSPF YANG [RFC9129], которая сама дополняет [RFC8349], для поддержки конфигурации и рабочих состояний расширенных анонсов состояния каналов OSPFv3 (LSA), определённых в [RFC8362].

Заданный здесь модуль YANG соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].

2. Диаграммы деревьев

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

3. OSPFv3 Extended LSA

Этот документ определяет модель данных YANG для OSPFv3 Extended LSA, дополняя базовую модель OSPF [RFC9129] для поддержки расширения OSPFv3 LSA [RFC8362]. Расширенные OSPFv3 LSA поддерживают анонсы состояния каналов на основе TLV в соответствии с [RFC5340].

Модуль YANG OSPFv3 Extended LSA требует поддержки базовой модели OSPF, определяющей базовые состояния и конфигурацию OSPF. Модуль YANG OSPF дополняет модель данных YANG ietf-routing, заданную в [RFC8349]. Дополнения модуля YANG ietf-ospfv3-extended-lsa обеспечивают поддержку глобальной конфигурации, конфигурации областей (area) и добавление OSPFv3 Extended LSA к рабочему состоянию базы состояний каналов (Link State Database или LSDB).

   module: ietf-ospfv3-extended-lsa

     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf:
       +--rw extended-lsa-support?   boolean
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:areas
               /ospf:area:
       +--rw extended-lsa-support?   boolean
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
               /ospf:interfaces/ospf:interface/ospf:database
               /ospf:link-scope-lsa-type/ospf:link-scope-lsas
               /ospf:link-scope-lsa/ospf:version/ospf:ospfv3/ospf:ospfv3
               /ospf:body:
       +--ro e-link
          +--ro rtr-priority?   uint8
          +--ro lsa-options
          |  +--ro lsa-options*   identityref
          +--ro e-link-tlvs* []
             +--ro unknown-tlv
             |  +--ro type?     uint16
             |  +--ro length?   uint16
             |  +--ro value?    yang:hex-string
             +--ro intra-prefix-tlv
             |  +--ro metric?           ospf:ospf-metric
             |  +--ro prefix?           inet:ip-prefix
             |  +--ro prefix-options
             |  |  +--ro prefix-options*   identityref
             |  +--ro sub-tlvs* []
             |     +--ro unknown-sub-tlv
             |        +--ro type?     uint16
             |        +--ro length?   uint16
             |        +--ro value?    yang:hex-string
             +--ro ipv6-link-local-addr-tlv
             |  +--ro link-local-address?   inet:ipv6-address
             |  +--ro sub-tlvs* []
             |     +--ro unknown-sub-tlv
             |        +--ro type?     uint16
             |        +--ro length?   uint16
             |        +--ro value?    yang:hex-string
             +--ro ipv4-link-local-addr-tlv
                +--ro link-local-address?   inet:ipv4-address
                +--ro sub-tlvs* []
                   +--ro unknown-sub-tlv
                      +--ro type?     uint16
                      +--ro length?   uint16
                      +--ro value?    yang:hex-string
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
               /ospf:database/ospf:area-scope-lsa-type
               /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
               /ospf:ospfv3/ospf:ospfv3/ospf:body:
       +--ro e-router
       |  +--ro router-bits
       |  |  +--ro rtr-lsa-bits*   identityref
       |  +--ro lsa-options
       |  |  +--ro lsa-options*   identityref
       |  +--ro e-router-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro link-tlv
       |        +--ro interface-id?            uint32
       |        +--ro neighbor-interface-id?   uint32
       |        +--ro neighbor-router-id?      rt-types:router-id
       |        +--ro type?                    ospf:router-link-type
       |        +--ro metric?                  ospf:ospf-link-metric
       |        +--ro sub-tlvs* []
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-network
       |  +--ro lsa-options
       |  |  +--ro lsa-options*   identityref
       |  +--ro e-network-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro attached-router-tlv
       |        +--ro adjacent-neighbor-router-id*   rt-types:router-id
       +--ro e-nssa
       |  +--ro e-external-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro external-prefix-tlv
       |        +--ro flags
       |        |  +--ro ospfv3-e-external-prefix-bits*   identityref
       |        +--ro metric?           ospf:ospf-metric
       |        +--ro prefix?           inet:ip-prefix
       |        +--ro prefix-options
       |        |  +--ro prefix-options*   identityref
       |        +--ro sub-tlvs* []
       |           +--ro ipv6-fwd-addr-sub-tlv
       |           |  +--ro forwarding-address?   inet:ipv6-address
       |           +--ro ipv4-fwd-addr-sub-tlv
       |           |  +--ro forwarding-address?   inet:ipv4-address
       |           +--ro route-tag-sub-tlv
       |           |  +--ro route-tag?   uint32
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-inter-area-prefix
       |  +--ro e-inter-prefix-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro inter-prefix-tlv
       |        +--ro metric?           ospf:ospf-metric
       |        +--ro prefix?           inet:ip-prefix
       |        +--ro prefix-options
       |        |  +--ro prefix-options*   identityref
       |        +--ro sub-tlvs* []
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-inter-area-router
       |  +--ro e-inter-router-tlvs* []
       |     +--ro unknown-tlv
       |     |  +--ro type?     uint16
       |     |  +--ro length?   uint16
       |     |  +--ro value?    yang:hex-string
       |     +--ro inter-router-tlv
       |        +--ro lsa-options
       |        |  +--ro lsa-options*   identityref
       |        +--ro metric?                  ospf:ospf-metric
       |        +--ro destination-router-id?   rt-types:router-id
       |        +--ro sub-tlvs* []
       |           +--ro unknown-sub-tlv
       |              +--ro type?     uint16
       |              +--ro length?   uint16
       |              +--ro value?    yang:hex-string
       +--ro e-intra-area-prefix
          +--ro referenced-ls-type?         uint16
          +--ro referenced-link-state-id?   uint32
          +--ro referenced-adv-router?      rt-types:router-id
          +--ro e-intra-prefix-tlvs* []
             +--ro unknown-tlv
             |  +--ro type?     uint16
             |  +--ro length?   uint16
             |  +--ro value?    yang:hex-string
             +--ro intra-prefix-tlv
                +--ro metric?           ospf:ospf-metric
                +--ro prefix?           inet:ip-prefix
                +--ro prefix-options
                |  +--ro prefix-options*   identityref
                +--ro sub-tlvs* []
                   +--ro unknown-sub-tlv
                      +--ro type?     uint16
                      +--ro length?   uint16
                      +--ro value?    yang:hex-string
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/ospf:ospf/ospf:database
               /ospf:as-scope-lsa-type/ospf:as-scope-lsas
               /ospf:as-scope-lsa/ospf:version/ospf:ospfv3/ospf:ospfv3
               /ospf:body:
       +--ro e-as-external
          +--ro e-external-tlvs* []
             +--ro unknown-tlv
             |  +--ro type?     uint16
             |  +--ro length?   uint16
             |  +--ro value?    yang:hex-string
             +--ro external-prefix-tlv
                +--ro flags
                |  +--ro ospfv3-e-external-prefix-bits*   identityref
                +--ro metric?           ospf:ospf-metric
                +--ro prefix?           inet:ip-prefix
                +--ro prefix-options
                |  +--ro prefix-options*   identityref
                +--ro sub-tlvs* []
                   +--ro ipv6-fwd-addr-sub-tlv
                   |  +--ro forwarding-address?   inet:ipv6-address
                   +--ro ipv4-fwd-addr-sub-tlv
                   |  +--ro forwarding-address?   inet:ipv4-address
                   +--ro route-tag-sub-tlv
                   |  +--ro route-tag?   uint32
                   +--ro unknown-sub-tlv
                      +--ro type?     uint16
                      +--ro length?   uint16
                      +--ro value?    yang:hex-string

4. Модуль YANG OSPFv3 Extended LSA

[RFC6991] и [RFC8294] не упоминаются в этом документе, но ссылки на них даны в модуле ietf-ospfv3-extended-lsa.yang.

   <CODE BEGINS> file "ietf-ospfv3-extended-lsa@2024-06-07.yang"
   module ietf-ospfv3-extended-lsa {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ospfv3-extended-lsa";
     prefix ospfv3-e-lsa;

     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing
          Management (NMDA Version)";
     }
     import ietf-ospf {
       prefix ospf;
       reference
         "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     organization
       "IETF LSR - Link State Routing Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/lsr/> 
        WG List:  <mailto:lsr@ietf.org> 

        Author:   Acee Lindem
                  <mailto:acee.ietf@gmail.com> 
        Author:   Sharmila Palani
                  <mailto:sharmila.palani@microsoft.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.ietf@gmail.com>"; 
     description
       "Этот модуль YANG определяет конфигурацию и рабочее состояние
        OSPFv3 Extended LSA, общие для реализаций всех производителей.
        Семантика и кодирование OSPFv3 Extended LSA описаны в RFC 8362. 
        OSPFv3 Extended LSA обеспечивают на основе TLV расширения базовых 
        типов LSA, определённых в RFC 5340.

        Модуль YANG соответствует архитектуре NMDA (RFC 8342).

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

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

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

     reference
       "RFC 9587: YANG Data Model for OSPFv3 Extended Link State
        Advertisements (LSAs)";

     revision 2024-06-07 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9587: YANG Data Model for OSPFv3 Extended Link State
          Advertisements (LSAs)";
     }

     /*
      * Идентификаторы типов OSPFv3 Extended LSA
      */

     identity ospfv3-e-router-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Router-LSA - тип 0xA021.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.1";
     }

     identity ospfv3-e-network-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Network-LSA - тип 0xA022.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.2";
     }

     identity ospfv3-e-summary-lsa-type {
       base ospf:ospfv3-lsa-type;
       description
         "Типы OSPFv3 Extended Summary LSA 
          E-Inter-Area-Prefix-LSA and E-Inter-Area-Router-LSA.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграфы 4.3 и 4.4";
     }

     identity ospfv3-e-inter-area-prefix-lsa {
       base ospfv3-e-summary-lsa-type;
       description
         "OSPFv3 E-Inter-Area-Prefix-LSA - тип 0xA023.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.3";
     }

     identity ospfv3-e-inter-area-router-lsa {
       base ospfv3-e-summary-lsa-type;
       description
         "OSPFv3 E-Inter-Area-Router-LSA - тип 0xA024.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.4";
     }

     identity ospfv3-e-external-lsa-type {
       base ospf:ospfv3-lsa-type;
       description
         "Типы OSPFv3 Extended External LSA 
          E-AS-External-LSA и E-NSSA-LSA (NSSA- это 
          Not-So-Stubby-Area — не совсем тупиковая область).";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграфы 4.5 и 4.6";
     }

     identity ospfv3-e-as-external-lsa {
       base ospfv3-e-external-lsa-type;
       description
         "OSPFv3 E-AS-External-LSA - тип 0xC025.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.5";
     }

     identity ospfv3-e-nssa-lsa {
       base ospfv3-e-external-lsa-type;
       description
         "OSPFv3 E-NSSA-LSA - тип 0xA027.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.6";
     }

     identity ospfv3-e-link-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Link-LSA - тип 0x8028.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.7";
     }

     identity ospfv3-e-intra-area-prefix-lsa {
       base ospf:ospfv3-lsa-type;
       description
         "OSPFv3 E-Intra-Area-Prefix-LSA - тип 0xA029.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4.8";
     }

     identity ospfv3-e-prefix-option {
       description
         "Базовые идентификаторы для опций префикса OSPFv3.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1";
     }

     identity nu-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс следует исключать
          из расчётов IPv6.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity la-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс фактически является
          адресом IPv6 анонсирующего маршрутизатора.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity p-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс NSSA следует транслировать
          в E-AS-External-LSA и анонсировать транслирующему NSSA BR.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity dn-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс E-Inter-Area-Prefix-LSA или
          E-AS-External-LSA анонсируется как префикс L3VPN.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity n-bit {
       base ospfv3-e-prefix-option;
       description
         "При установленном флаге префикс является адресом хоста,
          который идентифицирует анонсирующий маршрутизатор.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.1
          RFC 5340: OSPF for IPv6, Приложение A.4.1.1";
     }

     identity ospfv3-e-external-prefix-option {
       description
         "Базовый идентификатор для опций внешнего префикса OSPFv3.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.6";
     }

     identity e-bit {
       base ospfv3-e-external-prefix-option;
       description
         "При установленном флаге E заданная метрика является внешней
          метрикой типа 2. Это означает, что метрика считается больше,
          чем у любого пути внутри AS. Сброшенный бит E указывает 
          внешнюю метрику типа 1. Это означает, что она выражается в 
          таких же единицах, как и в других LSA (как стоимость
          интерфейса в Router-LSA).";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.6";
     }

     grouping unknown-sub-tlv {
       description
         "Неизвестная группа TLV.";
       container unknown-sub-tlv {
         uses ospf:tlv;
         description
           "Неизвестный суб-TLV внешнего TLV.";
       }
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 6.3";
     }

     grouping ospfv3-lsa-prefix {
       description
         "Префикс OSPFv3 LSA.";
       leaf prefix {
         type inet:ip-prefix;
         description
           "LSA prefix.";
       }
       container prefix-options {
         leaf-list prefix-options {
           type identityref {
             base ospfv3-e-prefix-option;
           }
           description
             "Список флагов опций префикса OSPFv3, содержащий
              идентификаторы опций OSPFv3, установленных для
              префикса OSPFv3.";
         }
         description
           "Опции префикса.";
         reference
           "RFC 8362:  OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 3.1";
       }
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3";
     }

     grouping external-prefix-tlv {
       container external-prefix-tlv {
         description
           "External-Prefix TLV.";
         container flags {
           leaf-list ospfv3-e-external-prefix-bits {
             type identityref {
               base ospfv3-e-external-prefix-option;
             }
             description
               "Список битов OSPFv3 External-Prefix TLV.";
           }
           description
             "Флаги внешнего префикса.";
         }
         leaf metric {
           type ospf:ospf-metric;
           description
             "Метрика внешнего префикса.";
         }
         uses ospfv3-lsa-prefix;
         list sub-tlvs {
           description
             "Суб-TLV External-Prefix TLV.";
           container ipv6-fwd-addr-sub-tlv {
             description
               "Суб-TLV IPv6-Forwarding-Address для E-AS-External-LSA
                и E-NSSA-LSA для семейства адресов IPv6.";
             leaf forwarding-address {
               type inet:ipv6-address;
               description
                 "Адрес пересылки IPv6.";
             }
             reference
               "RFC 8362: OSPFv3 Link State Advertisement (LSA)
                Extensibility, параграф 3.10";
           }
           container ipv4-fwd-addr-sub-tlv {
             description
               "Суб-TLV IPv4-Forwarding-Address для E-AS-External-LSA
                и E-NSSA-LSA для семейства адресов IPv4.";
             leaf forwarding-address {
               type inet:ipv4-address;
               description
                 "Адрес пересылки IPv4.";
             }
             reference
               "RFC 8362: OSPFv3 Link State Advertisement (LSA)
                Extensibility, параграф 3.11";
           }
           container route-tag-sub-tlv {
             description
               "Суб-TLV Route-Tag.";
             leaf route-tag {
               type uint32;
               description
                 "Тег маршрута.";
             }
             reference
               "RFC 8362: OSPFv3 Link State Advertisement (LSA)
                Extensibility, параграф 3.12";
           }
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа External-Prefix TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.6";
     }

     grouping intra-area-prefix-tlv {
       container intra-prefix-tlv {
         description
           "Intra-Area-Prefix-LSA TLV.";
         leaf metric {
           type ospf:ospf-metric;
           description
             "Метрика внутриобластного префикса.";
         }
         uses ospfv3-lsa-prefix;
         list sub-tlvs {
           description
             "Суб-TLV Intra-Area-Prefix TLV.";
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа Intra-Area-Prefix TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.7";
     }

     grouping ipv6-link-local-addr-tlv {
       container ipv6-link-local-addr-tlv {
         description
           "IPv6 Link-Local Address TLV.";
         leaf link-local-address {
           type inet:ipv6-address;
           description
             "Адрес IPv6 Link-Local.";
         }
         list sub-tlvs {
           description
             "Суб-TLV IPv6 Link-Local Address TLV.";
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа IPv6 Link-Local Address TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.8";
     }

     grouping ipv4-link-local-addr-tlv {
       container ipv4-link-local-addr-tlv {
         description
           "IPv4 Link-Local Address TLV.";
         leaf link-local-address {
           type inet:ipv4-address;
           description
             "Адрес IPv4 Link-Local.";
         }
         list sub-tlvs {
           description
             "Суб-TLV IPv4 Link-Local Address TLV.";
           uses unknown-sub-tlv;
         }
       }
       description
         "Группа IPv4 Link-Local Address TLV.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 3.9";
     }

     /* Конфигурация */

     augment "/rt:routing/rt:control-plane-protocols"
           + "/rt:control-plane-protocol/ospf:ospf" {
       when "../rt:type = 'ospf:ospfv3'" {
         description
           "Дополняет протокол маршрутизации OSPFv3.";
       }
       description
         "Дополняет конфигурацию на уровне экземпляра OSPFv3 поддержкой
          Extended LSA. При включённой поддержке будут анонсироваться
          OSPFv3 Extended LSA, и не будут передаваться OSPFv3 Legacy
          LSA, которые анонсируются при отключённой поддержке. Однако 
          OSPFv3 Extended LSA могут анонсироваться в Extended LSA Sparse
          Mode для поддержки постепенного внедрения, как описано в
          параграфе 6.2 of RFC 8362.";
       leaf extended-lsa-support {
         type boolean;
         default "false";
         description
           "Включает поддержку OSPFv3 Extended LSA для домена OSPFv3.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, Приложение A - Global Configuration Support";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf:ospf/ospf:"
           + "areas/ospf:area" {
       when "../../../rt:type = 'ospf:ospfv3'" {
         description
           "Дополняет конфигурацию протокола OSPFv3 на уровне области.";
       }
       description
         "Дополняет конфигурацию протокола OSPFv3 на уровне области
          поддержкой Extended LSA.";
       leaf extended-lsa-support {
         type boolean;
         must "derived-from(../ospf:area-type,'stub-nssa-area') or "
            + "(current() = 'true') or "
            + "(../../../extended-lsa-support = 'false')" {
           description
             "Для обычных областей (области с лавинной рассылкой LSA
              уровня AS) отключение AreaExtendedLSASupport на уровне
              области запрещено при включении ExtendedLSASupport на
              уровне экземпляра. Анонсы E-AS-External-LSA рассылаются
              лавинно во все обычные области OSPFv3 (не тупиковые и не
              NSSA), поэтому отключение поддержки на уровне области
              невозможно.";
         }
         description
           "Дополняет конфигурацию протокола OSPFv3 на уровне области
            поддержкой Extended LSA. При включённой поддержке будут
            анонсироваться OSPFv3 Extended LSA и не будут передаваться 
            OSPFv3 Legacy LSA, которые анонсируются при отключённой 
            поддержке. Однако OSPFv3 Extended LSA могут анонсироваться
            в Extended LSA Sparse Mode для поддержки постепенного 
            внедрения, как описано в параграфе 6.2 of RFC 8362. По
            умолчанию статус поддержки Extended LSA наследуется из
            конфигурации на уровне экземпляра.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, Приложение B - Area Configuration Support";
       }
     }

     /*
      * Дополнения базы состояний каналов (Link State Database или LSDB)
      */

     augment "/rt:routing/"
           + "rt:control-plane-protocols/rt:control-plane-protocol/"
           + "ospf:ospf/ospf:areas/ospf:area/"
           + "ospf:interfaces/ospf:interface/ospf:database/"
           + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/"
           + "ospf:link-scope-lsa/ospf:version/ospf:ospfv3/"
           + "ospf:ospfv3/ospf:body" {
       when "../../../../../../../../../../../"
          + "rt:type = 'ospf:ospfv3'" {
         description
           "Это дополнение применимо лишь к OSPFv3.";
       }
       description
         "Добавляет OSPFv3 Link-scoped Extended LSA к рабочему
          состоянию LSDB на интерфейсе.";
       container e-link {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-link-lsa'" {
           description
             "Применимо лишь к E-Link-LSA.";
         }
         description
           "E-Link-LSA contents.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.7";
         leaf rtr-priority {
           type uint8;
           description
             "Приоритет маршрутизатора для интерфейса.";
         }
         uses ospf:ospfv3-lsa-options;
         list e-link-tlvs {
           description
             "E-Link-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Link TLV.";
           }
           uses intra-area-prefix-tlv;
           uses ipv6-link-local-addr-tlv;
           uses ipv4-link-local-addr-tlv;
         }
       }
     }

     augment "/rt:routing/"
           + "rt:control-plane-protocols/rt:control-plane-protocol/"
           + "ospf:ospf/ospf:areas/ospf:area/ospf:database/"
           + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/"
           + "ospf:area-scope-lsa/ospf:version/ospf:ospfv3/"
           + "ospf:ospfv3/ospf:body" {
       when "../../../../../../../../../"
          + "rt:type = 'ospf:ospfv3'" {
         description
           "Это дополнение применимо лишь к OSPFv3.";
       }
       description
         "Добавляет OSPFv3 Area-scoped Extended LSA к рабочему
          состоянию LSDB для области.";
       reference
         "RFC 8362: OSPFv3 Link State Advertisement (LSA)
          Extensibility, параграф 4";
       container e-router {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-router-lsa'" {
           description
             "Применимо лишь к OSPFv3 E-Router-LSA.";
         }
         description
           "Содержимое OSPFv3 E-Router-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.1";
         uses ospf:ospf-router-lsa-bits;
         uses ospf:ospfv3-lsa-options;
         list e-router-tlvs {
           description
             "E-Router-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Router TLV.";
           }
           container link-tlv {
             description
               "E-Router-LSA TLV.";
             leaf interface-id {
               type uint32;
               description
                 "Идентификатор интерфейса для канала.";
             }
             leaf neighbor-interface-id {
               type uint32;
               description
                 "Идентификатор интерфейса соседа по каналу.";
             }
             leaf neighbor-router-id {
               type rt-types:router-id;
               description
                 "Идентификатор соседнего маршрутизатора на канале.";
             }
             leaf type {
               type ospf:router-link-type;
               description
                 "Тип канала: 1 - «точка-точка»
                              2 - канал в транзитную сеть
                              3 - канал в тупиковую сеть
                              4 - виртуальный канал.";
             }
             leaf metric {
               type ospf:ospf-link-metric;
               description
                 "Метрика канала.";
             }
             list sub-tlvs {
               description
                 "Суб-TLV Link TLV.";
               uses unknown-sub-tlv;
             }
           }
         }
       }
       container e-network {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-network-lsa'" {
           description
             "Применимо лишь к E-Network-LSA.";
         }
         description
           "Содержимое E-Network-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.2";
         uses ospf:ospfv3-lsa-options;
         list e-network-tlvs {
           description
             "E-Network-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Network TLV.";
           }
           container attached-router-tlv {
             description
               "Attached-Routers TLV.";
             leaf-list adjacent-neighbor-router-id {
               type rt-types:router-id;
               description
                 "Идентификатор смежного маршрутизатора.";
             }
           }
         }
       }
       container e-nssa {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-nssa-lsa'" {
           description
             "Применимо лишь к E-NSSA-LSA.";
         }
         description
           "Содержимое E-NSSA-LSA.";
         list e-external-tlvs {
           description
             "E-NSSA-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-External TLV.";
           }
           uses external-prefix-tlv;
         }
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.6";
       }
       container e-inter-area-prefix {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-inter-area-prefix-lsa'" {
           description
             "Применимо лишь к E-Inter-Area-Prefix-LSA.";
         }
         description
           "Содержимое E-Inter-Area-Prefix-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.3";
         list e-inter-prefix-tlvs {
           description
             "E-Inter-Area-Prefix-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Inter-Area-Prefix TLV.";
           }
           container inter-prefix-tlv {
             description
               "Неизвестный E-Inter-Area-Prefix-LSA TLV.";
             leaf metric {
               type ospf:ospf-metric;
               description
                 "Метрика внутриобластного префикса.";
             }
             uses ospfv3-lsa-prefix;
             list sub-tlvs {
               description
                 "Суб-TLV Inter-Area-Prefix TLV.";
               uses unknown-sub-tlv;
             }
           }
         }
       }
       container e-inter-area-router {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-inter-area-router-lsa'" {
           description
             "Применимо лишь к E-Inter-Area-Router-LSA.";
         }
         description
           "Содержимое E-Inter-Area-Router-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.4";
         list e-inter-router-tlvs {
           description
             "E-Inter-Area-Router-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Inter-Area-Router TLV.";
           }
           container inter-router-tlv {
             description
               "Неизвестный E-Inter-Area-Router-LSA TLV.";
             uses ospf:ospfv3-lsa-options;
             leaf metric {
               type ospf:ospf-metric;
               description
                 "Метрика межобластного маршрутизатора.";
             }
             leaf destination-router-id {
               type rt-types:router-id;
               description
                 "Идентификатор целевого маршрутизатора.";
             }
             list sub-tlvs {
               description
                 "Inter-Area-Router TLV sub-TLV.";
               uses unknown-sub-tlv;
             }
           }
         }
       }
       container e-intra-area-prefix {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-intra-area-prefix-lsa'" {
           description
             "Применимо лишь к E-Intra-Area-Prefix-LSA.";
         }
         description
           "Содержимое E-Intra-Area-Prefix-LSA.";
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.8";
         leaf referenced-ls-type {
           type uint16;
           description
             "Тип Referenced Link State.";
         }
         leaf referenced-link-state-id {
           type uint32;
           description
             "Referenced Link State ID.";
         }
         leaf referenced-adv-router {
           type rt-types:router-id;
           description
             "Анонсирующий маршрутизатор.";
         }
         list e-intra-prefix-tlvs {
           description
             "E-Intra-Area-Prefix-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-Intra-Area-Prefix TLV.";
           }
           uses intra-area-prefix-tlv;
         }
       }
     }

     augment "/rt:routing/"
           + "rt:control-plane-protocols/rt:control-plane-protocol/"
           + "ospf:ospf/ospf:database/"
           + "ospf:as-scope-lsa-type/ospf:as-scope-lsas/"
           + "ospf:as-scope-lsa/ospf:version/ospf:ospfv3/"
           + "ospf:ospfv3/ospf:body" {
       when "../../../../../../../"
          + "rt:type = 'ospf:ospfv3'" {
         description
           "Это дополнение действительно лишь для OSPFv3.";
       }
       description
         "Это дополнение добавляет OSPFv3 AS-scoped Extended LSA к
          рабочему состоянию для LSDB на уровне экземпляра AS.";
       container e-as-external {
         when "../../ospf:header/ospf:type = "
            + "'ospfv3-e-lsa:ospfv3-e-as-external-lsa'" {
           description
             "Применимо лишь к E-AS-External-LSA.";
         }
         description
           "Содержимое E-AS-External-LSA.";
         list e-external-tlvs {
           description
             "E-AS-External-LSA TLV.";
           container unknown-tlv {
             uses ospf:tlv;
             description
               "Неизвестный E-External TLV.";
           }
           uses external-prefix-tlv;
         }
         reference
           "RFC 8362: OSPFv3 Link State Advertisement (LSA)
            Extensibility, параграф 4.5";
       }
     }
   }
   <CODE ENDS>

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В заданном здесь модуле ietf-ospfv3-extended-lsa.yang определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/ospf:ospf/extended-lsa-support

/ospf:ospf/ospf:areas/ospf:area/extended-lsa-support

Способность управлять поддержкой OSPFv3 Extended LSA может приводить к атакам на службы (Denial-of-Service или DoS), поскольку маршрутизаторы OSPFv3 будут использовать для расчётов OSPFv3 SPF исключительно OSPFv3 Extended LSA, либо OSPFv3 Legacy LSA. Использование маршрутизаторами OSPFv3 разных типов LSA приведёт к неполной доступности и возможному разделению на части домена маршрутизации OSPFv3. Дополнительные сведения о совместимости OSPFv3 Extended LSA приведены в разделе 6 [RFC8362].

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

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

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

В соответствии с этим документом агентство IANA внесло URI в реестр IETF XML Registry [RFC3688]

   URI:  urn:ietf:params:xml:ns:yang:ietf-ospfv3-extended-lsa
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

В соответствии с этим документом агентство IANA зарегистрировало модуль YANG в реестре YANG Module Names [RFC6020]

   Name:  ietf-ospfv3-extended-lsa
   Maintained by IANA:  N
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ospfv3-extended-lsa
   Prefix:  ospfv3-e-lsa
   Reference:  RFC 9587

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

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

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

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, «OSPF for IPv6», RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

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

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

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

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

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

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

[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, «Common YANG Data Types for the Routing Area», RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.

[RFC8341] Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, «A YANG Data Model for Routing Management (NMDA Version)», RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, «OSPFv3 Link State Advertisement (LSA) Extensibility», RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.

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

[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, «YANG Data Model for the OSPF Protocol», RFC 9129, DOI 10.17487/RFC9129, October 2022, <https://www.rfc-editor.org/info/rfc9129>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», W3C Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/xml/>.

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

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

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

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

Приложение A. Пример конфигурации

Ниже приведён пример XML (в соответствии с [W3C.REC-xml-20081126]) использования модели данных YANG для OSPFv3 Extended LSA. Длинные строки разорваны (\) в соответствии с [RFC8792].

   <?xml version='1.0' encoding='UTF-8'?>
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <router-id>192.0.2.1</router-id>
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf">\
           ospf:ospfv3</type>
           <name>"OSPFv3"</name>
           <ospf xmlns="urn:ietf:params:xml:ns:yang:ietf-ospf">
             <extended-lsa-support xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ospfv3-extended-lsa">true</extended-lsa-support>
           </ospf>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>

Этот же пример в формате JSON [RFC7951] показан ниже.

   {
     "routing": {
       "router-id": "192.0.2.1",
       "control-plane-protocols": {
         "control-plane-protocol": {
           "type": "ospf:ospfv3",
           "name": "\"OSPFv3\"",
           "ospf": {
             "extended-lsa-support": true
           }
         }
       }
     }
   }

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

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

Большое спасибо Tom Petch, Mahesh Jethanandani, Renato Westphal, Victoria Pritchard, Reshad Rahman, Chris Hopps за их рецензии и комментарии.

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

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
 
Sharmila Palani
Microsoft
1 Microsoft Way
Redmond, WA 98052
United States of America
Email: sharmila.palani@microsoft.com
 
Yingzhen Qu
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.ietf@gmail.com

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

nmalykh@protokols.ru


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

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

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

RFC 9562 Universally Unique Identifiers (UUIDs)

Internet Engineering Task Force (IETF)                          K. Davis
Request for Comments: 9562                                 Cisco Systems
Obsoletes: 4122                                               B. Peabody
Category: Standards Track                                        Uncloud
ISSN: 2070-1721                                                 P. Leach
                                                University of Washington
                                                                May 2024

Universally Unique Identifiers (UUIDs)

Глобально уникальные идентификаторы (UUID)

PDF

Аннотация

В этой спецификации определены глобально уникальные идентификаторы UUID (Universally Unique Identifier), которые называют также GUID (Globally Unique Identifier), и пространство имён Uniform Resource Name для UUID. UUID имеют размер 128 битов и предназначены для обеспечения пространственной и временной уникальности. Изначально UUID применялись в сетевой вычислительной системе Apollo Network Computing System (NCS), затем в среде распределенных вычислений DCE (Distributed Computing Environment) фонда OSF (Open Software Foundation) и платформах Microsoft Windows.

Данная спецификация основана на спецификации OSF DCE с любезного разрешения OSF (сейчас известен как The Open Group). Информация из ранних версий спецификации OSF DCE также включена в документ. Данный документ отменяет RFC 4122.

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

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

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

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

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

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

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

1. Введение

Эта спецификация определяет пространство имён Uniform Resource Name для глобально уникальных идентификаторов (UUID), называемых также GUID. UUID имеет размер 128 битов и не требует централизованной регистрации.

Применение UUID очень широко распространено в вычислительных системах. UUID образуют ядро инфраструктуры идентификаторов для многих операционных систем, таких как Microsoft Windows, и приложений, таких как Web-браузер Mozilla. Во многих случаях идентификаторы могут раскрываться (expose) разными нестандартными способами.

Эта спецификация пытается стандартизовать практику применения как максимально открытую так, чтобы она приносила пользу всем в рамках Internet. Представленные здесь сведения предназначены служить кратким руководством для желающих реализовать услуги с использованием UUID в сочетании с URN [RFC8141] или иначе.

Имеются документы ITU-T Recommendation и ISO/IEC Standard [X667], основанные на [RFC4122]. Оба набора спецификаций согласованы и полностью совместимы технически. Ничто в этом документе не следует считать отменой стандартов DCE, определяющих UUID.

2. Мотивация

Одной из основных причин широкого применения UUID является отсутствие централизованного администрирования (хотя два формата могут использовать необязательные IEEE 802 Node ID, в остальных этого нет). В результате генерацию по запросу можно полностью автоматизировать и применять идентификаторы с разными целями. Описанный здесь алгоритм генерации UUID поддерживает очень высокую скорость (10 миллионов и более идентификаторов в секунду на одной машине), что позволяет при необходимости использовать UUID даже в качестве идентификаторов транзакций.

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

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

2.1. Причины обновления

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

Одной из областей, где UUID популярны, являются ключи баз данных (БД). Это связано со всё более распределенной природой современных приложений. В таких случаях системы автоинкремента, часто применяемые в БД, уже не работают хорошо, а согласование порядковых номеров через сеть может стать проблемой. Возможность применения UUID в распределённых системах в качестве уникальных и сравнительно коротких значений, не требующих координации, является хорошим вариантом, но UUID версий 1-5, определённые в [RFC4122], не обладают некоторыми желаемыми характеристиками, как указано ниже.

  1. Версии UUID без упорядочения по времени (такие как UUIDv4, см. параграф 5.4) имеют слабую локальность индексов БД. Это означает, что новые значения, созданные последовательно, не размещаются в индексе близко одно к другому, что требует их вставки в случайные места. В результате снижение производительности основных используемых структур (B-tree и варианты) может быть значительным.

  2. 100-наносекундная Григорианская эпоха во временных метках UUIDv1 (параграф 5.1) необычна и её трудно точно представить с использованием стандартных форматов чисел, таких как описаны в [IEEE754].

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

  4. Возникают проблемы приватности и сетевой безопасности при использовании адреса MAC3 в поле узла (node) UUIDv1. Раскрываемые MAC-адрес может применяться в атаках для определения местоположения сетевых интерфейсов и раскрытия иных сведений о соответствующих машинах (как минимум, производитель, а, возможно и другие детали). Кроме того, с появлением виртуальных машин и контейнеров уникальность MAC-адресов не гарантируется.

  5. Многие детали реализации, заданные в [RFC4122], предполагали компромиссы, которые невозможно соблюсти для всех приложений и которые не являются необходимыми для совместимости реализаций.

  6. В [RFC4122] не различаются требования к генерации и простому хранению UUID, хотя они зачастую разные.

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

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

  1. [ULID]

  2. [LexicalUUID]

  3. [Snowflake]

  4. [Flake]

  5. [ShardingID]

  6. [KSUID]

  7. [Elasticflake]

  8. [FlakeID]

  9. [Sonyflake]

  10. [orderedUuid]

  11. [COMBGUID]

  12. [SID]

  13. [pushID]

  14. [XID]

  15. [ObjectID]

  16. [CUID]

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

  1. Исправление замеченных ошибок, связанных в основном с размещением битов, ведущим к несовместимости реализаций [Err1957], [Err3546], [Err4975], [Err4976], [Err5560] и т. п.

  2. Отвязывание других версий UUID от битовой схемы UUIDv1, чтобы поля (такие как time_hi_and_version) не требовалось указывать в UUID, не основанных на времени, а также предоставление определений для UUIDv3, UUIDv4 и UUIDv5, аналогичных UUIDv1.

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

  4. Представление опыта и проблем безопасности для современной эпохи в отношении адресов MAC, алгоритмов хэширования, защищённых случайных значений и др.

  5. Предоставление стандартизованных вариантов для конкретных реализаций и/или экспериментов с UUID.

  6. Предоставление тестовых векторов для иллюстрации реальных UUID, созданных по этой спецификации.

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

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

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

3.2. Сокращения

ABNF

Augmented Backus-Naur Form — расширенная форма Бакуса-Наура

CSPRNG

Cryptographically Secure Pseudorandom Number Generator — криптографически защищённый генератор случайных чисел

DBMS

Database Management System — система управления базами данных (СУБД)

IEEE

Institute of Electrical and Electronics Engineers — институт инженеров по электротехнике и электронике

ITU

International Telecommunication Union — Международный союз электросвязи (МСЭ)

MAC

Media Access Control — управление доступом к среде

MD5

Message Digest 5 — дайджест сообщения 5

MSB

Most Significant Bit — наиболее значимый (старший) бит

OID

Object Identifier — идентификатор объекта

SHA

Secure Hash Algorithm — защищённый алгоритм хэширования

SHA-1

Secure Hash Algorithm 1 — защищённый алгоритм хэширования со 160-битовым дайджестом сообщения

SHA-3

Secure Hash Algorithm 3 — защищённый алгоритм хэширования (произвольный размер)

SHA-224

Secure Hash Algorithm 2 — защищённый алгоритм хэширования со 224-битовым дайджестом сообщения

SHA-256

Secure Hash Algorithm 2 — защищённый алгоритм хэширования со 256-битовым дайджестом сообщения

SHA-512

Secure Hash Algorithm 2 — защищённый алгоритм хэширования со 512-битовым дайджестом сообщения

SHAKE

Secure Hash Algorithm 3 based on the KECCAK algorithm — защищённый алгоритм хэширования на базе KECCAK

URN

Uniform Resource Names — унифицированные имена ресурсов

UTC

Coordinated Universal Time — универсальное координатное время

UUID

Universally Unique Identifier — глобально уникальный идентификатор

UUIDv1

Universally Unique Identifier version 1 — глобально уникальный идентификатор версии 1

UUIDv2

Universally Unique Identifier version 2 — глобально уникальный идентификатор версии 2

UUIDv3

Universally Unique Identifier version 3 — глобально уникальный идентификатор версии 3

UUIDv4

Universally Unique Identifier version 4 — глобально уникальный идентификатор версии 4

UUIDv5

Universally Unique Identifier version 5 — глобально уникальный идентификатор версии 5

UUIDv6

Universally Unique Identifier version 6 — глобально уникальный идентификатор версии 6

UUIDv7

Universally Unique Identifier version 7 — глобально уникальный идентификатор версии 7

UUIDv8

Universally Unique Identifier version 8 — глобально уникальный идентификатор версии 8

4. Формат UUID

Размер UUID составляет 16 октетов (128 битов), а структура определяется битами полей variant и version, как описано ниже. Биты UUID нумеруются от 0 до 127, а октеты — от 0 до 15.

При отсутствии иных явных спецификаций приложения или протокола представления каждое поле кодируется, начиная со старшего байта (сетевой порядок байтов — network byte order).

Сохранение UUID в двоичной форме выполняется упорядочением всех полей в формате big-endian. Однако известно, что GUID компонентной модели объектов (Component Object Model или COM) компании Microsoft используют порядок little-endian. Рассмотрение этого вопроса выходит за рамки спецификации (см. [MS_COM_GUID]).

UUID можно представлять в двоичном или целочисленном формате. При использовании с URN или в тексте приложений UUID следует представлять строками hex-and-dash, состоящими из нескольких групп шестнадцатеричных цифр (в верхнем или нижнем регистре), разделённых одиночными тире/дефисами. Использование в БД описано в параграфе 6.13.

Формальное определение строкового представления UUID имеет показанную ниже форму ABNF [RFC5234].

   UUID     = 4hexOctet «-»
              2hexOctet «-»
              2hexOctet «-»
              2hexOctet «-»
              6hexOctet
   hexOctet = HEXDIG HEXDIG
   DIGIT    = %x30-39
   HEXDIG   = DIGIT / «A» / «B» / «C» / «D» / «E» / «F»
f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Рисунок 1. Пример строкового формата UUID.


Отметим, что буквы могут быть как строчными, так и прописными (включая те и другие в одном значении), как указано в параграфе 2.3 [RFC5234]. Пример текстового представления UUID показан на рисунке 1.

Значение UUID на рисунке 1 может быть представлено в двоичной форме (рисунок 2), целым числом (рисунок 3) или как URN (рисунок 4) [RFC8141].

111110000001110101001111101011100111110111101100000100011101000\
01010011101100101000000001010000011001001000111100110101111110110

Рисунок 2. Пример двоичного формата UUID.

329800735698586629295641978511506172918

Рисунок 3. Пример целочисленного UUID без знака (десятичное значение).

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Рисунок 4. Пример URN для UUID.


Имеется много других форматов представления UUID и ниже приведены примеры некоторых из них.

  • Некоторые реализации UUID (например, [Python] и [Microsoft]) выводят UUID в форме строк в фигурных скобках, включая символы тире.

  • В [X667] дано определение формата UUID для использования UUID с OID.

  • [IBM_NCS] содержит устаревшую спецификацию уникального формата UUID, совместимого с Variant 0xx из таблицы 1.

4.1. Поле Variant

Поле variant определяет схему UUID. Интерпретация всех остальных битов зависит от установки битов этого поля. Поэтому было бы точнее назвать его полем типа, но здесь сохранено исходное название для совместимости. Поле variant включает переменное число старших битов октета 8 в UUID. Содержимое поля variant показано в таблице 1, x указывает, что бит не имеет значения.

Таблица 1. Варианты UUID.

MSB0

MSB1

MSB2

MSB3

Вариант

Описание

0

x

x

x

14-7

Резерв. Совместимость с системой сетевых вычислений (Network Computing System или NCS). Включает Nil UUID (см. параграф 5.9).

1

0

x

x

8-9,A-B

Вариант, описываемый в этом документе.

1

1

0

x

C-D

резерв. Совместимость со старыми версиями Microsoft Corporation.

1

1

1

x

E-F

Резерв для будущих определений, включая Max UUID (параграф 5.10).

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

Биты 64 и 65 в UUID (биты 0 и 1 октета 8) должны быть установлены в соответствии со строкой 2 таблицы 1, поэтому во всех схемах битов и полей эти биты не указаны.

4.2. Поле Version

Номер версии указывается четырьмя старшими битами октета 6 (биты 48 — 51 в UUID). В таблице 2 показаны все версии для UUID variant 10xx, задаваемые этим документом.

Таблица 2. Версии UUID Variant 10xx, заданные этой спецификацией.

MSB0

MSB1

MSB2

MSB3

Версия

Описание

0

0

0

0

0

Не используется.

0

0

0

1

1

UUID на основе григорианского времени, заданные этим документом.

0

0

1

0

2

Резерв для версии DCE Security со встроенными POSIX UUID.

0

0

1

1

3

Заданная этим документом версия на основе имени с хэшированием MD5.

0

1

0

0

4

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

0

1

0

1

5

Заданная этим документом версия на основе имени с хэшированием SHA-1.

0

1

1

0

6

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

0

1

1

1

7

Заданный этим документом UUID на основе времени Unix Epoch.

1

0

0

0

8

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

1

0

0

1

9

Резерв для будущих определений.

1

0

1

0

10

Резерв для будущих определений.

1

0

1

1

11

Резерв для будущих определений.

1

1

0

0

12

Резерв для будущих определений.

1

1

0

1

13

Резерв для будущих определений.

1

1

1

0

14

Резерв для будущих определений.

1

1

1

1

15

Резерв для будущих определений.

Примеры версии и варианта в соответствии с таблицей приведены на рисунке 5, где M представляет размещение версии для шестнадцатеричного значения 0x4 (0b0100), а N — размещение варианта для одного из 4 возможных значений варианта 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011).

00000000-0000-4000-8000-000000000000
00000000-0000-4000-9000-000000000000
00000000-0000-4000-A000-000000000000
00000000-0000-4000-B000-000000000000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Рисунок 5. Примеры UUIDv4 Variant.


Следует отметить, что остальные варианты из таблицы 1 используют разные механизмы субтипов или версионирования. Запись и определение остальных комбинаций вариантов и субтипов UUID выходит за рамки документа.

5. Схемы UUID

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

5.1. UUID версии 1

UUIDv1 базируется на времени и содержит 60-битовую метку времени в формате UTC в виде числа интервалов по 100 наносекунд с момента времени 00:00:00.00 15 октября 1582 (дата григорианской реформы христианского календаря).

UUIDv1 включает также поле clock_seq для предотвращения дубликатов, которые могут возникать при переводе часов назад или смене идентификатора узла (Node ID).

Поле node содержит адрес IEEE 802 MAC, который обычно является адресом хоста или случайным значением, созданным в соответствии с параграфами 6.9 и 6.10.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           time_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           time_mid            |  ver  |       time_high       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|         clock_seq         |             node              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Схема полей и битов UUIDv1.


time_low

32 младших бита 60-битовой стартовой метки времени (биты 0 — 31, октеты 0 — 3).

time_mid

Средние 16 битов 60-битовой стартовой метки времени (биты 32 — 47, октеты 4 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b0001 (1) (биты 48 — 51, октет 6).

time_high

12 старших5 битов 60-битовой стартовой метки времени (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

clock_seq

14-битовое поле упорядочения часов (биты 66 — 79, октеты 8 — 9).

node

48-битовый пространственно-уникальный идентификатор (биты 80 — 127, октеты 10 — 15).

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

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

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

Поле clock_seq должно исходно (один раз за время существования системы) инициализироваться случайным значением для минимизации сходства (корреляции между системами). Это обеспечивает максимальную защиту в случае быстрого переноса Node ID от системы к системе. Исходному значению недопустимо коррелировать с Node ID.

Замечания для идентификаторов узлов на основе IEEE 802

  • В системах с несколькими адресами IEEE 802 можно использовать любой доступный адрес.

  • В системах без адреса IEEE должно использоваться случайное или псевдослучайное значение (см. параграфы 6.9 и 6.10).

  • В системах с 64-битовым адресом MAC можно использовать 48 младших (правых) битов.

  • Системам с 16-битовым адресом IEEE 802.15.4 следует применять взамен его 64-битовый MAC-адрес (можно использовать младшие 48 битов). Как вариант, можно сгенерировать 32 случайных бита и добавить их в конец 16-битового MAC-адреса для создания 48-битового значения.

5.2. UUID версии 2

UUIDv2 предназначены для DCE Security UUID (см .[C309] [C311]), поэтому определение здесь не приводится.

5.3. UUID версии 3

UUIDv3 предназначены для создания UUID по именам, которые берутся из некого пространства имён и уникальны в нём (см. параграф 6.5). Значения UUIDv3 создаются путём расчёта хэш-значения MD5 [RFC1321] для данного значения Namespace ID (параграф 6.6), объединённого (конкатенация) со значением желаемого имени, после их приведения к канонической последовательности октетов, заданной стандартами или соглашениями пространства имён, в сетевом порядке байтов. Значение MD5 помещается в UUID, затем устанавливаются поля version и variant в соответствии с параграфами 4.2 и 4.1 (см. пример в Приложении A.2). Информация о выборе канонического формата желаемого имени приведена в параграфе 6.5 (Замечание об именах).

По возможности вместо UUIDv3 следует применять UUIDv5. Сведения о безопасности MD5 приведены в [RFC6151].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            md5_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          md5_high             |  ver  |       md5_mid         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        md5_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            md5_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Схема полей и битов UUIDv2.


md5_high

48 старших (слева) битов рассчитанного значения MD5 (биты 0 — 47, октеты 0 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b0011 (3) (биты 48 — 51, октет 6).

md5_mid

12 младших (справа) из 16 битов рассчитанного значения MD5, следующих за md5_high (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

md5_low

62 младших (справа) битов из оставшихся 64 битов рассчитанного значения MD5 (биты 66 — 127, октеты 8 — 15).

5.4. UUID версии 4

UUIDv4 предназначена для генерации UUID из действительно случайных или псевдослучайных значений.

Реализация может генерировать 128 битов случайных данных и заполнять ими структуру UUID (рисунок 8). Затем поля version и variant устанавливаются в соответствии с параграфами 4.1 и 4.2. Как вариант, реализация может генерировать случайные значения random_a, random_b и random_c (всего 122 бита), а затем заполнить поля version и variant. Рекомендации по генерации случайных значений приведены в параграфе 6.9.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           random_a                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          random_a             |  ver  |       random_b        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                       random_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           random_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Схема полей и битов UUIDv4.


random_a

Первые 48 битов, заполненные случайными данными (параграф 6.9) (биты 0 — 47, октеты 0 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b0100 (4) (биты 48 — 51, октет 6).

random_b

12 дополнительных битов, заполненные случайными данными (параграф 6.9) (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

random_c

62 бита после поля var, заполненные случайными данными (параграф 6.9) (биты 66 — 127, октеты 8 — 15).

5.5. UUID версии 5

UUIDv5 предназначены для генерации UUID по «именам», которые берутся из некого пространства имён и уникальны в нем, как описано в параграфе 6.5.

Значения UUIDv5 создаются путём расчёта хэш-значения SHA-1 [FIPS180-4] для данного значения Namespace ID (параграф 6.6), объединённого (конкатенация) с желаемым именем, после их приведения к канонической форме в соответствии со стандартами или соглашениями пространства имён с сетевым порядком байтов. Старшие (слева) 128 битов значения SHA-1 помещаются в схему UUID, а оставшиеся 32 (младшие) бита SHA-1 отбрасываются. Затем в UUID заполняются поля version и variant в соответствии с параграфами 4.2 и 4.1. Пример подстановки битов и отбрасывания лишнего представлен в Приложении A.4. Информация о выборе канонического формата желаемого имени приведена в параграфе 6.5 (Замечание об именах).

Возможны ситуации (обычно в зависимости от политики безопасности), когда библиотеки SHA-1 недоступны или сочтены небезопасными для применения. Поэтому может оказаться желательной генерация UUID по именам с использованием SHA-256 или более новых методов SHA. Для таких UUID недопустимо использовать UUIDv5 и взамен должны применяться UUIDv8, заданные в параграфе 5.8. Иллюстративный пример UUIDv8 для основанных на имени идентификаторов с использованием SHA-256 приведён в Приложении B.2.

Вопросы безопасности SHA-1 рассмотрены в [RFC6194].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           sha1_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         sha1_high             |  ver  |      sha1_mid         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                       sha1_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           sha1_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Схема полей и битов UUIDv5.


sha1_high

Старшие (слева) 48 битов рассчитанного значения SHA-1 (биты 0 — 47, октеты 0 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b0101 (5) (биты 48 — 51, октет 6).

sha1_mid

Младшие 12 из следующих после sha1_high 16 битов рассчитанного значения SHA-1 (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

sha1_low

62 младших бита оставшейся части (старшие 128 битов) хэш-значения SHA-1 (биты 66 — 127, октеты 8 — 15).

5.6. UUID версии 6

UUIDv6 — совместимая по полям версия UUIDv1 (параграф 5.1) с переупорядочением для улучшения локальности БД. Ожидается применение UUIDv6 прежде всего в контексте использования UUIDv1. Системам, не использующим устаревшую версию UUIDv1, следует применять UUIDv7 (параграф 5.7).

Вместо расщепления временной метки на три части (low, mid, high) как в UUIDv1 версия UUIDv6 обращает последовательность битов метки времени и записывает их от старшего к младшему. Т. е. из 60-битовой метки времени, принятой в UUIDv1 (параграф 5.1) в UUIDv6 сначала берутся 48 старших битов, за которыми следует 4 бита версии и оставшиеся 12 битов исходной 60-битовой временной метки. Поле clock_seq применяется, как указано в параграфе 5.1.

Для битов clock_seq и node следует устанавливать псевдослучайные значение при каждой генерации нового UUIDv6, однако реализация может применять поведение clock_seq и MAC-адреса, описанное в параграфе 5.1. Дополнительные сведения о применении MAC-адресов в UUID представлены в разделе 8.

Формат UUIDv6 показан на рисунке 10.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           time_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           time_mid            |  ver  |       time_low        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|         clock_seq         |             node              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Схема полей и битов UUIDv6.


time_high

32 старших (слева) бита 60-битовой стартовой метки времени (биты 0 — 31, октеты 0 — 3).

time_mid

Средние 16 битов 60-битовой стартовой метки времени (биты 32 — 47, октеты 4 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b0110 (биты 48 — 51, октет 6).

time_low

Оставшиеся 12 битов 60-битовой стартовой метки времени (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

clock_seq

14-битовое поле упорядочения часов (биты 66 — 79, октеты 8 — 9).

node

48-битовый пространственно-уникальный идентификатор (биты 80 — 127, октеты 10 — 15).

В UUIDv6 расщепление метки времени на time_high и time_mid необязательно, поскольку порядок 48 битов time_high и time_mid не меняется. Этот шаг остаётся полезным при использовании имеющийся реализации UUIDv1.

5.7. UUID версии 7

UUIDv7 включает упорядоченные по времени значения меток из широко применяемого и хорошо известного источника Unix Epoch — число миллисекунд, прошедших с полуночи 1 января 1970 г. UTC, без учёта високосных секунд. В общем случае UUIDv7 обеспечивает лучшую энтропию по сравнению с UUIDv1 (параграф 5.1) и UUIDv6 (параграф 5.6).

Значения UUIDv7 создаются путём размещения временной метки Unix в миллисекундах) в старших 48 битах, заполнения полей version и variant, а также размещения случайных битов в оставшихся частях UUIDv7 для обеспечения уникальности, как указано в параграфе 6.9. Как вариант, реализации могут заполнять эти 74 указанной ниже комбинацией полей для обеспечения монотонного роста в рамках 1 миллисекунды:

  1. необязательная субмиллисекундная часть метки времени (до 12 битов), см. параграф 6.2 (метод 3);

  2. необязательный счётчик с хорошей затравкой, как указано в параграфе 6.2 (метод 1 или 2);

  3. случайные данные для каждого нового значения UUIDv7 в остальных битах.

Реализациям следует, по возможности, применять UUIDv7 вместо UUIDv1 и UUIDv6.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Схема полей и битов UUIDv7.


unix_ts_ms

48-битовое беззнаковое значение (big-endian) временной метки Unix Epoch в миллисекундах, как указано в параграфе 6.1 (биты 0 — 47, октеты 0 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b0111 (7) (биты 48 — 51, октет 6).

rand_a

12 псевдослучайных битов для обеспечения уникальности (параграф 6.9) и/или дополнительной монотонности, как указано в параграфе 6.2 (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

rand_b

62 псевдослучайных бита для обеспечения уникальности (параграф 6.9) и/или дополнительной монотонности, как указано в параграфе 6.2 (биты 66 — 127, октеты 8 — 15). .

5.8. UUID версии 8

UUIDv8 обеспечивает формат для экспериментов и фирменных решений. Единственным требованием к этой версии является то, что биты variant и version должны быть установлены в соответствии с параграфами 4.1 и 4.2. Уникальность UUIDv8 будет зависеть от реализации и предполагать её недопустимо.

Явно определены лишь биты полей version и variant, а оставшиеся 122 контролируются реализацией. Важно отметить, что UUIDv8 не является заменой UUIDv4 (параграф 5.4), где эти 122 бита заполняются случайными значениями.

Ниже указаны примеры ситуаций, где могут применяться UUIDv8.

  • Реализация хочет включить в UUID информацию, не заданную в этом документе.

  • У реализации имеются ограничения на уровне языка или приложения, препятствующие применению стандартных UUID.

В Приложении B приведены два иллюстративных примера фирменных алгоритмов UUIDv8.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           custom_a                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          custom_a             |  ver  |       custom_b        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                       custom_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           custom_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. Схема полей и битов UUIDv8.


custom_a

48 битов, заполняемых в соответствии с потребностями реализации (биты 0 — 47, октеты 0 — 5).

ver

4-битовое поле версии, заданное в параграфе 4.2, со значением 0b1000 (8) (биты 48 — 51, октет 6).

custom_b

12 битов, заполняемых в соответствии с потребностями реализации (биты 52 — 63, октеты 6 — 7).

var

2-битовое поле варианта, заданное в параграфе 4.1, со значением 0b10 (биты 64 — 65, октет 8).

custom_c

62 бита после поля var, заполняемых в соответствии с потребностями реализации 62 (биты 66 — 127, октеты 8 — 15).

5.9. Nil UUID

00000000-0000-0000-0000-000000000000

Рисунок 13. Формат Nil UUID.


Nil UUID — это особый случай UUID, где все 128 имеют значение 0.

Nil UUID может применяться для указания отсутствия иного значения UUID, если требуется или применяется 128-битовый идентификатор UUID. Nil UUID можно считать эквивалентом отсутствия нужного значения, т. е это резервное значение для особых случаев в конкретной реализации.

Отметим, что Nil UUID относится к диапазону варианта Apollo NCS в соответствии с первой строкой таблицы 1.

5.10. Max UUID

Max UUID — это особый случай UUID, где все 128 битов имеют значение 1. Этот идентификатор можно считать инверсией Nil UUID (см. параграф 5.9).

FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

Рисунок 14. Формат Max UUID.


Max UUID можно применять в качестве контрольного значения, когда требуется 128-битовый идентификатор UUID, но такие концепции как «конец списка UUID» нужно выражать и резервировать для зависящих от реализации случаев.

Отметим, что значение Max UUID относится к диапазону ещё не определённых (yet-to-be defined) в соответствии с последней строкой таблицы 1.

6. Опыт применения UUID

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

6.1. Временные метки

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

Надёжность

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

Источник

В UUIDv1 и UUIDv6 применяются временные метки Gregorian Epoch, а в UUIDv7 — Unix Epoch. Если нужны метки другой эпохи, должна применяться версия UUIDv8.

Субсекундное разрешение и точность

Для временных меток применяется множество уровней точности: миллисекунды, микросекунды, наносекунды и т. д. Кроме того, для упорядочения по времени при разных субсекундных уровнях могут применяться дробные значения. Системные часы имеют тот или иной уровень дискретности, который зачатую ниже точности, обеспечиваемой операционной системой. В настоящее время для UUIDv1 и UUIDv6 применяется дискретность в 100 нсек, а для UUIDv7 — 1 мсек для Unix Epoch, что не выше точности многих современных систем. Для других уровней точности можно применять UUIDv8. По аналогии с параграфом 6.2 для UUIDv1 и UUIDv6 можно имитировать более высокую точность временных меток, подсчитывая число UUID с одинаковым значением системного времени и создавая на основе этого дробную часть временной метки. Число меток высокого разрешения будет варьироваться от 0 до числа интервалов по 100 нсек в одном интервале системных часов.

Размер

От размера временной ветки напрямую зависит продолжительность её возможного использования в UUID до достижения максимального значения и это следует принимать во внимание при выборе типа метки. В версиях UUIDv1 и UUIDv6 применяются 60-битовые метки времени, пригодные до 52366 н. э., в UUIDv7 — 48-битовые, которые будут действовать до 10889 н. э.

Изменение, размытие, размазывание

Реализации могут изменять фактические метки времени. Примерами этого являются соображения безопасности, связанные с предоставлением реального времени в UUID для 1) корректировки неточных часов, 2) обработки високосных секунд, 3) получение значений миллисекунд путём деления на 1024 (или иное значение) по причинам производительности (вместо деления числа микросекунд на 1000). Эта спецификация не задаёт требований или гарантий точности часов (совпадения с фактическим временем). Если не требуется частая генерация UUID, метки UUIDv1 и UUIDv6 могут просто быть системным временем, умноженным на число 100-наносекундных интервалов в одном интервале системного таймера.

Заполнение

Если требуется дополнение меток времени, реализация должна заполнять старшие (слева) биты. Примером является заполнение старших битов метки Unix нулями до размера 48 битов в UUIDv7 или заполнение старших битов числом переходов 32-битовых меток Unix через 0 после 19 января 2038 г.

Отсечка

Если требуется отсечка временной метки, отбрасываться должны младшие (справа) биты. Примером может служить отсечка 16 младших битов 64-битовых меток Unix до 48 битов в UUIDv7.

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

Если система перегружает генератор, запрашивая слишком много UUID в одном интервале системного таймера, служба UUID может возвращать ошибку или приостанавливать генератор UUID до смены значения системных часов. Недопустимо сознательно возвращать дубликаты значений при переходе счётчика через 0 (rollover). Отметим, что при частой перегрузке генераторов UUID системе могут быть выделены добавочные Node ID, что позволит ускорить выделение, делая потенциально доступными множество UUID для каждого значения метки. Похожие методы рассматриваются в параграфе 6.4.

6.2. Монотонность и счётчики

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

Следует озаботиться монотонностью UUID при пакетной генерации. Т. е. при создании 1000 UUID для одной метки времени следует обеспечить логику упорядочения генерации этой 1000 UUID. Реализации пакетной генерации UUID могут применять монотонный счётчик, инкрементируемый для каждого UUID создаваемого с той же меткой времени.

В реализациях UUID для одного узла, которым не требуется пакетное создание UUID, встроенные метки времени UUIDv6 и UUIDv7 могут обеспечить достаточные гарантии монотонности просто за счёт создания нового UUID после того, как временная метка обновилась. Узлы распределенных систем рассматриваются в параграфе 6.4.

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

Выделенный счётчик фиксированного размера (метод 1)

Некоторые реализации выделяют определённое число битов в схеме UUID исключительно для подсчёта числа UUID созданных в течение данного интервала меток UUID. При наличии счётчика фиксированного размера он должен помещаться сразу после встроенной временной метки. Это улучшает сортировку и позволяет генерировать случайные данные для каждого увеличения счётчика. В этом случае поле rand_a (или часть его битов слева) в UUIDv7 служит выделенным счётчиком фиксированного размера, который инкрементируется при каждой генерации UUID. Случайные биты в конце rand_b (трейлер) при каждой генерации UUID помогут создавать непредсказуемые UUID. Если для счётчика нужно больше битов можно использовать также старшие (слева) биты поля rand_b.

Монотонные случайные числа (метод 2)

Этот метод позволяет использовать случайные данные как счётчик. Эти монотонные значения можно рассматривать как «счётчик со случайной затравкой», которая должна инкрементироваться в младших битах при каждой генерации UUID с данной временной меткой. В UUIDv7 для этого следует использовать поле rand_b при пакетной генерации в течение одного интервала временной метки. Приращение для каждой генерации UUID является случайным положительным целым числом желаемого размера. Это обеспечивает требуемый уровень непредсказуемости UUID за счёт базовой энтропии. Можно инкрементировать значение на 1, если важно число генерируемых в определённом интервале UUID, а предсказуемость не является проблемой. Однако не следует увеличивать счётчик на 1 в реализациях, поддерживающих непредсказуемость, поскольку значения легко угадать.

Замена старших битов для повышения точности часов (метод 3)

Для UUIDv7 с миллисекундной дискретностью меток времени можно использовать дополнительную точность часов, доступную в системе, для замены 12 случайных битов, следующих сразу за меткой времени. Это позволяет получить упорядоченные по времени значения с субмиллисекундным разрешением, используя подходящее для среды реализации число битов. В этом случае биты повышения точности должны размещаться в начале (слева) поля rand_a для UUIDv7.

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

Предположим, например, системное время 1 января 2023 г. 12:34:56,1234567. С учётом точности лучше 1 мсек получим значение 0,4567 как дробную часть миллисекунды. Для кодирования этого значения в 12 битов можно взять число возможных значений этих битов (4096 или 212), умножить его на значение дробной части и отсечь результат до целого числа, что даёт 1870. Это число можно представить в шестнадцатеричной (0x74E) или двоичной (0b011101001110) форме. Затем эти 12 битов можно использовать как старшие (слева) биты поля случайного значения UUID (rand_a в UUIDv7). Это работает для любого числа битов, помещаемых в UUID, и приложение может выбрать число битов на основе доступного разрешения часов. Для UUIDv7 число ограничено 12 битами, доступными в поле случайных значений.

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

Ниже рассматриваются вопросы создания надёжных выделенных счётчиков с фиксированным числом битов.

Затравка выделенного счётчика с фиксированным размером

Реализации со счётчиком фиксированного размера инициализируют этот счётчик случайным значением при каждом увеличении (шаге) метки времени. При неизменном значении метки счётчик инкрементируется по специальной логике. При использовании счётчика со случайной затравкой (seed) вместе с методом 1 (см. выше) случайное значение может генерироваться при каждом увеличении счётчика без влияния на сортируемость. Недостатком такого подхода является возможность переполнения счётчика при выборе недостаточного размера или нехватке места для требуемого числа приращений. Реализации со счётчиком фиксированного размера могут применять случайную инициализацию части, а не всего значения счётчика. Например, в 24-битовом счётчике можно случайно инициализировать 23 младших бита, а старший бит инициализировать 0 с целью предотвращения переполнения счётчика.

Размер выделенного счётчика с фиксированным размером

Разрядность счётчика выбирается в соответствии с уровнем точности меток времени. Например, для миллисекундной точности обычно требуется больший размер счётчика, чем для наносекундной. В общем случае следует делать размер не менее 12 битов и не более 42. Нужно выбирать размер так, чтобы обеспечивалась достаточная энтропия случайной части UUID после размещения счётчика. Энтропия позволяет улучшить непредсказуемость UUID при пакетной генерации.

Далее рассматриваются вопросы, связанные с переходом счётчика через максимум (rollover).

Защита от обнуления (rollover)

Описанная выше «Затравка счётчика фиксированного размера» полезна и для устранения перехода счётчика через 0 при достижении максимума. Это подходит и для методов с монотонным случайным счётчиком, когда гарантируется, что размер инкрементируемой части меньше общего размера случайного приращения. Это позволяет инкрементировать младшие (справа) биты счётчика без риска перехода через максимальное значение счётчика.

Обработка достижения максимума счётчика (Rollover)

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

Для обеспечения монотонности идентификаторов UUID со встроенным счётчиком реализация может:

  1. сравнить текущую метку времени с сохранённой;

  2. если метки совпадают, счётчик инкрементируется выбранным методом;

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

Проверка ошибок монотонности

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

6.3. Состояния генератора UUID

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

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

Для UUIDv1 и UUIDv6 при неизменном Node ID (например, сетевой адаптер для Node ID не отделим от системы) или реинициализации упорядочения часов случайным значением можно возвращать текущее значение Node ID вместо его записи в стабильное хранилище. Состояние не требуется записывать в стабильное хранилище при каждой генерации UUIDv1 или UUIDv6. Для метки времени в хранилище можно периодически устанавливать значение больше уже использованного в UUID. Пока в генерируемых UUID метка времени меньше записанной в хранилище, а clock_seq и Node ID остаются неизменными, обновлять нужно лишь общую энергонезависимую копию состояния. Если значение метки в хранилище указывает в будущее на величину меньше типичного времени перезагрузки системы, отказ (перезагрузка) не приведёт к необходимости заново инициализировать clock_seq.

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

6.4. Распределённая генерация UUID

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

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

Node ID

В этом методе в структуру UUID помещается псевдослучайное значение Node ID, которое помогает гарантировать уникальность битового пространства для данного узла. В результате созданные узлом UUID не конфликтуют с UUID, созданными другими узлами (с иным Node ID ). Реализациям со встроенным идентификатором узла следует использовать UUIDv8. В качестве Node ID не следует применять адреса IEEE 802 MAC (см. раздел 8). Местоположение и число используемых битов определяется реализацией и выходит за рамки документа. Не рассматривается здесь также создание и согласование уникальных идентификаторов для каждого узла.

Централизованный реестр

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

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

6.5. Генерация UUID на основе имён

Хотя некоторые предпочитают термин «основанные на хэше» для описания UUID, применяющих алгоритмы хэширования (MD5 или SHA-1), в документе сохраняется термин «основанные на именах» для согласованности с ранее опубликованными документами и имеющимися реализациями. Требования к UUID на основе имён приведены ниже.

  • UUID, созданные из одного имени (в одном каноническом формате) в одном пространстве имён, должны быть одинаковыми.

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

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

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

Замечание об именах

Понятие имени (и пространства имён) следует трактовать широко, не ограничиваясь текстовыми именами. Каноническая последовательность октетов — это последовательность, соответствующая спецификации канонической формы представления данной формы имени. Имя может иметь множество форм, из которых лишь 1 является канонической. Разработчики новых пространств имён для UUID должны указывать спецификацию канонической формы имён в этом пространстве или определять каноническую форму, если её ещё нет. Например, на момент создания этого документа в системе доменных имён ((Domain Name System или DNS) [RFC9499] было 3 формата передачи: базовый (www.example.com), для представления (www.example.com.) и для передачи в линию (3www7example3com0). Для отличительных имён [X500] (Distinguished Name или Dn) [RFC4122] разрешает принимать текстовые и двоичные (DER). Для унифицированных указателей ресурсов (Uniform Resource Locator или URL) [RFC1738] можно указать полное доменное имя (Fully Qualified Domain Name или FQDN) с идентификатором протокола или без него (www.example.com или https://www.example.com). Для идентификаторов объектов (OID) [X660] можно выбрать нотацию с точками без точки (2.999) или с точкой (.2.999) в начале, а также один из многих форматов [X680], таких как OID Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/Example). Хотя по умолчанию большинство пользователей могут применять базовый формат для DNS, FQDN для URL, текст для X.500 и нотацию без ведущей точки для OID, реализациям UUID на основе имён обычно следует принимать ввод в любой форме. Каждый из форматов имени в пространстве имён будет давать на выходе свой UUID. Поэтому механизмы и соглашения, применяемые для выделения имён и обеспечения их уникальности в своём пространстве выходят за рамки этой спецификации.

6.6. Распределение и использование идентификаторов пространства имён

В этом параграфе описаны идентификаторы некоторых потенциально интересных пространств имён, таких как DNS [RFC9499], URL [RFC1738], OID [X660], Dns [X500]. Описаны также выделение, регистрация в IANA и другие детали.

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

 

Пространство имён

Namespace ID

Документ

для имени

для идентификатора

DNS

6ba7b810-9dad-11d1-80b4-00c04fd430c8

[RFC9499]

[RFC4122], RFC 9562

URL

6ba7b811-9dad-11d1-80b4-00c04fd430c8

[RFC1738]

[RFC4122], RFC 9562

OID

6ba7b812-9dad-11d1-80b4-00c04fd430c8

[X660]

[RFC4122], RFC 9562

X500

6ba7b814-9dad-11d1-80b4-00c04fd430c8

[X500]

[RFC4122], RFC 9562

 

Элементы добавляются в реестр по процедуре Specification Required [RFC8126]. Распределение Namespace ID назначенными экспертами показано ниже.

  • Первое значение Namespace ID для DNS было рассчитано из UUIDv1 на основе времени и в качестве стартовой точки служит 6ba7b810-9dad-11d1-80b4-00c04fd430c8.

  • В последующих значениях Namespace ID увеличивается младший (справа) бит time_low 6ba7b810, а для остальной части UUID фиксируется значение 9dad-11d1-80b4-00c04fd430c8.

  • Новые значения Namespace ID должны использовать такую же логику и недопустимо выдавать ранее использованные значения Namespace ID.

  • Таким образом, для следующего Namespace ID доступно значение time_low 6ba7b815 а полный идентификатор будет иметь значение 6ba7b815-9dad-11d1-80b4-00c04fd430c8.

  • Верхней границей time_low в случае значений Namespace ID является ffffffff (полный идентификатор ffffffff-9dad-11d1-80b4-00c04fd430c8), что должно обеспечить достаточно места для будущих значений Namespace ID.

Отметим, что 6ba7b813-9dad-11d1-80b4-00c04fd430c8 и его использование не заданы этим документом и [RFC4122], поэтому его не следует применять значение Namespace ID.

Новые Namespace ID должны документироваться в соответствии с разделом 7, если они должны быть глобально доступны и совместимы. Реализации могут продолжать специфичные для поставщика, приложения или внедрения значения Namespace ID, но это не гарантирует совместимости. Для таких ID недопустимо применять указанную выше логику и взамен рекомендуется Namespace ID UUIDv4 или UUIDv7. Если вероятность конфликтов (параграф 6.7) и уникальность (параграф 6.8) UUID на основе имени не являются проблемой, реализация может применять при создании Namespace ID для приложения версию UUIDv8. Реализациям следует возможность ввода пользовательских пространств имён для вновь зарегистрированных IANA Namespace ID сверх указанных выше, а также специфичных для приложения Namespace ID.

6.7. Устойчивость к конфликтам

Реализациям следует учитывать последствия конфликтов UUID в приложениях и при выборе между версиями UUID, использующими энтропию (случайность), и другими компонентами, такими как описаны в параграфах 6.1 и 6.2. Это особенно важно для устойчивости к конфликтам в распределенных системах, как описано в параграфе 6.4. Ниже приведены два примера, иллюстрирующие разный уровень влияния конфликтов на приложение.

Слабое влияние

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

Сильное влияние

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

6.8. Глобальная и локальная уникальность

Созданные по этой спецификации UUID могут применяться для обеспечения гарантий локальной уникальности. Например, в случаях, когда не нужна глобальная уникальность вне приложения, уникальности созданных в рамках локального приложения UUID может быть достаточно для БД. Хотя абсолютную глобальную уникальность невозможно обеспечить без схемы обмена данными, для практической уникальности UUID такая схема не требуется. Реализации могут при необходимости использовать общую схему обмена данными, описанную в параграфе 6.4для повышения уровня уникальности, обеспечиваемого данной спецификацией.

6.9. Непредсказуемость

Реализациям следует применять криптозащищенный генератор псевдослучайных чисел (CSPRNG) для создания трудно предсказуемых значений с низкой вероятностью коллизий (уникальность). Исключением являются случаи недоступности CSPRNG в среде исполнения. Следует озаботиться подобающим обновлением состояния CSPRNG в таких ситуациях, как ветвление процессов. CSPRNG гарантирует, что лучшие решения из параграфов 6.7 и 8 будут в современных UUID. Дополнительные сведения по созданию случайных чисел криптографического качества даны в [RFC4086], [RFC8937], [RANDOM].

6.10. UUID, не идентифицирующие хост

В этом параграфе описана генерация UUIDv1 или UUIDv6 в случаях недоступности или нежелательности применения адресов IEEE 802. Реализации могут использовать методы рандомизации MAC-адресов [IEEE802.11bh] в качестве альтернативы псевдослучайной логике, описанной в этом параграфе. Как вариант, реализации могут выбрать получение 48-битового псевдослучайного числа криптографического качества в соответствии с параграфом 6.9 для использования в качестве Node ID. После генерации 48-битового случайного идентификатора узла реализация должна установить в младшем бите первого октета Node ID значение 1. Этот бит служит для указания индивидуального или группового адреса и никогда не устанавливается в адресах IEEE 802 реальных сетевых плат. Поэтому не может возникать конфликтов между UUID, созданных на машинах с сетевым адаптером и без такового. Пример генерации случайного 48-битового значения и его последующего использования приведён в Приложении A. Дополнительные сведения об адресах IEEE 802, битах unicast/multicast и local/global приведены в [RFC9542].

Отметим, что для совместимости с прежними спецификациями здесь используется бит unicast/multicast, а не более корректный local/global, поскольку в сети возможны MAC-адреса с обоими значениями бита local/global. С битом unicast/multicast этого не происходит, поскольку узел не может иметь группового адреса.

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

Точный алгоритм генерации Node ID зависит от конкретной системы, поскольку доступные данные и функции очень часто зависят от системы. Базовый подход заключается в сборе как можно большего числа источников в буфер, создании дайджеста сообщения (например, SHA-256 или SHA-512 [FIPS180-4]), взятия из хера 6 произвольных байтов и установки бита multicast, как указано выше.

6.11. Сортировка

UUIDv6 м UUIDv7 устроены так, что реализации, которым нужна сортировка (например, индексов БД), могут обрабатывать идентификаторы как неразобранные (raw) байты без необходимости из разбора или анализа. Упорядоченные по времени монотонные UUID выигрывают от большей локальности индексов БД, поскольку новые значения индексов размещаются близко друг к другу. В результате объекты лучше группируются для повышения производительности. Реальные различия при таком подходе и случайной вставке данных могут составлять порядок величины и больше.

Форматы UUID, соответствующие этой спецификации, предназначены для лексической сортировки в текстовом представлении. UUID создаются с сетевым порядком байтов (big-endian). Если нужен обратный порядок (little-endian), можно использовать UUIDv8.

6.12. Непрозрачность

В общем случае рекомендуется избегать ненужного анализа значений UUID, используя их как «непрозрачные» (opaquely). Хотя задачи приложений могут требовать того или иного анализа (introspection), например, полей var (параграф 4.1) и ver (параграф 4.2) или временных меток UUID, рекомендуется избегать таких операций. Соблюдение этих рекомендаций упростит приложения, повысит их совместимость и производительность.

6.13. Вопросы БД и СУБД

Для многих приложений (например, БД) сохранение UUID в форме текста избыточно, поскольку требует 288 битов для представления 128-битовых значений UUID. По возможности, UUID для БД следует сохранять в 128-битовой двоичной форме. В других системах UUID можно хранить в двоичном или текстовом виде.

  • Двоичная форма обеспечивает экономию места и может ускорять доступ.

  • Текстовая форма занимает больше места, но требует меньше трансляций, что может упростить реализации.

Производителям систем управления базами данных (СУБД) рекомендуется обеспечивать функции генерации и хранения UUID в заданных здесь форматах для применения в качестве идентификаторов (или их части), таких как первичные ключи, суррогатные ключи для временных БД, внешние ключи для полиморфных отношений, ключи пар key-value в столбцах JSON и БД и т. п. В приложениях с монолитными БД созданные базой (а не клиентом) UUID могут быть более монотонными. UUID могут дополняться другими идентификаторами для обеспечения целостности и обратной связи.

Разработчикам БД рекомендуется не использовать UUID на основе имён (параграфы 5.3 и 5.5) в качестве первичных ключей таблиц. Основной проблемой при проектировании БД является допущение о неизменности определённых значений, которое на деле оказывается ошибкой. Почтовые индексы, номера лицензий и другие идентификационные номера и т. п. кажутся уникальными и неизменными в данный момент времени, а позднее возникают обстоятельства, требующие их замены. Изменение идентификатора, служившего вводом name для UUID на основе имени, может привести к аннулированию структуры БД. Для таких случаев отмечено, что использование UUID, не основанных на имени, будет приводить к тому, что рассматриваемое поле будет размещено там, где легче адаптироваться к изменениям (исключая первичные ключи). В общем случае с учётом отмеченных проблем рекомендуется избегать естественных ключей в виде UUID на основе имён и применять суррогатные ключи UUID на основе времени.

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

Все ссылки на [RFC4122] в реестрах IANA (за исключением созданных этим документом) заменены ссылками на этот документ, включая регистрацию пространства имён IANA URN [URNNamespaces] для UUID. Ссылки на параграф 4.1.2 в [RFC4122] заменены ссылками на раздел 4 данного документа.

Агентству IANA нужно отслеживать субтипы UUID и особые случаи Namespace IDs Values, как указано в параграфах 7.1 и 7.2 в реестре <https://www.iana.org/assignments/uuid>. При оценке запросов назначенным экспертам следует учитывать отклики сообщества, чёткость определения базовой спецификации и её требования. Значения, зависимые от производителя, приложения или конкретного внедрения, не регистрируются. Технические документы следует публиковать в стабильном виде с обеспечением свободного доступа (в идеале с указанием URL), но они не обязаны быть стандартами. Назначенные эксперты одобряют или отклоняют запрос на регистрацию и сообщают об этом в IANA. В отказ следует включать объяснение причин и, если это применимо, рекомендации по изменению.

7.1. Реестр IANA UUID Subtypes и регистрация в нём

Эта спецификация задаёт реестр UUID Subtypes для широко применяемых стандартов UUID.

Таблица 4. Субтипы IANA UUID.

 

Имя

ID

Субтип

Вариант

Документ

Gregorian Time-based

1

version

OSF DCE / IETF

[RFC4122], RFC 9562

DCE Security

2

version

OSF DCE / IETF

[C309], [C311]

MD5 Name-based

3

version

OSF DCE / IETF

[RFC4122], RFC 9562

Random

4

version

OSF DCE / IETF

[RFC4122], RFC 9562

SHA-1 Name-based

5

version

OSF DCE / IETF

[RFC4122], RFC 9562

Reordered Gregorian Time-based

6

version

OSF DCE / IETF

RFC 9562

Unix Time-based

7

version

OSF DCE / IETF

RFC 9562

Custom

8

version

OSF DCE / IETF

RFC 9562

 

Значения в реестр могут добавляться по процедуре Standards Action [RFC8126]. Требования указаны ниже.

  • Минимальное и максимальное значение ID для субтипа version варианта OSF DCE / IETF должно находиться в диапазоне от 0 до 15. Версии из таблицы 27 указанные как резервные или не используемые, не включаются в реестр IANA до подобающего определения.

  • В столбце «Субтип» содержится текст произвольной формы. На момент публикации этого документа были лишь два субтипа UUID — version и family. Субтип family относится к пространству вариантов Apollo NCS (выходит за рамки этой спецификации). Вариант Microsoft может иметь механизм субтипов, однако эти субтипы не известны и выходят за рамки спецификации. Варианты «Резерв для будущих определений» могут вносить новые субтипы в будущем. Значения идентификаторов (Subtype ID) могут перекрываться, например, ID может существовать в нескольких вариантах.

  • В столбце «Субтип» содержится текст произвольной формы. Вероятно будет применяться 4 значения: OSF DCE / IETF, Apollo NCS, Microsoft и значение, относящееся к варианту «Резерв для будущих определений». В будущем могут быть добавлены новые имена.

7.2. Реестр IANA UUID Namespace ID и регистрация в нём

Эта спецификация задаёт реестр UUID Namespace IDs для широко используемых значений Namespace ID. Детали регистрации, включая рекомендации для назначенных экспертов, приведены в параграфе 6.6.

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

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

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

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

Вопросы безопасности для MD5 рассмотрены в [RFC6151], для SHA-1 — в [RFC6194].

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

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

[C309] X/Open Company Limited, «X/Open DCE: Remote Procedure Call», ISBN 1-85912-041-5, Open CAE Specification C309, August 1994, <https://pubs.opengroup.org/onlinepubs/9696999099/toc.pdf>.

[C311] The Open Group, «DCE 1.1: Authentication and Security Services», Open Group CAE Specification C311, August 1997, <https://pubs.opengroup.org/onlinepubs/9696989899/toc.pdf>.

[FIPS180-4] National Institute of Standards and Technology (NIST), «Secure Hash Standard (SHS)», FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

[FIPS202] National Institute of Standards and Technology (NIST), «SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions», FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.

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

[RFC8141] Saint-Andre, P. And J. Klensin, «Uniform Resource Names (URNs)», RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.

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

[X667] ITU-T, «Information technology — Open Systems Interconnection — Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components», ISO/IEC 9834-8:2004, ITU-T Recommendation X.667, September 2004.

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

[COMBGUID] «Creating sequential GUIDs in C# for MSSQL or PostgreSql», commit 2759820, December 2020, <https://github.com/richardtallent/RT.Comb>.

[CUID] «Collision-resistant ids optimized for horizontal scaling and performance.», commit 215b27b, October 2020, <https://github.com/ericelliott/cuid>.

[Elasticflake] Pearcy, P., «Sequential UUID / Flake ID generator pulled out of elasticsearch common», commit dd71c21, January 2015, <https://github.com/ppearcy/elasticflake>.

[Err1957] RFC Errata, Erratum ID 1957, RFC 4122, <https://www.rfc-editor.org/errata/eid1957>.

[Err3546] RFC Errata, Erratum ID 3546, RFC 4122, <https://www.rfc-editor.org/errata/eid3546>.

[Err4975] RFC Errata, Erratum ID 4975, RFC 4122, <https://www.rfc-editor.org/errata/eid4975>.

[Err4976] RFC Errata, Erratum ID 4976, RFC 4122, <https://www.rfc-editor.org/errata/eid4976>.

[Err5560] RFC Errata, Erratum ID 5560, RFC 4122, <https://www.rfc-editor.org/errata/eid5560>.

[Flake] Boundary, «Flake: A decentralized, k-ordered id generation service in Erlang», commit 15c933a, February 2017, <https://github.com/boundary/flake>.

[FlakeID] «Flake ID Generator», commit fcd6a2f, April 2020, <https://github.com/T-PWK/flake-idgen>.

[IBM_NCS] IBM, «uuid_gen Command (NCS)», March 2023, <https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-command-ncs>.

[IEEE754] IEEE, «IEEE Standard for Floating-Point Arithmetic.», IEEE Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019, <https://standards.ieee.org/ieee/754/6210/>.

[IEEE802.11bh] IEEE, «IEEE Draft Standard for Information technology-Telecommunications and information exchange between systems Local and metropolitan area networks-Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment: Enhancements for Extremely High Throughput (EHT)», Electronic ISBN 978-1-5044-9520-2, March 2023, <https://standards.ieee.org/ieee/802.11bh/10525/>.

[KSUID] Segment, «K-Sortable Globally Unique IDs», commit bf376a7, July 2020, <https://github.com/segmentio/ksuid>.

[LexicalUUID] Twitter, «Cassie», commit f6da4e0, November 2012, <https://github.com/twitter-archive/cassie>.

[Microsoft] Microsoft, «2.3.4.3 GUID — Curly Braced String Representation», April 2023, <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d>.

[MS_COM_GUID] Chen, R., «Why does COM express GUIDs in a mix of big-endian and little-endian? Why can“t it just pick a side and stick with it?», September 2022, <https://devblogs.microsoft.com/oldnewthing/20220928-00/?p=107221>.

[ObjectID] MongoDB, «ObjectId», <https://docs.mongodb.com/manual/reference/method/ObjectId/>.

[orderedUuid] Cabrera, I. B., «Laravel: The mysterious «Ordered UUID»», January 2020, <https://itnext.io/laravel-the-mysterious-ordered-uuid-29e7500b4f8>.

[pushID] Lehenbauer, M., «The 2^120 Ways to Ensure Unique Identifiers», February 2015, <https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html>.

[Python] Python, «uuid — UUID objects according to RFC 4122», <https://docs.python.org/3/library/uuid.html>.

[RANDOM] Occil, P., «Random Number Generator Recommendations for Applications», June 2023, <https://peteroupc.github.io/random.html>.

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.

[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, «Uniform Resource Locators (URL)», RFC 1738, DOI 10.17487/RFC1738, December 1994, <https://www.rfc-editor.org/info/rfc1738>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, «A Universally Unique Identifier (UUID) URN Namespace», RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.

[RFC5234] Crocker, D., Ed. And P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6151] Turner, S. and L. Chen, «Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms», RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.

[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, «Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms», RFC 6194, DOI 10.17487/RFC6194, March 2011, <https://www.rfc-editor.org/info/rfc6194>.

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

[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., and C. Wood, «Randomness Improvements for Security Protocols», RFC 8937, DOI 10.17487/RFC8937, October 2020, <https://www.rfc-editor.org/info/rfc8937>.

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

[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, <https://www.rfc-editor.org/info/rfc9542>.

[ShardingID] Instagram Engineering, «Sharding & IDs at Instagram», December 2012, <https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c>.

[SID] «sid : generate sortable identifiers», Commit 660e947, June 2019, <https://github.com/chilts/sid>.

[Snowflake] Twitter, «Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.», commit ec40836, May 2014, <https://github.com/twitter-archive/snowflake>.

[Sonyflake] Sony, «A distributed unique ID generator inspired by Twitter“s Snowflake», commit 848d664, August 2020, <https://github.com/sony/sonyflake>.

[ULID] «Universally Unique Lexicographically Sortable Identifier», Commit d0c7170, May 2019, <https://github.com/ulid/spec>.

[URNNamespaces] IANA, «Uniform Resource Names (URN) Namespaces», <https://www.iana.org/assignments/urn-namespaces/>.

[X500] ITU-T, «Information technology — Open Systems Interconnection — The Directory: Overview of concepts, models and services», ISO/IEC 9594-1, ITU-T Recommendation X.500, October 2019.

[X660] ITU-T, «Information technology — Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree», ISO/IEC 9834-1, ITU-T Recommendation X.660, July 2011.

[X680] ITU-T, «Information Technology — Abstract Syntax Notation One (ASN.1) & ASN.1 encoding rules», ISO/IEC 8824-1:2021, ITU-T Recommendation X.680, February 2021.

[XID] «Globally Unique ID Generator», commit efa678f, October 2020, <https://github.com/rs/xid>.

Приложение A. Тестовые векторы

Тестовые векторы UUIDv1 и UUIDv6 используют одну и ту же 60-битовую метку времени: 0x1EC9414C232AB00 (138648505420000000) — вторник, 22 февраля, 2022 2:22:22.000000 PM GMT-05:00. Совпадают также значения clock_seq и node, сгенерированные из случайных данных. Для рандомизированного значения node в младшем бите первого октета устанавливается значение 1, как указано в параграфе 6.10. Это меняет начальное значение 0x9E6BDECED846 на 0x9F6BDECED846.

Псевдокод для преобразования 64-битовых меток Unix в 100-наносекундные метки сохранен в документе для справки.

# Gregorian-to-Unix Offset:
# The number of 100 ns intervals between the
# UUID Epoch 1582-10-15 00:00:00
# and the Unix Epoch 1970-01-01 00:00:00
# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

# Unix 64-bit Nanosecond Timestamp:
# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

# Work:
# Greg_100_ns = (1645557742000000000/100)+122192928000000000
# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

# Final:
# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000

Рисунок 15. Псевдокод тестового вектора метки времени.


A.1. Пример значения UUIDv1

-------------------------------------------
поле      биты  значение
-------------------------------------------
time_low   32   0xC232AB00
time_mid   16   0x9414
ver         4   0x1
time_high  12   0x1EC
var         2   0b10
clock_seq  14   0b11, 0x3C8
node       48   0x9F6BDECED846
-------------------------------------------
total      128
-------------------------------------------
final: C232AB00-9414-11EC-B3C8-9F6BDECED846

Рисунок 16. Пример тестового вектора UUIDv1.


A.2. Пример значения UUIDv3

Расчёт MD5 для DNS Namespace ID и Name со значением www.example.com показан на рисунке 17. Сопоставления и значения полей приведены на рисунке 18, а пподстановка битов version и variant — на рисунке 19.


Namespace (DNS):  6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name:             www.example.com
------------------------------------------------------
MD5:              5df418813aed051548a72f4a814cf09e

Рисунок 17. Пример UUIDv3 MD5.


-------------------------------------------
поле     биты  значение
-------------------------------------------
md5_high  48   0x5df418813aed
ver        4   0x3
md5_mid   12   0x515
var        2   0b10
md5_low   62   0b00, 0x8a72f4a814cf09e
-------------------------------------------
total     128
-------------------------------------------
final: 5df41881-3aed-3515-88a7-2f4a814cf09e

Рисунок 18. Пример тестового вектора UUIDv3.

MD5 hex and dash:      5df41881-3aed-0515-48a7-2f4a814cf09e
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final:                 5df41881-3aed-3515-88a7-2f4a814cf09e

Рисунок 19. Пример подстановки битов Ver/Var в UUIDv3.


A.3. Пример значения UUIDv4

-------------------------------------------
поле     биты  значение
-------------------------------------------
random_a  48   0x919108f752d1
ver        4   0x4
random_b  12   0x320
var        2   0b10
random_c  62   0b01, 0xbacf847db4148a8
-------------------------------------------
total     128
-------------------------------------------
final: 919108f7-52d1-4320-9bac-f847db4148a8

Рисунок 20. Пример тестового вектора UUIDv4.


Пример UUIDv4 создан путём генерации 16 случайных байтов со значением 919108F752D133205BACF847DB4148A8, которое применяется для заполнения полей (рисунок 20).

Подстановка битов version и variant показана на рисунке 21.

Random hex:            919108f752d133205bacf847db4148a8
Random hex and dash:   919108f7-52d1-3320-5bac-f847db4148a8
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final:                 919108f7-52d1-4320-9bac-f847db4148a8

Рисунок 21. Пример UUIDv4 с подстановкой битов Ver/Var.


A.4. Пример значения UUIDv5

Расчёт SHA-1 для DNS Namespace ID и Name со значением www.example.com показан на рисунке 22. Сопоставления и значения полей приведены на рисунке 23, а подстановка битов version и variant, а также сохраняемая и отсекаемая часть — на рисунке 24.

Namespace (DNS):  6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name:             www.example.com
----------------------------------------------------------
SHA-1:            2ed6657de927468b55e12665a8aea6a22dee3e35

Рисунок 22. Пример UUIDv5 SHA-1.

-------------------------------------------
поле      биты  значение
-------------------------------------------
sha1_high  48   0x2ed6657de927
ver         4   0x5
sha1_mid   12   0x68b
var         2   0b10
sha1_low   62   0b01, 0x5e12665a8aea6a2
-------------------------------------------
total      128
-------------------------------------------
final: 2ed6657d-e927-568b-95e1-2665a8aea6a2

Рисунок 23. Пример тестового вектора UUIDv5.

SHA-1 hex and dash:    2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final:                 2ed6657d-e927-568b-95e1-2665a8aea6a2
Discarded:                                                 -2dee3e35

Рисунок 24. Пример UUIDv5 с подстановкой Ver/Var и отбрасыванием части SHA-1.


A.5. Пример значения UUIDv6

-------------------------------------------
поле       биты  значение
-------------------------------------------
time_high   32   0x1EC9414C
time_mid    16   0x232A
ver          4   0x6
time_high   12   0xB00
var          2   0b10
clock_seq   14   0b11, 0x3C8
node        48   0x9F6BDECED846
-------------------------------------------
total       128
-------------------------------------------
final: 1EC9414C-232A- 6B00-B3C8-9F6BDECED846

Рисунок 25. Пример тестового вектора UUIDv6.


A.6. Пример значения UUIDv7

В этом примере UUIDv7 тестовый вектор использует общеизвестную метку времени Unix Epoch с миллисекундной точностью для заполнения первых 48 битов, а rand_a и rand_b заполняются случайными данными. Метка времени: вторник 22февраля 2022 г. 2:22:22.00 PM GMT-05:00 имеет вид 0x017F22E279B0 или 1645557742000.

-------------------------------------------
поле       биты  значение
-------------------------------------------
unix_ts_ms  48   0x017F22E279B0
ver          4   0x7
rand_a      12   0xCC3
var          2   0b10
rand_b      62   0b01, 0x8C4DC0C0C07398F
-------------------------------------------
total       128
-------------------------------------------
final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F

Рисунок 26. Пример тестового вектора UUIDv7.


Приложение B. Иллюстративные примеры

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

B.1. Пример значения UUIDv8 на основе времени

В этом тестовом векторе UUIDv8 применяется общеизвестная 64-битовая временная метка Unix Epoch с разрешением 10 нсек, отсечённая справа до 60, для заполнения полей custom_a и custom_b, с установкой для битов ver между этими полями значения 8. Устанавливаются также биты var, а поле custom_c заполняется случайными данными.

Временная метка — вторник 22февраля 2022 г. 2:22:22.000000 PM GMT-05:00 — представлена как 0x2489E9AD2EE2E00 или 164555774200000000 (шаг 10 нсек).

-------------------------------------------
поле     биты  значение
-------------------------------------------
custom_a  48   0x2489E9AD2EE2
ver        4   0x8
custom_b  12   0xE00
var        2   0b10
custom_c  62   0b00, 0xEC932D5F69181C0
-------------------------------------------
total     128
-------------------------------------------
final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0

Рисунок 27. Пример UUIDv8 на основе времени.


B.2. Пример значения UUIDv8 на основе имени

В соответствии с параграфом 5.5 UUID на основе имени с использованием современных алгоритмов хэширования должны создаваться в пространстве UUIDv8. Можно применять новые алгоритмы, такие как SHA-256 или SHA-512 [FIPS180-4], SHA-3 или SHAKE [FIPS202] и даже алгоритмы, которые ещё не определены.

Namespace (DNS):       6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name:                  www.example.com
----------------------------------------------------------------
SHA-256:
5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8

Рисунок 28. Пример UUIDv8 SHA-256.


Вариант SHA-256 для расчёта SHA, показанный в Приложении A.4, приведён на рисунке 28 как иллюстративный пример. Создание основанного на имени UUIDv8 здесь выполняется по той же логике, которая описана в параграфе 5.5, но с использованием алгоритма SHA-256 вместо SHA-1.

Поля и их значения показаны на рисунке 29. Дополнительная иллюстрации подстановки битов ver и var, а также используемая и неиспользуемая части значения SHA-256 показаны на рисунке 30. Для алгоритмов защищённого хеширования, выдающих результат произвольного размера (например, SHAKE) важно подчеркнуть, что их выход должен быть не менее 128 битов.

-------------------------------------------
поле     биты  значение
-------------------------------------------
custom_a  48   0x5c146b143c52
ver        4   0x8
custom_b  12   0xafd
var        2   0b10
custom_c  62   0b01, 0x38a375d0df1fbf6
-------------------------------------------
total     128
-------------------------------------------
final: 5c146b14-3c52-8afd-938a-375d0df1fbf6

Рисунок 29. Пример UUIDv8 SHA-256 на основе имени.

A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8
B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6
D:                                     -fe12a66b645f72f6158759387e51f3c8

Рисунок 30. Пример UUIDv8 с подстановкой Ver/Var и отбрасыванием сегмента SHA-256.


На рисунке 30:

  • строка A содержит полное значение SHA-256 в шестнадцатеричном формате с разделителями (0);

  • строка B показывает позиции полей ver и var, которые должны быть переписаны;

  • в строке C приведено значение после установки битов ver и var;

  • в строке D показана отбрасываемая часть битов исходного значения SHA-256.

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

Авторы с благодарностью отмечают вклад Rich Salz, Michael Mealling, Ben Campbell, Ben Ramsey, Fabio Lima, Gonzalo Salgueiro, Martin Thomson, Murray S. Kucherawy, Rick van Rein, Rob Wilton, Sean Leonard, Theodore Y. Ts“o, Robert Kieffer, Sergey Prokhorenko, LiosK, а также всех участников сообщества IETF и GitHub, участвовавших в обсуждении этого документа.

Документ в значительной степени основан на спецификации OSF DCE (Приложение A к [C309]) для UUID. Полезные замечания были получены от Ted Ts“o.

Спасибо Ralf S. Engelschall, John Larmouth, Paul Thorpe за внимательное прочтение и доработку материала. Профессор Larmouth внёс неоценимый вклад при согласовании с ISO/IEC.

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

Kyzer R. Davis

Cisco Systems

Email: kydavis@cisco.com

Brad G. Peabody

Uncloud

Email: brad@peabody.io

Paul J. Leach

University of Washington

Email: pjl7@uw.edu


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

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

nmalykh@protokols.ru

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

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

3Media Access Control — управление доступом к среде.

4В оригинале ошибочно указано 0, см. https://www.rfc-editor.org/errata/eid7958. Прим. перев.

5В оригинале ошибочно сказано «младших», см. https://www.rfc-editor.org/errata/eid7955. Прим. перев.

6В оригинале ошибочно указано 5623, см. https://www.rfc-editor.org/errata/eid8288. Прим. перев.

7В оригинале ошибочно указана таблица 1, см. https://www.rfc-editor.org/errata/eid8695. Прим. перев.

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

RFC 9542 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 9542                                   Independent
BCP: 141                                                        J. Abley
Obsoletes: 7042                                               Cloudflare
Category: Best Current Practice                                    Y. Li
ISSN: 2070-1721                                      Huawei Technologies
                                                              April 2024

IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Соображения IANA, использование протоколов и документации IETF для параметров IEEE 802

PDF

Аннотация

Некоторые протоколы IETF используют форматы кадров Ethernet и параметры IEEE 802. В этом документе обсуждаются некоторые аспекты таких параметров и их использование в протоколах IETF, приведены соображения IANA по выделению точек под IANA Organizationally Unique Identifier (OUI), а также указаны некоторые значения для использования в документации. Документ заменяет RFC 7042.

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

Документ относится к категории Internet Best Current Practice.

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

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

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

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

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


1. Введение

В некоторых протоколах IETF применяются форматы и параметры кадров Ethernet и других кадров, связанных с IEEE 802 [IEEE802], включая MAC-адреса и идентификаторы протоколов. Регистрационное агентство (Registration Authority) IEEE [IEEE_RA] управляет выделением идентификаторов, используемых в сетях IEEE 802, в некоторых случаях выделяя блоки таких идентификаторов для дальнейшего распределения получившей блок организацией. IEEE RA также предоставляет ряд учебных пособий, относящихся к этим параметрам [IEEEtutorials].

Агентство IEEE RA выделило IANA уникальный идентификатор организации (Organizationally Unique Identifier или OUI) и соответствующий набор MAC-адресов, а также иные коды, основанные на полученном OUI. Этот документ описывает соображения IANA по распределению кодов в рамках IANA OUI, включая MAC-адреса и идентификаторы протоколов, а также указывает некоторые значения для использования в документации. Как указано в [RFC2606] и [RFC5737], использование значений кодов, зарезервированных для документации и примеров, снижает вероятность конфликтов и путаницы в результате использования кодов, выделенных для других целей (применения в реальных системах). В документе рассматривается несколько других случаев применения IETF кодов IEEE 802, включая коды IEEE 802 для контроля отказов связности (Connectivity Fault Management тлт CFM) [RFC7319] и связанных с производителями субтипов TLV (Vendor-Specific TLV Sub-Type) [RFC8520] протокола IEEE 802 для обнаружения локального канала (Link Local Discovery Protocol или LLDP) [IEEE802.1AB]. Документ также задаёт теги краткого двоичного представления объектов (Concise Binary Object Representation или CBOR) для MAC-адресов и OUI/CID.

Приведённые здесь описания правил и процедур [IANA] являются полномочными, но описания правил, процедур и стандартов регистрации IEEE имеют лишь информативный характер, а полномочные сведения IEEE следует получать из документов IEEE.

Этот документ включает процедуры [RFC8126], за исключением случаев противоречия данному документу. Здесь термин «ратификация IESG» (IESG Ratification), определённый в параграфе 5.1, указывает сочетание процедур Expert Review и IESG Approval, определённых в [RFC8126], где IESG Approval требуется лишь в тех случаях, когда эксперт не отклоняет запрос. Это не совпадает с трактовкой IESG Approval в [RFC8126].

1.1. Используемые обозначения

В документе применяется шестнадцатеричная нотация. Каждый октет (8-битовый байт) представляется двумя шестнадцатеричными цифрами, указывающими октет как целое число без знака. Последовательные октеты разделяются символом дефиса (-). В документе используется принятый в IETF (сетевой) порядок битов, хотя физически битов октета передаются по каналу IEEE [IEEE.802.3_2012], начиная с младшего (обратный по отношению к IETF).

AFN

Address Family Number [RFC4760] — номер семейства адресов.

CBOR

Concise Binary Object Representation [RFC8949] — краткое двоичное представление.

CFM

Connectivity Fault Management [RFC7319] — контроль отказов связности.

CID

Company Identifier — идентификатор компании (см. параграф 2.1.2).

DSAP

Destination Service Access Point — точка доступа к целевому сервису (см. раздел 3).

EUI

Extended Unique Identifier — расширенный уникальный идентификатор.

EUI-48

48-битовый EUI.

IEEE

Institute of Electrical and Electronics Engineers [IEEE] — Институт инженеров по электротехнике и электронике.

IEEE 802

LAN/MAN Standards Committee [IEEE802] — Комитет стандартизации локальных и городских сетей.

IEEE RA

IEEE Registration Authority [IEEE_RA] — Регистрационное агентство IEEE.

IEEE SA

IEEE Standards Association [IEEE_SA] — Ассоциация стандартов IEEE.

LLC

Logical Link Control — управление логическим каналом. Тип заголовка кадра, где протокол указывается полями LSAP отправителя и получателя (см. раздел 3).

LSAP

Link-Layer Service Access Point — точка доступа к услугам канального уровня (см. раздел 3).

MA-L

MAC Address Block Large — большой блок MAC-адресов.

MA-M

MAC Address Block Medium — средний блок MAC-адресов.

MA-S

MAC Address Block Small — мелкий блок MAC-адресов.

MAC

Media Access Control — управление доступом к среде (не Message Authentication Code).

MAC-48

48-битовый MAC-адрес. Термин устарел, для глобально уникальных адресов применяется EUI-48.

OUI

Organizationally Unique Identifier — уникальный идентификатор организации (см. параграф 2.1.2).

RRTYPE

DNS Resource Record type [RFC6895] — тип записи о ресурсе DNS.

SLAP

IEEE 802 Structured Local Address Plan [IEEE802_OandA] — структурированный план локальной адресации IEEE 802 (см. параграф 2.1.1).

SNAP

Subnetwork Access Protocol — протокол доступа в подсеть (см. раздел 3).

SSAP

Source Service Access Point — точка доступа к сервису у источника (см. раздел 3).

tag

Ттермин «тег» в этом документе используется в двух значениях. Теги Ethernet описаны в разделе 3, теги CBOR — в параграфе 2.4.

TLV

Type-Length-Value — тип-размер-значение.

**

Обозначение возведения в степень. Например, 2**24 указывает 2 в степени 24.

1.2. Регистрационное агентство IEEE

Изначально за регистрацию параметров Ethernet отвечала корпорация Xerox Corporation, а в 1986 г. было организовано агентство IEEE Registration Authority, доступное через Web [IEEE_RA].

IEEE Registration Authority работает под руководством совета управляющих (Board of Governors) Ассоциации стандартов IEEE (IEEE SA), а надзор за деятельность агентства осуществляет специальный комитет (IEEE Registration Authority Committee или IEEE RAC), являющийся комитетом Совета управляющих.

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

1.3. Идентификатор IANA OUI

Агентство IEEE RA выделило IANA уникальный идентификатор организации (OUI) 00-00-5E. В настоящее время нет значения OUI, зарезервированного для документации, но имеются коды в иерархии IANA OUI, описанные ниже.

1.4. Коды CFM

В стандарте IEEE Std 802.1Q [IEEE.802.1Q_2014] для IETF выделены два блока кодов 802 CFM — один для CFM OpCode, другой для CFM TLV Type (дополнительные сведения приведены в [RFC7319]). В реестре IANA Connectivity Fault Management (CFM) OAM IETF Parameters созданы субреестры для этих кодов. В данном документе эти блоки кодов больше не обсуждаются.

2. Параметры идентификаторов Ethernet

В этом разделе приведены обобщающие контекст сведения из [IEEE802_OandA]. При возникновении каких-либо расхождений преимущество отдаётся [IEEE802_OandA]. В параграфе 2.1 рассмотрены 48-битовые идентификаторы MAC, их связь с OUI и другими префиксами, а также выделение значений в рамках IANA OUI. В параграфе 2.2 рассматриваются 64-битовые идентификаторы, а в параграфе 2.3 обсуждаются другие идентификаторы IETF MAC, не связанные с IANA OUI. Параграф 2.4 задаёт теги CBOR для MAC-адресов и OUI/CID.

Историческое примечание. В устаревшем документе Internet-Draft Note [RAC_OUI] представлены дополнительные сведения о реестрах [IEEE802].

2.1. 48-битовые идентификаторы MAC, OUI и другие префиксы

48-битовые «адреса» MAC являются наиболее распространёнными идентификаторами интерфейсов Ethernet. Уникальные в глобальном масштабе идентификаторы этого типа называются EUI-48 (Extended Unique Identifier 48). Идентификатор EUI-48 состоит из префикса, выделяемого IEEE RA и дополнительных битов, назначаемых владельцем префикса. С 2024 г. выделяются префиксы трёх размеров, однако некоторые биты префикса могут иметь специальное значение, как показано на рисунке 1.

Таблица .

 

Размер префикса в битах

Имя

Представляемые владельцем биты MAC-48

24

MA-L

24

28

MA-M

20

36

MA-S

12

 

4 младших бита первого из 6 октетов 48-битового MAC имеют особое значение и называются далее битами M, X, Y, Z (рисунок 1).

  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  Z  Y  X  M| .  .  .  .  .  .  .  .| октеты 0+1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  .  .  .  .| .  .  .  .  .  .  .  .| октеты 2+3
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  .  .  .  .| .  .  .  .  .  .  .  .| октеты 4+5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Рисунок . Структура 48-битового MAC-адреса.


Для глобальных адресов X = 0 и MAC-адрес начинается с префикса размером 3 октета или больше, указывающего блок адресов MAC. За префиксом следуют дополнительные дополнительные биты3 до полного размера MAC-адреса. Например IEEE выделяет мелкий блок MAC (MA-S), где заданы первые 4 ½ октета (36 битов), а держателю MA-S оставлены полтора октета (12 битов), которые он может использовать для создания 48-битовых MAC-адресов. Префиксы могут иметь несколько размеров [IEEEtutorials].

Для 48-битовых MAC-адресов выделены теги AFN, DNS RRTYPE и CBOR, как указано в параграфах 2.4, 5.3 и 5.9.

В IEEE Std 802 описаны процедуры и правила выделения идентификаторов, связанных с IEEE 802 [IEEE802_OandA]. Документация IEEE RA по EUI, OUI и CID доступна в [IEEEtutorials].

2.1.1. Особые биты первого октета

В первом октете адреса IEEE MAC имебтся особые биты [IEEE802_OandA], описанные ниже.

M

Этот бит часто называют групповым или многоадресным (multicast). Для индивидуальных MAC-адресов бит сброшен (0). Установленный (1) бит означает многоадресную передачу (групповую или широковещательную). Значение бита не зависит от установки битов X, Y, Z.

X

Этот бит называют universal/local (универсальный/локальный), а раньше использовалось название Local/Global. Сброшенный (0) быт указывает глобальный MAC-адрес, контролируемый владельцем выделенного IEEE префикса. Ранее установка (1) этого бита указывала «локальный» адрес MAC, контролируемый местным оператором сети (см. также параграф 2.3). Если бит установлен и действует IEEE 802 SLAP, характер MAC-адреса может определяться битами Y и Z, как описано ниже.

Y и Z

Эти два бита не имеют особого значения при сброшенном (0) бите X. Если бит X и действует IEEE 802 SLAP, эти биты делят ранее единое пространство «локальных» адресов MAC на 4 квадранта, как описано ниже.

Таблица .

 

Бит Y

Бит Z

Квадрант

0

0

Назначен административно

0

1

Расширенный локальный адрес

1

0

Резерв

1

1

Назначен стандартом

 

Хотя локальный администратор может установить (1) бит X в любом адресе, необязательный план SLAP выделяет 4 квадранта для пространства «локальных» адресов с помощью битов Y и Z, как указано ниже

Administratively Assigned — назначен административно

MAC-адреса этого квадранта называют назначенными административно идентификаторами (Administratively Assigned Identifier). Они предназначены для произвольного локального распределения, например, случайного (см. также параграф 2.3.1).

Extended Local — расширенный локальный адрес

MAC-адреса этого квадранта называют расширенными локальными идентификаторами (Extended Local Identifier). Фактически они не являются «локальными» при использовании SLAP. Эти адреса доступны организации, которой выделен идентификатор CID (параграф 2.1.2), задающий другие 20 битов 24-битового префикса с X=1, Y=0 и Z = 1.

Reserved — резерв

MAC-адреса этого квадранта зарезервированы для будущего использования со SLAP4. До этого они могут распределяться локально (как Administratively Assigned Identifier), но при последующем использовании SLAP могут возникнуть конфликты с этим распределением.

Standard Assigned — назначен стандартом

MAC-адреса этого квадранта называют назначенными стандартом (Standard Assigned Identifier или SAI). SAI выделяются протоколом, заданным в стандартеiIEEE 802, например, [IEEE802.1CQ]5.

2.1.2. OUI и CID

Префиксы MA-L, MA-M и MA-S выделяются со сброшенным битом Local (X=0). Держатель OUI имеет исключительное право назначать групповые MAC-адреса, используя изменённый вариант назначенного OUI, где бит M = 1 (рисунок 1) [IEEEtutorials].

Бит Local (X) сброшен (0) для глобально уникальных идентификаторов EUI-48, назначаемых владельцем MAC-L или более длинного префикса. При установленном бите Local идентификатор исторически считается локальным и находящимся под контролем местного администратора сети. Однако в настоящее время имеются рекомендации по необязательному управлению локальным пространством адресов, как описано в параграфе 2.1.1. Если бит Local установлен (1), владелец OUI не имеет особых полномочий для идентификаторов MAC, где три первых октета соответствуют его OUI или началу более длинного префикса.

CID является 24-битовым идентификатором компании и выделяется нуждающимся в таких идентификаторах организациям. Этот идентификатор можно применять вместо OUI, но не требуется назначать дочерние глобальные адреса MAC. В CID биты X и Z установлены (1), а бит Y сброшен в 0 (см. рисунок 1).

Для идентификаторов OUI и CID назначены теги AFN и CBOR, как описано в параграфах 2.4, 5.3, 5.9.

2.1.3. Назначение 48-битовых MAC в иерархии IANA OUI

OUI 00-00-5E назначен IANA, как указано в параграфе 1.3. Это включает 224 48-битовых групповых идентификаторов от 01-00-5E-00-00-00 до 01-00-5E-FF-FF-FF и 224 индивидуальных EUI-48 от 00-00-5E-00-00-00 до 00-00-5E-FF-FF-FF. Эти идентификаторы разделены на субблоки, как описано ниже.

Индивидуальные (unicast) блоки по 28 адресов

00-00-5E-00-00-00 — 00-00-5E-00-00-FF — резерв, распределяемый по процедуре IESG Ratification (параграф 5.1).
00-00-5E-00-01-00 — 00-00-5E-00-01-FF — выделен для протокола VRRP [RFC5798].
00-00-5E-00-02-00 — 00-00-5E-00-02-FF — выделен для протокола IPv6 VRRP [RFC5798].
00-00-5E-00-52-00 — 00-00-5E-00-52-FF — используется для мелких блоков (на 2024 г. выделены 4 блока из 256). См. [EthernetNum].
00-00-5E-00-53-00 — 00-00-5E-00-53-FF — используется для документации в соответствии с эти документом.
00-00-5E-90-01-00 — 00-00-5E-90-01-FF — используется для мелких блоков, где нужны индивидуальные и групповые MAC-адреса (на 2024 г. выделено 1 из 256 значений). См. [EthernetNum].

Групповые (multicast)

01-00-5E-00-00-00 — 01-00-5E-7F-FF-FF — 223 адресов для IPv4 multicast [RFC1112].
01-00-5E-80-00-00 — 01-00-5E-8F-FF-FF — 220 адресов для MPLS multicast [RFC5332].
01-00-5E-90-00-00 — 01-00-5E-90-00-FF — 28 адресов для мелких блоков (на 2024 г. выделены 4 блока из 256). См. [EthernetNum].
01-00-5E-90-01-00 — 01-00-5E-90-01-FF — используется для мелких блоков, где нужны индивидуальные и групповые MAC-адреса (на 2024 г. выделено 1 из 256 значений). См. [EthernetNum].
01-00-5E-90-10-00 — 01-00-5E-90-10-FF — 28 адресов для документации в соответствии с эти документом.

Более подробные и актуальные сведения представлены в реестре IANA OUI Ethernet Numbers [EthernetNum].

2.1.4. Значения 48-битовых адресов MAC для документации

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

  • 00-00-5E-00-53-00 — 00-00-5E-00-53-FF для индивидуальных адресов.

  • 01-00-5E-90-10-00 — 01-00-5E-90-10-FF для групповых адресов.

2.1.5. Вопросы распределения 48-битовых IANA MAC

Назначения 48-битовых адресов в иерархии текущего и будущих IANA OUI (см. параграф 5.6) должны соответствовать приведённым ниже требованиям.

  • Назначение для стандартных целей (IETF Standard или иные стандарты, связанные с IETF).

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

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

  • Документирование в Internet-Draft или RFC.

Кроме того, выделение должно быть одобрено (см. процедуры в параграфе 5.1):

  • для мелких и средних блоков из 1, 2, 4, …, 32768, 65536 (20, 21, 22, …, 215, 216) идентификатора EUI-48 по процедуре Expert Review (параграф 5.1).

  • для больших блоков из 131072 (217) и более адресов EUI-48 по процедуре IESG Ratification ( параграф 5.1).

2.2. 64-битовые идентификаторы MAC

В IEEE определены 64-битовые идентификаторы MAC, включая EUI-64, которые применяются:

  • в IEEE Std 1394 [IEEE1394] (называется также FireWire и i.Link);

  • в IEEE Std 802.15.4 [IEEE802.15.4] ( называется также Zigbee);

  • в [InfiniBand];

  • в изменённой форме для создания некоторых идентификаторов интерфейсов IPv6, как описано в параграфе 2.2.1, хотя сейчас это признано устаревшим.

Добавление 5-октетного (40 юитов) расширения к 3-октетному (24 бита) OUI или более короткое расширение более длинного префикса [RAC_OUI], чтобы в сумме получилось 64 бита, создаёт EUI-64 битовый идентификатор в рамках OUI или более длинного префикса. Первый октет имеет особые биты, как и в идентификаторах EUI-48.

Для 64-битовых MAC-адресов выделены теги AFN, DNS RRTYPE и CBOR, как описано в параграфах 2.4, 5.3 и 5.9.

Далее рассматривается в основном «изменённая» форма идентификаторов EUI-64, однако те, кому такой идентификатор выделен, могут применять не изменённую форму MAC на любом канале, где 64-битовые идентификаторы применяются для интерфейсов.

2.2.1. Использование изменённых идентификаторов EUI-64 в IPv6

Описанный ниже подход к созданию идентификаторов IPv6 для интерфейсов в настоящее время признан устаревшим и взамен рекомендуется использовать метод, описанный в [RFC8064].

Идентификаторы EUI-64 служат в качестве 64 младших битов некоторых адресов IPv6 (параграф 2.5.1 и Приложение A к [RFC4291], Приложение A к [RFC5214]). При таком использовании EUI-64 бит X (universal/local) инвертируется для формирования «идентификатора Modified EUI-64» IETF. Примером изменённого индивидуального идентификатора EUI-64 в рамках IANA OUI может служить 02-00-5E-aa-bb-cc-dd-ee, где aa-bb-cc-dd-ee — это расширение. Первый октет имеет значение 02, а не 00, поскольку в изменённых EUI-64 бит X инвертируется по сравнению с EUI-48. Бит 0x02 (X или universal/local) в первом октете имеют уникальные в глобальном масштабе идентификаторы, тогда как идентификаторы со сброшенным (0) битом назначаются локально и не подлежат глобальному управлению. Бит X (universal/local) инвертирован для упрощения ввода идентификаторов локального действия администраторами сетей. В результате изменённые идентификаторы EUI-64 вида 1, 2 и т. д. (нули в начале не показаны) являются локальными. Без этого изменения локальные идентификаторы бы имели вид 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02 и т. д.

Как и в 48-битовых MAC бит M (0x01) в первом октете указывает групповой или широковещательны идентификатор.

Когда первые два октета расширения изменённого идентификатора EUI-64 имеют значение FF-FE, остальное расширение является 24-битовым значением, заданным владельцем OUI для EUI-48. Например, в идентификаторах 02-00-5E-FF-FE-yy-yy-yy и 03-00-5E-FF-FE-yy-yy-yy октеты yy-yy-yy являются частью (глобального индивидуального или группового идентификатора EUI-48), назначенной владельцем OUI (в данном случае IANA). Таким образом, держатель одного или множества идентификаторов EUI-48 в рамках IANA OUI имеет равное число изменённых идентификаторов EUI-64, которые могут формироваться вставкой FF-FE в середину идентификаторов EUI-48 и инвертированием бита X.

Некоторые изменённые идентификаторы EUI-64 в рамках IANA OUI зарезервированы для держателей адресов IPv4. Например, в 02-00-5E-FE-xx-xx-xx-xx октеты xx-xx-xx-xx указывают 32-битовый адрес IPv4. Владелец адреса IPv4 получает индивидуальный и групповой адрес EUI-64 address. Изменённые идентификаторы EUI-64 из диапазона от 02-00-5E-FE-F0-00-00-00 до 02-00-5E-FE-FF-FF-FF-FF фактически зарезервированы в ожидании спецификации адресов IPv4 класса E [RFC1112]. Однако в изменённых идентификаторах EUI-64 на основе адреса IPv4 бит universal/local следует устанавливать в соответствии с локальным или глобальным характером адреса IPv4, не забывая о том, что трактовка этого бита в изменённых идентификаторах EUI-64 обратна по отношению к обычным (неизменным) EUI-64.

2.2.2. Вопросы назначения IANA EUI-64

В таблице 3 показано распределение идентификаторов Modified EUI-64 в рамках IANA OUI. Как отмечено выше, соответствующие MAC-адреса могут формироваться добавлением бита 02 к первому октету. Во всех случаях соответствующие групповые 64-битовые адреса MAC, созданные путём добавления к первому октету бита 01, имеют такой же статус, как и указанные в таблице блоки 64-битовых индивидуальных адресов. Значения применяются с префиксом 02-00-5E для формирования изменённых адресов EUI-64.

Таблица . 64-битовые MAC-адреса IANA.

 

Адреса

Применение

Документ

00-00-00-00-00 — 0F-FF-FF-FF-FF

Резерв

RFC 9542

10-00-00-00-00 — 10-00-00-00-FF

Документация

RFC 9542

10-00-00-01-00 — EF-FF-FF-FF-FF

Не выделены

FD-00-00-00-00 — FD-FF-FF-FF-FF

Резерв

RFC 9542

FE-00-00-00-00 — FE-FF-FF-FF-FF

Держатели адресов IPv4

RFC 9542

FF-00-00-00-00 — FF-FD-FF-FF-FF

Резерв

RFC 9542

FF-FE-00-00-00 — FF-FE-FF-FF-FF

IANA EUI-48

RFC 9542

FF-FF-00-00-00 — FF-FF-FF-FF-FF

Резерв

RFC 9542

 

Выделения указанных в таблице резервных идентификаторов выполняется по процедуре IESG Ratification (параграф 5.1). Идентификаторы IANA EUI-64 в рамках IANA OUI выделяются в соответствии с указанными ниже требованиями.

  • Назначение для стандартных целей (IETF Standard или иные стандарты, связанные с IETF).

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

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

  • Документирование в Internet-Draft или RFC.

Кроме того, выделение должно быть одобрено (см. процедуры в параграфе 5.1):

  • для мелких и средних блоков из 1, 2, 4, …, 134217728, 268435456 (20, 21, 22, …, 227, 228) идентификатора EUI-64 по процедуре Expert Review (параграф 5.1).

  • для больших блоков из 536870912 (229) и более адресов EUI-64 по процедуре IESG Ratification ( параграф 5.1).

2.2.3. Значения EUI-64 для документации

Ниже приведены блоки неизмененных 64-битовых адресов MAC для использования в документации. Полученные из IPv4 адреса основаны на адресах IPv4 для документации [RFC5737], а полученные из MAC — на описанных выше адресах EUI-48 для документации.

Индивидуальные адреса для документации

00-00-5E-EF-10-00-00-00 — 00-00-5E-EF-10-00-00-FF — общее назначение.
00-00-5E-FE-C0-00-02-00 — 00-00-5E-FE-C0-00-02-FF, 00-00-5E-FE-C6-33-64-00 — 00-00-5E-FE-C6-33-64-FF и 00-00-5E-FE-CB-00-71-00 — 00-00-5E-FE-CB-00-71-FF — основаны на IPv4.
00-00-5E-FF-FE-00-53-00 — 00-00-5E-FF-FE-00-53-FF — основаны на EUI-48.
00-00-5E-FE-EA-C0-00-02, 00-00-5E-FE-EA-C6-33-64 и 00-00-5E-FE-EA-CB-00-71 — групповые адреса IPv4 на основе индивидуальных адресов IPv4 [RFC6034].

Групповые адреса для документации

01-00-5E-EF-10-00-00-00 — 01-00-5E-EF-10-00-00-FF — общее назначение.
01-00-5E-FE-C0-00-02-00 — 01-00-5E-FE-C0-00-02-FF, 01-00-5E-FE-C6-33-64-00 — 01-00-5E-FE-C6-33-64-FF и 01-00-5E-FE-CB-00-71-00 — 01-00-5E-FE-CB-00-71-FF — основаны на IPv4.
01-00-5E-FE-EA-C0-00-02, 01-00-5E-FE-EA-C6-33-64 и 01-00-5E-FE-EA-CB-00-71 IPv4 — групповые адреса IPv4 на основе индивидуальных адресов IPv4 [RFC6034].
01-00-5E-FF-FE-90-10-00 — 01-00-5E-FF-FE-90-10-FF — основаны на EUI-48.

2.3. Другие 48-битовые идентификаторы MAC, применяемые IETF

Ниже описаны ещё два блока 48-битовых адресов MAC, используемые IETF.

2.3.1. Идентификаторы с префиксом 33-33

Все 48-битовые идентификаторы MAC с префиксом 33-33 (232 групповых идентификатора MAC из диапазона 33-33-00-00-00-00 — 33-33-FF-FF-FF-FF) используются в соответствии с [RFC2464] для группового обмена IPv6. Во всех этих идентификаторах бит Group (последний в первом октете) установлен (1), как это требуется для корректной работы в качестве группового идентификатора с имеющимся оборудованием. Установлен (1) также бит Local, но в Ethernet со стандартной групповой адресацией IPv6 нужно учитывать такое использование адресов. Эти групповые MAC-адреса относятся к квадранту административно назначаемых адресов SLAP (параграф 2.1.1).

Историческое замечание. При разработке IPv6 было принято использовать цифру 3 для неизвестных значений и примеров, 3333 Coyote Hill Road, Palo Alto, California — это адрес исследовательского центра Palo Alto (Palo Alto Research Center или PARC), ранее называвшегося Xerox PARC. Спецификация Ethernet была разработана Digital Equipment Corporation, Intel Corporation и Xerox Corporation. До IEEE [IEEE.802.3_2012] протокол Ethernet иногда называли DIX Ethernet по первым буквам названий этих компаний.

2.3.2. Серия CF

В информационном [RFC2153] 3-октетные значения CF-00-00 — CF-FF-FF объявлены как OUI, доступные для распределения IANA производителям программ для использования с PPP [RFC1661] или иных применений, где не требуется OUI от IEEE. При использовании в качестве 48-битовых префиксов MAC в этих значениях особые биты Z, Y, X (Local) и M (Group) в конце первого октета будут иметь значение 1, тогда как в выделенных IEEE идентификаторах OUI биты X и M сброшены (0), а во всех CID сброшены биты Y и M. Таким образом, конфликтов между OUI серии CF и выделенными IEEE значениями OUI/CID не возникает. Групповые MAC-адреса, созданные с OUI серии CF, попадают в квадрант SLAP Standard Assigned (параграф 2.1.1). Бит Group не имеет значения для PPP. В [RFC2153] сказано «Серия CF0000 была выбрана для удобства запоминания, чтобы соответствовать PPP NLPID ‘CF’». Дополнительные сведения об идентификаторах протоколов сетевого уровня (Network Layer Protocol Identifier или NLPID) приведены в [RFC6328].

CF-00-00 является зарезервированным, CF-00-00-00-00-00 — групповой идентификатор указанный IANA как используемый для шлейфовых тестов Ethernet.

За срок более 10 лет было выделено лишь несколько значений из серии CF, указанных в реестрах IANA OUI Ethernet Numbers» [EthernetNum] и Point-to-Point (PPP) Protocol Field Assignments [PPPNum].

2.3.2.1. Отличия от RFC 2153

Раздел «Взаимодействие с IANA» [RFC2153] обновлён после одобрения [RFC5342] и остаётся в этом состоянии (нет технических изменений).

  • Использование идентификаторов серии CF, выделяемых IANA, отменено.

  • Агентству IANA предписано в дальнейшем не выделять значений в серии CF.

2.4. Теги CBOR

CBOR [RFC8949] — это формат данных, цели разработки которого включают возможность очень малых размеров кода, достаточно малый размер сообщений и расширяемость. В CBOR элемент данных может приложен к тегу CBOR для обеспечения дополнительной семантики, задаваемой тегом. Элементы данных (поля) с тегами CBOR не применяются в полях адресов IEEE 802, но могут быть полезны в элементах протокольных сообщений с кодированием CBOR.

Агентство IANA выделило значение 48 как тег CBOR для указания MAC-адреса. Приложенный к тегу элемент данных является строкой октетов, размер которой указывает, представлен ли 48-битовый (6 октетов) или 64-битовый (8 октетов) MAC-адрес. Если в будущем для размера адресов MAC будет применяться иное значение, кратное 8 битам, например 128 битов (16 октетов) использование тега 48 сохранится.

Тег CBOR 1048 выделен IANA для указания идентификаторов организаций OUI, CID или CF. Приложенный элемент данных является строкой из 3 октетов для размещения 24-битовых OUI и CID (параграф 2.1.2).

3. Параметры протокола Ethernet

Параметры протокола Ethernet позволяют указать в начале кадра его содержимое, например, пакет IPv4 или IPv6. Имеется два типа параметров идентификатора протокола [EthernetNum].

EtherType

16-битовый идентификатор, который при рассмотрении как целого числа без знака имеет значение не меньше 0x0600. На рисунке 2 показан простейший случай, где EtherType данных протокола в кадре указывается сразу после MAC-адресов отправителя и получателя. В [IEEE802_OandA] заданы два EtherType для локальных экспериментов — 0x88B5 и 0x88B6.
  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Destination MAC Address                     ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Source MAC Address                          ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  EtherType (не меньше 0x0600)                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Protocol Data                               ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Рисунок . Маркировка EtherType.


LSAP

Это 8-битовые идентификаторы протокола, размещаемые парой после поля, указывающего размер кадра. Это размер должен быть меньше 0x5DD (при рассмотрении как целого числа без знака), иначе его можно ошибочно принять за EtherType. Однако вместо размера может использоваться инкапсуляция LLC с EtherType = 0x8870 [IEEE802.1AC] в качестве индикатора незаданного размера. Значение LSAP указываются парами, где один элемент указывает обработчик протокола на стороне источника (SSAP), другой — на стороне получателя (DSAP), однако на практике разные значения этих элементов встречаются сравнительно редко. На рисунке 3 показан простейший случай, где поле размера указано сразу после MAC-адресов отправителя и получателя. На этом рисунке поле CTL (control) со значением 3 указывает службу дейтаграмм. Такой тип указания протокола иногда называют управлением логическим каналом (Logical Link Control или LLC).
  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Destination MAC Address                     ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Source MAC Address                          ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Frame length (или 0x8870)                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  DSAP                 |  SSAP                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  CTL = 0x03           |  Protocol Data       ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Рисунок . Маркировка LSAP.


Концепция маркировки EtherType была расширена для маркировки «тегами» Ethernet. Тег Ethernet в этом смысле является префиксом, тип которого указан EtherType, за которым следует другой тег, EtherType или индикатор протокола точки доступа к сервису канального уровня (LLC Link-Layer Service Access Point или LSAP) для «основного» тела кадра. Обычно в среде [IEEE802_OandA] теги имеют фиксированный размер и не включают кодирования своего размера, Например, C-Tag (ранее Q-Tag) [IEEE.802.1Q_2014] указывает для кадра VLAN клиента и приоритет. Обрабатывающее кадр устройство в общем случае не может безопасно обрабатывать что-либо в кадре после непонятного EtherType.

Значения EtherType и LSAP не выделяются IANA, их назначает IEEE RA [IEEE_RA] (см. параграф 1.2 и Приложение B). Однако для LSAP и EtherType имеются механизмы расширения, позволяющие использовать их с 5-октетными идентификаторами протокола Ethernet в рамках OUI, включая назначенные IANA в иерархии IANA OUI.

При использовании для кадра формата IEEE 802 LLC format (Subnetwork Access Protocol (SNAP)) [IEEE802_OandA] идентификатор протокола на основе OUI можно выразить в форме xx-xx-AA-AA-03-yy-yy-yy-zz-zz, где xx-xx — размер кадра (см. выше), который должен быть достаточно малым, чтобы не путаться с EtherType, AA — октет LSAP, указывающий такое применение и иногда называемый точкой доступа к услугам SNAP (SNAP Service Access Point или SNAP SAP), 03 — октет управления LLC, указывающий службу дейтаграмм, yy-yy-yy — OUI, а zz-zz — номер протокола в рамках OUI, назначенный владельцем OUI. 5-октетный размер таких идентификаторов протокола на основе OUI с октетом управления LLC (0x03) обеспечивает выравнивание по 16-битовой границе.

При использовании EtherType для указания основного типа тела кадра доступен особый тип 0x88B7 (OUI Extended EtherType). В этом случае тело кадра может начинаться с последовательности 88-B7-yy-yy-yy-zz-zz, где yy-yy-yy и zz-zz имеют такой же смысл, как в описанном выше формате SNAP, однако для формате с EtherType = 0x88B7 не сохраняется выравнивание по 16-битовым границам.

В формате SNAP возможно использование произвольного EtherType. Это делается указанием EtherType в поле zz-zz после OUI, содержащего лишь нули (00-00-00), и имеет вид xx-xx-AA-AA-03-00-00-00-zz-zz, где zz-zz — EtherType.

Помимо маркировки содержимого кадра, тип протокола IEEE 802 указывается в сообщениях протокола распознавания следующего узла (Next Hop Resolution Protocol) [RFC2332] сетей с множественным доступом без широковещания (Non-Broadcast Multi-Access или NBMA). В таких сообщениях предусмотрены 2-октетные EtherType и типы протокола на основе OUI. 16-битовые значения EtherType присутствуют также в заголовках базовой маршрутной инкапсуляции (Generic Routing Encapsulation или GRE) [RFC2784] и базовой инкапсуляции для виртуализации сетей (Generic Network Virtualization Encapsulation или Geneve) [RFC8926].

3.1. Назначение протоколов Ethernet в иерархии IANA OUI

Доступны 2-октетные номера протоколов в рамках IANA OUI. Например, в 88-B7-00-00-5E-qq-qq или xx-xx-AA-AA-03-00-00-5E-qq-qq поле qq-qq указывает номер протокола..

Было выделено несколько значения из 216 номеров протоколов диапазона 00-00-5E-00-00 — 00-00-5E-FF-FF (см. [EthernetNum]). Крайние значения 00-00-5E-00-00 и 00-00-5E-FF-FF зарезервированы и для их назначения требуется процедура IESG Ratification (см. параграф 5.1). Назначения номеров протокола (qq-qq) в рамках IANA OUI должны удовлетворять приведённым ниже требованиям.

  • Использование в стандарте (IETF Standard или иной стандарт, связанный с работой IETF).

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

  • Документирование в Internet-Draft или RFC.

  • Протокол не имеет EtherType (значение EtherType моет использоваться напрямую или, в случае LSAP, — вместе с SNAP SAP путём размещения OUI 00-00-00 перед EtherType, как описано выше).

Кроме того, для выделения значений должна использоваться процедура Expert Review (или IESG Ratification для зарезервированных значений), как описано в параграфе 5.1.

3.2. Номер протокола для документации

Номер протокола 0x0042 в рамках IANA OUI (т. е. 00-00-5E-00-42) выделен для использования в документации.

4. Другие параметры на основе OUI/CID

В некоторых протоколах IEEE 802 и др. предусмотрены основанная на OUI или CID параметры, помимо описанных выше. Такие параметры обычно включают OUI или CID, а также 1 октет дополнительного значения. Они называются фирменными (Organizationally Specific) параметрами, а иногда (менее точно), параметрами производителя (vendor specific). Параметры имеют вид yy-yy-yy-zz, где yy-yy-yy — OUI или CID, а zz — дополнительное значение. Примером такого параметра является селектор шифра (Cipher Suite Selector) [IEEE.802.11_2012].

Значения могут выделяться в рамках IANA OUI для других параметров на основе OUI по процедуре Expert Review, за исключением того, что для дополнительных значения, содержащих только 0 (00-00-5E-00) или только 1 (00-00-5E-FF), применяется процедура IESG Ratification (параграф 5.1), а дополнительное значение 0x42 (00-00-5E-42), дополненное нулями справа для выравнивания, служит для примеров в документации.

Значения параметров на основе IANA OUI должны выделяться для стандартов (IETF Standard или иной стандарт, связанный с IETF) и документироваться в Internet-Draft или RFC. При первоначальном выделении значения для конкретного параметра создаётся реестр IANA, включающий это значение, а также последующие значения этого параметра в рамках IANA OUI. Эксперт может задать имя для такого реестра. Если для такого параметра нужны правила, отличающиеся от приведённых выше, следует подготовить (обновить) RFC со статусом BCP или Standards Track RFC с указанием новых правил и параметра.

4.1. Тип TLV для IETF LLDP

Пример такого параметра на основе IANA OUI представлен в [RFC8520]. Он включает тип Organizationally Specific TLV для анонсирования унифицированного идентификатора ресурса (Uniform Resource Locator или URL) описания использования от производителя (Manufacturer Usage Description или MUD) в протоколе IEEE для обнаружения канального уровня (Link Local Discovery Protocol или LLDP) [IEEE802.1AB]. Дополнительно в IETF предложено использование кодов из этого пространства [BGP11dp] (см. параграф 5.8.).

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

Этот документ касается взаимодействия с IANA по вопросам назначения параметров Ethernet в связи с IANA OUI и смежным вопросам.

Примечание. Группа реестров (web-страница) IANA OUI Ethernet Numbers предназначена для реестров значений в рамках IANA OUI, а группа реестров IEEE 802 Numbers содержит списки значений, выделенных IEEE RA.

Документ не создаёт новых реестров IANA и не меняет имеющихся назначений.

Значения MAC-адресов и номеров протоколов для документации выделены [RFC7042].

5.1. Expert Review и IESG Ratification

В этом параграфе заданы процедуры Expert Review и IESG Ratification для MAC, протоколов и других идентификаторов на основе IANA OUI. В качестве эксперта выступает один или несколько человек, назначенных и работающих по поручению IESG.

5.1.1. Рекомендации для Expert Review

Описанная здесь процедура Expert Review соответствует aIANA Expert Review из [RFC8126].

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

5.1.2. Процедуры Expert Review и IESG Ratification

Может иметь смысл выделение очень больших частей пространства идентификаторов MAC (в настоящее время выделено лишь 1 значение из пространства индивидуальных 48-битовых кодов IANA и 1 значение из 16 доступных в пространстве групповых кодов). В этих случаях, а также при выделении «резервных» значений требуется процедура IESG Ratification для Expert Review с одобрением запроса, как описано ниже. Это можно считать сочетанием процедур Expert Review и IESG Approval, заданных в [RFC8126]. Процедура IESG Approval требуется лишь в тех случаях, когда эксперты не отклоняют запрос. Сама процедура описана ниже.

Заявитель заполняет соответствующий шаблон из Приложения A и направляет его IANA по адресу <iana@iana.org>.

Агентство IANA передаёт шаблон назначенному эксперту. Если эксперт берет самоотвод или не отвечает на запрос, IANA может выбрать другого назначенного эксперта, а при его отсутствии — обратиться в IESG.

Если IANA получает неодобрение от эксперта, выбранного для рассмотрения шаблона заявки, эта заявка отклоняется. Эксперту следует указывать причину отклонения, которую IANA передаёт заявителю.

При использовании процедуры Expert Review

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

При использовании процедуры IESG Ratification

Сначала выполняется процедура Expert Review. Если эксперты отклоняют запрос, они просто информируют IANA, а те — заявителя. Если же эксперты считают, что заявку следует одобрить, или имеются неясности и предположения о том, что следует привлечь внимание IESG, эксперты информируют IANA о своём мнении и IANA пересылает заявку вместе с мнениями экспертов в IESG. Окончательное решение о выделении значений или отказе должно приниматься IESG. Это может быть сделано через элемент управления в телечате IESG, как для других типов запросов. Если IESG не подтверждает положительное мнение экспертов или отклоняет заявку, для которой у экспертов нет уверенности, заявка отвергается. В иных случаях заявка одобряется. IESG информирует о своём решении экспертов и IANA. В случае отказа IESG следует указать его причину, которую IANA сообщает заявителю.

5.2. Смена имени группы реестров IANA (Web-страницы)

Для ясности и сходства с реестром IANA IEEE 802 Numbers группа реестров IANA Ethernet Numbers переименована в IANA OUI Ethernet Numbers.

Поскольку этот документ заменяет [RFC7042], ссылки на [RFC7042] в реестрах IANA IEEE 802 Numbers и IANA OUI Ethernet Numbers заменены ссылками на данный документ. В других реестрах IANA ссылки на [RFC7042] сохранены.

5.3. AFN и RRTYPE для MAC-адресов

Агентство IANA выделило значения Address Family Number (AFN) для MAC-адресов, как указано в таблице 4.

Таблица .

 

AFN

Десятичный

Шестнадцатеричный

Документ

48-битовый MAC

16389

0x4005

[RFC7042]

64-битовый MAC

16390

0x4006

[RFC7042]

OUI

16391

0x4007

[RFC7961]

Младшие 24 бита 48-битовых MAC-адресов — MAC/24

16392

0x4008

[RFC7961]

Младшие 40 битов 64-битовых MAC-адресов — MAC/40

16393

0x4009

[RFC7961]

 

Агентство IANA выделило значения DNS RRTYPE [RFC6895] для MAC-адресов, как указано в таблице 5.

Таблица .

 

Код RRTYPE

Данные

Обозначение

Десятичный

Шестнадцатеричный

Документ

48-битовый MAC

EUI48

108

0x006C

[RFC7043]

64-битовый MAC

EUI64

109

0x006D

[RFC7043]

 

5.4. Информационный материал группы реестров IANA

IANA поддерживает группу реестров, в настоящее время реализованную в форме web-страницы, для EtherType, OUI и групповых адресов, выделенных в рамках OUI, отличных от IANA OUI. Эта группа называется IEEE 802 Numbers. IANA обновляет сведения в реестрах при изменениях и одобрении значений экспертами.

5.5. Процесс назначения EtherType

Подача в IEEE RA заявки на выделение EtherType для протокола IETF требует процедуры IESG Approval, как указано в Приложении B. Для снижения путаницы этот процесс обычно выполняет главный эксперт реестра EtherType в группе IEEE 802 Numbers, как описано ниже (см. также параграф 5.4).

После IESG Approval для запроса EtherType IESG следует передать этот вопрос в IANA. В любом случае IANA будет просить эксперта реестра EtherType выполнить процесс запроса EtherType в IEEE RA [IEEE_RA]. Этот путь указан потому, что IESG обычно имеет дело с IANA для действий по выделению значений, а IANA следует знать, кто из экспертов реестра EtherType доступен (обычно запрос на выделение EtherType передаётся основному эксперту).

Ниже приведён примерный текст Internet-Draft, где требуется назначение от IANA и IEEE. Шаблон YYY заменяется разъяснением, для чего (почему) требуется EtherType с достаточным уровнем детализации, и обычно включает ссылки на соответствующие части Internet-Draft.

X. Assignment Considerations (вопросы назначение).

X.1. IEEE Assignment Considerations (вопросы назначения в IEEE).

IESG предлагается одобрить передачу в IEEE RA запроса на EtherType для YYY (IESG следует сообщить о свом одобрении в IANA и связанным с документом лицам; IANA пересылает IESG Approval эксперту реестра EtherType из группы IEEE 802 Numbers, который передаёт заявку в IEEE RA, информируя об этом IANA).

X.2. IANA Considerations (взаимодействие с IANA).

5.6. Исчерпание OUI

При исчерпании пространства индивидуальных или групповых идентификаторов EUI-48 в рамках OUI 00-00-5E на 90% и более IANA следует запросить в IEEE RA дополнительный идентификатор OUI для последующих назначений IANA. Назначенным экспертам следует контролировать распределение идентификаторов и информировать IANA о его исчерпании.

5.7. Таблица MAC-адресов IANA OUI

Этот документ вносит указанные ниже изменения в примечания к реестрам IANA Unicast 48-bit MAC Addresses, IANA Multicast 48-bit MAC Addresses и IANA 64-bit MAC Addresses. Кроме того, в этих реестрах обновляются ссылки, как указано в параграфе 5.2.

В Примечания к IANA Unicast 48-bit MAC Addresses и IANA Multicast 48-bit MAC Addresses вносится следующее изменение:

Эти значения используют префикс 00-00-5E (см. параграф 2.1.3 в RFC 9542).

В Примечания к IANA 64-bit MAC Addresses вносится следующее изменение:

Эти значения используют префикс 00-00-5E для формирования индивидуальных MAC-адресов и 01-00-5E — для групповых, а также префикс 02-00-5E для индивидуальных изменённых адресов EUI-64 и 03-00-5E — для групповых. Дополнительные сведения представлены в RFC 9542, в частности, в параграфе 2.2.2.

5.8. Субтипы IANA LLDP TLV

Агентство IANA перенесло реестр IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes из группы IEEE 802 Numbers в группу IANA OUI Ethernet Numbers, поскольку коды в этом реестре назначаются IANA. Кроме того, в реестр добавлена ссылка на RFC 9542. Обновлены также три записи этого реестра, как показано в таблице 6.

Таблица .

 

Значение

Описание

Документ

0

Резерв

RFC 9542

42

Пример для использования в документации

RFC 9542

255

Резерв

RFC 9542

 

Записи для значений 1 (MUD), 2-41 (не выделены) и 43-254 (не выделены) не изменились.

5.9. Назначение тегов CBOR

Агентство IANA выделило два тега CBOR Tags в реестре Concise Binary Object Representation (CBOR) Tags (таблица 7).

Таблица .

 

Тег

Элемент данных

Назначение

Документ

48

Строка байтов

Адрес IEEE MAC

RFC 9542

1048

Строка байтов

IEEE OUI/CID

RFC 9542

 

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

Этот документ посвящено назначению параметров IEEE 802, переданных в IANA (в частности, в рамках IANA OUI), и тесно связанным с этим вопросам. Документ не оказывает прямого влияния на безопасность, за исключением указанного ниже.

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

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

MAC-адрес идентифицирует физический или виртуальный интерфейс и может применяться для отслеживания устройства с этим интерфейсом, а, следовательно, и пользователей такого устройства. В [madinas] рассматриваются связанные с этим вопросы приватности, а также обсуждается применение случайных MAC-адресов для частичного снижения такой угрозы. В [RFC7043] рассматриваются вопросы безопасности и приватности при публикации MAC-адресов в DNS.

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

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

[IEEE.802.1Q_2014] IEEE, «IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks», IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, 18 December 2014, <http://ieeexplore.ieee.org/servlet/opac?punumber=6991460>.

[IEEE802.1AB] IEEE, «IEEE Standard for Local and metropolitan area networks — Station and Media Access Control Connectivity Discovery», IEEE Std 802.1AB-2016, DOI 10.1109/IEEESTD.2016.7433915, March 2016, <https://doi.org/10.1109/IEEESTD.2016.7433915>.

[IEEE802_OandA] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.

IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture — Amendment 2: Local Medium Access Control (MAC) Address Usage», IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, <https://doi.org/10.1109/IEEESTD.2017.8016709>.

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

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

[BGP11dp] Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, «BGP Logical Link Discovery Protocol (LLDP) Peer Discovery», Work in Progress, Internet-Draft, draft-acee-idr-lldp-peer-discovery-17, 4 January 2024, <https://datatracker.ietf.org/doc/html/draft-acee-idr-lldp-peer-discovery-17>.

[EthernetNum] IANA, «IANA OUI Ethernet Numbers», <https://www.iana.org/assignments/ethernet-numbers>.

[IANA] IANA, «Internet Assigned Numbers Authority», <https://www.iana.org>.

[IEEE] IEEE, «Institute of Electrical and Electronics Engineers», <https://www.ieee.org>.

[IEEE.802.11_2012] IEEE, «IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, 5 April 2012, <http://ieeexplore.ieee.org/servlet/opac?punumber=6178209>.

[IEEE.802.3_2012] IEEE, «IEEE Standard for Ethernet», IEEE 802.3-2012, DOI 10.1109/ieeestd.2012.6419735, 24 January 2013, <http://ieeexplore.ieee.org/servlet/opac?punumber=6419733>.

[IEEE1394] IEEE, «IEEE Standard for a High-Performance Serial Bus», IEEE Std 1394-2008, DOI 10.1109/IEEESTD.2008.4659233, October 2008, <https://doi.org/10.1109/IEEESTD.2008.4659233>.

[IEEE802] IEEE 802, «IEEE 802 LMSC», <https://www.ieee802.org>.

[IEEE802.15.4] IEEE, «IEEE Standard for Low-Rate Wireless Networks», IEEE Std 802.15.4-2020, DOI 10.1109/IEEESTD.2020.9144691, July 2020, <https://doi.org/10.1109/IEEESTD.2020.9144691>.

[IEEE802.1AC] IEEE 802, «IEEE Standard for Local and metropolitan area networks — Media Access Control (MAC) Service Definition», IEEE Std 802.1AC-2016, DOI 10.1109/IEEESTD.2017.7875381, March 2017, <https://doi.org/10.1109/IEEESTD.2017.7875381>.

[IEEE802.1CQ] IEEE, «Draft Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment», draft 0.8, IEEE Std 802.1CQ/D0.8, July 2022.

[IEEEtutorials] IEEE, «Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)», August 2017, <https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf>.

[IEEE_RA] IEEE, «Registration Authority», <https://standards.ieee.org/products-programs/regauth/>.

[IEEE_SA] IEEE, «IEEE Standards Association», <https://standards.ieee.org>.

[InfiniBand] InfiniBand Trade Association, «InfiniBand Architecture Specification Volume 1», November 2007, <https://www.infinibandta.org/>.

[madinas] Zúñiga, JC., Bernardos, CJ., Ed., and A. Andersdotter, «Randomized and Changing MAC Address state of affairs», Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-12, 28 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-12>.

[PPPNum] IANA, «Point-to-Point (PPP) Protocol Field Assignments», <https://www.iana.org/assignments/ppp-numbers>.

[RAC_OUI] Parsons, G., «OUI Registry Restructuring», Work in Progress, Internet-Draft, draft-ieee-rac-oui-restructuring-01, 9 September 2013, <https://datatracker.ietf.org/doc/html/draft-ieee-rac-oui-restructuring-01>.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

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

[RFC2153] Simpson, W., «PPP Vendor Extensions», RFC 2153, DOI 10.17487/RFC2153, May 1997, <https://www.rfc-editor.org/info/rfc2153>.

[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, «NBMA Next Hop Resolution Protocol (NHRP)», RFC 2332, DOI 10.17487/RFC2332, April 1998, <https://www.rfc-editor.org/info/rfc2332>.

[RFC2464] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.

[RFC2606] Eastlake 3rd, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <https://www.rfc-editor.org/info/rfc2606>.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.

[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, «Etymology of «Foo»», RFC 3092, DOI 10.17487/RFC3092, April 2001, <https://www.rfc-editor.org/info/rfc3092>.

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

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)», RFC 5214, DOI 10.17487/RFC5214, March 2008, <https://www.rfc-editor.org/info/rfc5214>.

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, «MPLS Multicast Encapsulations», RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.

[RFC5342] Eastlake 3rd, D., «IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters», RFC 5342, DOI 10.17487/RFC5342, September 2008, <https://www.rfc-editor.org/info/rfc5342>.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

[RFC6034] Thaler, D., «Unicast-Prefix-Based IPv4 Multicast Addresses», RFC 6034, DOI 10.17487/RFC6034, October 2010, <https://www.rfc-editor.org/info/rfc6034>.

[RFC6328] Eastlake 3rd, D., «IANA Considerations for Network Layer Protocol Identifiers», BCP 164, RFC 6328, DOI 10.17487/RFC6328, July 2011, <https://www.rfc-editor.org/info/rfc6328>.

[RFC6895] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

[RFC7042] Eastlake 3rd, D. and J. Abley, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.

[RFC7043] Abley, J., «Resource Records for EUI-48 and EUI-64 Addresses in the DNS», RFC 7043, DOI 10.17487/RFC7043, October 2013, <https://www.rfc-editor.org/info/rfc7043>.

[RFC7319] Eastlake 3rd, D., «IANA Considerations for Connectivity Fault Management (CFM) Code Points», BCP 191, RFC 7319, DOI 10.17487/RFC7319, July 2014, <https://www.rfc-editor.org/info/rfc7319>.

[RFC7961] Eastlake 3rd, D. and L. Yizhou, «Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV», RFC 7961, DOI 10.17487/RFC7961, August 2016, <https://www.rfc-editor.org/info/rfc7961>.

[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, «Recommendation on Stable IPv6 Interface Identifiers», RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8520] Lear, E., Droms, R., and D. Romascanu, «Manufacturer Usage Description Specification», RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.

[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., «Geneve: Generic Network Virtualization Encapsulation», RFC 8926, DOI 10.17487/RFC8926, November 2020, <https://www.rfc-editor.org/info/rfc8926>.

[RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, «Link-Layer Address Assignment Mechanism for DHCPv6», RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.

[RFC8948] Bernardos, CJ. and A. Mourad, «Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6», RFC 8948, DOI 10.17487/RFC8948, December 2020, <https://www.rfc-editor.org/info/rfc8948>.

[RFC8949] Bormann, C. and P. Hoffman, «Concise Binary Object Representation (CBOR)», STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

Приложение A. Шаблоны

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

A.1. Шаблон идентификатора или блока идентификаторов EUI-48/EUI-64

Applicant Name:

Applicant Email:

Applicant Telephone: (с указанием кода страны)

Use Name: (короткое имя параметра, например, Foo Protocol [RFC3092])

Document: (Internet-Draft или RFC со спецификацией применения идентификатора или блока идентификаторов)

Specify whether this is an application for EUI-48 or EUI-64 identifiers:

Size of Block requested: (должен быть равен целой степени 2, включая 20)

Specify multicast, unicast, or both:

A.2. Шаблон номера протокола на основе IANA OUI/CID

Applicant Name:

Applicant Email:

Applicant Telephone: (с указанием кода страны)

Use Name: (короткое имя параметра, например, Foo Protocol)

Document: (Internet-Draft или RFC со спецификацией применения номера протокола)

Note: (любые дополнительные сведения)

A.3. Шаблон для других параметров на основе IANA OUI/CID

Applicant Name:

Applicant Email:

Applicant Telephone: (с указанием кода страны)

Protocol where the OUI/CID-Based Parameter for which a value is being requested appears: (например, выбор Cipher Suite в IEEE 802.11)

Use Name: (короткое имя для применения кода, например, Foo Cipher Suite» [RFC3092])

Document: ( Internet-Draft или RFC со спецификацией применения параметра на основе IANA OUI)

Note: (любые дополнительные сведения)

Приложение B. EtherType

В этом приложении представлена копия заявления IESG (1 мая 2023 г.) о получении новых IETF EtherType (B.1). Отметим, что имеется информационный реестр IANA для некоторых важных EtherType, заданных для протоколов IETF или IEEE 802 [IANA]. Может быть полезна также страница IEEE RA для EtherType (см. раздел 3) <https://standards.ieee.org/regauth/ethertype/eth.txt>.

B.1. Заявление IESG для EtherType

From: IESG

Date: 1 May 2023

Регистрационное агентство IEEE (IEEE RA) под надзором IEEE Registration Authority Committee (IEEE RAC) выделило значения EtherType (см. https://standards.ieee.org/products-programs/regauth/ethertype/). В спецификациях некоторых протоколов IETF применяются значения EtherType. Все случаи применения EtherType подлежат техническому рецензированию IEEE RA на предмет соответствия правилам.

Поскольку ресурс EtherType достаточно ограничен, IEEE RAC сообщает, что не будет выделять новых EtherType для спецификаций протоколов IETF, пока IESG не одобрит спецификацию протокола для публикации как RFC. В исключительных случаях IEEE RA может рассмотреть раннее выделение EtherType для находящегося в разработке протокола IETF при получении запроса, одобренного IESG.

Для информирования IEEE RAC об одобрении IESG запроса на выделение параметров Ethernet для протокола IETF все будущие запросы EtherType для протоколов IETF будут направляться в IESG.

Отметим, что EtherType для локальных экспериментов были выделены IEEE 8026 для использования в процессе разработки и экспериментах.

Приложение C. Отличия от RFC 7042

Этот документ отменяет [RFC7042] и вносит указанные ниже изменения. Тем не менее, заполненный шаблон, на основе которого было выделено значение для протокола, основанное на IANA OUI, для использования в документации, сохраняется в соответствии с Приложением C к [RFC7042].

  • Добавлены сведения о префиксах EUI MA-M (28 битов) и MA-S (36 битов), выделяемых IEEE RA.

  • Добавлены сведения о разделении пространства «локальных» MAC-адресов на 4 квадранта в рамках SLAP [IEEE802_OandA].

  • Включено Заявление IESG Statement для EtherType (Приложение B.1) и более подробно описаны процедуры IETF для подачи заявок в IEEE RA на значения EtherType для использования в протоколах IETF (параграф 5.5).

  • Упомянуты коды IEEE 802 CFM, выделенные IETF ( параграф 1.4).

  • Упомянут элемент данных Organizationally Specific LLDP, выделенный в рамках IANA OUI, и создан реестр для будущих значений ( параграф 4.1).

  • Уточнены некоторые детали в параграфе 5.1 для процедур Expert Review и IESG Ratification.

  • Заданы теги CBOR для MAC-адресов и OUI/CID ( параграф 2.4).

  • Добавлено требование к полю версии для выделения номеров протоколов в рамках IANA OUI ( параграф 3.1).

  • Упомянуто использование EtherType в заголовках инкапсуляции Geneve [RFC8926] (раздел 3).

  • Добавлено сочетание процедур Expert Review и IESG Approval как часть процедуры IESG Ratification.

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

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

Для текущего документа: Carsten Bormann, Bob Hinden, рабочая группа IEEE 802.1, Éric Vyncke, Dale Worley, Amanda Baber.

Для [RFC7042] (отменен этим документом): David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, Dan Romascanu.

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

Donald E. Eastlake 3rd
Independent
2386 Panoramic Circle
Apopka, Florida 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com, donald.eastlake@futurewei.com
 
Joe Abley
Cloudflare
Amsterdam
The Netherlands
Phone: +31 45 56 36 34
Email: jabley@strandkip.nl
 
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Phone: +86-13809002299
Email: liyizhou@huawei.com

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

nmalykh@protokols.ru


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

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

3В оригинале некорректно говорится о дополнительных октетах, см. https://www.rfc-editor.org/errata/eid7952. Прим. перев.

4Tне существует автоматизированного способа определить, настроена ли локальная сеть на SLAP и/или работу в соответствии с ним.

5Хотя в SLAP используются MAC-адреса, назначаемые локальным протоколом из квадранта SAI м назначаемые протоколом, заданным в стандарте IEEE 802, использование SLAP не является обязательным. Локальные администраторы моут использовать положения протоколов IETF из [RFC8947] и [RFC8948], которые поддерживают распределение MAC-адресов в локальном пространстве MAC с использованием DHCPv6 [RFC8415] или иного протокола.

6IEEE Std 802. IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture.

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

RFC 9568 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Internet Engineering Task Force (IETF)                         A. Lindem
Request for Comments: 9568                       LabN Consulting, L.L.C.
Obsoletes: 5798                                                 A. Dogra
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                               April 2024

Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Протокол резервирования виртуальных маршрутизаторов (VRRP) версии 3 для IPv4 и IPv6

PDF

Аннотация

Этот документ определяет версию 3 протокола резервирования виртуальных маршрутизаторов (Virtual Router Redundancy Protocol или VRRP) для IPv4 и IPv6. Документ заменяет собой RFC 5798, ранее задававший VRRP (версия 3). RFC 5798 отменил RFC 3768, задававший VRRP (версия 2) для IPv4. VRRP задаёт протокол выбора для динамического назначения ответственности за виртуальный маршрутизатор одному из маршрутизаторов VRRP в ЛВС. Маршрутизатор VRRP, контролирующий адреса IPv4 или IPv6, связанные с виртуальным маршрутизатором, (Virtual Router или VR) называется активным (Active Router или AR) и пересылает пакеты на эти адреса IPv4 или IPv6. На активных маршрутизаторах настраиваются виртуальные адреса IPv4 или IPv6, а резервные маршрутизаторы (Backup Router или BR) определяют семейство виртуальных адресов для анонсирования на основе версии протокола IP. Внутри маршрутизатора VRRP виртуальные маршрутизаторы для каждого из семейств адресов IPv4 и IPv6 независимы один от другого и всегда считаются отдельными экземплярами VR. Процесс выбора обеспечивает динамический перенос ответственности пересылку, если AR становится недоступным. Для IPv4 преимуществом использования VRRP является более высокая доступность принятого по умолчанию маршрута без необходимости менять настройки протоколов динамической маршрутизации и обнаружения маршрутизаторов на каждом конечном хосте. Для IPv6 преимуществом является более быстрое переключение на BR, чем при использовании стандартных механизмов IPv6 Neighbor Discovery.

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

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

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

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

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

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

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

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

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

1. Введение

Этот документ определяет версию 3 протокола резервирования виртуальных маршрутизаторов (VRRP) для IPv4 и IPv6. Документ заменяет собой RFC 5798, ранее задававший VRRP (версия 3). RFC 5798 отменил RFC 3768, задававший VRRP (версия 2) для IPv4. VRRP задаёт протокол выбора для динамического назначения ответственности за виртуальный маршрутизатор (см. парагра 1.7) одному из маршрутизаторов VRRP в ЛВС. Маршрутизатор VRRP, контролирующий адреса IPv4 или IPv6, связанные с виртуальным маршрутизатором, (VR) называется активным (AR) и пересылает пакеты на эти адреса IPv4 или IPv6 (за исключением пакетов, адресованных на эти адреса, как указано в параграфе 8.3.1). На активных маршрутизаторах настраиваются виртуальные адреса IPv4 или IPv6, а резервные маршрутизаторы (BR) определяют семейство виртуальных адресов для анонсирования на основе версии протокола IP. Внутри маршрутизатора VRRP виртуальные маршрутизаторы для каждого из семейств адресов IPv4 и IPv6 независимы один от другого и всегда считаются отдельными экземплярами VR. Процесс выбора обеспечивает динамический перенос ответственности пересылку, если AR становится недоступным.

VRRP обеспечивает функции, похожие на функции фирменных протоколов Hot Standby Router Protocol (HSRP) [RFC2281] IP Standby Protocol [IPSTB].

1.1. Отличия от RFC 5798

Ниже перечислены изменения, внесённые в [RFC5798].

  1. Обновлена терминология VRRP в соответствии с рекомендациями по всеохватному языку для технологий IETF, в качестве которых выбран документ Национального института стандартов и технологий (National Institute of Standards and Technology или NIST) Guidance for NIST Staff on Using Inclusive Language in Documentary Standards [NISTIR8366].

  2. Термин VRRP Router для маршрутизатора, принимающего на себя ответственность за пересылку пакетов, был заменён на Active Router в соответствии со всеохватывающей терминологией IETF. Кроме того, исправлены несоответствия терминов [RFC5798] Active Router и Backup Router, а также изменён нежелательный термин для привлечения и отбрасывания нежелательных пакетов.

  3. Исправлены ошибки, относящиеся в конечному автомату, в разделе 6.

  4. Уточнён расчёт контрольных сумм в параграфе 5.2.8 для точного указания включаемых частей для псевдозаголовка IPv4.

  5. При получении анонса VRRP от маршрутизатора VRRP с меньшим приоритетом активный маршрутизатор VRRP незамедлительно отправляет анонс VRRP, чтобы мосты с обучением могли пересылать пакеты в корректный сегмент Ethernet (см. параграф 6.4.3).

  6. Удалены приложения, описывающие работу с устаревшими технологиями (Fiber Distributed Data Interface (FDDI), Token Ring, ATM LAN Emulation).

  7. Добавлены рекомендации, указывающие, что анонсы IPv6 Unsolicited Neighbor Advertisement следует воспринимать активным и резервным маршрутизаторам (параграф 8.2.4).

  8. Рекомендуется проверять совпадение Maximum Advertisement Interval, хотя это не влияет на отбрасывание пакетов VRRP ( параграф 7.1).

  9. Внесены редакционные правки для улучшения читаемости.

  10. Раздел «Взаимодействие с IANA» дополнен сведениями о выделении групповых адресов IPv4/IPv6 и MAC-адресов Ethernet.

1.2. Примечание по терминологии

В документе рассматриваются операции IPv4 и IPv6, для которых применительно к протоколу VRRP описания и процедуры совпадают. Было бы уместно использовать термин IP для обозначения IPv4 или IPv6, однако его часто относят только к IPv4. Поэтому в спецификации применяется обозначение IPvX (где X — 4 или 6) для обозначения обоих протоколов. Там, где версия IP имеет значение, указывается полный протокол, а термин IP не применяется.

1.3. IPv4

Имеется множество методов, с помощью которых конечный хост IPv4 может определить первый маршрутизатор (first-hop) на пути к целевому адресу IPv4. Они включают запуск (или отслеживание) протокола динамической маршрутизации, такого как Routing Information Protocol (RIP) [RFC2453] или OSPF версии 2 [RFC2328], запуск клиента обнаружения маршрутизаторов по ICMP [RFC1256], запуск DHCPv4 [RFC2131] или использование заданного статически маршрута по умолчанию.

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

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

Протокол резервирования виртуального маршрутизатора (VRRP) разработан для устранения критической точки отказа, присущей сетям с использованием принятого по умолчанию маршрута. VRRP задаёт протокол выбора, который динамически назначает ответственность за VR одному из маршрутизаторов VRRP в ЛВС. Маршрутизатор VRRP, контролирующий адреса IPv4, связанные с VR, называется активным маршрутизатором (AR) и пересылает пакеты, переданные по этим адресам IPv4. Процесс выбора обеспечивает динамическую передачу ответственности за пересылку, когда AR становится недоступным. Любой из адресов IPv4 виртуального маршрутизатора ЛВС можно использовать конечным хостам в качестве принятого по умолчанию первого маршрутизатора. Преимуществом применения VRRP является повышение доступности принятого по умолчанию пути без необходимости настройки протокола динамической маршрутизации или обнаружения маршрутизаторов на каждом конечном хосте.

1.4. IPv6

Хоты IPv6 в ЛВС обычно узнают о принятых по умолчанию маршрутизаторах из полученных анонсов Router Advertisement протокола обнаружения соседей IPv6 (Neighbor Discovery или ND) [RFC4861]. Групповые (multicast) анонсы Router Advertisement передаются периодически с такой скоростью, что хостам может потребоваться более 10 секунд, чтобы узнать о принятых по умолчанию маршрутизаторах в ЛВС. Анонсы передаются не настолько часто, чтобы полагаться на отсутствие Router Advertisement для обнаружения отказов маршрутизаторов.

Протокол ND включает механизм детектирования недоступности соседей (Neighbor Unreachability Detection) для обнаружения отказов соседних узлов (маршрутизаторов или хостов) или путей пересылки к соседям. Это выполняется путём отправки соседям индивидуальных сообщений ND Neighbor Solicitation. Для снижения издержек, связанных с этим сообщения Neighbor Solicitation передаются лишь соседям, которым узел активно отправляет трафик и лишь при отсутствии положительной индикации активности маршрутизатора в течение некоторого времени. При использовании принятых по умолчанию параметров ND хосту может потребоваться более 10 секунд для обнаружения недоступности маршрутизатора, чтобы переключиться на другой маршрутизатор, заданный по умолчанию. Такая задержка заметна для пользователей и может приводить к тайм-аутам некоторых реализаций транспортных протоколов.

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

Протокол VRRP для IPv6 обеспечивает более быстрое переключение на другой маршрутизатор, нежели стандартные процедуры ND. При использовании VRRP маршрутизатор BR может заменить принятый по умолчанию примерно за 3 секунды (с принятыми по умолчанию парамерами VRRP). Это происходит без взаимодействия с хостами и при минимальном трафике VRRP.

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

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

1.6. Область действия

Далее в документе рассматриваются свойства, цели разработки и теория операций VRRP. Представлены форматы сообщений, правила обработки и конечный автомат, гарантирующие сходимость к одному активному маршрутизатору (AR). В заключение рассматриваются вопросы, связанные с отображением MAC-адресов, обработкой сообщений ARP, генерацией сообщений ICMP о перенаправлении и соображения безопасности.

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

VRRP Router — маршрутизатор VRRP

Маршрутизатор, на котором работает протокол VRRP. Он может участвовать в одном или нескольких VR.

Virtual Router — виртуальный маршрутизатор

Абстрактный объект, управляемый VRRP и выступающий принятым по умолчанию маршрутизатором для хостов общей ЛВС. VR имеет идентификатор (Virtual Router Identifier) и набор связанных с ним адресов IPv4 или IPv6 из общей ЛВС. Маршрутизатор VRRP может служить резервным (Backup Router) для одного или нескольких VR.

Virtual Router Identifier — идентификатор виртуального маршрутизатора

Целое число (1-255), указывающее экземпляр VR в ЛВС. Используется также аббревиатура VRID.

Virtual Router MAC Address — MAC-адрес виртуального маршрутизатора

Групповой адрес Ethernet MAC, используемый в анонсах VRRP для VRID (см. параграф 7.3).

IP Address Owner — владелец адреса IP

Маршрутизатор VRRP, имеющий адреса VR IPvX в качестве адресов реальных интерфейсов. Это маршрутизатор, который, будучи работающим, отвечает за пакеты, направленные по этим адресам IPvX, для ICMP, запросов соединений TCP и т. п.

Primary IP Address — первичный адрес IP

В IPv4 — это адрес IPv4, выбранный из набора реальных адресов интерфейса. Одним из возможных алгоритмов является выбор первого адреса. В IPv4 анонсы VRRP всегда передаются с использованием первичного адреса IPv4 в поле отправителя пакета IPv4. В IPv6 применяется локальный для канала адрес (link-local) интерфейса, через который передаётся пакет.

Forwarding Responsibility — ответственность за пересылку

Ответственность за пересылку пакетов, переданных по адресам IPvX, связанным с VR. Это включает восприятие пакетов, переданных по MAC-адресу VR, пересылку пакетов в соответствии с локальной базой маршрутной информации (Routing Information Base или RIB) и пересылки (Forwarding Information Base или FIB), ответы на запросы ARP для адресов IPv4 и на запросы ND для адресов IPv6.

Active Router — активный маршрутизатор

Маршрутизатор VRRP, принимающий на себя ответственность за пересылку пакетов, переданных по адресам IPvX, связанным с VR, отклики на запросы ARP (для IPv4) и ND (для IPv6. Отметим, что при доступности владельца адреса IPvX он всегда будет AR.

Backup Router(s) — резервные маршрутизаторы

Набор маршрутизаторов VRRP, доступных для принятия ответственности за VR в случае отказа текущего AR.

Drop Route — маршрут отбрасывания

Маршрут в базе RIB, который будет приводить к отбрасыванию трафика, соответствующего ему.

2. Требуемые свойства

В этом разделе описаны свойства, которые считались обязательными при разработке VRRP.

2.1. Резервирование адресов IPvX

Резервирование адресов IPvX является основной функцией VRRP. При обеспечении выбора AR и описанных ниже дополнительных функций протоколу следует стремиться:

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

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

  • работать с широким спектром технологий ЛВС с множественным доступом, способных поддерживать IPvX;

  • разрешать несколько VR в сети для распределения нагрузки;

  • поддерживать множество логических подсетей IPvX в одном сегменте ЛВС.

2.2. Указание предпочтительного пути

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

2.3. Минимизация прерывания обслуживания

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

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

2.4. Эффективная работа в расширенных ЛВС

Передача пакетов IPvX (IPv4 или IPv6) в ЛВС с множественным доступом требует сопоставления адресов IPvX с адресами MAC. Использование MAC-адреса VR в расширенной ЛВС с обучающимися мостами может существенно влиять на издержки пропускной способности для пакетов, передаваемых виртуальному маршрутизатору. Если MAC-адрес VR не применяется как адрес отправителя в кадрах канального уровня, местоположение этого MAC-адреса не будет определено, что приведёт к лавинной передаче всех пакетов, отправленных маршрутизатору VR. Для повышения эффективности в таких средах протоколу следует:

  1. использовать MAC-адрес VR в поле отправителя пакетов от маршрутизатора AR для изучения MAC;

  2. выдавать сообщение срезу после переключения AR для обновления MAC-адресов;

  3. периодически передавать сообщения от AR для поддержки кэша MAC-адресов.

2.5. Субсекундные операции для IPv4 и IPv6

Для сред IPv4 и IPv6 требуется обнаружение отказа AR за доли секунды. В предыдущих работах были предложены субсекундные операции для IPv6, а данная спецификация использует этот подход для IPv4 и IPv6.

Одной из возможных проблемных ситуаций при использовании малых значений Advertisement_Interval (см. параграф 6.1) является генерация маршрутизатором VRRP большего числа пакетов, нежели он способен передать, и рост очереди на этом маршрутизаторе. В таких случаях пакеты для передачи в защищаемую VRRP ЛВС могут задерживаться в очереди на время, превышающее наименьшее значение Advertisement_Interval. При этом интервал Active_Down_Interval (см. параграф 6.1) может быть настолько малым, что даже обычные задержки в очереди могут заставить резервный маршрутизатор сделать вывод об отказе AR и предложить себя в качестве нового AR. Вскоре после этого задержанные пакеты от исходного AR заставят маршрутизатор VRRP снова переключиться на BR и это может происходить много раз в секунду, вызывая значительные перебои в трафике. Для смягчения этой проблемы следует рассмотреть возможность предоставления пакетам VRRP приоритета на выходном интерфейсе. Если AR замечает такую ситуацию, ему следует указать это в системном журнале (с учётом ограничения частоты записей).

3. Обзор VRRP

VRRP задаёт протокол выбора для обеспечения функций VR, описанных выше. Обмен сообщениями протокола выполняется с помощью групповых дейтаграмм IPv4 или IPv6, поэтому протокол может работать в разных ЛВС с множественным доступом, поддерживающих групповую адресацию IPvX. С каждым каналом виртуального маршрутизатора VRRP связан 1 общеизвестный MAC-адрес. Этот документ в задаёт детали отображения лишь для сетей, использующих 48-битовые адреса MACIEEE 802. MAC-адрес VR указывается в поле отправителя всех периодических сообщений VRRP, передаваемых AR, чтобы стало возможным изучение MAC на канальном уровне (L2) мостами расширенных ЛВС.

VR указывается идентификатором VRID и набором адресов IPv4 или IPv6. Маршрутизатор VRRP может связывать VR с реальным адресом на своём интерфейсе. Область действия каждого VR ограничивается одной ЛВС. На маршрутизаторе VRRP могут настраиваться дополнительные отображения VR и приоритеты для VR, которые маршрутизатор готов реализовать. Сопоставление VRID с адресами IPvX должно быть настраиваемым для всех маршрутизаторов VRRP в ЛВС.

Не задаётся ограничений на многократное использование VRID с другими сопоставлениями адресов в разных ЛВС и применение одного VRID для набора адресов IPv4 и IPv6. Однако это будут разные маршрутизаторы VR.

Для минимизации трафика периодические сообщения VRRP Advertisement для каждого VR передаёт лишь AR. Маршрутизатор BR не пытается вытеснить AR, пока у него нет более высокого приоритета. Это исключает перебои в обслуживании, пока не появится более предпочтительный путь. Можно также административно запретить попытки вытеснение AR. Единственным исключением является то, что маршрутизатор VRRP всегда будет становиться AR для любого VR, связанного с адресом, которым он владеет. Если AR становится недоступным, BR с наивысшим приоритетом становится AR с небольшой задержкой, обеспечивая контролируемую передачу ответственности за VR с минимальным прерыванием обслуживания.

Протокол VRRP обеспечивает быстрый переход BR в состояние AR для минимизации перебоев в обслуживании и включает оптимизацию, снижающую сложность протокола в сочетании с гарантиями контролируемого перехода в состояние AR для типичных рабочих ситуаций. Эта оптимизация обеспечивает протокол выбора с минимальными требованиями к рабочим состояниям, минимальным набором активных состояний протокола и одним типом сообщений и отправителем. Определены типовые рабочие сценарии с двумя резервными маршрутизаторами и/или разными предпочтениями путей для каждого маршрутизатора. Побочным эффектом несоблюдения этих допущений, т. е. наличия более двух резервных путей с одинаковым предпочтением, является кратковременная пересылка дубликатов пакетов в течение короткого периода выбора AR. Однако допущение типичных сценариев, вероятно, верно для большинства ситуаций — потеря AR случается достаточно редко, а ожидаемая продолжительность процесса выбора AR достаточно мала (< 4 секунд для принятого по умолчанию Advertisement_Interval с возможностью снижения до значений < 1/25 секунды). Таким образом, оптимизация VRRP значительно упрощает устройство протокола при сохранении невысокой вероятности кратковременных нарушений работы.

4. Примеры сетей VRRP

4.1. Пример 1

На рисунке 1 показана простая сеть с двумя маршрутизаторами VRRP, реализующими один VR.

        +-----------+ +-----------+
        | Router-1  | | Router-2  |
        |(AR VRID=1)| |(BR VRID=1)|
        |           | |           |
VRID=1  +-----------+ +-----------+
IPvX A------>*            *<---------IPvX B
             |            |
             |            |
-------------+------------+--+-----------+-----------+-----------+
                             ^           ^           ^           ^
                             |           |           |           |
     Адреса IPvX принятого   |           |           |           |
     по умолчанию    ---> (IPvX A)    (IPvX A)    (IPvX A)    (IPvX A)
     маршрутизатора          |           |           |           |
                    IPvX H1->*  IPvX H2->*  IPvX H3->*  IPvX H4->*
                          +--+--+     +--+--+     +--+--+     +--+--+
                          |  H1 |     |  H2 |     |  H3 |     |  H4 |
                          +-----+     +-----+     +--+--+     +--+--+
Обозначения
    --+---+---+-- = Ethernet
                H = хост
               AR = AR
               BR = BR
               *  = адрес IPvX: X = 4 для IPv4 и 6 для IPv6
               (IPvX) = принятый по умолчанию маршрутизатор для хостов

Рисунок . Пример сети VRRP.


В случае IPv4 (IPvX на рисунке обозначает IPv4) на каждом маршрутизаторе заранее назначается адрес IPv4 на интерфейсе ЛВС (на Router-1 это IPv4 A, на Router-2 — IPv4 B), а на каждом хосте устанавливается принятый по умолчанию маршрут (по протоколу DHCPv4 или настройку статического маршрута) через один из маршрутизаторов (на рисунке все хосты используют адрес IPv4 A). В случае IPv6 (IPvX на рисунке обозначает IPv6) каждый маршрутизатор имеет свой адрес IPv6 link-local на интерфейсе ЛВС и адрес IPv6 link-local для VRID, который является общим для всех маршрутизаторов с одним VRID. Каждый хост узнаёт принятый по умолчанию маршрут из сообщений Router Advertisement от одного из этих маршрутизаторов (на рисунке все хосты используют IPv6 Link-Local A).

В среде VRRP IPv4 каждый маршрутизатор поддерживает приём и передачу для одного и того же адреса IPv4. Router-1 является владельцем IPv4 A, а Router-2 — IPv4 B. VR определяется привязкой уникального идентификатора VRID к адресу, принадлежащему Router-1. В среде VRRP IPv6 каждый маршрутизатор поддерживает приём и передачу для адресов IPv6, связанных с VRID. Router-1 является владельцем IPv6 A, а Router-2 — IPv6 B. VR определяется привязкой уникального идентификатора VRID к адресу, принадлежащему Router-1. В обоих случаях (IPv4 и IPv6) протокол VRRP обеспечивает переключения VR при отказе на BR.

В примере показан VR, настроенный на охват адреса IPvX, принадлежащего Router-1 (VRID=1, IPvX_Address=A). При включении VRRP на Router-1 для VRID=1 этот маршрутизатор будет заявлять себя как AR с priority = 255, поскольку он владеет адресом IPvX для VR. При включении VRRP на Router-2 для VRID=1 этот маршрутизатор будет заявлять себя как BR с priority = 100 (принятое по умолчанию значение), поскольку он не является владельцем адреса IPvX. При отказе Router-1 протокол VRRP переведёт Router-2 в состояние AR, временно передав ему ответственность за пересылку IPvX A для обеспечения бесперебойного обслуживания хостов.

Отметим, что для обоих случаев на рисунке IPvX B не резервируется и используется только маршрутизатором Router-2 в качестве адреса на интерфейсе. Для резервирования IPvX B требуется настроить второй VR, как показано ниже.

4.2. Пример 2

На рисунке 2 показана конфигурация с двумя VR, между которыми хосты распределяют трафик.

В примере для IPv4 (IPvX на рисунке обозначает адрес IPv4) половина хостов настраивается со статическим маршрутом по умолчанию через IPv4 A (Router-1), остальные используют IPv4 B (Router-2 ). Настройка VR с VRID=1 совпадает с предыдущим примером (параграф 4.1), а второй VR добавлен для охвата адреса IPv4, принадлежащего Router-2 (VRID=2, IPv4_Address=B). В этом случае Router-2 будет заявлять себя как AR для VRID=2, а Router-1 будет служить BR. Это демонстрирует развёртывание с распределением нагрузки при доступности обоих маршрутизаторов с обеспечением полного резервирования для отказоустойчивости.

        +-----------+  +-----------+
        |  Router-1 |  | Router-2  |
        |(AR VRID=1)|  |(BR VRID=1)|
        |(BR VRID=2)|  |(AR VRID=2)|
VRID=1  +-----------+  +-----------+  VRID=2
IPvX A ----->*             *<---------- IPvX B
             |             |
             |             |
   ----------+-------------+-+-----------+-----------+-----------+
                             ^           ^           ^           ^
                             |           |           |           |
     Адрес IPvX принятого    |           |           |           |
     по умолчанию    ---> (IPvX A)    (IPvX A)    (IPvX B)    (IPvX B)
     маршрутизатора          |           |           |           |
                    IPvX H1->*  IPvX H2->*  IPvX H3->*  IPvX H4->*
                          +--+--+     +--+--+     +--+--+     +--+--+
                          |  H1 |     |  H2 |     |  H3 |     |  H4 |
                          +-----+     +-----+     +--+--+     +--+--+

Обозначения
    --+---+---+-- = Ethernet
                H = хост
               AR = AR
               BR = BR
               *  = адрес IPvX: X = 4 для IPv4 и 6 для IPv6
               (IPvX) = принятый по умолчанию маршрутизатор для хостов

Рисунок . Пример сети VRRP.


В примере для IPv6 (IPvX на рисунке обозначает адрес IPv6) половина хостов настраивается с маршрутом по умолчанию через IPv6 A (Router-1), остальные используют IPv6 B(Router-2 ). Настройка VR с VRID=1 совпадает с предыдущим примером (параграф 4.1), а второй VR добавлен для охвата адреса IPv6, принадлежащего Router-2 (VRID=2, IPv6_Address=B). В этом случае Router-2 будет заявлять себя как AR для VRID=2, а Router-1 будет служить BR. Это демонстрирует развёртывание с распределением нагрузки при доступности обоих маршрутизаторов с обеспечением полного резервирования для отказоустойчивости.

Отметим, что детали распределения нагрузки выходят за рамки этого документа. Если серверам нужны различные веса, полагаться на сообщения Router Advertisement для распределения трафика между маршрутизаторами может быть бессмысленно [RFC4311].

5. Протокол

Назначением VRRP Advertisement является передача всем маршрутизаторам VRRP значения Maximum Advertisement Interval и адреса IPvX маршрутизатора AR, связанного с VRID.

Когда VRRP служит для защиты адреса IPv4, пакеты VRRP инкапсулируются в пакеты IPv4, которые передаются по групповому адресу IPv4, назначенному VRRP. При использовании VRRP для защиты адреса IPv6 пакеты VRRP инкапсулируются в пакеты IPv6, которые передаются по групповому адресу IPv6, назначенному VRRP.

5.1. Формат пакетов VRRP

В этом параграфе описан формат пакетов VRRP и соответствующих полей заголовков IPvX (с учётом семейства).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Поля IPv4 или IPv6                     |
...                                                           ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type  | Virtual Rtr ID|   Priority    |IPvX Addr Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserve| Max Advertise Interval|          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                         Адреса IPvX                           |
+                                                               +
+                                                               +
+                                                               +
+                                                               +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакетов IPv4/IPv6 VRRP Advertisement.


5.1.1. Описание полей IPv4

5.1.1.1. Source Address

Первичный адрес IPv4 на интерфейсе, с которого передаётся пакет.

5.1.1.2. Destination Address

Групповой адрес IPv4, назначенный IANA для протокола VRRP (224.0.0.18). Это групповой адрес, действующий на локальном канале. Маршрутизаторам недопустимо пересылать такие дейтаграммы независимо от значения TTL.

5.1.1.3. TTL

Должно иметь значение 255. Маршрутизатор VRRP должен отбрасывать пакеты с иным значением [RFC5082].

5.1.1.4. Protocol

Номер протокола IPv4, выделенный IANA для VRRP (десятичное значение 112).

5.1.2. Описание полей IPv6

5.1.2.1. Source Address

Адрес IPv6 link-local на интерфейсе, с которого передаётся пакет.

5.1.2.2. Destination Address

Групповой адрес IPv6, назначенный IANA для протокола VRRP (ff02:0:0:0:0:0:0:12). Это групповой адрес, действующий на локальном канале. Маршрутизаторам недопустимо пересылать такие дейтаграммы при любом значении Hop Limit.

5.1.2.3. Hop Limit

Должно иметь значение 255. Маршрутизатор VRRP должен отбрасывать пакеты с иным значением [RFC5082].

5.1.2.4. Next Header

Протокол IPv6 Next Header, выделенный IANA для VRRP (десятичное значение 112).

5.2. Описание полей VRRP

5.2.1. Version

Версия протокола VRRP для этого пакета. Этот документ задаёт версию 3.

5.2.2. Type

Указывает тип пакета VRRP. В этой версии протокола определён лишь один тип:

1

ADVERTISEMENT (анонс).

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

5.2.3. Virtual Rtr ID (VRID)

Поле Virtual Rtr ID указывает VR, для которого пакет указывает состояние.

5.2.4. Priority

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

Маршрутизаторы VRRP, резервирующие VR, должны использовать для приоритета десятичные значения 1-254. По умолчанию для маршрутизаторов VRRP, резервирующих VR, используется десятичное значение 100. Рекомендации по выбору приоритета приведены в параграфе 8.3.2. Значение приоритета 0 указывает, что текущий AR прекратил своё участие в VRRP. Это служит для того, чтобы маршрутизаторы BR приступали к выбору AR, не ожидая завершения текущего Active_Down_Interval (см. параграф 6.1).

5.2.5. IPvX Addr Count

Поле IPvX Addr Count указывает число адресов (IPv4 или IPv6) в анонсе VRRP и должно иметь значение не меньше 1. Анонсы VRRP со значением 0 должны игнорироваться.

5.2.6. Reserve

В поле Reserve должно устанавливаться значение 0, а при получении поле игнорируется.

5.2.7. Max Advertise Interval

12-битовое поле, указывающее интервал между анонсами в сотых долях секунды (по умолчанию 100 — 1 секунда).

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

5.2.8. Checksum

Поле контрольной суммы служит для обнаружения повреждений данных в сообщениях VRRP. Для семейств адресов IPv4 и IPv6 контрольная сумма представляет собой 16-битовое дополнение до 1 суммы дополнений до 1 для сообщения VRRP. При расчёте контрольной суммы значение поля Checksum принимается равным 0. Детали расчёта контрольных сумм описаны в [RFC1071].

Для адресов IPv4 при расчёте контрольной суммы используются поля сообщения VRRP, начиная с поля Version и заканчивая последним адресом IPv4 (см. параграф 5.2). Для адресов IPv6 в расчёт контрольной суммы включается также добавленный в начало псевдозаголовок, определённый в параграфе 8.1 [RFC8200]. В поле Next Header псевдозаголовка для протокола VRRP следует устанавливать десятичное значение 112.

5.2.9. Адреса IPvX

Эти поля относятся к одному или нескольким адресам IPvX, связанным с VR. Число адресов указывается в поле IPvX Addr Count. Поля применяются для поиска и устранения неполадок в настройках маршрутизаторов. При отправке более одного адреса рекомендуется настраивать на всех маршрутизаторах передачу адресов в одном порядке, чтобы упростить сравнение.

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

Для IPv6 первым должен указываться адрес IPv6 link-local, связанный с VR.

Эти поля содержат 1 или несколько адресов IPv4 или IPv6. Семейство (IPv4 или IPv6, но не сочетание) должно совпадать с семейством адреса в заголовке IPvX пакета VRRP.

6. Конечный автомат протокола

6.1. Параметры виртуального маршрутизатора

VRID

Идентификатор VR — настраиваемое десятичное значение от 1 до 255. Значение по умолчанию отсутствует.

Priority

Значение приоритета, используемое маршрутизатором VRRP при выборе AR для данного VR. Десятичное значение 255 зарезервировано для маршрутизатора, владеющего адресом IPvX, связанным с VR, значение 0 зарезервировано для AR с целью указания снятия ответственности за VR. Десятичные значения 1-254 доступны для маршрутизаторов VRRP, резервирующих VR. Большее значение указывает более высокий приоритет. По умолчанию используется десятичное значение 100.

IPv4_Addresses

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

IPv6_Addresses

Один или несколько адрес IPv6, связанный с VR. Настраиваемый список адресов без значения по умолчанию. Первым в списке должен быть адрес Link-Local, связанный с VR.

IPvX_Addresses

Адрес IPv4 или IPv6, связанный с этим VR (см. выше IPv4_Addresses и IPv6_Addresses).

Advertisement_Interval

Интервал времени между анонсами VRRP Advertisement, передаваемых эти VR (в сотых долях секунды). По умолчанию установлено значение 100 (1 секунда).

Active_Adver_Interval

Интервал анонсирования, содержащийся в VRRP Advertisement, полученных от AR (в сотых долях секунды). Это значение сохраняется маршрутизаторами VR в состоянии Backup и применяется для расчёта Skew_Time (см. параграф 8.3.2) и Active_Down_Interval. Исходное значение совпадает с Advertisement_Interval.

Skew_Time

Время для изменения Active_Down_Interval в сотых долях секунды. Рассчитывается по формуле (((256 — Priority) * Active_Adver_Interval) / 256).

Active_Down_Interval

Интервал времени, по истечение которого BR объявляет AR отказавшим в сотых долях секунды. Рассчитывается по формуле (3 * Active_Adver_Interval) + Skew_Time.

Preempt_Mode

Указывает, будет ли BR с более высоким приоритетом (при запуске или перезапуске) вытеснять AR с низким приоритетом. Значение True (принято по умолчанию) разрешает вытеснение, False — запрещает.
Примечание. Маршрутизатор, владеющий адресом IPvX, связанным с VR использует вытеснение всегда, независимо от установки этого флага.

Accept_Mode

Указывает, будет ли VR в состоянии Active воспринимать пакеты, направленные владельцу адреса IPvX, как свои, даже если они ему не принадлежат. По умолчанию установлено значение False. Системы, полагающиеся, например, на ping IPvX-адреса владельца, могут пожелать установить Accept_Mode = True.
Примечание. Сообщения IPv6 Neighbor Solicitation и Neighbor Advertisement недопустимо отбрасывать при Accept_Mode = False.

Virtual_Router_MAC_Address

MAC-адрес, используемый в поле MAC отправителя анонсов VRRP и анонсируемый в сообщениях ARP/ND как MAC-адрес для использования в IPvX_Addresses.

6.2. Таймеры

Active_Down_Timer

Таймер, срабатывающий при отсутствии VRRP Advertisement в течение Active_Down_Interval (только BR).

Adver_Timer

Таймер для запуска передачи VRRP Advertisement по времени Advertisement_Interval (только AR).

6.3. Диаграмма смены состояний

                +---------------+
     +--------->|               |<-------------+
     |          |  Initialize   |              |
     |   +------|               |----------+   |
     |   |      +---------------+          |   |
     |   |                                 |   |
     |   V                                 V   |
+---------------+                       +---------------+
|               |---------------------->|               |
|    Active     |                       |    Backup     |
|               |<----------------------|               |
+---------------+                       +---------------+

Рисунок . Диаграмма смены состояний.


6.4. Описания состояний

В описаниях ниже имена состояний указываются как {state-name}, а пакеты — заглавными буквами.

Маршрутизатор VRRP реализует экземпляр конечного автомата для каждого VR, в котором он участвует.

6.4.1. Initialize

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

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

  • Если Priority = 255, т. е. маршрутизатор владеет адресами IPvX, связанными с VR:

    • передаётся сообщение ADVERTISEMENT;

    • если защищаемый адрес IPvX является IPv4:

      • для каждого адреса IPv4, связанного с VR, передаётся широковещательное беспричинное сообщение ARP с IPv4-адресом1 VR и MAC-адресом VR в качестве целевого адреса канального уровня;

    • иначе // IPv6

      • для каждого адреса IPv6, связанного с VR, передаётся незапрошенный анонс ND Neighbor Advertisement с установленным флагом Router Flag (R), сброшенным флагом Solicited Flag (S), установленным флагом Override flag (O), целевым адресом IPv6 для VR и MAC-адресом VR в качестве целевого адреса канального уровня;

    • завершение проверки семейства адресов;

    • для Adver_Timer устанавливается значение Advertisement_Interval;

    • состояние меняется на {Active};

  • иначе // маршрутизатор не является владельцем адреса

    • для Active_Adver_Interval устанавливается значение Advertisement_Interval;

    • для Active_Down_Timer устанавливается значение Active_Down_Interval;

    • состояние меняется на {Backup};

  • завершение проверки условия Priority = 255.

На этом обработка события Startup завершается.

6.4.2. Backup

Состояние {Backup} предназначено для отслеживания доступности и статуса AR. В приведённом ниже описании применяется групповой адрес Solicited-Node [RFC4291].

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

  • Если защищаемый адрес IPvX является IPv4:

    • маршрутизатору недопустимо отвечать на запросы ARP, для адресов IPv4 маршрутизатора VR;

  • иначе // защищаемый адрес относится к IPv6

    • маршрутизатору недопустимо отвечать на сообщения ND Neighbor Solicitation для адресов IPv6, связанных с VR;

    • маршрутизатору недопустимо передавать сообщения ND Router Advertisement для VR;

  • завершение проверки принадлежности защищаемого адреса к IPv4;

  • маршрутизатор должен отбрасывать пакеты с MAC-адресом получателя, совпадающим с MAC-адресом VR;

  • маршрутизатору недопустимо воспринимать пакеты, направленные по адресам IPvX, связанным с VR;

  • по событию Shutdown:

    • отключается таймер Active_Down_Timer;

    • состояние меняется на {Initialize};

  • завершение обработки события Shutdown;

  • по срабатыванию таймера Active_Down_Timer:

    • передаётся сообщение ADVERTISEMENT;

  • если защищаемый адрес IPvX является IPv4:

      • для каждого адреса IPv4, связанного с VR передаётся широковещательное беспричинное сообщение ARP, содержащее IPv4-адрес VR и MAC-адрес VR в качестве целевого адреса канального уровня;

    • иначе // IPv6

      • рассчитывается присоединяется групповой адрес Solicited-Node [RFC4291] для адресов IPv6, связанных с VR;

      • для каждого адреса IPv6, связанного с VR, передаётся незапрошенный анонс ND Neighbor Advertisement с установленным флагом Router Flag (R), сброшенным флагом Solicited Flag (S), установленным флагом Override flag (O), целевым адресом IPv6 для VR и MAC-адресом VR в качестве целевого адреса канального уровня;

    • завершение проверки принадлежности защищаемого адреса к IPv4;

    • для Adver_Timer устанавливается значение Advertisement_Interval;

    • состояние меняется на {Active};

  • завершение обработки по таймеру Active_Down_Timer;

  • при получении сообщения ADVERTISEMENT:

    • если Priority в ADVERTISEMENT имеет ненулевое значение:

      • для Active_Down_Timer устанавливается значение Skew_Time;

    • завершение обработки ненулевого приоритета;

      • если Preempt_Mode = False или Priority в ADVERTISEMENT не меньше локального Priority:

        • для Active_Adver_Interval устанавливается значение Max Advertise Interval из ADVERTISEMENT;

        • заново рассчитывается Skew_Time;

        • заново рассчитывается Active_Down_Interval;

        • для Active_Down_Timer устанавливается значение Active_Down_Interval;

      • иначе // вытеснение было разрешено, а приоритет в анонсе меньше локального;

        • ADVERTISEMENT отбрасывается;

      • завершение проверки возможности вытеспения;

    • завершение обработки нулевого приоритета;

  • завершение проверки получения анонса.

На этом обработка в состоянии {Backup} завершается.

6.4.3. Active

В состоянии {Active} маршрутизатор выполняет пересылку для адресов IPvX, связанных с VR. Флаг Preempt_Mode Flag в режиме {Active} не принимается во внимание.

В состоянии {Active} маршрутизатор VRRP должен выполнять указанные ниже действия.

  • Если защищаемый адрес IPvX относится к IPv4:

    • маршрутизатор должен отвечать на запросы ARP для адресов IPv4, связанных с VR;

  • иначе // IPv6

    • маршрутизатор должен быть членом группы Solicited-Node для адресов IPv6, связанных с VR;

    • маршрутизатор должен отвечать на сообщения ND Neighbor Solicitation (с установленным флагом Router Flag (R)) для адресов IPv6, связанных с VR;

    • маршрутизатор должен передавать сообщения ND Router Advertisement для VR;

    • если Accept_Mode = False:

      • маршрутизатору недопустимо отбрасывать IPv6 Neighbor Solicitation и Neighbor Advertisement;

  • завершение проверки семейства адресов;

  • маршрутизатор должен пересылать пакеты с MAC-адресом получателя, совпадающим с MAC-адресом VR;

  • маршрутизатор должен воспринимать пакеты, направленные по адресам IPvX, связанным с VR, если он владеет этим адресом IPvX или Accept_Mode = True, в иных случаях воспринимать пакеты недопустимо;

  • по событию Shutdown:

    • выключается таймер Adver_Timer;

    • передаётся ADVERTISEMENT с Priority = 0;

    • состояние меняется на {Initialize};

  • завершение обработки Shutdown;

  • по таймеру Adver_Timer:

    • передаётся ADVERTISEMENT;

    • для Adver_Timer устанавливается значение Advertisement_Interval;

  • завершение обработки по таймеру анонсов;

  • при получении сообщения ADVERTISEMENT:

    • если поле Priority в ADVERTISEMENT имеет значение 0:

      • передаётся ADVERTISEMENT;

      • для Adver_Timer устанавливается значение Advertisement_Interval;

    • иначе // приоритет отличен от 0;

      • если Priority в ADVERTISEMENT больше локального Priority или приоритеты совпадают и первичный адрес IPvX отправителя больше локального первичного адреса IPvX (сравнение как целых чисел без знака с сетевым порядком байтов):

        • выключается таймер Adver_Timer;

        • для Active_Adver_Interval устанавливается значение Max Advertise Interval из ADVERTISEMENT;

        • заново рассчитывается Skew_Time;

        • заново рассчитывается Active_Down_Interval;

        • для Active_Down_Timer устанавливается значение Active_Down_Interval;

        • состояние меняется на {Backup};

      • иначе // логика нового AR

        • ADVERTISEMENT отбрасывается;

        • незамедлительно передаётся ADVERTISEMENT для подтверждения статуса {Active} передавшему анонс маршрутизатору VRRP и обновления обучающихся мостов указанием корректного пути к активному маршрутизатору VRRP;

      • завершение обработки при обнаружении нового AR;

    • завершение обработки по приоритету;

  • завершение обработки полученного анонса.

На этом работа в состоянии {Active} завершается.

Примечание. Пакеты VRRP передаются с MAC-адресом VR в поле отправителя, чтобы обеспечить обучающимся мостам корректное определение сегмента ЛВС, к которому подключён VR.

7. Передача и приём пакетов VRRP

7.1. Приём пакетов VRRP

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

  • Если получен пакет IPv4:

    • должно проверяться наличие значения 255 в поле IPv4 TTL;

  • иначе // получен пакет VRRP IPv6;

    • должно проверяться наличие значения 255 в поле IPv6 Hop Limit;

  • завершение обработки по семейству адресов;

  • должен проверяться номер версии VRRP (3);

  • должно проверяться значение типа пакета VRRP (1 — ADVERTISEMENT);

  • должна проверяться полнота полученного пакета VRRP (включая фиксированные поля и адрес IPvX);

  • должна проверяться контрольная сумма VRRP;

  • должна выполняться проверка настройки VRID на принявшем пакет интерфейсе и того, что локальный маршрутизатор не является владельцем адреса IPvX (Priority = 255 ).

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

Получателю следует проверять, что Max Advertise Interval в принятом пакете VRRP совпадает со значением Advertisement_Interval настроенным для VRID, поскольку при различии интервалов может возникать нестабильность (см. параграф 5.2.7). При отрицательном результате проверки следует внести запись об этом в системный журнал (с учётом ограничения частоты записей) и можно указать некорректность настройки через систему управления.

Получатель может проверить соответствие IPvX Addr Count и сприска адресов IPvX настроенным для VRID адресам IPvX. При отрицательном результате проверки следует внести запись об этом в системный журнал (с учётом ограничения частоты записей) и можно указать некорректность настройки через систему управления.

7.2. Передача пакетов VRRP

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

  • Заполнение полей пакета VRRP в соответствии с состоянием конфигурации VR.

  • Расчёт контрольной суммы VRRP.

  • Установка в поле MAC-адреса отправителя значения MAC-адреса VR.

  • Если защищаемым адресом является IPv4,

    • установка в поле адреса отправителя IPv4 первичного адреса IPv4 на интерфейсе

  • иначе // IPv6

    • установка в поле адреса отправителя IPv6 адреса IPv6 link-local для интерфейса

  • завершение обработки по семействам адресов;

  • установка для протокола IPvX значения VRRP;

  • передача пакета VRRP в группу IPvX VRRP.

Примечание. Пакеты VRRP передаются с MAC-адресом VR в поле MAC отправителя, чтобы обучающиеся мосты могли корректно определить сегмент ЛВС, к которому подключён VR.

7.3. MAC-адрес VR

MAC-адрес, связанный с Virtual является адресом IEEE 802 MAC [RFC9542] в формате

   IPv4: 00-00-5E-00-01-{VRID} (шестнадцатеричное с сетевым порядком байтов)

Три первых октета взяты из уникального идентификатора IANA (Organizationally Unique Identifier или OUI), следующие 2 (00-01) указывают блок адресов, выделенных VRRP для протокола IPv4. {VRID} — это идентификатор VR. Этот формат позволяет иметь в ЛВС до 255 маршрутизаторов IPv4 VRRP.

   IPv6: 00-00-5E-00-02-{VRID} (шестнадцатеричное с сетевым порядком байтов)

Три первых октета взяты из IANA OUI, следующие 2 (00-01) указывают блок адресов, выделенных VRRP для протокола IPv6. {VRID} — это идентификатор VR. Формат позволяет иметь в ЛВС до 255 маршрутизаторов IPv6 VRRP.

7.4. Идентификаторы интерфейсов IPv6

В [RFC8064] указано, что [RFC7217] применяется в качестве принятой по умолчанию схемы создания стабильных адресов при автоматической настройке IPv6 без поддержки состояний (Stateless Address Autoconfiguration или SLAAC) [RFC4862]. MAC-адрес VR недопустимо применять для параметра Net_Iface в алгоритмах создания идентификаторов интерфейсов (Interface Identifier или IID) [RFC7217] и [RFC8981].

Эта спецификация VRRP описывает, как анонсируется и преобразуется адрес IPv6 link-local маршрутизатора VRRP и связанные с ним адреса IPv6 в MAC-адрес VR.

8. Вопросы эксплуатации

8.1. IPv4

8.1.1. ICMP Redirect

Перенаправление ICMP можно использовать при работе VRRP между группой маршрутизаторов, что позволяет принять VRRP в средах с несимметричной топологией.

Адресу отправителя IPv4 в перенаправлении ICMP следует быть адресом, который конечный хост использовал при принятии решения о следующем маршрутизаторе (next-hop). Если маршрутизатор VRRP является AR для VR, содержащих адреса, которыми он не владеет, при выборе адреса источника перенаправления этот маршрутизатор должен определить, какому из VR был направлен пакет. Одним из методов определения VR является изучение MAC-адреса получателя в пакете, вызвавшем перенаправление.

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

8.1.2. Запросы ARP от хостов

Когда хост передаёт запрос ARP для обного из адресов IPv4 маршрутизатора VR, маршрутизатор AR должен отвечать сообщением ARP, указывающим MAC-адрес VR. Отметим, что адресом отправителя в кадре Ethernet с откликом ARP является физический MAC-адрес физического маршрутизатора. Маршрутизатору AR недопустимо указывать свой физический MAC-адрес в отклике ARP. Это позволяет хостам всегда использовать один MAC-адрес, независимый от текущего AR.

При загрузке или перезагрузке маршрутизатора VRRP ему не следует передавать каких-либо сообщений ARP, использующих его физический MAC-адрес для адреса IPv4, которым он владеет (в соответствии с параграфом 1.7), и следует передавать лишь сообщения ARP с MAC-адресом VR. Это означает соблюдение указанных ниже условий.

  • При настройке интерфейса маршрутизаторам AR следует широковещательно передавать беспричинное сообщение ARP с MAC-адресом VR для каждого адреса IPv4 на этом интерфейсе.

  • При инициализации интерфейсов для операций VRRP в процессе загрузки системы беспричинные сообщения ARP должны задерживаться до момента установки адреса IPv4 и MAC-адреса VR.

  • При доступе к конкретному маршрутизатору VRRP, например, с помощью Secure Shell (SSH), следует использовать адрес IPv4, заведомо принадлежащий этому маршрутизатору.

8.1.3. Proxy ARP

При использовании Proxy ARP на маршрутизаторе VRRP он должен анонсировать MAC-адрес VR в сообщении Proxy ARP, поскольку в противном случае хосты получат реальный MAC-адрес маршрутизатора VRRP.

8.2. IPv6

8.2.1. ICMPv6 Redirect

Перенаправления ICMPv6 обычно могут применяться при работе VRRP на группе маршрутизаторов [RFC4443]. Это позволяет использовать VRRP в средах, где топология не симметрична, например, маршрутизаторы VRRP не соединены с одними и теми же получателями. В качестве адреса отправителя ICMPv6 следует указывать адрес, который конечный хост использовал при выборе next-hop. Если маршрутизатор VRRP играет роль AR для маршрутизатора(ов) VR, содержащих адреса, которыми он не владеет, при выборе адреса источника перенаправления нужно определить, какому VR был направлен пакет. Определение выполняется по MAC-адресу получателя в пакете, вызвавшем перенаправление.

8.2.2. ND Neighbor Solicitation

Когда хост передаёт сообщение ND Neighbor Solicitation для обного из адресов IPv6 маршрутизатора VR, маршрутизатор AR должен отвечать на него, указывая MAC-адрес VR. Маршрутизатору AR недопустимо указывать свой физический MAC-адрес в отклике. Это позволяет хостам всегда использовать один MAC-адрес, независимый от текущего AR.

При передаче маршрутизатором AR сообщения ND Neighbor Solicitation для адреса хоста IPv6 он должен включать в это сообщение MAC-адрес VR, если в сообщении передаётся опция адреса канального уровня отправителя. Использовать свой физический MAC-адрес в качестве канального адреса источника недопустимо.

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

  • При настройке интерфейса маршрутизаторам AR следует передавать незапрошенное сообщение ND Neighbor Advertisement с MAC-адресом VR для адреса IPv6 на этом интерфейсе.

  • При инициализации интерфейсов для операций VRRP в процессе загрузки системы все сообщения ND Router Advertisement, ND Neighbor Advertisement и ND Neighbor Solicitation должны задерживаться до момента установки адреса IPv6 и MAC-адреса VR.

При перезапуске AR, где защищаемый VRRP адрес является адресом интерфейса (т. е. маршрутизатор владеет адресом) обнаружения дубликатов адресов (Duplicate Address Detection) может не срабатывать, поскольку BR может сообщать, что адрес принадлежит ему. Одним из решений является отказ от обнаружения дубликатов в таких случаях.

8.2.3. Анонсы маршрутизаторов

Когда резервный маршрутизатор VRRP становится AR для VR, он отвечает за передачу сообщений Router Advertisement для VR, как указано в параграфе 6.4.3. Маршрутизаторы BR должны быть настроены для передачи тех же опций Router Advertisement, что и владелец адреса.

Опции Router Advertisement, анонсирующие особые службы, такие как Home Agent Information Option, которые присутствуют у владельца адреса, владельцу не следует передавать, пока маршрутизаторы BR не подготовлены для полного предоставления таких же услуг и не имеют полной и синхронизированной базы данных для этих услуг.

8.2.4. Незапрошенные анонсы соседей

Маршрутизатору VRRP, действующему как AR или BR для IPv6, следует воспринимать сообщения Unsolicited Neighbor Advertisement и обновлять соответствующий кэш соседей [RFC4861]. Поскольку эти анонсы передаются по групповому адресу IPv6 all-nodes (ff02::1) [RFC4861] млм IPv6 all-routers (ff02::2), они будут получены. Сообщения Unsolicited Neighbor Advertisement передаются при смене адреса канального уровня [RFC4861] и для незапрошенного обнаружения первого маршрутизатора (first-hop) [RFC9131]. Может потребоваться дополнительная настройка, чтобы сообщения Unsolicited Neighbor Advertisement обновляли соответствующий кэш соседей.

8.3. IPvX

8.3.1. Возможные петли при пересылке

Маршрутизатору VRRP, не являющемуся владельцем адреса, не следует пересылать пакеты, направленные по адресу IPvX, для которого он стал AR, поскольку такая пересылка создаёт ненужный трафик. Кроме того, при получении ЛВС пакетов, которые эта сеть передала, могут возникать петли, исчезающие лишь по завершении IPvX TTL. Одним из механизмов предотвращения таких петель маршрутизаторами VRRP является добавление (удаление) Drop Route для хостов на каждом не принадлежащем маршрутизатору адресе IPvX при переходе в состояние AR (выходе из него).

8.3.2. Рекомендации по установке приоритета

Значение приоритета 255 указывает, что конкретный маршрутизатор является владельцем адреса IPvX для VRID. Маршрутизатор VRRP с приоритетом 255 при старте будет вытеснять маршрутизаторы с меньшим приоритетом. Для VRID значение 255 следует назначать лишь одному маршрутизатору VRRP на канале. При обнаружении нескольких таких маршрутизаторов этот факт следует указать в системном журнале (соблюдая ограничения по частоте записей). При отсутствии таких маршрутизаторов VRRP вытеснения не происходит.

Чтобы избежать одновременного перехода нескольких BR в состояние AR при отказе или выключении прежнего AR, все VR следует настраивать с разными приоритетами. Разница должна быть достаточно большой, чтобы BR с низким приоритетом не переходили в состояние Active до получения анонса от BR с самым высоким приоритетом о его переходе в состояние AR. При обнаружении нескольких VRRP, анонсирующих одинаковый приоритет, этот факт можно указать в системном журнале (соблюдая ограничения по частоте записей).

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

8.4. Взаимодействие VRRPv3 и VRRPv2

8.4.1. Допущения

  1. Функциональная совместимость VRRPv2 и VRRPv3 не является обязательной.

  2. Смешение VRRPv2 и VRRPv3 следует допускать лишь при переходе от VRRPv2 к VRRPv3 и не оставлять в качестве постоянного решения.

8.4.2. Поддержка взаимодействия с VRRPv2 в VRRPv3

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

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

Когда VR настроен таким образом и является AR, он должен передавать оба типа анонсов с настроенной скоростью, даже если она субсекундная. Настроенный таким образом VR, являющийся BR, должен использовать тайм-аут на основе скорости, анонсированной AR. В случае VRRPv2 AR это означает, что маршрутизатор должен перевести полученное значение тайм-аута (в секундах) в сотые доли секунды. Маршрутизатору BR следует игнорировать анонсы VRRPv2 от текущего AR, если от него приходят и пакеты VRRPv3it. BR может сообщать, что VRRPv3 AR не передаёт пакетов VRRPv2, поскольку это говорит о несогласии поддерживать взаимодействие с VRRPv2.

8.4.2.1. Вопросы взаимодействия
8.4.2.1.1. Медленные AR с высоким приоритетом

Этот вопрос рассмотрен в параграфе 5.2.7.

VRRPv2 AR, взаимодействующий с субсекундным VRRPv3 BR является наиболее важным примером такой ситуации.

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

8.4.2.1.2. Перегрузка резервных маршрутизаторов VRRPv2

Возможно, что VRRPv3 AR, передающий анонсы с субсекундной скоростью, перегрузит VRRPv2 BR с потенциально неопределённым результатом

В случае обновления следует сначала запускать VRRPv3 AR с более низкой частотой анонсов, например, 100 (1 анонс в секунду), пока маршрутизаторы VRRPv2 не будут обновлены. После проверки корректности работы VRRPv3 поддержку VRRPv2 можно отключить и настроить субсекундную скорость передачи.

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

VRRP для IPvX не поддерживает проверки подлинности. Прежние версии VRRP включали несколько типов аутентификации (от её отсутствия до строгой проверки подлинности). Опыт эксплуатации и анализ показали, что это не обеспечивает достаточной защиты для преодоления уязвимости из-за неверно настроенных секретов, что приводило к выбору нескольких AR сразу. В силу особенностей протокола VRRP даже криптографическая защита сообщений VRRP не препятствует враждебным узлам выдавать себя за AR, создавая в сети сразу несколько AR. Аутентификация сообщений VRRP может предотвратить переход всех нормально работающих маршрутизаторов в состояние Backup из-за действий враждебных узлов. Однако наличие нескольких AR может создать больше проблем, чем отсутствие маршрутизаторов, но аутентификация это не препятствует. Даже если враждебный узел не может нарушить работу VRRP, он способен повредить ARP/ND и результат будет таким же, как при переходе всех маршрутизаторов в состояние Backup.

Некоторые коммутаторы L2 способны фильтровать, например, сообщения ARP и/или ND от конечных хостов по портам коммутатора. Этот механизм позволяет фильтровать и сообщения VRRP с портов коммутатора, связанных с конечными хостами, и может рассматриваться для внедрения в сетях с недоверенными хостами.

Следует отметить, что такие атаки являются подмножеством атак, которые может организовать любой подключенный к ЛВС узел независимо от VRRP, включая:

  • неразборчивый (promiscuous) приём пакетов с любого MAC-адреса маршрутизатора;

  • передача пакетов с MAC-адресом маршрутизатора в поле MAC отправителя заголовка L2, чтобы вынудить коммутаторы L2 отправлять адресованные маршрутизатору пакеты вредоносному узлу;

  • отправка перенаправления, указывающих всем хостам направлять свои пакеты в другое место;

  • передача незапрошенных откликов ND;

  • отклики на запросы ND и т. п.

Все означенное может происходить независимо от VRRP и протокол не добавляет уязвимостей, а большинство из них устраняется независимо, например с помощью защищённого обнаружения соседей (SEcure Neighbor Discovery или SEND) [RFC3971].

VRRP включает механизм (установка значения 255 в IPv4 TTL и IPv6 Hop Limit и проверка при получении), защищающий от внедрения пакетов VRRP из удалённой сети [RFC5082]. Это ограничивает возможности атак.

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

В контексте IPv6 при наличии SEND протокол VRRP совместим с режимами SEND trust anchor (привязка доверия) и trust anchor or CGA (привязка доверия или CGA) [RFC3971]. В настройках SEND нужно предоставлять маршрутизаторам AR и BR одинаковое делегирование префиксов, чтобы те и другие анонсировали общий набор префиксов подсети. Однако AR и BR следует иметь свои пары ключей, чтобы избежать применения общего секретного ключа.

В контексте IPv6 рекомендуется следовать руководству по защите из параграфа 2.3 в [RFC9099].

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

Агентство IANA обновило в своих реестрах ссылки на [RFC5798] ссылками на данный документ, как указано ниже.

Выделено значение 112 для VRRP в реестре Assigned Internet Protocol Numbers.

В реестре Local Network Control Block (224.0.0.0 — 224.0.0.255 (224.0.0/24)) внутри IPv4 Multicast Address Space Registry [RFC5771] агентство IANA выделило для VRRP групповой адрес IPv4 224.0.0.18.

В реестре Link-Local Scope Multicast Addresses внутри IPv6 Multicast Address Space Registry [RFC3307] агентство IANA выделило групповой адрес IPv6 link-local ff02:0:0:0:0:0:0:12 для VRRP с протоколом IPv6.

В реестре IANA MAC ADDRESS BLOCK [RFC9542] агентство IANA выделило блоки индивидуальных адресов Ethernet, приведённые в таблице 1 (в шестнадцатеричном формате).

Таблица .

 

Адреса

Использование

Документ

00-01-00 — 00-01-FF

VRRP (Virtual Router Redundancy Protocol)

RFC 9568

00-02-00 — 00-02-FF

VRRP IPv6 (Virtual Router Redundancy Protocol IPv6)

RFC 9568

 

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

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

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

[RFC3307] Haberman, B., «Allocation Guidelines for IPv6 Multicast Addresses», RFC 3307, DOI 10.17487/RFC3307, August 2002, <https://www.rfc-editor.org/info/rfc3307>.

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

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

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, «The Generalized TTL Security Mechanism (GTSM)», RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, «IANA Guidelines for IPv4 Multicast Address Assignments», BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <https://www.rfc-editor.org/info/rfc5771>.

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

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, <https://www.rfc-editor.org/info/rfc9542>.

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

[IPSTB] Higginson, P. and M. Shand, «Development of Router Clusters to Provide Fast Failover in IP Networks», Digital Technical Journal, Volume 9, Number 3, 1997.

[NISTIR8366] National Institute of Standards and Technology (NIST), «Guidance for NIST Staff on Using Inclusive Language in Documentary Standards,», NISTIR 8366, DOI 10.6028/NIST.IR.8366, April 2021, <https://doi.org/10.6028/NIST.IR.8366>.

[RFC1071] Braden, R., Borman, D., and C. Partridge, «Computing the Internet checksum», RFC 1071, DOI 10.17487/RFC1071, September 1988, <https://www.rfc-editor.org/info/rfc1071>.

[RFC1256] Deering, S., Ed., «ICMP Router Discovery Messages», RFC 1256, DOI 10.17487/RFC1256, September 1991, <https://www.rfc-editor.org/info/rfc1256>.

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.

[RFC2281] Li, T., Cole, B., Morton, P., and D. Li, «Cisco Hot Standby Router Protocol (HSRP)», RFC 2281, DOI 10.17487/RFC2281, March 1998, <https://www.rfc-editor.org/info/rfc2281>.

[RFC2328] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, «Virtual Router Redundancy Protocol», RFC 2338, DOI 10.17487/RFC2338, April 1998, <https://www.rfc-editor.org/info/rfc2338>.

[RFC2453] Malkin, G., «RIP Version 2», STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

[RFC3768] Hinden, R., Ed., «Virtual Router Redundancy Protocol (VRRP)», RFC 3768, DOI 10.17487/RFC3768, April 2004, <https://www.rfc-editor.org/info/rfc3768>.

[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, «SEcure Neighbor Discovery (SEND)», RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.

[RFC4311] Hinden, R. and D. Thaler, «IPv6 Host-to-Router Load Sharing», RFC 4311, DOI 10.17487/RFC4311, November 2005, <https://www.rfc-editor.org/info/rfc4311>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

[RFC7217] Gont, F., «A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)», RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.

[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, «Recommendation on Stable IPv6 Interface Identifiers», RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.

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

[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, «Operational Security Considerations for IPv6 Networks», RFC 9099, DOI 10.17487/RFC9099, August 2021, <https://www.rfc-editor.org/info/rfc9099>.

[RFC9131] Linkova, J., «Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers», RFC 9131, DOI 10.17487/RFC9131, October 2021, <https://www.rfc-editor.org/info/rfc9131>.

[VRRP-IPv6] Hinden, R. and J. Cruz, «Virtual Router Redundancy Protocol for IPv6», Work in Progress, Internet-Draft, draft-ietf-vrrp-ipv6-spec-08, 5 March 2007, <https://datatracker.ietf.org/doc/html/draft-ietf-vrrp-ipv6-spec-08>.

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

Текст для IPv6 в этой спецификации основан на [RFC2338], авторами которого являются S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. Авторы [VRRP-IPv6] признательны Erik Nordmark, Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh Gupta, Don Provan, Mark Hollinger, John Cruz, Melissa Johnson за их полезные предложения.

Текст для IPv4 в этой спецификации основан на [RFC3768]. Авторы спецификации благодарны Glen Zorn, Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve M. Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman, Russ Housley, Harald Alvestrand, Ned Freed, Ted Hardie, Bert Wijnen, Bill Fenner, Alex Zinin за их комментарии и предложения.

Спасибо Steve Nadas за работу по объединению и редактированию [RFC3768] и [VRRP-IPv6], приведшему в итоге к [RFC5798].

Спасибо Stewart Bryant, Sasha Vainshtein, Pascal Thubert, Alexander Okonnikov, Ben Niven-Jenkins, Tim Chown, Mališa Vučinić, Russ White, Donald Eastlake, Dave Thaler, Eric Kline, Vijay Gurbani за комментарии к текущему документу (RFC 9568). Спасибо Gyan Mishra, Paul Congdon, Jon Rosen за обсуждения, связанные с исключением приложений для устаревших технологий. Спасибо Dhruv Dhody и Donald Eastlake за комментарии и предложения для улучшения раздела IANA. Спасибо Sasha Vainshtein за рекомендации по проверке Maximum Advertisement Interval. Спасибо Tim Chown и Fernando Gont за дискуссии и обновления, связанные с IPv6 SLAAC. Особая благодарность Quentin Armitage за подробную рецензию и обширные комментарии к текущему документу (RFC 9568).

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

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
 
Aditya Dogra
Cisco Systems
Sarjapur Outer Ring Road
Bangalore 560103
Karnataka
India
Email: addogra@cisco.com

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

nmalykh@protokols.ru


1В оригинале ошибочно указан MAC-адрес, см. https://www.rfc-editor.org/errata/eid7947. Прим. перев.

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

RFC 9557 Date and Time on the Internet: Timestamps with Additional Information

Internet Engineering Task Force (IETF)                         U. Sharma
Request for Comments: 9557                                  Igalia, S.L.
Updates: 3339                                                 C. Bormann
Category: Standards Track                         Universität Bremen TZI
ISSN: 2070-1721                                               April 2024

Date and Time on the Internet: Timestamps with Additional Information

Даты и время в Internet — временные метки с дополнительной информацией

PDF

Аннотация

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

Документ обновляет RFC 3339 в части интерпретации локального смещения Z, которое больше не считается «подразумевающим, что UTC является предпочтительной точкой отсчёта для указанного времени».

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

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

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

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

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

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

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

1. Ведение

Даты и время применяются в самых разных приложениях Internet — от ведения журналов на серверах до создания календарей и расписаний.

Каждый момент времени может быть представлен в описательном текстовом формате с использованием временной метки. В [ISO8601-1:2019] стандартизован широко применяемый формат временных меток, а ранняя версия стандарта [ISO8601:1988] стала основой для формата дат и времени в Internet [RFC3339]. Однако этот формат очень ограничивает включение в метки дополнительной информации. Кроме того, любые контекстные сведения, связанные с данной временной меткой, требуется обрабатывать отдельно или добавлять нестандартным способом.

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

Этот документ задаёт расширение формата временных меток [RFC3339] для представления дополнительных сведений, включая часовой пояс.

Документ обновляет [RFC3339] в части интерпретации локального смещения Z, которое больше не считается «подразумевающим, что UTC является предпочтительной точкой отсчёта для указанного времени» (см. раздел 2).

1.1. Область действия

В [RFC3339] задан синтаксис временных меток для представления даты и времени в Internet. Настоящий документ задаёт синтаксис расширения с указанными ниже свойствами.

  • Суффикс расширения не обязателен, что делает метки [RFC3339] совместимыми с новым форматом.

  • Формат совместим с имеющимся популярным синтаксисом для добавления в метки времени имён часовых поясов [JAVAZDT].

  • Формат обеспечивает обобщенный способ добавления информации во временные метки.

Этот формат назван расширенным форматом дат и времени Internet (Internet Extended Date/Time Format или IXDTF).

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

  • время в будущем, указанное как местное время в конкретном часовом поясе, когда изменения в определении этого часового пояса (такие, как политические решения о введении или отмене перехода на сезонное время) влияют на момент, представляемый временной меткой;

  • «плавающее время», т. е. местное время без указания смещения от UTC или часового пояса, в котором следует интерпретировать время;

  • использование временных шкал, отличающихся от UTC, например, международных атомных часов (International Atomic Time или TAI).

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

  • политических решений, как отмечено выше;

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

  • ошибок в программах, создающих и применяющих временные метки.

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

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

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

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

UTC

Всемирное координированное время (Coordinated Universal Time), поддерживаемое с 1988 г. Международным бюро мер и весов (Bureau International des Poids et Mesures или BIPM) с учётом високосных секунд, указываемых Международной службой вращения земли и эталонных систем (International Earth Rotation and Reference Systems Service) [IERS]. С 1972 г. до 1987 г поддержка UTC полностью обеспечивалась Международным бюро времени (Bureau International de l’Heure или BIH). До 1972 г. не было общего признания UTC и гражданское время определялось отдельными юрисдикциями, использующими разные методы, чтобы пытаться следовать Мировому времени (Universal Time) на основе измерений вращения Земли.
UTC часто ошибочно называют GMT (Greenwich Mean Time — среднее время по Гринвичу) — более ранней шкалой времени, преемником которой является UTC.

ABNF

Дополненная форма Бэкуса-Наура (Augmented Backus-Naur Form) — формат, применяемый для представления допустимых строка протокола или языка, как определено в [RFC5234]. Правила Приложения B к [RFC5234] импортируются неявно.

IXDTF

Расширенный формат дат и времени Internet (Internet Extended Date/Time Format), заданный в разделе 4.

Timestamp — временная метка

Однозначное представление определённого момента времени.

UTC Offset — смещение от UTC

Разница между местным временем и UTC, обычно указываемая положительным или отрицательным числом часов и минут. Например, местное время в городе Нью-Йорк (New York, NY, USA) зимой 2023 г. отставало на 5 часов от UTC, поэтому смещение UTC было -05:00.

Z

Суффикс, который применительно ко времени означает смещение от UTC 00:00. Обычно произносится как Zulu по фонетическому представлению буквы Z в алфавите ICAO. Определение взято из раздела 2 в [RFC3339], фонетический алфавит описан в документе Международной организации гражданской авиации (International Civil Aviation Organization или ICAO) [ICAO-PA].

Time Zone — часовой пояс

Набор правил, представляющих соотношение местного времени и UTC для определённого места или региона. Математически часовой пояс можно представить как функцию, сопоставляющую временные метки со смещением от UTC. Часовой пояс позволяет детерминировано преобразовать временную метку в местное время. Можно применять часовой пояс для обратного преобразования с учётом того, что местное время может иметь несколько разных временных меток вблизи перехода на сезонное время или иных изменений смещения от UTC для данного часового пояса. В отличие от смещения от UTC во временной метке, где не принимается каких-либо допущений о смещении от UTC других связанных временных меток (что не позволяет применять его для операций с локальным временем, таких как «на 1 день позже»), часовой пояс определяет также способ получения новых временных меток на основе разницы в местном времени. Например, для расчёта времени «на один день позже данной метки в Сан-Франциско (Калифорния), нужен часовой пояс, поскольку смещение от UTC местного времени в Сан-Франциско может меняться от одного дня к другому.

IANA Time Zone — часовой пояс IANA

Именованный часовой пояс, включенный в базу данных часовых поясов (Time Zone Database), часто обозначаемую tz или zoneinfo, которые поддерживает IANA [TZDB] [BCP175]. Большинство часовых поясов IANA названо по крупнейшему городу определённого региона в рамках одним правил часового пояса, например, Europe/Paris или Asia/Tokyo [TZDB-NAMING].
Правила, заданные для именованных часовых поясов IANA, могут меняться с течением времени. Использование именованных часовых поясов IANA предполагает следование правилам, действующим на момент интерпретации. Дополнительные сведения, передаваемые с использованием имён часовых поясов меняются при изменении правил, занесённом в IANA Time Zone Database.

Offset Time Zone — часовой пояс со смещением

Часовой пояс, указанный конкретным смещением от UTC (например, +08:45) и сериализованный с использованием в качестве имени того же формата численного смещения от UTC, который применяется во временной метке [RFC3339], например, 2022-07-08T00:14:07+08:45[+08:45]
Смещение в суффиксе, не повторяющее смещение во временной метке, является несогласованным (см. параграф 3.4).
Хотя сериализация часовых поясов со смещением поддерживается в этом документе для совместимости с прежними версиями java.time.ZonedDateTime [JAVAZDT], использовать часовые пояса со смещением настоятельно не рекомендуется. В частности, программам недопустимо копировать смещение от UTC из метки в смещение часового пояса для выполнения требования других программ, которым нужен на входе суффикс часового пояса. Это будет приводить к некорректному допущению о неисзменности смещения от UTC временных меток в данном месте, что может привести к ошибкам расчётов в программах, которые выводят временные метки из полученных путём сложения, вычитания или иных операций. Например, 2020-01-01T00:00+01:00[Europe/Paris] позволяет программам добавить шесть месяцев к временной метке с поправкой на летнее время. Однако такой же расчёт, применённый к 2020-01-01T00:00+01:00[+01:00], даст некорректный результат, который будет отставать на 1 час от времени часового пояса Europe/Paris.

CLDR

Common Locale Data Repository [CLDR] — проект консорциума Unicode для предоставления приложениям данных о локальных настройках (locale data).

Дополнительные сведения о шкалах времени приведены в Приложении E к [RFC1305], разделе 3 в [ISO8601:1988] и соответствующих документах ITU [ITU-R-TF.460-6] (отметим, что [RFC1305] был заменён [RFC5905], где нет приложения E, упомянутого здесь).

2. Обновление RFC 3339

2.1. Основания

В параграфе 4.3 [RFC3339] сказано, что смещение, указанное как Z или +00:00, предполагает, что «UTC является предпочтительной точкой отсчёта для указанного времени». Смещение -00:00 указывает, что «известно время UTC, но неизвестно смещение локального времени».

Это соглашение отражает похожее соглашение для сведений о дате и времени в сообщениях электронной почты, описанное в параграфе 3.3 [RFC5322] и введённое ранее в параграфе 3.3 [RFC2822]. Это соглашение для заголовков электронной почты применяется на практике, тогда как его адаптация в [RFC3339] всегда оставалась затруднительной из-за того, что [ISO8601:2000] и более поздние версии фактически не допускают использование -00:00.

Поэтому реализации, которым нужно выразить семантику -00:00, обычно использовали вместо этого Z.

2.2. Изменения в RFC 3339

Эта спецификация обновляет параграф 4.3 в [RFC3339], приводя его в соответствие с фактической практикой интерпретации смещения Z как -00:00: «известно время UTC, но неизвестно смещение локального времени».

Параграф 4.3 в [RFC3339] в новой редакции следует представлять как указано ниже.

Если известно время в UTC, но смещение местного времени не известно, это может быть представлено как смещение Z (в исходной спецификации для этого указано смещение -00:00, которое не разрешено в [ISO8601:2000] и поэтому не обеспечивает функциональной совместимости; в параграфе 3.3 [RFC5322] описано похожее соглашение для электронной почты, которое не вызывает проблем). Семантически это отличается от смещения +00:00, которое предполагает, что UTC является предпочтительной точкой отсчёта для указанного времени.

2.3. Примечания

Отметим, что семантика локального смещения +00:00 не изменилась, оно по-прежнему означает, что UTC является предпочтительной точкой отсчёта для указанного времени.

Отметим также, что факт запрета в [ISO8601:2000] и последующих вресиях стандарта использовать -00:00 в качестве локального смещения снижает функциональную совместимость, которая может обесчпечиваться при использовании этого свойства, однако данная спецификация формально не запрещает этот синтаксис. С учётом обновления [RFC3339] вместо этого следует применять суффикс локального смещения Z.

3. Расширенный формат даты и времени в Internet (IXDTF)

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

3.1. Формат расширенной информации

Формат позволяет приложениям добавлять дополнительные важные сведения к обычным временным меткам [RFC3339]. Это делается путём определения тегов с ключом и значением через знак равенства (=). Значением тега может быть один или несколько элементов, разделённых символом дефиса (знака вычитания). Приложения могут создавать информационные суффиксы временных меток с любым числом таких тегов. В ключах используются только символы нижнего регистра. В значениях регистр символов учитывается, если не указано иное. Обработка несогласованных сведений в суффиксах рассматривается в параграфе 3.3.

3.2. Ключи регистрации для тегов расширенной информации

Ключи тегов суффиксов регистрируются с предоставлением сведений, указанных в этом параграфе. Эта информация задана по образу используемой в реестре Media Types [RFC6838] и при возникновении сомнений следует применять положения для этого реестра.

Key Identifier

Ключ (в соответствии с suffix-key из параграфа 4.1).

Registration Status

Статус регистрации — временная (Provisional) или постоянная (Permanent).

Description

Очень краткое описание ключа.

Change Controller

Контролёр изменений — лицо, отвечающее за спецификацию, регулирующую значения этого ключа. Эти сведения могут включать адрес электронной почты, списки рассылки или ссылки на соответствующие web-страницы (URL).

Reference

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

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

3.3. Необязательность, выборочность и критичность тегов

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

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

Суффиксный тег может указывать свою критичность. Это говорит получателю, что недопустимо действовать со строкой IXDTF, пока не обработан указанный тег. Критичный суффиксный тег указывается восклицательным знаком (!) после открывающей скобки (см. critical-flag в параграфе 4.1).

Строка IXDTF вида 2022-07-08T00:14:07+01:00[Europe/Paris] внутренне противоречива (см. параграф 3.4), поскольку Europe/Paris не использует часовой пояс со смещением +01:00 в июле 2022 г. Однако подсказка часового пояса в суффиксном теге является выборочной и получатель не обязан реагировать на несоответствие, он может рассматривать строку IXDTF как 2022-07-08T00:14:07+01:00

В соответствии с разделом 2 (см. также параграф 3.4) строка IXDTF 2022-07-08T00:14:07Z[Europe/Paris] не показывает несоответствия, поскольку локальное смещение Z не предполагает конкретного часого пояса при интерпретации. Применение правил Time Zone Database для Europe/Paris летом 2022 делает её эквивалентом 2022-07-08T02:14:07+02:00[Europe/Paris]

Неизвестный суффикс вида 2022-07-08T00:14:07+01:00[knort=blargel] можно игнорировать полностью (в предположении непонимания ключа knort).

В отличие от избирательного использования суффксного тена строки вида

   2022-07-08T00:14:07+01:00[!Europe/Paris]
   2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese]
   2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese]
   2022-07-08T00:14:07Z[!knort=blargel]

имеют внутреннее несоответствие или непонятную пару ключ-значение, которые помечены как критические, и получатель должен считать эти строки IXDTF ошибочными. Это означает, что приложение должно отвергнуть данные или выполнить иную обработку ошибок, например, спросить у пользователя, как следует реагировать (см. параграф 3.4).

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

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

   2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
   2022-07-08T00:14:07Z[u-ca=chinese]

будут считаться одинаковыми.

3.4. Несогласованность time-offset и сведений о часовом поясе

Временная метка [RFC3339] может включать значение time-offset, указывающее разницу между местным временем и UTC (см. раздел 4 в [RFC3339] с учётом изменений, внесённых в разделе 2 этой спецификации в параграф 4.3 [RFC3339]). Сведения, указанные значением time-offset, могут не соответствовать информации, представленной суффиксом часового пояса для метки IXDTF. Например, приложение-календарь может хранить строку IXDTF, представляющую встречу в далёком будущем в определённом часовом поясе. Если затем определение часового пояса будет изменено, исходно согласованные строки IXDTF могут стать несогласованными.

При установленном флаге критичности и несоответствии time-offset суффиксу часового пояса приложение должно реагировать на несоответствие. Если флаг критичности не установлен, приложение может реагировать на несоответствие. Реакция на несоответствие может включать отклонение временной метки или устранение несоответствия с использованием дополнительной информации, например, ввода данных от пользователя или запрограммированного поведения.

Временные метки IXDTF на рисунке 1 представляют время 00:14:07 UTC, указывая местное время с time-offset +00:00. Однако в часовом поясе Europe/London в июле 2022 г. используется смещение +01:00, поэтому временные метки будут несогласованными, причём в первом случае приложение должно реагировать на несоответствие (критический суффикс часового пояса), а во втором — может реагировать на несоответствие (выборочный суффикс).

В

2022-07-08T00:14:07+00:00[!Europe/London]
2022-07-08T00:14:07+00:00[Europe/London]

Рисунок . Несогласованность меток IXDTF.


соответствии с параграфом 4.3 [RFC3339], обновлённым в разделе 2, временные метки IXDTF могут не включать сведения о местном времени в часть [RFC3339], просто используя Z вместо числового смещения часового пояса. Временные метки IXDTF на рисунке 2 (то же время, что и в строках рисунка 1) являются несогласованными, поскольку они не указывают ни местного времени, ни местного смещения в своей части [RFC3339]. Приложения, получающие такие строки, могут местное смещение и время, используя правила для суффикса часового пояса. Например, суффикс Europe/London на рисунке 2 (как и на рисунке 1), может быть помечен как критический (т. е. приложение должно понимать сведения о часовом поясе) или является выборочным, представляющим лишь дополнительные сведения.

О

2022-07-08T00:14:07Z[!Europe/London]
2022-07-08T00:14:07Z[Europe/London]

Рисунок . Согласованность меток IXDTF.


тметим, что вместо Z можно использовать -00:00, поскольку они имеют одинаковый смысл в соответствии с разделом 2, но [ISO8601:2000] не разрешает -00:00, поэтому предпочтительно использовать Z.

4. Синтаксические расширения RFC 3339

4.1. ABNF

Ниже приведены правила, расширяющие синтаксис ABNF, заданный в [RFC3339], для включения необязательного суффикса. Расширенный формат дат и времени Internet (IXDTF) описывается правилом date-time-ext. Элементы date-time и time-numoffset взяты из параграфа 5.6 в [RFC3339], а ALPHA и DIGIT из Приложения B.1 к [RFC5234].

   time-zone-initial = ALPHA / "." / "_"
   time-zone-char    = time-zone-initial / DIGIT / "-" / "+"
   time-zone-part    = time-zone-initial *time-zone-char
                       ; но не . или ..
   time-zone-name    = time-zone-part *("/" time-zone-part)
   time-zone         = "[" critical-flag
                           time-zone-name / time-numoffset "]"

   key-initial       = lcalpha / "_"
   key-char          = key-initial / DIGIT / "-"
   suffix-key        = key-initial *key-char

   suffix-value      = 1*alphanum
   suffix-values     = suffix-value *("-" suffix-value)
   suffix-tag        = "[" critical-flag
                           suffix-key "=" suffix-values "]"
   suffix            = [time-zone] *suffix-tag

   date-time-ext     = date-time suffix

   critical-flag     = [ "!" ]

   alphanum          = ALPHA / DIGIT
   lcalpha           = %x61-7A

Рисунок . Грамматика ABNF для расширений RFC 3339.

Отметим, что time-zone и suffix-tag синтаксически похожи но первый не включает знака равенства (=). Этот особый случай доступен лишь для тегов часовых поясов.

Определению ABNF для time-zone-part соответствуют «.» и «..», которые явно исключены (см. примечание для time-zone-part).

Элемент time-zone-name предназначен быть именем IANA Time Zone. Поскольку генератор и получатель могут использовать разные версии Time Zone Database, получатели могут не знать имени IANA Time Zone и им следует рассматривать такие ситуации как любые другие несоответствия.

Примечание. На момент создания документа размер time-zone-part был ограничен 14 символами правилами из [TZDB-NAMING]. Одна платформа может соблюдать это ограничение, а другая использовать более длинные имена. Поскольку time-zone-name в конечном итоге приходится искать в локальной базе данных, создание time-zone-part на рисунке 3 намеренно сделано разрешительным.

4.2. Примеры

В этом параграфе приведены некоторые примеры расширенного формата дат и времени Internet (IXDTF).

Н

1996-12-19T16:39:57-08:00

Рисунок . Дата и время RFC 3339 со смещением часового пояса.


а рисунке 4 представлен момент 39 минут 57 секунд после 16 часов 19 декабря 1996 г. со смещением -08:00 от UTC. Отметим, что это совпадает с моментом 1996-12-20T00:39:57Z, выраженным в UTC.

Н

1996-12-19T16:39:57-08:00[America/Los_Angeles]

Рисунок . Добавление имени часового пояса.


а рисунке 5 представлен тот же момент, но дополнительно указан связанный с ним часовой пояс (Pacific Time), который принимают во внимание осведомленные о часовых поясах приложения.

Н

1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

Рисунок . Проектирование для еврейского календаря.


а рисунке 6 представлен тот же момент, но он информирует осведомленные о календаре приложения (см. раздел 5), что им следует отображать это время на еврейский календарь.

Н

1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]

Рисунок . Добавление экспериментальных тегов.


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

5. Ключ u-ca — осведомлённость о календаре

Суффикс u-ca предназначен для указания календаря, предпочтительного для представления даты и времени. Календарь — это набор правил, определяющих учёт и использование дат реализациями. Набор значений суффиксов, разрешённых для этого ключа — это значения, определённые для идентификатора календаря Unicode (Calendar Identifier) [TR35]. В [CLDR-LINKS] приведены ссылки на наиболее свежие данные о [CLDR], как стабильные, так и находящиеся в разработке.

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

Агентство IANA создало реестр Timestamp Suffix Tag Keys в новой группе реестров Internet Date/Time Format. В каждую запись реестра следует включать сведения, указанные в параграфе 3.2. Исходное содержимое реестра приведено в таблице 1.

Таблица . Исходное содержимое реестра Timestamp Suffix Tag Keys.

Идентификатор ключа

Статус регистрации

Описание

Контролёр изменений

Документ

u-ca

постоянная

Предпочтительный календарь для представления

IETF

раздел 5 в RFC 9557

Регистрация выполняется по процедуре Specification Required [BCP26] для постоянных записей и Expert Review — для временных. В последнем случае экспертам следует убедиться в наличии базовой спецификации, даже если она ещё не опубликована. Экспертам также следует экономно распределять идентификаторы ключей, указывающих на общеприменимую семантику, сохраняя их в резерве для случаев потенциально широкого использования, когда могут обеспечиваться преимущества за счёт коротких ключей. Если эксперты узнают о внедрении и использовании ключа, они могут сами инициировать регистрацию, чтобы предотвратить возможные в будущем конфликты.

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

7.1. Избыточное раскрытие

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

7.2. Уязвимости реализаций формата данных

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

7.3. Работа с несогласованными данными

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

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

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

[BCP175] Best Current Practice 175, <https://www.rfc-editor.org/info/bcp175>. На момент написания этого документа: Lear, E. and P. Eggert, «Procedures for Maintaining the Time Zone Database», BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <https://www.rfc-editor.org/info/rfc6557>.

[BCP178] Best Current Practice 178, <https://www.rfc-editor.org/info/bcp178>. На момент написания этого документа: Saint-Andre, P., Crocker, D., and M. Nottingham, «Deprecating the «X-» Prefix and Similar Constructs in Application Protocols», BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.

[BCP26] Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>. На момент написания этого документа: Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

[RFC3339] Klyne, G. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

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

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

[CLDR] Unicode CLDR, «Unicode CLDR Project», <https://cldr.unicode.org>.

[CLDR-LINKS] Unicode CLDR, «Stable Links Info», <https://cldr.unicode.org/stable-links-info>.

[DATA-MINIMIZATION] Arkko, J., «Emphasizing data minimization among protocol participants», Work in Progress, Internet-Draft, draft-arkko-iab-data-minimization-principle-05, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-arkko-iab-data-minimization-principle-05>.

[ICAO-PA] International Civil Aviation Organization, «Annex 10 to the Convention on International Civil Aviation: Aeronautical Telecommunications; Volume II Communication Procedures including those with PANS status», 7th ed., July 2016, <https://store.icao.int/annex-10-aeronautical-telecommunications-volume-ii-communication-procedures-including-those-with-pans-status>.

[IERS] IERS, «International Earth Rotation Service Bulletins», <https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html>.

[ISO8601-1:2019] ISO, «Date and time — Representations for information interchange — Part 1: Basic rules», ISO 8601-1:2019, February 2019, <https://www.iso.org/standard/70907.html>.

[ISO8601:1988] ISO, «Data elements and interchange formats — Information interchange — Representation of dates and times», ISO 8601:1988, June 1988, <https://www.iso.org/standard/15903.html>. Also available from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf>.

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

[ITU-R-TF.460-6] ITU-R, «Standard-frequency and time-signal emissions», ITU-R Recommendation TF.460-6, February 2002, <https://www.itu.int/rec/R-REC-TF.460/en>.

[JAVAZDT] Oracle, «Class DateTimeFormatter: ISO_ZONED_DATE_TIME», <https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.

[RFC1305] Mills, D., «Network Time Protocol (Version 3) Specification, Implementation and Analysis», RFC 1305, DOI 10.17487/RFC1305, March 1992, <https://www.rfc-editor.org/info/rfc1305>.

[RFC2822] Resnick, P., Ed., «Internet Message Format», RFC 2822, DOI 10.17487/RFC2822, April 2001, <https://www.rfc-editor.org/info/rfc2822>.

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

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[TR35] Davis, M., Ed., «Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML)», <https://www.unicode.org/reports/tr35/#UnicodeCalendarIdentifier>.

[TZDB] IANA, «Time zone and daylight saving time data», <https://data.iana.org/time-zones/tz-link.html>.

[TZDB-NAMING] IANA, «Theory and pragmatics of the tz code and data», <https://data.iana.org/time-zones/theory.html>.

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

Эта спецификация использует результаты ECMA TC39, в частности для предложения Temporal (временное).

Richard Gibson и Justin Grant внесли редакторские улучшения. Руководители рабочей группы SEDATE Chairs Mark McFadden и Bron Gondwana (последний также был руководителем CALEXT) помогли организовать структуры, нужные для работы в среде с несколькими SDO. John Klensin критически отнёсся к разработке этой спецификации, что привело к её существенному улучшению. Авторы особенно признательны Francesca Palombini за её общее руководство и рецензию AD.

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

Justin Grant
Email: justingrant.ietf.public@gmail.com

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

Ujjwal Sharma
Igalia, S.L.
Bugallal Marchesi, 22, 1º
15008 A Coruña
Spain
Email: ryzokuken@igalia.com
 
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org

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

nmalykh@protokols.ru


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

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

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

RFC 9567 DNS Error Reporting

Internet Engineering Task Force (IETF)                         R. Arends
Request for Comments: 9567                                     M. Larson
Category: Standards Track                                          ICANN
ISSN: 2070-1721                                               April 2024

DNS Error Reporting

Отчёты об ошибках DNS

rfc9567

Аннотация

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

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

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

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

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

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

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

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

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

1. Введение

При обслуживании полномочным сервером устаревшей зоны с подписью DNSSEC криптографические подписи для наборов записей о ресурсах (resource record set или RRset) могут теряться и проверяющий распознаватель не сможет подтвердить эти записи. Аналогичная ситуация возникает и при несоответствии записей подписавшего делегирование (Delegation Signer или DS) в родительской зоне ключу подписи в дочерней зоне.

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

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

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

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

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

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

В документе применяется терминология DNS из BCP 219 [RFC9499], а также определён ряд терминов.

Reporting resolver — информирующий распознаватель

Проверяющий распознаватель, поддерживающий отчёты об ошибках DNS.

Report query — запрос отчета

Запрос DNS, применяемый для отчёта об ошибке. Этот запрос относится к типу записей о ресурсах DNS TXT. Содержимое отчёта кодируется в QNAME запроса DNS к агенту мониторинга.

Monitoring agent — агент мониторинга

Полномочный сервер, получающий запросы отчётов и отвечающий на них. Агент указывается доменным именем (домен агента).

Agent domain — домен агента

Доменное имя, возвращаемое в опции EDNS0 Report-Channel и указывающее, куда распознаватели DNS могут направлять отчёты об ошибках.

4. Обзор

Полномочный сервер указывает поддержку отчётов об ошибках DNS включением в отклик опции EDNS0 Report-Channel с OPTION-CODE=18 и домена агента. Агент указывается полным доменным именем без сжатия в формате передачи DNS. Полномочному серверу недопустимо включать эту опцию в отклик, если имя домена агента пусто или указано null-меткой (указывает корень DNS). Полномочный сервер включает опцию EDNS0 Report-Channel без её запроса, т. е. независимо от наличия этой опции в запросе.

Если полномочный сервер указал поддержку отчётов об ошибках DNS и имеется проблема, о которой можно сообщить с помощью расширенных ошибок DNS, сообщающий распознаватель кодирует отчёт об ошибке в QNAME запроса отчёта. Отвечающий распознаватель создаёт QNAME путём конкатенации метки _er, QTYPE, QNAME, вызвавшего отказ, расширенного кода ошибки DNS (в соответствии с [RFC8914]), ещё одной метки _er и домена агента. Пример представлен в параграфе 4.1, а спецификация — в параграфе 6.1.1. Отметим, что обычный код RCODE не включается, поскольку он не относится к расширенным кодам ошибок DNS. Полученный в результате запрос передаётся отвечающим распознавателем как стандартный запрос DNS для записи TXT.

Запрос отчёта в конечном счёте поступает к агенту мониторинга, возвращающему отклик, который может кэшироваться отвечающим распознавателем. Это кэширование очень важно, поскольку оно снижает число запросов отчётов, передаваемых отвечающим распознавателем для одной и той же проблемы (т. е. при кэшировании отправляется лишь 1 запрос в интервале TTL). Число запросов отчётов об ошибках может быть снижено путём оптимизаций, пдобных описанным в [RFC8020] и [RFC8198].

В этом документе не даётся рекомендаций по содержимому RDATA в записях TXT.

4.1. Пример

Отвечающий распознаватель передаёт для имени broken.test. запрос тип A. Домен test. размещён на нескольких полномочных серверах, один из которых обслуживает устаревшую версию зоны (test.). На этом сервере задан домен агента a01.agent-domain.example. При получении этим сервером запроса для broken.test. он будет передавать отклик с опцией EDNS0 Report-Channel и доменным именем a01.agent- domain.example.

Отвечающий распознаватель не сможет проверить broken.test. RRset для типа A (тип 1 для RR), поскольку запись RRSIG является просроченной. Распознаватель создаёт QNAME _er.1.broken.test.7._er.a01.agent-domain.example. и распознает это имя. QNAME указывает расширенную ошибку DNS 7, возникшую при попытке подтвердить broken.test. для типа A (тип 1 для RR).

При получении этого запроса агентом мониторинга (оператор полномочного сервера для a01.agent-domain.example.) агент может определить, что зона test. содержит просроченную подпись (расширенная ошибка DNS 7) для типа A применительно к имени broken.test.. Агент мониторинга может связаться с операторами test. для исправления ошибки.

5. Спецификация опции EDNS0

Метод использует опцию EDNS0 [RFC6891] для указания домена агента в откликах DNS, как показано на рисунке.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION-CODE = 18       |       OPTION-LENGTH           |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/                         AGENT DOMAIN                          /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

OPTION-CODE

2-октетный код EDNS0, используемый в опции EDNS0 для индикации поддержки отчётов об ошибках. Этот код опции EDNS0 называется Report-Channel.

OPTION-LENGTH

2-октетное значение размера поля AGENT DOMAIN в октетах.

AGENT DOMAIN

Полное доменное имя [RFC9499] в формате передачи DNS без сжатия.

6. Спецификация отчётов об ошибках DNS

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

Класс DNS не указывается в отчётах об ошибках.

6.1. Спецификация отвечающего распознавателя

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

В запросы недопустимо включать опцию EDNS0 Report-Channel.

Отвечающему распознавателю недопустимо использовать отчёт об ошибках DNS, если полномочный сервер вернул пустое поле AGENT DOMAIN в опции EDNS0 Report-Channel.

Чтобы агент мониторинга имел большую уверенность в достоверности отчёта, отвечающему распознавателю следует передавать отчёты об ошибках по протоколу TCP [RFC7766] или иному протоколу с явным соединением, а также следует использовать DNS Cookie [RFC7873]. Это затруднит подмену адреса источника.

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

6.1.1. Создание запроса отчёта

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

  • Метка, содержащая строку _er.

  • QTYPE из запроса, вызвавшего расширенную ошибку DNS, в виде десятичного значения в одной метке DNS. При наличии в запросе дополнительных QTYPE, как описано в [MULTI-QTYPES], они представляются уникальными упорядоченными десятичными значениями через дефис (-). Например при наличии в запросе QTYPE A и AAAA они представляются как метка 1-28.

  • Список непустых меток, представляющих имя запроса, вызвавшего отчёт об ошибке DNS.

  • Расширенный код ошибки DNS, представленный десятичным значением в одной метке DNS.

  • Метка, содержащая строку _er.

  • Домен агента, полученный в опции EDNS0 Report-Channel от полномочного сервера.

Передача запроса отчёта с QNAME размером более 255 октетов недопустима.

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

6.2. Спецификация полномочного сервера

Полномочному серверу недопустимо включать в отклик более одной опции EDNS0 Report-Channel. Полномочный сервер включает в отклики опцию EDNS0 Report-Channel без запроса. Наличие EDNS0 Report-Channel в запросах не требуется.

6.3. Спецификация агента мониторинга

Полномочному серверу для домена агента рекомендуется возвращать позитивный отклик (без NODATA и NXDOMAIN) с записью TXT.

Агенту мониторинга следует отвечать на запросы без DNS Cookie, полученные по протоколу UDP, откликом с битом отсечки (TC), чтобы предложить распознавателю передать запрос по протоколу TCP.

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

Агентство IANA выделило указанный в таблице 1 код в реестре DNS EDNS0 Option Codes (OPT).

Таблица .

 

Значение

Имя

Статус

Документ

18

Report-Channel

Standard

RFC 9567

 

Агентство IANA выделило указанный в таблице 2 код в реестре Underscored and Globally Scoped DNS Node Names.

Таблица .

 

Тип RR

Имя узла

Документ

TXT

_er

RFC 9567

 

8. Вопросы эксплуатации

8.1. Выбор домена агента

Имя домена агента рекомендуется делать достаточно коротким, чтобы в запрос отчёта можно было включить более длинное значение QNAME. В качестве домена агента недопустимо указывать поддомен домена, для которого передаются отчёты. Например, если полномочный сервер обслуживает домен foo.example, недопустимо использовать домен агента с суффиксом foo.example.

8.2. Управление оптимизацией кэширования

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

Если агент мониторинга возвращает NXDOMAIN (ошибка имени), в соответствии с [RFC8020] любое имя в этом домене или его иерархии считается недоступным и негативное кэширование будет предотвращать последующие запросы для всего, что находится в этом домене или его иерархии, на время, определяемое TTL негативного отклика [RFC2308]. Поскольку агент мониторинга может не знать содержимого всех зон, для которых он служит агентом, ему недопустимо передавать NXDOMAIN для отслеживаемых доменов, поскольку это может препятствовать последующим запросам. Одним из методов предотвращения NXDOMAIN является использование шаблонного имени домена [RFC4592] в зоне для домена агента.

При подписанном домене агента распознаватель может использовать интенсивное негативное кэширование (см. [RFC8198]). Эта оптимизация использует записи NSEC и NSEC3 (без opt-out) и позволяет распознавателю синтезировать шаблонные имена. В таких случаях распознаватель не передаёт последующих запросов, поскольку может синтезировать отклик из кэшированных сведений.

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

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

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

Отчёты об ошибках DNS следует выполнять с использованием минимизации имён в запросах DNS [RFC9156] для повышения уровня приватности.

Отчёты DNS выполняются без какой-либо проверки подлинности между отвечающим распознавателем и полномочным сервером домена агента.

Распознавателям следует передавать отчёты об ошибках по протоколу TCP [RFC7766] или использовать DNS Cookie [RFC7873]. Это осложнит подмену адреса отправителя. Агенту мониторинга следует отвечать на полученные по протоколу UDP запросы без DNS Cookie откликом с установленным битом отсечки (TC), чтобы предложить распознавателю передавать запросы по протоколу TCP.

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

Агентам мониторинга, получающим отчёты об ошибках по протоколу UDP, следует учитывать, что адрес отправителя и сам отчёт могут быть поддельными.

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

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

Хотя этот документ не задаёт содержимого RDATA в записях TXT, при записи содержимого RDATA в системный журнал агент мониторинга должен предполагать возможную вредоносность этого содержимого и принимать соответствующие меры для предотвращения использования такого содержимого. Одним из решений является запись в журнал в шестнадцатеричном формате, что позволяет предотвратить возможность исполнения кода, представленного строками, как в уязвимости, описанной в [CVE-2021-44228].

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

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

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

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

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

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

[CVE-2021-44228] CVE, «CVE-2021-44228», 26 November 2021, <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228>.

[MULTI-QTYPES] Bellis, R., «DNS Multiple QTYPEs», Work in Progress, Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-multi-qtypes-00>.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/info/rfc4592>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.

[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, «DNS Transport over TCP — Implementation Requirements», RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.

[RFC7873] Eastlake 3rd, D. and M. Andrews, «Domain Name System (DNS) Cookies», RFC 7873, DOI 10.17487/RFC7873, May 2016, <https://www.rfc-editor.org/info/rfc7873>.

[RFC8020] Bortzmeyer, S. and S. Huque, «NXDOMAIN: There Really Is Nothing Underneath», RFC 8020, DOI 10.17487/RFC8020, November 2016, <https://www.rfc-editor.org/info/rfc8020>.

[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, «Aggressive Use of DNSSEC-Validated Cache», RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.

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

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

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

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

Этот документ основан на идее Roy Arends и David Conrad. Авторы благодарны Peter van Dijk, Stephane Bortzmeyer, Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst, Benno Overeinder, Paul Wouters, Petr Spacek за их вклад в работу.

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

Roy Arends
ICANN
Email: roy.arends@icann.org
 
Matt Larson
ICANN
Email: matt.larson@icann.org

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

nmalykh@protokols.ru


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

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

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

RFC 9564 Faster Than Light Speed Protocol (FLIP)

Independent Submission                                       M. Blanchet
Request for Comments: 9564                                      Viagenie
Category: Informational                                     1 April 2024
ISSN: 2070-1721

Faster Than Light Speed Protocol (FLIP)

Протокол FLIP

PDF

Аннотация

Последние достижения в сфере искусственного интеллекта (artificial intelligence или AI), такие как большие языковые модели позволяют разработать для Internet протокол, работающий быстрее скорости света (Faster than LIght speed Protocol или FLIP). FLIP позволяет избежать перегрузок, повысить безопасность и ускорить доставку пакетов в Internet с использованием AI для предсказания будущих пакетов на приёмной стороне до их прибытия. Документ описывает протокол, его различные инкапсуляции и некоторые эксплуатационные соображения.

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

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

Это вклад в RFC Series, независимый от других потоков RFC. RFC Editor принял решение о публикации документа по своему усмотрению и не делает каких-либо заявлений о его ценности для реализации или внедрения. Документы, одобренные для публикации RFC Editor, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

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

1. Введение

Представление ChatGPT широкой публике состоялось 30 ноября 2022 г. [CHATGPT]. С тех пор большие языковые модели (large language model или LLM) используются в самых разных приложениях. Они демонстрируют мощные способности генерировать точные результаты на основе входных данных и соответствующего обучения LLM. Данная спецификация протокола использует эту способность для предсказания будущих рпкетов до их прибытия к принимающему партнёру, что позволяет достичь скорости доставки, превышающей световую, поэтому протокол получи название «Быстрее скорости света» (Faster than LIght speed Protocol или FLIP).

Поскольку FLIP может предсказывать пакеты, кадры или потоки байтов, он может применяться на любом уровне стека протоколов IP. Более того, при должном обучении FLIP может также предсказывать будущие шифрованные пакеты, поскольку шифрование — это просто строки байтов. Данная спецификация показывает FLIP как промежуточный (shim) заголовок канального (L2) и транспортного уровня. Поскольку FLIP можно применять на любом уровне, предполагается разработка дополнительных спецификаций, таких как предсказание запросов и откликов HTTP, содержимого электронной почты и т. д.

Поскольку скорость связи в дальнем космосе, к сожалению, ограничена скоростью света, а расстояния между космическими аппаратами и Землёй очень велики, возникают очень большие задержки при связи. Обеспечивая доставку быстрее скорости света (faster-than-light-speed), FLIP является ключевым дополнением для сетей IP в дальнем космосе [IP-DEEP-SPACE].

2. Подготовка партнёров по протоколу

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

Например, реализация может взять большое число файлов с собранными пакетами (Packet Capture или PCAP) от tcpdump в разных точках Internet. То, что трафик может оказаться зашифрованным, не имеет значения, поскольку хорошо обученная LLM способна предсказать зашифрованных трафик так же хорошо, как открытый.

3. Заголовок FLIP

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

+----------+---------+----------------+----------------+
|  Version | Command | Inner Protocol | Optional Data  |
+----------+---------+----------------+----------------+

Version — версия

Это поле переменного и незаданного размера содержит хэш-значение SHA-256 для модели, используемое в качестве версии, как описано в разделе 5.

Command — команда

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

Таблица .

 

Команда

Код

Документ

model

0x01

RFC 9564

data

0x02

RFC 9564

 

Inner Protocol — внутренний протокол

Поскольку заголовок FLIP является промежуточным (shim), в этом поле указывается внутренний (вложенный) протокол. Например, промежуточный заголовок FLIP может помещаться между заголовками IP и TCP, а пакет IP будет содержать код FLIP в качестве транспортного протокола. Тогда поле внутреннего протокола FLIP будет содержать код TCP, который иначе размещался бы в заголовке пакета IP.

Optional Data — необязательные данные

Некоторые команды имеют дополнительные данные, размещаемые вслед за полем Command.

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

Для подобающей сигнализации вышележащему уровню о наличии заголовка FLIP резервируется определённый код (codepoint) на уровне ниже FLIP. В разделе 7 указаны такие регистрации для IP и транспортных кодов.

4. Работа протокола

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

Команды протокола описаны ниже.

Model (codepoint 0x01) — модель

Эта команда предоставляет партнёрам возможность передать свою модель по основному каналу (in-band) протокола FLIP. Сама модель передаётся в поле Optional Data заголовка FLIP. Перед фактическими данными модели помещается заголовок MIME с подходящим типом носителя. Если типа носителя для модели не существует, его следует зарегистрировать в реестре IANA Media Type.

Data (codepoint 0x02) — данные

Эта команда говорит принимающему партнёру, что следующие за ней данные могут быть предсказаны, благодаря чему достигается производительность выше скорости света (faster-than-light-speed).

Передачу модели партнёру по основному каналу (in-band) следует выполнять редко, поскольку размер моделей может быть большим. Кроме того, такая передача фактически раскрывает модель для прослушивающего линии злоумышленника. Разработчики могут предусмотреть использование пост-квантового криптографического алгоритма, который устойчив к предсказаниям AI, т. е. постквантового криптографического алгоритма с искусственным интеллектом (post-Quantum-AI cryptographic algorithm).

5. Версия протокола

Как описано в [RFC6709], большинство протоколов должно разрабатываться с возможностью будущих улучшений, например, предоставляя способ указать новую версию протокола. В случае FLIP обученные модели всегда будут улучшаться в результате нового обучения. В качестве номера версии применяется хэш-значение SHA-256 [RFC6234] обученной модели, чтобы каждый партнёр знал используемую версию FLIP. Значение SHA-256 помещается в поле Version заголовка FLIP, как описано выше. С учётом того, что новые значения SHA-256 являются не последовательными, а полностью случайными, это предотвращает атаки с повторным использованием (replay) предсказаний будущего.

6. Продолжение работы

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

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

Коды для FLIP могут регистрироваться в реестрах IANA:

  • Protocol Numbers [IANA-PN]: 345, FLIP, Faster than LIght speed Protocol, RFC 9564;

  • Service Name and Transport Protocol Port Number Registry [IANA-SN]: FLIP, 68534, udp and tcp, RFC 9564

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

Способность предсказывать будущие пакеты на основе LLM может использоваться злоумышленниками, прослушивающими трафик путём его перехвата. Если у них есть доступ к той же модели, которую использует целевой партнёр, можно предсказать следующие пакеты и начать различные атаки, включая такие новые атаки, как «воспроизведение будущего» (futureplay attack). По сравнению с типичными replay-атаками в этом случае злоумышленник может предсказать будущие пакеты и заранее отправить их получателю. Хотя сейчас это может показаться неочевидным, эти новые атаки следует изучить, пока они не стали проблемой. Поэтому предлагается продолжить исследования в этом направлении.

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

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

[CHATGPT] Wikipedia, «ChatGPT», 20 March 2024, <https://en.wikipedia.org/w/index.php?title=ChatGPT&oldid=1214732037>.

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

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

[IP-DEEP-SPACE] Blanchet, M., Huitema, C., and D. Bogdanović, «Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions», Work in Progress, Internet-Draft, draft-many-deepspace-ip-assessment-01, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-many-deepspace-ip-assessment-01>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, «US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)», RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, «Design Considerations for Protocol Extensions», RFC 6709, DOI 10.17487/RFC6709, September 2012, <https://www.rfc-editor.org/info/rfc6709>.

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

Поскольку в этой спецификации протокола применяется искусственный интеллект и большие языковые модели, было решено, что тупым людям недопустимо рецензировать эту спецификацию. Вместо этого спецификация была представлена нескольким чат-сервисам LLM и улучшена в соответствии с их комментариями и предложениями, что и отмечено здесь. Фактически эта спецификация могла быть полностью создана чат-службами LLM. Более того, с учётом того, что создаваемые IETF спецификации полагаются на человеческий интеллект, следует предусмотреть также возможность использования LLM для подготовки спецификаций. Наконец, учитывая трудности с подбором экспертов на руководящие позиции (например, в IESG или IAB), следует рассмотреть использование LLM для замещения этих позиций. К сожалению, из соображений приватности, безопасности и законодательства использованные для этой работы чат-службы LLM не могут быть названы здесь.

Адрес автора

Marc Blanchet
Viagenie
Email: marc.blanchet@viagenie.ca

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

nmalykh@protokols.ru

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

RFC 9499 DNS Terminology

Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 9499                                         ICANN
BCP: 219                                                     K. Fujiwara
Obsoletes: 8499                                                     JPRS
Updates: 2308                                                 March 2024
Category: Best Current Practice                                         
ISSN: 2070-1721

DNS Terminology

Терминология DNS

PDF

Аннотация

Система доменных имён (Domain Name System или DNS) определена в десятках разных RFC. Терминология, используемая при разработке и внедрении протоколов DNS, а также в работе операторов систем DNS, изменилась за десятилетия, прошедшие с момента исходного определения DNS. В этом документе приведены современные определения для многих терминов, применяемых в DNS.

Документ обновляет RFC 2308, уточняя определения терминов forwarder и QNAME. Документ отменяет RFC 8499, добавляя множество определений и уточнений. Полные списки изменённых и новых определений даны в Приложениях A и B.

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

Документ относится к категории Internet Best Current Practice.

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

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

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

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

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

1. Введение

DNS — простой протокол «запрос-отклик», где сообщения имеют общий формат для обоих направлений (в разделе 2 дано определение термина global DNS, который для многих зачастую означает то же, что и DNS). Протокол и формат сообщений заданы в [RFC1034] и [RFC1035], где определены некоторые термины. В последующих RFC определены другие термины. Некоторые из терминов, заданных в [RFC1034] и [RFC1035], сейчас имеют иное значение, нежели в 1987 г.

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

Связанные с DNS термины иногда определяют другие организации, например, рабочая группа WHATWG определила термин domain (см. https://url.spec.whatwg.org/). Консультативный комитет системы корневых серверов (Root Server System Advisory Committee или RSSAC) имеет хороший глоссарий [RSSAC026].

Большинство приведённых здесь определений представляют согласованный подход сообщества DNS — разработчиков протокола и операторов. Некоторые определения отличаются от прежних RFC и такие различия отмечены. При совпадении приведённых здесь определений с определениями прежних RFC приводится цитата из такого RFC. Если определение так или иначе изменено, прежний RFC указывается, но даётся новое определение. Список обновлённых определений представлен в Приложении A.

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

Отметим, что нет согласованного определения DNS. Можно рассматривать DNS как некую комбинацию общепринятой схемы именования объектов в Internet, распределенной базы данных, представляющей имена и некоторые свойства этих объектов, архитектуры, обеспечивающей распределенное обслуживание, устойчивость и нестрогую когерентность распределенной базы данных и простого протокола «запрос-отклик» (как отмечено ниже), реализующего эту архитектуру. В разделе 2 даны определения терминов global DNS и private DNS, чтобы разобраться с этими разными определениями.

Использование заглавных букв в терминах DNS часто не согласуется в разных RFC и практике применения DNS. В этом документе заглавные буквы применяются в соответствии с наиболее распространённой практикой и не указывается, что иное использование заглавных букв является ошибочным или устаревшим. В некоторых случаях применяется несколько стилей использования заглавных букв для одного термина из-за цитирования разных RFC.

Термины byte (байт) и octet (октет) в этом документе взаимозаменяемы. Использование обоих терминов обусловлено их применением в прежних RFC, определяющих термины DNS.

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

2. Имена

Naming system — система именования

Система именования связывает имена с данными. Системы именования имеют множество важных аспектов, позволяющих отличать одну систему от другой, наиболее заметные из них включают:
  • состав имён;
  • формат имён;
  • администрирование имён;
  • типы данных, которые могут быть связаны с именами;
  • типы метаданных для имён;
  • протокол для получения данных по имени;
  • контекст для распознавания имени.
Отметим, что этот список представляет небольшое подмножество аспектов, которые были определены людьми для систем именования, и IETF ещё предстоит согласовать набор аспектов, которые хорошо подойдут для сравнения систем именования. Например, такие аспекты могут включать протокол для обновления данных по имени, приватность имён, приватность связанных с именами данных, но эти аспекты не определены так же хорошо, как перечисленные выше. Приведённый список выбран потому, что он помогает описать DNS и похожие на DNS системы именования.

Domain name — доменное имя

Упорядоченный список из одной или нескольких меток.
Отметим, что это определение независимо от DNS RFC ([RFC1034] и [RFC1035]) и применимо к отличным от DNS системам. В [RFC1034] определено пространство доменных имён (domain name space) с использованием математических деревьев и их узлов в теории графов и это определение имеет такой же практический результат, что и приведённое здесь. Любой путь в направленном ациклическом графе можно представить доменным именем, состоящим из меток узлов графа, упорядоченных по удалённости от корня (это соглашение DNS, включённое в данный документ). Доменное имя, в котором последняя метка указывает корень графа, является полным, другие имена, чьи метки формируют строгий префикс полного доменного имени, связаны с первым опущенным узлом.
В разных документах IETF и других организаций термин «доменное имя» может использоваться по-разному. Обычно в предшествующих документах этот термин означает «имена, соответствующие синтаксису [RFC1035]», возможно, с дополнительными правилами, такими как «и являются или могут быть распознаваемыми в глобальной системе DNS» или «но только с использованием формата представления».

Label — метка

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

Global DNS — глобальная система DNS

С использованием краткого набора аспектов из Naming system глобальную систему DNS можно определить, как показано ниже. Большинство правил взято из [RFC1034] и [RFC1035], но термин global DNS определяется впервые.

Composition of names — состав имён

Имя в глобальной системе DNS имеет одну или несколько меток, размер каждой из которых составляет от 0 до 63 октетов (включительно). В полном доменном имени последняя метка в упорядоченном списке имеет размер 0 октетов, это единственная метка такого размера и она называется корнем (root) или корневой меткой (root label). Размер доменного имени в глобальной системе DNS не может превышать 255 октетов в формате передачи, корень вносит в этот размер 1 октет (в Multicast DNS [RFC6762] разрешаются имена размером 255 байтов плюс 1 завершающий нулевой байт на основе иной интерпретации RFC 1035 и учёта включаемого в 255 октетов).

Format of names — формат имён

Имена в глобальной системе DNS являются доменными именами. Имеется три формата имён — формат передачи, формат представления и базовый формат отображения.

Wire format — формат передачи

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

Presentation format — формат представления

Форматом представления имён в глобальной системе DNS является список меток, упорядоченных по удалению от корня, в кодировке ASCII с разделением меток символом точки (.). Ф формате представления полное доменное имя включает корневую метку и связанную с ней точку. Например, полное доменное имя с двумя некорневыми метками в формате представления будет иметь вид «example.tld.», а не «example.tld». В [RFC1035] определён метод показа октетов, не отображающихся в кодировке ASCII.

Common display format — базовый формат отображения

Базовый формат отображения применяется в приложениях и произвольных текстах. Он отличается от формата представления лишь необязательностью указания корневой метки и связанной с ней точки. Например, в базовом формате отображения полное доменное имя с двумя некорневыми метками обычно имеет вид «example.tld», а не «example.tld.». Имена в базовом формате отображения обычно записываются так, чтобы с учётом направления письма метки размещались в порядке снижения расстояния от корня. Например, в английском языке и языке программирования C корень или метка верхнего уровня (Top-Level Domain или TLD) размещаются справа, а в арабских языках могут размещаться слева в зависимости от местных традиций.

Administration of names — администрирование имён

Администирование задаётся путём передачи полномочий (см. определение термина delegation в разделе 7). Правила администрирования корневой зоны в глобальной системе DNS определяются операционным сообществом, организуемым в рамках Корпорации Internet по назначению имён и номеров (Internet Corporation for Assigned Names and Numbers или ICANN). Это сообщество выбирает оператора функций IANA (Functions Operator) для корневой зоны глобальной системы DNS. Серверы имён, обслуживающие корневую зону, предоставляются независимыми корневыми операторами. В других зонах глобальной системы DNS имеются свои правила администрирования.

Types of data that can be associated with names — типы данных, которые могут быть связаны с именами

С именем могут (необязательно) связаны записи о ресурсах. Имеется множество типов таких записей с уникальными структурами данных, определёнными в разных RFC и реестре IANA [IANA_Resource_Registry].

Types of metadata for names — типы метаданных для имён

Любое имя, опубликованное в DNS, представляется как набор записей о ресурсах (см. определение термина RRset в разделе 5). Некоторые имена сами по себе не имеют связанных с ними данных в глобальной системе DNS, но «присутствуют» в DNS, поскольку являются частью более длинных имён, с которыми связаны данные (см. определение термина empty non-terminals в разделе 7).

Protocol for getting data from a name — протокол для получения данных по имени

Протокол, описанный в [RFC1035].

Context for resolving a name — контекст для распознавания имени

Корневая зона глобальной системы DNS, распределенная по общедоступным техническим идентификаторам (Public Technical Identifier или PTI).

Private DNS — приватная система DNS

Имена, использующие протокол из [RFC1035], но не связанные с корневой зоной глобальной системы DNS, или недоступные всем в Internet по иным причинам. Система может использовать одновременно имена глобальной системы DNS и одной или нескольких приватных систем DNS (см., например, Split DNS в разделе 6).
Отметим, что имена, не появляющиеся в DNS и не предназначенные для поиска с использованием протокола DNS, не являются частью глобальной или приватной системы DNS, даже если они являются доменными именами.

Multicast DNS (mDNS)

«Multicast DNS (mDNS) обеспечивает возможность выполнения операций в стиле DNS на локальном канале при отсутствии какого либо обычного сервера Unicast DNS. В дополнение к этому Multicast DNS выделяет часть пространства имён DNS для свободного локального применения без необходимости внесения ежегодной платы, передачи полномочий или иной настройки традиционных серверов DNS для поиска этих имён.» (цитата из Аннотации к [RFC6762]). Несмотря на использование совместимого формата передачи, mDNS, строго говоря, является протоколом, отличным от DNS. Кроме того, в приведённой выше цитате вместо «части пространства имён DNS» уместней было бы сказать «часть пространства доменных имён». Имена mDNS не предназначены для поиска через DNS.

Locally served DNS zone — локально обслуживаемая зона DNS

Локально обслуживаемая зона DNS является частным случаем приватной системы DNS, где имена распознаются с использованием протокола DNS в локальном контексте. В [RFC6303] заданы субдомены IN-ADDR.ARPA, являющиеся зонами с локальным обслуживанием. Распознавание имён через локально обслуживаемые зоны может давать неоднозначные результаты. Например, одно и то же имя может распознаваться по-разному в разных контекстах локально обслуживаемых зон DNS. Контекст локально обслуживаемой зоны DNS может быть явным (например, как указано в [RFC6303] и [RFC7793]) или неявным (например, заданным локальным администратором DNS и неизвестным клиенту распознавания).

Fully Qualified Domain Name (FQDN) — полное доменное имя

Зачастую это просто эквивалент термина domain name of a node, указанного выше, однако такой вариант неоднозначен. Строго говоря, полное доменное имя должно включать все метки, в том числе метку корня с нулевым размером — такое имя записывается как «www.example.net.» (точка в конце). Однако все имена имеют общий корень, поэтому они часто указываются относительно этого корня (www.example.net) и все равно называются полными. Термин был введён в [RFC819]. В этом документе имена часто указываются от корня.
Необходимость термина «полное доменное имя» обусловлена существованием неполных доменных имён, где одна или несколько последних меток в списке опущены (например, www относительно example.net указывает www.example.net). Такие относительные имена понятны только с учётом контекста.

Host name — имя хоста

Этот термин и его эквивалент hostname используются широко, но не определены в [RFC1034], [RFC1035], [RFC1123], [RFC2181]. Система DNS исходно была развёрнута в среде с таблицами хостов (Host Table), как описано в [RFC952], и термин, вероятно, неформально следовал определению из этого документа, но со временем определение изменилось. Имя хоста часто указывает доменное имя, соответствующее правилам из параграфа 3.5 в [RFC1034], которые называют также предпочтительным синтаксисом имён (preferred name syntax), где каждый символ в каждой метке является буквой, цифрой или дефисом (-). Отметим, что любая метка в доменном имени может содержать любые значения октетов, а имена хостов обычно считаются доменными именами, где каждая метка следует правилам предпочтительного синтаксиса имён с поправкой на то, что метки могут начинаться с цифр ASCII (параграф 2.1 в [RFC1123]).
Термин hostname иногда используют для обозначения первой метки в FQDN, например, printer в printer.admin.example.com (иногда это формализуется в конфигурации операционных систем). Кроме того, термин иногда служит для описания любого имени, указывающего машину, и может включать метки, не соответствующие правилам предпочтительного синтаксиса имён.

Top-Level Domain (TLD) — домен верхнего уровня

Доменом верхнего уровня называют зону на 1 уровень ниже корня, такую как com или jp. С точки зрения DNS в TLD нет ничего особого. Большинство TLD являются зонами, ориентированными на передачу полномочий (определена в разделе 7), и их функционирование связано с существенными политическими вопросами. TLD часто делятся на подгруппы, такие как домены верхнего уровня с кодом страны (Country Code Top-Level Domain или ccTLD), базовые домены верхнего уровня (Generic Top-Level Domainили gTLD) и т. п. такое деление является вопросом политики и выходит за рамки этого документа.

Internationalized Domain Name (IDN) — доменное имя на национальном языке

Протокол доменов на национальных языках для приложений (Internationalized Domain Names for Applications или IDNA) обеспечивает стандартный механизм для обработки доменных имён с символами, отличными от ASCII, в приложениях DNS. На момент подготовки этого документа текущий стандарт, обычно называемый IDNA2008, определялся [RFC5890], [RFC5891], [RFC5892], [RFC5893] и [RFC5894]. В этих документах задано множество относящихся к IDN терминов, таких как LDH label, A-label, U-label. В [RFC6365] определены дополнительные термины, связанные с использованием национальных языков (часть их относится к IDN), в [RFC6055] приведено дополнительное рассмотрение IDN, включая новую терминологию.

Subdomain — субдомен

«Домен является субдоменом другого домена, если он содержится в том домене. Для проверки принадлежности достаточно убедиться, что в конце имени субдомена содержится имя домена. » (цитата из параграфа 3.1 в [RFC1034]). Например, в имени хоста nnn.mmm.example.com компоненты mmm.example.com и nnn.mmm.example.com являются субдоменами домена example.com. Отметим, что при сравнении учитываются метки целиком, т. е. ooo.example.com не будет субдоменом oo.example.com.

Alias — псевдоним

Владелец записи о ресурсе CNAME или субдомен владельца записи о ресурсе DNAME (определена в [RFC6672]). См. также canonical name.

Canonical name — каноническое имя

Запись о ресурсе CNAME «идентифицирует имя своего владельца в качестве псевдонима и задаёт соответствующее каноническое имя в разделе RDATA записи RR» (цитата из параграфа 3.6.2 в [RFC1034]). Такое использование термина «канонический» связано с математической концепцией канонической формы.

CNAME

«По традиции [владельца] метку[и] записи CNAME называют просто «CNAME». Это неудачная традиция, поскольку CNAME является сокращением «canonical name», а [владелец] метку[и] записи CNAME чаще всего не является каноническим именем» (цитата из параграфа 10.1.1 в [RFC2181] с заменой метки на владельца метки).

3. Коды откликов DNS

Некоторые коды откликов (response code или RCODE), заданные в [RFC1035], получили свои сокращённые имена. Все RCODE перечислены в реестре [IANA_Resource_Registry], где строчные и прописные буквы смешаны, хотя в большинстве документов применяются только заглавные буквы. В этом разделе описаны некоторые распространённые имена, заданные в [RFC1035], а также включён новый код и его описание. Полный список RCODE приведён в реестре IANA.

NOERROR

Этот код описан как отсутствие ошибок (No error condition) в параграфе 4.1.1 [RFC1035].

FORMERR

Этот код описан как ошибка формата, не позволяющая серверу интерпретировать запрос (Format error — The name server was unable to interpret the query), в параграфе 4.1.1 [RFC1035].

SERVFAIL

Этот код описан как отказ сервера, связанный с его неспособностью обработать запрос из-за своих проблем (Server failure — The name server was unable to process this query due to a problem with the name server), в параграфе 4.1.1 [RFC1035].

NXDOMAIN

Этот код описан как ошибка имени, связанная с отсутствием на сервере указанного в запросе имени (Name Error […] this code signifies that the domain name referenced in the query does not exist), в параграфе 4.1.1 [RFC1035]. В [RFC2308] код NXDOMAIN указан как синоним Name Error.

NOTIMP

Этот код описан как отсутствие поддержки сервером имён запрошенной функции (Not Implemented — The name server does not support the requested kind of query) в параграфе 4.1.1 [RFC1035].

REFUSED

Этот код описан как отклонение запроса в соответствии с правилами сервера, например, нежеланием предоставлять сведения конкретному запрашивающему или выполнять определённую информацию, такую как перенос зоны, для конкретных данных (Refused — The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data) в параграфе 4.1.1 [RFC1035].

NODATA

«Псевдо-RCODE, указывающий, что имя корректно для данного класса, но записей этого типа нет. Код NODATA выводится из ответа» (цитата из раздела 1 в [RFC2308]). «NODATA указывается ответом с RCODE = NOERROR и отсутствием имеющей отношение к делу информации в разделе ответов. Раздел полномочий будет содержать запись SOA или в нем совсем не будет записей NS» (цитата из параграфа 2.2 в [RFC2308]). Отметим, что рекомендации (referral) имеют формат, похожий на NODATA, и в [RFC2308] указано, как различать их.
Термин NXRRSET иногда применяется как синоним NODATA, однако это является ошибкой, поскольку для NXRRSET задан конкретный код ошибки [RFC2136].

Negative response — негативный отклик

Отклик, заказывающий, что конкретного набора RRset не существует, или RCODE для него говорит, что сервер не может ответить. Типы негативных откликов подробно рассмотрены в разделах 2 и 7 [RFC2308].

4. Транзакции DNS

Заголовком сообщения DNS являются первые 12 октетов. Многие поля и флаги на рисунках в параграфах 4.1.1 — 4.1.3 [RFC1035] указываются их именами. Например, коды откликов указаны как RCODE, данные записей — как RDATA, а бит полномочности ответа — как флаг (бит) AA.

Class — класс

Класс указывает «семейство протоколов или экземпляр протокола» (цитата из параграфа 3.6 в [RFC1034]). «DNS помечает все данные тегом класса и типа, что позволяет параллельно использовать разные форматы для данных типа адрес.» (цитата из параграфа 2.2 в [RFC1034]). На практике почти в каждом запросе используется класс IN (Internet). Имеется несколько запросов для класса CH (Chaos), но они обычно служат для получения сведений о самом сервере, а не для получения другого типа адреса.

QNAME

Наиболее распространённым является грубое определение QNAME как поля в разделе запроса Question. «Стандартный запрос задает искомое доменное имя (QNAME), тип (QTYPE) и класс (QCLASS) запроса, а также запрашивает соответствующие записи RR.» (цитата из параграфа 3.7.1 в [RFC1034]). Строго говоря, определение взято из параграфа 4.1.2 в [RFC1035], где QNAME определяется применительно к разделу Question. Это определение, по-видимому, применяется согласованно, поскольку при обсуждении реверсных запросов в параграфе 6.4.1 [RFC1035] указывается «имя владельца RR запроса и значение TTL», так как при реверсных запросах заполняется поле Answer, а раздел Question остаётся пустым (реверсные запросы отменены в [RFC3425], поэтому в данном документе нет соответствующих определений).
В [RFC2308] имеется альтернативное определение, помещающее QNAME в ответ (или последовательность ответов) вместо запроса. QNAME определяется как «Имя в запросном разделе (query section) ответа или место, где оно преобразуется в CNAME или цепочку CNAME, поле данных последней записи CNAME. Последней CNAME в данном случае считается запись, содержащая значение, которое не преобразуется в другую запись CNAME». В этом определении есть некая внутренняя логика, обусловленная определением и способом подстановки CNAME. Если сервер имён не находит набора RRset, соответствующего запросу, но находит то же имя в неком классе с записью CNAME, он «включает запись CNAME в отклик и повторяет запрос для доменного имени, заданного в поле данных записи CNAME» (цитата из параграфа 3.6.2 в [RFC1034]). Это явно указано в алгоритме распознавания, описанном в параграфе 4.3.2 [RFC1034]: «QNAME меняется на каноническое имя в CNAME RR и выполняется возврат к п 1». Поскольку запись CNAME явно говорит, что имя владельца является каноническим именем того, что содержится в RDATA, можно рассматривать новое имя (имя, которое было в RDATA записи CNAME RR) как QNAME. Однако это создаёт путаницу, поскольку отклик на запрос, который ведёт к обработке CNAME, содержит в отражённом разделе Question два значения QNAME — имя в исходном запросе и содержимое поля данных в последнем CNAME. Путаница возникает из-за итерационного (рекурсивного) режима распознавания, возвращающего в результате отклик, который не обязательно имеет то же имя владельца, что и QNAME в исходном запросе.
Для предотвращения возможной путаницы полезно различать три указанных ниже значения.

QNAME (исходное)

Имя, фактически переданное в разделе Question исходного запроса, которое всегда отражается (echo) в разделе Question (финального) отклика, когда установлено значение 1 для бита QR.

QNAME (эффективное)

Фактически распознанное имя, которое является исходно запрошенным или полученным в цепочке откликов CNAME.

QNAME (финальное)

Фактически распознанное имя, которое является исходно запрошенным или последним именем в цепочке откликов CNAME.
Поскольку определение в [RFC2308] относится фактически не к тому понятию, которое было принято в [RFC1034], лучше было бы использовать в [RFC2308] другое имя для этого понятия. В современной практике QNAME почти всегда означает то, что выше отмечено как QNAME (исходное).

Referrals — рекомендации (перенаправление)

Тип отклика, в котором сервер, сообщая о своей полной неполномочности для отклика, указывает запрашивающему распознавателю другое место для отправки запроса. Рекомендации могут быть частичными.
Рекомендации возникают, когда сервер не выполняет рекурсивное обслуживание при ответе на запрос. Это показано на этапе 3(b) алгоритма [RFC1034] (параграф 4.3.2).
Имеется два типа перенаправления. Первый указывает перенаправление вниз (downward referral, иногда описывается как отклик делегирования — delegation response), когда сервер полномочен для некоторой части QNAME. Раздел Authority в RDATA набора RRset содержит серверы имён, указанные на срезе зоны referred-to. При обычной работе DNS этот тип откликов нужен для поиска имён ниже передачи полномочий. Использование термина referral без дополнительных атрибутов означает именно этот вариант и многие считают его единственным допустимым типом перенаправления в DNS. Второй вариант перенаправляет вверх (upward referral, иногда описывается как перенаправление к корню — root referral), когда у сервера совсем нет полномочий для QNAME. В этом случае зоной referred-to в разделе Authority обычно является корневая зона (.). При нормальной работе DNS этот тип откликов не требуется для распознавания и корректного ответа на любой запрос. От серверов не требуется передавать перенаправление вверх и некоторые считают такое перенаправление признаком ошибочной настройки или ошибки. Для перенаправления вверх всегда требуется то или иное уточнение (например, upward или root) и оно никогда не указывается просто словом referral.
Отклик, содержащий лишь рекомендации, имеет пустой раздел Answer и содержит NS RRset для зоны referred-to в разделе Authority. Отклик может содержать RR, указывающие адреса, в разделе Additional. Бит AA сброшен.
В случае, когда запрос соответствует псевдониму (alias) и сервер не полномочен для цели этого псевдонима, но имеет полномочия для некого имени выше этой цели, алгоритм распознавания будет создавать отклик, который содержит полномочный ответ для псевдонима и перенаправление. Такой отклик с частичным ответом и перенаправлением содержит данные в разделе Answer, а в разделе Authority содержится NS RRset для зоны referred-to. Отклик может содержать RR, указывающие адреса, в разделе Additional. Бит AA установлен, поскольку первое имя в разделе Answer соответствует QNAME и сервер полномочен для ответа (см. параграф 4.1.1 в [RFC1035]).

5. Записи о ресурсах

RR

Сокращение для записи о ресурсах (resource record), см. параграф 3.6 в [RFC1034].

RRset

Набор записей о ресурсах «с совпадающими метками, типом и классом, но различными данными» (согласно разделу 5 в [RFC2181]). Иногда применяется обозначение RRSet. «Одна метка» в этом определении означает «одно имя владельца». Кроме того, в [RFC2181] сказано: «все значения TTL для записей RR в наборе RRSet должны быть одинаковы». Отметим, что записи RRSIG не соответствуют этому определению. В [RFC4035] сказано:
Процесс создания RRSIG RR для данного набора RRset описан в [RFC4034]. Набор RRset может включать множество связанных с ним записей RRSIG. Отметим, что по причине тесной связи записей RRSIG RR с наборами RRset, чьи сигнатуры эти записи содержат, записи RRSIG RR, в отличие от других типов DNS RR, не формируют наборов RRset. В частности, значения TTL для записей RRSIG RR с общим именем владельца, не следуют правилам для RRset, описанным в [RFC2181].

Master file — первичный файл

«Первичные файлы являются текстовыми и содержат записи RR в виде текста. Поскольку содержимое зоны может быть выражено в форме списка RR, первичные файлы используются в основном для определения зон, хотя их можно применять и для списков содержимого кэша» (цитата из раздела 5 в [RFC1035]). Первичные файлы иногда называют файлами зоны (zone file).

Presentation format — формат представления

Текстовый формат, используемый в первичных файлах. Этот формат показан, но не определён формально в [RFC1034] и [RFC1035]. Термин presentation format впервые использован в [RFC4034].

EDNS

Механизмы расширения для DNS, определённые в [RFC6891]. Иногда применяются обозначения EDNS0 и EDNS(0) для указания номера версии. EDNS позволяет клиентам и серверам DNS задавать размер сообщений больше заданных исходно 512 октетов, расширять пространство кодов откликов и передавать дополнительные опции, влияющие на обработку запросов DNS.

OPT

Псевдо-RR (иногда называется meta-RR), используемая для управляющей информации, относящейся к последовательности запросов и откликов конкретной транзакции (перефразированное определение из параграфа 6.1.1 в [RFC6891]). Применяется в EDNS.

Owner — владелец

«Имя домена, где найдена RR» (цитата из параграфа 3.6 в [RFC1034]). Зачастую применяется термин owner name.

SOA field names — имена полей SOA

В документах DNS, включая приведённые здесь определения, поля в RDATA записи о ресурсах SOA указываются по именам. SOA является сокращением от начала зоны полномочий (start of a zone of authority). Эти поля определены в параграфе 3.3.13 [RFC1035]. Имена полей (в порядке их указания в SOA RDATA) — MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, MINIMUM. Отметим, что назначение поля MINIMUM обновлено в разделе 4 [RFC2308] и новое определение говорит, что поле MINIMUM — это только «TTL для негативных откликов». В этом документе как правило используются имена полей, а не описывающие поля термины.

TTL

Максимальный срок действия (time to live) записи о ресурсе. «Поле TTL представляет собой целое число без знака с минимальным значением 0 и максимальным 2147483647 (т. е., 231 — 1). При передаче это значение следует помещать в младшие биты (31) 32-битового поля TTL, устанавливая для старшего бита (знак) нулевое значение.» (цитата из раздела 8 в [RFC2181]). Отметим, что в [RFC1035] ошибочно указано, что это целое число со знаком. Ошибка исправлена в [RFC2181].
TTL «задаёт временной интервал, в течение которого запись может кэшироваться прежде, чем снова возникнет необходимость обращения к источнику данных» (цитата из параграфа 3.2.1 в [RFC1035]). В параграфе 4.1.3 [RFC1035] сказано: «временной интервал (в секундах), в течение которого запись может кэшироваться до ее отбрасывания». Несмотря на определение для записи о ресурсе, значение TTL в каждой записи RRset должно быть одинаковым ([RFC2181], параграф 5.2).
Причина того, что TTL указывает максимальный срок действия, заключается в том, что оператор может сократить срок действия в оперативных целях, например при наличии запрета TTL больше определённого значения. Известно, что некоторые серверы игнорируют TTL в некоторых RRset (например, когда для полномочных данных установлен очень короткий срок действия), хотя это противоречит рекомендациям [RFC1035]. RRset может удаляться из кэша до завершения интервала TTL, при этом значение TTL становится неизвестным, поскольку RRset, с которым оно связано, больше не существует.
Существует также концепция принятого по умолчанию срока действия (default TTL) для зоны, который может быть параметром конфигурации программы сервера. Часто это выражается принятым по умолчанию значением для всего сервера и для зоны с помощью директивы $TTL в файле зоны. Директива $TTL была добавлена в формат первичного файла документом [RFC2308].

Class independent — независимый от класса

Тип записи о ресурсе, синтаксис и сементика которого одинаковы для каждого класса DNS. Тип записи о ресурсе, не являющийся независимым от класса, имеет разную трактовку в зависимости от класса DNS, к которому относится запись, если трактовка не определена для некоторых классов. Большинство типов записей о ресурсах определено для класса 1 (IN, Internet), но многие записи не определены для других классов.

Address records — адресные записи

Записи типа A или AAAA. В [RFC2181] они неформально определены как «(A, AAAA и т. п.)». Отметим, что в будущем могут быть определены новые типы адресных записей.

6. Серверы и клиенты DNS

В этом разделе даны определения терминов, используемых для систем, являющихся клиентами и/или серверами DNS. В прошлых RFC серверы DNS иногда назывались серверами имён (name server, nameserver) или просто серверами. Формального определения сервера DNS не существует, но в RFC обычно предполагается, что это сервер Internet, прослушивающий запросы и отправляющий отклики с использованием протокола DNS, заданного в [RFC1035] и его преемниках.

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

Термины, относящиеся к системе глобальных корневых серверов DNS, приведены в [RSSAC026], где определены такие термины как root server (корневой сервер), root server operator (оператор корневого сервера), а также термины, связанные со способами обслуживания корневой зоны глобальной системы DNS.

Resolver — распознаватель

«Программа, извлекающая из серверов имен информацию в ответ на запрос клиента» (цитата из параграфа 2.4 в [RFC1034]). Распознаватель выполняет запросы по имени, типу и классу, получая отклики. Логическая функция называется распознаванием (resolution). На практике термин обычно обозначает тот или иной тип распознавателя (некоторые типы определены ниже) и трактовка термина зависит от понимания контекста.
Связанным термином является resolve, для которого нет формального определения в [RFC1034] и [RFC1035]. Вмененное определение может иметь вид: «задание вопроса, состоящего из доменного имени, класса и типа и получение какого-то ответа». Вмененным определением для распознавания (resolution) может быть: «ответ, полученный от распознавания».

Stub resolver — распознаватель-заглушка

Распознаватель, не способный самостоятельно выполнить распознавание. Заглушки обычно зависят от рекурсивного распознавателя, который принимает на себя функцию фактического распознавания. Распознаватели-заглушки обсуждаются в параграфе 5.3.1 [RFC1034], но не определены там формально. Полное определение дано в параграфе 6.1.3.1 [RFC1123].

Iterative mode — итерационный режим

Режим распознавания, при котором получающий запросы сервер DNS отвечает ссылкой (рекомендацией — referral) на другой сервер. В параграфе 2.3 [RFC1034] это описано так: «сервер указывает клиенту другой сервер, который способен ответить на запрос клиента». Распознаватель, работающий в итерационном режиме иногда называют итерационным распознавателем (iterative resolver). См. также определение термина iterative resolution ниже.

Recursive mode — рекурсивный режим

Режим распознавания, при котором получающий запросы сервер DNS отвечает на них с использованием локального кэша или передаёт запросы другим серверам для получения окончательных ответов на них. В параграфе 2.3 [RFC1034] это описано так: «когда первый сервер транслирует (передаёт) запрос клиента другому серверу». В параграфе 4.3.1 [RFC1034] сказано: «в этом [рекурсивном] режиме сервер имён выполняет функции распознавателя имён и всегда возвращает ответ или сообщение об ошибке, но не ссылку на другой сервер». В этом же параграфе сказано:
Рекурсивный режим возникает в тех случаях, когда запрос с установленным флагом RD поступает на сервер, который желает обеспечивать рекурсивный сервис; клиент может убедиться в использовании рекурсивного режима, проверяя наличие в отклике обоих флагов RA и RD.
Работающий в рекурсивном режиме сервер можно рассматривать как комбинацию сервера имён (отвечает на запросы) и распознавателя (выполняет функцию распознавания). Работающие в таком режиме системы обычно называют рекурсивными серверами (recursive server), а иногда — рекурсивными распознавателями (recursive resolver). Эти термины могут применяться как взаимозаменяемые. На практике нет возможности узнать заранее, будет ли запрашиваемый сервер выполнять рекурсию.

Recursive resolver — рекурсивный распознаватель

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

Recursive query — рекурсивный запрос

Запрос с установленным (1) битом желательности рекурсии (Recursion Desired или RD) в заголовке (см. параграф 4.1.1 в [RFC1035]). Если рекурсивный сервис доступен и в запросе установлен бит RD, сервер использует свой распознаватель для ответа на запрос (см. параграф 4.3.2 в [RFC1034].)

Non-recursive query — нерекурсивный запрос

Запрос со сброшенным (0) битом RD в заголовке. Сервер может отвечать на такой запрос только локальными сведениями или возвращать ссылку на другой сервер, который «ближе» к ответу (см. параграф 4.3.1 в [RFC1034]).

Iterative resolution — итерационное распознавание

Сервер имён может получить запрос, на который способен ответить только другой сервер. Для решения этой проблемы имеется два подхода — рекурсивный, когда первый сервер выполняет от имени клиента запрос к другому серверу, и итерационный, когда сервер указывает клиенту другой сервер для передачи запроса тому (см. параграф 2.3 в [RFC1034]). При итерационном распознавании клиент повторяет нерекурсивные запросы и следует за перенаправлениями и/или псевдонимами (alias). Алгоритм итерационного распознавания описан в параграфе 5.3.3 [RFC1034].

Full resolver — полный распознаватель

Этот термин применяется в [RFC1035], но не определён там. В RFC 1123 определён полнофункциональный распознаватель (full-service resolver), который может совпадать или не совпадать с тем, что подразумевалось по full resolver в [RFC1035]. Это термин не определён должным образом ни в одном RFC и нет единого мнения о его трактовке. Использовать термин без надлежащего контекста не рекомендуется.

Full-service resolver

В параграфе 6.1.3.1 [RFC1123] этот термин определён как распознаватель, работающий в рекурсивном режиме с кэшированием (и соответствующий другим требованиям).

Priming — подготовка

«Поиск списка корневых серверов по конфигурации, где указаны все или некоторые предполагаемые адреса IP корневых серверов» (цитата из раздела 2 в [RFC8109]). Для работы в рекурсивном режиме распознавателю нужно знать адрес хотя бы одного корневого сервера. Подготовка зачастую выполняется по конфигурации, содержащей список полномочных серверов корневой зоны.

Root hints — подсказки корневых серверов

«Операторам рекурсивных распознавателей DNS обычно нужно настроить «файл подсказки корневых серверов» (root hints file). Этот файл содержит имена и адреса IP полномочных серверов имён корневой зоны, чтобы программы могли запускать процесс распознавания DNS. Во многих программах этот список является встроенным» (цитата из [IANA_RootFiles]). Файл подсказок часто используется при подготовке.

Negative caching — негативное кэширование

«Хранение информации о том, что чего-либо не существует, ответ не может быть получен или его не дают» (цитата из раздела 1 в [RFC2308]).

Authoritative server — полномочный сервер

«Сервер, знающий содержимое зоны DNS из локальных сведений и способный, тем самым, отвечать на запросы для зоны без необходимости обращения к другим серверам» (цитата из раздела 2 в [RFC2182]). Полномочный сервер указан в записи NS (name server) для зоны. Это система, отвечающая на запросы DNS сведениями о зонах, для которых она была настроена на отклик, с установленным (1) в заголовке отклика флагом AA. Это сервер, имеющий полномочия для одной или нескольких зон DNS. Отметим, что полномочный сервер может отвечать на запросы без передачи ему полномочий родительской зоны. Полномочные серверы также предоставляют рекомендации (referral), обычно для дочерних зон, получивших полномочия от них. В этих рекомендациях бит AA сброшен (0) и содержатся данные перенаправления в разделе Authority, а при необходимости и в разделах Additional.

Authoritative-only server — сервер, выполняющий только функции полномочного (без рекурсии)

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

Zone transfer — перенос зоны

Действие, при котором клиент запрашивает копию зоны, а полномочный сервер передаёт требуемые сведения (описание зон приведено в разделе 7). Имеется два базовых стандартных способа переноса зон — AXFR (Authoritative Transfer) для копирования всей зоны [RFC5936] и IXFR («Incremental Transfer») для копирования лишь изменившихся частей зоны [RFC1995]. Во многих системах применяются нестандартные методы переноса зон, выходящие за рамки протокола DNS.

Slave server — ведомый сервер

См. Secondary server.

Secondary server — вторичный сервер

«Полномочный сервер, который использует перенос зоны для ее получения» (цитата из параграфа 2.1 в [RFC1996]). Вторичные серверы обсуждаются также в [RFC1034], а в [RFC2182] они описаны более подробно. Хотя в ранних DNS RFC, таких как [RFC1996], использовался термин «ведомый» (slave), сейчас принято называть такие серверы вторичными (secondary).

Master server — ведущий сервер

См. Primary server.

Primary server — первичный сервер

«Любой полномочный сервер, настроенный на то, чтобы играть роль источника при переносе зоны для одного или нескольких [вторичных] серверов» (цитата из параграфа 2.1 в [RFC1996]). Более конкретно в [RFC2136] указано, что это: «полномочный сервер, настроенный как источник данных AXFR или IXFR для одного или нескольких [вторичных] серверов». Первичные серверы обсуждаются также в [RFC1034]. Хотя в ранних DNS RFC, таких как [RFC1996], использовался термин «ведущий» (master), сейчас принято называть такие серверы первичными (primary).

Primary master — первичный ведущий

«Первичный ведущий сервер зоны указывается в поле SOA MNAME, а также может указываться в NS RR» (цитата из параграфа 2.1 в [RFC1996]). В [RFC2136] термин primary master определён как: «Ведущий сервер в корне графа зависимостей AXFR/IXFR. Первичный ведущий сервер зоны указывается в поле SOA MNAME, а также может указываться в NS RR. По определению имеется лишь один первичный ведущий сервер на зону».
Идея первичного ведущего сервера используется лишь в [RFC1996] и [RFC2136]. В современной интерпретации primary master — это сервер, который является полномочным для зоны и получает обновления зоны из конфигурации (например, первичного файла) или транзакций UPDATE.

Stealth server — скрытый сервер

«Похож на ведомый сервер, но не указывается в NS RR для данной зоны» (цитата из параграфа 2.1 в [RFC1996]).

Hidden master — скрытый ведущий

Скрытый сервер, который является первичным для переноса зон. «При такой схеме ведущий сервер имён, обрабатывающий обновления, недоступен для хостов общего назначения в Internet, он не указывается в NS RRset» (цитата из параграфа 3.4.3 в [RFC6781]). В [RFC4641] сказано, что имя скрытого ведущего «присутствует в поле MNAME записей SOA RR», однако это имя вообще не присутствует в некоторых серверах глобальной системы DNS. Скрытый ведущий может быть также вторичным сервером для самой зоны.

Forwarding — пересылка

Процесс передачи сервером запроса DNS с установленным (1) битом RD другому серверу для распознавания. Пересылка является функцией распознавателя DNS и отличается от простой ретрансляции запросов вслепую.
В [RFC5625] не дано конкретного определения пересылки, но подробно описаны функции которые должна поддерживать система, выполняющая пересылку. Системы с пересылкой иногда называют DNS-прокси, но этот термин ещё не определён (даже в [RFC5625]).

Forwarder — пересылающий сервер

В разделе 1 [RFC2308] пересылающий сервер описан как «Сервер имён, используемый для распознавания (resolve) запросов взамен прямого использования цепочки полномочных серверов имён». Кроме того, в [RFC2308] сказано: «Обычно пересылающий сервер имеет более качественный доступ в Internet или поддерживает кэш большего размера, совместно используемый множеством распознавателей имён». Из этого определения следует, что пересылающие серверы обычно обращаются в запросами лишь к полномочным серверам. Однако в настоящее время пересылающие серверы часто занимают промежуточное место между распознавателями-заглушками (stub) и рекурсивными серверами. В [RFC2308] не сказано, является ли пересылающий сервер только итерационным или полнофункциональным распознавателем.

Policy-implementing resolver — реализующий правила распознаватель

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

Open resolver — открытый распознаватель

Полнофункциональный распознаватель, воспринимающий и обрабатывающий запросы от любых (или почтчи любых) клиентов. Их иногда называют общедоступными (public), хотя термин public resolver чаще применяется к распознавателям, которые предусмотрены как общедоступные, в отличие от распознавателей, которые открыты из-за ошибок в настройке. Открытые распознаватели обсуждаются в [RFC5358].

Split DNS — расщепление DNS

Термины split DNS и split-horizon DNS уже давно применяются в сообществе DNS без формального определения. Обычно они относятся к случаям, когда серверы DNS, полномочные для определённого набора доменов, дают разные ответы для этих доменов в зависимости от источника запроса. Результатом этого является то, что доменное имя, которое условно является уникальным в глобальном масштабе, имеет разный смысл для разных пользователей сети. Иногда это может быть результатом настройки представлений (view), описанных ниже.
В параграфе 3.8 [RFC2775] приведено связанное определение, которое слишком специфично, чтобы быть полезным в общем случае.

View — представление

Конфигурация сервера DNS, позволяющая ему предоставлять разные отклики в зависимости от атрибутов запроса, например для расщепления DNS. Обычно представления различаются по IP-адресу источника запроса, но могут различаться и по IP-адресу назначения, типу запроса (например, AXFR), его рекурсивности и т. п. Представления часто применяются для предоставления во «внутреннюю» защищённую сеть большего числа имён, чем во «внешнюю» незащищённую. Представления не являются стандартизованной частью DNS, но реализованы во многих серверных программах.

Passive DNS — пассивная система DNS

Механизм сбора данных DNS за счёт сохранения откликов DNS от серверов имён. Некоторые из таких систем собирают также связанные с откликами запросы DNS, хотя при этом возникают некоторые проблемы приватности. Базы данных пассивных систем DNS могут использоваться для ответов на исторические запросы о зонах DNS, например, о значениях, присутствовавших в прошлом, или времени появления имени. Базы данных пассивных DNS позволяют искать хранящиеся записи по ключам, отличающимся от имени и типа, например, «найти все имена, в которых есть запись A с определённым значением».

Anycast

«Технология, позволяющая сделать определённый адрес службы (Service Address) доступным во множестве дискретных, автономных пунктов, чтобы дейтаграмма, отправленная по anycast-адресу, маршрутизировалась в одно из доступных мест» (цитата из раздела 2 в [RFC4786]). В [RFC4786] приведено более подробное объяснение для Anycast и других терминов, связанный с таким использованием.

Instance — экземпляр

«При использовании anycast-маршрутизации, позволяющей нескольким серверам иметь один адрес IP, каждый из этих серверов принято называть экземпляром». Далее в [RSSAC026] сказано: «Экземпляр сервера, например, корневого, часто называют Anycast-экземпляром».

Privacy-enabling DNS server — сервер DNS с поддержкой приватности

«Сервер DNS, реализующий DNS на основе TLS [RFC7858], который может также поддерживать DNS на основе DTLS [RFC8094]» (цитата из раздела 2 в [RFC8310]). Поддержка приватности может обеспечиваться и другими типами серверов DNS, такими как DNS-over-HTTPS [RFC8484] и DNS-over-QUIC [RFC9250].

DNS-over-TLS (DoT) — DNS на основе TLS

DNS по протоколу TLS, как определено в [RFC7858] и преемниках.

DNS-over-HTTPS (DoH) — DNS на основе HTTPS

DNS по протоколу HTTPS, как определено в DNS [RFC8484] и преемниках.

DNS-over-QUIC (DoQ) — DNS на основе QUIC

DNS по протоколу QUIC, как определено в [RFC9250] и преемниках. В [RFC9250] DoQ определён как транспорт общего назначения для DNS, который может применяться между распознавателями-заглушками (stub) и рекурсивными серверами, между рекурсивными и полномочными серверами, а также для переноса зон.

Classic DNS — классический протокол DNS

DNS по протоколу UDP или TCP, как определено в [RFC1035] и преемниках. Classic DNS применяется при взаимодействии DNS между распознавателями-заглушками и рекурсивными распознавателями, а также между рекурсивными распознавателями и полномочными серверами. Протокол иногда называют Do53. Шифрование в классическом DNS не применяется.

Recursive DoT (RdoT) — рекурсивный DNS на основе TLS

RDoT — это транспорт DNS-over-TLS для между распознавателем-заглушкой и рекурсивным распознавателем или парой рекурсивных распознавателей. Этот термин нужен, поскольку предполагается в будущем применение DNS-over-TLS в качестве транспорта между рекурсивными распознавателями и полномочными серверами.

Authoritative DoT (ADoT) — полномочный DoT

Если DNS-over-TLS в будущем станет транспортом между рекурсивными распознавателями и полномочными серверами, ADoT будет обозначать такой транспорт.

XFR-over-TLS (XoT)

Перенос зоны DNS по протоколу TLS, как задано в [RFC9103]. Этот термин применим как для AXFR over TLS (AxoT), так и для IXFR over TLS (IXoT).

7. Зоны

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

Zone — зона

«Полномочная информация организуется в блоки, называемые зонами (ZONE) и эти зоны могут автоматически распространяться серверам имён, которые являются резервными для данных зон» (цитата из параграфа 2.4 в [RFC1034]).

Child — потомок

«Сущность (объект) в записи, которой переданы полномочия для домена от родителя (Parent)» (цитата из параграфа 1.1 в [RFC7344]).

Parent — родитель

«Домен, в котором зарегистрирован потомок (Child)» (цитата из параграфа 1.1 в [RFC7344]). Ранее в [RFC0882] был определён термин parent name server (родительский сервер имён) как «сервер имён, имеющий полномочия для пространства имён, которое будет содержать новый домен» (отметим, что [RFC0882] был отменён [RFC1034] и [RFC1035]). В [RFC819] описаны некоторые взаимоотношения между родителями и потомками.

Origin — начало (источник)

Имеется два вариант использования этого термина.
  1. «Доменное имя, появляющееся наверху зоны (сразу под срезом, отделяющим зону от её родителя)… Имя зоны совпадает с именем домена в источнике зоны» (цитата из раздела 6 в [RFC2181]. В настоящее время термины origin и apex (вершина, см. ниже) часто применяются как взаимозаменяемые.
  2. Доменное имя, в рамках которого данное относительное доменное имя появляется в файлах зоны. Обычно рассматривается в контексте $ORIGIN — элемента управления, определённого в параграфе 5.1 [RFC1035] как часть формата первичного файла. Например, если $ORIGIN имеет значение example.org., строка первичного файла для www фактически является записью для www.example.org..

Apex — вершина

Точка в дереве, где размещается владелец SOA и соответствующего полномочного NS RRset. Эта точка называется также вершиной зоны (zone apex). В [RFC4033] вершина определена как «имя на дочерней стороне среза зоны». Понятие вершины может быть полезно в теоретико-информационном описании структуры дерева, а понятие начала (origin) — как название той же концепции при реализации в файлах зоны. Однако это различие не всегда сохраняется на практике и можно найти примеры использования, противоречащие данному определению. В [RFC1034] используется термин «верхний узел зоны» в качестве синонима вершины, но этот термин не получил широкого распространения. В наши дни первое значение термина origin (см. выше) и термин apex часто используются как взаимозаменяемые.

Zone cut — срез зоны

Точка разграничения зон, где начало одной зоны является потомком другой. «Зоны ограничены «срезами». Каждый срез отделяет «дочернюю» зону (ниже среза) от «родительской» (выше среза)» (цитата из раздела 6 в [RFC2181], хотя это определение достаточно поверхностно). В параграфе 4.2 [RFC1034] вместо термина «срез зоны» используется просто срез (cut).

Delegation — передача полномочий (делегирование)

Процесс, в котором под вершиной данной зоны в пространстве имён создаётся отдельная зона. Передача полномочий происходит при добавлении в родительскую зону NS RRset для начала (origin) дочерней зоны. Делегирование всегда выполняется на срезе зоны. Термин часто является существительным3 — новая зона создаётся актом передачи полномочий.

Authoritative data — полномочные данные

«Все записи RR, связанные со всеми узлами от вершины зоны до узлов ветвей или узлов над срезами на нижнем краю зоны» (цитата из параграфа 4.2.1 в [RFC1034]). Отметим, что это определение может приводить к непреднамеренному включению любых присутствующих в зоне записей NS, которые на деле не являются полномочными, поскольку идентичные NS RR имеются ниже среза зоны. В этом проявляется неоднозначность понятия полномочных данных, поскольку записи NS на родительской стороне полномочно указывают делегирование, хотя сами не являются полномочными.
В разделе 2 [RFC4033] даётся определение Authoritative RRset, которое связано с полномочными данными, но более точно.

Lame delegation — неудачное делегирование

«Неудачное делегирование имеет место, когда серверу имён переданы полномочия предоставлять службу имён для зоны (через записи NS), но тот не обслуживает имена для этой зоны (обычно из-за того, что он не настроен как первичный или вторичный сервер этой зоны). (цитата из параграфа 2.8 в [RFC1912]). Согласно другому определению, неудачное делегирование «… возникает, когда сервер имён указан в записях NS для некого домена, но на деле не является сервером имён для этого домена. Запросы в этом случае передаются серверам, которые ничего [!] не знают об интересующем домена (по меньшей мере не возвращают ожидаемого). Более того, иногда на этих узлах (если они существуют) даже нет серверов имён» (цитата из параграфа 2.3 в [RFC1713]).
Приведённые ранние определения не совпадают с современным использованием термина lame delegation, но единого мнения о том, что считать неудачным делегированием, ент. Термин применяется не только для указания приведённых выше случаев, но и для ряда других ошибок при передаче полномочий, которые ведут к отсутствию откликов или возврату неполномочных откликов:
  • сервер имён с записью NS для зоны не отвечает на запросы DNS;
  • сервер имён с адресом IP, недоступным распознавателю;
  • сервер имён отвечает на запросы для определённого имени ошибкой или без бита полномочий.
Поскольку современное применение термина отличается от исходного определения, его следует считать устаревшим (историческим) и отказываться от него в пользу более чётких терминов.

Glue records — склеивающие записи

«… записи [RR], которые не относятся к полномочным данным зоны и являются RR с адресами серверов имён. Эти RR требуются только в тех случаях, когда имя сервера [имён] находится «ниже» среза и используются только, как часть отклика со ссылкой». Без склеивающих записей «может возникнуть ситуация, когда NS RR скажут, что для получения адреса сервера имён следует обратиться к серверу имён, адрес которого мы хотим узнать» (цитата из параграфа 4.2.1 в [RFC1034]).
В соответствии с более поздним определением склеивающие записи — это «любые записи в файле зоны, которые не являются в полной мере частью данной зоны, включая имена серверов DNS делегированных субзон (записи NS), адресные записи, сопровождающие эти записи NS (A, AAAA и т. п.), а также любые другие «приблудившиеся» данные» (цитата из параграфа 5.4.1 в [RFC2181]). Хотя терми иногда используется сегодня в соответствии с этим расширенным определением, контекст определения в [RFC2181] позволяет предположить, что оно относится лишь к использованию термина в этом документе.
В записях NS имеется три типа отношений между владельцем записи, именем в NS RDATA и началом зоны: отсутствие связи, нахождение в домене (in-domain) и братский домен. Применение этих трёх типов к склеивающим записям описано в [RFC9471].
Отсутствие связи — это отношения, где NS RDATA содержит сервер имён, который не является подчиненным началу зоны и, следовательно, не является частью самой зоны.
Нахождение в домене (in-domain) — это отношения, где NS RDATA содержит сервер имён, чьё имя является подчинённым или (редко) совпадает с именем владельца записей NS. Например, передача полномочий для child.example.com может создавать сервер имён в домене (in-domain) ns.child.example.com.
Братские отношения имеются, когда NS RDATA NS RDATA содержит сервер имён, чьё имя является подчинённым или (редко) совпадает с началом зоны родителя, но не является подчиненным или совпадающим с с именем владельца записей NS. Например, передача полномочий для child.example.com в зоне example.com может создавать сервер имён братского домена ns.another.example.com.
Примеры типов передачи полномочий приведены в таблице 1.

Таблица .

 

Делегирование

Родитель

Имя сервера имён

Тип

com

.

a.gtld-servers.net

sibling domain

net

.

a.gtld-servers.net

in-domain

example.org

org

ns.example.org

in-domain

example.org

org

ns.ietf.org

sibling domain

example.org

org

ns.example.com

unrelated

example.jp

jp

ns.example.jp

in-domain

example.jp

jp

ns.example.ne.jp

sibling domain

example.jp

jp

ns.example.com

unrelated

 

Bailiwick — сфера компетенции

Модификаторы In-bailiwick и Out-of-bailiwick служат для описания отношений между зоной и обслуживающими её серверами имён. Отмечено, что определение термина bailiwick в словаре вызывает больше путаницы, чем приносит пользы. Эти термины следует считать историческими (устаревшими) по своей природе.

Root zone — корневая зона

Зона дерева на основе DNS, вершиной которой является пустая метка. Иногда называется корнем DNS (DNS root).

Empty non-terminals (ENTs) — пустые нетерминальные элементы

«Доменные имена, в которых нет записей о ресурсах, но имеются субдомены» (цитата из параграфа 2.2.2 в [RFC4592]). Типичный пример е примеры в записях SRV — в имени _sip._tcp.example.com, домен _tcp.example.com, вероятно, не имеет RRset, но _sip._tcp.example.com имеет (по меньшей мере) SRV RRset.

Delegation-centric zone — ориентированная на передачу полномочий зона

Зона, состоящая в основном из передачи полномочий дочерним зонам. Это противоположность зоне, которая может включать делегирование дочерним зонам, но включает множество записей о ресурсах самой зоны и/или дочерних зон. Термин применяется в [RFC4956] и [RFC5155], но не определён ни в одном из них.

Occluded name — поглощённое имя

«Добавление точки делегирования через динамическое обновление будет переводить все подчинённые доменные имена в «подвешенное» состояние, когда они остаются частью зоны, но утрачивают доступность для поиска. Добавление записи DNAME даёт такой же эффект. Такие подчинённые имена называют поглощёнными (скрытыми)» (цитата из параграфа 3.5 в [RFC5936]).

Fast flux DNS — быстрая смена

Это «происходит, когда домен [найденный] в DNS использует записи A с несколькими адресами IP, имеющие очень короткий срок действия (Time-to-Live или TTL). Это означает, что домен распознаётся по разным адресам IP в течение короткого интервала времени» (цитата из параграфа 1.1.5 в [RFC6561] с исправлением опечаток). Помимо легитимных применений быструю смену можно использовать для доставки вредоносных программ. Поскольку адреса меняются быстро, сложно проверить все хосты. Следует отметить, что этот метод работает и с записями AAAA, но на момент создания этого документа такое использование редко наблюдалось в Internet.

Reverse DNS, reverse lookup — обратный (реверсный) поиск

«Процесс отображения адреса на имя обычно называется реверсным поиском (reverse lookup), а о зонах IN-ADDR.ARPA и IP6.ARPA говорят как об обратной системе DNS (reverse DNS)» (цитата из раздела 1 в [RFC5855]).

Forward lookup — прямой поиск

«Трансляция имени хоста в адрес» (цитата из раздела 6 в [RFC3493]).

arpa (Address and Routing Parameter Area Domain) — домен arpa

«Домен arpa был создан как часть исходного развёртывания DNS для предоставления механизма перехода от таблиц хостов (Host Table), применяемых в сети ARPANET, а также в качестве домена для реверсного отображения адресов IPv4. В 2000 г. аббревиатура была переименована в Address and Routing Parameter Area (область адресов и параметров маршрутизации) в надежде снизить путаницу с названием сети» (цитата из раздела 2 в [RFC3172]). Домен .arpa является «инфраструктурным», (ролью которого является поддержка операционной инфраструктуры Internet» (цитата из раздела 2 в [RFC3172]). История имени описана в [RFC3172].

Service name — имя службы

«Имена служб являются уникальными ключами реестра Service Name and Transport Protocol Port Number. Это уникальные символьные имена служб, которые могут использоваться для других целей, например, в записях DNS SRV» (цитата из раздела 5 в [RFC6335]).

8. Шаблоны

Wildcard — шаблон

В [RFC1034] термин wildcard (шаблон) определён так, что это оказалось непонятным для внедряющих протокол. Расширенное обсуждение шаблонов, включая более чёткие определения, приведено в [RFC4592]. Особое внимание уделено RR, в которых имя владельца начинается с метки *. «Такие RR называют шаблонами. Шаблонные RR можно представлять, как инструкцию по синтезированию RR» (цитата из параграфа 4.3.3 в [RFC1034])

Asterisk label — метка *

«Первый октет — это обычный тип и размер 1-октетной метки, а второй содержит код ASCII [RFC20] для символа *. Описательным именем для такой метки является «звёздочка» (цитата из параграфа 2.1.1 в [RFC4592]).

Wildcard domain name — шаблонное доменное имя

«Шаблонное имя домена определяется наличием в его начале (левые или младшие символы) метки с двоичным представлением 0000 0001 0010 1010 = 0x01 0x2a (шестнадцатеричное)» (цитата из параграфа 2.1.1 в [RFC4592]). Второй октет этой метки является кодом ASCII для символа *.

Closest encloser — ближайшее включающее [имя]

«Самый длинный предок имени» (цитата из параграфа 1.3 в [RFC5155]). Прежним определением было: «Узел в дереве зоны имеющихся доменных имён, в котором наибольшее число меток соответствует имени в запросе (последовательно вниз от корневой метки). Каждое совпадение является совпадением метки и порядок меток одинаков» (цитата из параграфа 3.3.1 в [RFC4592]).

Closest provable encloser- ближайшее подтверждённое включающее [имя]

«Самый длинный предок имени, наличие которого может быть доказано. Отметим, что это имя отличается от ближайшего включающего имени в зоне Opt-Out» (цитата из параграфа 1.3 в [RFC5155]). Определение opt-out дано в разделе 10.

Next closer name — имя вслед за включающим

«Имя, которое на 1 метку длиннее ближайшего подтверждённого включающего имени (closest provable encloser)» (цитата из параграфа 1.3 в [RFC5155]).

Source of Synthesis — источник синтезирования

«Источник синтеза определяется в контексте процесса запроса как шаблонное доменное имя, непосредственно порождаемое (descending) ближайшим включающим именем (closest encloser), при условии существования такого шаблонного имени. Непосредственно порождаемое означает, что источник источник синтезирования имеет форму <asterisk label>.<closest encloser>» (цитата из параграфа 3.3.1 в [RFC4592]).

9. Модель регистрации

Registry — реестр

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

Registrant — регистрирующий

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

Registrar — регистратор

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

EPP

Расширяемый протокол обеспечения (Extensible Provisioning Protocol или EPP), обычно применяемый для передачи регистрационных сведений между реестром и регистрирующим. Протокол EPP определён в [RFC5730].

WHOIS

Протокол, заданный в [RFC3912] и часто применяемый для запроса к базам данных реестров. Данные WHOIS часто применяются для связывания данных регистрации (таких, как контакты управляющих зоной лиц) с доменными именами. Термин «данные WHOIS» часто служит синонимом базы данных реестра, хотя сама база может обслуживаться другими протоколами, в частности, RDAP. Протокол WHOIS применяется также для работы с данными реестров адресов IP.

RDAP

Протокол доступа к данным регистрации (Registration Data Access Protocol), заданный в [RFC7480], [RFC7481], [RFC7485], [RFC9082], [RFC9083] и [RFC9224]. Протокол и формат данных RDAP предназначены для замены WHOIS.

DNS operator — оператор DNS

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

Public suffix — суффикс общего пользования

«Домен, контролируемый публичным регистратором» (цитата из параграфа 5.3 в [RFC6265]). Общепринятым толкованием этого термина является домен, в котором третьи лица могут регистрировать свои субдомены, а HTTP cookie (см. [RFC6265]) не следует устанавливать. В доменном имени нет сведений, является ли имя публичным суффиксом и определить это можно лишь внешними средствами. Фактически общедоступными суффиксами может быть как домен, так и его субдомены. Одним из ресурсов для нахождения публичных суффиксов является список (Public Suffix List или PSL), поддерживаемых компанией Mozilla <https://publicsuffix.org/>. Например, в момент создания этого документа домен com.au был указан в PSL как общедоступный суффикс (отметим, что впредь это может измениться).
Отметим, что термин public suffix по многим причинам вызывает разногласия в сообществе DNS и в будущем может быть существенно изменён. Одним из примеров сложностей отнесения домена к суффиксам общего пользования является то, что обозначение может меняться по мере изменения правил регистрации в зоне, как в случае домена uk (TLD) в 2014 г.

Subordinate и Superordinate — подчинённый и вышестоящий

Эти термины применяются в [RFC5731] для модели регистрации, но не определены там. Вместо этого они приведены в примерах: «Например, доменное имя example.com является вышестоящим для имени хоста ns1.example.com… Например, имя хоста ns1.example1.com является подчиненным для домена example1.com, но не является таковым для example2.com» (цитата из параграфа 1.1 в [RFC5731]). Эти термины указывают строгие способы обозначения отношений между доменами, когда один является субдоменом другого.

10. Базовые термины DNSSEC

Большинство терминов DNSSEC определено в [RFC4033], [RFC4034], [RFC4035] и [RFC5155]. Здесь выделены термины, вызывающие путаницу в сообществе DNS.

DNSSEC-aware и DNSSEC-unaware — с поддержкой или без поддержки DNSSEC

Эти два термина используются в некоторых RFC, но не определены формально. Однако в разделе 2 [RFC4033] определены многие типы распознавателей и валидаторов, включая «не проверяющий достоверность защищённый оконечный распознаватель» (non-validating security-aware stub resolver), «не проверяющий корректность оконечный распознаватель» (non-validating stub resolver), «защищённый сервер имён» (security-aware name server), «защищённый рекурсивный сервер имён» (security-aware recursive name server), «защищённый распознаватель» (security-aware resolver), «защищённый оконечный распознаватель» (security-aware stub resolver), «обычное <нечто>» (security-oblivious ‘anything’). Отметим, что термин «проверяющий распознаватель» (validating resolver), используемый в связанных с DNSSEC документах также не определён в указанных RFC, но определён ниже.

Signed zone — подписанная зона

«Зона с подписанными наборами RRset, содержащая корректно созданный ключ DNSKEY, подпись RRSIG, записи NSEC и (необязательно) DS» (цитата из раздела 2 в [RFC4033]). В другом контексте отмечалось, что сама зона фактически не подписывается, но все соответствующие RRset в зоне подписываются. Тем не менее, если зона, которую следует подписывать, содержит какие-либо не подписанные (или отклонённые) RRset, эти наборы будут считаться фиктивными, поэтому вся зона должна обслуживаться каким-либо способом.
Следует также отметить, что с момента публикации [RFC6840], записи NSEC больше не требуются для подписанных зон и вместо них подписанная зона может включать записи NSEC3. В [RFC7129] представлен дополнительный справочный комментарий и некоторый контекст для механизмов NSEC и NSEC3, используемых в DNSSEC для предоставления аутентифицированных откликов о несуществовании (denial-of-existence). NSEC и NSEC3 описаны ниже.

Online signing — подписание по запросам

В [RFC4470] определён термин on-line signing (через дефис) как: «генерация и подписывание этих записей по запросу», где «эти» относится к записям NSEC. Текущее определение расширено включением генерации и подписывания по запросам записей RRSIG, NSEC и NSEC3.

Unsigned zone — неподписанная зона

В разделе 2 [RFC4033] указано, что это «зона, не имеющая подписи». В разделе 2 [RFC4035] указано: «Зона, не включающая записи [корректно созданные записи DNSKEY, RRSIG, NSEC и (не обязательно) DS] в соответствии с указанными правилами, является неподписанной». Важно подчеркнуть, что в конце параграфа 5.2 [RFC4035] указана дополнительная ситуация, когда зона считается неподписанной: «Если распознаватель не поддерживает ни одного алгоритма, указанного в DS RRset, он не сможет проверить путь аутентификации к дочерней зоне. В таких случаях распознавателю следует трактовать дочернюю зону, как неподписанную».

NSEC

«Запись NSEC позволяет защищённому распознавателю аутентифицировать негативный отклик в случаях отсутствия имени или типа с использованием того же механизма, который применяется при аутентификации других откликов DNS» (цитата из параграфа 3.2 в [RFC4033]). Короче говоря, запись NSEC предоставляет аутентифицированные сведения о несуществовании.
«Запись NSEC содержит два отдельных элемента — имя следующего владельца (в каноническом порядке для зоны), содержащего полномочные данные, или точка передачи полномочий (делегирования) NS RRset и множество типов RR, присутствующих в имени владельца NSEC RR» (цитата из раздела 4 в [RFC4034]).

NSEC3

Подобно NSEC, запись NSEC3 предоставляет аутентифицированные сведения о несуществовании, однако записи NSEC3 смягчают перечисление зоны и поддерживают Opt-Out. Записи NSEC3 требуют связанных записей о ресурсах NSEC3PARAM. Записи NSEC3 и NSEC3PARAM определены в [RFC5155].
Отметим, что в [RFC6840] сказано, что [RFC5155] «в настоящее время считается частью семейства документов DNS Security, как указано в разделе 10 [RFC4033]». Это означает, что некоторые определения из прежних RFC, где говорится только о записях NSEC, вероятно, следует считать относящимися как к NSEC, так и к NSEC3.

Opt-out

«Флаг Opt-Out указывает, что NSEC3 RR может охватывать неподписанное делегирование» (цитата из параграфа 3.1.2.1 в [RFC5155]). Opt-Out решает проблему высоких затрат на защиту делегирования в незащищённую зону. При использовании Opt-Out имена, являющиеся незащищённым делегированием и пустые нетерминальные элементы, выводимое только из незащищённого делегирования) не требуют записи NSEC3 или соответствующих записей RRSIG. Записи Opt-Out NSEC3 не могут подтверждать или опровергать наличие незащищённого делегирования (взято из параграфа 5.1 в [RFC7129]).

Insecure delegation — незащищённая передача полномочий

«Подписанное имя, содержащее делегирование (NS RRset), но не имеющее DS RRset, что означает передачу полномочий в неподписанную субзону (цитата из раздела 2 в [RFC4956]).

Zone enumeration — перечисление зоны

«Практика выявления полного содержимого зоны с помощью последовательных запросов» (цитата из параграфа 1.3 в [RFC5155]). Иногда применяется термин zone walking (прохождение по зоне). Перечисление зоны отличается от предсказывания содержимого зоны — при предсказывании используется большой словарь возможных меток и передаются последовательные запросы для них или сопоставляет содержимое записей NSEC3 с таким словарём.

Validation — проверка

Проверкой в контексте DNSSEC считается одно из указанных ниже действий.
  • Проверка достоверности подписей DNSSEC.
  • Проверка достоверности откликов DNS, в том числе аутентифицированных сведений о несуществовании.
  • Создание цепочки аутентификации от привязки доверия до отклика DNS или отдельных DNS RRset в нем.
В двух первых определениях рассматривается лишь достоверность отдельных компонентов DNSSEC, таких как RRSIG и доказательства NSEC. Третье определение учитывает всю цепочку проверки подлинности DNSSEC и распознаватель «должен быть настроен так, чтобы он знал хотя бы одну аутентифицированную запись DNSKEY или DS» (цитата из раздела 5 в [RFC4035]).
В разделе 2 [RFC4033] сказано, что «проверяющий достоверность защищённый оконечный распознаватель … выполняет проверку достоверности подписи» и использует привязку доверия «как стартовую точку для создания цепочки аутентификации к подписанному отклику DNS». Таким образом, используются первое и третье определение. Процесс проверки достоверности записей RRSIG описана в параграфе 5.3 [RFC4035].
В [RFC5155] проверка достоверности откликов упоминается в контексте хэшированных аутентифицированных откликов о несуществовании, где применяется второе определение.
Термин аутентификация используется как взаимозаменяемый с проверкой достоверности в смысле третьего определения. В разделе 2 [RFC4033] описана цепочка, связывающая привязку доверия с данными DNS, как цепочка аутентификации (authentication chain). Отклик считается подлинным, если «все RRset в разделах Answer и Authority [проверены] на предмет аутентичности» (цитата из [RFC4035]). Данные DNS и отклики, сочтённые подлинными или достоверными, имеют статус безопасности secure (параграф 4.3 в [RFC4035] и раздел 5 в [RFC4033]). «Последнее слово при анализе аутентификации для ключей и данных DNS остаётся за локальной политикой, которая может расширить или переназначить расширения протокола [DNSSEC]» (цитата из параграфа 3.1 в [RFC4033]).
При использовании термина проверка (verification) он обычно является синонимом проверки достоверности.

Validating resolver — проверяющий распознаватель

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

Key signing key (KSK) — ключ подписания ключей

Ключ DNSSEC, «подписывающий только DNSKEY RRset на вершине зоны» (цитата из параграфа 3.1 в [RFC6781]).

Zone signing key (ZSK) — ключ подписания зоны

«Ключ DNSSEC, который может применяться для подписания всех RRset в зоне, для которых требуется подпись, за исключением DNSKEY RRset на вершине» (цитата из параграфа 3.1 в [RFC6781]). Отметим, что иногда ZSK применяется и для подписания DNSKEY RRset на вершине.

Combined signing key (CSK) — комбинированный ключ подписания

«В случаях, когда различия между KSK и ZSK не проводится, т. е. каждый может играть обе роли, говорят о схеме однотипного подписания (Single-Type Signing Scheme)» (цитата из параграфа 3.1 в [RFC6781]). Иногда применяется термин «комбинированный ключ подписания» (combined signing key или CSK). Применение определённого ключа ZSK, KSK или CSK определяет практика работы, а не протокол.

Secure Entry Point (SEP) — защищённая точка входа

Флаг в DNSKEY RDATA, который «можно использовать для различения ключей, предназначенных служить защищёнными точками входа в зону при создании цепочек доверия, т. е. на них (должны) будут указывать родительские DS RR или они будут заданы как привязки доверия. … Поэтому предполагается устанавливать флаг SEP для ключей, применяемых как KSK, но не для ключей, служащих ZSK, хотя в тех случаях, когда эти ключи не различаются (Single-Type Signing Scheme), предлагается устанавливать флаг SEP для всех ключей» (цитата из параграфа 3.2.3 в [RFC6781]). Отметим, что флаг SEP служит лишь подсказкой и его наличие или отсутствие не может применяться для дисквалификации применения DNSKEY RR в качестве KSK или ZSK при проверке достоверности.
Исходное определение SEP дано в [RFC3757] и чётко указывает, что SEP является ключом, а не просто битом в ключе. В аннотации к [RFC3757] сказано: «С помощью записи DS RR (Delegation Signer) была введена концепция открытого ключа, служащего защищённой точкой входа (secure entry point или SEP). В процессе обмена открытыми ключами с родителем возникает необходимость отличать ключи SEP от других открытых ключей в наборе записей DNSKEY (Domain Name System KEY). Бит флага в DNSKEY RR определён для индикации того, что DNSKEY применяется как SEP». Определение SEP как ключа было отменено в [RFC4034], а определение [RFC6781] согласуется с определением [RFC4034].

Trust anchor — привязка доверия

«Сконфигурированная запись DNSKEY RR или хэш DS RR записи DNSKEY RR. Проверяющий защищённый оконечный распознаватель использует этот открытый ключ или хэш а качестве стартовой точки для построения аутентификационной цепочки отклика DNS. В общем случае проверяющий распознаватель будет получать начальные значения таких привязок с помощью того или иного защищённого или доверенного способа, не входящего в протокол DNS.» (цитата из раздела 2 в [RFC4033].

DNSSEC Policy (DP) — правила (политика) DNSSEC

Заявление, которое «устанавливает требования и стандарты безопасности для реализации в зоне, подписанной DNSSEC» (цитата из раздела 2 в [RFC6841]).

DNSSEC Practice Statement (DPS) — заявление о практике DNSSEC

«Раскрывающий практику документ, который может поддерживать и дополнять правила DNSSEC (при наличии) и в котором говорится, как в управлении данной зоной реализованы процедуры и элементы управления на высоком уровне» (цитата из раздела 2 в [RFC6841]).

Hardware security module (HSM) — аппаратный модуль защиты

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

Signing software — программы для подписания

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

11. Состояния DNSSEC

Проверяющий достоверность распознаватель может определить, что отклик имеет одно из четырёх состояний — secure, insecure, bogus, indeterminate. Эти состояния определены в [RFC4033] и [RFC4035], хотя определения в этих документах несколько различаются. Здесь не предпринимается попытки согласовать эти определения и не высказывается мнения о необходимости такого согласования.

В разделе 5 [RFC4033] сказано:

Проверяющий распознаватель может определять 4 перечисленных ниже состояния.

Secure — защищённое

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

Insecure — незащищённое

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

Bogus — подделка

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

Indeterminate — неопределённое

Нет доверенной привязки, которая показывает, что определённая часть дерева защищена. Это состояние принимается по умолчанию.

В параграфе 4.3 [RFC4035] сказано:

Защищённый распознаватель должен быть способен должен различать перечисленные ниже случаи.

Защищённый (Secure)

RRset, для которого распознаватель способен построить цепочку подписанных записей DNSKEY и DS RR от доверенной защитной привязки (security anchor) до RRset. В этом случае набору RRset следует быть подписанным и для него выполняется проверка подписи, описанная выше.

Незащищённый (Insecure)

RRset, для которого распознаватель знает об отсутствии цепочки подписанных записей DNSKEY и DS RR от любой доверенной стартовой точки до RRset. Это может наблюдаться в тех случаях, когда целевой набор RRset находится в неподписанной зоне или потомке такой зоны. В этом случае набор RRset может быть как подписанным, так и неподписанным и распознаватель не сможет проверить подпись.

Подделка (Bogus)

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

Неопределённость (Indeterminate)

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

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

Приведённые здесь определения не меняют соображений безопасности для глобальных и приватных систем DNS.

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

Ссылки на RFC 8499 в реестрах IANA заменены ссылками на этот документ.

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

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

[IANA_RootFiles] IANA, «Root Files», <https://www.iana.org/domains/root/files>.

[RFC0882] Mockapetris, P., «Domain names: Concepts and facilities», RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>.

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

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

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

[RFC1912] Barr, D., «Common DNS Operational and Configuration Errors», RFC 1912, DOI 10.17487/RFC1912, February 1996, <https://www.rfc-editor.org/info/rfc1912>.

[RFC1996] Vixie, P., «A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)», RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.

[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, «Selection and Operation of Secondary DNS Servers», BCP 16, RFC 2182, DOI 10.17487/RFC2182, July 1997, <https://www.rfc-editor.org/info/rfc2182>.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.

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

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/info/rfc4592>.

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, «DNS Security (DNSSEC) Hashed Authenticated Denial of Existence», RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.

[RFC5358] Damas, J. and F. Neves, «Preventing Use of Recursive Nameservers in Reflector Attacks», BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.

[RFC5730] Hollenbeck, S., «Extensible Provisioning Protocol (EPP)», STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.

[RFC5731] Hollenbeck, S., «Extensible Provisioning Protocol (EPP) Domain Name Mapping», STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.

[RFC5855] Abley, J. and T. Manderson, «Nameservers for IPv4 and IPv6 Reverse Zones», BCP 155, RFC 5855, DOI 10.17487/RFC5855, May 2010, <https://www.rfc-editor.org/info/rfc5855>.

[RFC5936] Lewis, E. and A. Hoenes, Ed., «DNS Zone Transfer Protocol (AXFR)», RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>.

[RFC6561] Livingood, J., Mody, N., and M. O’Reirdan, «Recommendations for the Remediation of Bots in ISP Networks», RFC 6561, DOI 10.17487/RFC6561, March 2012, <https://www.rfc-editor.org/info/rfc6561>.

[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, «DNSSEC Operational Practices, Version 2», RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.

[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., «Clarifications and Implementation Notes for DNS Security (DNSSEC)», RFC 6840, DOI 10.17487/RFC6840, February 2013, <https://www.rfc-editor.org/info/rfc6840>.

[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, «A Framework for DNSSEC Policies and DNSSEC Practice Statements», RFC 6841, DOI 10.17487/RFC6841, January 2013, <https://www.rfc-editor.org/info/rfc6841>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, «Automating DNSSEC Delegation Trust Maintenance», RFC 7344, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-editor.org/info/rfc7344>.

[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, «DNS Terminology», RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, «Usage Profiles for DNS over TLS and DNS over DTLS», RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, «DNS Terminology», BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

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

[RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, «DNS Glue Requirements in Referral Responses», RFC 9471, DOI 10.17487/RFC9471, September 2023, <https://www.rfc-editor.org/info/rfc9471>.

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

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

[RFC20] Cerf, V., «ASCII format for network interchange», STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[RFC819] Su, Z. and J. Postel, «The Domain Naming Convention for Internet User Applications», RFC 819, DOI 10.17487/RFC0819, August 1982, <https://www.rfc-editor.org/info/rfc819>.

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

[RFC1713] Romao, A., «Tools for DNS debugging», FYI 27, RFC 1713, DOI 10.17487/RFC1713, November 1994, <https://www.rfc-editor.org/info/rfc1713>.

[RFC1995] Ohta, M., «Incremental Zone Transfer in DNS», RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.

[RFC2775] Carpenter, B., «Internet Transparency», RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>.

[RFC3172] Huston, G., Ed., «Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain («arpa»)», BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/info/rfc3172>.

[RFC3425] Lawrence, D., «Obsoleting IQUERY», RFC 3425, DOI 10.17487/RFC3425, November 2002, <https://www.rfc-editor.org/info/rfc3425>.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, «Basic Socket Interface Extensions for IPv6», RFC 3493, DOI 10.17487/RFC3493, February 2003, <https://www.rfc-editor.org/info/rfc3493>.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, «Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag», RFC 3757, DOI 10.17487/RFC3757, April 2004, <https://www.rfc-editor.org/info/rfc3757>.

[RFC3912] Daigle, L., «WHOIS Protocol Specification», RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.

[RFC4470] Weiler, S. and J. Ihren, «Minimally Covering NSEC Records and DNSSEC On-line Signing», RFC 4470, DOI 10.17487/RFC4470, April 2006, <https://www.rfc-editor.org/info/rfc4470>.

[RFC4641] Kolkman, O. and R. Gieben, «DNSSEC Operational Practices», RFC 4641, DOI 10.17487/RFC4641, September 2006, <https://www.rfc-editor.org/info/rfc4641>.

[RFC4697] Larson, M. and P. Barber, «Observed DNS Resolution Misbehavior», BCP 123, RFC 4697, DOI 10.17487/RFC4697, October 2006, <https://www.rfc-editor.org/info/rfc4697>.

[RFC4786] Abley, J. and K. Lindqvist, «Operation of Anycast Services», BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.

[RFC4956] Arends, R., Kosters, M., and D. Blacka, «DNS Security (DNSSEC) Opt-In», RFC 4956, DOI 10.17487/RFC4956, July 2007, <https://www.rfc-editor.org/info/rfc4956>.

[RFC5625] Bellis, R., «DNS Proxy Implementation Guidelines», BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.

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

[RFC5891] Klensin, J., «Internationalized Domain Names in Applications (IDNA): Protocol», RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.

[RFC5892] Faltstrom, P., Ed., «The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)», RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.

[RFC5893] Alvestrand, H., Ed. and C. Karp, «Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)», RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.

[RFC5894] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale», RFC 5894, DOI 10.17487/RFC5894, August 2010, <https://www.rfc-editor.org/info/rfc5894>.

[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, «IAB Thoughts on Encodings for Internationalized Domain Names», RFC 6055, DOI 10.17487/RFC6055, February 2011, <https://www.rfc-editor.org/info/rfc6055>.

[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

[RFC6303] Andrews, M., «Locally Served DNS Zones», BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.

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

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

[RFC6672] Rose, S. and W. Wijngaards, «DNAME Redirection in the DNS», RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/info/rfc6672>.

[RFC6762] Cheshire, S. and M. Krochmal, «Multicast DNS», RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC7129] Gieben, R. and W. Mekking, «Authenticated Denial of Existence in the DNS», RFC 7129, DOI 10.17487/RFC7129, February 2014, <https://www.rfc-editor.org/info/rfc7129>.

[RFC7480] Newton, A., Ellacott, B., and N. Kong, «HTTP Usage in the Registration Data Access Protocol (RDAP)», STD 95, RFC 7480, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-editor.org/info/rfc7480>.

[RFC7481] Hollenbeck, S. and N. Kong, «Security Services for the Registration Data Access Protocol (RDAP)», STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-editor.org/info/rfc7481>.

[RFC9082] Hollenbeck, S. and A. Newton, «Registration Data Access Protocol (RDAP) Query Format», STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, <https://www.rfc-editor.org/info/rfc9082>.

[RFC9083] Hollenbeck, S. and A. Newton, «JSON Responses for the Registration Data Access Protocol (RDAP)», STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, <https://www.rfc-editor.org/info/rfc9083>.

[RFC9224] Blanchet, M., «Finding the Authoritative Registration Data Access Protocol (RDAP) Service», STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, <https://www.rfc-editor.org/info/rfc9224>.

[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, «Inventory and Analysis of WHOIS Registration Objects», RFC 7485, DOI 10.17487/RFC7485, March 2015, <https://www.rfc-editor.org/info/rfc7485>.

[RFC7793] Andrews, M., «Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry», BCP 163, RFC 7793, DOI 10.17487/RFC7793, May 2016, <https://www.rfc-editor.org/info/rfc7793>.

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

[RFC8094] Reddy, T., Wing, D., and P. Patil, «DNS over Datagram Transport Layer Security (DTLS)», RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.

[RFC8109] Koch, P., Larson, M., and P. Hoffman, «Initializing a DNS Resolver with Priming Queries», BCP 209, RFC 8109, DOI 10.17487/RFC8109, March 2017, <https://www.rfc-editor.org/info/rfc8109>.

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

[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. Mankin, «DNS Zone Transfer over TLS», RFC 9103, DOI 10.17487/RFC9103, August 2021, <https://www.rfc-editor.org/info/rfc9103>.

[RSSAC026] Root Server System Advisory Committee (RSSAC), «RSSAC0226 RSSAC Lexicon», 2017, <https://www.icann.org/en/system/files/files/rssac-026-14mar17-en.pdf>.

Приложение A. Определения, обновлённые этим документом

Ниже указаны определения из других RFC, обновлённые этим документом.

  • Forwarder из [RFC2308]

  • QNAME из [RFC2308]

  • Secure Entry Point (SEP) из [RFC3757] (этот RFC уже устарел, см. [RFC4033], [RFC4034], [RFC4035]).

Приложение B. Определения, добавленные этим документом

Ниже указаны определения, добавленные этим документом.

  • Alias в разделе 2

  • Apex в разделе 7

  • arpa в разделе 7

  • Authoritative DoT (ADot)» в разделе 6

  • Bailiwick в разделе 7

  • Class independent в разделе 5

  • Classic DNS в разделе 6

  • Delegation-centric zone в разделе 7

  • Delegation в разделе 7

  • DNS operator в разделе 9

  • DNSSEC-aware в разделе 10

  • DNSSEC-unaware в разделе 10

  • Forwarding в разделе 6

  • Full resolver в разделе 6

  • Fully Qualified Domain Name в разделе 2

  • Global DNS в разделе 2

  • Hardware Security Module (HSM) в разделе 10

  • Host name в разделе 2

  • IDN в разделе 2

  • In-domain в разделе 7

  • Iterative resolution в разделе 6

  • Label в разделе 2

  • Locally served DNS zone в разделе 2

  • Naming system в разделе 2

  • Negative response в разделе 3

  • Non-recursive query в разделе 6

  • Open resolver в разделе 6

  • Passive DNS в разделе 6

  • Policy-implementing resolver в разделе 6

  • Presentation format в разделе 5

  • Priming в разделе 6

  • Private DNS в разделе 2

  • Recursive DoT (RDot) в разделе 6

  • Recursive resolver в разделе 6

  • Referrals в разделе 4

  • Registrant в разделе 9

  • Registrar в разделе 9

  • Registry в разделе 9

  • Root zone в разделе 7

  • Secure Entry Point (SEP) в разделе 10

  • Sibling domain в разделе 7

  • Signing software в разделе 10

  • Split DNS в разделе 6

  • Stub resolver в разделе 6

  • Subordinate в разделе 8

  • Superordinate в разделе 8

  • TLD в разделе 2

  • Validating resolver в разделе 10

  • Validation в разделе 10

  • View в разделе 6

  • Zone transfer в разделе 6

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

Andrew Sullivan был соавтором [RFC8499] и его предшественника — [RFC7719]. У текущего документа, который является небольшим обновлением [RFC8499], всего два автора. Работа Andrew над предыдущими документами заслуживает высокой оценки.

В создание [RFC8499] и [RFC7719] внесли вклад многие люди, отмеченные в разделах благодарностей этих документов.

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

Предметный указатель


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

Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
 
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Email: fujiwara@jprs.co.jp

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

nmalykh@protokols.ru


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

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

3В английском языке. Прим. перев.

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

RFC 9533 One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Internet Engineering Task Force (IETF)                             Z. Li
Request for Comments: 9533                                  China Mobile
Category: Standards Track                                        T. Zhou
ISSN: 2070-1721                                                   Huawei
                                                                  J. Guo
                                                               ZTE Corp.
                                                               G. Mirsky
                                                                Ericsson
                                                               R. Gandhi
                                                     Cisco Systems, Inc.
                                                            January 2024

One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Расширения протоколов OWAMP и TWAMP для измерения производительности LAG

PDF

Аннотация

Этот документ задаёт расширения протоколов односторонних One-Way Active Measurement Protocol или OWAMP) и двухсторонних (Two-Way Active Measurement Protocol или TWAMP) активных измерений для оценки производительности каждого члена группы агрегирования каналов (Link Aggregation Group или LAG). Знание показателей каждого канала в LAG позволяет операторам внедрять на каждом канале основанные на производительности правила распределения трафика.

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

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

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

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

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

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

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

1. Введение

Группы агрегирования каналов (LAG), как указано в [IEEE802.1AX], обеспечивают механизмы объединения нескольких физических каналов в один логический. Этот логический канал обеспечивает большую пропускную способность и повышает отказоустойчивость, поскольку при отказе одного из физических каналов агрегированный логический канал может продолжать пересылку трафика через оставшиеся в группе физические каналы.

Обычно при пересылке трафика через LAG применяется основанный на хэшировании механизм распределения трафика между членами LAG. Задержка в в разных каналах группы может различаться из-за разных транспортных путей, особенно при использовании LAG в распределенной сети. Для обеспечения малой задержки чувствительного ко времени трафика требуется явно распределять трафик по каналам LAG с учётом задержки, потерь и т. п. Для этого требуется решение, позволяющее измерить показатели производительности на каждом канале LAG. Измеренные значения показателей могут применяться вместе с анонсами атрибутов L2 членов группы [RFC8668] для распределения трафика.

В соответствии с классификацией [RFC7799], OWAMP [RFC4656] и TWAMP [RFC5357] являются активными методами измерения и могут дополнять пассивные и гибридные методы. В любом из методов можно использовать одну тестовую сессию через LAG для измерения производительности конкретного канала группы с использованием специально созданного квинтета (5-tuple). Сессию можно организовать для измерения средних значения части или всех каналов LAG, меняя один или несколько элементов квинтета. Однако без знания каждого члена группы тестовая сессия не может применяться для измерения производительности каждого физического канала в группе.

Этот документ расширяет протоколы OWAMP и TWAMP для измерения производительности каждого канала группы LAG. Расширение может обеспечивать такие же показатели, как OWAMP и TWAMP (задержка и её вариации, потери пакетов.

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

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

2. Микросессии в LAG

В этом документе рассматривается вариант, где LAG напрямую соединяет два узла. Пример на рисунке 1 показывает LAG из 4 каналов, соединяющих узлы A и B. Задача состоит в измерении производительности каждого канала в LAG.

+---+                       +---+
|   |-----------------------|   |
| A |-----------------------| B |
|   |-----------------------|   |
|   |-----------------------|   |
+---+                       +---+

Рисунок . Измерение производительности в LAG.

Для измерения показателей производительности каждого канала в LAG требуется организовать несколько сессий (по одной для каждого канала) между парой конечных точек, соединённых через LAG. Эти сессии далее в документе называются микросессиями. Хотя фактически микросессии являются сессиями OWAMP или TWAMP на каналах группы LAG, тестовые пакеты микросессий TWAMP должны содержать сведения о конкретном канале для проверки.

Для всех микросессий LAG используются общие значения Sender IP Address и Receiver IP Address. В качестве номера порта UDP все микросессии могут использовать общие значения Sender Port и Receiver Port или для каждой из микросессий может быть задана своя пара номеров Sender Port и Receiver Port. Первый вариант проще в использовании, поэтому рекомендуется применять его.

Тестовые пакеты в микросессиях должны содержать сведения о канале для проверки действительности. Например, при получении тестового пакета микросессии TWAMP Session-Sender проверяет, относится ли этот пакет к ожидаемому каналу группы.

3. Сессия OWAMP

3.1. Micro OWAMP-Control

Для поддержки микросессий OWAMP этот документ определяет новую команду — Request-OW-Micro-Sessions (5), основанную на команде OWAMP Request-Session и использующую формат сообщений, описанный в параграфе 3.5 [RFC4656]. Создание микросессии OWAMP выполняется по процедуре, описанной в параграфе 3.5 [RFC4656] с указанным ниже отличием.

Когда OWAMP Server получает команду Request-OW-Micro-Sessions и запрос воспринят, OWAMP Server должен организовать набор микросессии для всех членов группы LAG из которой было получено сообщение Request-OW-Micro-Sessions.

3.2. Micro OWAMP-Test

Пакеты Micro OWAMP-Test используют формат и процедуры, заданные для OWAMP-Test в разделе 4 [RFC4656] с указанным ниже дополнением.

OWAMP Session-Sender микросессии должен передавать пакеты Micro OWAMP-Test через канал, с которым связана микросессия. При получении тестового пакета OWAMP Session-Receiver микросессии должен сопоставлять канал, из которого принят пакет, с микросессией OWAMP. Если такой сессии нет, тестовый пакет должен отбрасываться.

4. Сессия Micro TWAMP

4.1. Micro TWAMP-Control

Для поддержки микросессий TWAMP этот документ определяет новую команду — Request-TW-Micro-Sessions (11), основанную на команде TWAMP Request-Session и использующую формат сообщений, описанный в параграфе 3.5 [RFC5357]. Для организации микросессии TWAMP используется процедура из параграфа 3.5 в [RFC5357] с указанным ниже дополнением.

При получении сервером TWAMP команды Request-TW-Micro-Sessions и восприятии запроса TWAMP Server должен организовать набор микросессий для всех членов группы каналов LAG, из которой получено сообщение Request-TW-Micro-Sessions.

4.2. Micro TWAMP-Test

Протокол Micro TWAMP-Test основан на протоколе TWAMP-Test [RFC5357] с расширениями, описанными в последующих параграфах.

4.2.1. Формат и содержимое пакетов отправителя

Формат пакета Micro TWAMP Session-Sender основан на формате TWAMP Session-Sender, заданном в параграфе 4.1.2 [RFC5357]. Добавлены два новых поля (Sender Micro-session ID и Reflector Micro-session ID) для передачи идентификаторов каналов группы LAG. Формат для режима без аутентификации приведён ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |             MBZ               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Micro-session ID    |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session-Sender в режиме без аутентификации.

Для режима с аутентификацией и шифрованием применяется показанный ниже формат.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        MBZ (12 октетов)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |              MBZ              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Micro-session ID    |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                        Packet Padding                         .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session-Sender в режиме с аутентификацией.

Все поля, за исключением Sender Micro-session ID и Reflector Micro-session ID, соответствуют определениям параграфа 4.1.2 в [RFC5357] с использованием указанных там процедур и рекомендаций.

Sender Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Sender. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Sender.

Reflector Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Reflector. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Reflector.

4.2.2. Поведение отправителя

TWAMP Session-Sender микросессии наследует поведение TWAMP Session-Sender, заданное в параграфе 4.1 [RFC5357]. Дополнительно TWAMP Session-Sender должен передавать тестовые пакеты Micro Session-Sender через каналы-члены, с которыми связана сессия. При передаче тестового пакета TWAMP Session-Sender микросессии должен включать идентификатор канала Sender, связанного с микросессией TWAMP, в поле Sender Micro-session ID. Если Session-Sender изнает идентификатор канала-члена группы у Reflector, он должен указываться в поле Reflector Micro-session ID (см. рисунки 2 и 3). В иных случаях поле Reflector Micro-session ID должно иметь значение 0.

Тестовый пакет с идентификатором канала у Sender передаётся рефлектору Session-Reflector, который «отражает» его с тем же идентификатором канала Sender. Таким образом, Session-Sender может использовать идентификатор канала Sender для проверки получения отражённого тестового пакета из канала-члена, связанного с корректной микросессией TWAMP.

Идентификатор канала у Reflector в поле Reflector Micro-session ID используется рефлектором Session-Reflector для проверки получения тестового пакета из канала, связанного с корректной микросессией TWAMP. Это означает, что Session-Sender нужно узнать идентификатор канала-члена группы у Reflector. Когда Session-Sender знает идентификатор канала у Reflector, он должен помещать его в поле Reflector Micro-session ID (см. рисунки 2 и 3) тестового пакета, передаваемого рефлектору Session-Reflector. Идентификатор канала у Reflector может быть определён из конфигурации или плоскости данных (например, из отражённого тестового пакета). Этот документ не задаёт способ получения идентификатора канала на стороне Reflector.

При получении отражённого тестового пакета TWAMP Session-Sender микросессии должен использовать полученный идентификатор канала для сопоставления тестового пакета с микросессией TWAMP. Если соответствующей сессии нет, отражённый тестовый пакет должен отбрасываться. Если имеется соответствующая сессия, Session-Sender микросессии должен использовать Sender Micro-session ID для проверки корректного получения тестового пакета из ожидаемого канала группы. Если пакет получен из другого канала, он должен отбрасываться. Session-Sender микросессии должен использовать поле Reflector Micro-session ID для проверки поведения Reflector. При несоответствии идентификатора тестовый пакет должен отбрасываться.

4.2.3. Формат и содержимое пакетов рефлектора

Формат пакета Micro TWAMP Session-Reflector основан на формате TWAMP Session-Reflector, заданном в параграфе 4.2.1 [RFC5357]. Добавлены два новых поля (Sender Micro-session ID и Reflector Micro-session ID) для передачи идентификаторов каналов группы LAG. Формат для режима без аутентификации приведён ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |               MBZ             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Receive Timestamp                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sender Sequence Number                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sender Timestamp                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sender Error Estimate    |    Sender Micro-session ID    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sender TTL   |      MBZ      |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session- Reflector в режиме без аутентификации.


Для режима с аутентификацией и шифрованием применяется показанный ниже формат.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |               MBZ             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Micro-session ID    |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Receive Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sender Sequence Number                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sender Timestamp                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sender Error Estimate    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sender TTL   |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
|                                                               |
|                        MBZ (15 октетов)                       |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|                        HMAC (16 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета Micro Session- Reflector в режиме с аутентификацией.

Все поля, за исключением Sender Micro-session ID и Reflector Micro-session ID, соответствуют определениям параграфа 4.1.2 в [RFC5357] с использованием указанных там процедур и рекомендаций.

Sender Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Sender. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Sender.

Reflector Micro-session ID (2 октета)

Содержит идентификатор канала в группе LAG на стороне Reflector. В будущем поле может применяться не только для LAG. Значение поля должно быть уникальным в рамках сессии TWAMP у Session-Reflector.

4.2.4. Поведение рефлектора

TWAMP Session-Reflector микросессии наследует поведение TWAMP Session-Reflector, описанное в параграфе 4.2 [RFC5357]. Дополнительно TWAMP Session-Reflector должен использовать идентификатор канала, откуда получен пакет, для сопоставления пакета с микросессией TWAMP. Если такой сессии нет, тестовый пакет должен отбрасываться. Если поле Reflector Micro-session ID отлично от 0, Reflector должен использовать значение Reflector Micro-session ID для проверки соответствия идентификатору канала, из которого получен пакет (при Reflector Micro-session ID = 0 проверка не выполняется), и должен отбрасывать тестовый пакет при несоответствии.

При отправке отклика на полученный тестовый пакет TWAMP Session-Reflector микросессии должен копировать идентификатор каналу Sender из принятого пакета в поле Sender Micro-session ID отражённого тестового пакета (см. рисунки 4 и 5). Кроме того, TWAMP Session-Reflector микросессии должен помещать в поле Reflector Micro-session ID (см. рисунки 4 и 5) отражённого пакета идентификатор канала, связанного с микросессией TWAMP.

5. Применимость

Для организации микросессий OWAMP клиент Control-Client передаёт команду Request-OW-Micro-Sessions серверу OWAMP. Сервер OWAMP воспринимает запрос и организует набор микросессий для всех каналов группы LAG.

Для микросессий TWAMP применяется похожая процедура, после чего TWAMP Session-Sender микросессии передаёт пакеты Micro Session-Sender с полями Sender Micro-session ID и Reflector Micro-session ID. Если поле Reflector Micro-session ID задано (не 0), Session-Reflector микросессии проверяет получение тестового пакета из канала, соответствующего корректной микросессии TWAMP. При отражении TWAMP Session-Reflector микросессии копирует Sender Micro-session ID из полученного от Session-Sender микросессии пакета в пакет Micro Session-Reflector, затем указывает в поле Reflector Micro-session ID идентификатор канала, связанного с микросессией TWAMP. При получении пакета Micro TWAMP Session-Reflector поле Sender Micro-session ID используется Session-Sender микросессии для проверки получения пакета из канала, соответствующего корректной сессии TWAMP. Session-Sender микросессии также использует поле Reflector Micro-session ID для проверки поведения Reflector.

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

6.1. Команда Micro OWAMP-Control

Агентство IANA включило указанную в таблице 1 команду в реестр OWAMP-Control Command Numbers.

Таблица . Номер команды Request-OW-Micro-Sessions.

 

Значение

Описание

Документ

5

Request-OW-Micro-Sessions

Этот документ

 

6.2. Команда Micro TWAMP-Control

Агентство IANA включило указанную в таблице 2 команду в реестр TWAMP-Control Command Numbers.

Таблица . Номер команды Request-TW-Micro-Sessions.

 

Значение

Описание

Документ

11

Request-TW-Micro-Sessions

Этот документ

 

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

Этот документ не задаёт дополнительных требований безопасности и механизмов защиты к описанным в [RFC4656] и [RFC5357].

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

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

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

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

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

[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, «Advertising Layer 2 Bundle Member Link Attributes in IS-IS», RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.

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

[IEEE802.1AX] IEEE, «IEEE Standard for Local and Metropolitan Area Networks — Link Aggregation», IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, May 2020, <https://ieeexplore.ieee.org/document/9105034>.

[RFC7799] Morton, A., «Active and Passive Metrics and Methods (with Hybrid Types In-Between)», RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

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

Авторы благодарны Fang Xin, Henrik Nydell, Mach Chen, Min Xiao, Jeff Tantsura, Marcus Ihlar, Richard Foote за ценные замечания к работе.

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

Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com
 
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
 
Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn
 
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
 
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com

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

nmalykh@protokols.ru


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

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

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

RFC 9534 Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Internet Engineering Task Force (IETF)                             Z. Li
Request for Comments: 9534                                  China Mobile
Category: Standards Track                                        T. Zhou
ISSN: 2070-1721                                                   Huawei
                                                                  J. Guo
                                                               ZTE Corp.
                                                               G. Mirsky
                                                                Ericsson
                                                               R. Gandhi
                                                     Cisco Systems, Inc.
                                                            January 2024

Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Расширение протокола STAMP для измерения производительности LAG

PDF

Аннотация

Этот документ расширяет простой протокол двухсторонних активных измерений (Simple Two-way Active Measurement Protocol или STAMP) измерений для оценки производительности каждого члена группы агрегирования каналов (Link Aggregation Group или LAG). Знание показателей каждого канала в LAG позволяет операторам внедрять на каждом канале основанные на производительности правила распределения трафика.

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

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

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

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

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

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

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

1. Введение

Группы агрегирования каналов (LAG), как указано в [IEEE802.1AX], обеспечивают механизмы объединения нескольких физических каналов в один логический. Этот логический канал обеспечивает большую пропускную способность и повышает отказоустойчивость, поскольку при отказе одного из физических каналов агрегированный логический канал может продолжать пересылку трафика через оставшиеся в группе физические каналы.

Обычно при пересылке трафика через LAG применяется основанный на хэшировании механизм распределения трафика между членами LAG. Задержка в в разных каналах группы может различаться из-за разных транспортных путей, особенно при использовании LAG в распределенной сети. Для обеспечения малой задержки чувствительного ко времени трафика требуется явно распределять трафик по каналам LAG с учётом задержки, потерь и т. п. Для этого требуется решение, позволяющее измерить показатели производительности на каждом канале LAG. Измеренные значения показателей могут применяться вместе с анонсами атрибутов L2 членов группы [RFC8668] для распределения трафика.

В соответствии с классификацией [RFC7799], (STAMP) [RFC8762] является активным методом измерения и может дополнять пассивные и гибридные методы. Протокол обеспечивает механизм измерения в одном направлении или по кругу (round-trip) таких показателей как задержка и её вариации, потеря пакетов. Тестовую сессию STAMP через LAG для измерения производительности конкретного канала группы с использованием специально созданного квинтета (5-tuple). Сессию можно организовать для измерения средних значения части или всех каналов LAG, меняя один или несколько элементов квинтета. Однако без знания каждого члена группы тестовая сессия STAMP не может применяться для измерения производительности каждого физического канала в группе.

Этот документ расширяет протокол STAMP для измерения производительности каждого канала группы LAG. Расширение может обеспечивать такие же показатели, как OWAMP [RFC4656] и TWAMP [RFC5357] (задержка и её вариации, потери пакетов.

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

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

2. Микросессии в LAG

В этом документе рассматривается вариант, где LAG напрямую соединяет два узла. Пример на рисунке 1 показывает LAG из 4 каналов, соединяющих узлы A и B. Задача состоит в измерении производительности каждого канала в LAG.

+---+                       +---+
|   |-----------------------|   |
| A |-----------------------| B |
|   |-----------------------|   |
|   |-----------------------|   |
+---+                       +---+

Рисунок . Измерение производительности в LAG.


Для измерения показателей производительности каждого канала в LAG требуется организовать несколько сессий (по одной для каждого канала) между парой конечных точек, соединённых через LAG. Эти сессии далее в документе называются микросессиями. Хотя фактически микросессии являются сессиями STAMP на каналах группы LAG, тестовые пакеты микросессий должны содержать сведения о конкретном канале для проверки.

Для всех микросессий LAG используются общие значения Sender IP Address и Receiver IP Address. В качестве номера порта UDP все микросессии могут использовать общие значения Sender Port и Receiver Port или для каждой из микросессий может быть задана своя пара номеров Sender Port и Receiver Port. Первый вариант проще в использовании, поэтому рекомендуется применять его.

Тестовые пакеты в микросессиях должны содержать сведения о канале для проверки действительности. Например, при получении тестового пакета микросессии STAMP Session-Sender проверяет, относится ли этот пакет к ожидаемому каналу группы. Сведения о канале группы кодируются в Micro-session ID TLV (см. раздел 3, где представлено также подробное описание проверки канала.

STAMP Session-Sender в микросессии может включать Follow-Up Telemetry TLV [RFC8972] для запроса сведений у Session-Reflector микросессии. Эта временная метка может быть важна для Session-Sender в микросессии, поскольку она повышает точность сетевых измерений за счёт минимизации влияния задержки на измерения.

3. Проверка каналов группы

Тестовые пакеты должны передавать сведения о члене группы в Micro-session ID TLV, заданном в этом параграфе, для проверки канала. Session-Sender микросессии проверяет, получен ли тестовый пакет из ожидаемого канала группы, а также проверяет, отправлен ли пакет ожидаемым каналом-членом на стороне Reflector. Session-Reflector микросессии проверяет, был ли пакет передан ожидаемым членом группы.

3.1. Micro-session ID TLV

Механизм STAMP TLV [RFC8972] расширяет тестовые пакеты STAMP добавлением одного или нескольких необязательных TLV. Этот документ задаёт TLV Type (11) для Micro-session ID TLV, передающих идентификатор канала-члена для STAMP Session-Sender в поле Sender Micro-session ID и для Session-Reflector — в поле Reflector Micro-session ID. Формат Micro-session ID TLV показан на рисунке 2.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|  Type = 11    |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Sender Micro-session ID   |   Reflector Micro-session ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Micro-session ID TLV.


Type (1 октет)

Служит для указания Micro-session ID TLV. Значение 11 выделено агентством IANA (раздел 5).

Length (2 октета)

Размер поля Value в октетах. Поле должно иметь значение 4.

Sender Micro-session ID (2 октета)

Указывает идентификатор канала группы LAG на стороне отправителя (Sender). В будущем поле может использоваться не только с LAG. Значение поля должно быть уникальным в сессии STAMP у Session-Sender.

Reflector Micro-session ID (2 октета)

Указывает идентификатор канала группы LAG на стороне рефлектора (Reflector). В будущем поле может использоваться не только с LAG. Значение поля должно быть уникальным в сессии STAMP у Session-Reflector.

3.2. Процедуры Micro STAMP-Test

Для Micro STAMP-Test используются процедуры из раздела 4 STAMP [RFC8762] с указанными ниже дополнениями.

STAMP Session-Sender микросессии должен передавать пакеты Micro STAMP-Test через канал группы, с которым связана сессия. Сопоставление микросессий STAMP м идентификаторами каналов Sender/Reflector может быть задано путём добавления STAMP YANG [STAMP-YANG], детали добавления выходят за рамки этого документа.

При передаче тестовых пакетов STAMP Session-Sender микросессии должен указывать в поле Sender Micro-session ID идентификатор канала, связанного с микросессией STAMP. Если Session-Sender знает идентификатор канала для рефлектора, должно устанавливаться поле Reflector Micro-session ID. В иных случаях должно указываться Reflector Micro-session ID = 0. Идентификатор канала для рефлектора можно узнать из конфигурации или определить из плоскости данных (например, из отражённого тестового пакета). Этот документ не задаёт способ получения идентификатора канала для Reflector.

При получении STAMP Session-Reflector тестового пакета с отличным от 0 полем Reflector Micro-session ID, рефлектор микросессии должен использовать идентификатор канала Reflector для проверки принадлежности к микросессии STAMP. При несовпадении идентификаторов тестовый пакет должен отбрасываться. Если Reflector Micro-session ID = 0, проверка не выполняется. Если все проверки успешны, Session-Reflector передаёт отражённый тестовый пакет для Session-Sender. STAMP Session-Reflector микросессии должен указывать идентификаторы канала для Sender и Reflector, связанные с микросессией STAMP, в поля Sender Micro-session ID и Reflector Micro-session ID, соответственно. Идентификатор канала для Sender копируется из полученного тестового пакета.

При получении отражённого тестового пакета Session-Sender микросессии должен использовать Sender Micro-session ID для проверки получения тестового пакета из ожидаемого канала. При несовпадении идентификаторов тестовый пакет должен отбрасываться. Session-Sender микросессии должен использовать значение Reflector Micro-session ID для проверки корректности поведения рефлектора и при несовпадении значений тестовый пакет должен отбрасываться.

Два режима работы STAMP Session-Reflector (stateless и stateful) характеризуют ожидаемое поведение, как описано в разделе 4 STAMP [RFC8762]. Для STAMP-Test в микросессиях также поддерживаются режимы с учётом и без учёта состояния, однако Micro STAMP-Test не создаёт дополнительного состояния STAMP, т. е. все процедуры, относящиеся к Micro-session ID не учитывают состояния.

4. Применимость

STAMP Session-Sender микросессии передаёт пакеты Micro Session-Sender с Micro-session ID TLV. Session-Reflector микросессии проверяет, получен ли тестовый пакет из канала, связанного с микросессией STAMP, если поле Reflector Micro-session ID установлено. При отражении тестового пакета STAMP Session-Reflector микросессии копирует Sender Micro-session ID из полученного пакета от Session-Sender микросессии в свой пакет Session-Reflector и устанавливает в поле Reflector Micro-session ID идентификатор канала, связанного с микросессией STAMP. Session-Sender микросессии при получении пакета Micro Session-Reflector проверяет, принят ли он из канала, связанного с микросессией STAMP, по значению поля Sender Micro-session ID. Session-Sender микросессии использует также Reflector Micro-session ID для проверки корректности поведения Reflector.

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

Агентство IANA выделило значение STAMP TLV Type лоя Micro-session ID TLV в реестре STAMP TLV Types [RFC8972].

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

 

Значение

Описание

Документ

11

Micro-session ID

Этот документ

 

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

Заданное в этом документе расширение STAMP предназначено для применения в системах с LAG, где Session-Sender и Session-Reflector соединены напрямую групповым каналом. Предполагается, что узел, вовлечённый в работу STAMP был проверен на предмет целостности соединения LAG и нахождения узла-партнера на другом конце этого соединения (one-hop-away).

Документ не добавляет соображений безопасности, а механизмы защиты, указанные в [RFC8762] и [RFC8972], применимы и к этому документу.

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

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

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

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

[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, «Simple Two-Way Active Measurement Protocol», RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, «Simple Two-Way Active Measurement Protocol Optional Extensions», RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.

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

[IEEE802.1AX] IEEE, «IEEE Standard for Local and Metropolitan Area Networks — Link Aggregation», IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, May 2020, <https://ieeexplore.ieee.org/document/9105034>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC7799] Morton, A., «Active and Passive Metrics and Methods (with Hybrid Types In-Between)», RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, «Advertising Layer 2 Bundle Member Link Attributes in IS-IS», RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.

[STAMP-YANG] Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, «Simple Two-way Active Measurement Protocol (STAMP) Data Model», Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-12, 5 November 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-12>.

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

Авторы благодарят Mach Chen, Min Xiao, Fang Xin, Marcus Ihlar, Richard Foote за ценные комментарии к работе.

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

Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com
 
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
 
Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn
 
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
 
 
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com

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

nmalykh@protokols.ru


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

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

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