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
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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).
この文書では、最も外側のMPLSラベル（即ち、トンネルラベル）はIPヘッダまたは総称ルーティングカプセル化（GRE）とIPヘッダのいずれかで置換されているBGP / MPLS IP仮想プライベートネットワーク（VPN）の実装戦略を記載しています。
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
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）ルータは一つ以上の仮想ルーティングおよび転送（VRF）インスタンスを維持します。 VRFインスタンスVPN固有の転送テーブルです。
PE routers exchange reachability information with one another using BGP [3] with multi-protocol extensions [4].
BGPを使用して互いにPEルータ交換到達可能性情報[3]マルチプロトコル拡張子を持つ[4]。
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それに添付してください。入力PEルータはVPNサイトからのパケットを受信すると、パケットの入口接続回線に関連付けられているVRFにパケットの宛先IPアドレスを検索します。この検索の結果、入口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 VPNの文脈において、この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）必要な転送動作は、転送パスに沿って各ホップで維持することができるように、情報は、トンネルLSPヘッダにVPNパケットからマッピングすることができます。
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.
セクション9と基準の10 [2]は、サービスプロバイダは、複数の自律システム間L3VPNサービスを提供する、より複雑な構成（すなわち、キャリアのキャリアおよびバックボーンマルチAS）を定義します。これらの構成では、VPNルートラベルは、ASの境界を越えて一緒にステッチすることができます。各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内に含まれます。一つの特定の構成（すなわち、インタープロバイダオプション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カプセル化のいずれかを使用して、入力PEルータは出力PEルータにネットワークを介してMPLSパケットを送信します。
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情報は、GRE / IPトンネルヘッダにVPNパケットからコピーすることができます。しかし、GRE / IPトンネルは、トンネルLSPが提供するすべてのトラフィックエンジニアリング機能が失われ、トラフィックエンジニアリング機能を欠いています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
"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 VPNは、MPLSラベルがパケットの入力PEルータとその出力PEルータ間のパス（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.
これらのルータは、必ずしもBGP / MPLS IP VPNをサポートしている必要がありますよう中継ルータは、MPLSまたはBGP / MPLS VPNをサポートする必要はないのに対し、この手順では、、、入力および出力PEルータ自体がMPLSをサポートしている必要がありますが、それは問題ではありません。
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ラベルスタックを追加し続けることで、VPNルートを識別するために、MPLSを使用し続けています。入力および出力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.アンインGRE MPLS-またはMPLSインIP [6]カプセル化はバックIPパケットに、上述したMPLSパケットを、有効に使用されます。これは、実際には、入口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-IP-またはMPLS・イン・GREのカプセル化を解くには、パケットの送信元IPアドレスを検証しない限り、フィルタリングは全く効果的な保護を提供していません。この文書では、カプセル化を解くにはトンネルパケットのIP送信元アドレスを検証する必要はありませんが、フィルタリングそうする失敗は効果的な宛先ベース（またはソースベースおよび宛先ベースの組み合わせ）があることを前提としていることを理解すべきです境界で。」
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.
入力PEルータは、カスタマーエッジ（CE）ルータからのパケットを受信すると、パケットのイングレス接続回線に関連付けられているVRFにパケットの宛先IPアドレスを検索します。これは、VPN-IPルートを見つけるために、（入力）PEルータを可能にします。 VPN-IPルートは、関連するVPNルートラベルと関連するBGPネクストホップを持つことになります。ラベルはパケットにプッシュされます。次に、IP（またはIP + GRE）カプセル化ヘッダは、MPLS-で-IP（又はMPLSインGRE）カプセル化パケットを作成、パケットの先頭に付加されています。カプセル化ヘッダのIPソース・アドレス・フィールドは、入口PEルータ自体のアドレスであろう。カプセル化ヘッダのIP宛先アドレスフィールドは、関連するBGPネクストホップの値を含むであろう。これは、出力PEルータのIPアドレスになります。必要な転送動作は、転送パスに沿って各ホップで維持することができるように、QoS情報は、GRE / IPトンネルヘッダにVPNパケットからコピーすることができます。
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アドレスは、[4] MP_REACH_NLRI BGP属性のネクストホップフィールドのネットワークアドレスから推測することができます。ネクストホップネットワークアドレスのセットが事前に知られていないが、VPN-IPルートのBGP分布を経由して動的に学習されることに注意してください。トンネル機能の首尾一貫したセットを仮定しても、リモートトンネルエンドポイントの先験的な構成が必要とされる、すべてのPEおよび自律システム境界ルータ（のASBR）の間に存在します。 IP（またはGRE）トンネルの動的作成が望まれる場合、PEとのASBRのセット全体は、同じトンネル能力を持たなければなりません。 IP（またはGRE）を使用する優先トンネルを設定する必要があります。二つ以上のトンネルメカニズム（すなわち、LSP、GRE、IP、等）を用いて、PEのセットは、ピアごとにトンネルタイプを決定しなければなりません。ピアごとにトンネル機能の自動関連付けは、今後の課題です。これらのトンネルは、IGP可視リンクされるべきではないことに注意してください、ルーティング隣接関係は、これらのトンネルを横切って支持されるべきではありません。
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-で-IP（又はMPLSイン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ソースアドレスを検証しなければなりません。
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ラベルは、無担保IPカプセル化に置き換えている場合は、GREまたは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、または「内部」と、加えて、所属するソースアドレスを有する、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.
これらのフィルタリストの保守、管理、集中することができます。さらに、実装に応じて、これらのフィルタリストは、パフォーマンスに影響することがあります。しかし、このようなフィルタは、VPNパケットのなりすましに対して（とりわけ）を保護するためにこれらのフィルタの場合は、追加のメンテナンスのオーバーヘッド、偽装されたVPNパケットに対する保護以外の理由で必要になることがありますすることはありません実用的な意義のものであってもよいです。単一の（または少数の）IPブロックのうちGREまたはIPトンネルに使用されるIPアドレスを割り当てることは、フィルタのメンテナンスを簡素化することができることに留意されたいです。
Security considerations in reference [6] apply here as well. Additional security issues are discussed in the previous section "Implications on Packet Spoofing".
リファレンスのセキュリティの考慮事項は、[6]ここにも適用されます。追加のセキュリティ問題は、前のセクション「パケットスプーフィングの影響」で説明されています。
Thanks to Robert Raszuk and Scott Wainner for their contributions to this document.
このドキュメントへの貢献のためのロバートRaszukとスコット・ワイナーに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[2]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル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]ベイツ、T.、チャンドラ、R.、カッツ、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]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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.ローゼン、 "IP又は総称ルーティングカプセル化（GRE）でカプセル化MPLS"、RFC 4023、2005年3月。
Authors' Addresses
著者のアドレス
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
ロナルドP. Bonicaジュニパーネットワークスの2251年コーポレートパークドライブハーンドン、VA 20171米国
EMail: rbonica@juniper.net
メールアドレス：rbonica@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719米国
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。