RFC 8703 - DLEP Link Identifier Extension 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8703.html
タイトル : RFC 8703 - DLEPリンク識別子拡張
翻訳編集 : 自動生成

[要約] RFC 8703は、DLEP（Dynamic Link Exchange Protocol）のLink Identifier拡張機能に関する仕様です。目的は、DLEPセッション内のリンクを一意に識別するための拡張機能を提供することです。

Internet Engineering Task Force (IETF)                         R. Taylor
Request for Comments: 8703                        Airbus Defence & Space
Category: Standards Track                                     S. Ratliff
ISSN: 2070-1721                                            February 2020

Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension

Dynamic Link Exchange Protocol（DLEP）リンク識別子拡張

Abstract

概要

The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC 8175) assumes that every modem in the radio network has an attached DLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.

Dynamic Link Exchange Protocol（DLEP）は、モデムが接続可能なルーターへの到達可能な宛先間のワイヤレスリンクのステータスを通知するためのプロトコルです。プロトコル（RFC 8175）のコア仕様では、無線ネットワークのすべてのモデムにDLEPルーターが接続されていることを想定しており、接続されたルーターのDLEPインターフェイスのメディアアクセス制御（MAC）アドレスを使用して、ネットワーク、その宛先へのリンクの状態と品質を報告するため。

This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain.

このドキュメントでは、上記の厳密な要件を満たさないモデムがDLEPを使用して、レイヤ2ドメインのデバイスを超えて到達可能な1つ以上の宛先へのリンクの可用性と品質を説明できるようにするDLEP拡張について説明します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8703.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8703で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Terminology
     1.2.  Applicability
     1.3.  Requirements Language
   2.  Operation
     2.1.  Identifier Restrictions
     2.2.  Negotiation
   3.  New Data Items
     3.1.  Link Identifier Length Data Item
     3.2.  Link Identifier Data Item
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Authors' Addresses

1. Introduction

1. はじめに

The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol [RFC8175] assumes that every modem in the radio network has an attached DLEP router and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.

Dynamic Link Exchange Protocol（DLEP）は、モデムが接続可能なルーターへの到達可能な宛先間のワイヤレスリンクのステータスを通知するためのプロトコルです。プロトコル[RFC8175]のコア仕様では、無線ネットワーク内のすべてのモデムにDLEPルーターが接続されていることを想定しており、レポートの目的で、接続されたルーターのDLEPインターフェイスのMACアドレスを使用してネットワーク内の宛先を特定する必要があります。その宛先へのリンクの状態と品質。

As with core DLEP [RFC8175], a router can use this knowledge to influence any routing or flow-control decisions regarding traffic to this destination, understanding that such traffic flows via Layer 3.

コアDLEP [RFC8175]と同様に、ルーターはこの知識を使用して、この宛先へのトラフィックに関するルーティングまたはフロー制御の決定に影響を与え、そのようなトラフィックがレイヤー3を介して流れることを理解できます。

1.1. Terminology

1.1. 用語

Local Layer 2 domain: The Layer 2 domain that links the router and modem participants of the current DLEP session.

ローカルレイヤー2ドメイン：現在のDLEPセッションのルーターとモデムの参加者をリンクするレイヤー2ドメイン。

Layer 3 DLEP Destination: A DLEP Destination that is not directly addressable within the local Layer 2 domain but is reachable via a node addressable within the local Layer 2 domain.

レイヤー3 DLEP宛先：ローカルレイヤー2ドメイン内で直接アドレス指定できないが、ローカルレイヤー2ドメイン内でアドレス指定可能なノードを介して到達可能なDLEP宛先。

Gateway Node: The last device with a MAC address reachable in the local Layer 2 domain on the path from the DLEP router participant towards the Layer 3 DLEP Destination. This device is commonly the DLEP peer modem but could be another DLEP Destination in the Layer 2 domain.

ゲートウェイノード：DLEPルーター参加者からレイヤー3 DLEP宛先へのパス上のローカルレイヤー2ドメインで到達可能なMACアドレスを持つ最後のデバイス。このデバイスは通常DLEPピアモデムですが、レイヤー2ドメイン内の別のDLEP宛先である可能性があります。

1.2. Applicability

1.2. 適用性

This extension was designed primarily to address the following use cases:

この拡張機能は、主に次の使用例に対処するために設計されました。

