Network Working Group B. Gleeson
Request for Comments: 2764 A. Lin
Category: Informational Nortel Networks
J. Heinanen
Telia Finland
G. Armitage
A. Malis
Lucent Technologies
February 2000
A Framework for IP Based Virtual Private Networks
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
IESG Note
IESG注意
This document is not the product of an IETF Working Group. The IETF currently has no effort underway to standardize a specific VPN framework.
この文書は、IETFワーキンググループの製品ではありません。 IETFは、現在、特定のVPNフレームワークを標準化するために進行中の努力を持っていません。
Abstract
抽象
This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.
この文書では、IPバックボーン全体で実行している仮想プライベートネットワーク（VPN）のためのフレームワークについて説明します。これは、VPNの様々な異なるタイプの、それぞれの要件について説明し、既存の又は提案された仕様を使用して、VPNの各タイプを実装するために使用することができる特定の機構が提案されています。このドキュメントの目的は、相互運用可能なVPNソリューションの広範な展開に必要な仕様のフルセットを開発するために、関連するプロトコル開発のためのフレームワークとして機能することです。
Table of Contents
目次
1.0 Introduction ................................................ 4
2.0 VPN Application and Implementation Requirements ............. 5
2.1 General VPN Requirements .................................... 5
2.1.1 Opaque Packet Transport: ................................. 6
2.1.2 Data Security ............................................. 7
2.1.3 Quality of Service Guarantees ............................. 7
2.1.4 Tunneling Mechanism ....................................... 8
2.2 CPE and Network Based VPNs .................................. 8
2.3 VPNs and Extranets .......................................... 9
3.0 VPN Tunneling ............................................... 10
3.1 Tunneling Protocol Requirements for VPNs .................... 11
3.1.1 Multiplexing .............................................. 11
3.1.2 Signalling Protocol ....................................... 12
3.1.3 Data Security ............................................. 13
3.1.4 Multiprotocol Transport ................................... 14
3.1.5 Frame Sequencing .......................................... 14
3.1.6 Tunnel Maintenance ........................................ 15
3.1.7 Large MTUs ................................................ 16
3.1.8 Minimization of Tunnel Overhead ........................... 16
3.1.9 Flow and congestion control ............................... 17
3.1.10 QoS / Traffic Management ................................. 17
3.2 Recommendations ............................................. 18
4.0 VPN Types: Virtual Leased Lines ............................ 18
5.0 VPN Types: Virtual Private Routed Networks ................. 20
5.1 VPRN Characteristics ........................................ 20
5.1.1 Topology .................................................. 23
5.1.2 Addressing ................................................ 24
5.1.3 Forwarding ................................................ 24
5.1.4 Multiple concurrent VPRN connectivity ..................... 24
5.2 VPRN Related Work ........................................... 24
5.3 VPRN Generic Requirements ................................... 25
5.3.1 VPN Identifier ............................................ 26
5.3.2 VPN Membership Information Configuration .................. 27
5.3.2.1 Directory Lookup ........................................ 27
5.3.2.2 Explicit Management Configuration ....................... 28
5.3.2.3 Piggybacking in Routing Protocols ....................... 28
5.3.3 Stub Link Reachability Information ........................ 30
5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30
5.3.3.1.2 VPRN Connectivity Only ................................ 30
5.3.3.1.3 Multihomed Connectivity ............................... 31
5.3.3.1.4 Backdoor Links ........................................ 31
5.3.3.1 Routing Protocol Instance ............................... 31
5.3.3.2 Configuration ........................................... 33
5.3.3.3 ISP Administered Addresses .............................. 33
5.3.3.4 MPLS Label Distribution Protocol ........................ 33
5.3.4 Intra-VPN Reachability Information ........................ 34
5.3.4.1 Directory Lookup ........................................ 34
5.3.4.2 Explicit Configuration .................................. 34
5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34
5.3.4.4 Link Reachability Protocol .............................. 35
5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36
5.3.5 Tunneling Mechanisms ...................................... 36
5.4 Multihomed Stub Routers ..................................... 37
5.5 Multicast Support ........................................... 38
5.5.1 Edge Replication .......................................... 38
5.5.2 Native Multicast Support .................................. 39
5.6 Recommendations ............................................. 40
6.0 VPN Types: Virtual Private Dial Networks ................... 41
6.1 L2TP protocol characteristics ............................... 41
6.1.1 Multiplexing .............................................. 41
6.1.2 Signalling ................................................ 42
6.1.3 Data Security ............................................. 42
6.1.4 Multiprotocol Transport ................................... 42
6.1.5 Sequencing ................................................ 42
6.1.6 Tunnel Maintenance ........................................ 43
6.1.7 Large MTUs ................................................ 43
6.1.8 Tunnel Overhead ........................................... 43
6.1.9 Flow and Congestion Control ............................... 43
6.1.10 QoS / Traffic Management ................................. 43
6.1.11 Miscellaneous ............................................ 44
6.2 Compulsory Tunneling ........................................ 44
6.3 Voluntary Tunnels ........................................... 46
6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 46
6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 48
6.4 Networked Host Support ...................................... 49
6.4.1 Extension of PPP to Hosts Through L2TP .................... 49
6.4.2 Extension of PPP Directly to Hosts: ...................... 49
6.4.3 Use of IPSec .............................................. 50
6.5 Recommendations ............................................. 50
7.0 VPN Types: Virtual Private LAN Segment ..................... 50
7.1 VPLS Requirements ........................................... 51
7.1.1 Tunneling Protocols ....................................... 51
7.1.2 Multicast and Broadcast Support ........................... 52
7.1.3 VPLS Membership Configuration and Topology ................ 52
7.1.4 CPE Stub Node Types ....................................... 52
7.1.5 Stub Link Packet Encapsulation ............................ 53
7.1.5.1 Bridge CPE .............................................. 53
7.1.5.2 Router CPE .............................................. 53
7.1.6 CPE Addressing and Address Resolution ..................... 53
7.1.6.1 Bridge CPE .............................................. 53
7.1.6.2 Router CPE .............................................. 54
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 54
7.1.7.1 Bridge CPE .............................................. 54
7.1.7.2 Router CPE .............................................. 54
7.2 Recommendations ............................................. 55
8.0 Summary of Recommendations .................................. 55
9.0 Security Considerations ..................................... 56
10.0 Acknowledgements ........................................... 56
11.0 References ................................................. 56
12.0 Author Information ......................................... 61
13.0 Full Copyright Statement ................................... 62
This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.
この文書では、IPバックボーン全体で実行している仮想プライベートネットワーク（VPN）のためのフレームワークについて説明します。これは、VPNの様々な異なるタイプの、それぞれの要件について説明し、既存の又は提案された仕様を使用して、VPNの各タイプを実装するために使用することができる特定の機構が提案されています。このドキュメントの目的は、相互運用可能なVPNソリューションの広範な展開に必要な仕様のフルセットを開発するために、関連するプロトコル開発のためのフレームワークとして機能することです。
There is currently significant interest in the deployment of virtual private networks across IP backbone facilities. The widespread deployment of VPNs has been hampered, however, by the lack of interoperable implementations, which, in turn, derives from the lack of general agreement on the definition and scope of VPNs and confusion over the wide variety of solutions that are all described by the term VPN. In the context of this document, a VPN is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN.
IPバックボーン施設間で仮想プライベートネットワークの展開に大きな関心が現在あり。 VPNの広範囲の展開は、順番に、すべてで記述されているソリューションの多種多様にわたるVPNと混乱の定義と範囲についての一般的な合意の欠如に由来し、相互運用可能な実装の欠如によって、しかし、妨げられてきました用語VPN。この文書の文脈では、VPNは、単に（公衆インターネット、またはプライベートIPバックボーンを含む）のIP機能を使用してプライベートワイドエリアネットワーク（WAN）施設のエミュレーション」と定義されます。そのため、WANの種類、正確にVPNを構成するものを超えるので、混乱があるようVPNのように多くの種類があります。
In this document a VPN is modeled as a connectivity object. Hosts may be attached to a VPN, and VPNs may be interconnected together, in the same manner as hosts today attach to physical networks, and physical networks are interconnected together (e.g., via bridges or routers). Many aspects of networking, such as addressing, forwarding mechanism, learning and advertising reachability, quality of service (QoS), security, and firewalling, have common solutions across both physical and virtual networks, and many issues that arise in the discussion of VPNs have direct analogues with those issues as implemented in physical networks. The introduction of VPNs does not create the need to reinvent networking, or to introduce entirely new paradigms that have no direct analogue with existing physical networks. Instead it is often useful to first examine how a particular issue is handled in a physical network environment, and then apply the same principle to an environment which contains virtual as well as physical networks, and to develop appropriate extensions and enhancements when necessary. Clearly having mechanisms that are common across both physical and virtual networks facilitates the introduction of VPNs into existing networks, and also reduces the effort needed for both standards and product development, since existing solutions can be leveraged.
この文書では、VPNは、接続オブジェクトとしてモデル化されます。ホストは、VPNに取り付けることができる、及びホスト今日は物理ネットワークに接続としてVPNは同様にして、一緒に相互接続することができる、及び物理的ネットワーク（例えば、ブリッジまたはルータを介して）一緒に相互接続されています。こうした、アドレス指定メカニズムを転送し、学習や広告到達可能性、サービスの品質（QoS）、セキュリティ、およびファイアウォールなどのネットワークの多くの側面には、持っているVPNの議論で発生両方の物理および仮想ネットワーク間で共通のソリューション、および多くの問題を抱えています物理ネットワークに実装され、それらの問題との直接の類縁体。 VPNの導入は、ネットワークを改良するために、または既存の物理ネットワークとは直接アナログを持っていない全く新しいパラダイムを導入する必要性を作成しません。その代わりに、第1の特定の問題は物理的なネットワーク環境でどのように扱われるかを検討した後、仮想含まれている環境だけでなく、物理的なネットワークに同じ原理を適用し、必要なときに適切な拡張機能や強化機能を開発するために有用であることがしばしばあります。明確に両方の物理および仮想ネットワークに共通する機構を有する既存のネットワークへのVPNの導入を容易にし、既存のソリューションを活用することができるので、また、標準および製品開発の両方に必要な労力を低減します。
This framework document proposes a taxonomy of a specific set of VPN types, showing the specific applications of each, their specific requirements, and the specific types of mechanisms that may be most appropriate for their implementation. The intent of this document is to serve as a framework to guide a coherent discussion of the specific modifications that may be needed to existing IP mechanisms in order to develop a full range of interoperable VPN solutions.
このフレームワークの文書は、それぞれの特定のアプリケーション、それらの特定の要件、およびその実施のために最も適切であるかもしれないメカニズムの特定のタイプを示し、VPNタイプの特定のセットの分類を提案しています。この文書の目的は、相互運用可能なVPNソリューションの完全な範囲を開発するために、既存のIPメカニズムに必要とされるかもしれない特定の修飾のコヒーレントな議論を案内するためのフレームワークとして機能することです。
The document first discusses the likely expectations customers have of any type of VPN, and the implications of these for the ways in which VPNs can be implemented. It also discusses the distinctions between Customer Premises Equipment (CPE) based solutions, and network based solutions. Thereafter it presents a taxonomy of the various VPN types and their respective requirements. It also outlines suggested approaches to their implementation, hence also pointing to areas for future standardization.
文書は、最初のVPNのいずれかのタイプの顧客が持っている可能性が高い予想、およびVPNが実装することができる方法のためにこれらの影響を議論します。また、顧客宅内機器（CPE）ベースのソリューション、およびネットワークベースのソリューションとの区別を説明します。その後、それは、さまざまなVPNの種類とそれぞれの要件の分類法を提示しています。また、したがって、将来の標準化のための領域を指し、それらの実装へのアプローチを提案したアウトライン。
Note also that this document only discusses implementations of VPNs across IP backbones, be they private IP networks, or the public Internet. The models and mechanisms described here are intended to apply to both IPV4 and IPV6 backbones. This document specifically does not discuss means of constructing VPNs using native mappings onto switched backbones - e.g., VPNs constructed using the LAN Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2] protocols operating over ATM backbones. Where IP backbones are constructed using such protocols, by interconnecting routers over the switched backbone, the VPNs discussed operate on top of this IP network, and hence do not directly utilize the native mechanisms of the underlying backbone. Native VPNs are restricted to the scope of the underlying backbone, whereas IP based VPNs can extend to the extent of IP reachability. Native VPN protocols are clearly outside the scope of the IETF, and may be tackled by such bodies as the ATM Forum.
この文書は唯一のIPバックボーン間VPNの実装を説明していることにも注意してください彼らは、プライベートIPネットワーク、または公共のインターネットで。ここで説明したモデルとメカニズムは、IPv4とIPv6バックボーンの両方に適用することを意図しています。 [1]またはマルチは、ATM（MPOA）上に[2]プロトコルは、ATMバックボーン上で動作する、例えば、VPNはATM（LANE）上LANエミュレーションを使用して構築 - この文書は、具体的に切り替え骨格上のネイティブ・マッピングを使用してVPNを構築する手段を説明しません。 IPバックボーンを切り替えバックボーン上のルータを相互接続することによって、そのようなプロトコルを用いて構築されている場合、議論VPNは、このIPネットワークの上で動作し、従って直下バックボーンのネイティブメカニズムを利用しません。 IPベースのVPNは、IP到達可能性の範囲まで拡張することができ、一方、ネイティブVPNは、根本的なバックボーンの範囲に制限されています。ネイティブのVPNプロトコルはIETFの範囲外で明確にしており、ATMフォーラムなどの団体が取り組むことができます。
There is growing interest in the use of IP VPNs as a more cost effective means of building and deploying private communication networks for multi-site communication than with existing approaches.
既存のアプローチよりもマルチサイト通信のための私設通信網を構築し、展開するよりコスト効果的な手段として、IP VPNの使用への関心の高まりがあります。
Existing private networks can be generally categorized into two types - dedicated WANs that permanently connect together multiple sites, and dial networks, that allow on-demand connections through the Public Switched Telephone Network (PSTN) to one or more sites in the private network.
永久に一緒に複数のサイトを接続し、公開によるオンデマンド接続は、プライベートネットワーク内の1つのまたは複数のサイトへの交換電話網（PSTN）できるようなネットワークを、ダイヤル専用のWAN - 既存のプライベートネットワークは、一般に2つのタイプに分類することができます。
WANs are typically implemented using leased lines or dedicated circuits - for instance, Frame Relay or ATM connections - between the multiple sites. CPE routers or switches at the various sites connect these dedicated facilities together and allow for connectivity across the network. Given the cost and complexity of such dedicated facilities and the complexity of CPE device configuration, such networks are generally not fully meshed, but instead have some form of hierarchical topology. For example remote offices could be connected directly to the nearest regional office, with the regional offices connected together in some form of full or partial mesh.
WANのは、典型的には、専用回線又は専用回線を使用して実装されている - 例えば、リレーまたはATM接続をフレーム - 複数のサイト間。さまざまなサイトでのCPEルータやスイッチが一緒にこれらの専用の設備を接続し、ネットワークを介して接続が可能になります。コストと複雑さ、専用設備のとCPE装置構成の複雑さを考えると、そのようなネットワークは、一般的にフルメッシュではなく、代わりに、階層トポロジのいくつかのフォームを持っています。たとえば、リモートオフィスは、完全または部分的なメッシュの何らかの形で一緒に接続されている地域事務所で、最寄りの地方事務所に直接接続することができます。
Private dial networks are used to allow remote users to connect into an enterprise network using PSTN or Integrated Services Digital Network (ISDN) links. Typically, this is done through the deployment of Network Access Servers (NASs) at one or more central sites. Users dial into such NASs, which interact with Authentication, Authorization, and Accounting (AAA) servers to verify the identity of the user, and the set of services that the user is authorized to receive.
プライベートダイヤルネットワークは、リモートユーザがPSTNまたはISDN（Integrated Services Digital Network）リンクを使用して企業ネットワークに接続できるようにするために使用されています。通常、これは、1つまたは複数の中央サイトでネットワークアクセスサーバー（NASを）の展開を介して行われます。ユーザーは、ユーザーのID、およびユーザーが受信を許可されているサービスのセットを確認するために、認証、認可、アカウンティング（AAA）サーバと相互作用する、などのNASにダイヤルします。
In recent times, as more businesses have found the need for high speed Internet connections to their private corporate networks, there has been significant interest in the deployment of CPE based VPNs running across the Internet. This has been driven typically by the ubiquity and distance insensitive pricing of current Internet services, that can result in significantly lower costs than typical dedicated or leased line services.
より多くの企業が企業のプライベートネットワークへの高速インターネット接続の必要性を発見したとして、最近では、インターネットを介して実行されているCPEベースのVPNの展開に大きな関心が寄せられています。これは典型的な専用または専用線サービスよりも大幅に低いコストにつながることができ、現在のインターネットサービスの普遍性と距離鈍感な価格設定により、一般的に駆動されました。
The notion of using the Internet for private communications is not new, and many techniques, such as controlled route leaking, have been used for this purpose [3]. Only in recent times, however, have the appropriate IP mechanisms needed to meet customer requirements for VPNs all come together. These requirements include the following:
プライベート通信のためにインターネットを使用するという概念は新しいものではありません、そして、そのような制御ルートリークなど、多くの技術が、この目的のために使用されている[3]。のみ最近では、しかし、すべて一緒に来VPNの顧客の要件を満たすために必要な適切なIPの仕組みを持っています。これらの要件は、次のものがあります。
The traffic carried within a VPN may have no relation to the traffic on the IP backbone, either because the traffic is multiprotocol, or because the customer's IP network may use IP addressing unrelated to that of the IP backbone on which the traffic is transported. In particular, the customer's IP network may use non-unique, private IP addressing [4].
VPN内で搬送されるトラフィックは、IPバックボーンのトラフィックとは関係を持たないことがあり、どちらかのトラフィックは、マルチプロトコルであるため、または顧客のIPネットワークは、トラフィックが搬送されているIPバックボーンのそれとは無関係のIPアドレス指定を使用する可能性があるため。具体的には、顧客のIPネットワークは非ユニーク使用することができ、プライベートIPアドレス指定の[4]。
In general customers using VPNs require some form of data security. There are different trust models applicable to the use of VPNs. One such model is where the customer does not trust the service provider to provide any form of security, and instead implements a VPN using CPE devices that implement firewall functionality and that are connected together using secure tunnels. In this case the service provider is used solely for IP packet transport.
一般の顧客にVPNを使用して、データセキュリティのいくつかのフォームを必要としています。 VPNの使用に適用異なる信頼モデルがあります。そのようなモデルの1つは、顧客がセキュリティの任意のフォームを提供するサービスプロバイダを信頼していないところで、代わりにファイアウォール機能を実装し、安全なトンネルを使用して互いに接続されているCPEデバイスを使用してVPNを実装しています。この場合、サービスプロバイダは、IPパケットトランスポートのためだけに使用されています。
An alternative model is where the customer trusts the service provider to provide a secure managed VPN service. This is similar to the trust involved when a customer utilizes a public switched Frame Relay or ATM service, in that the customer trusts that packets will not be misdirected, injected into the network in an unauthorized manner, snooped on, modified in transit, or subjected to traffic analysis by unauthorized parties.
お客様が安全に管理VPNサービスを提供するサービスプロバイダを信頼どこ代替モデルがあります。これは、顧客が公共のパケットは、誤った方向に向け不正な方法でネットワークに注入され、上の詮索、途中で変更、または受けることはないだろうという顧客の信託で、フレームリレーやATMサービスを切り替え利用する場合関わる信託に似ています権限のない者によるトラフィック分析へ。
With this model providing firewall functionality and secure packet transport services is the responsibility of the service provider. Different levels of security may be needed within the provider backbone, depending on the deployment scenario used. If the VPN traffic is contained within a single provider's IP backbone then strong security mechanisms, such as those provided by the IP Security protocol suite (IPSec) [5], may not be necessary for tunnels between backbone nodes. If the VPN traffic traverses networks or equipment owned by multiple administrations then strong security mechanisms may be appropriate. Also a strong level of security may be applied by a provider to customer traffic to address a customer perception that IP networks, and particularly the Internet, are insecure. Whether or not this perception is correct it is one that must be addressed by the VPN implementation.
ファイアウォール機能と安全なパケット・トランスポート・サービスを提供するこのモデルでは、サービスプロバイダの責任です。異なるレベルのセキュリティを使用し、展開シナリオに応じて、プロバイダのバックボーン内で必要することができます。 VPNトラフィックは、単一のプロバイダのIPバックボーン内に含まれる場合、このようなIPセキュリティプロトコルスイート（IPSec）のによって提供されるもののような強力なセキュリティメカニズムは、[5]、バックボーンノード間のトンネルのために必要ではないかもしれません。 VPNトラフィックが複数回投与が所有するネットワークや機器を横断場合は、強力なセキュリティメカニズムが適切かもしれません。また、セキュリティの強固なレベルは、IPネットワーク、特にインターネットは、安全ではないことを、顧客の認識に対処するために、顧客のトラフィックにプロバイダによって適用することができます。この認識が正しいかどうか、それは、VPNの実装によって対処しなければならないものです。
In addition to ensuring communication privacy, existing private networking techniques, building upon physical or link layer mechanisms, also offer various types of quality of service guarantees. In particular, leased and dial up lines offer both bandwidth and latency guarantees, while dedicated connection technologies like ATM and Frame Relay have extensive mechanisms for similar guarantees. As IP based VPNs become more widely deployed, there will be market demand for similar guarantees, in order to ensure end to end application transparency. While the ability of IP based VPNs to offer such guarantees will depend greatly upon the commensurate capabilities of the underlying IP backbones, a VPN framework must also address the means by which VPN systems can utilize such capabilities, as they evolve.
、通信のプライバシーを確保するプライベートネットワーク技術を既存の物理またはリンクレイヤメカニズムにより構築に加えて、サービス保証の品質の様々な種類を提供します。 ATMやフレームリレーなどの専用接続技術は、同様の保証のための大規模なメカニズムを持っていながら。特に、リースとダイヤルアップ回線は、両方の帯域幅と遅延保証を提供しますIPベースのVPNはより広く展開になると、アプリケーションの透明性をエンドツーエンドを確保するために、同様の保証に対する市場の需要があるでしょう。そのような保証を提供するIPベースのVPNの能力が大幅に基本的なIPバックボーンの相応の能力に依存しますが、VPNフレームワークはまた、彼らは進化としてVPNシステムは、こうした機能を利用することができる手段に対処しなければなりません。
Together, the first two of the requirements listed above imply that VPNs must be implemented through some form of IP tunneling mechanism, where the packet formats and/or the addressing used within the VPN can be unrelated to that used to route the tunneled packets across the IP backbone. Such tunnels, depending upon their form, can provide some level of intrinsic data security, or this can also be enhanced using other mechanisms (e.g., IPSec).
一緒に、上記の要件の最初の二つは、VPNがパケットフォーマット及び/又は横切るトンネルパケット経路に使用されるものとは無関係であることができるVPN内で使用されるIPアドレス指定トンネリング機構のいくつかのフォームを介して実装されなければならないことを意味しますIPバックボーン。このようなトンネルは、その形態に応じて、固有のデータセキュリティのいくつかのレベルを提供することができ、またはこれは、他の機構（例えば、IPSec）を使用して向上させることができます。
Furthermore, as discussed later, such tunneling mechanisms can also be mapped into evolving IP traffic management mechanisms. There are already defined a large number of IP tunneling mechanisms. Some of these are well suited to VPN applications, as discussed in section 3.0.
後述するように、さらに、このようなトンネリングメカニズムは、IPトラフィック管理メカニズムを進化にマッピングすることができます。すでにIPトンネリングメカニズムが多数定義されています。セクション3.0で説明したようにこれらのいくつかは、VPNアプリケーションに適しています。
Most current VPN implementations are based on CPE equipment. VPN capabilities are being integrated into a wide variety of CPE devices, ranging from firewalls to WAN edge routers and specialized VPN termination devices. Such equipment may be bought and deployed by customers, or may be deployed (and often remotely managed) by service providers in an outsourcing service.
現在のほとんどのVPNの実装は、CPE機器に基づいています。 VPN機能は、ファイアウォールからWANエッジルータと特殊VPN終端装置に至るまで、CPEデバイスの広範囲に組み込まれています。このような機器は購入し、顧客が展開され、またはアウトソーシングサービスで、サービスプロバイダによって展開（そして多くの場合、リモートで管理）することができることができます。
There is also significant interest in 'network based VPNs', where the operation of the VPN is outsourced to an Internet Service Provider (ISP), and is implemented on network as opposed to CPE equipment. There is significant interest in such solutions both by customers seeking to reduce support costs and by ISPs seeking new revenue sources. Supporting VPNs in the network allows the use of particular mechanisms which may lead to highly efficient and cost effective VPN solutions, with common equipment and operations support amortized across large numbers of customers.
VPNの動作は、インターネットサービスプロバイダ（ISP）に委託されており、CPE機器とは対照的に、ネットワーク上で実装されている「ネットワークベースのVPN」に大きな関心があります。サポートコストを削減しようとしている顧客が、新たな収入源を求めているISPによる両方の、このようなソリューションに大きな関心が寄せられています。ネットワークでVPNをサポートする一般的な装置と操作で、高度に効率的かつコスト効果的なVPNソリューションをもたらし得る特定の機構の使用は、顧客の多数横切っ償却サポートすることができます。
Most of the mechanisms discussed below can apply to either CPE based or network based VPNs. However particular mechanisms are likely to prove applicable only to the latter, since they leverage tools (e.g., piggybacking on routing protocols) which are accessible only to ISPs and which are unlikely to be made available to any customer, or even hosted on ISP owned and operated CPE, due to the problems of coordinating joint management of the CPE gear by both the ISP and the customer. This document will indicate which techniques are likely to apply only to network based VPNs.
以下で説明するメカニズムのほとんどは、CPEベースまたはネットワークベースのVPNのいずれかに適用することができます。特定のメカニズムが彼らのレバレッジツール（例えば、ルーティングプロトコルに便乗）のみのISPにアクセス可能であり、そうであることはあらゆる顧客が利用できるように、あるいは所有のISPでホストされていることがあるため、後者のみに適用さを証明する可能性があるがとISPと顧客の両方によってCPEギアの共同管理を調整する問題に、CPEを運営。このドキュメントは、技術が唯一のネットワークベースのVPNに適用する可能性があるかを示します。
The term 'extranet' is commonly used to refer to a scenario whereby two or more companies have networked access to a limited amount of each other's corporate data. For example a manufacturing company might use an extranet for its suppliers to allow it to query databases for the pricing and availability of components, and then to order and track the status of outstanding orders. Another example is joint software development, for instance, company A allows one development group within company B to access its operating system source code, and company B allows one development group in company A to access its security software. Note that the access policies can get arbitrarily complex. For example company B may internally restrict access to its security software to groups in certain geographic locations to comply with export control laws, for example.
用語「エクストラネットは、」一般的に二つ以上の企業が互いの企業の限られた量のデータへのネットワーク接続のアクセス権を持っていることにより、シナリオを参照するために使用されます。例えば、製造会社は、注文し、優れた注文の状況を追跡するために、そのサプライヤーが、それは部品の価格と可用性のためのデータベースを照会できるようにするためにエクストラネットを使用し、可能性があります。別の例は、共同ソフトウェア開発であり、例えば、会社Aは、そのオペレーティング・システムのソース・コードにアクセスするために、会社B内の1つの開発グループを可能にし、会社Bは会社Aの1つの開発グループがセキュリティソフトウェアにアクセスすることを可能にします。アクセスポリシーは、任意の複雑得ることができることに注意してください。たとえば、会社Bは、内部例えば、輸出管理法を遵守するために、特定の地理的な場所でのグループへのセキュリティソフトウェアへのアクセスを制限することができます。
A key feature of an extranet is thus the control of who can access what data, and this is essentially a policy decision. Policy decisions are typically enforced today at the interconnection points between different domains, for example between a private network and the Internet, or between a software test lab and the rest of the company network. The enforcement may be done via a firewall, router with access list functionality, application gateway, or any similar device capable of applying policy to transit traffic. Policy controls may be implemented within a corporate network, in addition to between corporate networks. Also the interconnections between networks could be a set of bilateral links, or could be a separate network, perhaps maintained by an industry consortium. This separate network could itself be a VPN or a physical network.
エクストラネットの重要な特徴は、このようにどのデータにアクセスできるユーザーの制御であり、これは、本質的に政策決定です。政策決定は、通常、プライベートネットワークとインターネットの間例えば、ソフトウェアのテストラボと企業ネットワークの残りの部分との間に、異なるドメイン間の相互接続点で、今日施行されています。施行は、アクセスリスト機能、アプリケーションゲートウェイ、またはトランジットトラフィックにポリシーを適用することができる任意の同様の装置と、ファイアウォール、ルータを介して行われてもよいです。ポリシーコントロールは、企業ネットワークの間に加えて、企業ネットワーク内に実装することができます。また、ネットワーク間の相互接続は、バイラテラルリンクのセットであり得る、または多分業界コンソーシアムによって維持別個のネットワークであってもよいです。この独立したネットワークは、それ自体がVPNまたは物理的なネットワークである可能性があります。
Introducing VPNs into a network does not require any change to this model. Policy can be enforced between two VPNs, or between a VPN and the Internet, in exactly the same manner as is done today without VPNs. For example two VPNs could be interconnected, which each administration locally imposing its own policy controls, via a firewall, on all traffic that enters its VPN from the outside, whether from another VPN or from the Internet.
ネットワークにVPNを導入することは、このモデルに変更を必要としません。 VPNをすることなく、今日行われているようにポリシーは、まったく同じ方法で、2つのVPN間、またはVPNとインターネットの間に施行することができます。例えば、2つのVPNは、他のVPNから、またはインターネットからか、外部からそのVPNに入るすべてのトラフィックに対して、ファイアウォールを経由して、各投与はローカルに、独自のポリシー制御を課しており、相互に接続することができます。
This model of a VPN provides for a separation of policy from the underlying mode of packet transport used. For example, a router may direct voice traffic to ATM Virtual Channel Connections (VCCs) for guaranteed QoS, non-local internal company traffic to secure tunnels, and other traffic to a link to the Internet. In the past the secure tunnels may have been frame relay circuits, now they may also be secure IP tunnels or MPLS Label Switched Paths (LSPs)
VPNのこのモデルは、使用されるパケットトランスポートの基本モードからポリシーの分離を提供します。例えば、ルータは、インターネットへのリンクに保証されたQoSのための仮想チャネル接続（VCC）、非ローカル社内トンネルを確保するトラフィック、および他のトラフィックをATMする音声トラフィックを指示することができます。過去には、セキュアトンネルは、今、彼らはまた、セキュアなIPトンネルであってもよいし、MPLSラベルが（LSPを）パスの交換、フレームリレー回路であったかもしれません
Other models of a VPN are also possible. For example there is a model whereby a set of application flows is mapped into a VPN. As the policy rules imposed by a network administrator can get quite complex, the number of distinct sets of application flows that are used in the policy rulebase, and hence the number of VPNs, can thus grow quite large, and there can be multiple overlapping VPNs. However there is little to be gained by introducing such new complexity into a network. Instead a VPN should be viewed as a direct analogue to a physical network, as this allows the leveraging of existing protocols and procedures, and the current expertise and skill sets of network administrators and customers.
VPNの他のモデルも可能です。例えば、アプリケーションフローのセットは、VPNにマッピングされるモデルがあります。ネットワーク管理者によって課されたポリシールールは非常に複雑得ることができるように、ポリシールールベースで使用され、したがってVPNの数は、このように非常に大きく成長することができ、かつ複数の重複のVPNが存在することができるアプリケーションフローの異なるセットの数。しかし、ネットワークに新たな複雑さを導入することによって得られることが少しはあります。これは、既存のプロトコルと手順、およびネットワーク管理者や顧客の現在の専門知識とスキルセットの活用を可能とする代わりにVPNは、物理的なネットワークへの直接アナログとして表示する必要があります。
As noted above in section 2.1, VPNs must be implemented using some form of tunneling mechanism. This section looks at the generic requirements for such VPN tunneling mechanisms. A number of characteristics and aspects common to any link layer protocol are taken and compared with the features offered by existing tunneling protocols. This provides a basis for comparing different protocols and is also useful to highlight areas where existing tunneling protocols could benefit from extensions to better support their operation in a VPN environment.
セクション2.1で上述したように、VPNは、トンネル機構のいくつかのフォームを使用して実装されなければなりません。このセクションでは、このようなVPNトンネリングメカニズムのための一般的な要件を調べます。任意のリンク層プロトコルに共通の特性及び態様の数を取り、既存のトンネリングプロトコルによって提供される機能と比較されます。これは、異なるプロトコルを比較するための基礎を提供し、また、既存のトンネリングプロトコルは、より良いVPN環境でその動作をサポートする拡張機能から利益を得ることができる領域を強調するのに便利です。
An IP tunnel connecting two VPN endpoints is a basic building block from which a variety of different VPN services can be constructed. An IP tunnel operates as an overlay across the IP backbone, and the traffic sent through the tunnel is opaque to the underlying IP backbone. In effect the IP backbone is being used as a link layer technology, and the tunnel forms a point-to-point link.
2つのVPNエンドポイントを接続するIPトンネルは、異なるVPNサービスの様々な構築可能な基本的なビルディング・ブロックです。 IPトンネルは、IPバックボーン上のオーバーレイとして動作し、トンネルを経由して送信されたトラフィックは、基礎となるIPバックボーンに不透明です。実際にはIPバックボーンは、リンク層技術として使用され、トンネルは、ポイントツーポイントリンクを形成します。
A VPN device may terminate multiple IP tunnels and forward packets between these tunnels and other network interfaces in different ways. In the discussion of different types of VPNs, in later sections of this document, the primary distinguishing characteristic of these different types is the manner in which packets are forwarded between interfaces (e.g., bridged or routed). There is a direct analogy with how existing networking devices are characterized today. A two-port repeater just forwards packets between its ports, and does not examine the contents of the packet. A bridge forwards packets using Media Access Control (MAC) layer information contained in the packet, while a router forwards packets using layer 3 addressing information contained in the packet. Each of these three scenarios has a direct VPN analogue, as discussed later. Note that an IP tunnel is viewed as just another sort of link, which can be concatenated with another link, bound to a bridge forwarding table, or bound to an IP forwarding table, depending on the type of VPN.
VPN装置は、複数のIPトンネルと異なる方法でこれらのトンネルと他のネットワークインターフェイス間のパケットを転送し終了することができます。 VPNの異なる種類の議論では、この文書の後のセクションでは、これらの異なるタイプの一次識別特性（例えば、架橋またはルーティング）パケットをインターフェイス間で転送される方法です。既存のネットワークデバイスが、今日特徴としているかとの直接類推があります。 2ポートリピータは、ちょうどそのポート間でパケットを転送し、パケットの内容を検査しません。ルータは、パケットに含まれるレイヤ3アドレス情報を使用してパケットを転送しながら、ブリッジは、パケットに含まれる情報をレイヤメディアアクセス制御（MAC）を使用してパケットを転送します。後述するように、これらの3つのシナリオのそれぞれは、直接VPN類似体を有します。 VPNの種類に応じて、IPトンネルがちょうど他のブリッジフォワーディングテーブルに結合された別のリンクで連結することができるリンクの種類、、、またはIPフォワーディングテーブルに結合したとみなされることに留意されたいです。
The following sections look at the requirements for a generic IP tunneling protocol that can be used as a basic building block to construct different types of VPNs.
次のセクションでは、VPNのさまざまな種類を構築するための基本的なビルディングブロックとして使用することができ、一般的なIPトンネリングプロトコルのための要件を見てください。
There are numerous IP tunneling mechanisms, including IP/IP [6], Generic Routing Encapsulation (GRE) tunnels [7], Layer 2 Tunneling Protocol (L2TP) [8], IPSec [5], and Multiprotocol Label Switching (MPLS) [9]. Note that while some of these protocols are not often thought of as tunneling protocols, they do each allow for opaque transport of frames as packet payload across an IP network, with forwarding disjoint from the address fields of the encapsulated packets.
IP / IP [6]、総称ルーティングカプセル化（GRE）トンネル[7]、レイヤ2トンネリングプロトコル（L2TP）[8]、IPSecの[5]、およびマルチプロトコルラベルスイッチング（MPLS）を含む多数のIPトンネリングメカニズムは、あります9]。これらのプロトコルのいくつかは、多くの場合、トンネリングプロトコルとして考えていない一方で、彼らはそれぞれのカプセル化されたパケットのアドレスフィールドから互いに素を転送すると、IPネットワークを介してパケットのペイロードとしてフレームの不透明な輸送を可能にないことに注意してください。
Note, however, that there is one significant distinction between each of the IP tunneling protocols mentioned above, and MPLS. MPLS can be viewed as a specific link layer for IP, insofar as MPLS specific mechanisms apply only within the scope of an MPLS network, whereas IP based mechanisms extend to the extent of IP reachability. As such, VPN mechanisms built directly upon MPLS tunneling mechanisms cannot, by definition, extend outside the scope of MPLS networks, any more so than, for instance, ATM based mechanisms such as LANE can extend outside of ATM networks. Note however, that an MPLS network can span many different link layer technologies, and so, like an IP network, its scope is not limited by the specific link layers used. A number of proposals for defining a set of mechanisms to allow for interoperable VPNs specifically over MPLS networks have also been produced ([10] [11] [12] [13], [14] and [15]).
、及びMPLS上記IPトンネリングプロトコルのそれぞれの間に1つの重大な違いがあること、しかし、注意してください。 MPLSは、IPベースのメカニズムはIP到達可能性の程度に延び、一方、特定のメカニズムは、MPLSネットワークの範囲内でのみ適用さMPLS限り、IPのための特定のリンク層と見なすことができます。このように、MPLSトンネルメカニズムができない上に直接構築されたVPN機構は、定義により、例えば、そのようなLANEとしてATMベースのメカニズムは、ATMネットワークの外側に延びることができ、それ以上そうではなく、MPLSネットワークの範囲外に延びています。 MPLSネットワークは、多くの異なるリンク層技術にまたがることができ、そのため、IPネットワークのような、その範囲は、使用される特定のリンク層によって限定されるものではないことに留意されたいです。具体的にはMPLSネットワーク上で相互運用可能なVPNのを可能にするためのメカニズムのセットを定義するための提案の数も製造されている（[10] [11] [12] [13]、[14]及び[15]）。
There are a number of desirable requirements for a VPN tunneling mechanism, however, that are not all met by the existing tunneling mechanisms. These requirements include:
VPNトンネリングメカニズムのために望ましい要件の数は、既存のすべてのトンネリングメカニズムによって満たされていないこと、しかし、があります。これらの要件は次のとおりです。
There are cases where multiple VPN tunnels may be needed between the same two IP endpoints. This may be needed, for instance, in cases where the VPNs are network based, and each end point supports multiple customers. Traffic for different customers travels over separate tunnels between the same two physical devices. A multiplexing field is needed to distinguish which packets belong to which tunnel. Sharing a tunnel in this manner may also reduce the latency and processing burden of tunnel set up. Of the existing IP tunneling mechanisms, L2TP (via the tunnel-id and session-id fields), MPLS (via the label) and IPSec (via the Security Parameter Index (SPI) field) have a multiplexing mechanism. Strictly speaking GRE does not have a multiplexing field. However the key field, which was intended to be used for authenticating the source of a packet, has sometimes been used as a multiplexing field. IP/IP does not have a multiplexing field.
複数のVPNトンネルが同じ2つのIPエンドポイント間で必要とされる場合があります。これは、VPNはネットワークベースであり、各エンドポイントは、複数の顧客をサポートしている場合には、例えば、必要になる場合があります。別の顧客のためのトラフィックは、同じ2つの物理デバイス間の別々のトンネルの上を移動します。多重化フィールドは、どのトンネルに属するパケットを区別するために必要です。このようにトンネルを共有することも、設定トンネルの待ち時間及び処理負担を軽減することができます。既存のIPトンネリングメカニズムの、L2TP（トンネルIDとセッションIDフィールドを経由して）、MPLS（ラベル経由）及び（セキュリティパラメータインデックス（SPI）フィールド経由）IPSecは、多重化メカニズムを持っています。厳密に言えばGREは、多重フィールドがありません。しかし、パケットの送信元を認証するために使用されることを意図したキーフィールドは、時には多重フィールドとして使用されてきました。 IP / IPは、多重フィールドがありません。
The IETF [16] and the ATM Forum [17] have standardized on a single format for a globally unique identifier used to identify a VPN (a VPN-ID). A VPN-ID can be used in the control plane, to bind a tunnel to a VPN at tunnel establishment time, or in the data plane, to identify the VPN associated with a packet, on a per-packet basis. In the data plane a VPN encapsulation header can be used by MPLS, MPOA and other tunneling mechanisms to aggregate packets for different VPNs over a single tunnel. In this case an explicit indication of VPN-ID is included with every packet, and no use is made of any tunnel specific multiplexing field. In the control plane a VPN-ID field can be included in any tunnel establishment signalling protocol to allow for the association of a tunnel (e.g., as identified by the SPI field) with a VPN. In this case there is no need for a VPN-ID to be included with every data packet. This is discussed further in section 5.3.1.
IETF [16]とATMフォーラム[17] VPN（VPN-ID）を識別するために使用されるグローバル一意識別子のための単一のフォーマットに標準化しました。 VPN-IDは、パケット単位で、パケットに関連付けられたVPNを識別するために、トンネル確立時、又はデータプレーンでVPNにトンネルを結合するために、制御プレーンで使用することができます。データプレーン内のVPNカプセル化ヘッダは、単一のトンネルを介して異なるVPNのパケットを集約するMPLS、MPOAおよび他のトンネリングメカニズムによって使用することができます。この場合、VPN-IDの明示的な指示は、すべてのパケットに含まれ、そしていかなる使用は任意トンネル特定多重分野で作られていません。制御プレーンではVPN-IDフィールドは、VPNと（SPIフィールドによって識別されるように、例えば）トンネルの関連付けを可能にするために、任意のトンネル確立シグナリングプロトコルに含めることができます。この場合、すべてのデータパケットに含まれるVPN-IDは必要ありません。これは、セクション5.3.1で詳しく説明されています。
There is some configuration information that must be known by an end point in advance of tunnel establishment, such as the IP address of the remote end point, and any relevant tunnel attributes required, such as the level of security needed. Once this information is available, the actual tunnel establishment can be completed in one of two ways - via a management operation, or via a signalling protocol that allows tunnels to be established dynamically.
このようなリモートエンドポイントのIPアドレス、およびそのような必要なセキュリティのレベルとして必要な任意の関連トンネル属性としてトンネル確立の予めエンドポイントによって知られていなければならないいくつかの設定情報があります。管理操作を介して、またはトンネルを動的に確立することを可能にするシグナリングプロトコルを介して、 - この情報が利用可能になると、実際のトンネルの確立は、2つの方法のいずれかで完了することができます。
An example of a management operation would be to use an SNMP Management Information Base (MIB) to configure various tunneling parameters, e.g., MPLS labels, source addresses to use for IP/IP or GRE tunnels, L2TP tunnel-ids and session-ids, or security association parameters for IPSec.
管理操作の例は、例えば、MPLSラベル、送信元アドレスIP / IPまたはGREトンネル、L2TPのトンネルIDとセッションIDに使用する、さまざまなトンネリングパラメータを設定するSNMP管理情報ベース（MIB）を使用することであろうまたはセキュリティアソシエーションは、IPSec用のパラメータ。
Using a signalling protocol can significantly reduce the management burden however, and as such, is essential in many deployment scenarios. It reduces the amount of configuration needed, and also reduces the management co-ordination needed if a VPN spans multiple administrative domains. For example, the value of the multiplexing field, described above, is local to the node assigning the value, and can be kept local if distributed via a signalling protocol, rather than being first configured into a management station and then distributed to the relevant nodes. A signalling protocol also allows nodes that are mobile or are only intermittently connected to establish tunnels on demand.
シグナリングプロトコルを使用すると、大幅しかし、管理の負担を軽減、そのように、多くの展開シナリオに不可欠であることができます。これは、必要な構成の量を減少させ、また、VPNは、複数の管理ドメインにまたがる場合に必要な管理の協調を低減します。例えば、上述した多重化フィールドの値は、値を割り当てるノードに対してローカルであり、シグナリングプロトコルを介して配信した場合に第一の管理ステーションに設定され、関連するノードに分配されるのではなく、ローカルに保つことができます。シグナリングプロトコルは、モバイルであるか、または断続的にしかオンデマンドトンネルを確立するために接続されたノードを可能にします。
When used in a VPN environment a signalling protocol should allow for the transport of a VPN-ID to allow the resulting tunnel to be associated with a particular VPN. It should also allow tunnel attributes to be exchanged or negotiated, for example the use of frame sequencing or the use of multiprotocol transport. Note that the role of the signalling protocol need only be to negotiate tunnel attributes, not to carry information about how the tunnel is used, for example whether the frames carried in the tunnel are to be forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM signalling - the same signalling protocol is used to set up Classical IP logical subnetworks as well as for LANE emulated LANs.
VPN環境で使用するシグナリングプロトコルは、得られたトンネルが特定のVPNに関連することができるようにVPN-IDの輸送を可能にすべきです。また、トンネルフレームシーケンシングまたはマルチトランスポートの使用の使用、例えば、交換又は交渉される属性を可能にすべきです。シグナリングプロトコルの役割のみトンネルで搬送フレームはレイヤ2またはレイヤ3で転送されるべきかどうか、例えば、トンネルの使用方法についての情報を搬送しないように、トンネル属性をネゴシエートすることが必要があることに注意してください（これはQ.2931 ATMシグナリングと同様 - 同一のシグナリングプロトコルは、古典的なIP論理サブネットワークならびにためLANEエミュレートLANを設定するために使用されています。
Of the various IP tunneling protocols, the following ones support a signalling protocol that could be adapted for this purpose: L2TP (the L2TP control protocol), IPSec (the Internet Key Exchange (IKE) protocol [18]), and GRE (as used with mobile-ip tunneling [19]). Also there are two MPLS signalling protocols that can be used to establish LSP tunnels. One uses extensions to the MPLS Label Distribution Protocol (LDP) protocol [20], called Constraint-Based Routing LDP (CR-LDP) [21], and the other uses extensions to the Resource Reservation Protocol (RSVP) for LSP tunnels [22].
使用される（L2TP（L2TP制御プロトコル）のIPSec（インターネット鍵交換（IKE）プロトコル[18]）、およびGRE：様々なIPトンネリングプロトコルを、以下のものが、この目的のために適合させることができるシグナリングプロトコルをサポートモバイルIPトンネリングを持つ[19]）。また、LSPトンネルを確立するために用いることができるシグナリングプロトコル2つのMPLSがあります。一つは、制約ベースのルーティングLDP（CR-LDP）[21]と呼ばれるMPLSラベル配布プロトコル（LDP）プロトコル[20]への拡張を使用し、他方はLSPトンネルのためのリソース予約プロトコル（RSVP）に拡張を使用する[22 ]。
A VPN tunneling protocol must support mechanisms to allow for whatever level of security may be desired by customers, including authentication and/or encryption of various strengths. None of the tunneling mechanisms discussed, other than IPSec, have intrinsic security mechanisms, but rely upon the security characteristics of the underlying IP backbone. In particular, MPLS relies upon the explicit labeling of label switched paths to ensure that packets cannot be misdirected, while the other tunneling mechanisms can all be secured through the use of IPSec. For VPNs implemented over non-IP backbones (e.g., MPOA, Frame Relay or ATM virtual circuits), data security is implicitly provided by the layer two switch infrastructure.
VPNトンネリングプロトコルはセキュリティのどんなレベルを可能にするためのメカニズムをサポートしなければならない様々な強みの認証および/または暗号化を含め、顧客が希望することができます。 IPSecの以外の議論トンネリングメカニズム、のいずれも、固有のセキュリティメカニズムを持っていませんが、基本的なIPバックボーンのセキュリティ特性に依存しています。具体的には、MPLSは、他のトンネリングメカニズムは、すべてのIPSecの使用を介して固定することができるが、ラベルの明示的な標識化は、パケットが誤って誘導することができないことを保証するために経路を切り替えに依存します。非IPバックボーン（例えば、MPOA、フレームリレーまたはATM仮想回線）上に実装されたVPNのため、データのセキュリティは、暗黙的層2つのスイッチインフラストラクチャによって提供されます。
Overall VPN security is not just a capability of the tunnels alone, but has to be viewed in the broader context of how packets are forwarded onto those tunnels. For example with VPRNs implemented with virtual routers, the use of separate routing and forwarding table instances ensures the isolation of traffic between VPNs. Packets on one VPN cannot be misrouted to a tunnel on a second VPN since those tunnels are not visible to the forwarding table of the first VPN.
全体的にVPNのセキュリティだけではトンネルの単なる機能ではなく、パケットがこれらのトンネルに転送されているかのより広い文脈で見ることがあります。仮想ルータを用いて実装VPRNsと、例えば、別個のルーティングおよび転送テーブルインスタンスを使用することは、VPN間のトラフィックの分離を確実にします。これらのトンネルは、最初のVPN転送テーブルに見えないから1 VPN上のパケットは、第二のVPN上のトンネルに誤ってルーティングすることができません。
If some form of signalling mechanism is used by one VPN end point to dynamically establish a tunnel with another endpoint, then there is a requirement to be able to authenticate the party attempting the tunnel establishment. IPSec has an array of schemes for this purpose, allowing, for example, authentication to be based on pre-shared keys, or to use digital signatures and certificates. Other tunneling schemes have weaker forms of authentication. In some cases no authentication may be needed, for example if the tunnels are provisioned, rather than dynamically established, or if the trust model in use does not require it.
シグナリングメカニズムのいくつかのフォームを動的に別のエンドポイントにトンネルを確立するために、1つのVPNエンドポイントによって使用される場合、トンネルの確立を試みる当事者を認証できるようにする必要があります。 IPSecは、この目的のためのスキームのアレイを有している事前共有鍵に基づくように、例えば、認証を可能にする、またはデジタル署名および証明書を使用します。他のトンネリング方式は、認証の弱い形態を有します。トンネルがプロビジョニングされている場合、いくつかのケースでは認証が動的に確立、または使用中の信頼モデルがそれを必要としない場合ではなく、例えば、必要とされなくてもよいです。
Currently the IPSec Encapsulating Security Payload (ESP) protocol [23] can be used to establish SAs that support either encryption or authentication or both. However the protocol specification precludes the use of an SA where neither encryption or authentication is used. In a VPN environment this "null/null" option is useful, since other aspects of the protocol (e.g., that it supports tunneling and multiplexing) may be all that is required. In effect the "null/null" option can be viewed as just another level of data security.
現在、IPSecのカプセル化セキュリティペイロード（ESP）プロトコル[23]は、暗号化や認証のいずれか、または両方をサポートしてSAを確立するために使用することができます。しかし、プロトコル仕様はどちらも暗号化や認証が使用されているSAの使用を排除します。 VPN環境では、この「NULL / NULL」オプションが有用であり、プロトコルの他の側面ので（例えば、それはトンネリングおよび多重化をサポートしていること）がすべてのことが必要であるかもしれません。実際には「ヌル/ nullに」オプションは、データセキュリティのちょうど別のレベルとみなすことができます。
In many applications of VPNs, the VPN may carry opaque, multiprotocol traffic. As such, the tunneling protocol used must also support multiprotocol transport. L2TP is designed to transport Point-to-Point Protocol (PPP) [24] packets, and thus can be used to carry multiprotocol traffic since PPP itself is multiprotocol. GRE also provides for the identification of the protocol being tunneled. IP/IP and IPSec tunnels have no such protocol identification field, since the traffic being tunneled is assumed to be IP.
VPNの多くのアプリケーションでは、VPNは不透明な、マルチプロトコルトラフィックを運ぶことができます。そのため、使用トンネリングプロトコルはまた、マルチプロトコルトランスポートをサポートしている必要があります。 L2TPは、ポイントツーポイントプロトコル（PPP）[24]パケットを移送するように設計され、したがって、PPP自体がマルチあるので、マルチプロトコルトラフィックを運ぶために使用することができます。 GREはまた、トンネリングされたプロトコルの識別を提供します。トンネリングされたトラフィックがIPであると仮定されるので、IP / IPおよびIPSecトンネルは、そのようなプロトコル識別フィールドを有していません。
It is possible to extend the IPSec protocol suite to allow for the transport of multiprotocol packets. This can be achieved, for example, by extending the signalling component of IPSec - IKE, to indicate the protocol type of the traffic being tunneled, or to carry a packet multiplexing header (e.g., an LLC/SNAP header or GRE header) with each tunneled packet. This approach is similar to that used for the same purpose in ATM networks, where signalling is used to indicate the encapsulation used on the VCC, and where packets sent on the VCC can use either an LLC/SNAP header or be placed directly into the AAL5 payload, the latter being known as VC-multiplexing (see [25]).
マルチパケットの輸送を可能にするためにIPsecプロトコルスイートを拡張することが可能です。各々とIKE、トンネリングされたトラフィックのプロトコルタイプを示すために、又はパケット多重化ヘッダ（例えば、LLC / SNAPヘッダまたはGREヘッダ）を運ぶために - これは、例えば、のIPSecの信号成分を拡張することによって、達成することができますトンネリングされたパケット。このアプローチは、シグナリングがVCCで使用されるカプセル化を示すために使用され、そしてVCCに送信されたパケットは、LLC / SNAPヘッダのいずれかを使用できる場所又はAAL5に直接配置されるATMネットワークで同じ目的のために使用されるものと同様ですペイロード、VC-多重化として知られている後者（[25]参照）。
One quality of service attribute required by customers of a VPN may be frame sequencing, matching the equivalent characteristic of physical leased lines or dedicated connections. Sequencing may be required for the efficient operation of particular end to end protocols or applications. In order to implement frame sequencing, the tunneling mechanism must support a sequencing field. Both L2TP and GRE have such a field. IPSec has a sequence number field, but it is used by a receiver to perform an anti-replay check, not to guarantee in-order delivery of packets.
VPNの顧客が必要なサービス属性の一つの品質は、物理的な専用線や専用の接続と同等の特性を一致、フレームシーケンシングかもしれません。配列決定は、プロトコルまたはアプリケーションを終了するために特定の端の効率的な動作のために必要とされ得ます。フレームシーケンシングを実現するためには、トンネリングメカニズムは、シーケンスフィールドをサポートしている必要があります。 L2TPとGREの両方が、そのようなフィールドを持っています。 IPSecは、シーケンス番号フィールドを持っていますが、パケットのインオーダー配信を保証しない、アンチリプレイチェックを実行するために受信機によって使用されます。
It is possible to extend IPSec to allow the use of the existing sequence field to guarantee in-order delivery of packets. This can be achieved, for example, by using IKE to negotiate whether or not sequencing is to be used, and to define an end point behaviour which preserves packet sequencing.
パケットのインオーダー配信を保証するために、既存のシーケンスフィールドの使用を許可するようにIPSecを拡張することが可能です。これは、例えば、配列決定を使用するか否かを交渉するために、パケット順序付けを維持エンドポイントの動作を定義するためにIKEを使用することによって、達成することができます。
The VPN end points must monitor the operation of the VPN tunnels to ensure that connectivity has not been lost, and to take appropriate action (such as route recalculation) if there has been a failure.
VPNエンドポイントは、接続が失われていない、障害があった場合（このような経路の再計算のような）適切な行動を取ることを保証するために、VPNトンネルの動作を監視しなければなりません。
There are two approaches possible. One is for the tunneling protocol itself to periodically check in-band for loss of connectivity, and to provide an explicit indication of failure. For example L2TP has an optional keep-alive mechanism to detect non-operational tunnels.
可能な2つの方法があります。トンネリングプロトコル自体が周期的接続の喪失のために、バンドチェックするために、障害の明示的な指示を提供するためのものです。たとえば、L2TPは、非動作のトンネルを検出するために、オプションのキープアライブ機構を備えています。
The other approach does not require the tunneling protocol itself to perform this function, but relies on the operation of some out-of-band mechanism to determine loss of connectivity. For example if a routing protocol such as Routing Information Protocol (RIP) [26] or Open Shortest Path First (OSPF) [27] is run over a tunnel mesh, a failure to hear from a neighbor within a certain period of time will result in the routing protocol declaring the tunnel to be down. Another out-of-band approach is to perform regular ICMP pings with a peer. This is generally sufficient assurance that the tunnel is operational, due to the fact the tunnel also runs across the same IP backbone.
他のアプローチは、この機能を実行するために、トンネリングプロトコル自体を必要とするが、接続性の損失を決定するために、いくつかのアウトオブバンド機構の動作に依存しません。そのようなルーティング情報プロトコル（RIP）などのルーティングプロトコル[26]またはオープンショーテストパスファースト（OSPF）[27]は、トンネルメッシュ上で実行される場合、例えば、一定期間内に近隣から聞く故障が発生しますトンネルを宣言ルーティングプロトコルにダウンすることができます。別のアウトオブバンドアプローチは、ピアに定期的なICMP pingを実行することです。これは、実際にトンネルも同じIPバックボーン横切る、一般的にトンネルが動作可能であることを十分に保証されます。
When tunnels are established dynamically a distinction needs to be drawn between the static and dynamic tunnel information needed. Before a tunnel can be established some static information is needed by a node, such as the identify of the remote end point and the attributes of the tunnel to propose and accept. This is typically put in place as a result of a configuration operation. As a result of the signalling exchange to establish a tunnel, some dynamic state is established in each end point, such as the value of the multiplexing field or keys to be used. For example with IPSec, the establishment of a Security Association (SA) puts in place the keys to be used for the lifetime of that SA.
トンネルが動的に確立されたときの区別が必要な静的および動的トンネル情報との間に描画する必要があります。トンネルが確立される前に、いくつかの静的情報は、リモートエンドポイントを識別し、トンネルの属性が提案および受諾するように、ノードによって必要とされます。これは、通常、設定操作の結果として、場所に置かれています。トンネルを確立するためのシグナリング交換の結果として、いくつかの動的状態は、使用される多重化フィールドまたは鍵の値と、各エンドポイントにおいて確立されています。 IPSecの持つ例えば、セキュリティアソシエーション（SA）の設立は、そのSAの寿命のために使用されるキーは、所定の位置に置きます。
Different policies may be used as to when to trigger the establishment of a dynamic tunnel. One approach is to use a data-driven approach and to trigger tunnel establishment whenever there is data to be transferred, and to timeout the tunnel due to inactivity. This approach is particularly useful if resources for the tunnel are being allocated in the network for QoS purposes. Another approach is to trigger tunnel establishment whenever the static tunnel configuration information is installed, and to attempt to keep the tunnel up all the time.
別のポリシーは、動的トンネルの確立をトリガするときのように使用することができます。一つのアプローチは、データ駆動型のアプローチを使用して、転送すべきデータがあるたびに、トンネルの確立をトリガすると、非アクティブによるトンネルをタイムアウトすることです。トンネルのためのリソースは、QoS目的のためにネットワークに配置されている場合、このアプローチは、特に有用です。別のアプローチは、静的トンネルの設定情報がインストールされるたびにトンネル確立をトリガするために、すべての時間をトンネルを維持しようとすることです。
An IP tunnel has an associated Maximum Transmission Unit (MTU), just like a regular link. It is conceivable that this MTU may be larger than the MTU of one or more individual hops along the path between tunnel endpoints. If so, some form of frame fragmentation will be required within the tunnel.
IPトンネルは通常のリンクのように、関連する最大送信単位（MTU）を有しています。なお、このMTUは、トンネルエンドポイント間の経路に沿って1つのまたは複数の個々のホップのMTUよりも大きくてもよいと考えられます。もしそうであれば、フレームの断片のいくつかのフォームは、トンネル内で必要とされるであろう。
If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation will occur when the IP datagram reaches a hop with an MTU smaller than the IP tunnel's MTU. This can have undesirable performance implications at the router performing such mid-tunnel fragmentation.
フレームは、1つのIPデータグラムにマッピングされて転送する場合、IPデータグラムは、IPトンネルのMTUよりも小さいMTUを有するホップに到達した場合、通常のIPフラグメンテーションが発生します。これは、ミッドトンネルの断片化を実行するルータで望ましくないパフォーマンスへの影響を持つことができます。
An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism.
トンネリングプロトコル自体は、おそらくトンネルシーケンス番号及びある種のエンド・オブ・メッセージマーカーを使用して、トンネルレベルで動作セグメンテーションとリアセンブリ能力を組み込むための別のアプローチがあります。 （マルチリンクPPPは、フラグメントパケットにこれと同様のメカニズムを使用することに注意してください）。これは、トンネル自体内のIPレベルの断片化を回避します。既存のトンネリングプロトコルはいずれも、このようなメカニズムをサポートしていません。
There is clearly benefit in minimizing the overhead of any tunneling mechanisms. This is particularly important for the transport of jitter and latency sensitive traffic such as packetized voice and video. On the other hand, the use of security mechanisms, such as IPSec, do impose their own overhead, hence the objective should be to minimize overhead over and above that needed for security, and to not burden those tunnels in which security is not mandatory with unnecessary overhead.
任意のトンネリングメカニズムのオーバーヘッドを最小限に抑える利点が明確にあります。これは、パケット化された音声やビデオなどのジッタと遅延に敏感なトラフィックの輸送のために特に重要です。一方、IPSecなどのセキュリティメカニズム、の使用は目的が頭上を超えると安全のために必要なことは、上記最小化すること、およびセキュリティが持つ必須ではありませんであるこれらのトンネル負担ないようにする必要があり、したがって、自分のオーバーヘッドを課すん不要なオーバーヘッド。
One area where the amount of overhead may be significant is when voluntary tunneling is used for dial-up remote clients connecting to a VPN, due to the typically low bandwidth of dial-up links. This is discussed further in section 6.3.
自発的トンネリングによるダイヤルアップリンクの典型的には、低帯域幅、VPNに接続するダイヤルアップリモートクライアントのために使用されるときにオーバーヘッドの量は重要であり得る一の領域です。これはセクション6.3で詳しく説明されています。
During the development of the L2TP protocol procedures were developed for flow and congestion control. These were necessitated primarily because of the need to provide adequate performance over lossy networks when PPP compression is used, which, unlike IP Payload Compression Protocol (IPComp) [28], is stateful across packets. Another motivation was to accommodate devices with very little buffering, used for example to terminate low speed dial-up lines. However the flow and congestion control mechanisms defined in the final version of the L2TP specification are used only for the control channels, and not for data traffic.
L2TPプロトコル手順の開発中に流れと輻輳制御用に開発されました。これらは、主にIPペイロード圧縮プロトコル（のIPComp）[28]とは異なり、ステートフル横切るパケットである、PPP圧縮が使用されている非可逆ネットワーク上十分な性能を提供する必要性を必要としました。もう一つの動機は、低速ダイヤルアップ回線を終端するために例えば使用される非常に小さなバッファリングを備えたデバイスを、対応することでした。しかしながらL2TP仕様の最終版で定義されたフローおよび輻輳制御機構のみ制御チャネルのためではなく、データトラフィックのために使用されます。
In general the interactions between multiple layers of flow and congestion control schemes can be very complex. Given the predominance of TCP traffic in today's networks and the fact that TCP has its own end-to-end flow and congestion control mechanisms, it is not clear that there is much benefit to implementing similar mechanisms within tunneling protocols. Good flow and congestion control schemes, that can adapt to a wide variety of network conditions and deployment scenarios are complex to develop and test, both in themselves and in understanding the interaction with other schemes that may be running in parallel. There may be some benefit, however, in having the capability whereby a sender can shape traffic to the capacity of a receiver in some manner, and in providing the protocol mechanisms to allow a receiver to signal its capabilities to a sender. This is an area that may benefit from further study.
一般に、フローおよび輻輳制御方式の複数の層の間の相互作用は非常に複雑であることができます。今日のネットワークにおけるTCPトラフィックの優位性と、TCPは、独自のエンド・ツー・エンドのフローと輻輳制御機構を持っているという事実を考えると、トンネリングプロトコル内と同様のメカニズムを実装する多くの利点があることは明らかではありません。ネットワークの状態や展開シナリオの多種多様に適応することができ良好な流れと輻輳制御方式は、自分自身および並列に実行されても他のスキームとの相互作用を理解するには、両方の開発およびテストするために複雑です。送信者が何らかの方法で受信機の能力にトラフィックをシェーピングし、受信機が送信者にその機能を通知することを可能にするプロトコルメカニズムを提供することができる能力を有することを、しかし、いくつかの利点があるかもしれません。これは、さらなる研究から利益を得ることができるエリアです。
Note also the work of the Performance Implications of Link Characteristics (PILC) working group of the IETF, which is examining how the properties of different network links can have an impact on the performance of Internet protocols operating over those links.
また、異なるネットワークリンクの特性は、それらのリンク上で動作するインターネットプロトコルのパフォーマンスに影響を与えることができる方法を検討しているIETFのワーキンググループリンク特性のパフォーマンスへの影響（PILC）の作品を注意してください。
As noted above, customers may require that VPNs yield similar behaviour to physical leased lines or dedicated connections with respect to such QoS parameters as loss rates, jitter, latency and bandwidth guarantees. How such guarantees could be delivered will, in general, be a function of the traffic management characteristics of the VPN nodes themselves, and the access and backbone networks across which they are connected.
上述したように、顧客は、VPNは損失率、ジッタ、待ち時間、および帯域保証などのQoSパラメータに関して物理的専用回線又は専用の接続と同様の挙動を生じることを必要とするかもしれません。どのような保証を提供することができ、一般的には、VPNのトラフィック管理特性の関数である自分自身をノード、およびそれらが接続されている全体にアクセスし、バックボーンネットワーク。
A full discussion of QoS and VPNs is outside the scope of this document, however by modeling a VPN tunnel as just another type of link layer, many of the existing mechanisms developed for ensuring QoS over physical links can also be applied. For example at a VPN node, the mechanisms of policing, marking, queuing, shaping and scheduling can all be applied to VPN traffic with VPN-specific parameters, queues and interfaces, just as for non-VPN traffic. The techniques developed for Diffserv, Intserv and for traffic engineering in MPLS are also applicable. See also [29] for a discussion of QoS and VPNs.
QoSおよびVPNの完全な議論は、しかし、リンク層のちょうど別の種類として、VPNトンネルをモデル化し、この文書の範囲外であり、物理リンク上のQoSを確保するために開発された既存のメカニズムの多くを適用することもできます。例えば、VPNノードで、ポリシングのメカニズムは、シェーピングおよびスケジューリングは、すべてちょうど非VPNトラフィック用として、パラメータ、キューおよびインターフェイスVPN固有でVPNトラフィックに適用することができ、キューイング、マーキング。 Diffservの、IntServのためおよびMPLSにおけるトラフィックエンジニアリングのために開発された技術を適用することも可能です。 QoSおよびVPNの議論のための[29]も参照してください。
It should be noted, however, that this model of tunnel operation is not necessarily consistent with the way in which specific tunneling protocols are currently modeled. While a model is an aid to comprehension, and not part of a protocol specification, having differing models can complicate discussions, particularly if a model is misinterpreted as being part of a protocol specification or as constraining choice of implementation method. For example, IPSec tunnel processing can be modeled both as an interface and as an attribute of a particular packet flow.
トンネル動作のこのモデルは、特定のトンネリングプロトコルは、現在モデル化された方法とは必ずしも一致しないことが、留意されるべきです。モデルは、プロトコル仕様の理解への援助、そして一部ではないですが、異なるモデルを有するモデルがプロトコル仕様の一部であるとして、または実装方法の選択を制約すると誤解される場合は特に、議論を複雑にすることができます。例えば、IPSecトンネル処理インターフェースとして特定のパケットフローの属性の両方としてモデル化することができます。
IPSec is needed whenever there is a requirement for strong encryption or strong authentication. It also supports multiplexing and a signalling protocol - IKE. However extending the IPSec protocol suite to also cover the following areas would be beneficial, in order to better support the tunneling requirements of a VPN environment.
強力な暗号化や強力な認証の要件があるたびにIPSecが必要とされています。 IKE - それはまた、多重化およびシグナリングプロトコルをサポートしています。しかしまた、以下の分野をカバーするためのIPSecプロトコルスイートを拡張することは、より良いVPN環境のトンネリングの要件をサポートするために、有益であろう。
- the transport of a VPN-ID when establishing an SA (3.1.2)
- SA（3.1.2）を確立するVPN-IDの輸送
- a null encryption and null authentication option (3.1.3)
- ヌル暗号化とヌル認証オプション（3.1.3）
- multiprotocol operation (3.1.4)
- マルチプロトコル動作（3.1.4）
- frame sequencing (3.1.5)
- フレームシーケンス（3.1.5）
L2TP provides no data security by itself, and any PPP security mechanisms used do not apply to the L2TP protocol itself, so that in order for strong security to be provided L2TP must run over IPSec. Defining specific modes of operation for IPSec when it is used to support L2TP traffic will aid interoperability. This is currently a work item for the proposed L2TP working group.
L2TPは、それ自体ではデータのセキュリティを提供していない、とL2TPを提供する強力なセキュリティのための順序でのIPSec上で実行する必要があるように使用されるすべてのPPPのセキュリティメカニズムは、L2TPプロトコル自体には適用されません。 L2TPトラフィックをサポートするために使用されている場合のIPSecのための具体的な動作モードを定義することは、相互運用性を支援します。これは、現在提案されているL2TPワーキンググループの作業項目です。
The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service. In this case a point-to-point link is provided to a customer, connecting two CPE devices, as illustrated below. The link layer type used to connect the CPE devices to the ISP nodes can be any link layer type, for example an ATM VCC or a Frame Relay circuit. The CPE devices can be either routers bridges or hosts.
VPNの最も単純な形式は、「仮想専用線」（VLL）サービスです。以下に示すように、この場合にポイントツーポイントリンクは二つのCPEデバイスを接続し、顧客に提供されます。 ISPノードにCPEデバイスを接続するために使用されるリンクレイヤタイプは、任意のリンク層タイプ、例えばATM VCCまたはフレームリレー回路であることができます。 CPEデバイスは、ルータ、ブリッジまたはホストのいずれかであり得ます。
The two ISP nodes are both connected to an IP network, and an IP tunnel is set up between them. Each ISP node is configured to bind the stub link and the IP tunnel together at layer 2 (e.g., an ATM VCC and the IP tunnel). Frames are relayed between the two links. For example the ATM Adaptation Layer 5 (AAL5) payload is taken and encapsulated in an IPSec tunnel, and vice versa. The contents of the AAL5 payload are opaque to the ISP node, and are not examined there.
2つのISPのノードが両方のIPネットワークに接続され、IPトンネルがそれらの間に設定されています。各ISPノードはレイヤ2で一緒スタブリンクとIPトンネルを結合するように構成されている（例えば、ATM VCCとIPトンネル）。フレームは二つのリンク間で中継されます。たとえばATMアダプテーション・レイヤ5（AAL5）ペイロードが取り出され、カプセル化されたIPSecトンネルに、およびその逆れます。 AAL5ペイロードの内容がISPノードに対して不透明であり、そこに検査されていません。
+--------+ ----------- +--------+
+---+ | ISP | ( IP ) | ISP | +---+
|CPE|-------| edge |-----( backbone ) -----| edge |------|CPE|
+---+ ATM | node | ( ) | node | ATM +---+
VCC +--------+ ----------- +--------+ VCC
<--------- IP Tunnel -------->
10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6 Addressing used by customer (transparent to provider)
（プロバイダに対して透明）顧客によって使用されるアドレス指定10.1.1.5サブネット= 10.1.1.4/30 10.1.1.6
Figure 4.1: VLL Example
図4.1：VLL例
To a customer it looks the same as if a single ATM VCC or Frame Relay circuit were used to interconnect the CPE devices, and the customer could be unaware that part of the circuit was in fact implemented over an IP backbone. This may be useful, for example, if a provider wishes to provide a LAN interconnect service using ATM as the network interface, but does not have an ATM network that directly interconnects all possible customer sites.
顧客には、1つのATM VCCまたはフレームリレー回路は、CPEデバイスを相互接続するために使用された、そして顧客は、回路の一部が、IPバックボーンを介して実装され、実際にあったことに気づかない可能性があるかのように同じように見えます。プロバイダがネットワークインタフェースとしてATMを使用してLANの相互接続サービスを提供することを希望するが、直接、可能なすべての顧客サイトを相互接続するATMネットワークを持っていない場合、これは、例えば、有用である可能性があります。
It is not necessary that the two links used to connect the CPE devices to the ISP nodes be of the same media type, but in this case the ISP nodes cannot treat the traffic in an opaque manner, as described above. Instead the ISP nodes must perform the functions of an interworking device between the two media types (e.g., ATM and Frame Relay), and perform functions such as LLC/SNAP to NLPID conversion, mapping between ARP protocol variants and performing any media specific processing that may be expected by the CPE devices (e.g., ATM OAM cell handling or Frame Relay XID exchanges).
なお、上述したように、ISPノードにCPEデバイスを接続するために使用される2つのリンクが同一のメディアタイプであるが、この場合、ISPノードは不透明な方法でトラフィックを扱うことができないことは必要ではありません。代わりISPノードは、その2つのメディアタイプ（例えば、ATMおよびフレーム・リレー）との間のインターワーキング装置の機能を実行し、NLPID変換にかかるLLC / SNAPなどの機能を実行する、ARPプロトコル変異体との間のマッピングと任意のメディアの特定の処理を行う必要がありますCPEデバイス（例えば、ATM OAMセルの取り扱いやフレームリレーXID交換）によって期待することができます。
The IP tunneling protocol used must support multiprotocol operation and may need to support sequencing, if that characteristic is important to the customer traffic. If the tunnels are established using a signalling protocol, they may be set up in a data driven manner, when a frame is received from a customer link and no tunnel exists, or the tunnels may be established at provisioning time and kept up permanently.
使用するIPトンネリングプロトコルは、マルチプロトコルの動作をサポートしている必要があり、その特性は、顧客のトラフィックに重要な場合は、シーケンシングをサポートする必要があるかもしれません。トンネルは、シグナリングプロトコルを使用して確立される場合、それらはデータ駆動方法で設定することができるフレームは顧客リンクなしトンネルから受信した場合、存在する、またはトンネルは時間をプロビジョニングで確立と恒久的に最大に保つことができます。
Note that the use of the term 'VLL' in this document is different to that used in the definition of the Diffserv Expedited Forwarding Per Hop Behaviour (EF-PHB) [30]. In that document a VLL is used to mean a low latency, low jitter, assured bandwidth path, which can be provided using the described PHB. Thus the focus there is primarily on link characteristics that are temporal in nature. In this document the term VLL does not imply the use of any specific QoS mechanism, Diffserv or otherwise. Instead the focus is primarily on link characteristics that are more topological in nature, (e.g., such as constructing a link which includes an IP tunnel as one segment of the link). For a truly complete emulation of a link layer both the temporal and topological aspects need to be taken into account.
この文書における用語「VLL」の使用は、Diffservの緊急転送当たりホップ挙動（EF-PHB）[30]の定義に使用されるものとは異なることに注意してください。その文書でVLLを説明PHBを使用して提供することができる低遅延、低ジッタ、保証帯域幅経路を意味するために使用されます。したがって、焦点は主に自然の中で時間的ですリンク特性にあります。この文書では、用語VLLは、任意の特定のQoSメカニズム、Diffservのか、それ以外の使用を意味するものではありません。代わりに、フォーカスは（例えば、そのようなリンクの一つのセグメントとしてIPトンネルを含むリンクを構築するなど）、本質的によりトポロジーであるリンクの特性に主にあります。リンク層の真の完全なエミュレーションのための時間的および位相的な側面の両方を考慮に入れる必要があります。
A Virtual Private Routed Network (VPRN) is defined to be the emulation of a multi-site wide area routed network using IP facilities. This section looks at how a network-based VPRN service can be provided. CPE-based VPRNs are also possible, but are not specifically discussed here. With network-based VPRNs many of the issues that need to be addressed are concerned with configuration and operational issues, which must take into account the split in administrative responsibility between the service provider and the service user.
仮想プライベートネットワークルーティング（VPRN）は、IP機能を使用してマルチサイト広域ルーティングネットワークのエミュレーションになるように定義されます。このセクションでは、ネットワークベースのVPRNサービスを提供することができるかを見ます。 CPEベースVPRNsも可能ですが、ここでは具体的に議論されていません。ネットワークベースのVPRNsで対処する必要がある問題の多くは、サービスプロバイダとサービス利用者間の管理責任で考慮に分割しなければならない設定と運用上の問題、と懸念しています。
The distinguishing characteristic of a VPRN, in comparison to other types of VPNs, is that packet forwarding is carried out at the network layer. A VPRN consists of a mesh of IP tunnels between ISP routers, together with the routing capabilities needed to forward traffic received at each VPRN node to the appropriate destination site. Attached to the ISP routers are CPE routers connected via one or more links, termed 'stub' links. There is a VPRN specific forwarding table at each ISP router to which members of the VPRN are connected. Traffic is forwarded between ISP routers, and between ISP routers and customer sites, using these forwarding tables, which contain network layer reachability information (in contrast to a Virtual Private LAN Segment type of VPN (VPLS) where the forwarding tables contain MAC layer reachability information - see section 7.0).
VPRNの際立った特徴は、VPNの他のタイプと比較して、パケットの転送がネットワーク層で行われることです。 VPRNは一緒に適切な宛先サイトへの各VPRNノードで受信されたトラフィックを転送するために必要なルーティング機能と、ISPルータとの間のIPトンネルのメッシュで構成されています。 ISPルータへの1つ以上のリンクを介して接続されたCPEルータで添付、「スタブ」リンクと呼ばれます。 VPRNのメンバーが接続される各ISPルータにVPRN特定の転送テーブルがあります。トラフィックは、フォワーディングテーブルがMACレイヤ到達可能性情報が含まれているVPNの仮想プライベートLANセグメントタイプ（VPLS）とは対照的に（ネットワーク層到達可能性情報が含まれているこれらの転送テーブルを使用して、ISPルータ間、およびISPルータと顧客サイト間で転送されます - ）のセクション7.0を参照してください。
An example VPRN is illustrated in the following diagram, which shows 3 ISP edge routers connected via a full mesh of IP tunnels, used to interconnect 4 CPE routers. One of the CPE routers is multihomed to the ISP network. In the multihomed case, all stub links may be active, or, as shown, there may be one primary and one or more backup links to be used in case of failure of the primary. The term ' backdoor' link is used to refer to a link between two customer sites that does not traverse the ISP network.
例えばVPRN 4台のCPEルータを相互接続するために使用されるIPトンネルの完全なメッシュを介して接続された3台のISPエッジルータを示す以下の図に示されています。 CPEルータの1つは、ISPのネットワークにマルチホームです。マルチホームの場合には、全てのスタブリンクが示されているように、一次の障害が発生した場合に使用する1つのプライマリと1つまたは複数のバックアップリンクが存在してもよい、アクティブである、またはよいです。用語「バックドア」リンクは、ISPのネットワークを経由しない2つの顧客サイト間のリンクを参照するために使用されます。
10.1.1.0/30 +--------+ +--------+ 10.2.2.0/30
+---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |<--------------------->| edge |-------|CPE|
+---+ stub | router | 10.9.9.4/30 | router | stub +---+
link +--------+ +--------+ link :
| ^ | | ^ :
| | | --------------- | | :
| | +----( )----+ | :
| | ( IP BACKBONE ) | :
| | ( ) | :
| | --------------- | :
| | | | :
| |IP tunnel +--------+ IP tunnel| :
| | | ISP | | :
| +---------->| edge |<----------+ :
| 10.9.9.8/30 | router | 10.9.9.12/30 :
backup| +--------+ backdoor:
link | | | link :
| stub link | | stub link :
| | | :
| +---+ +---+ :
+-------------|CPE| |CPE|.......................:
10.3.3.0/30 +---+ +---+ 10.4.4.0/30
Figure 5.1: VPRN Example
図5.1：VPRN例
The principal benefit of a VPRN is that the complexity and the configuration of the CPE routers is minimized. To a CPE router, the ISP edge router appears as a neighbor router in the customer's network, to which it sends all traffic, using a default route. The tunnel mesh that is set up to transfer traffic extends between the ISP edge routers, not the CPE routers. In effect the burden of tunnel establishment and maintenance and routing configuration is outsourced to the ISP. In addition other services needed for the operation of a VPN such as the provision of a firewall and QoS processing can be handled by a small number of ISP edge routers, rather than a large number of potentially heterogeneous CPE devices. The introduction and management of new services can also be more easily handled, as this can be achieved without the need to upgrade any CPE equipment. This latter benefit is particularly important when there may be large numbers of residential subscribers using VPN services to access private corporate networks. In this respect the model is somewhat akin to that used for telephony services, whereby new services (e.g., call waiting) can be introduced with no change in subscriber equipment.
VPRNの主な利点は、複雑さとCPEルータの構成が最小限に抑えられることです。 CPEルータに、ISPエッジルータは、デフォルトルートを使用して、すべてのトラフィックを送信する、顧客のネットワーク内の隣接ルータとして表示されます。トラフィックを転送するように設定されたトンネルメッシュはISPエッジルータではなく、CPEルータとの間に延びています。実際には、トンネル確立および維持し、ルーティング構成の負担がISPに委託されています。また、ファイアウォールとQoS処理の提供のようなVPNの動作に必要な他のサービスは、ISPエッジルータの数が少ないのではなく、潜在的に異種のCPEデバイスの多数によって処理することができます。これは任意のCPE機器をアップグレードすることなく実現することができるよう、新たなサービスの導入と管理もより簡単に、処理することができます。企業のプライベートネットワークにアクセスするためにVPNサービスを利用して個人加入者の多数があるかもしれないときに、この後者の利点は、特に重要です。この点において、モデルは、新たなサービス（例えば、コールウェイティング）加入者機器における変化なしで導入することができる、電話サービスのために使用されるものと幾分類似しています。
The VPRN type of VPN is in contrast to one where the tunnel mesh extends to the CPE routers, and where the ISP network provides layer 2 connectivity alone. The latter case can be implemented either as a set of VLLs between CPE routers (see section 4.0), in which case the ISP network provides a set of layer 2 point-to-point links, or as a VPLS (see section 7.0), in which case the ISP network is used to emulate a multiaccess LAN segment. With these scenarios a customer may have more flexibility (e.g., any IGP or any protocol can be run across all customer sites) but this usually comes at the expense of a more complex configuration for the customer. Thus, depending on customer requirements, a VPRN or a VPLS may be the more appropriate solution.
VPNのVPRN型トンネルメッシュがCPEルータに延びており、ISPネットワークが単独でレイヤ2接続を提供ここで1とは対照的です。後者の場合は、いずれかのISPネットワークがレイヤ2ポイントツーポイントリンクのセットを提供し、その場合、CPEルータ（セクション4.0を参照）との間のVLLSのセットとして、またはVPLS（セクション7.0を参照）として実装することができますその場合、ISPネットワークがマルチアクセスLANセグメントをエミュレートするために使用されます。これらのシナリオでは、顧客がより多くの柔軟性を有していてもよく（例えば、任意のIGPまたは任意のプロトコルは、すべての顧客のサイトで実行することができます）が、これは通常、顧客のためのより複雑な構成を犠牲にして。従って、顧客の要求に応じて、VPRNまたはVPLSは、より適切な溶液であってもよいです。
Because a VPRN carries out forwarding at the network layer, a single VPRN only directly supports a single network layer protocol. For multiprotocol support, a separate VPRN for each network layer protocol could be used, or one protocol could be tunneled over another (e.g., non-IP protocols tunneled over an IP VPRN) or alternatively the ISP network could be used to provide layer 2 connectivity only, such as with a VPLS as mentioned above.
VPRNは、ネットワーク層での転送を行うため、単一VPRNのみ直接単一のネットワーク層プロトコルをサポートします。マルチプロトコルサポートのために、各ネットワーク層プロトコルのための別個のVPRNを使用することができ、または1つのプロトコルは、別の上にトンネリングすることができる（IP VPRN上トンネリング例えば、非IPプロトコル）または代替的にISPネットワークは、レイヤ2接続を提供するために使用することができますのみ、そのようなVPLSと同様に上述したように。
The issues to be addressed for VPRNs include initial configuration, determination by an ISP edge router of the set of links that are in each VPRN, the set of other routers that have members in the VPRN, and the set of IP address prefixes reachable via each stub link, determination by a CPE router of the set of IP address prefixes to be forwarded to an ISP edge router, the mechanism used to disseminate stub reachability information to the correct set of ISP routers, and the establishment and use of the tunnels used to carry the data traffic. Note also that, although discussed first for VPRNs, many of these issues also apply to the VPLS scenario described later, with the network layer addresses being replaced by link layer addresses.
VPRNsために対処すべき問題は、初期設定、各ビア各VPRNにあるリンクのセット、VPRNにメンバーを有する他のルータのセット、及び到達可能なIPアドレスプレフィクスのセットのISPエッジルータによって決意を含みますスタブリンク、ISPエッジルータに転送するためのIPアドレスプレフィクスのセットのCPEルータによって決意、ISPルータの正しいセットにスタブ到達可能性情報を発信するために使用される機構、及びために使用されるトンネルの確立および使用データトラフィックを運びます。注意また、その、VPRNsために最初に説明するが、これらの問題の多くは、ネットワーク層アドレスをリンク層アドレスによって置き換えられると、後述するVPLSシナリオに適用されます。
Note that VPRN operation is decoupled from the mechanisms used by the customer sites to access the Internet. A typical scenario would be for the ISP edge router to be used to provide both VPRN and Internet connectivity to a customer site. In this case the CPE router just has a default route pointing to the ISP edge router, with the latter being responsible for steering private traffic to the VPRN and other traffic to the Internet, and providing firewall functionality between the two domains. Alternatively a customer site could have Internet connectivity via an ISP router not involved in the VPRN, or even via a different ISP. In this case the CPE device is responsible for splitting the traffic into the two domains and providing firewall functionality.
VPRN操作は、インターネットにアクセスするために顧客サイトで使用される機構から切り離されることに注意してください。 ISPエッジルータは、顧客サイトにVPRNとインターネット接続の両方を提供するために使用されるために一般的なシナリオは次のようになります。この場合、CPEルータはちょうど後者はインターネットにVPRNと他のトラフィックにプライベートトラフィックを操縦し、2つのドメインの間にファイアウォール機能を提供する責任があることで、ISPエッジルータを指すデフォルトルートを持っています。また、お客様のサイトがVPRNに関与していないISPルータを経由して、あるいは異なるISPを経由してインターネット接続を持つことができます。この場合、CPEデバイスは、2つのドメインにトラフィックを分割し、ファイアウォール機能を提供する責任があります。
The topology of a VPRN may consist of a full mesh of tunnels between each VPRN node, or may be an arbitrary topology, such as a set of remote offices connected to the nearest regional site, with these regional sites connected together via a full or partial mesh. With VPRNs using IP tunnels there is much less cost assumed with full meshing than in cases where physical resources (e.g., a leased line) must be allocated for each connected pair of sites, or where the tunneling method requires resources to be allocated in the devices used to interconnect the edge routers (e.g., Frame Relay DLCIs). A full mesh topology yields optimal routing, since it precludes the need for traffic between two sites to traverse a third. Another attraction of a full mesh is that there is no need to configure topology information for the VPRN. Instead, given the member routers of a VPRN, the topology is implicit. If the number of ISP edge routers in a VPRN is very large, however, a full mesh topology may not be appropriate, due to the scaling issues involved, for example, the growth in the number of tunnels needed between sites, (which for n sites is n(n-1)/2), or the number of routing peers per router. Network policy may also lead to non full mesh topologies, for example an administrator may wish to set up the topology so that traffic between two remote sites passes through a central site, rather than go directly between the remote sites. It is also necessary to deal with the scenario where there is only partial connectivity across the IP backbone under certain error conditions (e.g. A can reach B, and B can reach C, but A cannot reach C directly), which can occur if policy routing is being used.
VPRNのトポロジーは、各VPRNノードとの間のトンネルのフルメッシュからなっていてもよい、あるいは最も近い地域サイトに接続されたリモートオフィスの組として任意のトポロジーであってもよく、完全または部分を介して互いに接続され、これらの地域サイトとメッシュ。 VPRNsはIPを使用してサイトの各接続対のために割り当てられなければならない物理的リソース（例えば、専用回線）、又はトンネル方式が装置に割り当てられるリソースを必要とする場合にはより完全な噛み合いと仮定はるかに少ないコストであるトンネルエッジルータを相互接続するために使用される（例えば、リレーのDLCIフレーム）。それは第三を通過するには、2つのサイト間のトラフィックの必要性を排除するため、フルメッシュトポロジは、最適なルーティングを生み出します。フルメッシュのもう一つの魅力は、VPRNのためのトポロジー情報を設定する必要がないということです。代わりに、VPRNのメンバールータ与えられ、トポロジが暗黙的です。 VPRNでISPエッジルータの数が非常に大きい場合、しかしながら、フルメッシュトポロジーは、例えば、原因関与スケーリングの問題に、サイト間で必要なトンネルの数の増加は適切でないかもしれない、（nについてその部位は、Nである（N-1）/ 2）、またはルータ当たりルーティングピアの数。ネットワークポリシーは、2つのリモートサイト間のトラフィックは、リモートサイト間で直接行くのではなく、中央サイトを通過するようになっている。例えば、管理者がトポロジを設定したい場合があり、非フルメッシュトポロジにつながる可能性特定のエラー条件下IPバックボーンを横切る部分的にしか接続がある場合には、ポリシールーティングする場合に発生することができる（例えば、A Bに到達することができ、そしてBがCに達することができるが、直接Cに達することができない）シナリオに対処することも必要です使用されています。
For a network-based VPRN, it is assumed that each customer site CPE router connects to an ISP edge router through one or more point-to-point stub links (e.g. leased lines, ATM or Frame Relay connections). The ISP routers are responsible for learning and disseminating reachability information amongst themselves. The CPE routers must learn the set of destinations reachable via each stub link, though this may be as simple as a default route.
ネットワークベースのVPRNのために、各顧客サイトCPEルータは、1つの以上のポイントツーポイントスタブリンク（例えば専用回線、ATMやフレームリレー接続）を介してISPエッジルータに接続されているものとします。 ISPのルータは、それ自体で到達可能性情報を学習し、普及を担当しています。これはデフォルトルートと同じくらい簡単かもしれませんがCPEルータは、各スタブリンクを介して到達可能な目的地のセットを学ばなければなりません。
The stub links may either be dedicated links, set up via provisioning, or may be dynamic links set up on demand, for example using PPP, voluntary tunneling (see section 6.3), or ATM signalling. With dynamic links it is necessary to authenticate the subscriber, and determine the authorized resources that the subscriber can access (e.g. which VPRNs the subscriber may join). Other than the way the subscriber is initially bound to the VPRN, (and this process may involve extra considerations such as dynamic IP address assignment), the subsequent VPRN mechanisms and services can be used for both types of subscribers in the same way.
スタブリンクがプロビジョニングを介して、設定リンクを、専用であってもよいか、PPP、自発的トンネリング（セクション6.3を参照）、またはATMシグナリングを使用して、例えば、要求に応じて設定動的リンクであってもよいです。動的リンクとは、加入者を認証し、加入者（例えば、加入者が参加することができるVPRNsれる）にアクセスすることができ、承認されたリソースを決定する必要があります。加入者が最初に、VPRNに結合している（このプロセスは、動的IPアドレスの割り当てなどの追加の考慮事項を含んでいてもよい）方法以外の、その後のVPRN機構及びサービスは、同様に、加入者の両方のタイプのために使用することができます。
The addressing used within a VPRN may have no relation to the addressing used on the IP backbone over which the VPRN is instantiated. In particular non-unique private IP addressing may be used [4]. Multiple VPRNs may be instantiated over the same set of physical devices, and they may use the same or overlapping address spaces.
VPRN内で使用されるアドレッシングは、アドレッシングVPRNがインスタンス化された上でIPバックボーン上で使用されるとは関係を持たないことがあります。アドレッシング特定の非一意のプライベートIPで使用することができる[4]。複数のVPRNsは、物理デバイスの同じセット上でインスタンス化することができる、と彼らは同じまたは重複するアドレス空間を使用することができます。
For a VPRN the tunnel mesh forms an overlay network operating over an IP backbone. Within each of the ISP edge routers there must be VPN specific forwarding state to forward packets received from stub links ('ingress traffic') to the appropriate next hop router, and to forward packets received from the core ('egress traffic') to the appropriate stub link. For cases where an ISP edge router supports multiple stub links belonging to the same VPRN, the tunnels can, as a local matter, either terminate on the edge router, or on a stub link. In the former case a VPN specific forwarding table is needed for egress traffic, in the latter case it is not. A VPN specific forwarding table is generally needed in the ingress direction, in order to direct traffic received on a stub link onto the correct IP tunnel towards the core.
VPRNのためにトンネルメッシュは、IPバックボーン上で動作するオーバーレイネットワークを形成しています。 ISPエッジルータの各々内に存在するパケットは、適切な次のホップルータにスタブリンク（「入力トラフィック」）から受信し転送するVPN特定フォワーディング状態でなければならず、パケットを転送するためにコア（「出口トラフィック」）から受信適切なスタブリンク。 ISPエッジルータが同じVPRNに属する複数のスタブリンクをサポートケースでは、トンネルは、ローカルの問題として、エッジルータで終端、またはスタブリンクにすることができます。 VPN特定の転送テーブルを出力トラフィックのために必要とされる前者の場合には、後者の場合にはそうではありません。 VPN特定の転送テーブルは、一般的にトラフィックを向けるために、入力方向で必要とされるコアに向かって正しいIPトンネル上スタブリンク上で受信されました。
Also since a VPRN operates at the internetwork layer, the IP packets sent over a tunnel will have their Time to Live (TTL) field decremented in the normal manner, preventing packets circulating indefinitely in the event of a routing loop within the VPRN.
VPRNは、インターネット層で動作するため、また、トンネルを介して送信されるIPパケットは、VPRN内のルーティングループの場合に無限に循環するパケットを防ぐ、通常の方法でデクリメント（TTL）フィールドを生きて自分の時間を有するであろう。
Note also that a single customer site may belong concurrently to multiple VPRNs and may want to transmit traffic both onto one or more VPRNs and to the default Internet, over the same stub link. There are a number of possible approaches to this problem, but these are outside the scope of this document.
単一の顧客サイトが複数VPRNsに同時に属していてもよいし、同じスタブリンク上で、一つ以上のVPRNs上に、デフォルトのインターネットに両方のトラフィックを送信したいことにも注意してください。そこにこの問題へのアプローチの数があるが、これらはこの文書の範囲外です。
VPRN requirements and mechanisms have been discussed previously in a number of different documents. One of the first was [10], which showed how the same VPN functionality can be implemented over both MPLS and non-MPLS networks. Some others are briefly discussed below.
VPRN要件とメカニズムが異なる文書の数で、以前に議論されています。最初の一つは、同じVPN機能がMPLSおよび非MPLSネットワークの両方の上に実装することができる方法を示した[10]でした。いくつかの他のものは、以下に簡単に説明されています。
There are two main variants as regards the mechanisms used to provide VPRN membership and reachability functionality, - overlay and piggybacking. These are discussed in greater detail in sections
オーバーレイとピギーバック - VPRN会員と到達可能性の機能を提供するために使用されるメカニズムに関して二つの主要なバリエーションがあります。これらのセクションでより詳細に説明されています
5.3.2, 5.3.3 and 5.3.4 below. An example of the overlay model is described in [14], which discusses the provision of VPRN functionality by means of a separate per-VPN routing protocol instance and route and forwarding table instantiation, otherwise known as virtual routing. Each VPN routing instance is isolated from any other VPN routing instance, and from the routing used across the backbone. As a result any routing protocol (e.g. OSPF, RIP2, IS-IS) can be run with any VPRN, independently of the routing protocols used in other VPRNs, or in the backbone itself. The VPN model described in [12] is also an overlay VPRN model using virtual routing. That document is specifically geared towards the provision of VPRN functionality over MPLS backbones, and it describes how VPRN membership dissemination can be automated over an MPLS backbone, by performing VPN neighbor discovery over the base MPLS tunnel mesh. [31] extends the virtual routing model to include VPN areas, and VPN border routers which route between VPN areas. VPN areas may be defined for administrative or technical reasons, such as different underlying network infrastructures (e.g. ATM, MPLS, IP).
5.3.2、5.3.3および5.3.4以下。オーバレイモデルの一例は、別個の単位のVPNルーティングプロトコルインスタンスと経路とそうでない場合、仮想ルーティングとして知られている転送テーブルインスタンス、によってVPRNの機能の提供を説明している、[14]に記載されています。各VPNルーティングインスタンスは、他のVPNルーティングインスタンスから、バックボーンにわたって使用ルーティングから単離されます。結果として、任意のルーティングプロトコル（例えばOSPF、RIP2、IS-IS）は、互いに独立しVPRNsで使用されるルーティングプロトコルの、任意VPRNで実行、または骨格自体にすることができます。 [12]に記載のVPNモデルは、仮想ルーティングを使用してオーバーレイVPRNモデルです。その文書は、特にMPLSバックボーン経由VPRNの機能の提供に向け、それがベースのMPLSトンネルメッシュ上でVPNの近隣探索を実行することにより、MPLSバックボーン上で自動化することができる方法VPRN会員普及を説明しています。 [31] VPNエリア間のどのルートをVPN領域を含むように仮想ルーティング・モデルを拡張し、VPN境界ルータ。 VPN領域は、異なる基本的なネットワークインフラストラクチャ（例えば、ATM、MPLS、IP）などの管理または技術的な理由のために定義されてもよいです。
In contrast [15] describes the provision of VPN functionality using a piggybacking approach for membership and reachability dissemination, with this information being piggybacked in Border Gateway Protocol 4 (BGP) [32] packets. VPNs are constructed using BGP policies, which are used to control which sites can communicate with each other. [13] also uses BGP for piggybacking membership information, and piggybacks reachability information on the protocol used to establish MPLS LSPs (CR-LDP or extended RSVP). Unlike the other proposals, however, this proposal requires the participation on the CPE router to implement the VPN functionality.
対照的に、[15]この情報は、ボーダーゲートウェイプロトコル4（BGP）[32]パケットにピギーバックされると、メンバーシップおよび到達可能性普及のためのピギーバック方式を使用して、VPN機能を提供することを記載しています。 VPNはサイトが互いに通信できるかを制御するために使用されるBGPポリシーを使用して構築されています。 [13]また、会員情報をピギーバックするためのBGPを使用し、MPLSのLSP（CR-LDPまたは拡張RSVP）を確立するために使用されるプロトコルに到達可能性情報をピギーバック。他の提案とは異なり、しかし、この提案は、VPN機能を実装するためにCPEルータ上での参加が必要です。
There are a number of common requirements which any network-based VPRN solution must address, and there are a number of different mechanisms that can be used to meet these requirements. These generic issues are
任意のネットワークベースのVPRNソリューションが対処しなければならない共通の要件がいくつかありますし、これらの要件を満たすために使用することができる多数の異なるメカニズムがあります。これらの一般的な問題があります
1) The use of a globally unique VPN identifier in order to be able to refer to a particular VPN.
1）ためにグローバルに一意のVPN識別子の使用は、特定のVPNを参照できるようにします。
2) VPRN membership determination. An edge router must learn of the local stub links that are in each VPRN, and must learn of the set of other routers that have members in that VPRN.
2）VPRNメンバーシップ決定。エッジルータは、各VPRNにあるローカルスタブリンクから学ばなければならない、そしてそのVPRNでメンバーを持っている他のルータのセットで学ばなければなりません。
3) Stub link reachability information. An edge router must learn the set of addresses and address prefixes reachable via each stub link.
3）スタブリンク到達可能性情報。エッジルータは、アドレスおよび各スタブリンクを介して到達可能なアドレスプレフィックスのセットを学ばなければなりません。
4) Intra-VPRN reachability information. Once an edge router has determined the set of address prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN.
4）イントラVPRN到達可能性情報。エッジルータはそのスタブリンクのそれぞれに関連するアドレス・プレフィックスの組を決定すると、この情報はVPRNに互いにエッジルータに配布されなければなりません。
5) Tunneling mechanism. An edge router must construct the necessary tunnels to other routers that have members in the VPRN, and must perform the encapsulation and decapsulation necessary to send and receive packets over the tunnels.
5）トンネリングメカニズム。エッジルータはVPRNでメンバーを持っている他のルータに必要なトンネルを構築しなければならず、トンネルを介したパケットを送受信するために必要なカプセル化とカプセル化解除を実行する必要があります。
The IETF [16] and the ATM Forum [17] have standardized on a single format for a globally unique identifier used to identify a VPN - a VPN-ID. Only the format of the VPN-ID has been defined, not its semantics or usage. The aim is to allow its use for a wide variety of purposes, and to allow the same identifier to used with different technologies and mechanisms. For example a VPN-ID can be included in a MIB to identify a VPN for management purposes. A VPN-ID can be used in a control plane protocol, for example to bind a tunnel to a VPN at tunnel establishment time. All packets that traverse the tunnel are then implicitly associated with the identified VPN. A VPN-ID can be used in a data plane encapsulation, to allow for an explicit per-packet identification of the VPN associated with the packet. If a VPN is implemented using different technologies (e.g., IP and ATM) in a network, the same identifier can be used to identify the VPN across the different technologies. Also if a VPN spans multiple administrative domains the same identifier can be used everywhere.
VPN-ID - IETF [16]とATMフォーラム[17] VPNを識別するために使用されるグローバル一意識別子のための単一のフォーマットに標準化しました。唯一のVPN-IDのフォーマットは、その意味論や使用ではなく、定義されています。目的は、目的の多種多様のためのその使用を可能にするために、同じ識別子が異なる技術およびメカニズムを使用できるようにすることです。例えば、VPN-IDは、管理目的のためにVPNを識別するために、MIBに含まれることができます。 VPN-IDは、トンネル確立時にVPNトンネルに結合する、例えば、制御プレーンプロトコルで使用することができます。トンネルを通過するすべてのパケットは、その後、暗黙的に識別されたVPNに関連付けられています。 VPN-IDは、パケットに関連付けられたVPNの明示的なパケットごとの識別を可能にするために、データプレーンのカプセル化に使用することができます。 VPNは、ネットワーク内の異なる技術（例えば、IPやATM）を使用して実装されている場合、同じ識別子が異なるテクノロジー間VPNを識別するために使用することができます。 VPNは、複数の管理ドメインにまたがる場合も同じ識別子をどこでも使用することができます。
Most of the VPN schemes developed (e.g. [11], [12], [13], [14]) require the use of a VPN-ID that is carried in control and/or data packets, which is used to associate the packet with a particular VPN. Although the use of a VPN-ID in this manner is very common, it is not universal. [15] describes a scheme where there is no protocol field used to identify a VPN in this manner. In this scheme the VPNs as understood by a user, are administrative constructs, built using BGP policies. There are a number of attributes associated with VPN routes, such as a route distinguisher, and origin and target "VPN", that are used by the underlying protocol mechanisms for disambiguation and scoping, and these are also used by the BGP policy mechanism in the construction of VPNs, but there is nothing corresponding with the VPN-ID as used in the other documents.
開発されたVPN方式のほとんど（例えば、[11]、[12]、[13]、[14]）パケットを関連付けるために使用される制御及び/又はデータパケットで運ばれるVPN-IDの使用を必要とします特定のVPNを持ちます。このようにVPN-IDの使用は非常に一般的ですが、それは普遍的ではありません。 [15]このようにVPNを識別するために使用されるいかなるプロトコルフィールドが存在しないスキームが記載されています。この方式では、ユーザによって理解されるようなVPNは、行政の構築物で、BGPポリシーを使用して構築されました。そこにそのようなルート識別子としてVPN経路、関連付けられた属性の数、および起源であり、「VPN」を標的、曖昧性除去及びスコープの基礎となるプロトコルメカニズムによって使用される、これらはまたにおけるBGPポリシーメカニズムによって使用されていますVPNの構築が、他のドキュメントで使用されるようなVPN-IDに対応するものは何もありません。
Note also that [33] defines a multiprotocol encapsulation for use over ATM AAL5 that uses the standard VPN-ID format.
メモはまた、[33]、標準的なVPN-IDの形式を使用したATM AAL5上使用するためのマルチプロトコルのカプセル化を定義します。
In order to establish a VPRN, or to insert new customer sites into an established VPRN, an ISP edge router must determine which stub links are associated with which VPRN. For static links (e.g. an ATM VCC) this information must be configured into the edge router, since the edge router cannot infer such bindings by itself. An SNMP MIB allowing for bindings between local stub links and VPN identities is one solution.
VPRNを確立するため、または確立VPRNに新しい顧客サイトを挿入するために、ISPエッジルータはリンクがどのVPRNに関連付けられているスタブを決定しなければなりません。エッジルータは、自身がそのようなバインディングを推測することができないので、静的リンク（例えばATM VCC）の場合、この情報は、エッジルータに設定する必要があります。ローカルスタブリンクやVPNのアイデンティティの間のバインディングを可能にSNMP MIBは、1つの解決策です。
For subscribers that attach to the network dynamically (e.g. using PPP or voluntary tunneling) it is possible to make the association between stub link and VPRN as part of the end user authentication processing that must occur with such dynamic links. For example the VPRN to which a user is to be bound may be derived from the domain name the used as part of PPP authentication. If the user is successfully authenticated (e.g. using a Radius server), then the newly created dynamic link can be bound to the correct VPRN. Note that static configuration information is still needed, for example to maintain the list of authorized subscribers for each VPRN, but the location of this static information could be an external authentication server rather than on an ISP edge router. Whether the link was statically or dynamically created, a VPN-ID can be associated with that link to signify to which VPRN it is bound.
動的にネットワークに接続加入者（例えば、PPPあるいは自発的トンネリングを使用して）のためには、ダイナミックリンクで発生しなければならないエンドユーザ認証処理の一部として、スタブリンクとVPRNの間の関連付けを行うことが可能です。例えば、ユーザは、結合されるべきVPRNは、PPP認証の一部として使用されるドメイン名に由来してもよいです。ユーザーが正常に（例えば、RADIUSサーバを使用して）認証された場合、その後、新たに作成された動的リンクが正しいVPRNに結合させることができます。例えば、各VPRNのための認可加入者のリストを維持するために、この静的情報の場所ではなくISPエッジルータよりも外部認証サーバとすることができる、静的構成情報が依然として必要とされていることに留意されたいです。リンクは静的または動的に作成されたかどうか、VPN-IDは、それが結合しているVPRNこれに表すためにそのリンクに関連付けることができます。
After learning which stub links are bound to which VPRN, each edge router must learn either the identity of, or, at least, the route to, each other edge router supporting other stub links in that particular VPRN. Implicit in the latter is the notion that there exists some mechanism by which the configured edge routers can then use this edge router and/or stub link identity information to subsequently set up the appropriate tunnels between them. The problem of VPRN member dissemination between participating edge routers, can be solved in a variety of ways, discussed below.
リンクがVPRNいるにバインドされたスタブ学んだ後、各エッジルータは、少なくとも、その特定のVPRNの他のスタブのリンクをサポートしている各他のエッジルータまでの経路のアイデンティティのどちらかを学び、または必要があります。後者において暗黙構成エッジルータはその後、それらの間の適切なトンネルを設定するために、このエッジルータ及び/又はスタブリンク識別情報を使用することができるいくつかのメカニズムが存在するという考えです。参加エッジルータ間VPRN部材配布の問題は、以下に説明する様々な方法で解決することができます。
The members of a particular VPRN, that is, the identity of the edge routers supporting stub links in the VPRN, and the set of static stub links bound to the VPRN per edge router, could be configured into a directory, which edge routers could query, using some defined mechanism (e.g. Lightweight Directory Access Protocol (LDAP) [34]), upon startup.
特定のVPRNのメンバーは、つまり、VPRNでスタブリンクをサポートするエッジ・ルータのID、およびエッジルータごとにVPRNにバインドされた静的スタブリンクのセットは、エッジルータが照会できディレクトリの中に構成することができ、いくつかの定義されたメカニズムを使用して（例えばLDAP（Lightweight Directory Access Protocol）の[34]）、起動時に。
Using a directory allows either a full mesh topology or an arbitrary topology to be configured. For a full mesh, the full list of member routers in a VPRN is distributed everywhere. For an arbitrary topology, different routers may receive different member lists.
ディレクトリを使用してフルメッシュトポロジまたは任意のトポロジーのいずれかを設定することを可能にします。フルメッシュの場合は、VPRNのメンバールータの完全なリストはどこにでも配布されています。任意のトポロジーのために、異なるルータが異なるメンバーリストを受信することができます。
Using a directory allows for authorization checking prior to disseminating VPRN membership information, which may be desirable where VPRNs span multiple administrative domains. In such a case, directory to directory protocol mechanisms could also be used to propagate authorized VPRN membership information between the directory systems of the multiple administrative domains.
ディレクトリを使用すると、VPRNsは、複数の管理ドメインにまたがる場所が望ましいかもしれないVPRNメンバーシップ情報を、発信する前に許可検査が可能になります。このような場合には、ディレクトリ・プロトコルメカニズムへのディレクトリはまた、複数の管理ドメインのディレクトリシステムとの間の認可VPRNメンバーシップ情報を伝達するために使用することができます。
There also needs to be some form of database synchronization mechanism (e.g. triggered or regular polling of the directory by edge routers, or active pushing of update information to the edge routers by the directory) in order for all edge routers to learn the identity of newly configured sites inserted into an active VPRN, and also to learn of sites removed from a VPRN.
また、データベースの同期メカニズムのいくつかのフォームが必要である（例えば、トリガまたはエッジルータによるディレクトリの定期的なポーリング、またはActive Directoryによってエッジルータへの更新情報のプッシュ）、新たに身元を知るために、すべてのエッジルータためにアクティブVPRNに挿入された部位を構成し、またVPRNから除去部位を学習します。
A VPRN MIB could be defined which would allow a central management system to configure each edge router with the identities of each other participating edge router and the identity of each of the static stub links bound to the VPRN. Like the use of a directory, this mechanism allows both full mesh and arbitrary topologies to be configured. Another mechanism using a centralized management system is to use a policy server and use the Common Open Policy Service (COPS) protocol [35] to distribute VPRN membership and policy information, such as the tunnel attributes to use when establishing a tunnel, as described in [36].
VPRN MIBは、中央管理システムは、それぞれ他の参加エッジルータのアイデンティティとVPRNにバインドされた静的スタブリンクのそれぞれのアイデンティティを各エッジルータを設定できるようになるが定義することができます。ディレクトリを使用するように、この機構は、フルメッシュと任意のトポロジの両方が構成されることを可能にします。集中管理システムを使用する別の機構は、VPRNメンバーシップおよびポリシー情報を、配布するポリシーサーバを使用して、共通オープンポリシーサービス（COPS）プロトコル[35]を使用することでトンネルは、トンネルを確立する際に記載されているように、使用する属性など[36]。
Note that this mechanism allows the management station to impose strict authorization control; on the other hand, it may be more difficult to configure edge routers outside the scope of the management system. The management configuration model can also be considered a subset of the directory method, in that the management directories could use MIBs to push VPRN membership information to the participating edge routers, either subsequent to, or as part of, the local stub link configuration process.
このメカニズムは、厳密な許可制御を課すために、管理ステーションを可能にすることに注意してください。一方、管理システムの範囲外のエッジルータを設定することがより困難であり得ます。管理構成モデルは、後続に、または、ローカルスタブリンク設定プロセスの一部として、参加エッジルータにVPRNメンバーシップ情報をプッシュするMIBを使用することができ、その管理ディレクトリに、ディレクトリ方式のサブセットとみなすことができます。
VPRN membership information could be piggybacked into the routing protocols run by each edge router across the IP backbone, since this is an efficient means of automatically propagating information throughout the network to other participating edge routers. Specifically, each route advertisement by each edge router could include, at a minimum, the set of VPN identifiers associated with each edge router, and adequate information to allow other edge routers to determine the identity of, and/or, the route to, the particular edge router. Other edge routers would examine received route advertisements to determine if any contained information was relevant to a supported (i.e., configured) VPRN; this determination could be done by looking for a VPN identifier matching a locally configured VPN. The nature of the piggybacked information, and related issues, such as scoping, and the means by which the nodes advertising particular VPN memberships will be identified, will generally be a function both of the routing protocol and of the nature of the underlying transport.
VPRN会員情報は、これが自動的に他の参加エッジルータにネットワーク全体に情報を伝播する効率的な手段であるため、IPバックボーンを横切る各エッジルータによって実行されるルーティングプロトコルにピギーバックすることができます。具体的には、各エッジルータによって各経路広告は、最低でも、各エッジルータに関連付けられたVPN識別子の組、及び十分な情報が他のエッジルータは、の同一性を決定することを可能にするために、および/または、へのルートが含まれる可能性が特定のエッジルータ。任意の含まれる情報がサポートされている（すなわち、構成）VPRNに関連した場合に他のエッジルータが決定するために、受信した経路広告を調べるであろう。この決意は、ローカルに設定されたVPNと一致するVPN識別子を探すことによって行うことができます。特定のVPNメンバーシップを広告ノードが識別されることによりピギーバック情報の性質、及びそのようなスコープなどの関連問題、及び手段は、一般に、ルーティングプロトコルの基礎となる輸送の性質の両方の関数となります。
Using this method all the routers in the network will have the same view of the VPRN membership information, and so a full mesh topology is easily supported. Supporting an arbitrary topology is more difficult, however, since some form of pruning would seem to be needed.
この方法に、ネットワーク内のすべてのルータを使用すると、VPRN会員資格情報の同じビューを持つことになり、そのため、完全なメッシュトポロジーを簡単にサポートされています。剪定のいくつかのフォームが必要であると思われるので、任意のトポロジーをサポートすることが、しかし、より困難です。
The advantage of the piggybacking scheme is that it allows for efficient information dissemination, but it does require that all nodes in the path, and not just the participating edge routers, be able to accept such modified route advertisements. A disadvantage is that significant administrative complexity may be required to configure scoping mechanisms so as to both permit and constrain the dissemination of the piggybacked advertisements, and in itself this may be quite a configuration burden, particularly if the VPRN spans multiple routing domains (e.g. different autonomous systems / ISPs).
ピギーバック方式の利点は、効率的な情報発信が可能になり、それは、すべてのパス内のノードだけでなく、参加エッジルータは、そのような修飾された経路広告を受け入れることができることが必要ないことです。欠点は、重要管理の複雑さの両方が可能にするようにスコープ機構を構成して、ピギーバック広告の普及を制約するために必要となる場合があり、それ自体で、これはVPRNが異なる複数のルーティングドメイン（例えばまたがる場合は特に、非常に設定負担であってもよいということです自律システム/ ISPは）。
Furthermore, unless some security mechanism is used for routing updates so as to permit only all relevant edge routers to read the piggybacked advertisements, this scheme generally implies a trust model where all routers in the path must perforce be authorized to know this information. Depending upon the nature of the routing protocol, piggybacking may also require intermediate routers, particularly autonomous system (AS) border routers, to cache such advertisements and potentially also re-distribute them between multiple routing protocols.
ピギーバックされた広告を読み取るためにのみ関連するすべてのエッジルータを可能にするようにいくつかのセキュリティメカニズムは、ルーティングアップデートのために使用されていない限り、また、この方式は、一般に、パス内のすべてのルータがこの情報を知ることが許可されPERFORCEなければならない信頼モデルを意味しています。ルーティングプロトコルの性質に応じて、ピギーバックはまた、広告をキャッシュする中間ルータ、特に自律システム（AS）境界ルータを必要とし、潜在的に、複数のルーティングプロトコル間の再配布それらできます。
Each of the schemes described above have merit in particular situations. Note that, in practice, there will almost always be some centralized directory or management system which will maintain VPRN membership information, such as the set of edge routers that are allowed to support a certain VPRN, the bindings of static stub links to VPRNs, or authentication and authorization information for users that access the network via dynamics links. This information needs to be configured and stored in some form of database, so that the additional steps needed to facilitate the configuration of such information into edge routers, and/or, facilitate edge router access to such information, may not be excessively onerous.
上記のスキームの各々は、特定の状況において利点があります。実際には、ほとんど常にVPRNメンバーシップ情報を維持するいくつかの集中ディレクトリや管理システムがあるだろう、ということに注意してください、そのような特定のVPRNをサポートするために許可されているエッジルータのセットとして、VPRNsに静的スタブリンクのバインディング、またはダイナミックリンクを介してネットワークにアクセスするユーザーの認証および認可情報。この情報は、エッジルータにこのような情報の設定を容易にするために必要とされるので、追加のステップ、データベースの何らかの形で構成して格納する必要があり、および/または、そのような情報へのエッジルータへのアクセスを容易に、過度に面倒ではないかもしれません。
There are two aspects to stub site reachability - the means by which VPRN edge routers determine the set of VPRN addresses and address prefixes reachable at each stub site, and the means by which the CPE routers learn the destinations reachable via each stub link. A number of common scenarios are outlined below. In each case the information needed by the ISP edge router is the same - the set of VPRN addresses reachable at the customer site, but the information needed by the CPE router differs.
VPRNエッジルータは、各スタブサイトで到達可能な接頭辞VPRNアドレスとアドレスのセットを決定する手段、およびCPEルータは、各スタブリンクを介して到達可能な目的地を学ぶする手段 - 2つのスタブサイトの到達可能性への側面があります。一般的なシナリオの数は、以下に概説されています。それぞれのケースでISPエッジルータに必要な情報は同じです - VPRNのセットは、顧客のサイトで到達可能なアドレスが、CPEルータが必要とする情報が異なります。
The CPE router is connected via one link to an ISP edge router, which provides both VPRN and Internet connectivity.
CPEルータはVPRNとインターネット接続の両方を提供するISPエッジルータ、1つのリンクを介して接続されています。
This is the simplest case for the CPE router, as it just needs a default route pointing to the ISP edge router.
それだけでISPエッジルータを指すデフォルトルートを必要とするので、これは、CPEルータのための最も単純なケースです。
The CPE router is connected via one link to an ISP edge router, which provides VPRN, but not Internet, connectivity.
CPEルータは、一つVPRNを提供するISPエッジルータへのリンクではなく、インターネット接続を介して接続されています。
The CPE router must know the set of non-local VPRN destinations reachable via that link. This may be a single prefix, or may be a number of disjoint prefixes. The CPE router may be either statically configured with this information, or may learn it dynamically by running an instance of an Interior Gateway Protocol (IGP). For simplicity it is assumed that the IGP used for this purpose is RIP, though it could be any IGP. The ISP edge router will inject into this instance of RIP the VRPN routes which it learns by means of one of the intra-VPRN reachability mechanisms described in section 5.3.4. Note that the instance of RIP run to the CPE, and any instance of a routing protocol used to learn intra-VPRN reachability (even if also RIP) are separate, with the ISP edge router redistributing the routes from one instance to another.
CPEルータはそのリンクを経由して到達可能な非ローカルVPRN先のセットを知っている必要があります。これは、単一の接頭語であってもよいし、ばらばらプレフィックスの数であってもよいです。 CPEルータは、静的この情報を用いて構成することができる、またはインテリアゲートウェイプロトコル（IGP）のインスタンスを実行することによって、動的に学習することができます。それはどんなIGPことができても簡単にするためには、この目的のために使用されるIGPがRIPであると仮定されます。 ISPエッジルータは、セクション5.3.4に記載のイントラVPRN到達可能性機構の一つによって学習RIP VRPN経路のこのインスタンスに注入します。 CPEに対するRIPの実行のインスタンス、およびルーティングプロトコルのインスタンス（また、RIPも）内VPRNの到達可能性を学習するために使用されるが、ISPエッジルータが別のインスタンスからルートを再配布すると、別であることに留意されたいです。
The CPE router is multihomed to the ISP network, which provides VPRN connectivity.
CPEルータは、VPRNの接続性を提供ISPのネットワークにマルチホームです。
In this case all the ISP edge routers could advertise the same VPRN routes to the CPE router, which then sees all VPRN prefixes equally reachable via all links. More specific route redistribution is also possible, whereby each ISP edge router advertises a different set of prefixes to the CPE router.
この場合、すべてのISPのエッジルータは、すべてのリンクを介して均等に到達可能なすべてのVPRN接頭辞を見ているCPEルータに同じVPRNルートをアドバタイズできます。より具体的なルートの再分配は、各ISPエッジルータはCPEルータにプレフィックスの異なるセットをアドバタイズすることにより、も可能です。
The CPE router is connected to the ISP network, which provides VPRN connectivity, but also has a backdoor link to another customer site
CPEルータは、VPRNの接続性を提供ISPのネットワークに接続するだけでなく、別の顧客サイトへの裏口のリンクを持ってい
In this case the ISP edge router will advertise VPRN routes as in case 2 to the CPE device. However now the same destination is reachable via both the ISP edge router and via the backdoor link. If the CPE routers connected to the backdoor link are running the customer's IGP, then the backdoor link may always be the favored link as it will appear an an 'internal' path, whereas the destination as injected via the ISP edge router will appear as an 'external' path (to the customer's IGP). To avoid this problem, assuming that the customer wants the traffic to traverse the ISP network, then a separate instance of RIP should be run between the CPE routers at both ends of the backdoor link, in the same manner as an instance of RIP is run on a stub or backup link between a CPE router and an ISP edge router. This will then also make the backdoor link appear as an external path, and by adjusting the link costs appropriately, the ISP path can always be favored, unless it goes down, when the backdoor link is then used.
この場合、ISPエッジルータは、CPEデバイスにケース2のようにVPRNルートをアドバタイズします。しかし今、同じ宛先がISPエッジルータの両方を介してバックドアリンクを介して到達可能です。バックドアリンクに接続されたCPEルータは、顧客のIGPを実行している場合として表示されますISPエッジルータを介して注入として、それは先のに対し、「内部」のパスを表示されますよう、そして裏口のリンクは常に有利なリンクであってもよいです（顧客のIGPに）「外部」のパス。 RIPのインスタンスが実行されるように、この問題を回避するために、顧客のトラフィックがISPネットワークを横断したいと仮定すると、次に、RIPの別のインスタンスは、同じように、バックドアリンクの両端のCPEルータ間で実行されなければなりませんCPEルータとISPエッジルータ間のスタブまたはバックアップリンク上。バックドアリンクが、その後使用されているとき、それは、ダウンしない限り、これは、その後も外部パスとして、そして適切にリンクコストを調整することにより、バックドアリンクが表示されるようになり、ISPパスは常に、有利なことができます。
The description of the above scenarios covers what reachability information is needed by the ISP edge routers and the CPE routers, and discusses some of the mechanisms used to convey this information. The sections below look at these mechanisms in more detail.
上記シナリオの記述は、到達可能性情報は、ISPエッジルータとCPEルータが必要とされるものを覆っており、この情報を伝えるために使用されるメカニズムのいくつかを論じています。以下のセクションでは、より詳細にこれらのメカニズムを見てください。
A routing protocol can be run between the CPE edge router and the ISP edge router to exchange reachability information. This allows an ISP edge router to learn the VPRN prefixes reachable at a customer site, and also allows a CPE router to learn the destinations reachable via the provider network.
ルーティングプロトコルは、到達可能性情報を交換するためにCPEエッジルータとISPエッジルータとの間で実行することができます。これはVPRNを学ぶためのISPエッジルータは、顧客のサイトで到達可能な接頭辞ができ、また、CPEルータがプロバイダのネットワークを経由して到達可能な宛先を学ぶことができます。
The extent of the routing domain for this protocol instance is generally just the ISP edge router and the CPE router although if the customer site is also running the same protocol as its IGP, then the domain may extend into customer site. If the customer site is running a different routing protocol then the CPE router redistributes the routes between the instance running to the ISP edge router, and the instance running into the customer site.
顧客サイトは、そのIGPと同じプロトコルを実行している場合、ドメインは、顧客サイト内に延びることができるが、このプロトコルのインスタンスのルーティングドメインの程度は一般にちょうどISPエッジルータとCPEルータです。顧客サイトが異なるルーティングプロトコルを実行している場合、CPEルータは、ISPエッジルータに実行中のインスタンスとの間のルートを再配布し、そしてインスタンスは、顧客サイトに実行しています。
Given the typically restricted scope of this routing instance, a simple protocol will generally suffice. RIP is likely to be the most common protocol used, though any routing protocol, such as OSPF, or BGP run in internal mode (IBGP), could also be used.
このルーティングインスタンスの一般的に制限された範囲を与え、単純なプロトコルは、一般的に十分であろう。 RIPは、OSPF、またはBGPなどの任意のルーティングプロトコルは、内部モード（IBGP）で実行されても、使用される最も一般的なプロトコルである可能性が高いにも使用することができます。
Note that the instance of the stub link routing protocol is different from any instance of a routing protocol used for intra-VPRN reachability. For example, if the ISP edge router uses routing protocol piggybacking to disseminate VPRN membership and reachability information across the core, then it may redistribute suitably labeled routes from the CPE routing instance to the core routing instance. The routing protocols used for each instance are decoupled, and any suitable protocol can be used in each case. There is no requirement that the same protocol, or even the same stub link reachability information gathering mechanism, be run between each CPE router and associated ISP edge router in a particular VPRN, since this is a purely local matter.
スタブリンクルーティングプロトコルのインスタンスがイントラVPRN到達可能性のために使用されるルーティングプロトコルのインスタンスとは異なることに留意されたいです。 ISPエッジルータは、コアを横切っVPRN会員と到達可能性情報を広めるために便乗ルーティングプロトコルを使用する場合、例えば、それは、コアルーティングインスタンスにルーティングインスタンスCPEから適切に標識されたルートを再配布してもよいです。インスタンスごとに使用されるルーティングプロトコルが分離され、そして任意の適切なプロトコルは、それぞれの場合に使用することができます。これは純粋にローカルな問題であるため、同じプロトコルまたはメカニズムを集めるも同じスタブリンク到達可能性情報は、各CPEルータと特定のVPRNに関連するISPエッジルータとの間で実行される必要はありません。
This decoupling allows ISPs to deploy a common (across all VPRNs) intra-VPRN reachability mechanism, and a common stub link reachability mechanism, with these mechanisms isolated both from each other, and from the particular IGP used in a customer network. In the first case, due to the IGP-IGP boundary implemented on the ISP edge router, the ISP can insulate the intra-VPRN reachability mechanism from misbehaving stub link protocol instances. In the second case the ISP is not required to be aware of the particular IGP running in a customer site. Other scenarios are possible, where the ISP edge routers are running a routing protocol in the same instance as the customer's IGP, but are unlikely to be practical, since it defeats the purpose of a VPRN simplifying CPE router configuration. In cases where a customer wishes to run an IGP across multiple sites, a VPLS solution is more suitable.
このデカップリングは、ISPは、互いから、及び顧客ネットワークで使用される特定のIGPの両方から単離されたこれらの機構を有する（すべてVPRNs横切って）共通のイントラVPRN到達可能性機構、および共通のスタブリンク到達可能性機構を配備することを可能にします。最初のケースでは、ISPエッジルータに実装さIGP-IGP境界に起因し、ISPは、スタブリンクプロトコルインスタンスを誤動作からイントラVPRN到達可能性機構を絶縁することができます。後者の場合はISPは、顧客サイト内の特定のIGPランニングを意識する必要はありません。他のシナリオは、ISPエッジルータが顧客のIGPと同じインスタンス内のルーティングプロトコルを実行している場合、可能であり、それはVPRN簡略化CPEルータ構成の目的に反しているので、実用的ではないようです。顧客が複数のサイトにIGPを実行したい場合には、VPLSソリューションは、より適しています。
Note that if a particular customer site concurrently belongs to multiple VPRNs (or wishes to concurrently communicate with both a VPRN and the Internet), then the ISP edge router must have some means of unambiguously mapping stub link address prefixes to particular VPRNs. A simple way is to have multiple stub links, one per VPRN. It is also possible to run multiple VPRNs over one stub link. This could be done either by ensuring (and appropriately configuring the
特定の顧客サイトが同時に複数VPRNsに属する（または同時にVPRNとインターネットの両方と通信したい）場合には、ISPエッジルータが明確に特定VPRNsにスタブリンクアドレスプレフィックスをマッピングする手段を有していなければならないことに留意されたいです。簡単な方法は、複数のスタブリンク、VPRNごとに1つずつ持っていることです。 1つのスタブリンクを介して複数のVPRNsを実行することも可能です。これは、確実に（かつ適切に設定することで、どちらかを行うことができます
ISP edge router to know) that particular disjoint address prefixes are mapped into separate VPRNs, or by tagging the routing advertisements from the CPE router with the appropriate VPN identifier. For example if MPLS was being used to convey stub link reachability information, different MPLS labels would be used to differentiate the disjoint prefixes assigned to particular VPRNs. In any case, some administrative procedure would be required for this coordination.
ISPエッジルータは、その特定の互いに素アドレスプレフィックスは別個VPRNsにマッピングされ、又は適切なVPN識別子にCPEルータからルーティング広告をタグ付けすることによってされる）を知っています。 MPLSスタブリンク到達可能性情報を伝えるために使用されていた場合、例えば、異なるMPLSラベルは、特定VPRNsに割り当てられた互いに素プレフィックスを区別するために使用されるであろう。いずれの場合も、いくつかの管理手順については、この調整のために必要とされるであろう。
The reachability information across each stub link could be manually configured, which may be appropriate if the set of addresses or prefixes is small and static.
各スタブリンクを介して到達可能性情報は、手動でアドレスまたはプレフィクスのセットが小さく、静的である場合に適切であり得る、構成することができます。
The set of addresses used by each stub site could be administered and allocated via the VPRN edge router, which may be appropriate for small customer sites, typically containing either a single host, or a single subnet. Address allocation can be carried out using protocols such as PPP or DHCP [37], with, for example, the edge router acting as a Radius client and retrieving the customer's IP address to use from a Radius server, or acting as a DHCP relay and examining the DHCP reply message as it is relayed to the customer site. In this manner the edge router can build up a table of stub link reachability information. Although these address assignment mechanisms are typically used to assign an address to a single host, some vendors have added extensions whereby an address prefix can be assigned, with, in some cases, the CPE device acting as a "mini-DHCP" server and assigning addresses for the hosts in the customer site.
各スタブサイトで使用されるアドレスのセットは、典型的には、単一のホスト、又は単一のサブネットのいずれかを含有する、小さな顧客サイトに適切であり得る、VPRNエッジルータを介して投与し、割り当てることができました。アドレス割り当ては、例えば、エッジルータがRADIUSクライアントとして動作し、RADIUSサーバから使用するように、お客様のIPアドレスを取得する、またはDHCPリレーとして機能する、と、[37]、このようなPPPやDHCPなどのプロトコルを使用して行うことができ、それは顧客サイトに中継されるDHCP応答メッセージを調べます。このように、エッジルータは、スタブリンク到達可能性情報のテーブルを構築することができます。これらのアドレス割り当てメカニズムは、典型的には、単一のホストにアドレスを割り当てるために使用されているが、いくつかのベンダーは、いくつかのケースでは、CPE装置は、「ミニDHCP」サーバとして機能し、割り当て、アドレスプレフィックスを用いて、割り当てることができる拡張機能を追加しました顧客サイト内のホストのアドレス。
Note that with these schemes it is the responsibility of the address allocation server to ensure that each site in the VPN received a disjoint address space. Note also that an ISP would typically only use this mechanism for small stub sites, which are unlikely to have backdoor links.
これらの方式で、VPN内の各サイトは、ばらばらのアドレス空間を受け取ったことを確認するために、アドレス割り当てサーバの責任であることに注意してください。 ISPは通常、唯一のバックドアリンクを持っている可能性が低い小さなスタブサイトのためにこのメカニズムを使用することにも注意してください。
In cases where the CPE router runs MPLS, LDP can be used to convey the set of prefixes at a stub site to a VPRN edge router. Using the downstream unsolicited mode of label distribution the CPE router can distribute a label for each route in the stub site. Note however that the processing carried out by the edge router in this case is more than just the normal LDP processing, since it is learning new routes via LDP, rather than the usual case of learning labels for existing routes that it has learned via standard routing mechanisms.
CPEルータがMPLSを実行しているケースでは、自民党はVPRNエッジルータにスタブサイトでプレフィックスのセットを伝えるために使用することができます。ラベル配布の下流迷惑モードを使用すると、CPEルータは、スタブサイト内の各ルートのラベルを配布することができます。それはむしろ、それは標準のルーティングを介して学習している既存のルートのラベルを学習する通常の場合よりも、自民党を経由して新しいルートを学習しているので、この場合にはエッジルータが行う処理は、普通のLDP処理よりもあることに注意してくださいメカニズム。
Once an edge router has determined the set of prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN. Note also that there is an implicit requirement that the set of reachable addresses within the VPRN be locally unique that is, each VPRN stub link (not performing load sharing) maintain an address space disjoint from any other, so as to permit unambiguous routing. In practical terms, it is also generally desirable, though not required, that this address space be well partitioned i.e., specific, disjoint address prefixes per edge router, so as to preclude the need to maintain and disseminate large numbers of host routes.
エッジルータはそのスタブリンクの各々に関連付けられたプレフィクスのセットを決定すると、この情報はVPRNに互いにエッジルータに配布されなければなりません。明白なルーティングを可能にするように注意もVPRN内の到達可能なアドレスの集合であることをローカルに一意である暗黙の要求があると、各VPRNスタブリンク（ない行う負荷分散）は、他のアドレス空間互いに素を維持します。実際には、維持し、ホストルートを大量に普及する必要性を排除するように、このアドレス空間がよく、エッジルータごとに、すなわち、特定の、ばらばらのアドレスプレフィックスを分配することも必要ではないが、一般的に望ましいです。
The problem of intra-VPN reachability information dissemination can be solved in a number of ways, some of which include the following:
VPN内の到達可能性情報発信の問題は、以下のものを含むいくつかは、いくつかの方法で解決することができます。
Along with VPRN membership information, a central directory could maintain a listing of the address prefixes associated with each customer site. Such information could be obtained by the server through protocol interactions with each edge router. Note that the same directory synchronization issues discussed above in section 5.3.2 also apply in this case.
VPRN会員情報と共に、中央のディレクトリには、各顧客サイトに関連付けられたアドレスプレフィックスのリストを維持することができます。そのような情報は、各エッジルータとのプロトコル相互作用を介してサーバによって得ることができます。セクション5.3.2で上述の同じディレクトリ同期の問題はこの場合にも当てはまることに留意されたいです。
The address spaces associated with each edge router could be explicitly configured into each other router. This is clearly a non-scalable solution, particularly when arbitrary topologies are used, and also raises the question of how the management system learns such information in the first place.
各エッジ・ルータに関連付けられたアドレス空間は、明示的に互いにルータに構成することができます。これは、任意のトポロジが使用されている場合は特に、明らかに非スケーラブルなソリューションであり、また管理システムが最初の場所でそのような情報を学習する方法の問題を提起します。
In this approach, each edge router runs an instance of a routing protocol (a 'virtual router') per VPRN, running across the VPRN tunnels to each peer edge router, to disseminate intra-VPRN reachability information. Both full-mesh and arbitrary VPRN topologies can be easily supported, since the routing protocol itself can run over any topology. The intra-VPRN routing advertisements could be distinguished from normal tunnel data packets either by being addressed directly to the peer edge router, or by a tunnel specific mechanism.
このアプローチでは、各エッジルータは、イントラVPRN到達可能性情報を発信するために、各ピアエッジルータにVPRNトンネルを横切ってランニング、VPRN当たりのルーティングプロトコル（「仮想ルータ」）のインスタンスを実行します。ルーティングプロトコル自体は、任意のトポロジ上で実行することができるので、フルメッシュと任意VPRNトポロジーの両方を容易に支持することができます。イントラVPRNルーティング広告は、ピア・エッジ・ルータに直接アドレス指定されることにより、又はトンネル特定の機構のいずれかによって、通常のトンネルデータパケットと区別することができます。
Note that this intra-VPRN routing protocol need have no relationship either with the IGP of any customer site or with the routing protocols operated by the ISPs in the IP backbone. Depending on the size and scale of the VPRNs to be supported either a simple protocol like RIP or a more sophisticated protocol like OSPF could be used. Because the intra-VPRN routing protocol operates as an overlay over the IP backbone it is wholly transparent to any intermediate routers, and to any edge routers not within the VPRN. This also implies that such routing information can remain opaque to such routers, which may be a necessary security requirements in some cases. Also note that if the routing protocol runs directly over the same tunnels as the data traffic, then it will inherit the same level of security as that afforded the data traffic, for example strong encryption and authentication.
この内VPRNルーティングプロトコルは、任意の顧客サイトのIGPを持つまたはIPバックボーン内のISPが運営するルーティングプロトコルとのいずれかの関係を持っている必要はないことに注意してください。 VPRNsの大きさや規模に応じて、いずれかのRIPやOSPFなどのより洗練されたプロトコルのような単純なプロトコルを使用することができるサポートします。イントラVPRNルーティングプロトコルは、IPバックボーン上のオーバーレイとして動作するためには、任意の中間ルータに、なくVPRN内の任意のエッジルータに完全に透明です。これはまた、そのようなルーティング情報は、いくつかの場合に必要なセキュリティ要件とすることができるようなルータに不透明なままであり得ることを意味します。また、ルーティングプロトコルは、データトラフィックと同じトンネル上で直接実行されている場合それは例えば、強力な暗号化と認証のために、データトラフィックを与えたとして、それは同じレベルのセキュリティを継承することに注意してください。
If the tunnels over which an intra-VPRN routing protocol runs are dedicated to a specific VPN (e.g. a different multiplexing field is used for each VPN) then no changes are needed to the routing protocol itself. On the other hand if shared tunnels are used, then it is necessary to extend the routing protocol to allow a VPN-ID field to be included in routing update packets, to allow sets of prefixes to be associated with a particular VPN.
トンネルがその上イントラVPRNルーティングプロトコルの実行が（例えば、異なる多重化フィールドが各VPNのために使用される）は、特定のVPNに専用されている場合、変更はルーティングプロトコル自体に必要とされません。共有トンネルが使用されている一方、プレフィクスのセットは、特定のVPNに関連することができるように、VPN-IDフィールドが更新パケットをルーティングに含めることを可能にするルーティングプロトコルを拡張する必要があります。
By link reachability protocol is meant a protocol that allows two nodes, connected via a point-to-point link, to exchange reachability information. Given a full mesh topology, each edge router could run a link reachability protocol, for instance some variation of MPLS CR-LDP, across the tunnel to each peer edge router in the VPRN, carrying the VPN-ID and the reachability information of each VPRN running across the tunnel between the two edge routers. If VPRN membership information has already been distributed to an edge router, then the neighbor discovery aspects of a traditional routing protocol are not needed, as the set of neighbors is already known. TCP connections can be used to interconnect the neighbors, to provide reliability. This approach may reduce the processing burden of running routing protocol instances per VPRN, and may be of particular benefit where a shared tunnel mechanism is used to connect a set of edge routers supporting multiple VPRNs.
リンク可到達性プロトコルはポイントツーポイントリンクを介して接続された2つのノードは、到達可能性情報を交換することを可能にするプロトコルを意味します。フルメッシュトポロジーが与えられると、各エッジルータは、VPN-IDと各VPRNの到達可能性情報を運ぶ、VPRNにおける各ピアエッジルータへのトンネルを横切って、例えば、MPLS CR-LDPのいくつかの変化をリンク可到達性プロトコルを実行することができ2つのエッジルータ間のトンネルを横切って実行します。 VPRN会員資格情報が既にエッジルータに配布されている場合は隣人のセットが既に知られているように、その後、伝統的なルーティングプロトコルの近隣探索側面は、必要とされていません。 TCP接続は、信頼性を提供するために、隣人を相互接続するために使用することができます。このアプローチは、VPRNあたりルーティングプロトコルインスタンスを実行しているの処理負担を軽減することができる、共有トンネル機構が複数VPRNsを支持するエッジルータのセットを接続するために使用される特定の有益であり得ます。
Another approach to developing a link reachability protocol would be to base it on IBGP. The problem that needs to be solved by a link reachability protocol is very similar to that solved by IBGP - conveying address prefixes reliably between edge routers.
リンクの到達性プロトコルを開発するための別のアプローチは、IBGPでそれをベースにすることです。エッジルータとの間で確実にアドレスプレフィックスを運ぶ - リンク可到達性プロトコルによって解決される必要があるという問題がIBGPによって解決ものと非常に類似しています。
Using a link reachability protocol it is straightforward to support a full mesh topology - each edge router conveys its own local reachability information to all other routers, but does not redistribute information received from any other router. However once an arbitrary topology needs to be supported, the link reachability protocol needs to develop into a full routing protocol, due to the need to implement mechanisms to avoid loops, and there would seem little benefit in reinventing another routing protocol to deal with this. Some reasons why partially connected meshes may be needed even in a tunneled environment are discussed in section 5.1.1.
リンクの到達性プロトコルを使用して、フルメッシュトポロジをサポートするために簡単です - 各エッジルータは、他のすべてのルータに独自のローカル到達可能性情報を伝えるが、他のルータから受信した情報を再配布しません。任意のトポロジーをサポートする必要が一度ただし、リンクの到達性プロトコルは、ループを回避するためのメカニズムを実装する必要があるのために、完全なルーティングプロトコルに発展する必要があり、これに対処するための別のルーティングプロトコルを再発明ではほとんど利益が思われます。部分的に接続されているメッシュがトンネリングされた環境の中でも、必要とされる理由いくつかの理由は、セクション5.1.1で説明されています。
As with VPRN membership, the set of address prefixes associated with each stub interface could also be piggybacked into the routing advertisements from each edge router and propagated through the network. Other edge routers extract this information from received route advertisements in the same way as they obtain the VPRN membership information (which, in this case, is implicit in the identification of the source of each route advertisement). Note that this scheme may require, depending upon the nature of the routing protocols involved, that intermediate routers, e.g. border routers, cache intra-VPRN routing information in order to propagate it further. This also has implications for the trust model, and for the level of security possible for intra-VPRN routing information.
VPRNのメンバーと同様に、各スタブ・インターフェースに関連付けられているアドレスプレフィックスの組は、各エッジルータからルーティングアドバタイズメントにピギーバックすることができ、ネットワークを介して伝播します。彼らは（この場合には、各経路広告のソースの識別に暗黙である）VPRNメンバーシップ情報を取得するように他のエッジルータは、同様に受信した経路広告からこの情報を抽出します。例えば、この方式が必要とするかもしれないことに注意関与ルーティングプロトコルの性質に応じて、その中間ルータ境界ルータ、さらにそれを伝播するために、ルーティング情報をキャッシュ内VPRN。また、これは信頼モデルのため、イントラVPRNルーティング情報について可能なセキュリティのレベルに影響を与えています。
Note that in any of the cases discussed above, an edge router has the option of disseminating its stub link prefixes in a manner so as to permit tunneling from remote edge routers directly to the egress stub links. Alternatively, it could disseminate the information so as to associate all such prefixes with the edge router, rather than with specific stub links. In this case, the edge router would need to implement a VPN specific forwarding mechanism for egress traffic, to determine the correct egress stub link. The advantage of this is that it may significantly reduce the number of distinct tunnels or tunnel label information which need to be constructed and maintained. Note that this choice is purely a local manner and is not visible to remote edge routers.
上述のいずれの場合も、エッジルータは、遠隔エッジルータから直接出口スタブリンクにトンネリングを可能にするような方法で、そのスタブリンクプレフィックスを広めるためのオプションを有することに留意されたいです。エッジルータとではなく、特定のスタブリンクにこのようなすべてのプレフィクスを関連付けるようにあるいは、それは情報を広めることができました。この場合、エッジルータは、正しい出口スタブリンクを決定するために、出力トラフィック用のVPN特定の転送メカニズムを実装する必要があろう。この利点は、それが大幅に構築され維持される必要がある別個のトンネルまたはトンネルラベル情報の数を減らすことができるということです。この選択は、純粋にローカルな方法で、遠隔エッジルータに表示されていないことに留意されたいです。
Once VPRN membership information has been disseminated, the tunnels comprising the VPRN core can be constructed.
VPRNメンバーシップ情報が播種された後、VPRNコアを含むトンネルを構築することができます。
One approach to setting up the tunnel mesh is to use point-to-point IP tunnels, and the requirements and issues for such tunnels have been discussed in section 3.0. For example while tunnel establishment can be done through manual configuration, this is clearly not likely to be a scalable solution, given the O(n^2) problem of meshed links. As such, tunnel set up should use some form of signalling protocol to allow two nodes to construct a tunnel to each other knowing only each other's identity.
トンネルのメッシュを設定するための一つのアプローチは、ポイントツーポイントのIPトンネルを使用することで、そのようなトンネルの要件および問題がセクション3.0で議論されています。例えば、トンネル確立は、手動設定を介して行うことができるが、これは明らかにメッシュリンクのO（N ^ 2）の問題を与えられたスケーラブルなソリューションである可能性はありません。このように、設定したトンネルは、2つのノードのみが互いの身元を知ってお互いにトンネルを構築できるようにするシグナリングプロトコルのいくつかのフォームを使用する必要があります。
Another approach is to use the multipoint to point 'tunnels' provided by MPLS. As noted in [38], MPLS can be considered to be a form of IP tunneling, since the labels of MPLS packets allow for routing decisions to be decoupled from the addressing information of the packets themselves. MPLS label distribution mechanisms can be used to associate specific sets of MPLS labels with particular VPRN address prefixes supported on particular egress points (i.e., stub links of edge routers) and hence allow other edge routers to explicitly label and route traffic to particular VPRN stub links.
別のアプローチは、MPLSが提供する「トンネル」を指すように、マルチポイントを使用することです。 [38]で述べたようにMPLSパケットのラベルは、ルーティング決定はパケット自身のアドレス情報から分離することを可能にするため、MPLSは、IPトンネリングの形態であると考えることができます。 MPLSラベル配布メカニズムは、特定の出口点（エッジルータの、すなわち、スタブリンク）上でサポートされる特定のVPRNアドレスプレフィックスとMPLSラベルの特定のセットを関連付け、したがって、他のエッジルータが明示的に特定のVPRNスタブリンクにトラフィックを標識し、ルートを許可するために使用することができます。
One attraction of MPLS as a tunneling mechanism is that it may require less processing within each edge router than alternative tunneling mechanisms. This is a function of the fact that data security within a MPLS network is implicit in the explicit label binding, much as with a connection oriented network, such as Frame Relay. This may hence lessen customer concerns about data security and hence require less processor intensive security mechanisms (e.g., IPSec). However there are other potential security concerns with MPLS. There is no direct support for security features such as authentication, confidentiality, and non-repudiation and the trust model for MPLS means that intermediate routers, (which may belong to different administrative domains), through which membership and prefix reachability information is conveyed, must be trusted, not just the edge routers themselves.
トンネリング機構としてMPLSの魅力は、それが別のトンネリングメカニズムより各エッジルータ内の少ない処理を必要とするかもしれないということです。これは、MPLSネットワーク内のデータセキュリティは、フレームリレーなどの接続指向のネットワークと同じくらい、結合明示ラベルで暗黙的であるという事実の関数です。これは、したがって、データセキュリティに関する顧客の懸念を軽減し、したがってより少ないプロセッサ集中セキュリティ・メカニズム（例えば、IPSec）を必要とするかもしれません。しかし、MPLSと他の潜在的なセキュリティ上の懸念があります。そこな認証、機密性、および否認防止などのセキュリティ機能には直接のサポートはありませんし、MPLSのための信頼モデルは、会員とプレフィックス到達可能性情報が搬送される介して中間ルータ、（異なる管理ドメインに属している可能性があるが）、なければならないことを意味しますだけでなく、エッジルータ自身、信頼されます。
The discussion thus far has implicitly assumed that stub routers are connected to one and only one VPRN edge router. In general, this restriction should be capable of being relaxed without any change to VPRN operation, given general market interest in multihoming for reliability and other reasons. In particular, in cases where the stub router supports multiple redundant links, with only one operational at any given time, with the links connected either to the same VPRN edge router, or to two or more different VPRN edge routers, then the stub link reachability mechanisms will both discover the loss of an active link, and the activation of a backup link. In the former situation, the previously connected VPRN edge router will cease advertising reachability to the stub node, while the VPRN edge router with the now active link will begin advertising reachability, hence restoring connectivity.
議論は、これまで暗黙スタブルータは、唯一のVPRNエッジルータに接続されていることを想定しています。一般的に、この制限は、信頼性および他の理由マルチホーミングにおける一般的な市場の関心所与、VPRN動作を変更せずに緩和されることが可能であるべきです。具体的には、スタブルータは次いで、スタブリンク到達可能性、同じVPRNエッジルータに、または二つ以上の異なるVPRNエッジルータのいずれかに接続されたリンクと、任意の時点で動作だけで、複数の冗長リンクをサポートする場合にはメカニズムは、両方のアクティブリンクの損失、およびバックアップリンクの活性化を発見します。現在アクティブリンクとVPRNエッジルータは、したがって、接続を復元し、広告到達可能性を開始します前者の状況では、以前に接続VPRNのエッジルータは、スタブノードへの広告到達可能性を中止します。
An alternative scenario is where the stub node supports multiple active links, using some form of load sharing algorithm. In such a case, multiple VPRN edge routers may have active paths to the stub node, and may so advertise across the VPRN. This scenario should not cause any problem with reachability across the VPRN providing that the intra-VPRN reachability mechanism can accommodate multiple paths to the same prefix, and has the appropriate mechanisms to preclude looping - for instance, distance vector metrics associated with each advertised prefix.
スタブノードが負荷分散アルゴリズムのいくつかのフォームを使用して、複数のアクティブなリンクをサポートする場合、代替シナリオがあります。このような場合には、複数VPRNエッジルータは、スタブノードへのアクティブパスを有していてもよく、そうVPRN横切って広告することができます。このシナリオでは、イントラVPRN到達可能性機構が同じプレフィックスに複数のパスを収容することができることを提供VPRN横切って到達性に問題を引き起こし、そしてループ排除するための適切なメカニズムを有してはならない - 例えば、各アドバタイズプレフィックスに関連付けられた距離ベクトルメトリック。
Multicast and broadcast traffic can be supported across VPRNs either by edge replication or by native multicast support in the backbone. These two cases are discussed below.
マルチキャストおよびブロードキャストトラフィックは、エッジの複製またはバックボーンにおけるネイティブマルチキャストサポートのいずれかによってVPRNs全体でサポートすることができます。これら2例については後述します。
This is where each VPRN edge router replicates multicast traffic for transmission across each link in the VPRN. Note that this is the same operation that would be performed by CPE routers terminating actual physical links or dedicated connections. As with CPE routers, multicast routing protocols could also be run on each VPRN edge router to determine the distribution tree for multicast traffic and hence reduce unnecessary flood traffic. This could be done by running instances of standard multicast routing protocols, e.g. Protocol Independent Multicast (PIM) [39] or Distance Vector Multicast Routing Protocol (DVMRP) [40], on and between each VPRN edge router, through the VPRN tunnels, in the same way that unicast routing protocols might be run at each VPRN edge router to determine intra-VPN unicast reachability, as discussed in section 5.3.4. Alternatively, if a link reachability protocol was run across the VPRN tunnels for intra-VPRN reachability, then this could also be augmented to allow VPRN edge routers to indicate both the particular multicast groups requested for reception at each edge node, and also the multicast sources at each edge site.
各VPRNエッジルータはVPRNの各リンク上の伝送のためのマルチキャストトラフィックを複製するところです。これは、実際の物理リンクまたは専用接続を終端CPEルータによって実行される同様の動作であることに留意されたいです。 CPEルータと同様に、マルチキャストルーティングプロトコルは、マルチキャストトラフィックのための配信ツリーを決定するために、各VPRNエッジルータ上で動作し、したがって、不要なフラッディングトラフィックを削減することができます。これは、例えば、標準的なマルチキャストルーティングプロトコルのインスタンスを実行することによって行うことができますプロトコル独立マルチキャスト（PIM）[39]または距離ベクトルマルチキャストルーティングプロトコル（DVMRP）は[40]、および各VPRNエッジルータとの間で、VPRNトンネルを介して、同様に、ユニキャストルーティングプロトコルは、各VPRNエッジで実行されるかもしれませんセクション5.3.4で説明したように、イントラVPNユニキャスト到達可能性を決定するルータ。リンク可到達性プロトコルがイントラVPRN到達可能性のためにVPRNトンネルを横切って実行された場合あるいは、これはまた、VPRNエッジルータは、各エッジノードでの受信のために要求された特定のマルチキャストグループ、及び、マルチキャストソースの両方を示すことができるように拡張することができます各エッジサイトで。
In either case, there would need to be some mechanism to allow for the VPRN edge routers to determine which particular multicast groups were requested at each site and which sources were present at each site. How this could be done would, in general, be a function of the capabilities of the CPE stub routers at each site. If these run multicast routing protocols, then they can interact directly with the equivalent protocols at each VPRN edge router. If the CPE device does not run a multicast routing protocol, then in the absence of Internet Group Management Protocol (IGMP) proxying [41] the customer site would be limited to a single subnet connected to the VPRN edge router via a bridging device, as the scope of an IGMP message is limited to a single subnet. However using IGMP-proxying the CPE router can engage in multicast forwarding without running a multicast routing protocol, in constrained topologies. On its interfaces into the customer site the CPE router performs the router functions of IGMP, and on its interface to the VPRN edge router it performs the host functions of IGMP.
いずれの場合においても、その特定のマルチキャストグループを決定するためにVPRNエッジルータを可能にするいくつかのメカニズムがあることが必要となる各部位に要求されたソースは、各サイトに存在しています。どのようにこれは、一般的には、各サイトのCPEスタブルータの機能の機能だろう行うことができます。これらは、マルチキャストルーティングプロトコルを実行する場合、それらは各VPRNエッジルータでの等価なプロトコルと直接対話することができます。 CPE装置は、マルチキャストルーティングプロトコルを実行しない場合は、インターネットグループ管理プロトコル（IGMP）プロキシの非存在下で[41]顧客サイトのように、ブリッジ装置を介してVPRNエッジルータに接続された単一のサブネットに制限されますIGMPメッセージの範囲は、単一のサブネットに制限されています。しかしIGMPプロキシ-拘束トポロジにおけるマルチキャストルーティングプロトコルを実行することなく、マルチキャスト転送に関与し得るCPEルータを使用。顧客サイトへのそのインタフェース上のCPEルータは、IGMPのルータ機能を実行し、VPRNエッジルータへのインターフェイス上では、IGMPのホスト機能を実行します。
This is where VPRN edge routers map intra-VPRN multicast traffic onto a native IP multicast distribution mechanism across the backbone. Note that intra-VPRN multicast has the same requirements for isolation from general backbone traffic as intra-VPRN unicast traffic. Currently the only IP tunneling mechanism that has native support for multicast is MPLS. On the other hand, while MPLS supports native transport of IP multicast packets, additional mechanisms would be needed to leverage these mechanisms for the support of intra-VPRN multicast.
VPRNエッジルータがバックボーン上ネイティブIPマルチキャスト分配機構上イントラVPRNマルチキャストトラフィックをマッピングするところです。イントラVPRNマルチキャストがイントラVPRNユニキャストトラフィックなどの一般的なバックボーントラフィックから分離するための同様の要件を有することに留意されたいです。現在、マルチキャストをネイティブでサポートしている唯一のIPトンネリングメカニズムはMPLSです。 MPLSは、IPマルチキャストパケットのネイティブ転送をサポートしながら、一方で、追加のメカニズムは、イントラVPRNマルチキャストのサポートのためにこれらのメカニズムを活用するために必要とされるであろう。
For instance, each VPRN router could prefix multicast group addresses within each VPRN with the VPN-ID of that VPRN and then redistribute these, essentially treating this VPN-ID/intra-VPRN multicast address tuple as a normal multicast address, within the backbone multicast routing protocols, as with the case of unicast reachability, as discussed previously. The MPLS multicast label distribution mechanisms could then be used to set up the appropriate multicast LSPs to interconnect those sites within each VPRN supporting particular multicast group addresses. Note, however, that this would require each of the intermediate LSRs to not only be aware of each intra-VPRN multicast group, but also to have the capability of interpreting these modified advertisements. Alternatively, mechanisms could be defined to map intra-VPRN multicast groups into backbone multicast groups.
例えば、各VPRNルータは、バックボーンマルチキャスト内、そのVPRNのVPN-IDと各VPRN内のマルチキャストグループアドレスをプレフィックスと、これらを再配布、本質的に通常のマルチキャストアドレスとしてこのVPN-ID /イントラVPRNマルチキャストアドレスタプルを処理することができ前述のように、ユニキャスト到達可能の場合と同様に、ルーティングプロトコル。 MPLSマルチキャストラベル分配メカニズムは、特定のマルチキャストグループアドレスを支持する各VPRN内のこれらのサイトを相互接続するために、適切なマルチキャストLSPをセットアップするために使用することができます。ただし、これは各イントラVPRNマルチキャストグループを意識するだけでなく、これらの修飾された広告を解釈する能力を有するように、中間のLSRのそれぞれを必要とすること。代替的に、機構は、バックボーンマルチキャストグループにイントラVPRNマルチキャストグループをマップするように定義することができます。
Other IP tunneling mechanisms do not have native multicast support. It may prove feasible to extend such tunneling mechanisms by allocating IP multicast group addresses to the VPRN as a whole and hence distributing intra-VPRN multicast traffic encapsulated within backbone multicast packets. Edge VPRN routers could filter out unwanted multicast groups. Alternatively, mechanisms could also be defined to allow for allocation of backbone multicast group addresses for particular intra-VPRN multicast groups, and to then utilize these, through backbone multicast protocols, as discussed above, to limit forwarding of intra-VPRN multicast traffic only to those nodes within the group.
他のIPトンネリングメカニズムは、ネイティブマルチキャストをサポートしていません。全体としてVPRNにIPマルチキャストグループアドレスを割り当て、従って、バックボーンマルチキャストパケット内にカプセル化されたイントラVPRNマルチキャストトラフィックを分散させることによって、このようなトンネリングメカニズムを拡張することが可能証明することができます。エッジVPRNルータは、不要なマルチキャストグループをフィルタリングできます。代替的に、機構はまた、特定のイントラVPRNマルチキャストグループのためのバックボーンマルチキャストグループアドレスの割り当てを可能にするために定義することができ、上述したようにのみにイントラVPRNマルチキャストトラフィックの転送を制限するために、バックボーンマルチキャストプロトコルを使用して、これらを利用することグループ内のこれらのノード。
A particular issue with the use of native multicast support is the provision of security for such multicast traffic. Unlike the case of edge replication, which inherits the security characteristics of the underlying tunnel, native multicast mechanisms will need to use some form of secure multicast mechanism. The development of architectures and solutions for secure multicast is an active research area, for example see [42] and [43]. The Secure Multicast Group (SMuG) of the IRTF has been set up to develop prototype solutions, which would then be passed to the IETF IPSec working group for standardization.
ネイティブマルチキャストサポートを使用した特定の問題は、このようなマルチキャストトラフィックのセキュリティを提供することです。基礎となるトンネルのセキュリティ特性を継承エッジ複製の場合とは異なり、ネイティブマルチキャストメカニズムは、セキュアなマルチキャストメカニズムのいくつかのフォームを使用する必要があります。セキュアマルチキャストのためのアーキテクチャおよびソリューションの開発、例えば、活発な研究領域であるが、参照[42]及び[43]。 IRTFのセキュアマルチキャストグループ（きざ）は、その後、標準化のためにIETFのIPSecワーキンググループに渡されるプロトタイプ・ソリューションを開発するように設定されています。
However considerably more development is needed before scalable secure native multicast mechanisms can be generally deployed.
スケーラブルなセキュリティで保護ネイティブマルチキャストメカニズムは、一般的に展開することができる前に、しかしかなり多くの開発が必要とされています。
The various proposals that have been developed to support some form of VPRN functionality can be broadly classified into two groups - those that utilize the router piggybacking approach for distributing VPN membership and/or reachability information ([13],[15]) and those that use the virtual routing approach ([12],[14]). In some cases the mechanisms described rely on the characteristics of a particular infrastructure (e.g. MPLS) rather than just IP.
VPNメンバーシップ及び/又は到達可能性情報を配信するためのアプローチをピギーバックルータ（[13]、[15]）を利用するもの、およびそれらのそれ - VPRNの機能のいくつかのフォームをサポートするために開発されてきた様々な提案は、大きく二つのグループに分類することができます。仮想ルーティング・アプローチを使用する（[12]、[14]）。いくつかのケースで説明されたメカニズムは、特定のインフラ（例えばMPLS）だけではなく、IPの特性に依存しています。
Within the context of the virtual routing approach it may be useful to develop a membership distribution protocol based on a directory or MIB. When combined with the protocol extensions for IP tunneling protocols outlined in section 3.2, this would then provide the basis for a complete set of protocols and mechanisms that support interoperable VPRNs that span multiple administrations over an IP backbone. Note that the other major pieces of functionality needed - the learning and distribution of customer reachability information, can be performed by instances of standard routing protocols, without the need for any protocol extensions.
仮想ルーティングアプローチの文脈内では、ディレクトリまたはMIBに基づいて、会員配布プロトコルを開発することが有用であり得ます。セクション3.2に概説IPトンネリングプロトコルのためのプロトコル拡張と組み合わされた場合、これは、IPバックボーン上に複数回投与にまたがる相互運用VPRNsをサポートするプロトコルおよびメカニズムの完全なセットのための基礎を提供するであろう。学習と顧客の到達可能性情報の配布、任意のプロトコルの拡張を必要とせずに、標準のルーティングプロトコルのインスタンスで実行することができます - 必要な機能の他の主要な部分があることに注意してください。
Also for the constrained case of a full mesh topology, the usefulness of developing a link reachability protocol could be examined, however the limitations and scalability issues associated with this topology may not make it worthwhile to develop something specific for this case, as standard routing will just work.
また、フルメッシュトポロジーの制約ケースのために、リンクの到達性プロトコルを開発するの有用性を検討することができ、しかし、このトポロジに関連付けられた制限とスケーラビリティの問題は、標準のルーティングとなります、この場合の具体的な何かを開発することは価値がある加えることはできませんちょうど仕事。
Extending routing protocols to allow a VPN-ID to carried in routing update packets could also be examined, but is not necessary if VPN specific tunnels are used.
アップデートパケットをルーティングで運ばにVPN-IDを可能にするルーティングプロトコルを拡張することも検討したが、VPN固有のトンネルが使用される場合に必要ではないことができます。
A Virtual Private Dial Network (VPDN) allows for a remote user to connect on demand through an ad hoc tunnel into another site. The user is connected to a public IP network via a dial-up PSTN or ISDN link, and user packets are tunneled across the public network to the desired site, giving the impression to the user of being 'directly' connected into that site. A key characteristic of such ad hoc connections is the need for user authentication as a prime requirement, since anyone could potentially attempt to gain access to such a site using a switched dial network.
仮想プライベートダイヤルネットワーク（VPDN）は、別のサイトへのアドホックトンネルを通してオンデマンドで接続するリモートユーザーが可能になります。ユーザーは、ダイヤルアップPSTNまたはISDN回線を介して公衆IP網に接続されており、ユーザパケットを「直接」そのサイトに接続されたユーザーに印象を与え、所望の部位に、パブリックネットワーク経由でトンネリングされます。誰もが潜在的に切り替えダイヤルネットワークを使用して、そのようなサイトへのアクセスを試み可能性があるので、このようなアドホック接続の重要な特徴は、プライム要件として、ユーザー認証が必要です。
Today many corporate networks allow access to remote users through dial connections made through the PSTN, with users setting up PPP connections across an access network to a network access server, at which point the PPP sessions are authenticated using AAA systems running such standard protocols as Radius [44]. Given the pervasive deployment of such systems, any VPDN system must in practice allow for the near transparent re-use of such existing systems.
PPPセッションを、その時点でのネットワークアクセスサーバーへのアクセスネットワークを介してPPP接続を設定するユーザーは、Radiusのような標準プロトコルを実行しているAAAシステムを使用して認証されて今日、多くの企業ネットワークは、PSTNを介して行わダイヤル接続を介してリモートユーザへのアクセスを許可します[44]。このようなシステムの普及展開を考えると、任意のVPDNシステムは、実際には、このような既存のシステムの近くに透明再利用を可能にしなければなりません。
The IETF have developed the Layer 2 Tunneling Protocol (L2TP) [8] which allows for the extension of of user PPP sessions from an L2TP Access Concentrator (LAC) to a remote L2TP Network Server (LNS). The L2TP protocol itself was based on two earlier protocols, the Layer 2 Forwarding protocol (L2F) [45], and the Point-to-Point Tunneling Protocol (PPTP) [46], and this is reflected in the two quite different scenarios for which L2TP can be used - compulsory tunneling and voluntary tunneling, discussed further below in sections 6.2 and 6.3.
IETFは、[8] L2TPアクセス・コンセントレータ（LAC）から遠隔L2TPネットワークサーバー（LNS）へのユーザPPPセッションの拡張を可能にするレイヤ2トンネリングプロトコル（L2TP）を開発しました。 L2TPの自体は、2つの以前のプロトコルに基づいたプロトコル、レイヤ2転送プロトコル（L2F）[45]、およびポイントツーポイントトンネリングプロトコル（PPTP）[46]、そしてこれはのための2つの非常に異なるシナリオに反映されています、強制トンネリングおよび自発的トンネリングをセクション6.2および6.3でさらに後述 - L2TPを使用することができます。
This document focuses on the use of L2TP over an IP network (using UDP), but L2TP may also be run directly over other protocols such as ATM or Frame Relay. Issues specifically related to running L2TP over non-IP networks, such as how to secure such tunnels, are not addressed here.
この文書は、（UDPを使用して）IPネットワーク上でL2TPを使用することに焦点を当てているが、L2TPはまた、ATMやフレームリレーなどの他のプロトコル上で直接実行することができます。このようなトンネルを保護する方法として、特に非IPネットワーク上でL2TPの実行に関連する問題は、ここで扱われていません。
This section looks at the characteristics of the L2TP tunneling protocol using the categories outlined in section 3.0.
このセクションは、セクション3.0に概説カテゴリを使用して、L2TPトンネリングプロトコルの特性を調べ。
L2TP has inherent support for the multiplexing of multiple calls from different users over a single link. Between the same two IP endpoints, there can be multiple L2TP tunnels, as identified by a tunnel-id, and multiple sessions within a tunnel, as identified by a session-id.
L2TPは1つのリンクを介して異なるユーザからの複数の呼び出しの多重化のための固有のサポートを持っています。同じ2つのIPエンドポイント間で、セッションIDによって識別されるように、トンネル内のトンネルIDによって識別されるように、複数のL2TPトンネルと、複数のセッションが存在し得ます。
This is supported via the inbuilt control connection protocol, allowing both tunnels and sessions to be established dynamically.
これは、両方のトンネルとセッションを動的に確立することを可能にする、内蔵制御接続プロトコルを介して支持されています。
By allowing for the transparent extension of PPP from the user, through the LAC to the LNS, L2TP allows for the use of whatever security mechanisms, with respect to both connection set up, and data transfer, may be used with normal PPP connections. However this does not provide security for the L2TP control protocol itself. In this case L2TP could be further secured by running it in combination with IPSec through IP backbones [47], [48], or related mechanisms on non-IP backbones [49].
LNSにLACを介して、ユーザからのPPPの透明な拡張を可能にすることによって、L2TPを設定両方の接続に対して、どのようなセキュリティメカニズムの使用を可能にし、データ転送、通常のPPP接続で使用されてもよいです。しかし、これは、L2TP制御プロトコル自体のセキュリティを提供しません。この場合、L2TPは、非IPバックボーン[49]にIPバックボーン[47]、[48]、または関連するメカニズムを介してのIPSecと組み合わせて実行することによって固定することができます。
The interaction of L2TP with AAA systems for user authentication and authorization is a function of the specific means by which L2TP is used, and the nature of the devices supporting the LAC and the LNS. These issues are discussed in depth in [50].
ユーザ認証および許可のためのAAAシステムとL2TPの相互作用は、L2TPを使用することによって、特定の手段、およびLACとLNSをサポートするデバイスの性質の関数です。これらの問題は、[50]に詳しく説明されています。
The means by which the host determines the correct LAC to connect to, and the means by which the LAC determines which users to further tunnel, and the LNS parameters associated with each user, are outside the scope of the operation of a VPDN, but may be addressed, for instance, by evolving Internet roaming specifications [51].
ホストが接続するための正しいLACを決定する手段、及びLACはさらにトンネルにどのユーザを決定する手段と、各ユーザに関連付けられたLNSパラメータは、VPDNの動作の範囲外であるかもしれないが、進化インターネットローミング仕様[51]により、例えば、対処されます。
L2TP transports PPP packets (and only PPP packets) and thus can be used to carry multiprotocol traffic since PPP itself is multiprotocol.
L2TPは、PPPパケット（のみPPPパケット）を搬送するので、PPP自体がマルチであるので、マルチプロトコルトラフィックを運ぶために使用することができます。
L2TP supports sequenced delivery of packets. This is a capability that can be negotiated at session establishment, and that can be turned on and off by an LNS during a session. The sequence number field in L2TP can also be used to provide an indication of dropped packets, which is needed by various PPP compression algorithms to operate correctly. If no compression is in use, and the LNS determines that the protocols in use (as evidenced by the PPP NCP negotiations) can deal with out of sequence packets (e.g. IP), then it may disable the use of sequencing.
L2TPは、パケットのシーケンスされた配信をサポートしています。これは、セッション確立時に交渉することができる機能であり、それは、セッション中にLNSによってオン・オフすることができます。 L2TPにおけるシーケンス番号フィールドは、また、正しく動作するために、様々なPPP圧縮アルゴリズムによって必要とされるドロップされたパケットの表示を提供するために使用することができます。非圧縮が使用されず、LNSは（PPP NCPネゴシエーションによって証明されるように）、使用中のプロトコルは、シーケンスパケットのうち（例えば、IP）を扱うことができると判断した場合、それは、配列決定の使用を無効にすることができます。
A keepalive protocol is used by L2TP in order to allow it to distinguish between a tunnel outage and prolonged periods of tunnel inactivity.
キープアライブプロトコルは、それがトンネルの停止及びトンネル非アクティブの長期間を区別することを可能にするためにL2TPで使用されます。
L2TP itself has no inbuilt support for a segmentation and reassembly capability, but when run over UDP/IP IP fragmentation will take place if necessary. Note that a LAC or LNS may adjust the Maximum Receive Unit (MRU) negotiated via PPP in order to preclude fragmentation, if it has knowledge of the MTU used on the path between LAC and LNS. To this end, there is a proposal to allow the use of MTU discovery for cases where the L2TP tunnel transports IP frames [52].
L2TP自体は、セグメンテーションと再構築機能のための作り付けのサポートはありませんが、UDP / IP IPフラグメンテーション上で実行したときに、必要に応じて行われます。 LACまたはLNSが最大ユニット（MRU）がMTUの知識はLACとLNSとの間の経路上で使用した場合、断片化を排除するために、PPPを介してネゴシエートを受信調整してもよいことに留意されたいです。この目的のために、L2TPトンネルがIPフレーム[52]を搬送する場合のMTU発見の使用を可能にする提案があります。
L2TP as used over IP networks runs over UDP and must be used to carry PPP traffic. This results in a significant amount of overhead, both in the data plane with UDP, L2TP and PPP headers, and also in the control plane, with the L2TP and PPP control protocols. This is discussed further in section 6.3
IPネットワーク上で使用されるようにL2TPはUDP上で動作し、PPPトラフィックを運ぶために使用する必要があります。これは、L2TPおよびPPP制御プロトコルを用いて、制御プレーンにおいても、UDP、L2TP及びPPPヘッダ、およびとデータプレーンの両方で、オーバーヘッドのかなりの量になります。これはセクション6.3で詳しく説明されています
L2TP supports flow and congestion control mechanisms for the control protocol, but not for data traffic. See section 3.1.9 for more details.
L2TPは、制御プロトコルのためではなく、データトラフィックのフローと輻輳制御メカニズムをサポートしています。詳細については、セクション3.1.9を参照してください。
An L2TP header contains a 1-bit priority field, which can be set for packets that may need preferential treatment (e.g. keepalives) during local queuing and transmission. Also by transparently extending PPP, L2TP has inherent support for such PPP mechanisms as multi-link PPP [53] and its associated control protocols [54], which allow for bandwidth on demand to meet user requirements.
L2TPヘッダは、ローカルキューイングおよび送信中に優遇措置を必要とするかもしれないパケット（例えば、キープアライブ）を設定することができ、1ビットの優先度フィールドを含んでいます。また、透過的にPPPを拡張することによって、L2TPは、マルチリンクPPP [53]とユーザ要件を満たすようにオンデマンド帯域幅を可能にするその関連する制御プロトコル[54]、このようなPPP機構の固有のサポートを有しています。
In addition L2TP calls can be mapped into whatever underlying traffic management mechanisms may exist in the network, and there are proposals to allow for requests through L2TP signalling for specific differentiated services behaviors [55].
またL2TPコールがどの基礎となるトラフィック管理メカニズムにマッピングすることができるネットワーク内に存在し、特定の差別化サービスの動作のためのシグナリングL2TPを介して要求を可能にするための提案[55]が存在することができます。
Since L2TP is designed to transparently extend PPP, it does not attempt to supplant the normal address assignment mechanisms associated with PPP. Hence, in general terms the host initiating the PPP session will be assigned an address by the LNS using PPP procedures. This addressing may have no relation to the addressing used for communication between the LAC and LNS. The LNS will also need to support whatever forwarding mechanisms are needed to route traffic to and from the remote host.
L2TPは透過PPPを拡張するために設計されているので、PPPに関連付けられた通常のアドレス割り当てメカニズムに取って代わるしようとしません。したがって、一般的にPPPセッションを開始するホストは、PPPの手順を使用してLNSによってアドレスが割り当てられます。このLACとLNSとの間の通信に使用されるアドレス指定とは関係を持たなくてもよいアドレッシング。 LNSはまた、メカニズムはにし、リモートホストからのトラフィックをルーティングするために必要なものは何でも転送をサポートする必要があります。
Compulsory tunneling refers to the scenario in which a network node - a dial or network access server, for instance - acting as a LAC, extends a PPP session across a backbone using L2TP to a remote LNS, as illustrated below. This operation is transparent to the user initiating the PPP session to the LAC. This allows for the decoupling of the location and/or ownership of the modem pools used to terminate dial calls, from the site to which users are provided access. Support for this scenario was the original intent of the L2F specification, upon which the L2TP specification was based.
例えば、ダイヤルまたはネットワークアクセスサーバ、 - - 強制トンネリングは、ネットワークノードシナリオを指すLACとして作用する以下に示すように、リモートLNSにL2TPを使用してバックボーンを横切ってPPPセッションを拡張します。この操作は、LACにPPPセッションを開始するユーザーに対して透過的です。これは、ユーザがアクセスを提供されるためにサイトから、ダイヤル呼び出しを終了するために使用されるモデムプールの位置及び/又は所有権の分離を可能にします。このシナリオのサポートは、L2TP仕様がベースた時L2F仕様の当初の目的でした。
There are a number of different deployment scenarios possible. One example, shown in the diagram below, is where a subscriber host dials into a NAS acting as a LAC, and is tunneled across an IP network (e.g. the Internet) to a gateway acting as an LNS. The gateway provides access to a corporate network, and could either be a device in the corporate network itself, or could be an ISP edge router, in the case where a customer has outsourced the maintenance of LNS functionality to an ISP. Another scenario is where an ISP uses L2TP to provide a subscriber with access to the Internet. The subscriber host dials into a NAS acting as a LAC, and is tunneled across an access network to an ISP edge router acting as an LNS. This ISP edge router then feeds the subscriber traffic into the Internet. Yet other scenarios are where an ISP uses L2TP to provide a subscriber with access to a VPRN, or with concurrent access to both a VPRN and the Internet.
可能な異なる展開シナリオの数があります。以下の図に示す一例は、NASへの加入者ホストがダイヤルLACとして機能する場合であり、LNSとして動作するゲートウェイに（例えば、インターネット）は、IPネットワークを介してトンネリングされます。ゲートウェイは、企業ネットワークへのアクセスを提供し、企業ネットワーク自体内のデバイスとすることができるか、顧客がISPにLNS機能のメンテナンスを外部委託している場合には、ISPエッジルータとすることができます。 ISPがインターネットへのアクセスを加入者に提供するために、L2TPを使用している別のシナリオです。 NASへの加入者ホストダイヤルは、LACとして作用し、LNSとして動作ISPエッジルータにアクセスネットワークを介してトンネリングされます。このISPエッジルータは、インターネットに加入者トラフィックを送り込みます。 ISPがVPRNにアクセスできる、またはVPRNとインターネットの両方への同時アクセスを加入者に提供するために、L2TPを使用しているけれども、他のシナリオがあります。
A VPDN, whether using compulsory or voluntary tunneling, can be viewed as just another type of access method for subscriber traffic, and as such can be used to provide connectivity to different types of networks, e.g. a corporate network, the Internet, or a VPRN. The last scenario is also an example of how a VPN service as provided to a customer may be implemented using a combination of different types of VPN.
VPDNは、強制的または自発的トンネリングを使用するかどうか、加入者トラフィックのアクセス方法のちょうど別のタイプと見なすことができ、そのようなものとして、例えば、異なる種類のネットワークへの接続を提供するために使用することができます企業ネットワーク、インターネット、またはVPRN。最後のシナリオはまた、顧客に提供されるようなVPNサービスは、VPNの異なるタイプの組み合わせを使用して実施することができる方法の例です。
10.0.0.1
+----+
|Host|----- LAC ------------- LNS 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
<------- L2TP Tunnel ------->
<--------------------- PPP Session ------->
Figure 6.1: Compulsory Tunneling Example
図6.1：強制的トンネリングの例
Compulsory tunneling was originally intended for deployment on network access servers supporting wholesale dial services, allowing for remote dial access through common facilities to an enterprise site, while precluding the need for the enterprise to deploy its own dial servers. Another example of this is where an ISP outsources its own dial connectivity to an access network provider (such as a Local Exchange Carrier (LEC) in the USA) removing the need for an ISP to maintain its own dial servers and allowing the LEC to serve multiple ISPs. More recently, compulsory tunneling mechanisms have also been proposed for evolving Digital Subscriber Line (DSL) services [56], [57], which also seek to leverage the existing AAA infrastructure.
強制的トンネリングはもともと独自のダイヤルサーバーを展開する企業のための必要性を排除しながら、企業のサイトに共通の機能を介したリモートダイヤルアクセスを可能に、ホールセールダイヤルサービスをサポートするネットワークアクセスサーバー上の展開のために意図されていました。 ISPは独自のダイヤルサーバを維持するために、ISPの必要性を除去して、LECがサービスを提供することができます（たとえば、米国の地域通信事業（LEC）のような）アクセスネットワークプロバイダに、独自のダイヤル接続を委託ここの別の例は、複数のISP。さらに最近では、強制的なトンネリングメカニズムはまた、既存のAAAインフラストラクチャを活用しようとデジタル加入者線（DSL）サービス[56]、[57]、進化するために提案されています。
Call routing for compulsory tunnels requires that some aspect of the initial PPP call set up can be used to allow the LAC to determine the identity of the LNS. As noted in [50], these aspects can include the user identity, as determined through some aspect of the access network, including calling party number, or some attribute of the called party, such as the Fully Qualified Domain Name (FQDN) of the identity claimed during PPP authentication.
強制的なトンネルのルーティングを呼び出すと、設定した初期PPPコールのいくつかの側面は、LACはLNSの同一性を決定できるようにするために使用できることが必要です。で述べたように、このような完全修飾ドメイン名（FQDN）のような発呼者番号、被呼者のいくつかの属性を含む、アクセスネットワークのいくつかの側面を介して決定されるように[50]、これらの態様は、ユーザIDを含むことができアイデンティティは、PPP認証の間に主張しました。
It is also possible to chain two L2TP tunnels together, whereby a LAC initiates a tunnel to an intermediate relay device, which acts as an LNS to this first LAC, and acts as a LAC to the final LNS. This may be needed in some cases due to administrative, organizational or regulatory issues pertaining to the split between access network provider, IP backbone provider and enterprise customer.
これは、LACは、この最初のLACにLNSとして動作する中間中継装置へのトンネルを開始することにより、2つのL2TPトンネル一緒にチェーンすることも可能であり、最終的なLNSにLACとして機能します。これは、アクセスネットワークプロバイダ、IPバックボーンプロバイダーおよび企業の顧客との間の分割に関する、行政組織や規制の問題にいくつかのケースで必要になる場合があります。
Voluntary tunneling refers to the case where an individual host connects to a remote site using a tunnel originating on the host, with no involvement from intermediate network nodes, as illustrated below. The PPTP specification, parts of which have been incorporated into L2TP, was based upon a voluntary tunneling model.
自発的トンネリングは、以下に示すように、個々のホストが、中間ネットワークノードからのNOの関与と、ホスト上の発信トンネルを使用してリモートサイトに接続する場合を指します。 PPTP仕様、L2TPに組み込まれているの一部は、自発的トンネリングモデルに基づいていました。
As with compulsory tunneling there are different deployment scenarios possible. The diagram below shows a subscriber host accessing a corporate network with either L2TP or IPSec being used as the voluntary tunneling mechanism. Another scenario is where voluntary tunneling is used to provide a subscriber with access to a VPRN.
強制的トンネリングと同様に可能なさまざまな展開シナリオがあります。以下の図は、自発的トンネリングメカニズムとして使用されているL2TPまたはIPSecのいずれかと企業ネットワークにアクセスする加入者のホストを示しています。自発的トンネリングがVPRNへのアクセスを加入者に提供するために使用される別のシナリオです。
The L2TP specification has support for voluntary tunneling, insofar as the LAC can be located on a host, not only on a network node. Note that such a host has two IP addresses - one for the LAC-LNS IP tunnel, and another, typically allocated via PPP, for the network to which the host is connecting. The benefits of using L2TP for voluntary tunneling are that the existing authentication and address assignment mechanisms used by PPP can be reused without modification. For example an LNS could also include a Radius client, and communicate with a Radius server to authenticate a PPP PAP or CHAP exchange, and to retrieve configuration information for the host such as its IP address and a list of DNS servers to use. This information can then be passed to the host via the PPP IPCP protocol.
L2TP仕様は、LACは、ネットワーク・ノードだけでなく、ホスト上に配置することができる限り、自発的トンネリングをサポートしています。ホストが接続されているネットワークでは、LAC-LNS IPトンネルのための1つ、別の、典型的にはPPPを介して割り当てられた - そのようなホストは、2つのIPアドレスを有することに留意されたいです。自発的トンネリングにL2TPを使用する利点は、PPPが使用する既存の認証とアドレス割り当てメカニズムをそのまま再利用できるということです。例えば、LNSは、RADIUSクライアントを含むことができ、およびPPPのPAPまたはCHAPの交換を認証するために、そのようなそのIPアドレス、使用するDNSサーバのリストとしてホストの構成情報を取得するために、Radiusサーバと通信します。この情報はその後、PPP IPCPプロトコルを介してホストに渡すことができます。
10.0.0.1
+----+
|Host|----- ------------- 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
<-------------- L2TP Tunnel -------------->
with LAC on host
<-------------- PPP Session --------------> LNS on gateway
or
または
<-------------- IPSEC Tunnel -------------->
Figure 6.2: Voluntary Tunneling Example
図6.2：自発的トンネリングの例
The above procedure is not without its costs, however. There is considerable overhead with such a protocol stack, particularly when IPSec is also needed for security purposes, and given that the host may be connected via a low-bandwidth dial up link. The overhead consists of both extra headers in the data plane and extra control protocols needed in the control plane. Using L2TP for voluntary tunneling, secured with IPSec, means a web application, for example, would run over the following stack
上記の手順は、しかし、そのコストがないわけではありません。 IPsecは、セキュリティ目的のために必要であり、ホストが低帯域幅ダイヤルアップリンクを介して接続されてもよいことを考慮され、特に、このようなプロトコルスタックとかなりのオーバーヘッドがあります。オーバーヘッドは、データプレーン内の余分なヘッダと制御プレーンに必要な余分な制御プロトコルの両方からなります。 IPSecので確保し、自発的トンネリングにL2TPを使用して、Webアプリケーションを意味し、例えば、以下のスタック上で実行します
HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC
HTTP / TCP / IP / PPP / L2TP / UDP / ESP / IP / PPP / AHDLC
It is proposed in [58] that IPSec alone be used for voluntary tunnels reducing overhead, using the following stack.
単独のIPSecは、以下のスタックを使用して、オーバーヘッドを低減させる自発的トンネルに使用されることが[58]で提案されています。
HTTP/TCP/IP/ESP/IP/PPP/AHDLC
HTTP / TCP / IP / ESP / IP / PPP / AHDLC
In this case IPSec is used in tunnel mode, with the tunnel terminating either on an IPSec edge device at the enterprise site, or on the provider edge router connected to the enterprise site. There are two possibilities for the IP addressing of the host. Two IP addresses could be used, in a similar manner to the L2TP case. Alternatively the host can use a single public IP address as the source IP address in both inner and outer IP headers, with the gateway performing Network Address Translation (NAT) before forwarding the traffic to the enterprise network. To other hosts in the enterprise network the host appears to have an 'internal' IP address. Using NAT has some limitations and restrictions, also pointed out in [58].
この場合、IPSecは、企業サイトで、または企業サイトに接続されたプロバイダエッジルータ上のIPSecエッジデバイスのいずれかを終了トンネルと、トンネルモードで使用されています。ホストのIPアドレス指定のための2つの可能性があります。 2つのIPアドレスは、L2TPの場合と同様に、使用することができます。あるいはホストは、ゲートウェイが企業ネットワークにトラフィックを転送する前に、ネットワークアドレス変換（NAT）を実行して、内側と外側の両方のIPヘッダの送信元IPアドレスとして単一のパブリックIPアドレスを使用することができます。企業ネットワーク内の他のホストへのホストは、「内部のIPアドレスを持っているように見えます。 NATは、いくつかの制限と制限があります使用して、また、[58]で指摘。
Another area of potential problems with PPP is due to the fact that the characteristics of a link layer implemented via an L2TP tunnel over an IP backbone are quite different to a link layer run over a serial line, as discussed in the L2TP specification itself. For example, poorly chosen PPP parameters may lead to frequent resets and timeouts, particularly if compression is in use. This is because an L2TP tunnel may misorder packets, and may silently drop packets, neither of which normally occurs on serial lines. The general packet loss rate could also be significantly higher due to network congestion. Using the sequence number field in an L2TP header addresses the misordering issue, and for cases where the LAC and LNS are coincident with the PPP endpoints, as in voluntary tunneling, the sequence number field can also be used to detect a dropped packet, and to pass a suitable indication to any compression entity in use, which typically requires such knowledge in order to keep the compression histories in synchronization at both ends. (In fact this is more of an issue with compulsory tunneling since the LAC may have to deliberately issue a corrupted frame to the PPP host, to give an indication of packet loss, and some hardware may not allow this).
PPPの潜在的な問題の別の領域は、L2TP仕様自体で説明したようにIPバックボーン上L2TPトンネルを介して実装されたリンク層の特性は、シリアルライン上リンク層実行するために全く異なっているという事実によるものです。例えば、乏しい選択PPPパラメータは、圧縮が使用されている場合は特に、頻繁にリセットされ、タイムアウトにつながる可能性があります。 L2TPトンネルが正常にシリアルライン上で発生どちらも、パケットをmisorderよく、静かにパケットをドロップする可能性があるためです。一般的なパケット損失率は、ネットワークの輻輳が原因有意に高いことができます。する誤った順序の問題を解決し、そしてLACとLNSは、PPPエンドポイントと一致している場合について、自発的トンネリングのように、シーケンス番号フィールドは、また、ドロップされたパケットを検出するために使用することができるL2TPヘッダ内のシーケンス番号フィールドを使用して、及び典型的には、両端に同期して圧縮履歴を維持するために、そのような知識を必要とする使用中の圧縮エンティティに適切な指示を渡します。 （LACが意図的パケット損失の指標を与えるために、PPPホストに破損したフレームを発行する必要がある可能性があり、そしていくつかのハードウェアがこれを許可しないかもしれないので、実際には、これは強制的なトンネリングの問題の多いです）。
If IPSec is used for voluntary tunneling, the functions of user authentication and host configuration, achieved by means of PPP when using L2TP, still need to be carried out. A distinction needs to be drawn here between machine authentication and user authentication. ' Two factor' authentication is carried out on the basis of both something the user has, such as a machine or smartcard with a digital certificate, and something the user knows, such as a password. (Another example is getting money from an bank ATM machine - you need a card and a PIN number). Many of the existing legacy schemes currently in use to perform user authentication are asymmetric in nature, and are not supported by IKE. For remote access the most common existing user authentication mechanism is to use PPP between the user and access server, and Radius between the access server and authentication server. The authentication exchanges that occur in this case, e.g. a PAP or CHAP exchange, are asymmetric. Also CHAP supports the ability for the network to reauthenticate the user at any time after the initial session has been established, to ensure that the current user is the same person that initiated the session.
IPSecは自発的トンネリングのために使用される場合、L2TPを使用する場合、PPPによって達成ユーザ認証とホスト構成の機能は、まだ行われる必要があります。区別はマシン認証とユーザー認証の間、ここで描画する必要があります。 「2つのファクタ」認証は、パスワードなどのデジタル証明書を持つ機械やスマートカードなど、ユーザーが持っているものと、ユーザーが知っている何か、その両方に基づいて行われます。 （別の例は、銀行のATM機からお金を得ている - あなたはカードとPIN番号が必要）。ユーザ認証を行うために、現在使用中の既存のレガシースキームの多くは、自然の中で非対称であり、およびIKEによってサポートされていません。リモートアクセスのための最も一般的な既存のユーザ認証メカニズムは、アクセスサーバと認証サーバ間のユーザとアクセスサーバ、およびRadiusの間でPPPを使用することです。この場合、例えば起こる認証交換PAPまたはCHAP交換は、非対称です。また、CHAPは、現在のユーザーがセッションを開始し、同一人物であることを保証するために、最初のセッションが確立された後の任意の時点でユーザーを再認証するためのネットワークのための機能をサポートしています。
While IKE provides strong support for machine authentication, it has only limited support for any form of user authentication and has no support for asymmetric user authentication. While a user password can be used to derive a key used as a preshared key, this cannot be used with IKE Main Mode in a remote access environment, as the user will not have a fixed IP address, and while Aggressive Mode can be used instead, this affords no identity protection. To this end there have been a number of proposals to allow for support of legacy asymmetric user level authentication schemes with IPSec. [59] defines a new IKE message exchange - the transaction exchange - which allows for both Request/Reply and Set/Acknowledge message sequences, and it also defines attributes that can be used for client IP stack configuration. [60] and [61] describe mechanisms that use the transaction message exchange, or a series of such exchanges, carried out between the IKE Phase 1 and Phase 2 exchanges, to perform user authentication. A different approach, that does not extend the IKE protocol itself, is described in [62]. With this approach a user establishes a Phase 1 SA with a security gateway and then sets up a Phase 2 SA to the gateway, over which an existing authentication protocol is run. The gateway acts as a proxy and relays the protocol messages to an authentication server.
IKEは、マシン認証のための強力なサポートを提供していますが、それはユーザ認証のいずれかの形式のためにのみ限定的にサポートしており、非対称のユーザ認証をサポートしていません。ユーザーのパスワードが事前共有キーとして使用するキーを導出するために使用することができますが、ユーザーが固定IPアドレスを持っていないので、これは、リモートアクセス環境でIKEメインモードで使用することはできません、とアグレッシブモードを代わりに使用することができながら、 、これはアイデンティティ保護を与えるありません。このためのIPSecとレガシー非対称ユーザーレベルの認証方式のサポートを可能にする多数の提案がなされています。 [59]新しいIKEメッセージ交換を定義 - 取引交換 - 要求/応答およびセット/メッセージシーケンスを肯定応答の両方を可能にし、それはまた、クライアントのIPスタック構成のために使用することができる属性を定義します。 [60]及び[61]は、ユーザ認証を実行するために、IKEフェーズ1とフェーズ2の交換との間で行われる取引メッセージ交換、またはそのような交換のシリーズを使用するメカニズムを記述する。別のアプローチは、IKEプロトコル自体を拡張しない、[62]に記載されています。このアプローチでは、ユーザは、セキュリティゲートウェイとのフェーズ1 SAを確立した後、既存の認証プロトコルが実行される上ゲートウェイにフェーズ2 SAを設定します。ゲートウェイは、プロキシとして機能し、認証サーバへのプロトコルメッセージを中継します。
In addition there have also been proposals to allow the remote host to be configured with an IP address and other configuration information over IPSec. For example [63] describes a method whereby a remote host first establishes a Phase 1 SA with a security gateway and then sets up a Phase 2 SA to the gateway, over which the DHCP protocol is run. The gateway acts as a proxy and relays the protocol messages to the DHCP server. Again, like [62], this proposal does not involve extensions to the IKE protocol itself.
また、リモートホストがIPSec上のIPアドレスやその他の構成情報を設定できるようにする提案がなされています。例えば[63]リモートホストが最初のセキュリティゲートウェイとのフェーズ1 SAを確立した後、DHCPプロトコルが実行され、その上ゲートウェイにフェーズ2 SAを設定することにより、方法が記載されています。ゲートウェイは、プロキシとして動作し、DHCPサーバへのプロトコルメッセージを中継します。ここでも、[62]のように、この提案は、IKEプロトコル自体への拡張を必要としません。
Another aspect of PPP functionality that may need to supported is multiprotocol operation, as there may be a need to carry network layer protocols other than IP, and even to carry link layer protocols (e.g. ethernet) as would be needed to support bridging over IPSec. This is discussed in section 3.1.4.
そこにIP以外のネットワーク層プロトコルを運ぶために必要であり得る、およびIPSecにわたってブリッジングをサポートするために必要とされるようであっても、リンク層プロトコル（例えば、イーサネット）を搬送するように支持する必要があるかもしれないPPP機能の別の態様は、マルチプロトコル動作です。これは、セクション3.1.4で説明されています。
The methods of supporting legacy user authentication and host configuration capabilities in a remote access environment are currently being discussed in the IPSec working group.
リモートアクセス環境でレガシーユーザー認証とホストの設定機能をサポートする方法は、現在のIPSecワーキンググループで議論されています。
The current PPP based dial model assumes a host directly connected to a connection oriented dial access network. Recent work on new access technologies such as DSL have attempted to replicate this model [57], so as to allow for the re-use of existing AAA systems. The proliferation of personal computers, printers and other network appliances in homes and small businesses, and the ever lowering costs of networks, however, are increasingly challenging the directly connected host model. Increasingly, most hosts will access the Internet through small, typically Ethernet, local area networks.
現在のPPPベースのダイヤルモデルは直接接続指向ダイヤルアクセスネットワークに接続されたホストを想定しています。既存のAAAシステムの再使用を可能にするようなDSLなどの新しいアクセス技術の最近の研究では、このモデル[57]を複製しようとしてきました。家庭や中小企業では、パソコン、プリンタ、およびその他のネットワーク機器の普及、およびネットワークの今まで低下コストは、しかし、ますます直接接続されたホストのモデルに挑戦しています。ますます、ほとんどのホストは、小さな、通常、イーサネット、ローカルエリアネットワークを介してインターネットにアクセスします。
There is hence interest in means of accommodating the existing AAA infrastructure within service providers, whilst also supporting multiple networked hosts at each customer site. The principal complication with this scenario is the need to support the login dialogue, through which the appropriate AAA information is exchanged. A number of proposals have been made to address this scenario:
また、各顧客サイトでのネットワーク接続された複数のホストをサポートしながら、サービス・プロバイダ内の既存のAAAインフラストラクチャを収容する手段への関心が故にあります。このシナリオとの主な合併症は、適切なAAA情報が交換されるを通してログイン対話をサポートする必要があることです。提案の数は、このシナリオに対処するために行われています。
A number of proposals (e.g. [56]) have been made to extend L2TP over Ethernet so that PPP sessions can run from networked hosts out to the network, in much the same manner as a directly attached host.
提案の数（例えば[56]）PPPセッションがネットワークに出ネットワークホストから実行できるように直接接続されたホストとほとんど同じ方法で、イーサネット上でL2TPを拡張するためになされています。
There is also a specification for mapping PPP directly onto Ethernet (PPPOE) [64] which uses a broadcast mechanism to allow hosts to find appropriate access servers with which to connect. Such servers could then further tunnel, if needed, the PPP sessions using L2TP or a similar mechanism.
ホストが接続すると、適切なアクセス・サーバを見つけることができるようにブロードキャスト・メカニズムを使用して、イーサネット上に直接PPPをマッピングするための仕様（PPPOE）[64]もあります。そのようなサーバの可能性を更にトンネル、必要に応じて、L2TPまたは同様の機構を使用して、PPPセッション。
The IPSec based voluntary tunneling mechanisms discussed above can be used either with networked or directly connected hosts.
上述のIPSecベースの自発的トンネリングメカニズムは、ネットワークまたは直接接続されたホストとのいずれかを使用することができます。
Note that all of these methods require additional host software to be used, which implements either LAC, PPPOE client or IPSec client functionality.
これらのメソッドのすべてがLAC、PPPoEクライアントまたはIPSecクライアント機能のいずれかを実装し、使用する追加のホストソフトウェアを、必要とすることに注意してください。
The L2TP specification has been finalized and will be widely used for compulsory tunneling. As discussed in section 3.2, defining specific modes of operation for IPSec when used to secure L2TP would be beneficial.
L2TP仕様は確定されており、広く強制的トンネリングに使用されます。セクション3.2で議論したように、L2TPを固定するために使用される場合IPSecのための動作の特定のモードを定義することは有益であろう。
Also, for voluntary tunneling using IPSec, completing the work needed to provide support for the following areas would be useful
また、IPSecを使用して自発的トンネリングのために、以下の分野のサポートを提供するために必要な作業を完了することは有用であろう
- asymmetric / legacy user authentication (6.3)
- 非対称/レガシーユーザ認証（6.3）
- host address assignment and configuration (6.3)
- ホストアドレスの割り当ておよび構成（6.3）
along with any other issues specifically related to the support of remote hosts. Currently as there are many different non-interoperable proprietary solutions in this area.
特に、リモートホストのサポートに関連する他の問題と一緒に。現在、このエリアには多くの異なる非相互運用性の独自のソリューションがあるよう。
A Virtual Private LAN Segment (VPLS) is the emulation of a LAN segment using Internet facilities. A VPLS can be used to provide what is sometimes known also as a Transparent LAN Service (TLS), which can be used to interconnect multiple stub CPE nodes, either bridges or routers, in a protocol transparent manner. A VPLS emulates a LAN segment over IP, in the same way as protocols such as LANE emulate a LAN segment over ATM. The primary benefits of a VPLS are complete protocol transparency, which may be important both for multiprotocol transport and for regulatory reasons in particular service provider contexts.
仮想プライベートLANセグメント（VPLS）は、インターネット機能を使用してLANセグメントのエミュレーションです。 VPLSは時々プロトコル透過的に、ブリッジまたはルータのいずれかで、複数のスタブCPEノードを相互接続するために使用することができる透過LANサービス（TLS）としても知られているものを提供するために使用することができます。 VPLSは、LANEなどのプロトコルは、ATM上のLANセグメントをエミュレートと同様に、IP上のLANセグメントをエミュレートします。 VPLSの主な利点は、マルチプロトコル・トランスポートのために、特定のサービスプロバイダのコンテキストで規制上の理由のために、両方重要であるかもしれない完全なプロトコル透明性、です。
10.1.1.1 +--------+ +--------+ 10.1.1.2
+---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |-----------------------| edge |-------|CPE|
+---+ stub | node | | node | stub +---+
link +--------+ +--------+ link
^ | | ^
| | --------------- | |
| | ( ) | |
| +----( IP BACKBONE )----+ |
| ( ) |
| --------------- |
| | |
|IP tunnel +--------+ IP tunnel|
| | ISP | |
+-----------| edge |-----------+
| node |
+--------+ subnet = 10.1.1.0/24
|
stub link |
|
+---+
|CPE| 10.1.1.3
+---+
Figure 7.1: VPLS Example
図7.1：VPLS例
Topologically and operationally a VPLS can be most easily modeled as being essentially equivalent to a VPRN, except that each VPLS edge node implements link layer bridging rather than network layer forwarding. As such, most of the VPRN tunneling and configuration mechanisms discussed previously can also be used for a VPLS, with the appropriate changes to accommodate link layer, rather than network layer, packets and addressing information. The following sections discuss the primary changes needed in VPRN operation to support VPLSs.
位相的及び動作的VPLSは、最も容易には、エッジノードがリンク層ブリッジはなく、ネットワーク層転送を実装VPLSことを除いて、VPRNと本質的に等価であるとしてモデル化することができます。このように、先に述べたVPRNトンネリングおよび設定メカニズムのほとんどはまた、リンク層ではなく、ネットワーク層、パケットとアドレス情報を収容するために適切な変更で、VPLSのために使用することができます。次のセクションでは、VPLSsをサポートするためにVPRN操作に必要な主な変更を議論します。
The tunneling protocols employed within a VPLS can be exactly the same as those used within a VPRN, if the tunneling protocol permits the transport of multiprotocol traffic, and this is assumed below.
トンネリングプロトコルは、マルチプロトコルトラフィックの輸送を可能にし、これは以下とするとVPLS内で使用トンネリングプロトコルは、VPRN内で使用されるものと全く同じであることができます。
A VPLS needs to have a broadcast capability. This is needed both for broadcast frames, and for link layer packet flooding, where a unicast frame is flooded because the path to the destination link layer address is unknown. The address resolution protocols that run over a bridged network typically use broadcast frames (e.g. ARP). The same set of possible multicast tunneling mechanisms discussed earlier for VPRNs apply also to a VPLS, though the generally more frequent use of broadcast in VPLSs may increase the pressure for native multicast support that reduces, for instance, the burden of replication on VPLS edge nodes.
VPLSはブロードキャスト機能を持っている必要があります。これは、ブロードキャストフレームのために、宛先リンク層アドレスへの経路が不明であるので、ユニキャストフレームをフラッディングされたリンク層パケットフラッディング、の両方が必要です。ブリッジネットワーク上で実行するアドレス解決プロトコルは、典型的には、ブロードキャストフレーム（例えば、ARP）を使用します。 VPRNsための前述の可能なマルチキャストトンネリングメカニズムの同じセットVPLSsにおける放送概してより頻繁な使用は、例えば、VPLSエッジノード上の複製の負担を軽減ネイティブマルチキャストをサポートするための圧力を増大させることができるものの、VPLSにも適用さ。
The configuration of VPLS membership is analogous to that of VPRNs since this generally requires only knowledge of the local VPN link assignments at any given VPLS edge node, and the identity of, or route to, the other edge nodes in the VPLS; in particular, such configuration is independent of the nature of the forwarding at each VPN edge node. As such, any of the mechanisms for VPN member configuration and dissemination discussed for VPRN configuration can also be applied to VPLS configuration. Also as with VPRNs, the topology of the VPLS could be easily manipulated by controlling the configuration of peer nodes at each VPLS edge node, assuming that the membership dissemination mechanism was such as to permit this. It is likely that typical VPLSs will be fully meshed, however, in order to preclude the need for traffic between two VPLS nodes to transit through another VPLS node, which would then require the use of the Spanning Tree protocol [65] for loop prevention.
これは、一般的にVPLS内の他のエッジノードのみを任意のVPLSエッジノードでローカルVPNリンク割り当ての知識との同一、または経路を必要とするのでVPLSメンバーシップの構成はVPRNsのものと類似です。特に、このような構成は、各VPNエッジノードにおける転送の性質とは無関係です。このように、VPNのメンバー構成とVPRN構成について述べた普及のための機構のいずれかはまた、VPLSの構成に適用することができます。またVPRNsと同様に、VPLSのトポロジは、容易にこれを可能にするよう会員配布機構は、あったと仮定すると、エッジノードのVPLSのピア・ノードの構成を制御することによって操作することができました。典型的VPLSsが完全に、ループ防止のためのスパニングツリープロトコル[65]の使用を必要とする別のVPLSノードを介して通過への2つのVPLSノード間のトラフィックの必要性を排除するために、しかし、噛合される可能性があります。
A VPLS can support either bridges or routers as a CPE device.
VPLSは、CPEデバイスのいずれかとブリッジまたはルータをサポートすることができます。
CPE routers would peer transparently across a VPLS with each other without requiring any router peering with any nodes within the VPLS. The same scalability issues that apply to a full mesh topology for VPRNs, apply also in this case, only that now the number of peering routers is potentially greater, since the ISP edge device is no longer acting as an aggregation point.
CPEルータは、VPLS内の任意のノードとピアリング任意のルータを必要とすることなく、互いにVPLSを横切って透過ピアなります。 ISPエッジデバイスがもはや集約ポイントとして機能しているのでVPRNsのフルメッシュトポロジに適用されるのと同じスケーラビリティの問題が、この場合にも適用され、ピアリングルータのみが今数は、潜在的に大きくありません。
With CPE bridge devices the broadcast domain encompasses all the CPE sites as well as the VPLS itself. There are significant scalability constraints in this case, due to the need for packet flooding, and the fact that any topology change in the bridged domain is not localized, but is visible throughout the domain. As such this scenario is generally only suited for support of non-routable protocols.
CPEブリッジデバイスでブロードキャストドメインは、すべてのCPEサイトだけでなく、VPLS自体を包含する。そこ大幅なスケーラビリティパケットフラッディングの必要性のために、この場合の制約、およびブリッジドメイン内の任意のトポロジの変更がローカライズされていないという事実がありますが、ドメイン全体に表示されます。そのため、このシナリオでは、一般的に唯一の非ルーティング可能なプロトコルのサポートに適しています。
The nature of the CPE impacts the nature of the encapsulation, addressing, forwarding and reachability protocols within the VPLS, and are discussed separately below.
CPEの影響VPLS内のカプセル化、アドレッシング、転送および到達可能性プロトコルの性質の性質、及び以下に別々に議論されます。
In this case, packets sent to and from the VPLS across stub links are link layer frames, with a suitable access link encapsulation. The most common case is likely to be ethernet frames, using an encapsulation appropriate to the particular access technology, such as ATM, connecting the CPE bridges to the VPLS edge nodes. Such frames are then forwarded at layer 2 onto a tunnel used in the VPLS. As noted previously, this does mandate the use of an IP tunneling protocol which can transport such link layer frames. Note that this does not necessarily mandate, however, the use of a protocol identification field in each tunnel packet, since the nature of the encapsulated traffic (e.g. ethernet frames) could be indicated at tunnel setup.
この場合、パケットは、適切なアクセス・リンクカプセル化、リンク層フレームであるとスタブリンク間VPLSから送られてきました。最も一般的なケースは、VPLSエッジノードにCPEブリッジを接続するATMのような特定のアクセス技術に適切なカプセル化を使用して、イーサネットフレーム、、、である可能性が高いです。このようなフレームは、次に、VPLSに使用されるトンネルにレイヤ2に転送されます。先に述べたように、このようなリンク層フレームを輸送することができるIPトンネリングプロトコルの使用を義務付けません。これは必ずしも強制しないことに注意してください、しかし、カプセル化されたトラフィック（例えば、イーサネットフレーム）の性質ので、各トンネルパケットのプロトコル識別フィールドを使用すると、トンネル設定で示すことができます。
In this case, typically, CPE routers send link layer packets to and from the VPLS across stub links, destined to the link layer addresses of their peer CPE routers. Other types of encapsulations may also prove feasible in such a case, however, since the relatively constrained addressing space needed for a VPLS to which only router CPE are connected, could allow for alternative encapsulations, as discussed further below.
この場合には、典型的には、CPEルータはそのピアCPEルータのリンク層アドレス宛スタブリンクの両端のVPLSにからリンク層パケットを送信します。のみルータCPEにVPLSのために必要な比較的制約アドレス空間が接続されているので、カプセル化の他のタイプもまた、さらに後述するように、別のカプセル化を可能にすることができ、しかし、そのような場合に可能証明することができます。
Since a VPLS operates at the link layer, all hosts within all stub sites, in the case of bridge CPE, will typically be in the same network layer subnet. (Multinetting, whereby multiple subnets operate over the same LAN segment, is possible, but much less common). Frames are forwarded across and within the VPLS based upon the link layer addresses - e.g. IEEE MAC addresses - associated with the individual hosts. The VPLS needs to support broadcast traffic, such as that typically used for the address resolution mechanism used to map the host network addresses to their respective link addresses. The VPLS forwarding and reachability algorithms also need to be able to accommodate flooded traffic.
VPLSは、リンクレイヤで動作するので、全てのスタブ・サイト内のすべてのホストは、ブリッジCPEの場合には、典型的には同一のネットワーク層サブネットであろう。 （複数のサブネットが同一のLANセグメント上で動作することによりマルチネッティングは、可能であるが、はるかに一般的）。フレームを横切ってリンク層アドレスに基づいてVPLS内に転送される - 例えばIEEE MACアドレス - 個々のホストに関連付けられています。 VPLSは、一般的に、それぞれのリンクアドレスにホストネットワークアドレスをマッピングするために使用されるアドレス解決メカニズムのために使用されるような、ブロードキャストトラフィックをサポートする必要があります。 VPLSフォワーディングと到達可能性アルゴリズムも浸水トラフィックに対応できるようにする必要があります。
A single network layer subnet is generally used to interconnect router CPE devices, across a VPLS. Behind each CPE router are hosts in different network layer subnets. CPE routers transfer packets across the VPLS by mapping next hop network layer addresses to the link layer addresses of a router peer. A link layer encapsulation is used, most commonly ethernet, as for the bridge case.
単一のネットワーク層サブネットは一般VPLSを横切って、ルータのCPEデバイスを相互接続するために使用されます。各CPEルータの背後に異なるネットワーク層サブネット内のホストです。ルータピアのリンク層アドレスに次ホップネットワーク層アドレスをマッピングすることにより、VPLSを横切るCPEルータ転送パケット。リンク層のカプセル化は、ブリッジの場合のように、最も一般的にイーサネット（登録商標）、使用されています。
As noted above, however, in cases where all of the CPE nodes connected to the VPLS are routers, then it may be possible, due to the constrained addressing space of the VPLS, to use encapsulations that use a different address space than normal MAC addressing. See, for instance, [11], for a proposed mechanism for VPLSs over MPLS networks, leveraging earlier work on VPRN support over MPLS [38], which proposes MPLS as the tunneling mechanism, and locally assigned MPLS labels as the link layer addressing scheme to identify the CPE LSR routers connected to the VPLS.
上述したように、しかし、VPLSに接続されたCPEのすべてのノードがルータである場合には、それは通常のアドレッシングMACは異なるアドレス空間を使用してカプセル化を使用すること、によるVPLSの制約されたアドレス空間に、可能であってもよいです。トンネリング機構としてMPLSを提案MPLS [38]、上VPRN支持体上に以前の作業を活用する、MPLSネットワーク上VPLSsための提案されたメカニズムのために、例えば、[11]参照、およびリンク層アドレス指定方式としてローカルに割り当てられたMPLSラベルVPLSに接続されたCPE LSRルータを識別します。
The only practical VPLS edge node forwarding mechanism in this case is likely to be standard link layer packet flooding and MAC address learning, as per [65]. As such, no explicit intra-VPLS reachability protocol will be needed, though there will be a need for broadcast mechanisms to flood traffic, as discussed above. In general, it may not prove necessary to also implement the Spanning Tree protocol between VPLS edge nodes, if the VPLS topology is such that no VPLS edge node is used for transit traffic between any other VPLS edge nodes - in other words, where there is both full mesh connectivity and transit is explicitly precluded. On the other hand, the CPE bridges may well implement the spanning tree protocol in order to safeguard against 'backdoor' paths that bypass connectivity through the VPLS.
この場合の唯一の実用的なVPLSエッジノードの転送メカニズムは、[65]に従って、標準的なリンクレイヤパケットフラッディングとMACアドレス学習である可能性が高いです。上述したように、トラフィックをフラッディングするブロードキャスト・メカニズムの必要性があるでしょうけれどもそのように、明示的な内VPLS到達性プロトコルは、必要とされません。一般的には、VPLSトポロジはないVPLSエッジノードは、他のVPLSエッジノード間の通過トラフィックのために使用されないようなものである場合にも、VPLSエッジノード間のスパニングツリープロトコルを実装する必要が証明なくてもよい - 換言すれば、ある場合フルメッシュ接続性と輸送の両方を明示的に排除されます。一方、CPEブリッジはよくVPLSを介して接続をバイパスする「バックドア」経路に対して保護するために、スパニングツリープロトコルを実装することができます。
Standard bridging techniques can also be used in this case. In addition, the smaller link layer address space of such a VPLS may also permit other techniques, with explicit link layer routes between CPE routers. [11], for instance, proposes that MPLS LSPs be set up, at the insertion of any new CPE router into the VPLS, between all CPE
標準的な架橋技術がこの場合にも使用することができます。加えて、そのようなVPLSの小さいリンク層アドレス空間はまた、CPEルータ間の明示的なリンクレイヤ経路と、他の技術を可能にすることができます。 [11]は、例えば、MPLSのLSPがすべてのCPE間、VPLSに新しいCPEルータの挿入時に、設定されることを提案しています
LSRs. This then precludes the need for packet flooding. In the more general case, if stub link reachability mechanisms were used to configure VPLS edge nodes with the link layer addresses of the CPE routers connected to them, then modifications of any of the intra-VPN reachability mechanisms discussed for VPRNs could be used to propagate this information to each other VPLS edge node. This would then allow for packet forwarding across the VPLS without flooding.
LSR。これは、パケットフラッディングの必要性を排除します。より一般的なケースでは、スタブリンク到達可能性メカニズムは、次いでVPRNsに関して説明イントラVPN到達可能性のメカニズムの任意の変更が伝播するために使用することができ、それらに接続されたCPEルータのリンク層アドレスとVPLSエッジノードを構成するために使用された場合互いにVPLSエッジノードにこの情報。これはその後、洪水のないVPLS間でパケット転送を可能にします。
Mechanisms could also be developed to further propagate the link layer addresses of peer CPE routers and their corresponding network layer addresses across the stub links to the CPE routers, where such information could be inserted into the CPE router's address resolution tables. This would then also preclude the need for broadcast address resolution protocols across the VPLS.
機構はまた、そのような情報は、CPEルータのアドレス解決テーブルに挿入することができるCPEルータへスタブリンクを介してピアCPEルータのリンク層アドレスとそれに対応するネットワーク層アドレスを伝播するために開発され得ます。そして、これはまた、VPLS全体ブロードキャストアドレス解決プロトコルの必要性を排除するでしょう。
Clearly there would be no need for the support of spanning tree protocols if explicit link layer routes were determined across the VPLS. If normal flooding mechanisms were used then spanning tree would only be required if full mesh connectivity was not available and hence VPLS nodes had to carry transit traffic.
明らかに明示的なリンクレイヤルートがVPLS渡って決定された場合はスパニングツリープロトコルのサポートは必要ないでしょう。通常の氾濫メカニズムは、その後、使用された場合は、フルメッシュ接続が利用できませんでしたので、VPLSノードがトランジットトラフィックを運ぶために持っていた場合、スパニングツリーにのみ必要とされるであろう。
There is significant commonality between VPRNs and VPLSs, and, where possible, this similarity should be exploited in order to reduce development and configuration complexity. In particular, VPLSs should utilize the same tunneling and membership configuration mechanisms, with changes only to reflect the specific characteristics of VPLSs.
、この類似性は、開発および設定の複雑さを軽減するために利用されなければならない可能VPRNsとVPLSs、と、の間には有意な共通点があります。特に、VPLSsのみVPLSsの特定の特性を反映するように変更して、同じトンネリング会員構成機構を利用すべきです。
In this document different types of VPNs have been discussed individually, but there are many common requirements and mechanisms that apply to all types of VPNs, and many networks will contain a mix of different types of VPNs. It is useful to have as much commonality as possible across these different VPN types. In particular, by standardizing a relatively small number of mechanisms, it is possible to allow a wide variety of VPNs to be implemented.
この文書でのVPNの異なるタイプが個別に議論されてきたが、VPNのすべてのタイプに適用され、多くの一般的な要件とメカニズムが存在し、そして多くのネットワークはVPNのさまざまな種類のミックスが含まれています。これらの異なるVPNタイプにわたってできるだけ多くの共通点があると便利です。具体的には、機構の比較的小さな数を標準化することにより、VPNの多種多様を実施することを可能にすることが可能です。
The benefits of adding support for the following mechanisms should be carefully examined.
以下のメカニズムのサポートを追加することの利点は、慎重に検討する必要があります。
For IKE/IPSec:
IKE / IPSecの場合：
- the transport of a VPN-ID when establishing an SA (3.1.2)
- SA（3.1.2）を確立するVPN-IDの輸送
- a null encryption and null authentication option (3.1.3)
- ヌル暗号化とヌル認証オプション（3.1.3）
- multiprotocol operation (3.1.4)
- マルチプロトコル動作（3.1.4）
- frame sequencing (3.1.5)
- フレームシーケンス（3.1.5）
- asymmetric / legacy user authentication (6.3)
- 非対称/レガシーユーザ認証（6.3）
- host address assignment and configuration (6.3)
- ホストアドレスの割り当ておよび構成（6.3）
For L2TP:
L2TPの場合：
- defining modes of operation of IPSec when used to support L2TP (3.2)
- L2TP（3.2）をサポートするために使用される場合のIPSecの動作モードを定義します
For VPNs generally:
一般のVPNの場合：
- defining a VPN membership information configuration and dissemination mechanism, that uses some form of directory or MIB (5.3.2)
- ディレクトリまたはMIB（5.3.2）のいくつかのフォームを使用してVPNメンバーシップ情報の構成及び普及機構を定義します
- ensure that solutions developed, as far as possible, are applicable to different types of VPNs, rather than being specific to a single type of VPN.
- ソリューションを開発することを確認し、可能な限りではなく、VPNの単一タイプに特異的であるよりも、VPNの異なるタイプに適用可能です。
Security considerations are an integral part of any VPN mechanisms, and these are discussed in the sections describing those mechanisms.
セキュリティ上の考慮事項は、任意のVPN機構の不可欠な部分であり、これらは、これらのメカニズムを説明するセクションで説明されています。
Thanks to Anthony Alles, of Nortel Networks, for his invaluable assistance with the generation of this document, and who developed much of the material on which early versions of this document were based. Thanks also to Joel Halpern for his helpful review comments.
このドキュメントの生成と彼の貴重な援助のためのノーテルネットワークスのアンソニーAlles氏のおかげで、この文書の初期のバージョンをベースとした上で材料の多くを開発しました。彼の役に立つレビューコメントについても、ジョエルハルパーンに感謝します。
[1] ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000, January 1995.
[1] ATMフォーラム。バイ・レーン-0021.000 "ATM 1.0オーバーLANエミュレーション"、1995年1月。
[2] ATM Forum. "Multi-Protocol Over ATM Specification v1.0", af-mpoa-0087.000, June 1997.
[2] ATMフォーラム。 "マルチプロトコルオーバーATM仕様v1.0を"、AF-MPOA-0087.000、1997年6月。
[3] Ferguson, P. and Huston, G. "What is a VPN?", Revision 1, April 1 1998; http://www.employees.org/~ferguson/vpn.pdf.
[3]ファーガソン、P.とヒューストンは、G.は、 "VPNとは何ですか？"、リビジョン1、1998年4月1日。 http://www.employees.org/~ferguson/vpn.pdf。
[4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[4] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、G.、およびE.リア、BCP 5、RFC 1918、1996年2月、 "個人的なインターネットのための配分"。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[6]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[7] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[7]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[8] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[9] Rosen, E., et al., "Multiprotocol Label Switching Architecture", Work in Progress.
[9]ローゼン、E.、ら、 "マルチプロトコルラベルスイッチングアーキテクチャ"、ProgressのWork。
[10] Heinanen, J., et al., "MPLS Mappings of Generic VPN Mechanisms", Work in Progress.
[10] Heinanen、J.、ら、 "一般的なVPN機構のMPLSマッピング"、ProgressのWork。
[11] Jamieson, D., et al., "MPLS VPN Architecture", Work in Progress.
[11]ジェイミソン、D.、ら、 "MPLS VPNアーキテクチャ"、ProgressのWork。
[12] Casey, L., et al., "IP VPN Realization using MPLS Tunnels", Work in Progress.
[12]ケーシー、L.、ら。、進行中の作業 "MPLSトンネルを使用して、IP VPNの実現"。
[13] Li, T. "CPE based VPNs using MPLS", Work in Progress.
[13]のLi、T. "MPLSを使用してCPEベースのVPN"、ProgressのWork。
[14] Muthukrishnan, K. and A. Malis, "Core MPLS IP VPN Architecture", Work in Progress.
[14] Muthukrishnan、K.とA. Malis、 "コアMPLS IP VPNアーキテクチャ"、進行中の作業します。
[15] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[15]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[16] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[16]フォックス、B.及びB.グリーソン、 "仮想プライベートネットワーク識別子"、RFC 2685、1999年9月。
[17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM Forum, af-mpoa-0129.000.
[17]ペトリ、B.（編集） "VPN支持体上MPOA v1.1の補遺"、ATMフォーラム、AF-MPOA-0129.000。
[18] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[18]ハーキンズ、D.およびC.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[19] Calhoun, P., et al., "Tunnel Establishment Protocol", Work in Progress.
[19]カルフーン、P.、ら。、 "トンネル確立プロトコル"、ProgressのWork。
[20] Andersson, L., et al., "LDP Specification", Work in Progress.
[20]アンダーソン、L.、ら。、 "LDP仕様"、ProgressのWork。
[21] Jamoussi, B., et al., "Constraint-Based LSP Setup using LDP" Work in Progress.
[21] Jamoussi、B.、ら、進行中の作業 "LDPを使用して、制約ベースLSPセットアップ"。
[22] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", Work in Progress.
、進行中の作業[22]らAwduche、D.、。、 "LSPトンネルのためのRSVPの拡張"。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[23]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティプロトコル（ESP）"、RFC 2406、1998年11月。
[24] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[24]シンプソン、W.、エディタ、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[25]ペレス、M.、Liaw、F.、マンキン、A.、ホフマン、E.、グロスマン、D.およびA. Malis、 "ATMオーバーIP用のATMシグナリングサポート"、RFC 1755、1995年2月。
[26] Malkin, G. "RIP Version 2 Carrying Additional Information", RFC 1723, November 1994.
[26]、RFC 1723、1994年11月の "追加情報を運ぶRIPバージョン2" マルキン、G.。
[27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[27]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[28] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[28] Shacham、A.、Monsour、R.、ペレイラ、R.とM.トーマス、 "IPペイロード圧縮プロトコル（IPCompの）"、RFC 2393、1998年12月。
[29] Duffield N., et al., "A Performance Oriented Service Interface for Virtual Private Networks", Work in Progress.
[29]ダッフィールドN.、ら、「バーチャル・プライベート・ネットワークのためのサービスインタフェース指向のパフォーマンス」が進行中で働いています。
[30] Jacobson, V., Nichols, K. and B. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[30]ジェーコブソン、V.、ニコルズ、K.及びB. Poduri、 "緊急転送PHB"、RFC 2598、1999年6月。
[31] Casey, L., "An extended IP VPN Architecture", Work in Progress.
[31]ケーシー、L.、 "拡張されたIP VPNアーキテクチャ"、進行中の作業。
[32] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[32] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[33] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[33]グロスマン、D.およびJ. Heinanen、 "マルチプロトコルカプセル化ATMアダプテーション・レイヤ5上"、RFC 2684、1999年9月。
[34] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[34]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[35] Boyle, J., et al., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[35]ボイル、J.、ら、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[36] MacRae, M. and S. Ayandeh, "Using COPS for VPN Connectivity" Work in Progress.
[36]マクレー、M.およびS. Ayandeh、進行中の作業 "VPN接続のために使用COPS"。
[37] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[37] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[38] Heinanen, J. and E. Rosen, "VPN Support with MPLS", Work in Progress.
[38] Heinanen、J.およびE.ローゼン、 "MPLS VPNとサポート"、ProgressのWork。
[39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[39] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[40] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[40] Waitzman、D.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、RFC 1075、1988年11月。
[41] Fenner, W., "IGMP-based Multicast Forwarding (IGMP Proxying)", Work in Progress.
[41]フェナー、W.、 "IGMPベースのマルチキャスト転送（IGMPプロキシ）"、ProgressのWork。
[42] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[42]ウォルナー、D.、ハーダー、E.およびR.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ"、RFC 2627、1999年6月。
[43] Hardjono, T., et al., "Secure IP Multicast: Problem areas, Framework, and Building Blocks", Work in Progress.
[43] Hardjono、T.、ら、 "セキュアなIPマルチキャスト：問題領域、フレームワーク、およびビルディング・ブロック"、ProgressのWork。
[44] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[44] Rigney、C.、ルーベンス、A.、シンプソン、W.及びS. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[45] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[45]バレンシア、A.、リトルウッド、M.とT.コーラール、 "シスコレイヤ二フォワーディング（プロトコル） "L2F""、RFC 2341、1998年5月。
[46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[46] Hamzeh、K.、ポール、G.、Verthein、W.、Taarud、J.、リトル、W.およびG.ゾルン、 "ポイントツーポイントトンネリングプロトコル（PPTP）"、RFC 2637、1999年7月。
[47] Patel, B., et al., "Securing L2TP using IPSEC", Work in Progress.
[47]パテル、B.、ら、進行中、作業の "IPsecを使用してL2TPの保護"。
[48] Srisuresh, P., "Secure Remote Access with L2TP", Work in Progress.
[48] Srisuresh、P.は、進行中の作業、 "L2TPとリモートアクセスをセキュア"。
[49] Calhoun, P., et al., "Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IP networks", Work in Progress.
[49]カルフーン、P.ら、「レイヤ2トンネリングプロトコル 『L2TP』非IPネットワークのセキュリティ拡張機能」が進行中で働いています。
[50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS", Work in progress.
[50] Aboba、B.及びゾルン、G.、進行中の作業 "RADIUSを介してPPTP / L2TP強制トンネリングの実装"。
[51] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[51] Aboba、B.およびG.ゾルン、 "ローミングプロトコルを評価するための基準"、RFC 2477、1999年1月。
[52] Shea, R., "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in Progress.
[52]シェイ、R.、 "L2TPオーバーIPパスMTUディスカバリ（L2TPMTU）"、ProgressのWork。
[53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[53] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル（MP）"、RFC 1990、1996年8月。
[54] Richards, C. and K. Smith, "The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)", RFC 2125, March 1997.
[54]リチャーズ、C.及びK.スミス、 "PPP帯域幅割り当てプロトコル（BAP）PPP帯域幅割り当て制御プロトコル（BACP）"、RFC 2125、1997年3月。
[55] Calhoun, P. and K. Peirce, "Layer Two Tunneling Protocol "L2TP" IP Differential Services Extension", Work in Progress.
[55]カルフーン、P.とK.パース、「レイヤ2トンネリングプロトコル 『L2TP』 IPディファレンシャルサービス拡張」が進行中で働いています。
[56] ADSL Forum. "An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97- 215.
[56] ADSLフォーラム。 「ADSLシステムに勝る相互運用エンド・ツー・エンドのブロードバンドサービスアーキテクチャ（バージョン3.0）」、ADSLフォーラム97- 215。
[57] ADSL Forum. "Core Network Architectures for ADSL Access Systems (Version 1.01)", ADSL Forum 98-017.
[57] ADSLフォーラム。 「ADSLアクセスシステムのためのコア・ネットワーク・アーキテクチャ（バージョン1.01）」、ADSLフォーラム98から017まで。
[58] Gupta, V., "Secure, Remote Access over the Internet using IPSec", Work in Progress.
[58]グプタ、V.、「IPSecを使用してインターネット経由でセキュアなリモートアクセス」が進行中で働いています。
[59] Pereira, R., et al., "The ISAKMP Configuration Method", Work in Progress.
[59]ペレイラ、R。、ら、 "ISAKMPの設定方法"、ProgressのWork。
[60] Pereira, R. and S. Beaulieu, "Extended Authentication Within ISAKMP/Oakley", Work in Progress.
[60]ペレイラ、R.およびS.ボーリュー、 "ISAKMP / Oakleyの範囲内で拡張認証"、進行中の作業。
[61] Litvin, M., et al., "A Hybrid Authentication Mode for IKE", Work in Progress.
[61]リトビン、M.、ら、「IKE用ハイブリッド認証モード」、進行中の作業。
[62] Kelly, S., et al., "User-level Authentication Mechanisms for IPsec", Work in Progress.
[62]ケリー、S.、ら、 "ユーザレベルIPsecのための認証メカニズム"、ProgressのWork。
[63] Patel, B., et al., "DHCP Configuration of IPSEC Tunnel Mode", Work in Progress.
[63]パテル、B.、ら、 "IPSECトンネルモードのDHCP構成"、進行中の作業。
[64] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[64] Mamakos、L.、Lidlの、K.、Evarts、J.、カレル、D.、シモン、D.およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516、1999年2月。
[65] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges, ANSI/IEEE Std 802.1D, 1993 Edition.
[65] ANSI / IEEE - 10038：1993（ISO / IEC）情報技術 - 電気通信及びシステム間の情報交換 - ローカルエリアネットワーク - メディアアクセス制御（MAC）ブリッジ、ANSI / IEEE規格802.1D、1993年版。
Bryan Gleeson Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
ブライアン・グリーソンNortel Networksの4500グレートアメリカパークウェイサンタクララCA 95054 USA
Phone: +1 (408) 548 3711 EMail: bgleeson@shastanets.com
電話：+1（408）548 3711 Eメール：bgleeson@shastanets.com
Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland
わらテリアフィンランドユハ、株式会社Myyrmäentie2 01600 VANTAAフィンランド
Phone: +358 303 944 808 EMail: jh@telia.fi
電話番号：+358 303 944 808 Eメール：jh@telia.fi
Arthur Lin Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
アーサー・林Nortel Networksの4500グレートアメリカパークウェイサンタクララCA 95054 USA
Phone: +1 (408) 548 3788 EMail: alin@shastanets.com
電話：+1（408）548 3788 Eメール：alin@shastanets.com
Grenville Armitage Bell Labs Research Silicon Valley Lucent Technologies 3180 Porter Drive, Palo Alto, CA 94304 USA
グレンヴィルアーミテージベル研究所研究シリコンバレールーセント・テクノロジーズ3180ポータードライブ、パロアルト、CA 94304 USA
EMail: gja@lucent.com
メールアドレス：gja@lucent.com
Andrew G. Malis Lucent Technologies 1 Robbins Road Westford, MA 01886 USA
アンドリューG. Malisルーセント・テクノロジー1ロビンス・ロードウェストフォード、MA 01886 USA
Phone: +1 978 952 7414 EMail: amalis@lucent.com
電話：+1 978 952 7414 Eメール：amalis@lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。