[要約] RFC 7439は、IPv6-Only MPLSネットワークの運用におけるギャップ分析を行うためのものであり、IPv6のみを使用するMPLSネットワークの運用における課題と解決策を提供することを目的としています。
Internet Engineering Task Force (IETF) W. George, Ed.
Request for Comments: 7439 Time Warner Cable
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 Cisco
January 2015
Gap Analysis for Operating IPv6-Only MPLS Networks
IPv6のみのMPLSネットワークを運用するためのギャップ分析
Abstract
概要
This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.
このドキュメントでは、IPv6のコンテキストでマルチプロトコルラベルスイッチング（MPLS）プロトコルスイートを確認し、MPLS関連のプロトコルとアプリケーションをIPv6のみのネットワークで使用できるようにするために対処する必要があるギャップを特定します。このドキュメントは、MPLSスイートを定義する標準のギャップに焦点を当てることを意図しており、IPv6のみのMPLS機能のコンテキストで特定のベンダーの実装（またはその欠如）を強調することを意図していません。
In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.
データプレーンでは、MPLSはIPv6を完全にサポートしており、MPLSラベル付きパケットは、さまざまなカプセル化でIPv6パケットを介して伝送できます。ただし、MPLSコントロールプレーンプロトコル、MPLSアプリケーション、MPLS運用、管理、および保守（OAM）、およびMIBモジュール間のIPv6のサポートは混合されており、一部のプロトコルには大きなギャップがあります。ほとんどの主要なギャップについて、関連するプロトコルをアップグレードする作業が進行中です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7439.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7439で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 6
3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 6
3.2.1. Label Distribution Protocol (LDP) . . . . . . . . . . 6
3.2.2. Multipoint LDP (mLDP) . . . . . . . . . . . . . . . . 6
3.2.3. RSVP - Traffic Engineering (RSVP-TE) . . . . . . . . 7
3.2.3.1. Interior Gateway Protocol (IGP) . . . . . . . . . 8
3.2.3.2. RSVP-TE Point-to-Multipoint (P2MP) . . . . . . . 8
3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 8
3.2.4. Path Computation Element (PCE) . . . . . . . . . . . 8
3.2.5. Border Gateway Protocol (BGP) . . . . . . . . . . . . 9
3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) . 9
3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Layer 2 Virtual Private Network (L2VPN) . . . . . . . 9
3.3.1.1. Ethernet VPN (EVPN) . . . . . . . . . . . . . . . 10
3.3.2. Layer 3 Virtual Private Network (L3VPN) . . . . . . . 10
3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) . 11
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual
Private Extension (6VPE/4VPE) . . . . . . . . . . 11
3.3.2.3. BGP Encapsulation Subsequent Address Family
Identifier (SAFI) . . . . . . . . . . . . . . . . 12
3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . . 12
3.3.3. MPLS Transport Profile (MPLS-TP) . . . . . . . . . . 13
3.4. MPLS Operations, Administration, and Maintenance (MPLS
OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Label Switched Path Ping (LSP Ping) . . . . . . . . . 15
3.4.3. Bidirectional Forwarding Detection (BFD) . . . . . . 16
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 16
3.4.5. MPLS Transport Profile (MPLS-TP) OAM . . . . . . . . 16
3.5. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 17
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
IPv6 [RFC2460] is an integral part of modern network deployments. At the time when this document was written, the majority of these IPv6 deployments were using dual-stack implementations, where IPv4 and IPv6 are supported equally on many or all of the network nodes, and single-stack primarily referred to IPv4-only devices. Dual-stack deployments provide a useful margin for protocols and features that are not currently capable of operating solely over IPv6, because they can continue using IPv4 as necessary. However, as IPv6 deployment and usage becomes more pervasive, and IPv4 exhaustion begins driving changes in address consumption behaviors, there is an increasing likelihood that many networks will need to start operating some or all of their network nodes either as primarily IPv6 (most functions use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 provisioned on the device). This transition toward IPv6-only operation exposes any gaps where features, protocols, or implementations are still reliant on IPv4 for proper function. To that end, and in the spirit of the recommendation in RFC 6540 [RFC6540] that implementations need to stop requiring IPv4 for proper and complete function, this document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks and networks that are primarily IPv6 (hereafter referred to as IPv6-primary). This document is intended to focus on gaps in the standards defining the MPLS suite, and not to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.
IPv6 [RFC2460]は、最新のネットワーク導入に不可欠な要素です。このドキュメントが作成された時点では、これらのIPv6展開の大部分はデュアルスタック実装を使用しており、IPv4とIPv6はネットワークノードの多くまたはすべてで同等にサポートされ、シングルスタックは主にIPv4専用デバイスと呼ばれていました。デュアルスタック展開は、必要に応じてIPv4の使用を継続できるため、現在IPv6でのみ動作することができないプロトコルと機能に有用なマージンを提供します。ただし、IPv6の導入と使用がより広範になり、IPv4の枯渇がアドレス消費動作の変化を引き起こし始めているため、多くのネットワークが、主にIPv6として（ほとんどの機能が使用する）ネットワークノードの一部またはすべてを動作させる必要がある可能性が高まっています。 IPv6、いくつかのレガシー機能はIPv4を使用します）、またはIPv6のみとして（デバイスにIPv4がプロビジョニングされていません）。このIPv6のみの動作への移行により、機能、プロトコル、または実装が適切な機能を実現するためにIPv4に依存しているギャップが明らかになります。そのため、RFC 6540 [RFC6540]の推奨の精神に基づいて、実装は適切かつ完全な機能のためにIPv4の要求を停止する必要があると述べ、このドキュメントはIPv6のコンテキストでMPLSプロトコルスイートをレビューし、対処する必要のあるギャップを特定しますMPLS関連のプロトコルとアプリケーションをIPv6のみのネットワークおよび主にIPv6であるネットワーク（以降、IPv6-primaryと呼ぶ）で使用できるようにするため。このドキュメントは、MPLSスイートを定義する標準のギャップに焦点を当て、IPv6のみのMPLS機能のコンテキストで特定のベンダーの実装（またはその欠如）を強調することを目的としていません。
This section discusses some drivers for ensuring that MPLS completely supports IPv6-only operation. It is not intended to be a comprehensive discussion of all potential use cases, but rather a discussion of one use case to provide context and justification to undertake such a gap analysis.
このセクションでは、MPLSがIPv6のみの操作を完全にサポートするようにするためのいくつかのドライバーについて説明します。これは、すべての潜在的なユースケースの包括的な議論ではなく、そのようなギャップ分析を行うためのコンテキストと正当性を提供する1つのユースケースの議論です。
IP convergence is continuing to drive new classes of devices to begin communicating via IP. Examples of such devices could include set-top boxes for IP video distribution, cell tower electronics (macro or micro cells), infrastructure Wi-Fi access points, and devices for machine-to-machine (M2M) or Internet of Things (IoT) applications. In some cases, these classes of devices represent a very large deployment base, on the order of thousands or even millions of devices network-wide. The scale of these networks, coupled with the increasingly overlapping use of RFC 1918 [RFC1918] address space within the average network and the lack of globally routable IPv4 space available for long-term growth, begins to drive the need for many of the endpoints in this network to be managed solely via IPv6. Even if these devices are carrying some IPv4 user data, it is often encapsulated in another protocol such that the communication between the endpoint and its upstream devices can be IPv6-only without impacting support for IPv4 on user data. As the number of devices to manage increases, the operator is compelled to move to IPv6. Depending on the MPLS features required, it is plausible to assume that the (existing) MPLS network will need to be extended to these IPv6-only devices.
IPコンバージェンスは、IPを介した通信を開始するデバイスの新しいクラスを推進し続けています。このようなデバイスの例には、IPビデオ配信用のセットトップボックス、セルタワーエレクトロニクス（マクロまたはマイクロセル）、インフラストラクチャWi-Fiアクセスポイント、およびマシン間（M2M）またはモノのインターネット（IoT）用のデバイスが含まれます。アプリケーション。場合によっては、これらのクラスのデバイスは、ネットワーク全体で数千または数百万のオーダーの非常に大規模な展開ベースを表します。これらのネットワークの規模は、平均的なネットワーク内でのRFC 1918 [RFC1918]アドレス空間の使用がますます重複し、長期的な成長に利用できるグローバルにルーティング可能なIPv4空間の欠如と相まって、多くのエンドポイントの必要性を高め始めています。このネットワークはIPv6のみで管理されます。これらのデバイスが一部のIPv4ユーザーデータを伝送している場合でも、エンドポイントとそのアップストリームデバイス間の通信がIPv6のみでユーザーデータのIPv4のサポートに影響を与えないように、別のプロトコルでカプセル化されることがよくあります。管理するデバイスの数が増えると、オペレーターはIPv6への移行を余儀なくされます。必要なMPLS機能によっては、（既存の）MPLSネットワークをこれらのIPv6専用デバイスに拡張する必要があると想定するのがもっともです。
Additionally, as the impact of IPv4 exhaustion becomes more acute, more and more aggressive IPv4 address reclamation measures will be justified. Many networks are likely to focus on preserving their remaining IPv4 addresses for revenue-generating customers so that legacy support for IPv4 can be maintained as long as necessary. As a result, it may be appropriate for some or all of the network infrastructure, including MPLS Label Switching Routers (LSRs) and Label Edge Routers (LERs), to have its IPv4 addresses reclaimed and transition toward IPv6-only operation.
さらに、IPv4枯渇の影響がより深刻になるにつれて、より積極的なIPv4アドレス再利用対策が正当化されるようになります。多くのネットワークは、収益を生み出す顧客のために残りのIPv4アドレスを維持することに焦点を当てている可能性が高いため、IPv4のレガシーサポートを必要なだけ維持できます。その結果、MPLSラベルスイッチングルーター（LSR）やラベルエッジルーター（LER）を含むネットワークインフラストラクチャの一部またはすべてが、IPv4アドレスを再利用してIPv6のみの動作に移行することが適切な場合があります。
This gap analysis aims to answer the question of what fails when one attempts to use MPLS features on a network of IPv6-only devices. The baseline assumption for this analysis is that some endpoints, as well as Label Switching Routers (Provider Edge (PE) and Provider (P) routers), only have IPv6 transport available and need to support the full suite of MPLS features defined as of the time of this document's writing at parity with the support on an IPv4 network. This is necessary whether they are enabled via the Label Distribution Protocol (LDP) [RFC5036], RSVP - Traffic Engineering (RSVP-TE) [RFC3209], or Border Gateway Protocol (BGP) [RFC3107], and whether they are encapsulated in MPLS [RFC3032], IP [RFC4023], Generic Routing Encapsulation (GRE) [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) [RFC4817]. It is important when evaluating these gaps to distinguish between user data and control-plane data, because while this document is focused on IPv6-only operation, it is quite likely that some amount of the user payload data being carried in the IPv6-only MPLS network will still be IPv4.
このギャップ分析は、IPv6のみのデバイスのネットワークでMPLS機能を使用しようとしたときに何が失敗するかという質問に答えることを目的としています。この分析の基本的な前提は、一部のエンドポイントとラベルスイッチングルーター（プロバイダーエッジ（PE）とプロバイダー（P）ルーター）はIPv6トランスポートのみを使用でき、の時点で定義されているMPLS機能の完全なスイートをサポートする必要があるということです。このドキュメントの執筆時点で、IPv4ネットワークのサポートと同等です。これは、ラベル配布プロトコル（LDP）[RFC5036]、RSVP-トラフィックエンジニアリング（RSVP-TE）[RFC3209]、またはボーダーゲートウェイプロトコル（BGP）[RFC3107]によって有効にされているかどうか、およびMPLSにカプセル化されているかどうかに必要です。 [RFC3032]、IP [RFC4023]、Generic Routing Encapsulation（GRE）[RFC4023]、またはレイヤー2トンネリングプロトコルバージョン3（L2TPv3）[RFC4817]。これらのギャップを評価する場合、ユーザーデータとコントロールプレーンデータを区別することが重要です。このドキュメントではIPv6のみの操作に焦点を当てていますが、IPv6のみのMPLSで運ばれるユーザーペイロードデータの一部は、ネットワークはIPv4のままです。
A note about terminology: Gaps identified by this document are characterized as "Major" or "Minor". Major gaps refer to significant changes necessary in one or more standards to address the gap due to existing standards language having either missing functionality for IPv6-only operation or explicit language requiring the use of IPv4 with no IPv6 alternatives defined. Minor gaps refer to changes necessary primarily to clarify existing standards language. Usually these changes are needed in order to explicitly codify IPv6 support in places where it is either implicit or omitted today, but the omission is unlikely to prevent IPv6-only operation.
用語に関する注記：このドキュメントで識別されるギャップは、「メジャー」または「マイナー」として特徴付けられます。主要なギャップとは、既存の標準言語にIPv6のみの操作の機能がないか、IPv6の代替が定義されていないIPv4の使用を必要とする明示的な言語によるギャップに対処するために1つ以上の標準で必要な大幅な変更を指します。小さなギャップとは、主に既存の標準言語を明確にするために必要な変更を指します。通常、これらの変更は、今日暗黙的または省略されている場所でIPv6サポートを明示的にコード化するために必要ですが、省略してもIPv6のみの操作が妨げられることはほとんどありません。
MPLS labeled packets can be transmitted over a variety of data links [RFC3032], and MPLS labeled packets can also be encapsulated over IP. The encapsulations of MPLS in IP and GRE, as well as MPLS over L2TPv3, support IPv6. See Section 3 of RFC 4023 [RFC4023] and Section 2 of RFC 4817 [RFC4817], respectively.
MPLSラベル付きパケットはさまざまなデータリンク[RFC3032]を介して送信でき、MPLSラベル付きパケットはIPを介してカプセル化することもできます。 IPおよびGREでのMPLSのカプセル化、およびL2TPv3上のMPLSは、IPv6をサポートします。 RFC 4023 [RFC4023]のセクション3とRFC 4817 [RFC4817]のセクション2をそれぞれ参照してください。
Gap: None.
ギャップ：なし。
The Label Distribution Protocol (LDP) [RFC5036] defines a set of procedures for distribution of labels between Label Switching Routers that can use the labels for forwarding traffic. While LDP was designed to use an IPv4 or dual-stack IP network, it has a number of deficiencies that prevent it from working in an IPv6-only network. LDP-IPv6 [LDP-IPv6] highlights some of the deficiencies when LDP is enabled in IPv6-only or dual-stack networks and specifies appropriate protocol changes. These deficiencies are related to Label Switched Path (LSP) mapping, LDP identifiers, LDP discovery, LDP session establishment, next-hop address, and LDP Time To Live (TTL) security [RFC5082] [RFC6720].
ラベル配布プロトコル（LDP）[RFC5036]は、トラフィックを転送するためにラベルを使用できるラベルスイッチングルータ間でラベルを配布するための一連の手順を定義しています。 LDPはIPv4またはデュアルスタックIPネットワークを使用するように設計されていますが、IPv6のみのネットワークで機能することを妨げるいくつかの欠陥があります。 LDP-IPv6 [LDP-IPv6]は、IPv6のみまたはデュアルスタックネットワークでLDPが有効になっている場合のいくつかの欠点を強調し、適切なプロトコル変更を指定します。これらの欠陥は、Label Switched Path（LSP）マッピング、LDP識別子、LDPディスカバリ、LDPセッションの確立、ネクストホップアドレス、およびLDP Time To Live（TTL）セキュリティ[RFC5082] [RFC6720]に関連しています。
Gap: Major; update to RFC 5036 in progress via [LDP-IPv6], which should close this gap.
ギャップ：メジャー。 [LDP-IPv6]を介して進行中のRFC 5036への更新。このギャップを埋める必要があります。
Multipoint LDP (mLDP) is a set of extensions to LDP for setting up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) LSPs. These extensions are specified in RFC 6388 [RFC6388]. In terms of IPv6-only gap analysis, mLDP has two identified areas of interest:
マルチポイントLDP（mLDP）は、ポイントツーマルチポイント（P2MP）およびマルチポイントツーマルチポイント（MP2MP）LSPを設定するためのLDPの拡張セットです。これらの拡張はRFC 6388 [RFC6388]で指定されています。 IPv6のみのギャップ分析に関して、mLDPには2つの特定の関心領域があります。
1. LDP Control Plane: Since mLDP uses the LDP control plane to discover and establish sessions with the peer, it shares the same gaps as LDP (Section 3.2.1) with regards to control plane (discovery, transport, and session establishment) in an IPv6-only network.
1. LDPコントロールプレーン：mLDPはLDPコントロールプレーンを使用してピアとのセッションを検出および確立するため、IPv6のコントロールプレーン（検出、転送、およびセッション確立）に関してLDP（セクション3.2.1）と同じギャップを共有します。 -のみのネットワーク。
2. Multipoint (MP) Forwarding Equivalence Class (FEC) Root Address: mLDP defines its own MP FECs and rules, different from LDP, to map MP LSPs. An mLDP MP FEC contains a Root Address field that is an IP address in IP networks. The current specification allows specifying the root address according to the Address Family Identifier (AFI), and hence covers both IPv4 or IPv6 root addresses, requiring no extension to support IPv6-only MP LSPs. The root address is used by each LSR participating in an MP LSP setup such that root address reachability is resolved by doing a table lookup against the root address to find corresponding upstream neighbor(s). This will pose a problem if an MP LSP traverses IPv4-only and IPv6-only nodes in a dual-stack network on the way to the root node.
2. マルチポイント（MP）転送等価クラス（FEC）ルートアドレス：mLDPは、MP LSPをマップするために、LDPとは異なる独自のMP FECおよびルールを定義します。 mLDP MP FECには、IPネットワークのIPアドレスであるルートアドレスフィールドが含まれています。現在の仕様では、アドレスファミリ識別子（AFI）に従ってルートアドレスを指定できるため、IPv4またはIPv6の両方のルートアドレスをカバーしており、IPv6のみのMP LSPをサポートするための拡張は必要ありません。ルートアドレスは、MP LSPセットアップに参加している各LSRによって使用され、対応するアップストリームネイバーを見つけるためにルートアドレスに対してテーブルルックアップを実行することにより、ルートアドレスの到達可能性が解決されます。これは、MP LSPがルートノードへの途中でデュアルスタックネットワークのIPv4専用ノードとIPv6専用ノードを通過する場合に問題を引き起こします。
For example, consider following setup, where R1/R6 are IPv4-only, R3/ R4 are IPv6-only, and R2/R5 are dual-stack LSRs:
たとえば、R1 / R6がIPv4のみ、R3 / R4がIPv6のみ、R2 / R5がデュアルスタックLSRである次の設定を検討してください。
( IPv4-only ) ( IPv6-only ) ( IPv4-only )
R1 -- R2 -- R3 -- R4 -- R5 -- R6
Leaf Root
Assume R1 to be a leaf node for a P2MP LSP rooted at R6 (root node). R1 uses R6's IPv4 address as the root address in MP FEC. As the MP LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 root address reachability. RFC 6512 [RFC6512] defines a recursive-FEC solution and procedures for mLDP when the backbone (transit/ branch) LSRs have no route to the root. The proposed solution is defined for a BGP-free core in a VPN environment, but a similar concept can be used/extended to solve the above issue of the IPv6-only backbone receiving an MP FEC element with an IPv4 address. The solution will require a border LSR (the one that is sitting on the border of an IPv4/IPv6 island (namely, R2 and R5 in this example)) to translate an IPv4 root address to an equivalent IPv6 address (and vice versa) through procedures similar to RFC 6512.
R1が、R6をルートとするP2MP LSPのリーフノードであると想定します（ルートノード）。 R1はR6のIPv4アドレスをMP FECのルートアドレスとして使用します。 MP LSPシグナリングがR1からR6に進むと、IPv4ルートアドレスの到達可能性を見つけようとすると、MP LSPセットアップは最初のIPv6のみのトランジット/ブランチLSR（R3）で失敗します。 RFC 6512 [RFC6512]は、バックボーン（トランジット/ブランチ）LSRにルートへのルートがない場合のmLDPの再帰的FECソリューションと手順を定義しています。提案されたソリューションは、VPN環境のBGPフリーコアに対して定義されていますが、IPv4アドレスを持つMP FEC要素を受信するIPv6のみのバックボーンの上記の問題を解決するために、同様のコンセプトを使用/拡張できます。ソリューションでは、境界LSR（IPv4 / IPv6アイランドの境界（つまり、この例ではR2とR5）にあるもの）を介して、IPv4ルートアドレスを同等のIPv6アドレス（およびその逆）に変換する必要があります。 RFC 6512と同様の手順。
Gap: Major; update in progress for LDP via [LDP-IPv6], may need additional updates to RFC 6512.
ギャップ：メジャー。 [LDP-IPv6]を介したLDPの更新が進行中のため、RFC 6512への追加の更新が必要になる場合があります。
RSVP-TE [RFC3209] defines a set of procedures and enhancements to establish LSP tunnels that can be automatically routed away from network failures, congestion, and bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects.
RSVP-TE [RFC3209]は、ネットワーク障害、輻輳、ボトルネックから自動的にルーティングできるLSPトンネルを確立するための一連の手順と拡張機能を定義しています。 RSVP-TEでは、LSP_TUNNEL_IPv6オブジェクトとサブオブジェクトのおかげで、IPv4またはIPv6プレフィックスのLSPを確立できます。
Gap: None.
ギャップ：なし。
RFC 3630 [RFC3630] specifies a method of adding traffic engineering capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF Version 3.
RFC 3630 [RFC3630]は、OSPFバージョン2にトラフィックエンジニアリング機能を追加する方法を指定しています。RFC5329 [RFC5329]に新しいTLVとサブTLVが追加され、OSPFバージョン3のIPv6ネットワークにTE機能が拡張されました。
RFC 5305 [RFC5305] specifies a method of adding traffic engineering capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 [RFC6119] to extend TE capabilities to IPv6 networks.
RFC 5305 [RFC5305]は、IS-ISにトラフィックエンジニアリング機能を追加する方法を指定しています。 TE機能をIPv6ネットワークに拡張するために、新しいTLVとサブTLVがRFC 6119 [RFC6119]に追加されました。
Gap: None.
ギャップ：なし。
RFC 4875 [RFC4875] describes extensions to RSVP-TE for the setup of Point-to-Multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS) with support for both IPv4 and IPv6.
RFC 4875 [RFC4875]は、IPv4とIPv6の両方をサポートするMPLSおよびGeneralized MPLS（GMPLS）でのポイントツーマルチポイント（P2MP）LSPのセットアップのためのRSVP-TEの拡張について説明しています。
Gap: None.
ギャップ：なし。
RFC 4090 [RFC4090] specifies Fast Reroute (FRR) mechanisms to establish backup LSP tunnels for local repair supporting both IPv4 and IPv6 networks. Further, [RFC5286] describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS networks in the event of a single failure, whether link, node, or shared risk link group (SRLG) for both IPv4 and IPv6.
RFC 4090 [RFC4090]は、IPv4ネットワークとIPv6ネットワークの両方をサポートするローカル修復用のバックアップLSPトンネルを確立するための高速再ルーティング（FRR）メカニズムを指定しています。さらに、[RFC5286]は、両方のIPv4のリンク、ノード、共有リスクリンクグループ（SRLG）のいずれかで単一の障害が発生した場合に、純粋なIPおよびMPLSネットワークでユニキャストトラフィックのローカル保護を提供するためのループフリー代替の使用について説明していますおよびIPv6。
Gap: None.
ギャップ：なし。
The Path Computation Element (PCE) defined in RFC 4655 [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for path computations and is defined in RFC 5440 [RFC5440].
RFC 4655 [RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算制約を適用できるエンティティです。パス計算クライアント（PCC）は、パスを計算するようにPCEに要求する場合があります。 PCE通信プロトコル（PCEP）は、パス計算用のPCCとPCE間の通信プロトコルとして設計されており、RFC 5440 [RFC5440]で定義されています。
The PCEP specification [RFC5440] is defined for both IPv4 and IPv6 with support for PCE discovery via an IGP (OSPF [RFC5088] or IS-IS [RFC5089]) using both IPv4 and IPv6 addresses. Note that PCEP uses identical encoding of subobjects, as in RSVP-TE defined in RFC 3209 [RFC3209] that supports both IPv4 and IPv6.
PCEP仕様[RFC5440]は、IPv4とIPv6の両方のアドレスを使用するIGP（OSPF [RFC5088]またはIS-IS [RFC5089]）によるPCE検出をサポートするIPv4とIPv6の両方に対して定義されています。 PCEPは、IPv4とIPv6の両方をサポートするRFC 3209 [RFC3209]で定義されているRSVP-TEと同様に、サブオブジェクトの同一のエンコーディングを使用することに注意してください。
The extensions to PCEP to support confidentiality [RFC5520], route exclusions [RFC5521], monitoring [RFC5886], and P2MP TE LSPs [RFC6006] have support for both IPv4 and IPv6.
機密性[RFC5520]、ルート除外[RFC5521]、監視[RFC5886]、およびP2MP TE LSP [RFC6006]をサポートするためのPCEPの拡張機能は、IPv4とIPv6の両方をサポートしています。
Gap: None.
ギャップ：なし。
RFC 3107 [RFC3107] specifies a set of BGP protocol procedures for distributing the labels (for prefixes corresponding to any address family) between label switch routers so that they can use the labels for forwarding the traffic. RFC 3107 allows BGP to distribute the label for IPv4 or IPv6 prefix in an IPv6-only network.
RFC 3107 [RFC3107]は、トラフィックを転送するためにラベルを使用できるように、ラベルスイッチルータ間で（任意のアドレスファミリに対応するプレフィックスの）ラベルを配布するための一連のBGPプロトコル手順を指定します。 RFC 3107により、BGPはIPv6のみのネットワークでIPv4またはIPv6プレフィックスのラベルを配布できます。
Gap: None.
ギャップ：なし。
The Generalized Multi-Protocol Label Switching (GMPLS) specification includes signaling functional extensions [RFC3471] and RSVP-TE extensions [RFC3473]. The gap analysis in Section 3.2.3 applies to these.
Generalized Multi-Protocol Label Switching（GMPLS）仕様には、シグナリング機能拡張[RFC3471]およびRSVP-TE拡張[RFC3473]が含まれています。セクション3.2.3のギャップ分析がこれらに適用されます。
RFC 4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with capability for both IPv4 and IPv6. RFC 4990 [RFC4990] clarifies the use of IPv6 addresses in GMPLS networks including handling in the MIB modules.
RFC 4558 [RFC4558]は、IPv4とIPv6の両方の機能を備えたノードIDベースのRSVP Helloメッセージを指定しています。 RFC 4990 [RFC4990]は、MIBモジュールでの処理を含む、GMPLSネットワークでのIPv6アドレスの使用を明確化しています。
The second paragraph of Section 5.3 of RFC 6370 [RFC6370] describes the mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE with an assumption that Node_IDs are derived from valid IPv4 addresses. This assumption fails in an IPv6-only network, given that there would not be any IPv4 addresses.
RFC 6370 [RFC6370]のセクション5.3の2番目の段落では、MPLSトランスポートプロファイル（MPLS-TP）LSP_IDからRSVP-TEへのマッピングについて説明しています。Node_IDは有効なIPv4アドレスから派生していると想定しています。 IPv6のみのネットワークでは、IPv4アドレスがないため、この仮定は失敗します。
Gap: Minor; Section 5.3 of RFC 6370 [RFC6370] needs to be updated.
ギャップ：マイナー。 RFC 6370 [RFC6370]のセクション5.3を更新する必要があります。
L2VPN [RFC4664] specifies two fundamentally different kinds of Layer 2 VPN services that a service provider could offer to a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify the LDP protocol changes to instantiate VPWS and VPLS services, respectively, in an MPLS network using LDP as the signaling protocol. This is complemented by RFC 6074 [RFC6074], which specifies a set of procedures for instantiating L2VPNs (e.g., VPWS, VPLS) using BGP as a discovery protocol and LDP, as well as L2TPv3, as a signaling protocol. RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol changes to instantiate VPLS and VPWS services in an MPLS network, using BGP for both discovery and signaling.
L2VPN [RFC4664]は、サービスプロバイダーが顧客に提供できる2つの基本的に異なる種類のレイヤ2 VPNサービスを指定します。仮想プライベートワイヤサービス（VPWS）と仮想プライベートLANサービス（VPLS）です。 RFC 4447 [RFC4447]およびRFC 4762 [RFC4762]は、LDPをシグナリングプロトコルとして使用するMPLSネットワークで、VPWSおよびVPLSサービスをそれぞれインスタンス化するLDPプロトコルの変更を指定しています。これは、RFC 6074 [RFC6074]によって補完されます。RFC6074は、BGPをディスカバリプロトコルおよびLDPとして使用し、L2TPv3をシグナリングプロトコルとして使用して、L2VPN（VPWS、VPLSなど）をインスタンス化するための一連の手順を指定します。 RFC 4761 [RFC4761]およびRFC 6624 [RFC6624]は、MPLSネットワークでVPLSおよびVPWSサービスをインスタンス化するためのBGPプロトコルの変更を指定し、検出とシグナリングの両方にBGPを使用します。
In an IPv6-only MPLS network, use of L2VPN represents a connection of Layer 2 islands over an IPv6 MPLS core, and very few changes are necessary to support operation over an IPv6-only network. The L2VPN signaling protocol is either BGP or LDP in an MPLS network, and both can run directly over IPv6 core infrastructure as well as IPv6 edge devices. RFC 6074 [RFC6074] is the only RFC that appears to have a gap for IPv6-only operation. In its discovery procedures (Sections 3.2.2 and 6 of RFC 6074 [RFC6074]), it suggests encoding PE IP addresses in the Virtual Switching Instance ID (VSI-ID), which is encoded in Network Layer Reachability Information (NLRI) and should not exceed 12 bytes (to differentiate its AFI/SAFI (Subsequent Address Family Identifier) encoding from RFC 4761). This means that a PE IP address cannot be an IPv6 address. Also, in its signaling procedures (Section 3.2.3 of RFC 6074 [RFC6074]), it suggests encoding PE_addr in the Source Attachment Individual Identifier (SAII) and the Target Attachment Individual Identifier (TAII), which are limited to 32 bits (AII Type=1) at the moment.
IPv6のみのMPLSネットワークでは、L2VPNの使用はIPv6 MPLSコアを介したレイヤー2アイランドの接続を表し、IPv6のみのネットワークでの操作をサポートするために必要な変更はほとんどありません。 L2VPNシグナリングプロトコルは、MPLSネットワークではBGPまたはLDPであり、どちらもIPv6コアインフラストラクチャおよびIPv6エッジデバイス上で直接実行できます。 RFC 6074 [RFC6074]は、IPv6のみの操作にギャップがあると思われる唯一のRFCです。その発見手順（RFC 6074 [RFC6074]のセクション3.2.2および6）では、ネットワーク層到達可能性情報（NLRI）でエンコードされている仮想スイッチングインスタンスID（VSI-ID）でPE IPアドレスをエンコードすることを提案しています。 12バイトを超えない（RFC 4761からAFI / SAFI（後続アドレスファミリ識別子）エンコーディングを区別するため）。つまり、PE IPアドレスをIPv6アドレスにすることはできません。また、そのシグナリング手順（RFC 6074 [RFC6074]のセクション3.2.3）では、32ビット（AII）に制限されているソースアタッチメント個別識別子（SAII）およびターゲットアタッチメント個別識別子（TAII）でのPE_addrのエンコードを提案しています。 Type = 1）現時点では。
RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching Point PE TLV, which supports IPv4 and IPv6.
RFC 6073 [RFC6073]は、IPv4およびIPv6をサポートする新しいLDP疑似配線（PW）スイッチングポイントPE TLVを定義しています。
Gap: Minor; RFC 6074 needs to be updated.
ギャップ：マイナー。 RFC 6074を更新する必要があります。
Ethernet VPN [EVPN] defines a method for using BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP and mLDP, as well as Multicast VPLS [RFC7117], it inherits LDP gaps previously identified in Section 3.2.1. Once those gaps are resolved, it should function properly on IPv6-only networks as defined.
イーサネットVPN [EVPN]は、BGP MPLSベースのイーサネットVPNを使用する方法を定義します。 LDPとmLDP、およびマルチキャストVPLS [RFC7117]の機能を使用できるため、以前にセクション3.2.1で特定されたLDPギャップを継承します。これらのギャップが解決されると、IPv6のみのネットワークで定義どおりに正しく機能するようになります。
Gap: Major for LDP; update to RFC 5036 in progress via [LDP-IPv6] that should close this gap (see Section 3.2.1).
ギャップ：LDPのメジャー。このギャップを埋める[LDP-IPv6]を介して進行中のRFC 5036への更新（セクション3.2.1を参照）。
RFC 4364 [RFC4364] defines a method by which a Service Provider may use an IP backbone to provide IP VPNs for its customers. The following use cases arise in the context of this gap analysis:
RFC 4364 [RFC4364]は、サービスプロバイダーがIPバックボーンを使用して顧客にIP VPNを提供する方法を定義しています。このギャップ分析のコンテキストでは、次のユースケースが発生します。
1. Connecting IPv6 islands over IPv6-only MPLS network
1. IPv6のみのMPLSネットワークを介したIPv6アイランドの接続
2. Connecting IPv4 islands over IPv6-only MPLS network Both use cases require mapping an IP packet to an IPv6-signaled LSP. RFC 4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4-only and has references to 32-bit BGP next-hop addresses. RFC 4659 [RFC4659] adds support for IPv6 on L3VPNs, including 128-bit BGP next-hop addresses, and discusses operation whether IPv6 is the payload or the underlying transport address family. However, RFC 4659 does not formally update RFC 4364, and thus an implementer may miss this additional set of standards unless it is explicitly identified independently of the base functionality defined in RFC 4364. Further, Section 1 of RFC 4659 explicitly identifies use case 2 as out of scope for the document.
2. IPv6のみのMPLSネットワークを介したIPv4アイランドの接続どちらのユースケースでも、IPパケットをIPv6信号のLSPにマッピングする必要があります。 RFC 4364は、IPv4専用のレイヤー3仮想プライベートネットワーク（L3VPN）を定義し、32ビットBGPネクストホップアドレスへの参照を持っています。 RFC 4659 [RFC4659]は、128ビットBGPネクストホップアドレスを含むL3VPNでのIPv6のサポートを追加し、IPv6がペイロードであるか、基になるトランスポートアドレスファミリであるかを示しています。ただし、RFC 4659はRFC 4364を正式に更新しないため、RFC 4364で定義されている基本機能とは無関係に明示的に識別されない限り、実装者はこの追加の標準セットを見逃す可能性があります。ドキュメントの範囲外です。
The authors do not believe that there are any additional issues encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as transport on an IPv6-only network.
著者は、IPv6のみのネットワーク上のトランスポートとしてL2TPv3、RSVP、またはGMP（MPLSの代わりに）を使用するときに発生する追加の問題があるとは考えていません。
Gap: Major; RFC 4659 needs to be updated to explicitly cover use case 2 (discussed in further detail below)
ギャップ：メジャー。 RFC 4659は、ユースケース2を明示的にカバーするように更新する必要があります（以下でさらに詳しく説明します）
RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud. However, use case 2 is doing the opposite, and thus could also be referred to as IPv4 Provider Edge (4PE). The method to support this use case is not defined explicitly. To support it, IPv4 edge devices need to be able to map IPv4 traffic to MPLS IPv6 core LSPs. Also, the core switches may not understand IPv4 at all, but in some cases they may need to be able to exchange Labeled IPv4 routes from one Autonomous System (AS) to a neighboring AS.
RFC 4798 [RFC4798]は、IPv6プロバイダーエッジ（6PE）を定義しています。これは、MPLS対応のIPv4クラウド上でIPv6アイランドを相互接続する方法を定義しています。ただし、ユースケース2はその逆を行っているため、IPv4プロバイダーエッジ（4PE）と呼ばれることもあります。このユースケースをサポートするメソッドは明示的に定義されていません。これをサポートするには、IPv4エッジデバイスがIPv4トラフィックをMPLS IPv6コアLSPにマップできる必要があります。また、コアスイッチはIPv4をまったく理解しない場合がありますが、場合によっては、1つの自律システム（AS）から隣接するASにラベル付きIPv4ルートを交換できる必要があります。
Gap: Major; RFC 4798 covers only the "6PE" case. Use case 2 is currently not specified in an RFC.
ギャップ：メジャー。 RFC 4798は「6PE」の場合のみをカバーしています。ユースケース2は現在RFCで指定されていません。
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual Private Extension (6VPE/4VPE)
3.3.2.2. IPv6 Virtual Private Extension / IPv4 Virtual Private Extension（6VPE / 4VPE）
RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension (6VPE), a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. It allows the core network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 above. RFC 4364 should work as defined for use case 2 above, which could also be referred to as IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does not discuss this use and defines it as out of scope.
RFC 4659 [RFC4659]は、IPv6仮想プライベートネットワーク拡張（6VPE）を定義しています。これは、サービスプロバイダーがパケット交換バックボーンを使用して、IPv6顧客に仮想プライベートネットワーク（VPN）サービスを提供する方法です。これにより、コアネットワークをMPLS IPv4またはMPLS IPv6にできるため、上記のユースケース1に対応できます。 RFC 4364は、上記のユースケース2で定義されているとおりに機能する必要があります。これはIPv4 Virtual Private Extension（4VPE）とも呼ばれますが、RFCではこの使用法については明示的に説明されておらず、範囲外と定義されています。
Gap: Minor; RFC 4659 needs to be updated to explicitly cover use case 2.
ギャップ：マイナー。ユースケース2を明示的にカバーするには、RFC 4659を更新する必要があります。
RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute, which can be used to signal tunneling over an IP Core that is using a single address family. This mechanism supports transport of MPLS (and other protocols) over Tunnels in an IP core (including an IPv6-only core). In this context, load balancing can be provided as specified in RFC 5640 [RFC5640].
RFC 5512 [RFC5512]は、BGPカプセル化SAFIとBGPトンネルカプセル化属性を定義します。これらは、単一のアドレスファミリを使用しているIPコアを介したトンネリングのシグナリングに使用できます。このメカニズムは、IPコア（IPv6のみのコアを含む）のトンネルを介したMPLS（およびその他のプロトコル）の転送をサポートします。このコンテキストでは、RFC 5640 [RFC5640]で指定されているようにロードバランシングを提供できます。
Gap: None.
ギャップ：なし。
RFC 6513 [RFC6513] defines the procedure to provide multicast service over an MPLS VPN backbone for downstream customers. It is sometimes referred to as Next Generation Multicast VPN (NG-MVPN) The procedure involves the below set of protocols.
RFC 6513 [RFC6513]は、ダウンストリームカスタマーにMPLS VPNバックボーンを介してマルチキャストサービスを提供する手順を定義しています。次世代マルチキャストVPN（NG-MVPN）と呼ばれることもあります。この手順には、以下の一連のプロトコルが含まれます。
RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast (PIM) as a Provider Edge - Customer Edge (PE-CE) protocol, while Section 11.1.2 of RFC 6514 [RFC6514] explains the use of mLDP as a PE-CE protocol.
RFC 6513 [RFC6513]は、Protocol Independent Multicast（PIM）のプロバイダーエッジ-カスタマーエッジ（PE-CE）プロトコルとしての使用を説明し、RFC 6514 [RFC6514]のセクション11.1.2は、PE-CEとしてのmLDPの使用を説明していますプロトコル。
The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] is not sufficiently covering all scenarios when mLDP is used as a PE-CE protocol. The issue is explained in Section 2 of [mLDP-NLRI] along with a new route type that encodes the mLDP FEC in NLRI.
RFC 6514 [RFC6514]で定義されているMCAST-VPN NLRIルートタイプ形式は、mLDPがPE-CEプロトコルとして使用されている場合、すべてのシナリオを十分にカバーしていません。この問題は、[mLDP-NLRI]のセクション2で、NLRIでmLDP FECをエンコードする新しいルートタイプとともに説明されています。
Further, [PE-CE] defines the use of BGP as a PE-CE protocol.
さらに、[PE-CE]は、BGPの使用をPE-CEプロトコルとして定義しています。
Gap: None.
ギャップ：なし。
[RFC6513] explains the use of the below tunnels:
[RFC6513]は、以下のトンネルの使用について説明しています。
o RSVP-TE P2MP LSP
o RSVP-TE P2MP LSP
o PIM Tree
o PIMツリー
o mLDP P2MP LSP
o mLDP P2MP LSP
o mLDP MP2MP LSP
o mLDP MP2MP LSP
o Ingress Replication Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP (Section 3.2.2) P2MP and MP2MP LSP are covered in previous sections. There are no MPLS-specific gaps for PIM Tree or Ingress Replication, and any protocol-specific gaps not related to MPLS are outside the scope of this document.
o入力レプリケーションギャップ：RSVP-TE P2MP LSP（セクション3.2.3.2）およびmLDP（セクション3.2.2）のギャップP2MPおよびMP2MP LSPについては、前のセクションで説明しています。 PIMツリーまたは入力レプリケーションにはMPLS固有のギャップはなく、MPLSに関連しないプロトコル固有のギャップはこのドキュメントの範囲外です。
Section 3.1 of RFC 6513 [RFC6513] explains the use of PIM as a PE-PE protocol, while RFC 6514 [RFC6514] explains the use of BGP as a PE-PE protocol.
RFC 6513 [RFC6513]のセクション3.1では、PE-PEプロトコルとしてのPIMの使用について説明し、RFC 6514 [RFC6514]では、PE-PEプロトコルとしてのBGPの使用について説明しています。
PE-PE multicast routing is not specific to P-tunnels or to MPLS. It can be PIM or BGP with P-tunnels that are label based or PIM tree based. Enabling PIM as a PE-PE multicast protocol is equivalent to running it on a non-MPLS IPv6 network, so there are not any MPLS-specific considerations and any gaps are applicable for non-MPLS networks as well. Similarly, BGP only includes the P-Multicast Service Interface (PMSI) tunnel attribute as a part of the NLRI, which is inherited from P-tunnel instantiation and considered to be an opaque value. Any gaps in the control plane (PIM or BGP) will not be specific to MPLS.
PE-PEマルチキャストルーティングは、PトンネルまたはMPLSに固有のものではありません。ラベルベースまたはPIMツリーベースのPトンネルを備えたPIMまたはBGPにすることができます。 PIMをPE-PEマルチキャストプロトコルとして有効にすることは、PMPを非MPLS IPv6ネットワーク上で実行することと同等であるため、MPLS固有の考慮事項はなく、ギャップは非MPLSネットワークにも適用されます。同様に、BGPにはPマルチキャストサービスインターフェイス（PMSI）トンネル属性のみがNLRIの一部として含まれています。これは、Pトンネルのインスタンス化から継承され、不透明な値と見なされます。コントロールプレーン（PIMまたはBGP）のギャップは、MPLSに固有のものではありません。
Gap: Any gaps in PIM or BGP as a PE-PE multicast routing protocol are not unique to MPLS, and therefore are outside the scope of this document. It is included for completeness.
ギャップ：PE-PEマルチキャストルーティングプロトコルとしてのPIMまたはBGPのギャップは、MPLSに固有のものではないため、このドキュメントの範囲外です。完全を期すために含まれています。
MPLS-TP does not require IP (see Section 2 of RFC 5921 [RFC5921]) and should not be affected by operation on an IPv6-only network. Therefore, this is considered out of scope for this document but is included for completeness.
MPLS-TPはIPを必要とせず（RFC 5921 [RFC5921]のセクション2を参照）、IPv6のみのネットワークでの操作による影響を受けません。したがって、これはこのドキュメントの範囲外と見なされますが、完全を期すために含まれています。
Although not required, MPLS-TP can use IP. One such example is included in Section 3.2.6, where MPLS-TP identifiers can be derived from valid IPv4 addresses.
必須ではありませんが、MPLS-TPはIPを使用できます。そのような例の1つはセクション3.2.6に含まれており、MPLS-TP識別子は有効なIPv4アドレスから導出できます。
Gap: None. MPLS-TP does not require IP.
ギャップ：なし。 MPLS-TPはIPを必要としません。
For MPLS LSPs, there are primarily three OAM mechanisms: Extended ICMP [RFC4884] [RFC4950], LSP Ping [RFC4379], and Bidirectional Forwarding Detection (BFD) for MPLS LSPs [RFC5884]. For MPLS Pseudowires, there is also Virtual Circuit Connectivity Verification (VCCV) [RFC5085] [RFC5885]. Most of these mechanisms work in pure IPv6 environments, but there are some problems encountered in mixed environments due to address-family mismatches. The next subsections cover these gaps in detail.
MPLS LSPの場合、主に3つのOAMメカニズムがあります。拡張ICMP [RFC4884] [RFC4950]、LSP Ping [RFC4379]、およびMPLS LSPの双方向転送検出（BFD）[RFC5884]です。 MPLS疑似配線の場合、仮想回線接続検証（VCCV）[RFC5085] [RFC5885]もあります。これらのメカニズムのほとんどは純粋なIPv6環境で機能しますが、アドレスファミリの不一致が原因で混合環境で発生する問題がいくつかあります。次のサブセクションでは、これらのギャップについて詳しく説明します。
Gap: Major; RFC 4379 needs to be updated to better support multipath IPv6. Additionally, there is potential for dropped messages in Extended ICMP and LSP Ping due to IP version mismatches. It is important to note that this is a more generic problem with tunneling when address-family mismatches exist and is not specific to MPLS. While MPLS will be affected, it will be difficult to fix this problem specifically for MPLS, rather than fixing the more generic problem.
ギャップ：メジャー。マルチパスIPv6をより適切にサポートするには、RFC 4379を更新する必要があります。さらに、IPバージョンの不一致により、拡張ICMPおよびLSP Pingでメッセージがドロップされる可能性があります。これは、アドレスファミリの不一致が存在する場合のトンネリングに関するより一般的な問題であり、MPLSに固有のものではないことに注意することが重要です。 MPLSは影響を受けますが、より一般的な問題を修正するのではなく、MPLS専用にこの問題を修正することは困難です。
Extended ICMP to support Multi-part messages is defined in RFC 4884 [RFC4884]. This extensibility is defined generally for both ICMPv4 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 4950 [RFC4950]. ICMP Multi-part with MPLS extensions works for IPv4 and IPv6. However, the mechanisms described in RFC 4884 and 4950 may fail when tunneling IPv4 traffic over an LSP that is supported by an IPv6-only infrastructure.
マルチパートメッセージをサポートする拡張ICMPは、RFC 4884 [RFC4884]で定義されています。この拡張性は、一般にICMPv4とICMPv6の両方で定義されています。 MPLSの特定のICMP拡張機能は、RFC 4950 [RFC4950]で定義されています。 MPLS拡張機能を備えたICMPマルチパートは、IPv4およびIPv6で機能します。ただし、RFC 4884および4950で説明されているメカニズムは、IPv6のみのインフラストラクチャでサポートされているLSPを介してIPv4トラフィックをトンネリングすると失敗する場合があります。
Assume the following:
以下を想定します。
o The path between two IPv4-only hosts contains an MPLS LSP.
o 2つのIPv4専用ホスト間のパスには、MPLS LSPが含まれています。
o The two routers that terminate the LSP run dual stack.
o LSPを終端する2つのルータはデュアルスタックを実行します。
o The LSP interior routers run IPv6 only.
o LSP内部ルーターはIPv6のみを実行します。
o The LSP is signaled over IPv6.
o LSPはIPv6を介して通知されます。
Now assume that one of the hosts sends an IPv4 packet to the other. However, the packet's TTL expires on an LSP interior router. According to RFC 3032 [RFC3032], the interior router should examine the IPv4 payload, format an ICMPv4 message, and send it (over the tunnel upon which the original packet arrived) to the egress LSP. In this case, however, the LSP interior router is not IPv4-aware. It cannot parse the original IPv4 datagram, nor can it send an IPv4 message. So, no ICMP message is delivered to the source. Some specific ICMP extensions, in particular, ICMP extensions for interface and next-hop identification [RFC5837], restrict the address family of address information included in an Interface Information Object to the same one as the ICMP (see Section 4.5 of RFC 5837). While these extensions are not MPLS specific, they can be used with MPLS packets carrying IP datagrams. This has no implications for IPv6-only environments.
次に、一方のホストがIPv4パケットを他方に送信するとします。ただし、パケットのTTLはLSP内部ルーターで期限切れになります。 RFC 3032 [RFC3032]によると、内部ルーターはIPv4ペイロードを調べ、ICMPv4メッセージをフォーマットし、それを（元のパケットが到着したトンネルを介して）出力LSPに送信する必要があります。ただし、この場合、LSP内部ルーターはIPv4対応ではありません。元のIPv4データグラムを解析することも、IPv4メッセージを送信することもできません。そのため、ICMPメッセージはソースに配信されません。一部の特定のICMP拡張機能、特にインターフェイスとネクストホップの識別[RFC5837]のICMP拡張機能は、インターフェイス情報オブジェクトに含まれるアドレス情報のアドレスファミリーをICMPと同じものに制限します（RFC 5837のセクション4.5を参照）。これらの拡張はMPLS固有ではありませんが、IPデータグラムを運ぶMPLSパケットで使用できます。これはIPv6のみの環境には影響しません。
Gap: Major; IP version mismatches may cause dropped messages. However, as noted in the previous section, this problem is not specific to MPLS.
ギャップ：メジャー。 IPバージョンの不一致により、メッセージがドロップされる場合があります。ただし、前のセクションで説明したように、この問題はMPLSに固有のものではありません。
The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to work with IPv6. Specifically, the Target FEC Stacks include both IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). The only exceptions are the Pseudowire FECs, which are later specified for IPv6 in RFC 6829 [RFC6829]. The multipath information also includes IPv6 encodings (see Section 3.3.1 of RFC 4379).
RFC 4379 [RFC4379]で定義されているLSP Pingメカニズムは、IPv6で動作するように指定されています。具体的には、ターゲットFECスタックには、すべてのFECのIPv4バージョンとIPv6バージョンの両方が含まれています（RFC 4379のセクション3.2を参照）。唯一の例外は、疑似配線FECです。これは、後でRFC 6829 [RFC6829]でIPv6用に指定されています。マルチパス情報にはIPv6エンコーディングも含まれます（RFC 4379のセクション3.3.1を参照）。
LSP Ping packets are UDP packets over either IPv4 or IPv6 (see Section 4.3 of RFC 4379). However, for IPv6 the destination IP address is a (randomly chosen) IPv6 address from the range 0:0:0:0:0:FFFF:127/104; that is, using an IPv4-mapped IPv6 address. This is a transitional mechanism that should not bleed into IPv6-only networks, as [IPv4-MAPPED] explains. The issue is that the MPLS LSP Ping mechanism needs a range of loopback IP addresses to be used as destination addresses to exercise Equal Cost Multiple Path (ECMP), but the IPv6 address architecture specifies a single address (::1/128) for loopback. A mechanism to achieve this was proposed in [LOOPBACK-PREFIX].
LSP Pingパケットは、IPv4またはIPv6上のUDPパケットです（RFC 4379のセクション4.3を参照）。ただし、IPv6の場合、宛先IPアドレスは0：0：0：0：0：FFFF：127/104の範囲の（ランダムに選択された）IPv6アドレスです。つまり、IPv4でマップされたIPv6アドレスを使用します。これは、[IPv4-MAPPED]で説明されているように、IPv6のみのネットワークに流入しない移行メカニズムです。問題は、MPLS LSP Pingメカニズムが等コストマルチパス（ECMP）を実行するために宛先アドレスとして使用されるループバックIPアドレスの範囲を必要とすることですが、IPv6アドレスアーキテクチャはループバック用に単一のアドレス（:: 1/128）を指定します。これを達成するためのメカニズムは[LOOPBACK-PREFIX]で提案されました。
Additionally, RFC 4379 does not define the value to be used in the IPv6 Router Alert option (RAO). For IPv4 RAO, a value of zero is used. However, there is no equivalent value for IPv6 RAO. This gap needs to be fixed to be able to use LSP Ping in IPv6 networks. Further details on this gap are captured, along with a proposed solution, in [IPv6-RAO].
さらに、RFC 4379は、IPv6ルーターアラートオプション（RAO）で使用される値を定義していません。 IPv4 RAOの場合、ゼロの値が使用されます。ただし、IPv6 RAOに相当する値はありません。 IPv6ネットワークでLSP Pingを使用できるようにするには、このギャップを修正する必要があります。このギャップに関する詳細は、提案されたソリューションとともに[IPv6-RAO]に記載されています。
Another gap is that the mechanisms described in RFC 4379 may fail when tunneling IPv4 traffic over an LSP that is supported by IPv6-only infrastructure.
もう1つのギャップは、IPv6のみのインフラストラクチャでサポートされているLSPを介してIPv4トラフィックをトンネリングすると、RFC 4379で説明されているメカニズムが失敗する可能性があることです。
Assume the following:
以下を想定します。
o LSP Ping is operating in traceroute mode over an MPLS LSP.
o LSP Pingは、MPLS LSPを介してtracerouteモードで動作しています。
o The two routers that terminate the LSP run dual stack.
o LSPを終端する2つのルータはデュアルスタックを実行します。
o The LSP interior routers run IPv6 only.
o LSP内部ルーターはIPv6のみを実行します。
o The LSP is signaled over IPv6.
o LSPはIPv6を介して通知されます。
Packets will expire at LSP interior routers. According to RFC 4379, the interior router must parse the IPv4 Echo Request and then send an IPv4 Echo Reply. However, the LSP interior router is not IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send an IPv4 Echo Reply. So, no reply is sent.
パケットはLSP内部ルーターで期限切れになります。 RFC 4379によれば、内部ルーターはIPv4エコー要求を解析してから、IPv4エコー応答を送信する必要があります。ただし、LSP内部ルーターはIPv4対応ではありません。 IPv4エコー要求を解析することも、IPv4エコー応答を送信することもできません。したがって、返信は送信されません。
The mechanism described in RFC 4379 also does not sufficiently explain the behavior in certain IPv6-specific scenarios. For example, RFC 4379 defines the K value as 28 octets when the Address Family is set to IPv6 Unnumbered, but it doesn't describe how to carry a 32-bit LSR Router ID in the 128-bit Downstream IP Address field.
RFC 4379で説明されているメカニズムも、特定のIPv6固有のシナリオでの動作を十分に説明していません。たとえば、RFC 4379では、アドレスファミリがIPv6 Unnumberedに設定されている場合、K値を28オクテットとして定義していますが、128ビットダウンストリームIPアドレスフィールドで32ビットLSRルーターIDを伝送する方法については説明されていません。
Gap: Major; LSP Ping uses IPv4-mapped IPv6 addresses. IP version mismatches may cause dropped messages and unclear mapping from the LSR Router ID to Downstream IP Address.
ギャップ：メジャー。 LSP PingはIPv4にマップされたIPv6アドレスを使用します。 IPバージョンの不一致により、メッセージがドロップされ、LSRルーターIDからダウンストリームIPアドレスへのマッピングが不明確になる場合があります。
The BFD specification for MPLS LSPs [RFC5884] is defined for IPv4, as well as IPv6, versions of MPLS FECs (see Section 3.1 of RFC 5884). Additionally, the BFD packet is encapsulated over UDP and specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884).
MPLS LSP [RFC5884]のBFD仕様は、MPLS FECのIPv4バージョンとIPv6バージョンで定義されています（RFC 5884のセクション3.1を参照）。さらに、BFDパケットはUDPでカプセル化され、IPv4とIPv6の両方で実行するように指定されています（RFC 5884のセクション7を参照）。
Gap: None.
ギャップ：なし。
The OAM specifications for MPLS Pseudowires define usage for both IPv4 and IPv6. Specifically, VCCV [RFC5085] can carry IPv4 or IPv6 OAM packets (see Sections 5.1.1 and 5.2.1 of RFC 5085), and VCCV for BFD [RFC5885] also defines an IPv6 encapsulation (see Section 3.2 of RFC 5885).
MPLS疑似配線のOAM仕様は、IPv4とIPv6の両方の使用法を定義しています。具体的には、VCCV [RFC5085]はIPv4またはIPv6 OAMパケットを伝送でき（RFC 5085のセクション5.1.1および5.2.1を参照）、BFDのVCCV [RFC5885]はIPv6カプセル化も定義します（RFC 5885のセクション3.2を参照）。
Additionally, for LSP Ping for pseudowires, the Pseudowire FECs are specified for IPv6 in RFC 6829 [RFC6829].
さらに、疑似配線のLSP Pingの場合、疑似配線FECはRFC 6829 [RFC6829]でIPv6用に指定されています。
Gap: None.
ギャップ：なし。
As with MPLS-TP, MPLS-TP OAM [RFC6371] does not require IP or existing MPLS OAM functions and should not be affected by operation on an IPv6-only network. Therefore, this is out of scope for this document but is included for completeness. Although not required, MPLS-TP can use IP.
MPLS-TPと同様に、MPLS-TP OAM [RFC6371]はIPまたは既存のMPLS OAM機能を必要とせず、IPv6のみのネットワークでの操作による影響を受けません。したがって、これはこのドキュメントの範囲外ですが、完全を期すために含まれています。必須ではありませんが、MPLS-TPはIPを使用できます。
Gap: None. MPLS-TP OAM does not require IP.
ギャップ：なし。 MPLS-TP OAMはIPを必要としません。
RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802] and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete.
RFC 3811 [RFC3811]は、MPLSのテキスト表記法を定義しています。これらは、MplsExtendedTunnelIdおよびMplsLsrIdentifierの定義でIPv6をサポートしていません。これらのテキストの表記法は、MPLS-TE MIB仕様[RFC3812]、GMPLS-TE MIB仕様[RFC4802]、およびFRR拡張[RFC6445]で使用されています。 「マルチプロトコルラベルスイッチング（MPLS）管理用のテキスト表記法（TC）の定義」[MPLS-TC]は、このテキスト表記法を廃止としてマークすることにより、このギャップを解決しようとします。
The other MIB specifications for LSR [RFC3813], LDP [RFC3815], and TE [RFC4220] have support for both IPv4 and IPv6.
LSR [RFC3813]、LDP [RFC3815]、およびTE [RFC4220]の他のMIB仕様は、IPv4とIPv6の両方をサポートしています。
Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS-TE MIB modules. In particular, Section 8 of RFC 4990 [RFC4990] describes a method of defining or monitoring an LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working around some of the limitations in RFC 3811 [RFC3811].
最後に、RFC 4990 [RFC4990]では、MPLSおよびGMPLS-TE MIBモジュールでIPv6の送信元と宛先を処理する方法について説明しています。特に、RFC 4990 [RFC4990]のセクション8では、MPLS-TEおよびGMPLS-TE MIBモジュールを使用してLSPトンネルを定義または監視し、RFC 3811 [RFC3811]の一部の制限に対処する方法について説明しています。
Gap: Minor; Section 8 of RFC 4990 [RFC4990] describes a method to handle IPv6 addresses in the MPLS-TE [RFC3812] and GMPLS-TE [RFC4802] MIB modules. Work underway to update RFC 3811 via [MPLS-TC], may also need to update RFC 3812, RFC 4802, and RFC 6445, which depend on it.
ギャップ：マイナー。 RFC 4990 [RFC4990]のセクション8では、MPLS-TE [RFC3812]およびGMPLS-TE [RFC4802] MIBモジュールでIPv6アドレスを処理する方法について説明しています。 [MPLS-TC]を介してRFC 3811を更新する作業が進行中ですが、それに依存するRFC 3812、RFC 4802、およびRFC 6445も更新する必要がある場合があります。
This document has reviewed a wide variety of MPLS features and protocols to determine their suitability for use on IPv6-only or IPv6-primary networks. While some parts of the MPLS suite will function properly without additional changes, gaps have been identified in others that will need to be addressed with follow-on work. This section will summarize those gaps, along with pointers to any work in progress to address them. Note that because the referenced documents are works in progress and do not have consensus at the time of this document's publication, there could be other solutions proposed at a future time, and the pointers in this document should not be considered normative in any way. Additionally, work in progress on new features that use MPLS protocols will need to ensure that those protocols support operation on IPv6-only or IPv6-primary networks, or explicitly identify any dependencies on existing gaps that, once resolved, will allow proper IPv6-only operation.
このドキュメントでは、さまざまなMPLS機能とプロトコルをレビューして、IPv6のみのネットワークまたはIPv6プライマリネットワークでの使用への適合性を判断しました。 MPLSスイートの一部は追加の変更なしで適切に機能しますが、後続の作業で対処する必要がある他の部分でギャップが特定されています。このセクションでは、これらのギャップをまとめ、それらに対処するために進行中の作業へのポインタを示します。参照されているドキュメントは作成中であり、このドキュメントの公開時点でコンセンサスがないため、将来的に他の解決策が提案される可能性があることに注意してください。このドキュメント内のポインタは、決して規範と見なされるべきではありません。さらに、MPLSプロトコルを使用する新機能の進行中の作業では、これらのプロトコルがIPv6のみまたはIPv6プライマリネットワークでの動作をサポートすることを確認するか、解決すると適切なIPv6のみを許可する既存のギャップに対する依存関係を明示的に識別する必要があります。操作。
Identified Gaps in MPLS for IPv6-Only Networks
IPv6のみのネットワークのMPLSで識別されたギャップ
+---------+---------------------------------------+-----------------+
| Item | Gap | Addressed in |
+---------+---------------------------------------+-----------------+
| LDP | LSP mapping, LDP identifiers, LDP | [LDP-IPv6] |
| S.3.2.1 | discovery, LDP session establishment, | |
| | next-hop address, and LDP TTL | |
| | security | |
+---------+---------------------------------------+-----------------+
| mLDP | Inherits gaps from LDP, RFC 6512 | Inherits |
| S.3.2.2 | [RFC6512] | [LDP-IPv6], |
| | | additional |
| | | fixes TBD |
+---------+---------------------------------------+-----------------+
| GMPLS | RFC 6370 [RFC6370] Node ID derivation | TBD |
| S.3.2.6 | | |
+---------+---------------------------------------+-----------------+
| L2VPN | RFC 6074 [RFC6074] discovery, | TBD |
| S.3.3.1 | signaling | |
+---------+---------------------------------------+-----------------+
| L3VPN | RFC 4659 [RFC4659] does not define a | TBD |
| S.3.3.2 | method for 4PE/4VPE | |
+---------+---------------------------------------+-----------------+
| OAM | RFC 4379 [RFC4379] No IPv6 multipath | [IPv6-RAO] |
| S.3.4 | support, no IPv6 RAO, possible | |
| | dropped messages in IP version | |
| | mismatch | |
+---------+---------------------------------------+-----------------+
| MIB | RFC 3811 [RFC3811] no IPv6 textual | [MPLS-TC] |
| Modules | convention | |
| S.3.5 | | |
+---------+---------------------------------------+-----------------+
Table 1: IPv6-Only MPLS Gaps
表1：IPv6のみのMPLSギャップ
Changing the address family used for MPLS network operation does not fundamentally alter the security considerations currently extant in any of the specifics of the protocol or its features. However, follow-on work recommended by this gap analysis will need to address any effects that the use of IPv6 in their modifications may have on security.
MPLSネットワーク操作に使用されるアドレスファミリーを変更しても、プロトコルまたはその機能の詳細に現在存在するセキュリティの考慮事項は根本的に変更されません。ただし、このギャップ分析で推奨されている後続作業では、変更にIPv6を使用することでセキュリティに与える可能性のある影響に対処する必要があります。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月、<http://www.rfc-editor.org/info/rfc3032>。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001, <http://www.rfc-editor.org/info/rfc3107>.
[RFC3107] Rekhter、Y。およびE. Rosen、「Carrying Label Information in BGP-4」、RFC 3107、2001年5月、<http://www.rfc-editor.org/info/rfc3107>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、2003年1月、<http://www.rfc-editor.org/info/rfc3471>。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月、<http：//www.rfc-editor。 org / info / rfc3473>。
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004, <http://www.rfc-editor.org/info/rfc3811>.
[RFC3811]ナドー、T。、およびJ.クッチアラ、「マルチプロトコルラベルスイッチング（MPLS）管理のためのテキスト表記法（TC）の定義」、RFC 3811、2004年6月、<http://www.rfc-editor.org/info / rfc3811>。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、2005年3月、<http://www.rfc-editor.org / info / rfc4023>。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月、<http://www.rfc-editor.org/info/rfc4379> 。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-editor.org/info/4659>.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP Virtual Private Network（VPN）Extension for IPv6 VPN」、RFC 4659、2006年9月、<http ：//www.rfc-editor.org/info/4659>。
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, March 2007, <http://www.rfc-editor.org/info/rfc4817>.
[RFC4817]タウンズリー、M。、ピグナタロ、C。、ウェインナー、S。、シーリー、T.、J。ヤング、「MPLS over Layer 2 Tunneling Protocol Version 3」、RFC 4817、2007年3月、<http： //www.rfc-editor.org/info/rfc4817>。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Minei、I.、and B. Thomas、 "LDP Specification"、RFC 5036、October 2007、<http://www.rfc-editor.org/info/rfc5036>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月、< http://www.rfc-editor.org/info/rfc6074>。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、2011年9月、<http://www.rfc-editor.org/info / rfc6370>。
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012, <http://www.rfc-editor.org/info/rfc6512>.
[RFC6512] Wijnands、IJ。、Rosen、E.、Napierala、M。、およびN. Leymann、「バックボーンにルートへのルートがない場合のマルチポイントLDPの使用」、RFC 6512、2012年2月、<http：// www .rfc-editor.org / info / rfc6512>。
[EVPN] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-11, October 2014.
[EVPN] Sajassi、A.、Aggarwal、R.、Bitar、N.、Isaac、A.、J。Uttaro、「BGP MPLSベースのイーサネットVPN」、作業中、draft-ietf-l2vpn-evpn-11、 2014年10月。
[IPv4-MAPPED] Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Considered Harmful", Work in Progress, draft-itojun-v6ops-v4mapped-harmful-02, October 2003.
[IPv4-MAPPED] Metz、C。およびJ. Hagino、「有害と見なされる回線上のIPv4-Mappedアドレス」、作業中、draft-itojun-v6ops-v4mapped-harmful-02、2003年10月。
[IPv6-RAO] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Option for MPLS OAM", Work in Progress, draft-raza-mpls-oam-ipv6-rao-02, September 2014.
[IPv6-RAO] Raza、K.、Akiya、N。、およびC. Pignataro、「MPLS OAMのIPv6ルーターアラートオプション」、作業中、draft-raza-mpls-oam-ipv6-rao-02、2014年9月。
[LDP-IPv6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, draft-ietf-mpls-ldp-ipv6-14, October 2014.
[LDP-IPv6] Asati、R.、Manral、V.、Papneja、R。、およびC. Pignataro、「IPv6のLDPのアップデート」、作業中、draft-ietf-mpls-ldp-ipv6-14、10月2014。
[LOOPBACK-PREFIX] Smith, M., "A Larger Loopback Prefix for IPv6", Work in Progress, draft-smith-v6ops-larger-ipv6-loopback-prefix-04, February 2013.
[LOOPBACK-PREFIX] Smith、M。、「IPv6のより大きなループバックプレフィックス」、作業中、draft-smith-v6ops-larger-ipv6-loopback-prefix-04、2013年2月。
[mLDP-NLRI] Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", Work in Progress, draft-ietf-l3vpn-mvpn-mldp-nlri-10, November 2014.
[mLDP-NLRI] Wijnands、I.、Rosen、E。、およびU. Joorde、「BGP MCAST-VPNルートのNLRIでのmLDP FECのエンコード」、作業中、draft-ietf-l3vpn-mvpn-mldp-nlri -10、2014年11月。
[MPLS-TC] Manral, V., Tsou, T., Will, W., and F. Fondelli, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", Work in Progress, draft-manral-mpls-rfc3811bis-04, September 2014.
[MPLS-TC] Manral、V.、Tsou、T.、Will、W.、F。Fondelli、「Definions of Textual Conventions（TCs）for Multiprotocol Label Switching（MPLS）Management」、Work in Progress、draft-manral -mpls-rfc3811bis-04、2014年9月。
[PE-CE] Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE-CE Protocol", Work in Progress, draft-ietf-l3vpn-mvpn-pe- ce-02, October 2014.
[PE-CE] Patel、K.、Rekhter、Y。、およびE. Rosen、「MVPN PE-CEプロトコルとしてのBGP」、作業中、draft-ietf-l3vpn-mvpn-pe-ce-02、10月2014。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月、<http：// www.rfc-editor.org/info/rfc1918>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月、<http://www.rfc-editor.org/ info / rfc3630>。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004, <http://www.rfc-editor.org/info/rfc3812>.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「Multiprotocol Label Switching（MPLS）Traffic Engineering（TE）Management Information Base（MIB）」、RFC 3812、2004年6月、<http：// www .rfc-editor.org / info / rfc3812>。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004, <http://www.rfc-editor.org/info/rfc3813>.
[RFC3813] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「Multiprotocol Label Switching（MPLS）Label Switching Router（LSR）Management Information Base（MIB）」、RFC 3813、2004年6月、<http：// www.rfc-editor.org/info/rfc3813>。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004, <http://www.rfc-editor.org/info/rfc3815>.
[RFC3815] Cucchiara、J.、Sjostrand、H。、およびJ. Luciani、「マルチプロトコルラベルスイッチング（MPLS）、ラベル配布プロトコル（LDP）の管理対象オブジェクトの定義」、RFC 3815、2004年6月、<http：/ /www.rfc-editor.org/info/rfc3815>。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>.
[RFC4090]パン、P。、スワロー、G。、およびA.アトラス、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月、<http://www.rfc-editor.org/ info / rfc4090>。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005, <http://www.rfc-editor.org/info/rfc4220>.
[RFC4220] Dubuc、M.、Nadeau、T。、およびJ. Lang、「Traffic Engineering Link Management Information Base」、RFC 4220、2005年11月、<http://www.rfc-editor.org/info/rfc4220> 。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、2006年2月、<http://www.rfc-editor.org/info/rfc4364>。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「Pseudowire Setup and Maintenance Using a Label Distribution Protocol（LDP）」、RFC 4447、2006年4月、<http://www.rfc-editor.org/info/rfc4447>。
[RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement", RFC 4558, June 2006, <http://www.rfc-editor.org/info/rfc4558>.
[RFC4558] Ali、Z.、Rahman、R.、Prairie、D。、およびD. Papadimitriou、「Node-ID Based Resource Reservation Protocol（RSVP）Hello：A Clarification Statement」、RFC 4558、2006年6月、<http： //www.rfc-editor.org/info/rfc4558>。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月、<http://www.rfc-editor.org/ info / rfc4655>。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4664] Andersson、L。およびE. Rosen、「Framework for Layer 2 Virtual Private Networks（L2VPNs）」、RFC 4664、2006年9月、<http://www.rfc-editor.org/info/rfc4664>。
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K。およびY. Rekhter、「自動検出およびシグナリングにBGPを使用する仮想プライベートLANサービス（VPLS）」、RFC 4761、2007年1月、<http://www.rfc-editor.org/info / rfc4761>。
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M。およびV. Kompella、「ラベル配布プロトコル（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、2007年1月、<http://www.rfc-editor.org/info / rfc4762>。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007, <http://www.rfc-editor.org/info/rfc4798>.
[RFC4798] De Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用したIPv4 MPLSを介したIPv6アイランドの接続」、RFC 4798、2007年2月、<http ：//www.rfc-editor.org/info/rfc4798>。
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>.
[RFC4802]ナドー、T。およびA.ファレル、「汎用マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月、<http://www.rfc-editor.org/info/rfc4802> 。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Papadimitriou、D。、およびS. Yasukawa、「Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switched Paths（LSPs）」、RFC 4875、 2007年5月、<http://www.rfc-editor.org/info/rfc4875>。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007, <http://www.rfc-editor.org/info/rfc4884>.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「拡張ICMPによるマルチパートメッセージのサポート」、RFC 4884、2007年4月、<http：//www.rfc-editor .org / info / rfc4884>。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007, <http://www.rfc-editor.org/info/rfc4950>.
[RFC4950] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「ICMP Extensions for Multiprotocol Label Switching」、RFC 4950、2007年8月、<http://www.rfc-editor.org / info / rfc4950>。
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks", RFC 4990, September 2007, <http://www.rfc-editor.org/info/rfc4990>.
[RFC4990] Shiomoto、K.、Papneja、R.、and R. Rabbat、 "Use of Addresses in Generalized Multiprotocol Label Switching（GMPLS）Networks、RFC 4990、September 2007、<http：//www.rfc-editor。 org / info / rfc4990>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P。、およびC. Pignataro、「一般化TTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月、<http：// www.rfc-editor.org/info/rfc5082>。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]ナドー、T。およびC.ピニャタロ、「疑似配線仮想回線接続検証（VCCV）：疑似配線の制御チャネル」、RFC 5085、2007年12月、<http://www.rfc-editor.org/info/ rfc5085>。
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008, <http://www.rfc-editor.org/info/rfc5088>.
[RFC5088] Le Roux、JL。、Vasseur、JP。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、January 2008、<http：// www .rfc-editor.org / info / rfc5088>。
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5089] Le Roux、JL。、Vasseur、JP。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、January 2008、<http：/ /www.rfc-editor.org/info/rfc5089>。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286] Atlas、A。およびA. Zinin、「IP Fast Reroute：Loop-Free Alternatesの基本仕様」、RFC 5286、2008年9月、<http://www.rfc-editor.org/info/rfc5286>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008, <http://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A.、and A. Lindem、 "Traffic Engineering Extensions to OSPF Version 3"、RFC 5329、September 2008、<http：//www.rfc-editor。 org / info / rfc5329>。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。とJL。 Le Roux、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月、<http://www.rfc-editor.org/info/rfc5440>。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009, <http://www.rfc-editor.org/info/rfc5512>.
[RFC5512] Mohapatra、P。およびE. Rosen、「BGPカプセル化後続アドレスファミリ識別子（SAFI）およびBGPトンネルカプセル化属性」、RFC 5512、2009年4月、<http://www.rfc-editor.org/ info / rfc5512>。
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R.、Vasseur、JP。、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、2009年4月、<http：// www .rfc-editor.org / info / rfc5520>。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「Extensions to the Path Computation Element Communication Protocol（PCEP）for Route Exclusions」、RFC 5521、2009年4月、<http：//www.rfc- editor.org/info/rfc5521>。
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, August 2009, <http://www.rfc-editor.org/info/rfc5640>.
[RFC5640] Filsfils、C.、Mohapatra、P。、およびC. Pignataro、「メッシュソフトワイヤーのロードバランシング」、RFC 5640、2009年8月、<http://www.rfc-editor.org/info/rfc5640> 。
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010, <http://www.rfc-editor.org/info/rfc5837>.
[RFC5837] Atlas、A.、Bonica、R.、Pignataro、C.、Shen、N.、JR。 Rivers、「Extending ICMP for Interface and Next-Hop Identification」、RFC 5837、2010年4月、<http://www.rfc-editor.org/info/rfc5837>。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010, <http://www.rfc-editor.org/info/rfc5884>.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月、<http：/ /www.rfc-editor.org/info/rfc5884>。
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885]ナドー、T。、およびC.ピグナタロ、「疑似配線仮想回線接続検証（VCCV）のための双方向転送検出（BFD）」、RFC 5885、2010年6月、<http://www.rfc-editor.org/ info / rfc5885>。
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010, <http://www.rfc-editor.org/info/rfc5886>.
[RFC5886] Vasseur、JP。、Le Roux、JL。、およびY. Ikejiri、「A Set Monitoring Tools for Path Computation Element（PCE）-Based Architecture」、RFC 5886、2010年6月、<http：// www。 rfc-editor.org/info/rfc5886>。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921] Bocci、M.、Bryant、S.、Frost、D.、Levrau、L。、およびL. Berger、「A Transport Framework in MPLS in MPLS」、RFC 5921、2010年7月、<http：// www .rfc-editor.org / info / rfc5921>。
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010, <http://www.rfc-editor.org/info/rfc6006>.
[RFC6006] Zhao、Q.、King、D.、Verhaeghe、F.、Takeda、T.、Ali、Z。、およびJ. Meuric、「拡張ポイントツーポイントのパス計算要素通信プロトコル（PCEP） Multipoint Traffic Engineering Label Switched Paths」、RFC 6006、2010年9月、<http://www.rfc-editor.org/info/rfc6006>。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]マティーニ、L。、メッツ、C。、ナドー、T。、ボッチ、M。、およびM.アイサウィー、「セグメント化された疑似配線」、RFC 6073、2011年1月、<http：//www.rfc-editor。 org / info / rfc6073>。
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6119]ハリソンJ.、バーガーJ.、およびM.バートレット、「IS-ISでのIPv6トラフィックエンジニアリング」、RFC 6119、2011年2月、<http://www.rfc-editor.org/info/rfc6119 >。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6371] Busi、I.およびD. Allan、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月、<http://www.rfc-editor.org/info/rfc6371 >。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388] Wijnands、IJ。、Minei、I.、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのラベル配布プロトコル拡張」、RFC 6388、2011年11月、<http://www.rfc-editor.org/info/rfc6388>。
[RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", RFC 6445, November 2011, <http://www.rfc-editor.org/info/rfc6445>.
[RFC6445] Nadeau、T.、Koushik、A。、およびR. Cetin、「高速リルート用のマルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング管理情報ベース」、RFC 6445、2011年11月、<http：//www.rfc- editor.org/info/rfc6445>。
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513] Rosen、E。およびR. Aggarwal、「Multicast in MPLS / BGP IP VPNs」、RFC 6513、2012年2月、<http://www.rfc-editor.org/info/rfc6513>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012, <http://rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、2012年2月、<http：// rfc -editor.org/info/rfc6514>。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012, <http://www.rfc-editor.org/info/rfc6540>.
[RFC6540] George W.、Donley、C.、Liljenstolpe、C。、およびL. Howard、「すべてのIP対応ノードに必要なIPv6サポート」、BCP 177、RFC 6540、2012年4月、<http：// www .rfc-editor.org / info / rfc6540>。
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, May 2012, <http://www.rfc-editor.org/info/rfc6624>.
[RFC6624] Kompella、K.、Kothari、B。、およびR. Cherukuri、「自動検出とシグナリングにBGPを使用するレイヤ2仮想プライベートネットワーク」、RFC 6624、2012年5月、<http：//www.rfc-editor .org / info / rfc6624>。
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012, <http://www.rfc-editor.org/info/rfc6720>.
[RFC6720] Pignataro、C。およびR. Asati、「ラベル配布プロトコル（LDP）の一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 6720、2012年8月、<http://www.rfc-editor.org/ info / rfc6720>。
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013, <http://www.rfc-editor.org/info/rfc6829>.
[RFC6829] Chen、M.、Pan、P.、Pignataro、C。、およびR. Asati、「IPv6経由でアドバタイズされる疑似回線転送等価クラス（FEC）のラベルスイッチドパス（LSP）ping」、RFC 6829、2013年1月、 <http://www.rfc-editor.org/info/rfc6829>。
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.
[RFC7117] Aggarwal、R.、Kamite、Y.、Fang、L.、Rekhter、Y。、およびC. Kodeboniya、「Multicast in Virtual Private LAN Service（VPLS）」、RFC 7117、2014年2月、<http：/ /www.rfc-editor.org/info/rfc7117>。
Acknowledgements
謝辞
The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their detailed reviews, as well as Brian Haberman, Joel Jaeggli, Adrian Farrel, Nobo Akiya, Francis Dupont, and Tobias Gondrom for their comments.
著者は、Alvaro Retana、Andrew Yourtchenko、Loa Andersson、David Allan、Mach Chen、Mustapha Aissaoui、およびMark Tinkaに感謝し、Brian Haberman、Joel Jaeggli、Adrian Farrel、Nobo Akiya、Francis Dupont、 Tobias Gondromのコメント。
Contributors
貢献者
The following people have contributed text to this document:
以下の人々がこの文書にテキストを寄稿しました：
Rajiv Asati Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 United States
Rajiv Asati Cisco Systems 7025 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
EMail: rajiva@cisco.com Kamran Raza Cisco Systems 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
Eメール：rajiva@cisco.com Kamran Raza Cisco Systems 2000 Innovation Driveオタワ、オンタリオK2K-3E8カナダ
EMail: skraza@cisco.com
Ronald Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 United States
Ronald Bonica Juniper Networks 2251 Corporate Park Drive Herndon、VA 20171アメリカ合衆国
EMail: rbonica@juniper.net
Rajiv Papneja Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 United States
Rajiv Papneja Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
EMail: rajiv.papneja@huawei.com
Dhruv Dhody Huawei Technologies Leela Palace Bangalore, Karnataka 560008 India
Dhruv Dhody Huawei Technologies Leela Palace Bangalore、Karnataka、560008 India
EMail: dhruv.ietf@gmail.com
Vishwas Manral Ionos Networks Sunnyvale, CA 94089 United States
Vishwas Maral Nino's Networksサニーベール、CA 94089アメリカ合衆国
EMail: vishwas@ionosnetworks.com Nagendra Kumar Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709 United States
Eメール：vishwas@ionosnetworks.com Nagendra Kumar Cisco Systems、Inc. 7200 Kit Creek Road Research Triangle Park、NC 27709 United States
EMail: naikumar@cisco.com
Authors' Addresses
著者のアドレス
Wesley George (editor) Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20111 United States
ウェズリージョージ（編集者）タイムワーナーケーブル13820サンライズバレードライブハーンドン、バージニア州20111アメリカ合衆国
Phone: +1-703-561-2540
EMail: wesley.george@twcable.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Carlos Pignataro（編集者）Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Phone: +1-919-392-7428
EMail: cpignata@cisco.com