1. A radio system that does not operate in Layer 2 bridge mode but instead provides Layer 3 connectivity between destinations, often using its own embedded Layer 3 routing function.

1. レイヤ2ブリッジモードでは動作せず、代わりに宛先間にレイヤ3接続を提供する無線システム。多くの場合、独自の組み込みレイヤ3ルーティング機能を使用します。

2. A point-to-multipoint tunnel system, such as a software-defined wide-area network (SD-WAN) deployment, where the tunnel provider acts as a modem that has knowledge of the characteristics of the underlay network and provides that information as availability and metrics between tunnel endpoints in the overlay network.

2. ソフトウェア定義の広域ネットワーク（SD-WAN）展開などのポイントツーマルチポイントトンネルシステム。トンネルプロバイダーは、アンダーレイネットワークの特性を認識し、その情報を可用性として提供するモデムとして機能します。オーバーレイネットワークのトンネルエンドポイント間のメトリック。

3. A modem that provides connectivity to a remote wide-area network via a wireless link, but the concept of a Layer 2 reachable remote router does not apply. An example of such a modem would be an LTE device or 802.11 station that provides variable connectivity to the Internet.

3. ワイヤレスリンクを介してリモート広域ネットワークへの接続を提供するモデムですが、レイヤ2到達可能リモートルーターの概念は適用されません。そのようなモデムの例は、インターネットへの可変接続を提供するLTEデバイスまたは802.11ステーションです。

This list of use cases is not exhaustive, and this extension may well be applicable to future, currently unforeseen, use cases.

このユースケースのリストは完全なものではなく、この拡張機能は、将来の、現在予測できないユースケースに適用できる可能性があります。

1.3. Requirements Language

1.3. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. Operation

2. 操作

To refer to a Layer 3 DLEP Destination, the DLEP session participant adds a Link Identifier Data Item (Section 3.2) to the relevant Destination Message and (as usual) includes a MAC Address Data Item. When paired with a Link Identifier Data Item, the MAC Address Data Item MUST contain the MAC address of the Gateway Node.

レイヤー3 DLEP宛先を参照するために、DLEPセッションの参加者はリンク識別子データ項目（セクション3.2）を関連する宛先メッセージに追加し、（通常のように）MACアドレスデータ項目を含めます。リンク識別子データアイテムとペアになっている場合、MACアドレスデータアイテムにはゲートウェイノードのMACアドレスが含まれている必要があります。

As only modems are initially aware of Layer 3 DLEP Destinations, Link Identifier Data Items referring to a new link MUST first appear in a DLEP Destination Up Message from the modem to the router. Once a link has been identified in this way, Link Identifier Data Items may be used by either DLEP participant during the lifetime of a DLEP session. Because of this, a router MUST NOT send a DLEP Destination Announce Message containing a Link Identifier Data Item referring to a link that has not been mentioned in a prior DLEP Destination Up Message. If a modem receives such a message, it MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 ('Invalid Destination') and transition to the Session Termination state. If a router receives a Destination Up Message specifying a Link Identifier that has already been used, the router MUST respond with a Destination Up Response Message containing a Status Data Item with status code set to 130 ('Invalid Data') and transition to the Session Termination state.

モデムだけが最初にレイヤー3 DLEP宛先を認識しているため、新しいリンクを参照するリンク識別子データ項目は、最初にモデムからルーターへのDLEP宛先アップメッセージに表示される必要があります。このようにしてリンクが識別されると、DLEPセッションの存続期間中、いずれかのDLEP参加者がリンクIDデータ項目を使用できます。このため、ルーターは、以前のDLEP宛先アップメッセージで言及されていないリンクを参照するリンク識別子データアイテムを含むDLEP宛先通知メッセージを送信してはなりません（MUST NOT）。モデムがそのようなメッセージを受信した場合、ステータスコードが131（「無効な宛先」）に設定されたステータスデータアイテムを含むセッション終了メッセージを発行してセッションを終了し、セッション終了状態に移行する必要があります。ルーターが、すでに使用されているリンク識別子を指定する宛先アップメッセージを受信した場合、ルーターは、ステータスコードが130（ '無効なデータ'）に設定されたステータスデータアイテムを含む宛先アップ応答メッセージで応答し、セッションに移行する必要があります。終了状態。

