RFC4797 日本語訳
4797 Use of Provider Edge to Provider Edge (PE-PE) Generic RoutingEncapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks. Y.Rekhter, R. Bonica, E. Rosen. January 2007. (Format: TXT=18985 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Rekhter Request for Comments: 4797 R. Bonica Category: Informational Juniper Networks E. Rosen Cisco Systems, Inc. January 2007
Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 4797年のR.Bonicaカテゴリ: 情報の杜松は2007年1月にE.ローゼンシスコシステムズInc.をネットワークでつなぎます。
Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks
プロバイダー縁の(PE-PE)一般ルーティングのカプセル化(GRE)へのプロバイダー縁かBGP/MPLS IP仮想私設網における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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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ラベル(すなわち、トンネルラベル)がGenericルート設定Encapsulation(GRE)と共にIPヘッダーかIPヘッダーのどちらかに取り替えられるBGP/MPLS IP Virtual兵士のNetworks(VPNs)のために実現戦略を説明します。
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技術の展開を可能にします。
Rekhter, et al. Informational [Page 1] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [1ページ]情報のRFC4797L3VPN GRE2007年1月
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.4 3を使用しました。 動機. . . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 仕様. . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1。 イングレスPE. . . . 5 4.2によるGREのIPにおけるMPLS/MPLSカプセル化。 出口PE. . . . . 6 5によるGREのIPにおけるMPLS/MPLS被膜剥離術。 パケットスプーフィング. . . . . . . . . . . . . . . . 7 6での含意。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 7。 承認. . . . . . . . . . . . . . . . . . . . . . . . 7 8。 引用規格. . . . . . . . . . . . . . . . . . . . . 8
Rekhter, et al. Informational [Page 2] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [2ページ]情報のRFC4797L3VPN GRE2007年1月
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.
それぞれのProvider Edge(PE)ルータは1Virtualのルート設定とForwarding(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 Label Switching Paths(LSPs)[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サービスは独身のAutonomous System(AS)によって提供されます。 すべてのサービスプロバイダールータがサイトがそのASに取り付ける独身のASとすべてのVPNによって含まれています。 イングレスPEルータがVPNサイトからパケットを受けるとき、それはパケットのイングレス付属サーキットに関連しているVRFのパケットの送付先IPアドレスを調べます。 このルックアップの結果、イングレスPEルータはMPLSラベルスタック、データ・リンクヘッダー、および出力インタフェースを決定します。 ラベルスタックはパケットにprependedされます、そして、データ・リンクヘッダーはそれにprependedされます、そして、結果として起こるフレームは出力インタフェースへ列に並ばせられます。
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ルータを提供します。 推進経路に沿った各ホップで必要な推進の振舞いを維持できるようにVPNパケットからトンネルLSPヘッダーまでサービスの質(QoS)情報を写像できます。
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
参照[2]のセクション9と10はサービスプロバイダーが複数の自律システムの向こう側にサービスをL3VPNに提供するより複雑な構成(すなわち、キャリアズキャリアとマルチAS背骨)を定義します。これらの構成では、VPNルートラベルは一緒にステッチできます。
Rekhter, et al. Informational [Page 3] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [3ページ]情報のRFC4797L3VPN GRE2007年1月
across AS boundaries. Within each AS, tunnel LSPs carry VPN packets from network edge to network edge.
AS境界の向こう側に。 各ASの中では、トンネルLSPsはネットワーク縁からネットワーク縁まで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.
ほとんどの構成では、トンネルLSPsはAS境界を決して横断しません。 トンネルLSPは独身のASの中にいつも含まれています。 1つの特定の構成(すなわち、Inter-プロバイダーOption C)では、トンネルLSPsはAS境界を横断するかもしれません。
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 VPNsで存在しているトンネルLSPを取り替えます。 トンネルLSPのように、GRE/IPトンネルはイングレスと出口の間の推進経路にPEルータを提供します。 推進経路に沿った各ホップで必要な推進の振舞いを維持できるようにVPNパケットからGRE/IPトンネルヘッダーまでQoS情報をコピーできます。 しかしながら、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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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 Label Switched Path(LSP)を必要とします。 これは、イングレスと出口PEルータの間のMPLSを支持しない経路の一部があれば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.
イングレスと出口PEルータの間の経路に沿って非MPLSルータありさえするときさえ、BGP/MPLS IP VPNsが配備されるのを可能にするために、代替手段を持っているのは望ましいです。(代替手段は、トンネルラベルが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を支持しなければなりませんが、それは問題ではありません、トランジットルータがMPLSかBGP/MPLS VPNsを支持する必要はありませんがそれらのルータにBGP/MPLS IP VPNサポートが必ずなければならないとき。
Rekhter, et al. Informational [Page 4] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [4ページ]情報のRFC4797L3VPN GRE2007年1月
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. GREのMPLSかIPにおけるMPLS[6]カプセル化は、上で説明されたMPLSパケットをIPパケットに変わって戻させるのに使用されるでしょう。 有効なこれはイングレスPEルータと出口PEルータの間のGREかIPトンネルを作成します。
The net effect is that an MPLS packet gets sent through a GRE or an IP tunnel.
ネットの効果はGREかIPトンネルを通してMPLSパケットを送るということです。
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."
時々、管理ドメインの境界でソースアドレスフィルタリング(どんな送付先アドレスもフィルターにかけられないのを除いて)だけをします。 これがそうであり、IPにおけるMPLSかGREのMPLSのdecapsulatorがパケットのIPソースアドレスを有効にしない場合、フィルタリングは全く有効保護を提供しません。 「このドキュメントは、decapsulatorがトンネルを堀られたパケットのIPソースアドレスを有効にするのを必要としませんが、そうしない場合有効な目的地ベース(または、ソースベースと目的地ベースの組み合わせ)のフィルタリングが境界にあるのを予想するのが理解されるべきです。」
4.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE
4.1. イングレスPEによるGREのIPにおけるMPLS/MPLSカプセル化
The following description is not meant to specify an implementation strategy; any implementation procedure that produces the same result is acceptable.
以下の記述は実現戦略を指定することになっていません。 同じ結果を生むどんな実現手順も許容できます。
Rekhter, et al. Informational [Page 5] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [5ページ]情報のRFC4797L3VPN GRE2007年1月
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ルータがCustomer Edge(CE)ルータからパケットを受けるとき、それはパケットのイングレス付属サーキットに関連しているVRFのパケットの送付先IPアドレスを調べます。 これは、(イングレス)PEルータがVPN-IPルートを見つけるのを可能にします。 VPN-IPルートには、関連VPNルートラベルと関連BGP Next Hopがあるでしょう。 ラベルはパケットで押されます。 そして、IPにおけるMPLS(または、GREのMPLS)の要約のパケットを作成して、IP(または、IP+GRE)カプセル化ヘッダーはパケットにprependedされます。 カプセル化ヘッダーのIPソースアドレス・フィールドはイングレスPEルータ自体のアドレスになるでしょう。 カプセル化ヘッダーの受信者IPアドレス分野は関連BGP Next Hopの値を含むでしょう。 これは出口PEルータのIPアドレスになるでしょう。 推進経路に沿った各ホップで必要な推進の振舞いを維持できるようにVPNパケットからGRE/IPトンネルヘッダーまでQoS情報をコピーできます。
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]のNext Hop分野のNetwork Addressから推論されるかもしれません。 Next Hop Network Addressesのセットがあらかじめ知られていませんが、VPN-IPルートのBGP分配でダイナミックに学習されることに注意してください。 一貫したトンネル能力がすべてのPEsとAutonomous System Border Routers(ASBRs)の間に存在すると仮定して、遠く離れたトンネル終点の先験的な構成は全く必要ではありません。 PEとASBRsの全体のセットに、IP(または、GRE)トンネルのダイナミックな創造が望まれているなら、同じトンネル能力がなければなりません。 IP(または、GRE)トンネルを使用する好みを構成しなければなりません。 2つ以上のトンネルメカニズム(すなわち、LSP、GRE、IPなど)を使用するPEsの1セット aのトンネルタイプが決定しなければならない、-、同輩基礎。 今後の研究には1同輩あたり1個のベースに関するトンネル能力の自動協会があります。 目に見えるIGPリンクと、隣接番組SHOULD NOTを発送することであるこれらのトンネルSHOULD NOTがこれらのトンネルの向こう側に支持されることに注意してください。
4.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE
4.2. 出口PEによるGREのIPにおけるMPLS/MPLS被膜剥離術
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であり、したがって、IPにおけるdecapsulate MPLS(または、GREのMPLS)パケットに能力を持っています。 後被膜剥離術、パケットSHOULD、普通の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トンネル(目的地ベースのフィルタリングの代わりに)を保護するためにネットワーク縁でソースベースのフィルタリングを配備するなら、decapsulatorはトンネルを堀られたパケットのIPソースアドレスを有効にしなければなりません。
Rekhter, et al. Informational [Page 6] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [6ページ]情報のRFC4797L3VPN GRE2007年1月
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ラベルを非安全にされたIPカプセル化に取り替えるなら、GREやIPのように、だまされたパケットに対してVPNsを保護するのが、より難しくなることに注意されるべきです。 これはService Provider(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境界ルータを必要とします。 (SPは、パケットをフィルターにかけながら、PEルータ、または(b)に記述されます)。SPは属するソースアドレスを持っています。“inside"と各PEでさらに、そうしたすべてのパケットをフィルターにかけると、」 SPの外では、「外で」属するアドレスは出典を明示されます。(a) パケットをフィルターにかける、「外」からのSP、「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ブロックはフィルタの維持を簡素化するかもしれません。
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.
このドキュメントへの彼らの貢献をロバートRaszukとスコットWainnerをありがとうございます。
Rekhter, et al. Informational [Page 7] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [7ページ]情報のRFC4797L3VPN GRE2007年1月
8. Normative References
8. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[2] ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 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)」、RFC4271 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インチのためのMultiprotocol拡張子、RFC4760、2007年1月。」
[5] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[5] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[6] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[6] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約します」、RFC4023(2005年3月)。
Rekhter, et al. Informational [Page 8] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [8ページ]情報のRFC4797L3VPN GRE2007年1月
Authors' Addresses
作者のアドレス
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
ヤコフRekhter Juniperは1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
ロナルドP.Bonica杜松は米国でDriveハーンドン、2251の法人のParkヴァージニア 20171をネットワークでつなぎます。
EMail: rbonica@juniper.net
メール: rbonica@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
Boxborough、エリックC.ローゼンシスコシステムズInc.1414MA01719米国マサチューセッツ通り
EMail: erosen@cisco.com
メール: erosen@cisco.com
Rekhter, et al. Informational [Page 9] RFC 4797 L3VPN GRE January 2007
Rekhter、他 [9ページ]情報のRFC4797L3VPN GRE2007年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Rekhter, et al. Informational [Page 10]
Rekhter、他 情報[10ページ]
一覧
スポンサーリンク