RFC 4797 - Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4797
タイトル : RFC 4797 - BGP/MPLS IP仮想ネットワークでのプロバイダーエッジエッジ（PE-PE）ジェネリックルーティングカプセル化（GRE）またはIPの使用
翻訳編集 : 自動生成

[要約] RFC 4797は、BGP/MPLS IP仮想プライベートネットワークでのプロバイダエッジからプロバイダエッジへの一般的なルーティングカプセル化（GRE）またはIPの使用に関するものです。このRFCの目的は、PE-PE間のトラフィックを効率的に転送するためのガイドラインを提供することです。

Network Working Group                                         Y. Rekhter
Request for Comments: 4797                                     R. Bonica
Category: Informational                                 Juniper Networks
                                                                E. Rosen
                                                     Cisco Systems, Inc.
                                                            January 2007

Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks

BGP/MPLS IP仮想ネットワークでのプロバイダーエッジエッジ（PE-PE）ジェネリックルーティングカプセル化（GRE）またはIPの使用

Status of This Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（c）The IETF Trust（2007）。

IESG Note

IESGノート

This document proposes an automated mechanism for establishing tunnels between provider-edge routers in a VPN, but does not provide an automated mechanism for establishing security associations for these tunnels. Without such a mechanism, this document is not appropriate for publication on the Internet standards track.

このドキュメントは、VPN内のプロバイダーエッジルーター間でトンネルを確立するための自動化されたメカニズムを提案していますが、これらのトンネルのセキュリティ関連を確立するための自動化されたメカニズムを提供しません。このようなメカニズムがなければ、このドキュメントはインターネット標準のトラックで公開するのに適していません。

Abstract

概要

This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).

このドキュメントでは、BGP/MPLS IP仮想プライベートネットワーク（VPNS）の実装戦略について説明します。ここでは、最も外側のMPLSラベル（つまり、トンネルラベル）がIPヘッダーまたは一般的なルーティングカプセル化（GRE）を備えたIPヘッダーに置き換えられます。

The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not.

本明細書で説明する実装戦略により、エッジデバイスがMPLSおよびVPN認識であるがインテリアデバイスがそうではないネットワークでBGP/MPLS IP VPNテクノロジーを展開できます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 4
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE  . . . . 5
     4.2.  MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . . 6
   5.  Implications on Packet Spoofing . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8

1. Introduction

1. はじめに

A "conventional" BGP/MPLS IP VPN [2] is characterized as follows:

「従来の」BGP/MPLS IP VPN [2]は、次のように特徴付けられます。

Each Provider Edge (PE) router maintains one or more Virtual Routing and Forwarding (VRF) instances. A VRF instances is a VPN-specific forwarding table.

各プロバイダーエッジ（PE）ルーターは、1つ以上の仮想ルーティングと転送（VRF）インスタンスを維持します。VRFインスタンスは、VPN固有の転送テーブルです。

PE routers exchange reachability information with one another using BGP [3] with multi-protocol extensions [4].

PEルーターは、マルチプロトコル拡張[4]を使用してBGP [3]を使用して、到達可能性情報を互いに交換します。

MPLS Label Switching Paths (LSPs) [5] connect PE routers to one another.

MPLSラベルスイッチングパス（LSP）[5] PEルーターを互いに接続します。

In simple configurations, the VPN service is offered by a single Autonomous System (AS). All service provider routers are contained by a single AS and all VPN sites attach to that AS. When an ingress PE router receives a packet from a VPN site, it looks up the packet's destination IP address in a VRF that is associated with the packet's ingress attachment circuit. As a result of this lookup, the ingress PE router determines an MPLS label stack, a data link header, and an output interface. The label stack is prepended to the packet, the data link header is prepended to that, and the resulting frame is queued for the output interface.

単純な構成では、VPNサービスは単一の自律システム（AS）によって提供されます。すべてのサービスプロバイダールーターは、単一のasとすべてのVPNサイトがそのasに添付されています。Ingress PEルーターがVPNサイトからパケットを受信すると、パケットのイングレスアタッチメント回路に関連付けられているVRFのパケットの宛先IPアドレスを調べます。このルックアップの結果、Ingress PEルーターは、MPLSラベルスタック、データリンクヘッダー、および出力インターフェイスを決定します。ラベルスタックはパケットに加えられ、データリンクヘッダーはそれに加えられ、結果のフレームは出力インターフェイスのためにキューに掲載されます。

The innermost label in the MPLS label stack is called the VPN route label. The VPN route label is significant and visible to the egress PE router only. It controls forwarding of the packet by the egress PE router.