Because the MAC address associated with any DLEP Destination Message containing a Link Identifier Data Item is not the Layer 2 address of the final destination, all DLEP Destination Up Messages containing a Link Identifier Data Item MUST contain Layer 3 information. In the case of modems that provide Layer 3 wide area network connectivity between devices, this means one or more IPv4 or IPv6 Address Data Items providing the Layer 3 address of the final destination. When referring to some upstream backbone network infrastructures, this means one or more IPv4 or IPv6 Attached Subnet Data Items, for example: '0.0.0.0/0' or '::/0'. This mechanism allows the DLEP peer router to understand the properties of the link to those routes. The address or addresses in the IPv4 or IPv6 Address Data Items MUST be the addresses in use on the public side of any Network Address Translation.

リンク識別子データアイテムを含むDLEP宛先メッセージに関連付けられたMACアドレスは最終宛先のレイヤ2アドレスではないため、リンク識別子データアイテムを含むすべてのDLEP宛先アップメッセージには、レイヤ3情報が含まれている必要があります。デバイス間にレイヤー3ワイドエリアネットワーク接続を提供するモデムの場合、これは、最終宛先のレイヤー3アドレスを提供する1つ以上のIPv4またはIPv6アドレスデータ項目を意味します。一部のアップストリームバックボーンネットワークインフラストラクチャを指す場合、これは、1つ以上のIPv4またはIPv6のアタッチされたサブネットデータアイテムを意味します（例： '0.0.0.0/0'または ':: / 0'）。このメカニズムにより、DLEPピアルーターはこれらのルートへのリンクのプロパティを理解できます。 IPv4またはIPv6アドレスデータアイテムのアドレスは、ネットワークアドレス変換のパブリック側で使用されているアドレスでなければなりません。

When the DLEP peer router wishes to route packets to the Layer 3 DLEP Destination, the MAC address associated with the Gateway Node MUST be used as the Layer 2 destination of the packet if it wishes to use the modem network to forward the packet.

DLEPピアルーターがパケットをレイヤー3 DLEP宛先にルーティングする場合、モデムネットワークを使用してパケットを転送する場合は、ゲートウェイノードに関連付けられたMACアドレスをパケットのレイヤー2宛先として使用する必要があります。

As routers populate their Routing Information Base with the IP address of the next-hop router towards a destination, implementations supporting this extension SHOULD announce at least one valid IPv4 or IPv6 addresses of the Gateway Node; this removes the need for the router to use an additional IP address resolution protocol before adding the route to its Routing Information Base.

ルーターがルーティング情報ベースに宛先へのネクストホップルーターのIPアドレスを入力するとき、この拡張をサポートする実装は、ゲートウェイノードの少なくとも1つの有効なIPv4またはIPv6アドレスを通知する必要があります。これにより、ルーターがルーティング情報ベースにルートを追加する前に、追加のIPアドレス解決プロトコルを使用する必要がなくなります。

2.1. Identifier Restrictions

2.1. 制限を特定する

A Link Identifier is, by default, 4 octets in length. If a modem wishes to use a Link Identifier of a different length, it MUST be announced using the Link Identifier Length Data Item (Section 3.1) contained in the DLEP Session Initialization Response Message sent by the modem to the router.

リンク識別子は、デフォルトでは4オクテットの長さです。モデムが異なる長さのリンク識別子を使用したい場合は、モデムがルーターに送信するDLEPセッション初期化応答メッセージに含まれるリンク識別子の長さデータ項目（セクション3.1）を使用して通知する必要があります。

During the lifetime of a DLEP session, the length of Link Identifiers MUST remain constant, i.e., the Length field of the Link Identifier Data Item MUST NOT differ between destinations.

DLEPセッションの存続期間中、リンク識別子の長さは一定でなければなりません。つまり、リンク識別子データ項目の長さフィールドは宛先間で異なっていてはなりません。

The method for generating Link Identifiers is a modem implementation matter and out of scope of this document. Routers must not make any assumptions about the meaning of Link Identifiers or how Link Identifiers are generated.

リンク識別子を生成する方法は、モデム実装の問題であり、このドキュメントの範囲外です。ルーターは、リンク識別子の意味やリンク識別子の生成方法を想定してはなりません。

Within a single DLEP session, all Link Identifiers MUST be unique per MAC address. This means that a Layer 3 DLEP Destination is uniquely identified by the pair: {MAC Address,Link Identifier}.

