Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 9570 R. Bonica
Updates: 8029 Juniper Networks
Category: Standards Track G. Mirsky, Ed.
ISSN: 2070-1721 Ericsson
May 2024
The MPLS echo request and MPLS echo response messages, defined in RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to as LSP ping), are encapsulated in IP packets with headers that include a Router Alert Option (RAO). In actual deployments, the RAO was neither required nor used. Furthermore, RFC 6398 identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of using the MPLS echo request/reply as inter-area Operations, Administration, and Maintenance (OAM), and recommends against its use outside of controlled environments.
MPLSエコーリクエストとMPLSエコー応答メッセージは、RFC 8029で定義されており、「マルチプロトコルラベルスイッチ（MPLS）データプレーン障害の検出」（通常はLSP Pingと呼ばれます）は、Router Alertオプションを含むヘッダー付きのIPパケットにカプセル化されています。（ラオ）。実際の展開では、RAOは必要も使用もありませんでした。さらに、RFC 6398は、制御されていない環境でRAOに関連するセキュリティの脆弱性を特定します。制御された環境。
Therefore, this document retires the RAO for MPLS OAM and updates RFC 8029 to remove the RAO from LSP ping message encapsulations. Furthermore, this document explains why RFC 7506 has been reclassified as Historic.
したがって、このドキュメントはMPLS OAMのRAOを廃止し、RFC 8029を更新してLSP PingメッセージのカプセルからRAOを削除します。さらに、このドキュメントは、RFC 7506が歴史的として再分類された理由を説明しています。
Also, this document recommends the use of an IPv6 loopback address (::1/128) as the IPv6 destination address for an MPLS echo request message.
また、このドキュメントでは、MPLSエコーリクエストメッセージのIPv6宛先アドレスとしてIPv6ループバックアドレス（:: 1/128）を使用することを推奨しています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9570.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9570で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Router Alert for LSP Ping (RFC 8029)
2.1. MPLS Echo Request
2.2. MPLS Echo Reply
3. Reclassification of RFC 7506 as Historic
4. Update to RFC 8029
5. Backwards Compatibility
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to as LSP ping) [RFC8029] detects data plane failures in MPLS Label Switched Paths (LSPs). It can operate in "ping mode" or "traceroute mode." When operating in ping mode, it checks LSP connectivity. When operating in traceroute mode, it can trace an LSP and localize failures to a particular node along an LSP.
「マルチプロトコルラベルの切り替え（MPLS）データプレーン障害の検出」（通常はLSP Pingと呼ばれる）[RFC8029]は、MPLSラベルスイッチ付きパス（LSP）のデータプレーン障害を検出します。「Pingモード」または「Tracerouteモード」で動作できます。Pingモードで動作する場合、LSP接続をチェックします。Tracerouteモードで動作する場合、LSPをトレースし、LSPに沿って特定のノードに障害をローカライズすることができます。
The reader is assumed be familiar with [RFC8029] and its terminology.
読者は[RFC8029]とその用語に精通していると想定されています。
LSP ping defines a probe message called the "MPLS echo request." It also defines a response message called the "MPLS echo reply." Both messages are encapsulated in UDP and IP. The MPLS echo request message is further encapsulated in an MPLS label stack, except when all of the Forwarding Equivalency Classes in the stack correspond to Implicit Null labels.
LSP Pingは、「MPLSエコーリクエスト」と呼ばれるプローブメッセージを定義します。また、「MPLSエコー応答」と呼ばれる応答メッセージも定義します。両方のメッセージは、UDPとIPでカプセル化されています。MPLSエコー要求メッセージは、スタック内のすべての転送等価クラスが暗黙のヌルラベルに対応する場合を除き、MPLSラベルスタックにさらにカプセル化されます。
When operating in ping mode, LSP ping sends a single MPLS echo request message, with the MPLS TTL set to 255. This message is intended to reach the egress Label Switching Router (LSR). When operating in traceroute mode, MPLS ping sends multiple MPLS echo request messages as defined in Section 4.3 of [RFC8029]. It manipulates the MPLS TTL so that the first message expires on the first LSR along the path, and subsequent messages expire on subsequent LSRs.
Pingモードで動作する場合、LSP PingはMPLS TTLが255に設定された単一のMPLSエコー要求メッセージを送信します。このメッセージは、出口ラベルスイッチングルーター（LSR）に到達することを目的としています。Tracerouteモードで動作する場合、MPLS Pingは[RFC8029]のセクション4.3で定義されているように、複数のMPLSエコー要求メッセージを送信します。MPLS TTLを操作して、最初のメッセージがパスに沿った最初のLSRで期限切れになり、その後のメッセージがその後のLSRで期限切れになります。
According to [RFC8029], the IP header that encapsulates an MPLS echo request message must include a Router Alert Option (RAO). Furthermore, [RFC8029] also says that the IP header that encapsulates an MPLS echo reply message must include an RAO if the value of the Reply Mode in the corresponding MPLS echo request message is "Reply via an IPv4/IPv6 UDP packet with Router Alert." This document explains why an RAO was not needed in both cases. Furthermore, [RFC6398] identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of using the MPLS echo request/reply as inter-domain OAM over the public Internet, and recommends against its use outside of controlled environments, e.g., outside a single administrative domain.
[RFC8029]によると、MPLSエコー要求メッセージをカプセル化するIPヘッダーには、ルーターアラートオプション（RAO）を含める必要があります。さらに、[RFC8029]は、MPLSエコーの応答メッセージをカプセル化するIPヘッダーには、対応するMPLSエコーリクエストメッセージの返信モードの値が「ルーターアラート付きIPv4/IPv6 UDPパケットを介して返信」である場合、RAOを含める必要があると述べています。「このドキュメントでは、両方の場合にRaoが必要でなかった理由を説明しています。さらに、[RFC6398]は、制御されていない環境でRAOに関連するセキュリティの脆弱性を特定します。たとえば、単一の管理ドメインの外側。
Therefore, this document updates RFC 8029 [RFC8029] to retire the RAO from both LSP ping message encapsulations and explains why RFC 7506 [RFC7506] has been reclassified as Historic.
したがって、このドキュメントはRFC 8029 [RFC8029]を更新して、両方のLSP PingメッセージのカプセルからRAOを廃止し、RFC 7506 [RFC7506]が歴史的として再分類された理由を説明します。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
While the MPLS echo request message must traverse every node in the LSP under test, it must not traverse any other nodes. Specifically, the message must not be forwarded beyond the egress Label Switching Router (LSR). To achieve this, a set of the mechanisms that are used concurrently to prevent leaking MPLS echo request messages has been defined in [RFC8029]:
MPLSエコー要求メッセージは、テスト中のLSP内のすべてのノードを通過する必要がありますが、他のノードを通過してはなりません。具体的には、メッセージは、出力ラベルスイッチングルーター（LSR）を超えて転送してはなりません。これを達成するために、MPLSエコーリクエストメッセージの漏れを防ぐために同時に使用される一連のメカニズムが[RFC8029]で定義されています。
1. When the MPLS echo request message is encapsulated in IPv4, the IPv4 destination address must be chosen from the subnet 127/8. When the MPLS echo request message is encapsulated in IPv6, the IPv6 destination address must be chosen from the subnet 0:0:0:0:0:FFFF:7F00:0/104.
1. MPLSエコー要求メッセージがIPv4にカプセル化される場合、IPv4宛先アドレスをサブネット127/8から選択する必要があります。MPLSエコーリクエストメッセージがIPv6にカプセル化される場合、IPv6宛先アドレスはサブネット0：0：0：0：0：FFFF：7F00：0/104から選択する必要があります。
2. When the MPLS echo request message is encapsulated in IPv4, the IPv4 TTL must be equal to 1. When the MPLS echo request message is encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1. For further information on the encoding of the TTL / Hop Limit in an MPLS echo request message, see Section 4.3 of [RFC8029].
2. MPLSエコー要求メッセージがIPv4にカプセル化される場合、IPv4 TTLは1に等しくなければなりません。MPLSエコーリクエストメッセージがIPv6でカプセル化されている場合、IPv6ホップ制限は1に等しくなければなりません。/ MPLSエコーリクエストメッセージのホップ制限[RFC8029]のセクション4.3を参照してください。
3. When the MPLS echo request message is encapsulated in IPv4, the IPv4 header must include an RAO with the option value set to "Router shall examine packet" [RFC2113]. When the MPLS echo request message is encapsulated in IPv6, the IPv6 header chain must include a hop-by-hop extension header and the hop-by-hop extension header must include an RAO with the option value set to MPLS OAM [RFC7506].
3. MPLSエコーリクエストメッセージがIPv4にカプセル化される場合、IPv4ヘッダーには、「ルーターにパケットを調べなければならない」オプション値を備えたRAOを含める必要があります[RFC2113]。MPLSエコーリクエストメッセージがIPv6にカプセル化される場合、IPv6ヘッダーチェーンにはホップバイホップ拡張ヘッダーを含める必要があり、ホップバイホップエクステンションヘッダーには、MPLS OAM [RFC7506]に設定されたオプション値を持つRAOを含める必要があります。
Currently, all of these are required. However, any one is sufficient to prevent forwarding the packet beyond the egress LSR.
現在、これらはすべて必要です。ただし、Egress LSRを超えてパケットの転送を防ぐのに十分な人はいます。
Therefore, this document updates RFC 8029 [RFC8029] in that Requirement 3 is removed.
したがって、このドキュメントは、要件3が削除されたRFC 8029 [RFC8029]を更新します。
No implementation that relies on the RAO to prevent packets from being forwarded beyond the egress LSR has been reported to the MPLS Working Group.
RAOに依存する実装は、出口LSRを超えてパケットが転送されないようにしていないため、MPLSワーキンググループに報告されています。
An LSP ping replies to the MPLS echo request message with an MPLS echo reply message. Four reply modes are defined in [RFC8029]:
MPLSエコーエコー応答メッセージを使用して、MPLSエコーリクエストメッセージにlsp pingが応答します。4つの返信モードは[RFC8029]で定義されています。
1. Do not reply
1. 返信しないでください
2. Reply via an IPv4/IPv6 UDP packet
2. IPv4/IPv6 UDPパケットを介して返信します
3. Reply via an IPv4/IPv6 UDP packet with Router Alert
3. ルーターアラート付きIPv4/IPv6 UDPパケットを介して返信
4. Reply via application-level control channel
4. アプリケーションレベルの制御チャネルを介して返信します
The rationale for mode 3 is questionable, if not wholly misguided. According to RFC 8029 [RFC8029], "If the normal IP return path is deemed unreliable, one may use 3 (Reply via an IPv4/IPv6 UDP packet with Router Alert)."
モード3の理論的根拠は、完全に見当違いではないにしても、疑わしいです。RFC 8029 [RFC8029]によると、「通常のIPリターンパスが信頼できないとみなされる場合、3を使用できます（Router Alertを備えたIPv4/IPv6 UDPパケット）。」
However, it is not clear that the use of the RAO increases the reliability of the return path. In fact, one can argue it decreases the reliability in many instances, due to the additional burden of processing the RAO. This document updates RFC 8029 [RFC8029] in that mode 3 is removed.
ただし、RAOを使用すると、リターンパスの信頼性が向上することは明らかではありません。実際、RAOを処理する追加の負担により、多くの場合、それが信頼性を低下させると主張することができます。このドキュメントは、そのモード3でRFC 8029 [RFC8029]を更新します。
No implementations of mode 3 have been reported to the MPLS Working Group.
MPLSワーキンググループにモード3の実装は報告されていません。
RFC 7506 [RFC7506] defines the IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance. This document explains why RFC 7506 [RFC7506] has been reclassified as Historic.
RFC 7506 [RFC7506] MPLS操作、管理、およびメンテナンスのIPv6ルーターアラートオプションを定義します。このドキュメントは、RFC 7506 [RFC7506]が歴史的として再分類された理由を説明しています。
[RFC8029] requires that the IPv6 Destination Address used in IP/UDP encapsulation of an MPLS echo request packet be selected from the IPv4 loopback address range mapped to IPv6. Such packets do not have the same behavior as prescribed in [RFC1122] for an IPv4 loopback addressed packet.
[RFC8029]は、MPLSエコーリクエストパケットのIP/UDPカプセル化で使用されるIPv6宛先アドレスを、IPv6にマッピングしたIPv4ループバックアドレス範囲から選択することを要求しています。このようなパケットは、IPv4ループバックアドレス指定されたパケットについて[RFC1122]で規定されているのと同じ動作を持っていません。
[RFC4291] defines ::1/128 as the single IPv6 loopback address. Considering that, this specification updates Section 2.1 of [RFC8029] regarding the selection of an IPv6 destination address for an MPLS echo request message as follows:
[RFC4291] :: 1/128を単一のIPv6ループバックアドレスとして定義します。それを考慮して、この仕様は、MPLSエコー要求メッセージのIPv6宛先アドレスの選択に関する[RFC8029]のセクション2.1を次のように更新します。
OLD:
OLD:
The 127/8 range for IPv4 and that same range embedded in an IPv4-mapped IPv6 address for IPv6 was chosen for a number of reasons.
IPv4の127/8範囲と、IPv6のIPv4-Mapped IPv6アドレスに埋め込まれた同じ範囲が、いくつかの理由で選択されました。
RFC 1122 allocates the 127/8 as the "Internal host loopback address" and states: "Addresses of this form MUST NOT appear outside a host." Thus, the default behavior of hosts is to discard such packets. This helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded.
RFC 1122は、127/8を「内部ホストループバックアドレス」として割り当て、次のように述べています。「このフォームのアドレスはホストの外に表示されてはなりません」。したがって、ホストのデフォルトの動作は、そのようなパケットを破棄することです。これにより、診断パケットがホストに誤った方向に向けられている場合、静かに廃棄されるようになります。
RFC 1812 [RFC1812] states:
RFC 1812 [RFC1812]状態：
A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.
ルーターは、ネットワーク127に宛先アドレスを持つパケットを除いて、ループバックインターフェイスを除いて転送してはなりません。ルーターには、ネットワークマネージャーがこれらのチェックを無効にできるスイッチがある場合があります。そのようなスイッチが提供されている場合、デフォルトでチェックを実行する必要があります。
This helps to ensure that diagnostic packets are never IP forwarded.
これにより、診断パケットがIP転送されないようにするのに役立ちます。
The 127/8 address range provides 16M addresses allowing wide flexibility in varying addresses to exercise ECMP paths. Finally, as an implementation optimization, the 127/8 range provides an easy means of identifying possible LSP packets.
127/8のアドレス範囲は16mのアドレスを提供し、さまざまなアドレスで幅広い柔軟性を可能にし、ECMPパスを行使します。最後に、実装の最適化として、127/8の範囲は、可能なLSPパケットを識別する簡単な手段を提供します。
NEW:
NEW:
The 127/8 range for IPv4 was chosen for a number of reasons.
IPv4の127/8の範囲は、いくつかの理由で選択されました。
RFC 1122 [RFC1122] allocates the 127/8 as the "Internal host loopback address" and states: "Addresses of this form MUST NOT appear outside a host." Thus, the default behavior of hosts is to discard such packets. This helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded.
RFC 1122 [RFC1122]は、127/8を「内部ホストループバックアドレス」として割り当て、次のように述べています。「このフォームのアドレスはホストの外に表示されてはなりません」。したがって、ホストのデフォルトの動作は、そのようなパケットを破棄することです。これにより、診断パケットがホストに誤った方向に向けられている場合、静かに廃棄されるようになります。
RFC 1812 [RFC1812] states:
RFC 1812 [RFC1812]状態：
A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.
ルーターは、ネットワーク127に宛先アドレスを持つパケットを除いて、ループバックインターフェイスを除いて転送してはなりません。ルーターには、ネットワークマネージャーがこれらのチェックを無効にできるスイッチがある場合があります。そのようなスイッチが提供されている場合、デフォルトでチェックを実行する必要があります。
This helps to ensure that diagnostic packets are never IP forwarded.
これにより、診断パケットがIP転送されないようにするのに役立ちます。
The 127/8 address range provides 16M addresses allowing wide flexibility in varying addresses to exercise ECMP paths. Finally, as an implementation optimization, the 127/8 range provides an easy means of identifying possible LSP packets.
127/8のアドレス範囲は16mのアドレスを提供し、さまざまなアドレスで幅広い柔軟性を可能にし、ECMPパスを行使します。最後に、実装の最適化として、127/8の範囲は、可能なLSPパケットを識別する簡単な手段を提供します。
The IPv6 destination address for an MPLS echo request message is selected as follows:
MPLSエコーリクエストメッセージのIPv6宛先アドレスは、次のように選択されます。
* The IPv6 loopback address ::1/128 SHOULD be used.
* IPv6ループバックアドレス:: 1/128を使用する必要があります。
* The sender of an MPLS echo request MAY select the IPv6 destination address from the 0:0:0:0:0:FFFF:7F00/104 range.
* MPLSエコー要求の送信者は、0：0：0：0：0：FFFF：7F00/104範囲からIPv6宛先アドレスを選択できます。
* To exercise all paths in an ECMP environment, the source of entropy other than the IP destination address SHOULD be used. For example, the MPLS Entropy Label [RFC6790] or IPv6 Flow Label [RFC6438] can be used as the source of entropy.
* ECMP環境ですべてのパスを行使するには、IP宛先アドレス以外のエントロピーのソースを使用する必要があります。たとえば、MPLSエントロピーラベル[RFC6790]またはIPv6フローラベル[RFC6438]は、エントロピーの原因として使用できます。
Additionally, this specification updates Section 2.2 of [RFC8029] to replace the whole of the section with the following text:
さらに、この仕様は[RFC8029]のセクション2.2を更新して、セクション全体を次のテキストに置き換えます。
LSP Ping implementations SHOULD ignore RAO options when they arrive on incoming MPLS echo request and MPLS echo reply messages.
LSP Pingの実装は、RAOオプションが着信MPLSエコーリクエストに到着し、MPLSエコーエコー応答メッセージを無視する必要があります。
Resulting from the removal of the Reply mode 3 "Reply via an IPv4/ IPv6 UDP packet with Router Alert" (see Section 2.2), this specification updates Section 4.5 of [RFC8029] by removing the following text:
応答モードの削除3「ルーターアラートを備えたIPv4/ IPv6 UDPパケット」（セクション2.2を参照）を介して「応答」（セクション2.2を参照）の結果、この仕様は次のテキストを削除して[RFC8029]のセクション4.5を更新します。
If the Reply Mode in the echo request is "Reply via an IPv4 UDP packet with Router Alert", then the IP header MUST contain the Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69 [RFC7506] for IPv6. If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [RFC3032]).
エコー要求の返信モードが「ルーターアラートを備えたIPv4UDPパケットを介して返信」である場合、IPヘッダーには、IPv4または69 [RFC7506]の値0x0 [RFC2113]のルーターアラートIPオプションをIPV6の値0x0 [RFC2113]に含める必要があります。返信がLSPを介して送信された場合、この場合、最上位ラベルはルーターアラートラベル（1）でなければなりません（[RFC3032]を参照）。
Furthermore, this specification updates Section 4.3 of [RFC8029] as follows:
さらに、この仕様は[RFC8029]のセクション4.3を次のように更新します。
OLD:
OLD:
The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value 69 [RFC7506] for IPv6 MUST be set in the IP header.
IPv4の値0x0 [RFC2113]のルーターアラートIPオプションまたはIPv6の値69 [RFC7506]は、IPヘッダーに設定する必要があります。
NEW:
NEW:
The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value 69 [RFC7506] for IPv6 MUST NOT be set in the IP header.
IPv4の値0x0 [RFC2113]のルーターアラートIPオプションまたはIPv6の値69 [RFC7506]は、IPヘッダーに設定してはなりません。
LSP Ping implementations that conform to this specification SHOULD ignore RAO options when they arrive on incoming MPLS echo request and MPLS echo reply messages. However, this will not harm backwards compatibility because other mechanisms will also be in use by all legacy implementations in the messages they send and receive.
この仕様に準拠するLSP Ping実装は、受信MPLSエコーリクエストに到着したときにRAOオプションを無視する必要があり、MPLSエコーエコー応答メッセージが表示されます。ただし、他のメカニズムが送信および受信するメッセージのすべてのレガシー実装によっても使用されるため、これは後方互換性を害しません。
Section 6 of this document deprecates the IPv6 RAO value for MPLS OAM (69) in [IANA-IPV6-RAO] and the Reply Mode 3 ("Reply via an IPv4/IPv6 UDP packet with Router Alert") in [IANA-LSP-PING].
このドキュメントのセクション6は、[IANA-IPV6-RAO]のMPLS OAM（69）のIPv6 RAO値とReply Mode 3（ "IANA-LSP-のRouter Alertを備えたIPv4/IPv6 UDPパケットを介して返信する"）を廃止します。ping]。
[RFC8126] offers a formal description of the word "Deprecated". In this context, "Deprecated" means that the deprecated values SHOULD NOT be used in new implementations, and that deployed implementations that already use these values continue to work seamlessly.
[RFC8126]は、「非推奨」という言葉の正式な説明を提供します。この文脈では、「非推奨」とは、非推奨の値を新しい実装で使用すべきではなく、すでにこれらの値を使用している展開された実装がシームレスに機能し続けることを意味します。
IANA has marked the IPv6 RAO value of MPLS OAM (69) in [IANA-IPV6-RAO] as "DEPRECATED".
IANAは、[IANA-IPV6-RAO]のMPLS OAM（69）のIPv6 RAO値を「非推奨」としてマークしました。
IANA has marked Reply Mode 3 ("Reply via an IPv4/IPv6 UDP packet with Router Alert") in "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" [IANA-LSP-PING] as "DEPRECATED".
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）Pingパラメーター」[IANA-LSP-PING]の「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパラメーター」の応答モード3（「ルーターアラートを備えたIPv4/IPv6 UDPパケットを介して返信」）をマークしました。
The recommendations this document makes do not compromise security. Using the IPv6 loopback address ::1/128 strengthens security for LSP ping because it is standardized and has well-defined behavior.
このドキュメントが作成する推奨事項は、セキュリティを妥協しません。IPv6ループバックアドレスを使用する:: 1/128 LSP Pingのセキュリティは標準化されており、明確に定義された動作があるため、セキュリティを強化します。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997,
<https://www.rfc-editor.org/info/rfc2113>.
[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>.
[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>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
Option for MPLS Operations, Administration, and
Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April
2015, <https://www.rfc-editor.org/info/rfc7506>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[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>.
[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>.
[IANA-IPV6-RAO]
IANA, "IPv6 Router Alert Option Values",
<https://www.iana.org/assignments/ipv6-routeralert-
values>.
[IANA-LSP-PING]
IANA, "Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs) Ping Parameters",
<https://www.iana.org/assignments/mpls-lsp-ping-
parameters>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
The authors express their appreciation to Adrian Farrel and Gyan Mishra for their suggestions that improved the readability of the document.
著者は、ドキュメントの読みやすさを改善するという提案について、エイドリアン・ファレルとギャン・ミシュラに感謝を表明します。
Kireeti Kompella
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: kireeti.ietf@gmail.com
Ron Bonica
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: rbonica@juniper.net
Greg Mirsky (editor)
Ericsson
Email: gregimirsky@gmail.com