MPLSラベルスタックの最も内側のラベルは、VPNルートラベルと呼ばれます。VPNルートラベルは重要であり、出力PEルーターのみに見えます。出力PEルーターによるパケットの転送を制御します。

The outermost label in the MPLS label stack is called the tunnel label. The tunnel label causes the packet to be delivered to the egress PE router that understands the VPN route label. Specifically, the tunnel label identifies an MPLS LSP that connects the ingress PE router to the egress PE router. In the context of BGP/MPLS IP VPNs, this LSP is called a tunnel LSP.

MPLSラベルスタックの最も外側のラベルは、トンネルラベルと呼ばれます。トンネルラベルにより、パケットはVPNルートラベルを理解している出力PEルーターに配信されます。具体的には、トンネルラベルは、イングレスPEルーターを出口PEルーターに接続するMPLS LSPを識別します。BGP/MPLS IP VPNSのコンテキストでは、このLSPはトンネルLSPと呼ばれます。

The tunnel LSP provides a forwarding path between the ingress and egress PE routers. Quality of service (QoS) information can be mapped from the VPN packet to the tunnel LSP header so that required forwarding behaviors can be maintained at each hop along the forwarding path.

トンネルLSPは、侵入と出口のPEルーターの間の転送パスを提供します。サービス品質（QOS）情報は、VPNパケットからトンネルLSPヘッダーにマッピングできるため、転送パスに沿った各ホップで必要な転送動作を維持できます。