1つのDLEPセッション内では、すべてのリンク識別子はMACアドレスごとに一意である必要があります。つまり、レイヤー3のDLEP宛先は、{MACアドレス、リンク識別子}のペアで一意に識別されます。

Link Identifiers MUST NOT be reused, i.e., a {MAC Address,Link Identifier} pair that has been used to refer to one Layer 3 DLEP Destination MUST NOT be used again within the lifetime of a single DLEP peer-to-peer session.

リンク識別子は再利用してはなりません。つまり、1つのレイヤー3 DLEP宛先を参照するために使用された{MACアドレス、リンク識別子}ペアは、単一のDLEPピアツーピアセッションの存続期間中に再度使用してはなりません。

2.2. Negotiation

2.2. ネゴシエーション

To use this extension, as with all DLEP extensions, the extension MUST be announced during DLEP session initialization. A router advertises support by including the value 3 ('Link Identifiers') (Section 5), in the Extension Data Item within the Session Initialization Message. A modem advertises support by including the value 3 ('Link Identifiers') in the Extension Data Item within the Session Initialization Response Message. If both DLEP peers advertise support for this extension, then Link Identifier Data Items can be included in DLEP Messages.

この拡張機能を使用するには、すべてのDLEP拡張機能と同様に、DLEPセッションの初期化中に拡張機能を通知する必要があります。ルーターは、セッション初期化メッセージ内の拡張データ項目に値3（「リンク識別子」）（セクション5）を含めることでサポートをアドバタイズします。モデムは、セッション初期化応答メッセージ内の拡張データ項目に値3（「リンク識別子」）を含めることでサポートをアドバタイズします。両方のDLEPピアがこの拡張機能のサポートをアドバタイズする場合、DLEPメッセージにリンク識別子データ項目を含めることができます。

If a modem requires support for this extension in order to describe destinations and the router does not advertise support, then the modem MUST NOT include a Link Identifier Data Item in any DLEP Message. However, the modem SHOULD NOT immediately terminate the DLEP session; rather, it SHOULD use a combination of DLEP Session Messages and DLEP Attached Subnet Data Items to provide general information.

モデムが宛先を記述するためにこの拡張機能のサポートを必要とし、ルーターがサポートをアドバタイズしない場合、モデムはDLEPメッセージにリンク識別子データ項目を含めてはなりません（MUST NOT）。ただし、モデムはすぐにDLEPセッションを終了しないでください。むしろ、一般的な情報を提供するために、DLEPセッションメッセージとDLEP添付サブネットデータ項目の組み合わせを使用する必要があります。

3. New Data Items

3. 新しいデータアイテム

This extension introduces two new DLEP Data Items: 1) the Link Identifier Length Data Item (Section 3.1) used to announce the length of Link Identifiers at session initialization and 2) the Link Identifier Data Item (Section 3.2) used to identify a Layer 3 link at or beyond a destination.

この拡張機能は、2つの新しいDLEPデータ項目を導入します。1）セッション初期化時にリンク識別子の長さを通知するために使用されるリンク識別子の長さデータ項目（セクション3.1）および2）レイヤー3を識別するために使用されるリンク識別子データ項目（セクション3.2）リンク先またはリンク先。

3.1. Link Identifier Length Data Item

3.1. リンク識別子の長さデータ項目

The Link Identifier Length Data Item is used by a DLEP modem implementation to specify the length of Link Identifier Data Items. If the router advertised support by including the value 3 ('Link Identifiers') in the Extension Data Item inside the Session Initialization Message, this Data Item MAY be used in the Session Initialization Response Message if the specified length is not the default value of 4 octets. If the router did not specify support by including the value 3 ('Link Identifiers') in the Extension Data Item, this Data Item MUST NOT be sent.

リンク識別子の長さデータ項目は、リンク識別子データ項目の長さを指定するためにDLEPモデムの実装によって使用されます。ルーターがセッション初期化メッセージ内の拡張データ項目に値3（「リンク識別子」）を含めることでサポートをアドバタイズした場合、指定された長さがデフォルト値の4ではない場合、このデータ項目をセッション初期化応答メッセージで使用できます。オクテット。ルーターが拡張データ項目に値3（「リンク識別子」）を含めることでサポートを指定しなかった場合、このデータ項目を送信してはならない（MUST NOT）。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type                | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Link Identifier Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 26 (see Section 5)

