[要約] RFC 3809は、プロバイダが提供する仮想プライベートネットワーク（PPVPN）の一般的な要件を定義しています。このRFCの目的は、異なるネットワーク間でセキュアな通信を可能にするための標準化とガイドラインの提供です。
Network Working Group A. Nagarajan, Ed.
Request for Comments: 3809 Juniper Networks
Category: Informational June 2004
Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)
プロバイダープロビジョニング済み仮想プライベートネットワーク（PPVPN）の一般的な要件
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 Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.
このドキュメントは、プロバイダープロビジョニングされた仮想プライベートネットワーク（PPVPN）の一般的な要件について説明しています。要件は、サービス要件、プロバイダーの要件、エンジニアリング要件に分類されます。これらの要件は、特定のタイプのPPVPNテクノロジーに固有のものではなく、すべてのPPVPNテクノロジーに適用されます。すべてのPPVPNテクノロジーは、このドキュメントで説明されている傘のセットの要件を満たすことが期待されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Scenarios. . . . . . . . . . . . . . . . . . . 4
1.3. Outline of this document. . . . . . . . . . . . . . . . . 5
2. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions and Taxonomy . . . . . . . . . . . . . . . . . . . 7
4. Service Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.1. Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Data Isolation. . . . . . . . . . . . . . . . . . . . . . 9
4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.1. User data security . . . . . . . . . . . . . . . . 10
4.5.2. Access Control . . . . . . . . . . . . . . . . . . 10
4.5.3. Site authentication and authorization. . . . . . . 10
4.5.4. Inter domain security. . . . . . . . . . . . . . . 10
4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Quality of Service . . . . . . . . . . . . . . . . . . . 11
4.9. Service Level Agreement and Service Level Specification
Monitoring and Reporting. . . . . . . . . . . . . . . . . 13
4.10.Network Resource Partitioning and Sharing between VPNs. . 14
5. Provider requirements. . . . . . . . . . . . . . . . . . . . . 14
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Service Provider Capacity Sizing Projections . . . 15
5.1.2. VPN Scalability aspects. . . . . . . . . . . . . . 15
5.1.3. Solution-Specific Metrics. . . . . . . . . . . . . 17
5.2. Management . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Customer Management of a VPN . . . . . . . . . . . 18
6. Engineering requirements . . . . . . . . . . . . . . . . . . . 19
6.1. Forwarding plane requirements . . . . . . . . . . . . . . 19
6.2. Control plane requirements. . . . . . . . . . . . . . . . 20
6.3. Control Plane Containment . . . . . . . . . . . . . . . . 20
6.4. Requirements related to commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms. . . 21
6.5. Interoperability . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References. . . . . . . . . . . . . . . . . . . 23
8.2. Informative References. . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 24
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
This document is an output of the design team formed to develop requirements for PPVPNs in the Provider Provisioned Virtual Private Networks (PPVPN) working group and provides requirements that are generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3 Virtual Private Networks (L3VPN). This document discusses generic PPVPN requirements categorized as service, provider and engineering requirements. These are independent of any particular type of PPVPN technology. In other words, all PPVPN technologies are expected to meet the umbrella set of requirements described in this document. PPVPNs may be constructed across single or multiple provider networks and/or Autonomous Systems (ASes). In most cases the generic requirements described in this document are independent of the deployment scenario. However, specific requirements that differ based on whether the PPVPN is deployed across single or multiple providers (and/or ASes) will be pointed out in the document. Specific requirements related to Layer 3 PPVPNs are described in [L3REQTS]. Similarly, requirements that are specific to layer 2 PPVPNs are described in [L2REQTS].
このドキュメントは、プロバイダープロビジョニング仮想プライベートネットワーク（PPVPN）ワーキンググループのPPVPNの要件を開発するために形成された設計チームの出力であり、レイヤー2仮想プライベートネットワーク（L2VPN）とレイヤー3仮想プライベートネットワークの両方に汎用的な要件を提供します。l3vpn）。このドキュメントでは、サービス、プロバイダー、エンジニアリングの要件に分類される一般的なPPVPN要件について説明します。これらは、特定のタイプのPPVPNテクノロジーから独立しています。言い換えれば、すべてのPPVPNテクノロジーは、このドキュメントで説明されている要件の傘のセットを満たすことが期待されています。PPVPNは、単一または複数のプロバイダーネットワークおよび/または自律システム（ASES）で構築できます。ほとんどの場合、このドキュメントで説明されている一般的な要件は、展開シナリオとは無関係です。ただし、PPVPNが単一のプロバイダーまたは複数のプロバイダー（および/またはASE）に展開されているかどうかによって異なる特定の要件は、ドキュメントで指摘されます。レイヤー3 PPVPNに関連する特定の要件は、[L3REQTS]で説明されています。同様に、レイヤー2 PPVPNに固有の要件は、[L2REQTS]で説明されています。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Corporations and other organizations have become increasingly dependent on their networks for telecommunications and data communication. The data communication networks were originally built as Local Area Networks (LAN). Over time the possibility to interconnect the networks on different sites has become more and more important. The connectivity for corporate networks has been supplied by service providers, mainly as Frame Relay (FR) or Asynchronous Transfer Mode (ATM) connections, and more recently as Ethernet and IP-based tunnels. This type of network, interconnecting a number of sites over a shared network infrastructure is called Virtual Private Network (VPN). If the sites belong to the same organization, the VPN is called an Intranet. If the sites belong to different organizations that share a common interest, the VPN is called an Extranet.
企業やその他の組織は、電気通信とデータ通信のためのネットワークにますます依存しています。データ通信ネットワークは、もともとローカルエリアネットワーク（LAN）として構築されていました。時間が経つにつれて、さまざまなサイトでネットワークを相互接続する可能性はますます重要になりました。企業ネットワークの接続性は、主にフレームリレー（FR）または非同期転送モード（ATM）接続として、そして最近ではイーサネットおよびIPベースのトンネルとして、サービスプロバイダーによって提供されています。共有ネットワークインフラストラクチャを介して多くのサイトを相互接続するこのタイプのネットワークは、仮想プライベートネットワーク（VPN）と呼ばれます。サイトが同じ組織に属している場合、VPNはイントラネットと呼ばれます。サイトが共通の関心を共有するさまざまな組織に属している場合、VPNはエクストラネットと呼ばれます。
Customers are looking for service providers to deliver data and telecom connectivity over one or more shared networks, with service level assurances in the form of security, QoS and other parameters.
顧客は、セキュリティ、QoS、その他のパラメーターの形でサービスレベルの保証を備えた、1つ以上の共有ネットワークを介したデータとテレコム接続を提供するサービスプロバイダーを探しています。
In order to provide isolation between the traffic belonging to different customers, mechanisms such as Layer 2 connections or Layer 2/3 tunnels are necessary. When the shared infrastructure is an IP network, the tunneling technologies that are typically used are IPsec, MPLS, L2TP, GRE, IP-in-IP etc.
さまざまな顧客に属するトラフィック間の分離を提供するには、レイヤー2接続やレイヤー2/3トンネルなどのメカニズムが必要です。共有インフラストラクチャがIPネットワークである場合、通常使用されるトンネリングテクノロジーは、IPSEC、MPLS、L2TP、GRE、IP-in-IPなどです。
Traditional Internet VPNs have been based on IPsec to provide security over the Internet. Service providers are now beginning to deploy enhanced VPN services that provide features such as service differentiation, traffic management, Layer 2 and Layer 3 connectivity, etc. in addition to security. Newer tunneling mechanisms have certain features that allow the service providers to provide these enhanced VPN services.
従来のインターネットVPNは、インターネット上でセキュリティを提供するためのIPSECに基づいています。サービスプロバイダーは現在、セキュリティに加えて、サービス差別化、トラフィック管理、レイヤー2、レイヤー3接続などの機能を提供する拡張VPNサービスの展開を開始しています。新しいトンネリングメカニズムには、サービスプロバイダーがこれらの拡張されたVPNサービスを提供できる特定の機能があります。
The VPN solutions we define now MUST be able to accommodate the traditional types of VPNs as well as the enhanced services now being deployed. They need to be able to run in a single service provider's network, as well as between a set of service providers and across the Internet. In doing so the VPNs SHOULD NOT be allowed to violate basic Internet design principles or overload the Internet core routers or accelerate the growths of the Internet routing tables. Specifically, Internet core routers SHALL NOT be required to maintain VPN-related information, regardless of whether the Internet routing protocols are used to distribute this information or not. In order to achieve this, the mechanisms used to develop various PPVPN solutions SHALL be as common as possible with generic Internet infrastructure mechanisms like discovery, signaling, routing and management. At the same time, existing Internet infrastructure mechanisms SHALL NOT be overloaded.
現在定義しているVPNソリューションは、従来のタイプのVPNと、現在展開されている拡張サービスに対応できる必要があります。彼らは、単一のサービスプロバイダーのネットワークで、および一連のサービスプロバイダー間とインターネット全体の間で実行できる必要があります。そうすることで、VPNは、基本的なインターネット設計原則に違反したり、インターネットコアルーターに過負荷になったり、インターネットルーティングテーブルの成長を加速したりすることを許可されてはなりません。具体的には、インターネットルーティングプロトコルがこの情報の配布に使用されるかどうかにかかわらず、VPN関連の情報を維持するためにインターネットコアルーターを必要としません。これを達成するために、さまざまなPPVPNソリューションを開発するために使用されるメカニズムは、発見、シグナル、ルーティング、管理などの一般的なインターネットインフラストラクチャメカニズムと可能な限り共通するものとします。同時に、既存のインターネットインフラストラクチャメカニズムは過負荷でなければなりません。
Another generic requirement from a standardization perspective is to limit the number of different solution approaches. For example, for service providers that need to support multiple types of VPN services, it may be undesirable to require a completely different solution approach for each type of VPN service.
標準化の観点からの別の一般的な要件は、異なるソリューションアプローチの数を制限することです。たとえば、複数のタイプのVPNサービスをサポートする必要があるサービスプロバイダーの場合、各タイプのVPNサービスに対して完全に異なるソリューションアプローチを必要とすることは望ましくない場合があります。
There are three different deployment scenarios that need to be considered for PPVPN services:
PPVPNサービスで考慮する必要がある3つの異なる展開シナリオがあります。
1. Single-provider, single-AS: This is the least complex scenario, where the PPVPN service is offered across a single service provider network spanning a single Autonomous System.
1. 単一プロバイダー、シングルAS：これは最も複雑ではないシナリオであり、PPVPNサービスは、単一の自律システムにまたがる単一のサービスプロバイダーネットワークで提供されます。
2. Single-provider, multi-AS: In this scenario, a single provider may have multiple Autonomous Systems (for e.g., a global Tier-1 ISP with different ASes depending on the global location, or an ISP that has been created by mergers and acquisitions of multiple networks). This scenario involves the constrained distribution of routing information across multiple Autonomous Systems.
2. 単一プロバイダー、マルチAS：このシナリオでは、単一のプロバイダーに複数の自律システムがある場合があります（たとえば、グローバルな場所に応じて異なるASEを持つグローバルTier-1 ISP、または合併と買収によって作成されたISP複数のネットワークの）。このシナリオには、複数の自律システムにわたるルーティング情報の制約された配布が含まれます。
3. Multi-provider: This scenario is the most complex, wherein trust negotiations need to be made across multiple service provider backbones in order to meet the security and service level agreements for the PPVPN customer. This scenario can be generalized to cover the Internet, which comprises of multiple service provider networks. It should be noted that customers can construct their own VPNs across multiple providers. However such VPNs are not considered here as they would not be "Provider-provisioned".
3. マルチプロバイダー：このシナリオは最も複雑であり、PPVPN顧客のセキュリティおよびサービスレベルの契約を満たすために、複数のサービスプロバイダーバックボーンにわたって信頼交渉を行う必要があります。このシナリオは、複数のサービスプロバイダーネットワークで構成されるインターネットをカバーするために一般化できます。顧客は複数のプロバイダーで独自のVPNを構築できることに注意する必要があります。ただし、そのようなVPNは、「プロバイダーがプロビジョニングされている」ため、ここでは考慮されません。
A fourth scenario, "Carrier's carrier" VPN may also be considered. In this scenario, a service provider (for example, a Tier 1 service provider) provides VPN service to another service provider (for example, a Tier 2 service provider), which in turn provides VPN service on its VPN to its customers. In the example given above, the Tier 2 provider's customers are contained within the Tier 2 provider's network, and the Tier 2 provider itself is a customer of the Tier 1 provider's network. Thus, this scenario is not treated separately in the document, because all of the single provider requirements would apply equally to this case.
4番目のシナリオ「キャリアのキャリア」VPNも考慮される場合があります。このシナリオでは、サービスプロバイダー（ティア1サービスプロバイダーなど）が別のサービスプロバイダー（ティア2サービスプロバイダーなど）にVPNサービスを提供し、VPNサービスをVPNに顧客に提供します。上記の例では、Tier 2プロバイダーの顧客はTier 2プロバイダーのネットワークに含まれており、Tier 2プロバイダー自体はTier 1プロバイダーのネットワークの顧客です。したがって、このシナリオは、すべての単一プロバイダー要件がこのケースに等しく適用されるため、ドキュメントで個別に扱われません。
It is expected that many of the generic requirements described in this document are independent of the three deployment scenarios listed above. However, specific requirements that are indeed dependent on the deployment scenario will be pointed out in this document.
このドキュメントで説明されている一般的な要件の多くは、上記の3つの展開シナリオとは無関係であると予想されます。ただし、展開シナリオに実際に依存する特定の要件は、このドキュメントで指摘されます。
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The document contains several sections, with each set representing a significant aspect of PPVPN requirements.
このドキュメントは、プロバイダープロビジョニングされた仮想プライベートネットワーク（PPVPN）の一般的な要件について説明しています。ドキュメントにはいくつかのセクションが含まれており、各セットはPPVPN要件の重要な側面を表しています。
Section 2 lists authors who contributed to this document. Section 3 defines terminology and presents a taxonomy of PPVPN technologies. The taxonomy contains two broad classes, representing Layer 2 and Layer 3 VPNs. Each top level VPN class contains subordinate classes. For example, the Layer 3 VPN class contains a subordinate class of PE-based Layer 3 VPNs.
セクション2には、このドキュメントに貢献した著者をリストします。セクション3では、用語を定義し、PPVPNテクノロジーの分類法を提示します。分類法には、レイヤー2とレイヤー3 VPNを表す2つの幅広いクラスが含まれています。各トップレベルVPNクラスには、下位クラスが含まれています。たとえば、レイヤー3 VPNクラスには、PEベースのレイヤー3 VPNの下位クラスが含まれています。
Sections 4, 5, 6 describe generic PPVPN requirements.
セクション4、5、6は、汎用PPVPN要件について説明します。
The requirements are broadly classified under the following categories:
要件は、次のカテゴリに広く分類されています。
1) Service requirements - Service attributes that the customer can observe or measure. For example, does the service forward frames or route datagrams? What security guarantees does the service provide? Availability and stability are key requirements in this category.
1) サービス要件 - 顧客が観察または測定できるサービス属性。たとえば、サービスはフォワードフレームまたはルートデータグラムですか？このサービスはどのようなセキュリティ保証を提供しますか？このカテゴリでは、可用性と安定性が重要な要件です。
2) Provider requirements - Characteristics that Service Providers use to determine the cost-effectiveness of a PPVPN service. Scaling and management are examples of Provider requirements.
2) プロバイダーの要件 - サービスプロバイダーがPPVPNサービスの費用対効果を決定するために使用する特性。スケーリングと管理は、プロバイダーの要件の例です。
3) Engineering requirements - Implementation characteristics that make service and provider requirements achievable. These can be further classified as:
3) エンジニアリング要件 - サービスとプロバイダーの要件を達成可能にする実装特性。これらはさらに分類できます。
3a) Forwarding plane requirements - e.g., requirements related to router forwarding behavior.
3a）転送面の要件 - 例えば、ルーター転送挙動に関連する要件。
3b) Control plane requirements - e.g., requirements related to reachability and distribution of reachability information.
3b）制御プレーンの要件 - たとえば、到達可能性情報の到達可能性と分布に関連する要件。
3c) Requirements related to the commonality of PPVPN mechanisms with each other and with generic Internet mechanisms.
3c）PPVPNメカニズムの共通性に関連する要件は、互いに、および一般的なインターネットメカニズムを使用します。
This document was the combined effort of several individuals that were part of the Service Provider focus group whose intentions were to present Service Provider view on the general requirements for PPVPN. A significant set of requirements were directly taken from previous work by the PPVPN WG to develop requirements for Layer 3 PPVPN [L3REQTS]. The existing work in the L2 requirements area has also influenced the contents of this document [L2REQTS].
このドキュメントは、PPVPNの一般的な要件に関するサービスプロバイダーの見解を提示する意図があったサービスプロバイダーフォーカスグループの一部であった複数の個人の合計努力でした。レイヤー3 PPVPN [L3REQTS]の要件を開発するために、PPVPN WGによる以前の研究から、重要な要件セットが直接取得されました。L2要件領域の既存の作業は、このドキュメント[L2REQTS]の内容にも影響を与えています。
Besides the editor, the following are the authors that contributed to this document:
編集者に加えて、このドキュメントに貢献した著者は次のとおりです。
Loa Andersson (loa@pi.se) Ron Bonica (ronald.p.bonica@mci.com) Dave McDysan (dave.mcdysan@mci.com) Junichi Sumimoto (j.sumimoto@ntt.com) Muneyoshi Suzuki (suzuki.muneyoshi@lab.ntt.co.jp) David Meyer (dmm@1-4-5.net) Marco Carugi (marco.carugi@nortelnetworks.com) Yetik Serbest (yetik_serbest@labs.sbc.com) Luyuan Fang (luyuanfang@att.com) Javier Achirica (achirica@telefonica.net)
loa andersson（loa@pi.se）ron bonica（ronald.p.bonica@mci.com）dave mcdysan（dave.mcdysan@mci.com）Junichi sumimoto（j.sumimoto@ntt.com）Muneyoshi Suzuki（Suzuki.Muneyoshi@lab.ntt.co.jp）David Meyer（dmm@1-4-5.net）marco carugi（marco.carugi@nortelnetworks.com）Yetik Serbest（Yetik_serbest@labs.sbc.com）luyuan fang（luyuanfang@att att att.com）javier achirica（achirica@telefonica.net）
The terminology used in this document is defined in [TERMINOLOGY]. In addition the following terminology is used:
このドキュメントで使用される用語は、[用語]で定義されています。さらに、次の用語が使用されます。
Site: a geographical location with one or more users or one or more servers or a combination of servers and users.
サイト：1つ以上のユーザーまたは1つ以上のサーバー、またはサーバーとユーザーの組み合わせを備えた地理的位置。
User: the end user equipment (hosts), e.g., a workstation.
ユーザー：エンドユーザー機器（ホスト）、たとえばワークステーション。
PPVPN
________________|__________________
| |
Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________
| | | |
PE-based CE-based PE-based CE-based
|__________|
______|_____
| |
P2P P2MP
The figure above presents a taxonomy of PPVPN technologies. PE-based and CE-based Layer 2 VPNs may also be further classified as point-to-point (P2P) or point-to-multipoint (P2MP). It is also the intention of the working group to have a limited number of solutions, and this goal must be kept in mind when proposing solutions that meet the requirements specified in this document. Definitions for CE-based and PE-based PPVPNs can be obtained from [L3FRAMEWORK]. Layer 2 specific definitions can be obtained from [L2FRAMEWORK].
上の図は、PPVPNテクノロジーの分類法を示しています。PEベースおよびCEベースのレイヤー2 VPNは、ポイントツーポイント（P2P）またはポイントツーマルチポイント（P2MP）としてさらに分類することもできます。また、ワーキンググループが限られた数のソリューションを持つことを意図していることであり、このドキュメントで指定された要件を満たすソリューションを提案する際には、この目標を念頭に置いておく必要があります。CEベースおよびPEベースのPPVPNの定義は、[L3Framework]から取得できます。レイヤー2の特定の定義は、[l2framework]から取得できます。
These are the requirements that a customer can observe or measure, in order to verify if the PPVPN service that the Service Provider (SP) provides is satisfactory. As mentioned before, each of these requirements apply equally across each of the three deployment scenarios unless stated otherwise.
これらは、サービスプロバイダー（SP）が提供するPPVPNサービスが満足できるかどうかを確認するために、顧客が観察または測定できる要件です。前述のように、これらの要件はそれぞれ、特に明記しない限り、3つの展開シナリオのそれぞれに等しく適用されます。
VPN services MUST have high availability. VPNs that are distributed over several sites require connectivity to be maintained even in the event of network failures or degraded service.
VPNサービスには高可用性が必要です。いくつかのサイトに分布しているVPNは、ネットワークの障害や劣化したサービスがあった場合でも、接続を維持する必要があります。
This can be achieved via various redundancy techniques such as:
これは、次のようなさまざまな冗長性手法で実現できます。
1. Physical Diversity
1. 物理的な多様性
A single site connected to multiple CEs (for CE-based PPVPNs) or PEs (for PE-based PPVPNs), or different POPs, or even different service providers.
複数のCE（CEベースのPPVPNS用）またはPES（PEベースのPPVPNS用）、または異なるPOP、または異なるサービスプロバイダーに接続された単一のサイト。
2. Tunnel redundancy
2. トンネル冗長性
Redundant tunnels may be set up between the PEs (in a PE-based PPVPN) or the CEs (in a CE-based PPVPN) so that if one tunnel fails, VPN traffic can continue to flow across the other tunnel that has already been set-up in advance.
PES（PEベースのPPVPN）またはCES（CEベースのPPVPN）の間に冗長トンネルを設置できるため、1つのトンネルが故障した場合、VPNトラフィックはすでに設定されている他のトンネルを横切って流れ続けることができます。-up事前に。
Tunnel redundancy may be provided over and above physical diversity. For example, a single site may be connected to two CEs (for CE-based PPVPNs) or two PEs (for PE-based PPVPNs). Tunnels may be set up between each of the CEs (or PEs as the case may be) across different sites.
トンネルの冗長性は、物理的な多様性以上に提供される場合があります。たとえば、単一のサイトは、2つのCE（CEベースのPPVPNSの場合）または2つのPE（PEベースのPPVPNSの場合）に接続できます。異なるサイトで各CE（または場合によってはPESがある場合がある場合）の間にトンネルを設置できます。
Of course, redundancy means additional resources being used, and consequently, management of additional resources, which would impact the overall scaling of the service.
もちろん、冗長性とは、追加のリソースが使用され、その結果、サービスの全体的なスケーリングに影響を与える追加のリソースの管理を意味します。
It should be noted that it is difficult to guarantee high availability when the VPN service is across multiple providers, unless there is a negotiation between the different service providers to maintain the service level agreement for the VPN customer.
VPN顧客のサービスレベル契約を維持するためのさまざまなサービスプロバイダー間の交渉がない限り、VPNサービスが複数のプロバイダーに渡っている場合、高可用性を保証することは困難であることに注意する必要があります。
In addition to availability, VPN services MUST also be stable. Stability is a function of several components such as VPN routing, signaling and discovery mechanisms, in addition to tunnel stability. For example, in the case of routing, route flapping or routing loops MUST be avoided in order to ensure stability. Stability of the VPN service is directly related to the stability of the mechanisms and protocols used to establish the service. It SHOULD also be possible to allow network upgrades and maintenance procedures without impacting the VPN service.
可用性に加えて、VPNサービスも安定している必要があります。安定性は、トンネルの安定性に加えて、VPNルーティング、シグナル伝達、および発見メカニズムなど、いくつかのコンポーネントの関数です。たとえば、ルーティングの場合、安定性を確保するために、ルーティングまたはルーティングループを避ける必要があります。VPNサービスの安定性は、サービスの確立に使用されるメカニズムとプロトコルの安定性に直接関連しています。また、VPNサービスに影響を与えることなく、ネットワークのアップグレードとメンテナンス手順を許可することも可能です。
VPN services MUST support unicast (or point to point) traffic and SHOULD support any-to-any or point-to-multipoint traffic including multicast and broadcast traffic. In the broadcast model, the network delivers a stream to all members of a subnetwork, regardless of their interest in that stream. In the multicast model, the network delivers a stream to a set of destinations that have registered interest in the stream. All destinations need not belong to the same subnetwork. Multicast is more applicable to L3 VPNs while broadcast is more applicable to L2VPNs. It is desirable to support multicast limited in scope to an intranet or extranet. The solution SHOULD be able to support a large number of such intranet or extranet specific multicast groups in a scalable manner.
VPNサービスは、ユニキャスト（またはポイントツーポイント）トラフィックをサポートする必要があり、マルチキャストやブロードキャストトラフィックを含む、任意またはポイントツーマルチポイントトラフィックをサポートする必要があります。ブロードキャストモデルでは、ネットワークは、そのストリームへの関心に関係なく、サブネットワークのすべてのメンバーにストリームを提供します。マルチキャストモデルでは、ネットワークはストリームに関心を登録した一連の目的地にストリームを提供します。すべての目的地は、同じサブネットワークに属する必要はありません。マルチキャストはL3 VPNにより適用可能ですが、ブロードキャストはL2VPNにより適用できます。イントラネットまたはエクストラネットの範囲でマルチキャストリミテッドをサポートすることが望ましいです。このソリューションは、スケーラブルな方法で多数のこのようなイントラネットまたはエクストラネット固有のマルチキャストグループをサポートできる必要があります。
All PPVPN approaches SHALL support both IPv4 and IPv6 traffic. Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) SHALL be supported via encapsulation in IP or MPLS tunnels in the case of L2VPNs.
すべてのPPVPNアプローチは、IPv4とIPv6トラフィックの両方をサポートするものとします。特定のL2トラフィックタイプ（ATM、フレームリレー、イーサネットなど）は、L2VPNSの場合のIPまたはMPLSトンネルのカプセル化を介してサポートされるものとします。
The PPVPN MUST support forwarding plane isolation. The network MUST never deliver user data across VPN boundaries unless the two VPNs participate in an intranet or extranet.
PPVPNは、転送面の分離をサポートする必要があります。2つのVPNがイントラネットまたはエクストラネットに参加しない限り、ネットワークはVPN境界を越えてユーザーデータを配信してはなりません。
Furthermore, if the provider network receives signaling or routing information from one VPN, it MUST NOT reveal that information to another VPN unless the two VPNs participate in an intranet or extranet. It should be noted that the disclosure of any signaling/routing information across an extranet MUST be filtered per the extranet agreement between the organizations participating in the extranet.
さらに、プロバイダーネットワークが1つのVPNから信号またはルーティング情報を受信した場合、2つのVPNがイントラネットまたはエクストラネットに参加しない限り、その情報を別のVPNに明らかにしてはなりません。エクストラネット間の信号/ルーティング情報の開示は、エクストラネットに参加している組織間のエクストラネット契約に従ってフィルタリングする必要があることに注意する必要があります。
A range of security features SHOULD be supported by the suite of PPVPN solutions in the form of securing customer flows, providing authentication services for temporary, remote or mobile users, and the need to protect service provider resources involved in supporting a PPVPN. These security features SHOULD be implemented based on the framework outlined in [VPN-SEC]. Each PPVPN solution SHOULD state which security features it supports and how such features can be configured on a per customer basis. Protection against Denial of Service (DoS) attacks is a key component of security mechanisms. Examples of DoS attacks include attacks to the PE or CE CPUs, access connection congestion, TCP SYN attacks and ping attacks.
さまざまなセキュリティ機能は、顧客フローを保護する形式での一連のPPVPNソリューションによってサポートされ、一時的、リモートユーザー、またはモバイルユーザーに認証サービスを提供し、PPVPNのサポートに関与するサービスプロバイダーリソースを保護する必要性をサポートする必要があります。これらのセキュリティ機能は、[VPN-SEC]で概説されているフレームワークに基づいて実装する必要があります。各PPVPNソリューションは、どのセキュリティ機能がサポートするか、およびそのような機能を顧客ごとに構成する方法を述べる必要があります。サービス拒否（DOS）攻撃に対する保護は、セキュリティメカニズムの重要な要素です。DOS攻撃の例には、PEまたはCE CPUへの攻撃、アクセス接続輻輳、TCP Syn攻撃、PING攻撃が含まれます。
Some security mechanisms (such as use of IPsec on a CE-to-CE basis) may be equally useful regardless of the scope of the VPN. Other mechanisms may be more applicable in some scopes than in others. For example, in some cases of single-provider single-AS VPNs, the VPN service may be isolated from some forms of attack by isolating the infrastructure used for supporting VPNs from the infrastructure used for other services. However, the requirements for security are common regardless of the scope of the VPN service.
いくつかのセキュリティメカニズム（CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CESの使用など）は、VPNの範囲に関係なく同様に役立つ場合があります。他のメカニズムは、他のメカニズムよりもいくつかのスコープでより適用できる場合があります。たとえば、Single-Provider single-as VPNの場合には、VPNサービスは、他のサービスに使用されるインフラストラクチャからのVPNをサポートするために使用されるインフラストラクチャを分離することにより、何らかの形の攻撃から分離される場合があります。ただし、VPNサービスの範囲に関係なく、セキュリティの要件は一般的です。
PPVPN solutions that support user data security SHOULD use standard methods (e.g., IPsec) to achieve confidentiality, integrity, authentication and replay attack prevention. Such security methods MUST be configurable between different end points, such as CE-CE, PE-PE, and CE-PE. It is also desirable to configure security on a per-route or per-VPN basis. User data security using encryption is especially desirable in the multi-provider scenario.
ユーザーデータセキュリティをサポートするPPVPNソリューションは、標準的な方法（IPSECなど）を使用して、機密性、完全性、認証、およびリプレイ攻撃防止を実現する必要があります。このようなセキュリティ方法は、CE-CE、PE-PE、CE-PEなどの異なるエンドポイント間で構成可能でなければなりません。また、ルートごとまたはVPNごとにセキュリティを構成することも望ましいです。暗号化を使用したユーザーデータセキュリティは、マルチプロバイダーシナリオで特に望ましいものです。
A PPVPN solution may also have the ability to activate the appropriate filtering capabilities upon request of a customer. A filter provides a mechanism so that access control can be invoked at the point(s) of communication between different organizations involved in an extranet. Access control can be implemented by a firewall, access control lists on routers, cryptographic mechanisms or similar mechanisms to apply policy-based access control. Access control MUST also be applicable between CE-CE, PE-PE and CE-PE. Such access control mechanisms are desirable in the multi-provider scenario.
PPVPNソリューションには、顧客の要求に応じて適切なフィルタリング機能をアクティブにする機能もあります。フィルターはメカニズムを提供し、エクストラネットに関与するさまざまな組織間の通信のポイントでアクセス制御を呼び出すことができます。アクセス制御は、ファイアウォール、ルーターのアクセス制御リスト、暗号化メカニズム、またはポリシーベースのアクセス制御を適用する同様のメカニズムによって実装できます。アクセス制御は、CE-CE、PE-PE、CE-PEの間にも適用する必要があります。このようなアクセス制御メカニズムは、マルチプロバイダーシナリオで望ましいです。
A PPVPN solution requires authentication and authorization of the following:
PPVPNソリューションでは、以下の認証と承認が必要です。
- temporary and permanent access for users connecting to sites (authentication and authorization BY the site)
- サイトに接続するユーザー向けの一時的および恒久的なアクセス（サイトによる認証と承認）
- the site itself (authentication and authorization FOR the site)
- サイト自体（サイトの認証と承認）
The VPN solution MUST have appropriate security mechanisms to prevent the different kinds of Distributed Denial of Service (DDoS) attacks mentioned earlier, misconfiguration or unauthorized accesses in inter domain PPVPN connections. This is particularly important for multi-service provider deployment scenarios. However, this will also be important in single-provider multi-AS scenarios.
VPNソリューションには、前述のさまざまな種類の分散サービス拒否（DDOS）攻撃、誤解、またはインタードメインPPVPN接続における不正アクセスを防ぐための適切なセキュリティメカニズムが必要です。これは、マルチサービスプロバイダーの展開シナリオにとって特に重要です。ただし、これは単一プロバイダーMulti-ASシナリオでも重要です。
A VPN SHOULD support arbitrary, customer-defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. These can actually be different from the topology used by the service provider. To the extent possible, a PPVPN service SHOULD be independent of the geographic extent of the deployment.
VPNは、たとえば、ハブアンドスポークから部分的なメッシュからフルメッシュトポロジまで、任意の顧客定義の敷地間接続をサポートする必要があります。これらは、実際には、サービスプロバイダーが使用するトポロジーとは異なる場合があります。可能な限り、PPVPNサービスは、展開の地理的範囲とは無関係でなければなりません。
Multiple VPNs per customer site SHOULD be supported without requiring additional hardware resources per VPN. This SHOULD also include a free mix of L2 and L3 VPNs.
VPNごとに追加のハードウェアリソースを必要とせずに、顧客サイトごとの複数のVPNをサポートする必要があります。これには、L2とL3 VPNの無料ミックスも含める必要があります。
To the extent possible, the PPVPN services SHOULD be independent of access network technology.
可能な限り、PPVPNサービスはアクセスネットワークテクノロジーとは独立している必要があります。
Each customer resource MUST be identified by an address that is unique within its VPN. It need not be identified by a globally unique address.
各顧客リソースは、VPN内で一意のアドレスによって識別される必要があります。グローバルにユニークなアドレスで識別する必要はありません。
Support for private addresses as described in [RFC1918], as well as overlapping customer addresses SHALL be supported. One or more VPNs for each customer can be built over the same infrastructure without requiring any of them to renumber. The solution MUST NOT use NAT on the customer traffic to achieve that goal. Interconnection of two networks with overlapping IP addresses is outside the scope of this document.
[RFC1918]で説明されているプライベートアドレスのサポートと、重複する顧客アドレスがサポートされます。各顧客の1つ以上のVPNは、同じインフラストラクチャの上に構築することができます。ソリューションは、その目標を達成するために顧客トラフィックにNATを使用してはなりません。2つのネットワークと重複するIPアドレスの相互接続は、このドキュメントの範囲外です。
A VPN service SHALL be capable of supporting non-IP customer addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g., Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses may be desirable in some cases, but is beyond the scope of VPN solutions developed in the IETF, and therefore, this document.
VPNサービスは、レイヤー2 VPN（フレームリレー、ATM、イーサネットなど）の場合、カプセル化技術を介して非IPカスタマーアドレスをサポートできるものとします。非IPレイヤー3アドレスのサポートは、場合によっては望ましい場合がありますが、IETFで開発されたVPNソリューションの範囲を超えているため、このドキュメントがあります。
A technical approach for supporting VPNs SHALL be able to support QoS via IETF standardized mechanisms such as Diffserv. Support for best-effort traffic SHALL be mandatory for all PPVPN types. The extent to which any specific VPN service will support QoS is up to the service provider. In many cases single-provider single-AS VPNs will offer QoS guarantees. Support of QoS guarantees in the multi-service-provider case will require cooperation between the various service providers involved in offering the service.
VPNをサポートするための技術的アプローチは、IETF標準化されたメカニズムを介してQOSをサポートできるものとします。すべてのPPVPNタイプには、ベストエフォルトトラフィックのサポートが必須でなければなりません。特定のVPNサービスがQoSをサポートする程度は、サービスプロバイダー次第です。多くの場合、単一プロバイダーシングルAS VPNはQoS保証を提供します。マルチサービスプロバイダーケースでのQoS保証のサポートには、サービスの提供に関与するさまざまなサービスプロバイダー間の協力が必要になります。
It should be noted that QoS mechanisms in the multi-provider scenario REQUIRES each of the participating providers to support the mechanisms being used, and as such, this is difficult to achieve.
マルチプロバイダーシナリオのQoSメカニズムには、各参加プロバイダーが使用されているメカニズムをサポートする必要があるため、これを達成することは困難であることに注意する必要があります。
Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing.
QoSを含むすべてのケースでは、CEおよび/またはPEがシェーピングおよび/またはポリシングを実行する必要がある場合があることに注意してください。
The need to provide QoS will occur primarily in the access network, since that will often be the bottleneck. This is likely to occur since the backbone effectively statistically multiplexes many users, and is traffic engineered or includes capacity for restoration and growth. Hence in most cases PE-PE QoS is not a major issue. As far as access QoS is concerned, there are two directions of QoS management that may be considered in any PPVPN service regarding QoS:
QoSを提供する必要性は、主にアクセスネットワークで発生します。これは、多くの場合ボトルネットになるためです。これは、バックボーンが多くのユーザーを効果的に統計的に多重化し、トラフィックエンジニアリングされているか、回復と成長の能力を含むため、これが発生する可能性があります。したがって、ほとんどの場合、PE-PE QOSは大きな問題ではありません。Access QOSに関する限り、QOSに関するQOS管理には2つの方向があります。
- From the CE across the access network to the PE - From the PE across the access network to CE
- CEからアクセスネットワークを横切るCEからPEまで - アクセスネットワークを横切るPEからCEまで
PPVPN CE and PE devices SHOULD be capable of supporting QoS across at least the following subset of access networks, as applicable to the specific type of PPVPN (L2 or L3). However, to the extent possible, the QoS capability of a PPVPN SHOULD be independent of the access network technology:
PPVPN CEデバイスとPEデバイスは、特定のタイプのPPVPN（L2またはL3）に適用されるように、少なくとも以下のアクセスネットワークのサブセットでQoSをサポートできる必要があります。ただし、可能な限り、PPVPNのQOS機能は、アクセスネットワークテクノロジーとは独立している必要があります。
- ATM Virtual Connections (VCs) - Frame Relay Data Link Connection Identifiers (DLCIs) - 802.1d Prioritized Ethernet - MPLS-based access - Multilink Multiclass PPP - QoS-enabled wireless (e.g., LMDS, MMDS) - Cable modem - QoS-enabled Digital Subscriber Line (DSL)
- ATM仮想接続（VCS） - フレームリレーデータリンク接続識別子（DLCIS）-802.1D優先イーサネット-MPLSベースのアクセス - マルチリンクマルチクラスPPP -QOS対応ワイヤレス（LMDS、MMDSなど） - ケーブルモデム-QOS対応デジタルデジタルデジタルサブスクライバーライン（DSL）
Different service models for QoS may be supported. Examples of PPVPN QoS service models are:
QoSのさまざまなサービスモデルがサポートされる場合があります。PPVPN QOSサービスモデルの例は次のとおりです。
- Managed access service: Provides QoS on the access connection between CE and the customer facing ports of the PE. No QoS support is required in the provider core network in this case.
- マネージドアクセスサービス：CEとPEのポートに面した顧客の間のアクセス接続にQOを提供します。この場合、プロバイダーコアネットワークではQoSサポートは必要ありません。
- Edge-to-edge QoS: Provides QoS across the provider core, either between CE pairs or PE pairs, depending on the tunnel demarcation points. This scenario requires QoS support in the provider core network. As mentioned above, this is difficult to achieve in a multi-provider VPN offering.
- エッジツーエッジQos：トンネルの境界点に応じて、CEペアまたはPEペアの間のプロバイダーコア全体にQOを提供します。このシナリオには、プロバイダーコアネットワークでQoSサポートが必要です。上記のように、これはマルチプロバイダーVPN製品で達成することが困難です。
A Service Level Specification (SLS) may be defined per access network connection, per VPN, per VPN site, and/or per VPN route. The service provider may define objectives and the measurement interval for at least the SLS using the following Service Level Objective (SLO) parameters:
サービスレベルの仕様（SLS）は、アクセスネットワーク接続、VPNごと、VPNサイト、および/またはVPNルートごとに定義できます。サービスプロバイダーは、少なくとも次のサービスレベル目標（SLO）パラメーターを使用して、少なくともSLSの目標と測定間隔を定義できます。
- QoS and traffic parameters for the Intserv flow or Diffserv class [Y.1541]
- IntServ FlowまたはDiffServクラスのQoSおよびトラフィックパラメーター[Y.1541]
- Availability for the site, VPN, or access connection
- サイト、VPN、またはアクセス接続の可用性
- Duration of outage intervals per site, route or VPN
- サイト、ルート、またはVPNごとの停止間隔の期間
- Service activation interval (e.g., time to turn up a new site)
- サービスアクティベーション間隔（たとえば、新しいサイトを上げる時間）
- Trouble report response time interval
- 報告の対応時間間隔を報告します
- Time to repair interval
- 間隔を修復する時間
- Total traffic offered to the site, route or VPN
- サイト、ルート、またはVPNに提供される総トラフィック
- Measure of non-conforming traffic for the site, route or VPN
- サイト、ルート、またはVPNの不適合トラフィックの測定
- Delay and delay variation (jitter) bounds
- 遅延および遅延変動（ジッター）の境界
- Packet ordering, at least when transporting L2 services sensitive to reordering (e.g., ATM).
- 少なくとも並べ替えに敏感なL2サービスを輸送する場合、パケットの順序付け（たとえば、ATM）。
The above list contains items from [Y.1241], as well as other items typically part of SLAs for currently deployed VPN services [FRF.13]. See [RFC3198] for generic definitions of SLS, SLA, and SLO.
上記のリストには、[Y.1241]の項目と、通常展開されているVPNサービスのSLAの一部[Frf.13]の項目が含まれています。SLS、SLA、およびSLOの一般的な定義については、[RFC3198]を参照してください。
The provider network management system SHALL measure, and report as necessary, whether measured performance meets or fails to meet the above SLS objectives.
プロバイダーネットワーク管理システムは、測定されたパフォーマンスが上記のSLS目標を満たすか、満たさないかどうかを測定し、必要に応じて報告します。
In many cases the guaranteed levels for Service Level Objective (SLO) parameters may depend upon the scope of the VPN. For example, one level of guarantee might be provided for service within a single AS. A different (generally less stringent) guarantee might be provided within multiple ASs within a single service provider. At the current time, in most cases specific guarantees are not offered for multi-provider VPNs, and if guarantees were offered they might be expected to be less stringent still.
多くの場合、サービスレベルの目的（SLO）パラメーターの保証レベルは、VPNの範囲に依存する場合があります。たとえば、1つのレベルの保証が1つのAS内にサービスを提供される場合があります。単一のサービスプロバイダー内の複数のASS内で、異なる（一般に厳格でない）保証が提供される場合があります。現在の場合、ほとんどの場合、マルチプロバイダーVPNには特定の保証が提供されておらず、保証が提供された場合は、まだ厳しくないと予想されます。
The service provider and the customer may negotiate a contractual arrangement that includes a Service Level Agreement (SLA) regarding compensation if the provider does not meet an SLS performance objective. Details of such compensation are outside the scope of this document.
サービスプロバイダーと顧客は、プロバイダーがSLSパフォーマンスの目標を満たしていない場合、報酬に関するサービスレベル契約（SLA）を含む契約上の取り決め（SLA）を交渉することができます。このような補償の詳細は、この文書の範囲外です。
Network resources such as memory space, FIB table, bandwidth and CPU processing SHALL be shared between VPNs and, where applicable, with non-VPN Internet traffic. Mechanisms SHOULD be provided to prevent any specific VPN from taking up available network resources and causing others to fail. SLAs to this effect SHOULD be provided to the customer.
メモリスペース、FIBテーブル、帯域幅、CPU処理などのネットワークリソースは、VPNと該当する場合、非VPNインターネットトラフィックとの間で共有するものとします。特定のVPNが利用可能なネットワークリソースを取り上げて他の人を失敗させるのを防ぐために、メカニズムを提供する必要があります。この効果に対するSLAは、顧客に提供する必要があります。
Similarly, resources used for control plane mechanisms are also shared. When the service provider's control plane is used to distribute VPN specific information and provide other control mechanisms for VPNs, there SHALL be mechanisms to ensure that control plane performance is not degraded below acceptable limits when scaling the VPN service, or during network events such as failure, routing instabilities etc. Since a service provider's network would also be used to provide Internet service, in addition to VPNs, mechanisms to ensure the stable operation of Internet services and other VPNs SHALL be made in order to avoid adverse effects of resource hogging by large VPN customers.
同様に、制御プレーンのメカニズムに使用されるリソースも共有されます。サービスプロバイダーの制御プレーンがVPN固有の情報を配布し、VPNの他の制御メカニズムを提供するために使用される場合、VPNサービスをスケーリングするとき、または障害などのネットワークイベント中に、コントロールプレーンのパフォーマンスが許容限界以下で低下しないようにするメカニズムがあります。、ルーティングの不安定性など。サービスプロバイダーのネットワークは、VPNSに加えて、インターネットサービスやその他のVPNの安定した動作を確保するためのメカニズムを提供するために、インターネットサービスを提供するためにも使用されます。VPNの顧客。
This section describes operational requirements for a cost-effective, profitable VPN service offering.
このセクションでは、費用対効果の高い収益性の高いVPNサービスの提供に関する運用要件について説明します。
The scalability for VPN solutions has many aspects. The list below is intended to comprise of the aspects that PPVPN solutions SHOULD address. Clearly these aspects in absolute figures are very different for different types of VPNs - i.e., a point to point service has only two sites, while a VPLS or L3VPN may have a larger number of sites. It is also important to verify that PPVPN solutions not only scales on the high end, but also on the low end - i.e., a VPN with three sites and three users should be as viable as a VPN with hundreds of sites and thousands of users.
VPNソリューションのスケーラビリティには多くの側面があります。以下のリストは、PPVPNソリューションが対処すべき側面で構成されることを目的としています。明らかに、絶対的な数値のこれらの側面は、VPNの種類によって非常に異なります。つまり、ポイントトゥポイントサービスには2つのサイトしかありませんが、VPLSまたはL3VPNには多くのサイトがある場合があります。また、PPVPNソリューションがハイエンドでスケーリングするだけでなく、ローエンドでもスケーリングすることを確認することも重要です。つまり、3つのサイトと3つのユーザーを持つVPNは、数百のサイトと数千のユーザーを持つVPNと同じくらい実行可能である必要があります。
A PPVPN solution SHOULD be scalable to support a very large number of VPNs per Service Provider network. The estimate is that a large service provider will require support for O(10^4) VPNs within four years.
PPVPNソリューションは、サービスプロバイダーネットワークごとに非常に多数のVPNをサポートするためにスケーラブルである必要があります。推定では、大規模なサービスプロバイダーが4年以内にO（10^4）VPNのサポートを必要とすると推定されます。
A PPVPN solution SHOULD be scalable to support a wide range of number of site interfaces per VPN, depending on the size and/or structure of the customer organization. The number of site interfaces SHOULD range from a few site interfaces to over 50,000 site interfaces per VPN.
PPVPNソリューションは、顧客組織のサイズおよび/または構造に応じて、VPNごとの幅広いサイトインターフェイスをサポートするためにスケーラブルである必要があります。サイトインターフェイスの数は、いくつかのサイトインターフェイスからVPNあたり50,000を超えるサイトインターフェイスまでの範囲です。
A PPVPN solution SHOULD be scalable to support of a wide range of number of routes per VPN. The number of routes per VPN may range from just a few to the number of routes exchanged between ISPs (O(10^5)), with typical values being in the O(10^3) range. The high end number is especially true considering the fact that many large ISPs may provide VPN services to smaller ISPs or large corporations. Typically, the number of routes per VPN is at least twice the number of site interfaces.
PPVPNソリューションは、VPNあたりの幅広いルートをサポートするためにスケーラブルである必要があります。VPNあたりのルート数は、ISP（O（10^5））の間で交換されるルートの数からわずか数から、典型的な値がO（10^3）範囲にあります。多くの大規模なISPが小規模なISPまたは大企業にVPNサービスを提供する可能性があるという事実を考えると、ハイエンド数は特に当てはまります。通常、VPNあたりのルート数は、サイトインターフェイスの少なくとも2倍です。
A PPVPN solution SHOULD support high values of the frequency of configuration setup and change, e.g., for real-time provisioning of an on-demand videoconferencing VPN or addition/deletion of sites.
PPVPNソリューションは、たとえば、オンデマンドビデオ会議VPNまたはサイトの追加/削除のリアルタイムプロビジョニングのために、構成のセットアップと変更の頻度の高い値をサポートする必要があります。
Approaches SHOULD articulate scaling and performance limits for more complex deployment scenarios, such as single-provider multi-AS VPNs, multi-provider VPNs and carriers' carrier. Approaches SHOULD also describe other dimensions of interest, such as capacity requirements or limits, number of interworking instances supported as well as any scalability implications on management systems.
アプローチは、単一プロバイダーのマルチAS VPN、マルチプロバイダーVPN、キャリアキャリアなどの、より複雑な展開シナリオのスケーリングとパフォーマンスの制限を明確にする必要があります。また、アプローチは、容量の要件や制限、サポートされるインターワーキングインスタンスの数、管理システムへのスケーラビリティへの影響など、他の関心のある側面を説明する必要があります。
A PPVPN solution SHOULD support a large number of customer interfaces on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with current Internet protocols.
PPVPNソリューションは、現在のインターネットプロトコルを使用して、単一のPE（PEベースのPPVPN用）またはCE（CEベースのPPVPN用）上の多数の顧客インターフェイスをサポートする必要があります。
This section describes the metrics for scaling PPVPN solutions, points out some of the scaling differences between L2 and L3 VPNs. It should be noted that the scaling numbers used in this document must be treated as typical examples as seen by the authors of this document. These numbers are only representative and different service providers may have different requirements for scaling. Further discussion on service provider sizing projections is in Section 5.1.1. Please note that the terms "user" and "site" are as defined in Section 3. It should also be noted that the numbers given below would be different depending on whether the scope of the VPN is single-provider single-AS, single-provider multi-AS, or multi-provider. Clearly, the larger the scope, the larger the numbers that may need to be supported. However, this also means more management issues. The numbers below may be treated as representative of the single-provider case.
このセクションでは、PPVPNソリューションのスケーリングのメトリックについて説明し、L2とL3 VPNのスケーリングの違いの一部を示しています。このドキュメントで使用されているスケーリング番号は、このドキュメントの著者が見た典型的な例として扱わなければならないことに注意する必要があります。これらの数値は代表的なものであり、さまざまなサービスプロバイダーがスケーリングに異なる要件を持っている場合があります。サービスプロバイダーのサイジング予測に関するさらなる議論は、セクション5.1.1にあります。「ユーザー」と「サイト」という用語はセクション3で定義されていることに注意してください。また、以下に示す数値は、VPNの範囲が単一プロバイダーシングルAS、単一 - 単一プロバイダーであるかどうかによって異なることに注意する必要があります。プロバイダーMulti-AS、またはマルチプロバイダー。明らかに、スコープが大きいほど、サポートする必要がある数値が大きくなります。ただし、これはより多くの管理上の問題も意味します。以下の数字は、単一プロバイダーのケースの代表として扱うことができます。
The number of users per site follows the same logic as for users per VPN. Further, it must be possible to have single user sites connected to the same VPN as very large sites are connected to.
サイトごとのユーザー数は、VPNあたりのユーザーと同じロジックに従います。さらに、非常に大きなサイトが接続されているのと同じVPNに接続されている単一のユーザーサイトを持つことができなければなりません。
L3 VPNs SHOULD scale from 1 user per site to O(10^4) per site. L2 VPNs SHOULD scale from 1 user to O(10^3) per site for point-to-point VPNs and to O(10^4) for point-to-multipoint VPNs.
L3 VPNは、サイトごとに1ユーザーからサイトごとにO（10^4）にスケーリングする必要があります。L2 VPNは、ポイントツーポイントVPNの場合、サイトごとに1ユーザーからO（10^3）、およびポイントツーマルチポイントVPNの場合はO（10^4）にスケーリングする必要があります。
The number of sites per VPN clearly depends on the number of users per site. VPNs SHOULD scale from 2 to O(10^3) sites per VPN. These numbers are usually limited by device memory.
VPNあたりのサイトの数は、サイトごとのユーザー数によって明らかに異なります。VPNは、VPNあたり2からO（10^3）サイトから拡張する必要があります。これらの数値は通常、デバイスメモリによって制限されます。
The number of PEs that supports the same set of VPNs, i.e., the number of PEs that needs to directly exchange information on VPN de-multiplexing information is clearly a scaling factor in a PE-based VPN. Similarly, in a CE-based VPN, the number of CEs is a scaling factor. This number is driven by the type of VPN service, and also by whether the service is within a single AS/domain or involves a multi-SP or multi-AS network. Typically, this number SHOULD be as low as possible in order to make the VPN cost effective and manageable.
VPNの同じセットをサポートするPEの数、つまり、VPN脱融解情報に関する情報を直接交換する必要があるPEの数は、明らかにPEベースのVPNのスケーリング因子です。同様に、CEベースのVPNでは、CESの数がスケーリング因子です。この数値は、VPNサービスのタイプによって駆動されます。また、サービスが単一のAS/ドメイン内にあるか、マルチSPまたはマルチASネットワークが含まれているかによっても駆動されます。通常、この数は、VPNをコスト効果的かつ管理しやすくするために、できるだけ低くする必要があります。
The number of sites per PE needs to be discussed based on several different scenarios. On the one hand there is a limitation to the number of customer facing interfaces that the PE can support. On the other hand the access network may aggregate several sites connected on comparatively low bandwidth on to one single high bandwidth interface on the PE. The scaling point here is that the PE SHOULD be able to support a few or even a single site on the low end and O(10^4) sites on the high end. This number is also limited by device memory. Implementations of PPVPN solutions may be evaluated based on this requirement, because it directly impacts cost and manageability of a VPN.
PEあたりのサイト数については、いくつかの異なるシナリオに基づいて議論する必要があります。一方では、PEがサポートできるインターフェイスに直面する顧客の数に制限があります。一方、アクセスネットワークは、PEの1つの高い帯域幅インターフェイスに比較的低い帯域幅で接続されたいくつかのサイトを集約する場合があります。ここでのスケーリングポイントは、PEがローエンドのいくつかまたは単一のサイトをハイエンドのO（10^4）サイトでサポートできるはずです。この番号は、デバイスメモリによっても制限されています。PPVPNソリューションの実装は、VPNのコストと管理性に直接影響するため、この要件に基づいて評価できます。
The number of VPNs SHOULD scale linearly with the size of the access network and with the number of PEs. As mentioned in Section 5.1.1, the number of VPNs in the network SHOULD be O(10^4). This requirement also effectively places a requirement on the number of tunnels that SHOULD be supported in the network. For a PE-based VPN, the number of tunnels is of the same order as the number of VPNs. For a CE-based VPN, the number of tunnels in the core network may be fewer, because of the possibility of tunnel aggregation or multiplexing across the core.
VPNの数は、アクセスネットワークのサイズとPEの数で直線的にスケーリングする必要があります。セクション5.1.1で述べたように、ネットワーク内のVPNの数はO（10^4）でなければなりません。また、この要件は、ネットワークでサポートされるべきトンネルの数にも効果的に要件を置きます。PEベースのVPNの場合、トンネルの数はVPNの数と同じ順序です。CEベースのVPNの場合、コアネットワークのトンネルの数が少ない場合があります。
In some cases a service provider may support multiple VPNs for the same customer of that service provider. For example, this may occur due to differences in services offered per VPN (e.g., different QoS, security levels, or reachability) as well as due to the presence of multiple workgroups per customer. It is possible that one customer will run up to O(100) VPNs.
場合によっては、サービスプロバイダーがそのサービスプロバイダーの同じ顧客に対して複数のVPNをサポートする場合があります。たとえば、これは、VPNごとに提供されるサービスの違い（例：異なるQos、セキュリティレベル、または到達可能性）のために、および顧客ごとの複数のワークグループが存在するために発生する可能性があります。1人の顧客がO（100）VPNに走る可能性があります。
Since any VPN solution SHALL support private customer addresses, the number of addresses and address prefixes are important in evaluating the scaling requirements. The number of address prefixes used in routing protocols and in forwarding tables specific to the VPN needs to scale from very few (for smaller customers) to very large numbers seen in typical Service Provider backbones. The high end is especially true considering that many Tier 1 SPs may provide VPN services to Tier 2 SPs or to large corporations. For a L2 VPN this number would be on the order of addresses supported in typical native Layer 2 backbones.
VPNソリューションはプライベート顧客アドレスをサポートするため、スケーリング要件の評価において、アドレスとアドレスのプレフィックスの数が重要です。ルーティングプロトコルおよびVPNに固有のテーブルの転送で使用されるアドレスプレフィックスの数は、非常に少ない顧客（小規模な顧客の場合）から典型的なサービスプロバイダーのバックボーンで見られる非常に多くの数にスケーリングする必要があります。多くのティア1 SPSがティア2 SPSまたは大企業にVPNサービスを提供する可能性があることを考えると、ハイエンドは特に真実です。L2 VPNの場合、この数値は、典型的なネイティブレイヤー2バックボーンでサポートされているアドレスの順序にあります。
Each PPVPN solution SHALL document its scalability characteristics in quantitative terms. A VPN solution SHOULD quantify the amount of state that a PE and P device has to support. This SHOULD be stated in terms of the order of magnitude of the number of VPNs and site interfaces supported by the service provider. Ideally, all VPN-specific state SHOULD be contained in the PE device for a PE-based VPN. Similarly, all VPN-specific state SHOULD be contained in the CE device for a CE-based VPN. In all cases, the backbone routers (P devices) SHALL NOT maintain VPN-specific state as far as possible.
各PPVPNソリューションは、そのスケーラビリティ特性を定量的に文書化するものとします。VPNソリューションは、PEおよびPデバイスがサポートする必要がある状態の量を定量化する必要があります。これは、サービスプロバイダーがサポートするVPNとサイトインターフェイスの数の大きさの順序で記載する必要があります。理想的には、すべてのVPN固有の状態は、PEベースのVPNのPEデバイスに含める必要があります。同様に、すべてのVPN固有の状態は、CEベースのVPNのCEデバイスに含める必要があります。すべての場合において、バックボーンルーター（Pデバイス）は、VPN固有の状態を可能な限り維持してはなりません。
Another metric is that of complexity. In a PE-based solution the PE is more complex in that it has to maintain tunnel-specific information for each VPN, but the CE is simpler since it does not need to support tunnels. On the other hand, in a CE-based solution, the CE is more complex since it has to implement routing across a number of tunnels to other CEs in the VPN, but the PE is simpler since it has only one routing and forwarding instance. Thus, the complexity of the PE or CE SHOULD be noted in terms of their processing and management functions.
別のメトリックは複雑さのメトリックです。PEベースのソリューションでは、各VPNのトンネル固有の情報を維持する必要があるという点でPEはより複雑ですが、CEはトンネルをサポートする必要がないためより単純です。一方、CEベースのソリューションでは、CEはVPNの他のCESへの多数のトンネルを横切るルーティングを実装する必要があるため、より複雑ですが、PEは1つのルーティングと転送インスタンスしかないため、より単純です。したがって、PEまたはCEの複雑さは、それらの処理機能と管理機能の観点から注意する必要があります。
A service provider MUST have a means to view the topology, operational state, service order status, and other parameters associated with each customer's VPN. Furthermore, the service provider MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers.
サービスプロバイダーには、各顧客のVPNに関連付けられたトポロジ、運用状態、サービス順序ステータス、およびその他のパラメーターを表示する手段が必要です。さらに、サービスプロバイダーには、VPNサービスを顧客に提供する機器に関連する根本的な論理的および物理的トポロジ、運用状態、プロビジョニングステータス、およびその他のパラメーターを表示する手段が必要です。
In the multi-provider scenario, it is unlikely that participating providers would provide each other a view to the network topology and other parameters mentioned above. However, each provider MUST ensure via management of their own networks that the overall VPN service offered to the customers are properly managed. In general the support of a single VPN spanning multiple service providers requires close cooperation between the service providers. One aspect of this cooperation involves agreement on what information about the VPN will be visible across providers, and what network management protocols will be used between providers.
マルチプロバイダーのシナリオでは、参加プロバイダーが互いに互いにネットワークトポロジやその他のパラメーターを眺めることができるとは考えにくいです。ただし、各プロバイダーは、顧客に提供されるVPNサービス全体が適切に管理されていることを、独自のネットワークの管理を通じて確保する必要があります。一般に、複数のサービスプロバイダーにまたがる単一のVPNのサポートには、サービスプロバイダー間の緊密な協力が必要です。この協力の1つの側面には、VPNに関する情報がプロバイダー全体で表示されるか、プロバイダー間でどのネットワーク管理プロトコルが使用されるかについての合意が含まれます。
VPN devices SHOULD provide standards-based management interfaces wherever feasible.
VPNデバイスは、実現可能な場所に標準ベースの管理インターフェイスを提供する必要があります。
A customer SHOULD have a means to view the topology, operational state, service order status, and other parameters associated with his or her VPN.
顧客は、トポロジ、運用状態、サービス順序ステータス、およびVPNに関連するその他のパラメーターを表示する手段を持つ必要があります。
All aspects of management information about CE devices and customer attributes of a PPVPN manageable by an SP SHOULD be capable of being configured and maintained by the customer after being authenticated and authorized.
SPが管理できるPPVPNのCEデバイスと顧客属性に関する管理情報のすべての側面は、認証および承認された後に顧客が構成および維持できる必要があります。
A customer SHOULD be able to make dynamic requests for changes to traffic parameters. A customer SHOULD be able to receive real-time response from the SP network in response to these requests. One example of such as service is a "Dynamic Bandwidth management" capability, that enables real-time response to customer requests for changes of allocated bandwidth allocated to their VPN(s). A possible outcome of giving customers such capabilities is Denial of Service attacks on other VPN customers or Internet users. This possibility is documented in the Security Considerations section.
顧客は、トラフィックパラメーターの変更を動的にリクエストできる必要があります。顧客は、これらの要求に応じてSPネットワークからリアルタイムの応答を受信できる必要があります。サービスなどの1つの例は、「動的帯域幅管理」機能であり、VPNに割り当てられた割り当てられた帯域幅の変更に対する顧客の要求に対するリアルタイムの応答を可能にします。そのような機能を顧客に提供することの結果の可能性は、他のVPN顧客またはインターネットユーザーに対するサービス攻撃の拒否です。この可能性は、セキュリティ上の考慮事項セクションに文書化されています。
These requirements are driven by implementation characteristics that make service and provider requirements achievable.
これらの要件は、サービスとプロバイダーの要件を達成可能にする実装特性によって駆動されます。
VPN solutions SHOULD NOT pre-suppose or preclude the use of IETF developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or IPsec. The separation of VPN solution and tunnels will facilitate adaptability with extensions to current tunneling techniques or development of new tunneling techniques. It should be noted that the choice of the tunneling techniques may impact the service and scaling capabilities of the VPN solution.
VPNソリューションは、IP-in-IP、L2TP、GRE、MPLS、IPSECなどのIETF開発技術の使用を事前にサポートまたは排除するべきではありません。VPNソリューションとトンネルの分離は、現在のトンネリング技術または新しいトンネリング技術の開発への拡張を伴う適応性を促進します。トンネリング技術の選択は、VPNソリューションのサービスとスケーリング機能に影響を与える可能性があることに注意する必要があります。
It should also be noted that specific tunneling techniques may not be feasible depending on the deployment scenario. In particular, there is currently very little use of MPLS in the inter-provider scenario. Thus, native MPLS support may be needed between the service providers, or it would be necessary to run MPLS over IP or GRE. It should be noted that if MPLS is run over IP or GRE, some of the other capabilities of MPLS, such as Traffic Engineering, would be impacted. Also note that a service provider MAY optionally choose to use a different encapsulation for multi-AS VPNs than is used for single AS VPNs. Similarly, a group of service providers may choose to use a different encapsulation for multi-service provider VPNs than for VPNs within a single service provider.
また、特定のトンネリング技術は、展開シナリオに応じて実行不可能である可能性があることにも注意する必要があります。特に、現在、プロバイダー間シナリオではMPLSの使用はほとんどありません。したがって、サービスプロバイダー間でネイティブMPLSサポートが必要になる場合があります。または、IPまたはGREでMPLSを実行する必要があります。MPLSがIPまたはGREで実行されている場合、トラフィックエンジニアリングなどのMPLSの他の機能の一部が影響を受けることに注意する必要があります。また、サービスプロバイダーは、単一としてVPNSに使用されるよりも、Multi-AS VPNに異なるカプセル化を使用することをオプションで選択できることに注意してください。同様に、サービスプロバイダーのグループは、単一のサービスプロバイダー内のVPNよりもマルチサービスプロバイダーVPNSに異なるカプセル化を使用することを選択できます。
For Layer 2 VPNs, solutions SHOULD utilize the encapsulation techniques defined by the Pseudo-Wire Emulation Edge-to-Edge (PWE3) Working Group, and SHOULD NOT impose any new requirements on these techniques.
レイヤー2 VPNの場合、ソリューションは、擬似ワイヤーエミュレーションエッジツーエッジ（PWE3）ワーキンググループによって定義されるカプセル化技術を利用する必要があり、これらの手法に新しい要件を課すべきではありません。
PPVPN solutions MUST NOT impose any restrictions on the backbone traffic engineering and management techniques. Conversely, backbone engineering and management techniques MUST NOT affect the basic operation of a PPVPN, apart from influencing the SLA/SLS guarantees associated with the service. The SP SHOULD, however, be REQUIRED to provide per-VPN management, tunnel maintenance and other maintenance required in order to meet the SLA/SLS.
PPVPNソリューションは、バックボーントラフィックエンジニアリングと管理手法に制限を課してはなりません。逆に、バックボーンエンジニアリングおよび管理手法は、サービスに関連するSLA/SLS保証に影響を与えることを除けば、PPVPNの基本的な動作に影響を与えてはなりません。ただし、SPNの管理、トンネルのメンテナンス、およびSLA/SLSを満たすために必要なその他のメンテナンスを提供するために、SPは必要です。
By definition, VPN traffic SHOULD be segregated from each other, and from non-VPN traffic in the network. After all, VPNs are a means of dividing a physical network into several logical (virtual) networks. VPN traffic separation SHOULD be done in a scalable fashion. However, safeguards SHOULD be made available against misbehaving VPNs to not affect the network and other VPNs.
定義上、VPNトラフィックは互いに、およびネットワーク内の非VPNトラフィックから分離する必要があります。結局のところ、VPNは物理ネットワークをいくつかの論理的（仮想）ネットワークに分割する手段です。VPNトラフィック分離は、スケーラブルな方法で行う必要があります。ただし、ネットワークや他のVPNに影響を与えないように、VPNの誤動作に対して保護手段を利用できるようにする必要があります。
A VPN solution SHOULD NOT impose any hard limit on the number of VPNs provided in the network.
VPNソリューションは、ネットワークで提供されるVPNの数に厳しい制限を課すべきではありません。
The plug and play feature of a VPN solution with minimum configuration requirements is an important consideration. The VPN solutions SHOULD have mechanisms for protection against customer interface and/or routing instabilities so that they do not impact other customers' services or impact general Internet traffic handling in any way.
構成要件を最小限に抑えるVPNソリューションのプラグアンドプレイ機能は、重要な考慮事項です。VPNソリューションには、他の顧客のサービスに影響を与えたり、一般的なインターネットトラフィックの取り扱いに影響を与えないように、顧客インターフェイスやルーティングの不安定性から保護するためのメカニズムが必要です。
A VPN SHOULD be provisioned with minimum number of steps. For instance, a VPN need not be configured in every PE. For this to be accomplished, an auto-configuration and an auto-discovery protocol, which SHOULD be as common as possible to all VPN solutions, SHOULD be defined. However, these mechanisms SHOULD NOT adversely affect the cost, scalability or stability of a service by being overly complex, or by increasing layers in the protocol stack.
VPNには、最小ステップ数でプロビジョニングする必要があります。たとえば、VPNをすべてのPEで構成する必要はありません。これを達成するためには、すべてのVPNソリューションに可能な限り一般的であるはずの自動構成と自動配置プロトコルを定義する必要があります。ただし、これらのメカニズムは、過度に複雑であることによって、またはプロトコルスタックの層を増やすことにより、サービスのコスト、スケーラビリティ、または安定性に悪影響を与えるべきではありません。
Mechanisms to protect the SP network from effects of misconfiguration of VPNs SHOULD be provided. This is especially of importance in the multi-provider case, where misconfiguration could possibly impact more than one network.
VPNの誤解の影響からSPネットワークを保護するメカニズムを提供する必要があります。これは、誤った構成が複数のネットワークに影響を与える可能性があるマルチプロバイダーのケースで特に重要です。
The PPVPN control plane MUST include a mechanism through which the service provider can filter PPVPN related control plane information as it passes between Autonomous Systems. For example, if a service provider supports a PPVPN offering, but the service provider's neighbors do not participate in that offering, the service provider SHOULD NOT leak PPVPN control information into neighboring networks. Neighboring networks MUST be equipped with mechanisms that filter this information should the service provider leak it. This is important in the case of multi-provider VPNs as well as single-provider multi-AS VPNs.
PPVPN制御プレーンには、サービスプロバイダーが自律システム間を通過するときにPPVPN関連のコントロールプレーン情報をフィルタリングできるメカニズムを含める必要があります。たとえば、サービスプロバイダーがPPVPNオファリングをサポートしているが、サービスプロバイダーの隣人がその提供に参加していない場合、サービスプロバイダーはPPVPN制御情報を隣接ネットワークに漏らしてはなりません。隣接するネットワークには、サービスプロバイダーが漏れた場合にこの情報をフィルタリングするメカニズムを装備する必要があります。これは、マルチプロバイダーVPNと単一プロバイダーのマルチAS VPNの場合に重要です。
As far as possible, the mechanisms used to establish a VPN service SHOULD re-use well-known IETF protocols, limiting the need to define new protocols from scratch. It should, however, be noted that the use of Internet mechanisms for the establishment and running of an Internet-based VPN service, SHALL NOT affect the stability, robustness, and scalability of the Internet or Internet services. In other words, these mechanisms SHOULD NOT conflict with the architectural principles of the Internet, nor SHOULD it put at risk the existing Internet systems. For example, IETF-developed routing protocols SHOULD be used for routing of L3 PPVPN traffic, without adding VPN-specific state to the Internet core routers. Similarly, well-known L2 technologies SHOULD be used in VPNs offering L2 services, without imposing risks to the Internet routers. A solution MUST be implementable without requiring additional functionality to the P devices in a network, and minimal functionality to the PE in a PE-based VPN and CE in a CE-based VPN.
可能な限り、VPNサービスを確立するために使用されるメカニズムは、よく知られているIETFプロトコルを再利用して、新しいプロトコルをゼロから定義する必要性を制限する必要があります。ただし、インターネットベースのVPNサービスの確立と実行にインターネットメカニズムの使用は、インターネットまたはインターネットサービスの安定性、堅牢性、およびスケーラビリティに影響を与えないことに注意する必要があります。言い換えれば、これらのメカニズムは、インターネットのアーキテクチャの原則と矛盾するものではなく、既存のインターネットシステムを危険にさらすこともありません。たとえば、VPN固有の状態をインターネットコアルーターに追加せずに、IETF開発のルーティングプロトコルをL3 PPVPNトラフィックのルーティングに使用する必要があります。同様に、インターネットルーターにリスクを課すことなく、L2サービスを提供するVPNSでよく知られているL2テクノロジーを使用する必要があります。ソリューションは、ネットワーク内のPデバイスに追加の機能を必要とせずに実装でき、PEベースのVPNおよびCEベースのVPNのCEのPEに最小限の機能を最小限に抑える必要があります。
In addition to commonality with generic Internet mechanisms, infrastructure mechanisms used in different PPVPN solutions (both L2 and L3), e.g., discovery, signaling, routing and management, SHOULD be as common as possible.
一般的なインターネットメカニズムとの共通性に加えて、さまざまなPPVPNソリューション（L2とL3の両方）で使用されるインフラストラクチャメカニズム、例えば発見、シグナル、ルーティング、管理は、可能な限り一般的でなければなりません。
Each technical solution is expected to be based on interoperable Internet standards.
各技術的なソリューションは、相互運用可能なインターネット標準に基づいていることが期待されています。
Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution SHOULD be ensured (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers.
ネットワーク要素、ネットワーク、およびサービスレベルでのマルチベンダーの相互運用性と同じ技術的ソリューションの異なる実装の間のサービスレベルを保証する必要があります（対応する標準の完全性に依存する可能性があります）。これは、SPSと顧客にとって中心的な要件です。
The technical solution MUST be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service.
技術的なソリューションは、SPネットワークインフラストラクチャ内だけでなく、顧客のネットワーク機器とPPVPNサービスの使用を行うために、マルチベンダーの相互運用可能でなければなりません。
Customer access connections to a PPVPN solution may be different at different sites (e.g., Frame Relay on one site and Ethernet on another).
PPVPNソリューションへの顧客のアクセス接続は、異なるサイトで異なる場合があります（たとえば、あるサイトのフレームリレー、別のサイトのイーサネット）。
Interconnection of a L2VPN over an L3VPN as if it were a customer site SHALL be supported. However, interworking of Layer 2 technologies is not required, and is outside the scope of the working group, and therefore, of this document.
L3VPNを介したL2VPNの相互接続は、まるで顧客サイトであるかのようにサポートされます。ただし、レイヤー2テクノロジーの相互作用は必須ではなく、ワーキンググループの範囲外であるため、このドキュメントの範囲外です。
Inter-domain interoperability - It SHOULD be possible to deploy a PPVPN solution across domains, Autonomous Systems, or the Internet.
ドメイン間の相互運用性 - ドメイン、自律システム、またはインターネットにPPVPNソリューションを展開することが可能です。
Security requirements for Provider Provisioned VPNs have been described in Section 4.5. In addition, the following considerations need to be kept in mind when a provider provisioned VPN service is provided across a public network infrastructure that is also used to provide Internet connectivity. In general, the security framework described in [VPN-SEC] SHOULD be used as far as it is applicable to the given type of PPVPN service.
プロバイダーのプロビジョニングVPNのセキュリティ要件は、セクション4.5で説明されています。さらに、インターネット接続の提供にも使用されるパブリックネットワークインフラストラクチャ全体でプロバイダープロビジョニングVPNサービスが提供される場合、以下の考慮事項を念頭に置いておく必要があります。一般に、[VPN-SEC]で説明されているセキュリティフレームワークは、特定のタイプのPPVPNサービスに適用できる限り使用する必要があります。
The PE device has a lot of functionality required for the successful operation of the VPN service. The PE device is frequently also part of the backbone providing Internet services, and is therefore susceptible to security and denial of service attacks. The PE control plane CPU is vulnerable from this point of view, and it may impact not only VPN services but also general Internet services if not adequately protected. In addition to VPN configuration, if mechanisms such as QoS are provisioned on the PE, it is possible for attackers to recognize the highest priority traffic or customers and launch directed attacks. Care SHOULD be taken to prevent such attacks whenever any value added services such as QoS are offered.
PEデバイスには、VPNサービスの操作が成功するために必要な多くの機能があります。PEデバイスは、多くの場合、インターネットサービスを提供するバックボーンの一部であるため、セキュリティとサービス攻撃の拒否を受けやすいです。PEコントロールプレーンCPUは、この観点から脆弱であり、VPNサービスだけでなく、適切に保護されていない場合は一般的なインターネットサービスにも影響を与える可能性があります。VPN構成に加えて、QoSなどのメカニズムがPEにプロビジョニングされている場合、攻撃者は最優先のトラフィックまたは顧客を認識し、指示された攻撃を開始する可能性があります。QoSなどの付加価値サービスが提供されるたびに、そのような攻撃を防ぐために注意する必要があります。
When a service such as "Dynamic Bandwidth Management" as described in Section 5.2.1 is provided, it allows customers to dynamically request for changes to their bandwidth allocation. The provider MUST take care to authenticate such requests and detect and prevent possible Denial-of-Service attacks. These DoS attacks are possible when a customer maliciously or accidentally may cause a change in bandwidth allocation that may impact the bandwidth allocated to other VPN customers or Internet users.
セクション5.2.1で説明されている「動的帯域幅管理」などのサービスが提供されると、顧客は帯域幅の割り当ての変更を動的に要求できます。プロバイダーは、そのようなリクエストを認証し、可能性のあるサービス拒否攻撃を検出および防止するように注意しなければなりません。これらのDOS攻撃は、顧客が悪意を持ってまたは誤って、他のVPN顧客またはインターネットユーザーに割り当てられた帯域幅に影響を与える可能性のある帯域幅の割り当ての変更を引き起こす可能性がある場合に可能です。
Different choices of VPN technology have different assurance levels of the privacy of a customer's network. For example, CE-based solutions may enjoy more privacy than PE-based VPNs by virtue of tunnels extending from CE to CE, even if the tunnels are not encrypted. In a PE-based VPN, a PE has many more sites than those attached to a CE in a CE-based VPN. A large number of these sites may use [RFC1918] addresses. Provisioning mistakes and PE software bugs may make traffic more prone to being misdirected as opposed to a CE-based VPN. Care MUST be taken to prevent misconfiguration in all kinds of PPVPNs, but more care MUST be taken in the case of PE-based VPNs, as this could impact other customers and Internet services. Similarly, there SHOULD be mechanisms to prevent the flooding of Internet routing tables whenever there is a misconfiguration or failure of PPVPN control mechanisms that use Internet routing protocols for relay of VPN-specific information.
VPNテクノロジーのさまざまな選択には、顧客のネットワークのプライバシーの保証レベルが異なります。たとえば、CEベースのソリューションは、たとえトンネルが暗号化されていなくても、CEからCEに伸びるトンネルにより、PEベースのVPNよりも多くのプライバシーを享受する場合があります。PEベースのVPNでは、PEにはCEベースのVPNのCEに接続されているサイトよりも多くのサイトがあります。これらのサイトの多くは、[RFC1918]アドレスを使用する場合があります。プロビジョニングのミスとPEソフトウェアのバグにより、CEベースのVPNとは対照的に、トラフィックが誤った方向に向けられやすくなる可能性があります。あらゆる種類のPPVPNの誤解を防ぐために注意する必要がありますが、PEベースのVPNの場合は、他の顧客やインターネットサービスに影響を与える可能性があるため、より多くの注意が必要です。同様に、VPN固有の情報のリレーにインターネットルーティングプロトコルを使用するPPVPN制御メカニズムの誤った構成または障害がある場合は、インターネットルーティングテーブルの洪水を防ぐメカニズムがあるはずです。
Different deployment scenarios also dictate the level of security that may be needed for a VPN. For example, it is easier to control security in a single provider, single AS VPN and therefore, expensive encryption techniques may not be used in this case, as long as VPN traffic is isolated from the Internet. There is a reasonable amount of control possible in the single provider, multi AS case, although care SHOULD be taken to ensure the constrained distribution of VPN route information across the ASes. Security is more of a challenge in the multi-provider case, where it may be necessary to adopt encryption techniques in order to provide the highest level of security.
さまざまな展開シナリオも、VPNに必要なセキュリティのレベルを決定します。たとえば、VPNとして単一の単一のプロバイダーでセキュリティを制御する方が簡単であるため、VPNトラフィックがインターネットから分離されている限り、この場合、高価な暗号化手法は使用されない場合があります。単一のプロバイダーでは、Multi Asケースで可能な合理的な量の制御がありますが、ASES全体のVPNルート情報の制約された分布を確保するために注意する必要があります。セキュリティは、最高レベルのセキュリティを提供するために暗号化技術を採用する必要があるマルチプロバイダーのケースでは、より課題です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider Provisioned Virtual Private Networks", Work in Progress.
[用語] Andersson、L.、Madsen、T。、「プロバイダープロビジョニング仮想プライベートネットワークの用語」、進行中の作業。
[L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress, March 2003.
[L3Framework] Callon、R.、Suzuki、M.、et al。「レイヤー3プロバイダーのプロビジョニング仮想プライベートネットワークのフレームワーク」は、2003年3月に進行中の作業です。
[L2FRAMEWORK] Andersson, L., et al. "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work in Progress, March 2004.
[L2Framework] Andersson、L.、et al。「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、2004年3月、進行中の作業。
[L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress, April 2003.
[L3REQTS] Carugi、M.、McDysan、D。et al。、「レイヤー3プロバイダープロビジョニング仮想プライベートネットワークのサービス要件」、2003年4月、進行中の作業。
[L2REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Work in Progress, April 2003.
[L2REQTS] Augustyn、W.、Serbest、Y.、et al。、「レイヤー2プロバイダープロビジョニング仮想プライベートネットワークのサービス要件」、2003年4月、進行中の作業。
[Y.1241] "IP Transfer Capability for the support of IP based Services", Y.1241 ITU-T Draft Recommendation, March 2000.
[Y.1241]「IPベースのサービスのサポートのためのIP転送機能」、Y.1241 ITU-Tドラフト推奨、2000年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J。and S.Waldbusser、「ポリシーベースの管理のための用語」、RFC 3198、2001年11月。
[VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress, February 2004.
[VPN-SEC] Fang、L.、et al。、「プロバイダープロビジョニング仮想プライベートネットワークのセキュリティフレームワーク」、2004年2月、Work in Progress。
[FRF.13] Frame Relay Forum, "Service Level Definitions Implementation Agreement", August 1998.
[frf.13]フレームリレーフォーラム、「サービスレベル定義実装契約」、1998年8月。
[Y.1541] "Network Performance Objectives for IP-based Services", Y.1541, ITU-T Recommendation.
[Y.1541]「IPベースのサービスのネットワークパフォーマンス目標」、Y.1541、ITU-Tの推奨。
This work was done in consultation with the entire design team for PPVPN requirements. A lot of the text was adapted from the Layer 3 requirements document produced by the Layer 3 requirements design team. The authors would also like to acknowledge the constructive feedback from Scott Bradner, Alex Zinin, Steve Bellovin, Thomas Narten and other IESG members, and the detailed comments from Ross Callon.
この作業は、PPVPN要件について設計チーム全体と協議して行われました。テキストの多くは、レイヤー3要件設計チームによって作成されたレイヤー3要件ドキュメントから採用されました。著者はまた、スコット・ブラッドナー、アレックス・ジニン、スティーブ・ベロヴィン、トーマス・ナルテン、その他のIESGメンバーからの建設的なフィードバックと、ロスコロンからの詳細なコメントを認めたいと考えています。
Ananth Nagarajan Juniper Networks
Ananth Nagarajan Juniperネットワーク
EMail: ananth@juniper.net
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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エディター機能の資金は現在、インターネット協会によって提供されています。