Sections 9 and 10 of reference [2] define more complex configurations (i.e., carriers' carrier and multi-AS backbones) in which service providers offer L3VPN services across multiple autonomous systems. In these configurations, VPN route labels can be stitched together across AS boundaries. Within each AS, tunnel LSPs carry VPN packets from network edge to network edge.

参照[2]のセクション9および10では、サービスプロバイダーが複数の自律システムでL3VPNサービスを提供する、より複雑な構成（つまり、キャリアのキャリアとマルチASバックボーン）を定義します。これらの構成では、VPNルートラベルは境界として一緒にステッチできます。それぞれのAS内で、トンネルLSPはネットワークエッジからネットワークエッジまでのVPNパケットを運びます。

In most configurations, tunnel LSPs never traverse AS boundaries. The tunnel LSP is always contained within a single AS. In one particular configuration (i.e., Inter-provider Option C), tunnel LSPs may traverse AS boundaries.

ほとんどの構成では、トンネルLSPが境界として横断することはありません。トンネルLSPは常に単一のAS内に含まれています。1つの特定の構成（つまり、インタープロバイダーオプションC）では、トンネルLSPが境界として横断する場合があります。

This memo describes procedures for creating an MPLS packet that carries the VPN route label, but does not carry the tunnel label. Then, using either GRE or IP encapsulation, the ingress PE router sends the MPLS packet across the network to the egress PE router.

このメモは、VPNルートラベルを搭載しているがトンネルラベルを運ばないMPLSパケットを作成する手順について説明しています。次に、GREまたはIPカプセル化のいずれかを使用して、Ingress PEルーターは、ネットワークを介してMPLSパケットを出力PEルーターに送信します。

That is, a GRE or IP tunnel replaces the tunnel LSP that was present in "conventional" BGP/MPLS IP VPNs. Like the tunnel LSP, the GRE/IP tunnel provides a forwarding path between the ingress and egress PE routers. QoS information can be copied from the VPN packet to the GRE/IP tunnel header so that required forwarding behaviors can be maintained at each hop along the forwarding path. However, because the GRE/IP tunnel lacks traffic engineering capabilities, any traffic engineering features provided by the tunnel LSP are lost.

つまり、GREまたはIPトンネルは、「従来の」BGP/MPLS IP VPNに存在するトンネルLSPに取って代わります。トンネルLSPと同様に、GRE/IPトンネルは、侵入と出口のPEルーターの間の転送パスを提供します。QOS情報は、VPNパケットからGRE/IPトンネルヘッダーにコピーできるため、転送パスに沿って各ホップで必要な転送動作を維持できます。ただし、GRE/IPトンネルにはトラフィックエンジニアリング機能がないため、トンネルLSPが提供するトラフィックエンジニアリング機能は失われます。

2. Conventions Used In This Document

2. このドキュメントで使用されている規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [1]に記載されているように解釈される。

3. Motivation

3. モチベーション

"Conventional" BGP/MPLS IP VPNs require an MPLS Label Switched Path (LSP) between a packet's ingress PE router and its egress PE router. This means that a BGP/MPLS IP VPN cannot be implemented if there is a part of the path between the ingress and egress PE routers that does not support MPLS.

「従来の」BGP/MPLS IP VPNSには、パケットのイングレスPEルーターとその出口PEルーターの間のMPLSラベルスイッチ付きパス（LSP）が必要です。これは、MPLSをサポートしていない侵入と出口のPEルーターの間にパスの一部がある場合、BGP/MPLS IP VPNを実装できないことを意味します。

In order to enable BGP/MPLS IP VPNs to be deployed even when there are non-MPLS routers along the path between the ingress and egress PE routers, it is desirable to have an alternative, which allows the tunnel label to be replaced with either an IP or (IP + GRE) header. The encapsulation header would have the address of the egress PE router in its destination IP address field, and this would cause the packet to be delivered to the egress PE router.

BGP/MPLS IP VPNを、侵入と出口のPEルーターの間のパスに沿って非MPLSルーターがある場合でも展開できるようにするために、代替手段を持つことが望ましいため、トンネルラベルをいずれかに置き換えることができます。IPまたは（IP GRE）ヘッダー。カプセル化ヘッダーには、宛先IPアドレスフィールドに出口PEルーターのアドレスがあり、これにより、パケットが出口PEルーターに配信されます。

In this procedure, the ingress and egress PE routers themselves must support MPLS, but that is not an issue, as those routers must necessarily have BGP/MPLS IP VPN support, whereas the transit routers need not support MPLS or BGP/MPLS VPNs.

この手順では、侵入と出力のPEルーター自体はMPLSをサポートする必要がありますが、それらのルーターには必ずBGP/MPLS IP VPNサポートが必要なため、それは問題ではありません。

4. Specification

4. 仕様

In short, the technical approach specified here is:

要するに、ここで指定されている技術的アプローチは次のとおりです。

1. Continue to use MPLS to identify a VPN route, by continuing to add an MPLS label stack to the VPN packets. Between the ingress and egress PE router, the outermost member of the label stack will represent the VPN route label.

1. VPNパケットにMPLSラベルスタックを追加し続けることにより、MPLSを使用してVPNルートを識別します。侵入と出口のPEルーターの間で、ラベルスタックの最も外側のメンバーがVPNルートラベルを表します。

2. An MPLS-in-GRE or MPLS-in-IP [6] encapsulation will be used to turn the MPLS packet, described above, back into an IP packet. This, in effect, creates a GRE or an IP tunnel between the ingress PE router and the egress PE router.

2. MPLS-in-GREまたはMPLS-in-IP [6]カプセル化を使用して、上記のMPLSパケットをIPパケットに戻します。これにより、実際には、イングレスPEルーターと出力PEルーターの間にGREまたはIPトンネルが作成されます。

The net effect is that an MPLS packet gets sent through a GRE or an IP tunnel.

最終的な効果は、MPLSパケットがGREまたはIPトンネルを介して送信されることです。

Service providers must protect the above-mentioned IP or GRE tunnel as recommended in Section 8.2 of reference [6]. As stated in that document:

サービスプロバイダーは、参照[6]のセクション8.2で推奨されるように、上記のIPまたはGREトンネルを保護する必要があります。その文書で述べたように：

"If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside.

「トンネルが完全に単一の管理ドメイン内にある場合、境界でのアドレスフィルタリングを使用して、トンネルエンドポイントのIPソースアドレスまたはトンネルエンドポイントのIP宛先アドレスを使用してパケットがないことを確認できます。。

However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet.

ただし、トンネルヘッドとトンネルの尾が同じ管理ドメインにない場合、これは困難になる可能性があり、パケットがパブリックインターネットを通過する必要がある場合、宛先アドレスに基づくフィルタリングは不可能になる可能性があります。

Sometimes only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE validates the IP source address of the packet. This document does not require that the decapsulator validate the IP source address of the tunneled packets, but it should be understood that failure to do so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries."

場合によっては、管理ドメインの境界でソースアドレスフィルタリング（宛先アドレスフィルタリングではなく）のみが実行される場合があります。この場合、MPLS-in-IPまたはMPLS-in-GRSの脱カプセレーターがパケットのIPソースアドレスを検証しない限り、フィルタリングは効果的な保護をまったく提供しません。このドキュメントでは、カプセレータがトンネルパケットのIPソースアドレスを検証することは必要ありませんが、そうしないと、効果的な宛先ベースの（またはソースベースと宛先ベースの組み合わせ）フィルタリングがあることを前提としていることを理解する必要があります。境界で。」

4.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE

4.1. MPLS-in-IP/MPLS-in-gre-in-greのカプセル化によるPE

The following description is not meant to specify an implementation strategy; any implementation procedure that produces the same result is acceptable.

次の説明は、実装戦略を指定することではありません。同じ結果を生成する実装手順は受け入れられます。

When an ingress PE router receives a packet from a Customer Edge (CE) router, it looks up the packet's destination IP address in a VRF that is associated with the packet's ingress attachment circuit. This enables the (ingress) PE router to find a VPN-IP route. The VPN-IP route will have an associated VPN route label and an associated BGP Next Hop. The label is pushed on the packet. Then an IP (or IP+GRE) encapsulation header is prepended to the packet, creating an MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. The IP source address field of the encapsulation header will be an address of the ingress PE router itself. The IP destination address field of the encapsulation header will contain the value of the associated BGP Next Hop; this will be an IP address of the egress PE router. QoS information can be copied from the VPN packet to the GRE/IP tunnel header so that required forwarding behaviors can be maintained at each hop along the forwarding path.

Ingress PEルーターが顧客エッジ（CE）ルーターからパケットを受信すると、パケットのイングレスアタッチメント回路に関連付けられているVRFでパケットの宛先IPアドレスを調べます。これにより、（イングレス）PEルーターがVPN-IPルートを見つけることができます。VPN-IPルートには、関連するVPNルートラベルと関連するBGP Next Hopがあります。ラベルはパケットにプッシュされます。次に、IP（またはIP GRE）カプセル化ヘッダーがパケットに加えられ、MPLS-in-IP（またはMPLS-in-GRE）カプセル化されたパケットが作成されます。カプセル化ヘッダーのIPソースアドレスフィールドは、Ingress PEルーター自体のアドレスになります。カプセル化ヘッダーのIP宛先アドレスフィールドには、関連するBGP Next Hopの値が含まれます。これは、出力PEルーターのIPアドレスになります。QOS情報は、VPNパケットからGRE/IPトンネルヘッダーにコピーできるため、転送パスに沿って各ホップで必要な転送動作を維持できます。

The IP address of the remote tunnel endpoints MAY be inferred from the Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute [4]. Note that the set of Next Hop Network Addresses is not known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. Assuming a consistent set of tunnel capabilities exist between all the PEs and Autonomous System Border Routers (ASBRs), no a priori configuration of the remote tunnel endpoints is needed. The entire set of PE and ASBRs MUST have the same tunnel capabilities if the dynamic creation of IP (or GRE) tunnels is desired. The preference to use an IP (or GRE) tunnel MUST be configured. A set of PEs using two or more tunnel mechanisms (i.e., LSP, GRE, IP, etc.) MUST determine the tunnel type on a per-peer basis. The automatic association of tunnel capabilities on a per-peer basis is for future study. Note that these tunnels SHOULD NOT be IGP-visible links, and routing adjacencies SHOULD NOT be supported across these tunnel.

リモートトンネルエンドポイントのIPアドレスは、MP_REACH_NLRI BGP属性の次のホップフィールドのネットワークアドレスから推測できます[4]。次のホップネットワークアドレスのセットは事前に知られていないが、VPN-IPルートのBGP分布を介して動的に学習されることに注意してください。すべてのPESと自律システムの境界ルーター（ASBR）の間に一貫した一連のトンネル機能が存在すると仮定すると、リモートトンネルエンドポイントのアプリオリ構成は必要ありません。IP（またはGRE）トンネルの動的な作成が必要な場合、PEとASBRのセット全体に同じトンネル機能が必要です。IP（またはGRE）トンネルを使用する優先度を構成する必要があります。2つ以上のトンネルメカニズム（つまり、LSP、GRE、IPなど）を使用したPESのセットは、ピアごとにトンネルタイプを決定する必要があります。ピアごとにトンネル能力の自動関連は、将来の研究のためです。これらのトンネルはIGP可視リンクであってはならないことに注意してください。また、ルーティングの隣接は、これらのトンネル全体でサポートされてはなりません。

4.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE

4.2. MPLS-in-IP/MPLS-in-gre脱カプセル化による出口PEによる

Every egress PE is also an ingress PE, and hence has the ability to decapsulate MPLS-in-IP (or MPLS-in-GRE) packets. After decapsulation, the packets SHOULD be delivered to the routing function for ordinary MPLS switching.

すべての出力PEは侵入PEでもあるため、MPLS-in-IP（またはMPLS-in-GRE）パケットを脱カプセル化する能力があります。脱カプセル化後、パケットは通常のMPLSスイッチングのルーティング関数に配信する必要があります。

As stated above, if the service provider deploys source-based filtering at network edges to protect the IP/GRE tunnel (instead of destination-based filtering), the decapsulator must validate the IP source address of the tunneled packets.

上記のように、サービスプロバイダーがネットワークエッジでソースベースのフィルタリングを展開して（宛先ベースのフィルタリングの代わりに）IP/GREトンネルを保護する場合、脱カプセーターはトンネルパケットのIPソースアドレスを検証する必要があります。

5. Implications on Packet Spoofing

5. パケットスプーフィングへの影響

It should be noted that if the tunnel MPLS labels are replaced with an unsecured IP encapsulation, like GRE or IP, it becomes more difficult to protect the VPNs against spoofed packets. This is because a Service Provider (SP) can protect against spoofed MPLS packets by the simple expedient of not accepting MPLS packets from outside its own boundaries (or more generally, by keeping track of which labels are validly received over which interfaces, and discarding packets that arrive with labels that are not valid for their incoming interfaces).

トンネルMPLSラベルがGREやIPなどの無担保IPカプセル化に置き換えられている場合、VPNをスプーフィングされたパケットから保護することがより困難になることに注意してください。これは、サービスプロバイダー（SP）が、MPLSパケットを独自の境界から受け入れないという単純な手段により（またはより一般的には、どのラベルがインターフェイス上で有効に受信され、パケットを破棄することにより、単純なMPLSパケットから保護できるためです。それは、着信インターフェイスに有効でないラベルで到着します）。

By contrast, protection against spoofed IP packets requires all SP boundary routers to perform filtering; either (a) filtering packets from "outside" the SP, which are addressed to PE routers, or (b) filtering packets from "outside" the SP, which have source addresses that belong "inside" and, in addition, filtering on each PE all packets that have source addresses that belong "outside" the SP.

対照的に、スプーフィングされたIPパケットに対する保護には、フィルタリングを実行するためにすべてのSP境界ルーターが必要です。（a）PEルーターにアドレス指定されたspの「外部」からのフィルタリングパケット、または（b）「内側」に属するソースアドレスがあり、さらにそれぞれのフィルタリングを「外側」からフィルタリングするパケットをフィルタリングするPE sp。

The maintenance of these filter lists can be management intensive. Furthermore, depending upon implementation, these filter lists can be performance affecting. However, such filters may be required for reasons other than protection against spoofed VPN packets, in which case the additional maintenance overhead of these filters to protect (among other things) against spoofing of VPN packets may be of no practical significance. Note that allocating IP addresses used for GRE or IP tunnels out of a single (or a small number of) IP block could simplify maintenance of the filters.

これらのフィルターリストのメンテナンスは、管理集約的です。さらに、実装に応じて、これらのフィルターリストはパフォーマンスに影響を与える可能性があります。ただし、そのようなフィルターは、Spoofed VPNパケットからの保護以外の理由で必要になる場合があります。この場合、VPNパケットのスプーフィングから（とりわけ）保護するためのこれらのフィルターの追加メンテナンスオーバーヘッドは、実際的に意味がない場合があります。単一（または少数の）IPブロックからGREまたはIPトンネルに使用されるIPアドレスを割り当てることで、フィルターのメンテナンスを簡素化できることに注意してください。

6. Security Considerations

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

Security considerations in reference [6] apply here as well. Additional security issues are discussed in the previous section "Implications on Packet Spoofing".

参照[6]のセキュリティ上の考慮事項もここにも適用されます。追加のセキュリティの問題については、前のセクション「パケットスプーフィングへの影響」で説明します。

7. Acknowledgments

7. 謝辞

Thanks to Robert Raszuk and Scott Wainner for their contributions to this document.

この文書への貢献をしてくれたロバート・ラシュクとスコット・ウェインナーに感謝します。

8. Normative References

8. 引用文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[2] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[2] Rosen、E。and Y. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。

[3] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[3] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。

[4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

[4] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。

[5] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[5] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。

[6] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.

[6] Worster、T.、Rekhter、Y。、およびE. Rosen、「IPまたは一般的なルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。

Authors' Addresses

著者のアドレス

Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US

Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US

   EMail: yakov@juniper.net

Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US

Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon、VA 20171 US

   EMail: rbonica@juniper.net

Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US

エリック・C・ローゼン・シスコ・システムズ、1414マサチューセッツ・アベニュー・ボックスボロー、マサチューセッツ州01719米国

   EMail: erosen@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。