データ項目タイプ：26（セクション5を参照）

Length: 2

長さ：2

Link Identifier Length: The length, in octets, of Link Identifiers used by the DLEP modem for this session.

リンクIDの長さ：このセッションのDLEPモデムで使用されるリンクIDの長さ（オクテット単位）。

A Link Identifier Length Data Item that specifies a Link Identifier Length of 4 octets (the default) is valid, even if it has no effect.

リンク識別子の長さを4オクテット（デフォルト）に指定するリンク識別子の長さデータ項目は、効果がない場合でも有効です。

3.2. Link Identifier Data Item

3.2. リンク識別子データ項目

The Link Identifier Data Item MAY be used wherever a MAC Address Data Item is defined as usable in core DLEP [RFC8175].

リンク識別子データ項目は、MACアドレスデータ項目がコアDLEP [RFC8175]で使用可能として定義されている場合はいつでも使用できます。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type                | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Link Identifier...                          :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 27 (see Section 5)

データ項目タイプ：27（セクション5を参照）

Length: The length of the Data Item, by default 4, but may be different if a Link Identifier Length Data Item (Section 3.1) has been announced during session initialization.

長さ：データ項目の長さ。デフォルトでは4ですが、セッションの初期化中にリンク識別子の長さデータ項目（セクション3.1）がアナウンスされている場合は異なる場合があります。

Link Identifier: The unique identifier of the Layer 3 DLEP Destination. This Link Identifier has no implicit meaning and is only used to discriminate between multiple links.

リンク識別子：レイヤー3 DLEP宛先の一意の識別子。このリンク識別子には暗黙の意味はなく、複数のリンクを区別するためにのみ使用されます。

4. Security Considerations

4. セキュリティに関する考慮事項

As an extension to core DLEP [RFC8175], the security considerations of that protocol apply to this extension. This extension adds no additional security mechanisms or features.

コアDLEP [RFC8175]の拡張機能として、そのプロトコルのセキュリティに関する考慮事項がこの拡張機能に適用されます。この拡張機能は、追加のセキュリティメカニズムや機能を追加しません。

None of the features introduced by this extension require extra security considerations by an implementation.

この拡張機能で導入された機能は、実装による追加のセキュリティ考慮事項を必要としません。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has assigned the following value to the "Extension Type Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. This new value is in the range with the "Specification Required" [RFC8126] policy.

IANAは、「Dynamic Link Exchange Protocol（DLEP）Parameters」レジストリ内の「Extension Type Values」レジストリに次の値を割り当てました。この新しい値は、「指定が必要」[RFC8126]ポリシーの範囲内です。

   +------+------------------+
   | Code | Description      |
   +======+==================+
   | 3    | Link Identifiers |
   +------+------------------+

Table 1: Addition to the Extension Type Values Registry

表1：拡張タイプ値レジストリへの追加

IANA has assigned two new values to the "Data Item Type Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. These new values are in the range with the "Specification Required" [RFC8126] policy.

IANAは、「Dynamic Link Exchange Protocol（DLEP）パラメータ」レジストリ内の「データアイテムタイプ値」レジストリに2つの新しい値を割り当てました。これらの新しい値は、「Specification Required」[RFC8126]ポリシーの範囲内にあります。

   +-----------+------------------------+
   | Type Code | Description            |
   +===========+========================+
   | 26        | Link Identifier Length |
   +-----------+------------------------+
   | 27        | Link Identifier        |
   +-----------+------------------------+

Table 2: Additions to the Data Item Type Values Registry

表2：データ項目タイプ値レジストリへの追加

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, <https://www.rfc-editor.org/info/rfc8175>.

[RFC8175] Ratliff、S.、Jury、S.、Satterwhite、D.、Taylor、R。、およびB. Berry、「Dynamic Link Exchange Protocol（DLEP）」、RFC 8175、DOI 10.17487 / RFC8175、2017年6月、< https://www.rfc-editor.org/info/rfc8175>。

6.2. Informative References

6.2. 参考引用

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

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。

Authors' Addresses

著者のアドレス

Rick Taylor Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ United Kingdom

Rick Taylor Airbus Defense＆Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ United Kingdom

   Email: rick.taylor@airbus.com

Stan Ratliff

スタン・ラトリフ