[要約] RFC 8629は、DLEPプロトコルのマルチホップ転送拡張機能に関するものであり、要約すると以下のようになります。1. DLEPプロトコルを使用して、複数のホップを経由してデータを転送するための拡張機能を提供する。 2. マルチホップ転送により、ネットワークの範囲を広げることができる。 3. 目的は、効率的なデータ転送とネットワークの拡張性を向上させることである。
Internet Engineering Task Force (IETF) B. Cheng
Request for Comments: 8629 MIT Lincoln Laboratory
Category: Standards Track L. Berger, Ed.
ISSN: 2070-1721 LabN Consulting, L.L.C.
July 2019
Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension
動的リンク交換プロトコル（DLEP）マルチホップ転送拡張機能
Abstract
概要
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.
このドキュメントでは、DLEP対応モデムによるマルチホップ転送のレポートと制御を可能にするDynamic Link Exchange Protocol（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/rfc8629.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8629で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extension Usage and Identification . . . . . . . . . . . . . 3
3. Extension Data Items . . . . . . . . . . . . . . . . . . . . 3
3.1. Hop Count . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Hop Control . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Reset . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Terminate . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Direct Connection . . . . . . . . . . . . . . . . . . 7
3.2.4. Suppress Forwarding . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Extension Type Value . . . . . . . . . . . . . . . . . . 8
5.2. Data Item Values . . . . . . . . . . . . . . . . . . . . 9
5.3. Hop Control Actions Registry . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. It provides the exchange of link-related control information between a modem and a router. DLEP defines a base set of mechanisms as well as support for possible extensions. This document defines one such extension.
Dynamic Link Exchange Protocol（DLEP）は[RFC8175]で定義されています。モデムとルーター間でリンク関連の制御情報を交換します。 DLEPはメカニズムの基本セットと可能な拡張のサポートを定義します。このドキュメントでは、そのような拡張機能の1つを定義しています。
Some modem technologies support mobile ad hoc network (MANET) forwarding where connectivity to destinations is provided via forwarding in intermediate modems. This document refers to forwarding by intermediate modems as "multi-hop forwarding". DLEP Destination Messages can be used to report such reachable destinations (see [RFC8175]), but do not provide any information related to the number or capacity of the hops. The extension defined in this document enables modems to inform routers when multi-hop forwarding is being used and allows routers to request that modems change multi-hop forwarding behavior. The extension defined in this document is referred to as "Multi-Hop Forwarding", where each modem that transmits/sends data to reach a particular destination is counted as a hop.
一部のモデム技術は、中間モデムでの転送を介して宛先への接続が提供されるモバイルアドホックネットワーク（MANET）転送をサポートしています。このドキュメントでは、中間モデムによる転送を「マルチホップ転送」と呼びます。 DLEP宛先メッセージは、そのような到達可能な宛先（[RFC8175]を参照）を報告するために使用できますが、ホップの数や容量に関する情報は提供しません。このドキュメントで定義された拡張機能により、マルチホップ転送が使用されているときにモデムがルーターに通知し、ルーターがモデムにマルチホップ転送動作を変更するように要求することができます。このドキュメントで定義されている拡張機能は「マルチホップ転送」と呼ばれ、特定の宛先に到達するためにデータを送信/送信する各モデムはホップとしてカウントされます。
It is important to note that the use of the Hop Control mechanism defined in this document can result in connectivity changes and even loss of the ability to reach one or more destinations. The defined mechanism will report such connectivity changes, but the details of what a router does or how it reacts to such are out scope of this document.
このドキュメントで定義されているホップ制御メカニズムを使用すると、接続が変更され、1つ以上の宛先に到達する能力が失われる可能性があることに注意することが重要です。定義されたメカニズムはこのような接続の変更を報告しますが、ルーターが何をするか、またはどのようにそれに反応するかについての詳細は、このドキュメントの範囲外です。
This document defines a new DLEP Extension Type Value in Section 2, which indicates the use of the extension, and three new DLEP Data Items in Section 3.
このドキュメントでは、セクション2で新しいDLEP拡張タイプ値を定義します。これは、拡張の使用を示し、セクション3で3つの新しいDLEPデータ項目を示します。
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]で説明されているように解釈されます。
The use of the Multi-Hop Forwarding Extension SHOULD be configurable. Per [RFC8175], to indicate that the extension is to be used, an implementation includes the Multi-Hop Forwarding Extension Type Value in the Extensions Supported Data Item. The Extensions Supported Data Item is sent and processed according to [RFC8175].
マルチホップ転送拡張機能の使用は構成可能である必要があります（SHOULD）。 [RFC8175]に従って、拡張機能が使用されることを示すために、実装には、マルチホップ転送拡張機能タイプ値が拡張機能サポートデータ項目に含まれています。 Extensions Supported Data Itemは、[RFC8175]に従って送信および処理されます。
The Multi-Hop Forwarding Extension Type Value is 1 (see Section 5).
マルチホップ転送拡張タイプの値は1です（セクション5を参照）。
Three data items are defined by this extension. The Hop Count Data Item is used by a modem to provide the number of modem hops traversed to reach a particular destination. The Hop Control Data Item is used by a router to request that a modem alter connectivity to a particular destination. The Suppress Forwarding Data Item is used by a router to request that a modem disable multi-hop forwarding on either a device or destination basis.
この拡張機能では、3つのデータ項目が定義されています。ホップカウントデータアイテムは、特定の宛先に到達するために通過するモデムホップの数を提供するためにモデムによって使用されます。ルーターがホップ制御データ項目を使用して、モデムが特定の宛先への接続を変更することを要求します。 Suppress Forwarding Data Itemは、ルーターがモデムにデバイスまたは宛先ベースでマルチホップ転送を無効にするよう要求するために使用されます。
The Hop Count Data Item is used by a modem to indicate the number of modems that transmit/send data to reach a particular destination, i.e., hops, between the modem and a specific destination. In other words, each hop represents a transmission, and the number of hops is equal to the number of transmissions required to go from a router's connected modem to the destination's connected modem. The minimum number of hops is 1, which represents transmission to destinations that are directly reachable via the router's locally connected modem.
ホップカウントデータアイテムは、特定の宛先に到達するためにデータを送信/送信するモデムの数を示すためにモデムによって使用されます。つまり、モデムと特定の宛先の間のホップです。つまり、各ホップは送信を表し、ホップの数は、ルーターの接続されたモデムから宛先の接続されたモデムに移動するために必要な送信の数と同じです。最小ホップ数は1です。これは、ルーターのローカル接続されたモデムを介して直接到達可能な宛先への送信を表します。
The data item also contains an indication of when a destination that currently has a hop count of greater than one (1) could be made directly reachable by a modem, e.g., by reaiming an antenna.
データ項目には、ホップカウントが現在1より大きい宛先が、たとえばアンテナを再構築することによって、モデムから直接到達できるようになったときの指示も含まれています。
The Hop Count Data Item SHOULD be carried in the Destination Up, Destination Update, Destination Announce Response, and Link Characteristics Response Messages when the Hop Count to a destination is greater than one (1).
ホップカウントデータアイテムは、宛先へのホップカウントが1より大きい場合、宛先アップ、宛先更新、宛先アナウンス応答、およびリンク特性応答メッセージで運ばれる必要があります。
A router receiving a Hop Count Data Item can use this information in its forwarding and routing decisions, but specific use is out of scope of this document. When using this extension, the absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1).
ホップカウントデータアイテムを受信するルーターは、この情報を転送およびルーティングの決定に使用できますが、特定の使用はこのドキュメントの範囲外です。この拡張機能を使用する場合、ホップカウントデータ項目がないことは、ルーターによってホップカウント値1として解釈される必要があります。
The format of the Hop Count Data Item is:
ホップカウントデータアイテムの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 21
データ項目タイプ：21
Length: 2
長さ：2
P:
P：
The P-bit indicates that a destination is potentially directly reachable. When the P-bit is set, the router MAY request a direct link to the associated destination using the Hop Control Data Item described below. This field MUST be ignored when the value contained in the Hop Count field is one (1).
Pビットは、宛先が潜在的に直接到達可能であることを示します。 Pビットが設定されている場合、ルーターは、以下で説明するホップ制御データ項目を使用して、関連する宛先への直接リンクを要求できます（MAY）。ホップカウントフィールドに含まれる値が1の場合、このフィールドは無視する必要があります。
Reserved:
予約済み：
The Reserved field MUST be set to zero by the sender (a modem) and ignored by the receiver (a router).
Reservedフィールドは、送信側（モデム）によってゼロに設定され、受信側（ルーター）によって無視されなければなりません（MUST）。
Hop Count:
ホップ数：
The Hop Count is an unsigned 8-bit integer indicating the number of modem hops required (i.e., number of times a packet will be transmitted) to reach the destination indicated in the message. The special value of 255 (0xFF) is used to indicate that the number of hops is an unknown number greater than one (1). This field MUST contain a value of at least one (1) if the associated destination is reachable.
ホップカウントは、メッセージに示された宛先に到達するために必要なモデムホップの数（つまり、パケットが送信される回数）を示す符号なし8ビット整数です。特別な値である255（0xFF）は、ホップ数が1より大きい未知の数であることを示すために使用されます。関連付けられた宛先に到達できる場合、このフィールドには少なくとも1つの値が含まれている必要があります。
A value of zero (0) is used to indicate that the processing of a Hop Control action (see Section 3.2) has resulted in the destination no longer being reachable. A zero value MUST NOT be used in any message other than a Link Characteristics Response Message.
ゼロ（0）の値は、ホップ制御アクション（セクション3.2を参照）の処理の結果、宛先に到達できなくなったことを示します。ゼロ値は、リンク特性応答メッセージ以外のメッセージでは使用してはなりません。
The Hop Control Data Item is used by a router to request a change in connectivity to a particular destination or to perform multi-hop processing on a device-wide basis. A router can request that a multi-hop-reachable destination be changed to a single-hop destination. A router can also indicate that the modem terminates a previous direct connectivity request to a particular destination.
ルーターは、ホップ制御データ項目を使用して、特定の宛先への接続の変更を要求するか、デバイス全体でマルチホップ処理を実行します。ルーターは、マルチホップ到達可能な宛先をシングルホップ宛先に変更するよう要求できます。ルーターは、モデムが特定の宛先への以前の直接接続要求を終了することを示すこともできます。
The Hop Control Data Item MAY be carried in a Session Update Message sent by a router when the control applies to the whole device, or a Link Characteristics Request Message when the control applies to a particular destination.
ホップ制御データ項目は、制御がデバイス全体に適用される場合にルーターによって送信されるセッション更新メッセージ、または制御が特定の宛先に適用される場合にリンク特性要求メッセージで伝達される場合があります。
A modem that receives the Hop Control Data Item in a Link Characteristics Request Message SHOULD take whatever actions are needed to make the change indicated by the data item for the associated destination Media Access Control (MAC) address. Once the change is made, fails, or is rejected, the modem MUST respond with a Link Characteristics Response Message containing an updated Hop Count Data Item. Note that other destinations can be impacted as a result of the change, and such changes are reported in Destination Down and Destination Update Messages. The modem MUST notify the router of each destination that is not identified in the Link Characteristics Response Message and is no longer reachable via a Destination Down Message. The modem MUST also notify the router of each impacted destination that is not identified in the Link Characteristics Response Message via a Destination Update Message.
リンク特性要求メッセージでホップ制御データ項目を受信するモデムは、関連する宛先メディアアクセス制御（MAC）アドレスのデータ項目が示す変更を行うために必要なアクションを実行する必要があります（SHOULD）。変更が行われるか、失敗するか、拒否されると、モデムは更新されたホップカウントデータ項目を含むリンク特性応答メッセージで応答する必要があります。変更の結果として他の宛先が影響を受ける可能性があることに注意してください。そのような変更は、宛先ダウンおよび宛先更新メッセージで報告されます。モデムは、リンク特性応答メッセージで識別されず、宛先ダウンメッセージを介して到達できなくなった各宛先をルーターに通知する必要があります。モデムは、宛先更新メッセージを介して、リンク特性応答メッセージで識別されない影響を受ける各宛先をルーターに通知する必要もあります。
Failures may occur for multiple reasons, for example, the transmission characteristics of the link don't support the one-hop connection at the time of the request. Requests can be rejected by local policy.
障害は、複数の理由で発生する可能性があります。たとえば、リンクの送信特性が要求時のワンホップ接続をサポートしていないなどです。リクエストはローカルポリシーによって拒否されます。
A modem that receives the Hop Control Data Item in a Session Update Message SHOULD take whatever actions are needed to make the change indicated by the data item for all known destinations. Once the change is made, fails, or is rejected, the modem MUST respond with a Session Update Response Message with an appropriate Status Code. The destination-specific impact of processing a Hop Control Data Item in a Session Update Message is provided via Destination Down and Destination Update Messages. The modem MUST notify the router of each destination that is no longer reachable via a Destination Down Message. The modem MUST notify the router of any changes in Hop Counts via Destination Update Messages.
セッション更新メッセージでホップ制御データ項目を受信するモデムは、すべての既知の宛先のデータ項目によって示される変更を行うために必要なアクションを実行する必要があります（SHOULD）。変更が行われた、失敗した、または拒否された場合、モデムは適切なステータスコードを含むセッション更新応答メッセージで応答する必要があります。セッション更新メッセージ内のホップ制御データ項目の処理の宛先固有の影響は、宛先ダウンおよび宛先更新メッセージを介して提供されます。モデムは、Destination Down Messageを介して到達できなくなった各宛先をルーターに通知する必要があります。モデムは、宛先更新メッセージを介してホップカウントの変更をルータに通知する必要があります。
The format of the Hop Control Data Item is:
ホップ制御データ項目の形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Control Actions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 22
データ項目タイプ：22
Length: 2
長さ：2
Hop Control Actions:
ホップ制御アクション：
The Hop Control Actions field is an unsigned 16-bit value with the following meaning:
ホップ制御アクションフィールドは、次の意味を持つ符号なし16ビット値です。
+-------+---------------------+
| Value | Action |
+-------+---------------------+
| 0 | Reset |
| 1 | Terminate |
| 2 | Direct Connection |
| 3 | Suppress Forwarding |
+-------+---------------------+
Table 1: Hop Control Actions Values
表1：ホップ制御アクションの値
The Reset Action requests that the default behavior be restored. When received in a Session Update Message, a modem MUST clear all control actions that have previously been processed on a device-wide basis and revert to its configured behavior. When received in a Link Characteristics Request Message, a modem MUST clear all control actions that have previously been processed for the destination indicated in the message.
リセットアクションは、デフォルトの動作に戻すことを要求します。モデムは、セッション更新メッセージで受信されると、以前にデバイス全体で処理されていたすべての制御アクションをクリアし、構成された動作に戻す必要があります。モデムは、リンク特性要求メッセージで受信されると、メッセージで示された宛先に対して以前に処理されたすべての制御アクションをクリアする必要があります。
The Terminate Action is only valid on a per-destination basis and MUST NOT be sent in a Session Update Message. It indicates that a direct connection is no longer needed with the destination identified in the message. This request has no impact on multi-hop destinations and may fail even in a single-hop case, i.e., it can result in the Hop Count to the destination not being impacted by the processing of the request.
終了アクションは宛先ごとにのみ有効であり、セッション更新メッセージで送信してはなりません。これは、メッセージで識別された宛先との直接接続が不要になったことを示しています。このリクエストはマルチホップの宛先には影響せず、シングルホップの場合でも失敗する可能性があります。つまり、宛先へのホップ数がリクエストの処理の影響を受けない可能性があります。
The Direct Connection Action is only valid on a per-destination basis and MUST NOT be sent in a Session Update Message. It indicates that the modem SHOULD attempt to establish a direct connection with the destination identified in the message. This action SHOULD only be sent for destinations for which the Hop Count is both greater than 1 and has the P-Bit set in the previously received Hop Count Data Item. Results of the request for the destination identified in the message are provided as described above.
直接接続アクションは、宛先ごとにのみ有効であり、セッション更新メッセージで送信してはなりません。これは、モデムがメッセージで識別された宛先との直接接続の確立を試みる必要があることを示しています。このアクションは、ホップカウントが1より大きく、以前に受信したホップカウントデータアイテムにPビットが設定されている宛先に対してのみ送信する必要があります（SHOULD）。メッセージで識別された宛先に対する要求の結果は、上記のように提供されます。
The Suppress Forwarding Action is used by a router to indicate to its peer that multi-hop forwarding performed by the modem is to be suppressed. A router can request that multi-hop forwarding be suppressed on a device-wide or destination-specific basis.
ルーターによる抑制転送アクションは、モデムによって実行されるマルチホップ転送が抑制されることをピアに示すために使用されます。ルーターは、デバイス全体または宛先固有の基準でマルチホップ転送を抑制するように要求できます。
A modem that receives the Suppress Forwarding Data Item in a Session Update Message MUST suppress multi-hop forwarding on a device-wide basis. This means that data traffic originating from the modem's peer router SHALL only be sent by the modem to destinations that are one modem hop away, and that any data traffic received by the modem from another modem that is not destined to the peer router SHALL be dropped. The impact on destination hop counts are provided to the router by the modem as described above.
セッション更新メッセージでSuppress Forwardingデータアイテムを受信するモデムは、デバイス全体でマルチホップ転送を抑制しなければなりません（MUST）。つまり、モデムのピアルータから発信されたデータトラフィックは、モデムから1モデムホップ離れた宛先にのみ送信されるものとし（SHALL）、ピアルータに向けられていない別のモデムからモデムが受信したデータトラフィックはすべて破棄されるものとします。 。宛先ホップ数への影響は、上記のようにモデムによってルーターに提供されます。
A modem that receives the Suppress Forwarding Data Item in a Link Characteristics Request Message MUST suppress multi-hop forwarding for only the destination indicated in the message. This means that data traffic originating from the modem's peer router SHALL be sent by the modem to the destination indicated in the Link Characteristics Request Message only when it is one modem hop away. Notably, data traffic received by the modem from another modem can be forwarded by the modem per its normal processing. Results are provided as described above.
リンク特性要求メッセージでSuppress Forwarding Dataアイテムを受信するモデムは、メッセージで示された宛先のみのマルチホップ転送を抑制しなければなりません（MUST）。つまり、モデムのピアルータから発信されたデータトラフィックは、モデムが1ホップホップの場合にのみ、リンク特性要求メッセージに示された宛先にモデムによって送信される必要があります。特に、別のモデムからモデムが受信したデータトラフィックは、通常の処理に従ってモデムで転送できます。結果は上記のように提供されます。
The extension defined in this document enables the reporting and control of forwarding information by DLEP-capable modems. The extension does not inherently introduce any additional vulnerabilities above those documented in [RFC8175]. The approach taken to security in that document applies equally when running the extension defined in this document.
このドキュメントで定義されている拡張機能により、DLEP対応のモデムによる転送情報の報告と制御が可能になります。拡張機能は、[RFC8175]で文書化されている脆弱性を超える脆弱性を本質的にもたらしません。このドキュメントでセキュリティに採用されているアプローチは、このドキュメントで定義されている拡張機能を実行するときにも同様に適用されます。
The extension does define one mechanism that is worth particular note. It includes a Hop Control mechanism (see Section 3.2) that is similar to the Link Characteristics Request Message defined in [RFC8175] in that it can impact the set of destinations reported as reachable. With the Link Characteristics Request Message, this risk is implicit. With the Hop Control mechanism defined in this document, it is more likely. From a security perspective, implementations should be aware of this increased risk and may choose to implement additional configuration control mechanisms to ensure that the Hop Control mechanism is only used under conditions intended by the network operator.
エクステンションは、特に注目に値するメカニズムを1つ定義しています。 [RFC8175]で定義されているリンク特性要求メッセージと同様のホップ制御メカニズム（セクション3.2を参照）が含まれ、到達可能として報告される宛先のセットに影響を与えることができます。リンク特性要求メッセージでは、このリスクは暗黙的です。このドキュメントで定義されているホップ制御メカニズムにより、可能性が高くなります。セキュリティの観点から、実装ではこのリスクの増加を認識しておく必要があり、追加の構成制御メカニズムを実装して、ホップ制御メカニズムがネットワークオペレーターが意図した条件下でのみ使用されるようにすることができます。
Implementations of the extension defined in this document MUST support configuration of TLS usage, as described in [RFC8175], in order to protect configurations where injection attacks are possible, i.e., when the link between a modem and router is not otherwise protected.
このドキュメントで定義されている拡張機能の実装は、インジェクション攻撃が可能な構成を保護するために、つまりモデムとルーター間のリンクが他の方法で保護されていない場合に、[RFC8175]で説明されているようにTLS使用の構成をサポートする必要があります。
Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router or a switch that interconnects the modem and router. Similar attacks are generally possible for DLEP, for example, an impersonating modem may cause a session reset or cause a compromised modem to simply drop all traffic destined to, or sent by, a router. [RFC8175] defines the use of TLS to protect against the impersonating attacker.
この拡張により、侵害されたまたは偽装されたモデムが、ルーターまたはモデムとルーターを相互接続するスイッチによる送信を抑制することができることに注意してください。同様の攻撃がDLEPで一般的に可能です。たとえば、なりすましのモデムがセッションをリセットしたり、侵害されたモデムがルーター宛てまたはルーターから送信されたすべてのトラフィックを単純にドロップしたりする可能性があります。 [RFC8175]は、偽装攻撃者から保護するためのTLSの使用を定義しています。
As described below, IANA has assigned 3 values to registries defined by [RFC8175] and created a new registry.
以下で説明するように、IANAは[RFC8175]で定義されたレジストリに3つの値を割り当て、新しいレジストリを作成しました。
IANA has registered the following new value in the Specification Required range of the "Extension Type Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry.
IANAは、「Dynamic Link Exchange Protocol（DLEP）Parameters」レジストリ内の「Extension Type Values」レジストリの「Specification Required」範囲に次の新しい値を登録しました。
+------+----------------------+
| Code | Description |
+------+----------------------+
| 1 | Multi-Hop Forwarding |
+------+----------------------+
Table 2: Requested Extension Type Value
表2：要求された拡張タイプの値
IANA has registered the following 2 values in the Specification Required range of the "Data Item Type Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry.
IANAは、「Dynamic Link Exchange Protocol（DLEP）Parameters」レジストリ内の「Data Item Type Values」レジストリの「Specification Required」範囲に次の2つの値を登録しました。
+-----------+-------------+
| Type Code | Description |
+-----------+-------------+
| 21 | Hop Count |
| 22 | Hop Control |
+-----------+-------------+
Table 3: Requested Data Item Values
表3：要求されたデータアイテムの値
IANA has created the "Hop Control Actions Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. The following table provides initial registry values and the registration procedures [RFC8126] that apply:
IANAは、「Dynamic Link Exchange Protocol（DLEP）Parameters」レジストリ内に「Hop Control Actions Values」レジストリを作成しました。次の表は、レジストリの初期値と適用される登録手順[RFC8126]を示しています。
+-------------+------------------------+
| Value | Action/Policy |
+-------------+------------------------+
| 0 | Reset |
| 1 | Terminate |
| 2 | Direct Connection |
| 3 | Suppress Forwarding |
| 4-65519 | Specification Required |
| 65520-65534 | Private Use |
| 65535 | Reserved |
+-------------+------------------------+
Table 4: Hop Control Actions Values
表4：ホップ制御アクションの値
[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>。
[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>。
Acknowledgments
謝辞
Helpful comments were received from members of the MANET working group, including Henning Rogge, Victoria Pritchard, and David Wiggins.
ヘニングロッジ、ビクトリアプリチャード、デビッドウィギンズなどのMANETワーキンググループのメンバーから役立つコメントが寄せられました。
Authors' Addresses
著者のアドレス
Bow-Nan Cheng MIT Lincoln Laboratory Massachusetts Institute of Technology 244 Wood Street Lexington, MA 02421-6426
ボウナンチェンMITリンカーン研究所マサチューセッツ工科大学244 Wood Street Lexington、MA 02421-6426
Email: bcheng@ll.mit.edu
Lou Berger (editor) LabN Consulting, L.L.C.
ルーバーガー（編集者）LabN Consulting、L.L.C.
Email: lberger@labn.net