[要約] RFC 2764は、IPベースの仮想プライベートネットワーク（VPN）のためのフレームワークを提供しています。このRFCの目的は、異なるネットワーク間でセキュアな通信を確立するためのガイドラインを提供することです。
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
IPベースの仮想プライベートネットワークのフレームワーク
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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施設を使用したプライベートワイドエリアネットワーク（WAN）施設のエミュレーション」（パブリックインターネット、またはプライベートIPバックボーンを含む）として単純に定義されます。そのため、ワンの種類と同じくらい多くの種類の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の導入を促進し、既存のソリューションをレバレッジできるため、標準と製品開発の両方に必要な努力を削減します。
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タイプの特定のセットの分類法を提案し、それぞれの特定のアプリケーション、特定の要件、および実装に最も適している特定のタイプのメカニズムを示します。このドキュメントの目的は、既存の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ネットワークであろうとパブリックインターネットなど、IPバックボーン全体のVPNの実装のみについて説明していることに注意してください。ここで説明するモデルとメカニズムは、IPv4とIPv6の両方のバックボーンに適用することを目的としています。このドキュメントでは、ネイティブマッピングを使用してスイッチ付きバックボーンにVPNを構築する手段（たとえば、ATM（レーン）[1]を介したLANエミュレーションを使用して構築されたVPNまたはATM（MPOA）上のマルチプロトコル（MPOA）[2]プロトコルを使用して構築されたVPNSの手段については説明しません。そのようなプロトコルを使用してIPバックボーンが構築されている場合、スイッチされたバックボーン上にルーターを相互接続することにより、議論されたVPNはこのIPネットワークの上で動作するため、基礎となるバックボーンのネイティブメカニズムを直接使用しません。ネイティブVPNは、基礎となるバックボーンの範囲に制限されていますが、IPベースのVPNはIPリーチ性の範囲まで拡張できます。ネイティブ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.
通常、既存のプライベートネットワークは、複数のサイトを永続的に接続する専用のワンとダイヤルネットワークに分類される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またはIntegrated Services Digital Network（ISDN）リンクを使用して、リモートユーザーがエンタープライズネットワークに接続できるようにするために使用されます。通常、これは、1つ以上の中央サイトでのネットワークアクセスサーバー（NASS）の展開を通じて行われます。ユーザーは、ユーザーのIDとユーザーが受け取ることを許可されているサービスのセットを確認するために、認証、承認、および会計（AAA）サーバーと対話するこのようなNASSにダイヤルします。
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メカニズムがすべてまとめられています。これらの要件には次のものが含まれます。
2.1.1 Opaque Packet Transport:
2.1.1 不透明なパケットトランスポート：
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サービスを提供する場所です。これは、顧客がパケットが誤った方向に向けられたり、ネットワークに注入されたり、snめられたり、輸送で修正されたり、被験者であると信頼しているという点で、顧客がパブリックスイッチのフレームリレーまたは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).
一緒に、上記の要件の最初の2つは、VPNが何らかの形のIPトンネリングメカニズムを通じて実装されなければならないことを意味します。ここでは、VPN内で使用されるパケット形式および/またはアドレス指定が、トンネルパケットを横切ってルーティングするために使用されるものとは無関係である可能性があります。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.
「エクストラネット」という用語は、一般に、2つ以上の企業が限られた量の互いの企業データへのネットワークアクセスを持つシナリオを参照するために使用されます。たとえば、製造会社は、サプライヤーにエクストラネットを使用して、コンポーネントの価格設定と可用性のためにデータベースを照会し、未払いの注文のステータスを注文および追跡できるようにする場合があります。別の例は、共同ソフトウェア開発です。たとえば、会社Aでは、B社内の1つの開発グループがオペレーティングシステムソースコードにアクセスできます。B社は、A社の1つの開発グループがセキュリティソフトウェアにアクセスできるようにします。アクセスポリシーは任意に複雑になる可能性があることに注意してください。たとえば、B社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) 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のこのモデルは、使用されるパケットトランスポートの基礎となるモードからポリシーを分離することを提供します。たとえば、ルーターは、保証されたQO、非ローカルな内部企業トラフィックのために、インターネットへのリンクへのその他のトラフィックのために、ATM仮想チャネル接続（VCC）に音声トラフィックを向けることができます。過去には、安全なトンネルはフレームリレー回路であった可能性がありますが、今では安全なIPトンネルまたはMPLSラベルスイッチ付きパス（LSP）である可能性があります。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ポートのリピーターは、ポート間でパケットを順方向に進め、パケットの内容を調べません。ブリッジは、パケットに含まれるメディアアクセスコントロール（MAC）レイヤー情報を使用してパケットを転送し、ルーターはパケットに含まれるレイヤー3アドレス指定情報を使用してパケットを転送します。これらの3つのシナリオにはそれぞれ、後で説明するように、直接的なVPNアナログがあります。IPトンネルは、VPNのタイプに応じて、別のリンクに連結したり、ブリッジ転送テーブルにバインドされたり、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]).
ただし、上記のIPトンネルプロトコルのそれぞれとMPLSの間には、1つの重要な区別があることに注意してください。MPLSは、MPLSネットワークの範囲内でのみ適用される限り、IPの範囲内でのみ適用される限り、IPの特定のリンクレイヤーと見なすことができますが、IPベースのメカニズムはIPリーチ性の範囲にまで及びます。そのため、MPLSトンネリングメカニズムに直接構築されたVPNメカニズムは、定義上、MPLSネットワークの範囲外に拡張することはできません。たとえば、レーンなどのATMベースのメカニズムはATMネットワークの外側に拡張できます。ただし、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.
同じ2つのIPエンドポイントの間に複数のVPNトンネルが必要になる場合がある場合があります。これは、たとえば、VPNがネットワークベースであり、各エンドポイントが複数の顧客をサポートする場合に必要になる場合があります。さまざまな顧客のトラフィックは、同じ2つの物理デバイスの間で個別のトンネルを越えて移動します。どのパケットがどのトンネルに属しているかを区別するには、多重化フィールドが必要です。この方法でトンネルを共有すると、セットアップのトンネルの潜在性と処理負担が減少する場合があります。既存のIPトンネルメカニズムのうち、L2TP（トンネルIDおよびセッションIDフィールドを介して）、MPLS（ラベルを介して）およびIPSEC（セキュリティパラメーターインデックス（SPI）フィールドを介して）には多重化メカニズムがあります。厳密に言えば、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をパケットごとに識別したりすることができます。データプレーンでは、MPLS、MPOA、およびその他のトンネルメカニズムでVPNカプセル化ヘッダーを使用して、単一のトンネル上のさまざまなVPNのパケットを集約することができます。この場合、VPN-IDの明示的な兆候がすべてのパケットに含まれており、トンネル固有の多重化フィールドでは無駄になります。コントロールプレーンでは、VPN-IDフィールドを任意のトンネル設立シグナル伝達プロトコルに含めて、トンネルの関連付け（たとえば、SPIフィールドで識別されるように）とVPNとの関連を可能にすることができます。この場合、すべてのデータパケットに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.
管理操作の例は、SNMP管理情報ベース（MIB）を使用して、MPLSラベル、IP/IPまたはGREトンネル、L2TPトンネルIDおよびセッションIDに使用するさまざまなトンネルパラメーター、例えば、ソースアドレスを構成することです。または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-IDの輸送を可能にして、結果のトンネルを特定のVPNに関連付けることができます。また、フレームシーケンスの使用やマルチプロトコル輸送の使用など、トンネル属性を交換または交渉することもできます。シグナリングプロトコルの役割は、トンネルの使用方法についての情報を携帯することではなく、トンネルの属性を交渉するだけである必要があることに注意してください。Q.2931 ATMシグナル伝達と同様に、同じシグナル伝達プロトコルを使用して、古典的なIP論理サブネットワークとレーンエミュレートLANSをセットアップします。
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].
さまざまなIPトンネルプロトコルのうち、次のものは、この目的に適合できるシグナル伝達プロトコルをサポートしています：L2TP（L2TP制御プロトコル）、IPSEC（インターネットキーエクスチェンジ（IKE）プロトコル[18]）、およびGRE（モバイルIPトンネル[19]）。また、LSPトンネルの確立に使用できる2つのMPLSシグナル伝達プロトコルがあります。1つは、制約ベースのルーティングLDP（CR-LDP）[21]と呼ばれるMPLSラベル分布プロトコル（LDP）プロトコル[20]の拡張機能を使用し、もう1つは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セキュリティは、単なるトンネルだけではなく、パケットがそれらのトンネルにどのように転送されるかについて、より広いコンテキストで表示する必要があります。たとえば、仮想ルーターで実装されたVPRNでは、個別のルーティングと転送のテーブルインスタンスを使用すると、VPN間のトラフィックの分離が保証されます。これらのトンネルは最初のVPNの転送テーブルに見えないため、1つのVPNのパケットを2番目の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.
現在、セキュリティペイロード（ESP）プロトコル[23]をカプセル化するIPSECを使用して、暗号化または認証のいずれかをサポートするSASを確立できます。ただし、プロトコルの仕様では、暗号化も認証も使用されていないSAの使用を妨げます。VPN環境では、この「null/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およびIPSECトンネルには、トンネル化されるトラフィックがIPであると想定されるため、このようなプロトコル識別フィールドはありません。
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プロトコルスイートを拡張して、マルチプロトコルパケットの輸送を可能にすることができます。これは、たとえば、IPSEC -IKEのシグナル伝達コンポーネントを拡張して、トンネルに登録されているトラフィックのプロトコルタイプを示すか、それぞれのパケットマルチプレックスヘッダー（LLC/SNAPヘッダーまたはGREヘッダーなど）をそれぞれ携帯することで達成できます。トンネルパケット。このアプローチは、ATMネットワークで同じ目的で使用されるアプローチと類似しています。これは、VCCで使用されているカプセル化を示すためにシグナルを使用し、VCCで送信されるパケットがLLC/SNAPヘッダーを使用するか、AAL5に直接配置できる場所に似ています。ペイロード、後者は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の顧客が必要とするサービスの品質属性の1つは、フレームシーケンスであり、物理リースラインまたは専用接続の同等の特性と一致する場合があります。特定のエンドからエンドプロトコルまたはアプリケーションの効率的な動作には、シーケンスが必要になる場合があります。フレームシーケンスを実装するには、トンネルメカニズムがシーケンスフィールドをサポートする必要があります。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つのアプローチがあります。1つは、トンネリングプロトコル自体が、定期的に接続の喪失についてインバンドを定期的にチェックし、障害の明示的な兆候を提供することです。たとえば、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ピンを実行することです。これは一般に、トンネルが同じ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.
動的トンネルの確立をいつトリガーするかについては、さまざまなポリシーを使用できます。1つのアプローチは、データ駆動型のアプローチを使用し、転送するデータがあるときはいつでもトンネルの確立をトリガーし、不活性のためにトンネルをタイムアウトすることです。このアプローチは、トンネルのリソースが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.
別のアプローチは、トンネルプロトコル自体が、おそらくトンネルシーケンス番号と何らかの種類のメサージの終了マーカーを使用して、トンネルレベルで動作するセグメンテーションと再組み立て機能を組み込むことです。（Multilink 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.
オーバーヘッドの量が重要な領域の1つは、ダイヤルアップリンクの帯域幅が一般的に低いため、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プロトコル手順の開発中に、流れと輻輳制御のために開発されました。これらは主に、PPP圧縮が使用されるときに損失のあるネットワークよりも適切なパフォーマンスを提供する必要があるために必要でした。これは、IPペイロード圧縮プロトコル（IPComp）[28]とは異なり、パケット全体でステートフルです。もう1つの動機は、たとえば低速ダイヤルアップラインを終了するために使用されるバッファリングがほとんどないデバイスに対応することでした。ただし、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およびVPNSの議論については、[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をサポートします。ただし、VPN環境のトンネル要件をより適切にサポートするために、IPSECプロトコルスイートを次の領域もカバーすることも有益です。
- the transport of a VPN-ID when establishing an SA (3.1.2)
- SAを確立するときのVPN-IDの輸送（3.1.2）
- 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はそれ自体でデータセキュリティを提供せず、使用されるPPPセキュリティメカニズムはL2TPプロトコル自体には適用されないため、強力なセキュリティを提供するためには、L2TPがIPSECを介して実行する必要があります。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）サービスです。この場合、以下に示すように、2つのCPEデバイスを接続するポイントツーポイントリンクが顧客に提供されます。CPEデバイスをISPノードに接続するために使用されるリンクレイヤータイプは、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（たとえば、ATM VCCやIPトンネルなど）でスタブリンクとIPトンネルを結合するように構成されています。フレームは2つのリンク間で中継されます。たとえば、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)
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.
顧客にとっては、CPEデバイスを相互接続するために単一のATM VCCまたはフレームリレー回路を使用した場合と同じように見え、顧客は、回路の一部が実際に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).
CPEデバイスをISPノードに接続するために使用される2つのリンクは、同じメディアタイプのものである必要はありませんが、この場合、ISPノードは上記のように不透明な方法でトラフィックを処理できません。代わりに、ISPノードは、2つのメディアタイプ（ATMおよびフレームリレーなど）間のインターワーキングデバイスの関数を実行し、LLC/SNAPなどの機能をNLPID変換に実行し、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 Expedited Forwarding Per Hop行動（EF-PHB）の定義で使用されるものとは異なることに注意してください[30]。そのドキュメントでは、VLLは、レイテンシ、低いジッター、保証された帯域幅パスを意味するために使用されます。これは、説明されたPHBを使用して提供できます。したがって、そこに焦点は、主に本質的に一時的なリンク特性にあります。このドキュメントでは、VLLという用語は、特定のQoSメカニズム、Diffservなどの使用を意味するものではありません。代わりに、焦点は主に本質的にトポロジカルなリンク特性にあります（たとえば、リンクの1つのセグメントとして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ベースのVPRNも可能ですが、ここでは具体的には説明しません。ネットワークベースのVPRNでは、対処する必要がある問題の多くは、構成と運用上の問題に関係しています。これは、サービスプロバイダーとサービスユーザーの間の管理責任の分割を考慮する必要があります。
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は、ISPルーター間のIPトンネルのメッシュと、各VPRNノードで受信したトラフィックを適切な宛先サイトに転送するために必要なルーティング機能で構成されています。ISPルーターに接続されているのは、「スタブ」リンクと呼ばれる1つ以上のリンクを介して接続されているCPEルーターです。VPRNのメンバーが接続されている各ISPルーターにVPRN固有の転送テーブルがあります。トラフィックは、ISPルーター間、およびISPルーターと顧客サイト間で転送され、ネットワークレイヤーリーチビリティ情報を含むこれらの転送テーブルを使用して（仮想プライベートLANセグメントタイプのVPN（VPLS）とは対照的です。 - セクション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つ以上のバックアップリンクがある場合があります。「バックドア」という用語は、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エッジルーターが顧客のネットワークの近隣ルーターとして表示され、デフォルトのルートを使用してすべてのトラフィックを送信します。トラフィックを転送するためにセットされたトンネルメッシュは、CPEルーターではなく、ISPエッジルーター間で延びています。実際には、トンネルの確立とメンテナンスとルーティングの構成の負担は、ISPに外部委託されます。さらに、ファイアウォールの提供やQoS処理など、VPNの操作に必要な他のサービスは、多数の不均一なCPEデバイスではなく、少数のISPエッジルーターによって処理できます。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.
VPRNタイプのVPNは、トンネルメッシュがCPEルーターに拡張され、ISPネットワークがレイヤー2接続のみを提供するものとは対照的です。後者のケースは、CPEルーター間のVLLのセットとして実装できます（セクション4.0を参照）、ISPネットワークはレイヤー2ポイントツーポイントリンクのセットを提供するか、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.
VPRNで対処すべき問題には、初期構成、各VPRNにあるリンクのセットのISPエッジルーターによる決定、VPRNにメンバーがいる他のルーターのセット、およびそれぞれを介して到達可能なIPアドレスプレフィックスのセットが含まれます。IPアドレスプレフィックスのセットのCPEルーターによる決定、ISPエッジルーターに転送されるCPEルーター、スタブリーチビリティ情報を正しいISPルーターのセットに広めるために使用されるメカニズム、および使用したトンネルの確立と使用データトラフィックを運びます。また、VPRNについて最初に説明しましたが、これらの問題の多くは後で説明した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ルーターにはISPエッジルーターを指すデフォルトルートがあり、後者はVPRNへの個人トラフィックとインターネットへのその他のトラフィックを操縦し、2つのドメイン間のファイアウォール機能を提供する責任があります。あるいは、顧客サイトでは、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ノード間のトンネルの完全なメッシュで構成されている場合があります。また、最寄りの地域サイトに接続されたリモートオフィスのセットなど、これらの地域のサイトが完全または部分的に接続されているなど、任意のトポロジーである場合があります。メッシュ。IPトンネルを使用するVPRNSを使用すると、完全なメッシュでコストがはるかに少ないです。たとえば、接続されたサイトの各ペアに物理リソース（リースラインなど）を割り当てる必要がある場合、またはトンネリング方法でデバイスに割り当てられるリソースを必要とする場合よりも、エッジルーター（例：フレームリレーDLCIS）を相互接続するために使用されます。完全なメッシュトポロジは、2つのサイト間のトラフィックが3分の1を横断する必要性を排除するため、最適なルーティングを生成します。フルメッシュのもう1つの魅力は、VPRNのトポロジ情報を構成する必要がないことです。代わりに、VPRNのメンバールーターを考えると、トポロジは暗黙的です。VPRN内のISPエッジルーターの数が非常に大きい場合、たとえばサイト間で必要なトンネルの数の増加（nの場合）の増加など、スケーリングの問題のために、完全なメッシュトポロジが適切ではない場合があります。サイトはn（n-1）/2）、またはルーターあたりのルーティングピア数です。ネットワークポリシーは、非フルメッシュトポロジにつながる可能性もあります。たとえば、管理者は、リモートサイト間を直接移動するのではなく、2つのリモートサイト間のトラフィックが中央サイトを通過するようにトポロジを設定することをお勧めします。また、特定のエラー条件下でIPバックボーン全体に部分的な接続のみがあるシナリオに対処する必要があります（たとえば、AはBに到達でき、BはCに到達できますが、Aは直接到達できません）。これは、ポリシールーティングの場合に発生する可能性があります。使用されています。
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シグナル伝達など、オンデマンドで設定された動的リンクである場合があります。動的リンクを使用すると、サブスクライバーを認証し、サブスクライバーがアクセスできる認定リソース（サブスクライバーが参加できるVPRN）を決定する必要があります。サブスクライバーが最初に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]。複数のVPRNは、同じ物理デバイスのセットでインスタンス化される場合があり、同じまたは重複するアドレススペースを使用する場合があります。
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固有の転送テーブルが必要です。
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パケットは通常の方法で（TTL）フィールドを通常の方法で減少させ、VPRN内のルーティングループが発生した場合に無期限に循環することを防ぎます。
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.
また、単一の顧客サイトは複数のVPRNに同時に属し、同じスタブリンクで1つ以上のVPRNとデフォルトのインターネットの両方にトラフィックを送信したい場合があることに注意してください。この問題には多くの可能なアプローチがありますが、これらはこのドキュメントの範囲外です。
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の要件とメカニズムは、以前に多くの異なるドキュメントで議論されています。最初の1つは[10]であり、MPLSネットワークと非MPLSネットワークの両方で同じVPN機能をどのように実装できるかを示しました。他のいくつかについては、以下で簡単に説明します。
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 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).
VPRNメンバーシップと到達可能性の機能を提供するために使用されるメカニズムに関する2つの主要なバリアントがあります - オーバーレイとピギーバック。これらについては、以下のセクション5.3.2、5.3.3および5.3.4で詳しく説明します。オーバーレイモデルの例は、[14]で説明されています。これは、仮想ルーティングとも呼ばれます。各VPNルーティングインスタンスは、他のVPNルーティングインスタンスやバックボーン全体で使用されるルーティングから分離されています。その結果、ルーティングプロトコル（OSPF、RIP2、IS-ISなど）は、他のVPRNまたはバックボーン自体で使用されるルーティングプロトコルとは無関係に、任意の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]は、メンバーシップとリーチ性普及のためのピギーバックアプローチを使用してVPN機能の提供を説明し、この情報はBorder Gateway Protocol 4（BGP）[32]パケットでピギーバックされています。VPNは、BGPポリシーを使用して構築されます。BGPポリシーは、どのサイトが相互に通信できるかを制御するために使用されます。[13]は、MPLS LSP（CR-LDPまたは拡張RSVP）を確立するために使用されるプロトコル上のピギーバックメンバーシップ情報にもBGPを使用し、Piggybacks Reachability情報を使用します。ただし、他の提案とは異なり、この提案では、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.
IETF [16]およびATMフォーラム[17]は、VPN -VPN -IDを識別するために使用されるグローバルに一意の識別子の単一形式で標準化されています。VPN-IDの形式のみが定義されており、セマンティクスや使用法ではありません。目的は、さまざまな目的での使用を許可し、同じ識別子が異なるテクノロジーとメカニズムで使用できるようにすることです。たとえば、VPN-IDをMIBに含めて、管理目的でVPNを特定できます。VPN-IDは、たとえば、トンネルの確立時間でトンネルをVPNに結合するために、コントロールプレーンプロトコルで使用できます。トンネルを横断するすべてのパケットは、特定されたVPNに暗黙的に関連付けられます。VPN-IDは、パケットに関連付けられたVPNのパケットごとの明示的な識別を可能にするために、データプレーンのカプセル化で使用できます。ネットワーク内の異なるテクノロジー（IPやATMなど）を使用してVPNが実装されている場合、同じ識別子を使用して、異なるテクノロジー全体で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の他のスタブリンクをサポートする他のエッジルーターのアイデンティティ、または少なくともルートのいずれかを学習する必要があります。後者の暗黙的なのは、構成されたエッジルーターがこのエッジルーターおよび/またはスタブリンクID情報を使用して、それらの間に適切なトンネルをセットアップできるメカニズムが存在するという概念です。参加エッジルーター間の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のスタブリンクをサポートするエッジルーターのアイデンティティ、およびEdgeルーターごとにVPRNにバインドされた静的スタブリンクのセットは、ディレクトリに構成できます。、いくつかの定義されたメカニズム（例：LightWeight Directory Access Protocol（LDAP）[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.
ディレクトリを使用すると、VPRNメンバーシップ情報を広める前に認可チェックが可能になります。これは、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.
また、すべてのEDGEルーターが新たに新たにアイデンティティを学習するためには、何らかの形のデータベース同期メカニズム（例：ディレクトリのトリガーまたはディレクトリの定期的なポーリング、またはディレクトリによるエッジルーターへの更新情報のアクティブなプッシュ）も必要です。アクティブな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に結合した各静的スタブリンクのIDとともに構成できます。ディレクトリの使用と同様に、このメカニズムにより、完全なメッシュと任意のトポロジの両方を構成できます。集中管理システムを使用したもう1つのメカニズムは、ポリシーサーバーを使用し、一般的なオープンポリシーサービス（COPS）プロトコル[35]を使用して、トンネルを確立するときに使用するトンネル属性などのVPRNメンバーシップとポリシー情報を配布することです。[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.
このメカニズムにより、管理ステーションは厳格な承認管理を課すことができることに注意してください。一方、管理システムの範囲外でエッジルーターを構成することはより困難な場合があります。管理構成モデルは、マネジメントディレクトリがMIBSを使用して、VPRNメンバーシップ情報を参加エッジルーターにプッシュし、その後、またはローカルスタブリンク構成プロセスのいずれかで、VPRNメンバーシップ情報をプッシュできるという点で、ディレクトリメソッドのサブセットと見なすこともできます。
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.
さらに、更新をルーティングに使用して、すべての関連するエッジルーターのみがピギーバック広告を読み取ることができるように、いくつかのセキュリティメカニズムが使用されない限り、このスキームは一般に、パス内のすべてのルーターがこの情報を知ることを許可する必要がある信頼モデルを意味します。ルーティングプロトコルの性質に応じて、ピギーバックは中間ルーター、特に自律システム（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への静的スタブリンクのバインディングなど、VPRNメンバーシップ情報を維持する集中型ディレクトリまたは管理システムがほとんど常にあることに注意してください。ダイナミクスリンクを介してネットワークにアクセスするユーザー向けの認証と承認情報。この情報は、そのような情報の構成をエッジルーターに促進するために必要な追加の手順、および/またはそのような情報へのエッジルーターへのアクセスを促進するために必要な追加の手順が過度に面倒ではないように、何らかの形式のデータベースで構成および保存する必要があります。
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.
スタブサイトの到達可能性には2つの側面があります。VPRNエッジルーターが各スタブサイトで到達可能なVPRNアドレスとアドレスのプレフィックスのセットを決定する手段、およびCPEルーターが各スタブリンクを介して到達可能な宛先に到達可能な宛先を学習する手段です。多くの一般的なシナリオを以下に概説します。いずれの場合も、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ルーターは、ISPエッジルーターへの1つのリンクを介して接続されています。これは、インターネット、接続ではなくVPRNを提供します。
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はRIPであると想定されていますが、IGPである可能性があります。ISPエッジルーターは、セクション5.3.4で説明されているVPRN内の到達可能性メカニズムの1つによって学習するVRPNルートをRIPのこのインスタンスに注入します。RIPのインスタンスはCPEに実行され、VPRN内の到達可能性を学習するために使用されるルーティングプロトコルのインスタンス（RIPもRIPもあっても）が別々であることに注意してください。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エッジルーターは、ケース2のようにCPEデバイスのようにVPRNルートを宣伝します。ただし、ISPエッジルーターとバックドアリンクの両方を介して、同じ宛先に到達可能になりました。バックドアリンクに接続されているCPEルーターが顧客のIGPを実行している場合、バックドアリンクは常に「内部」パスに表示されるため、常に好ましいリンクになりますが、ISPエッジルーターを介して注入される宛先は、「外部」パス（顧客のIGPへ）。この問題を回避するために、顧客がトラフィックがISPネットワークを横断することを望んでいると仮定すると、RIPのインスタンスが実行されるのと同じ方法で、バックドアリンクの両端のCPEルーターの間でRIPの個別のインスタンスを実行する必要があります。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エッジルーターの間で実行して、リーチ性情報を交換できます。これにより、ISPエッジルーターが顧客サイトで到達可能なVPRNプレフィックスを学習できるようになり、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.
このプロトコルインスタンスのルーティングドメインの範囲は、一般にISPエッジルーターとCPEルーターにすぎませんが、顧客サイトがIGPと同じプロトコルを実行している場合、ドメインは顧客サイトに拡張される場合があります。顧客サイトが異なるルーティングプロトコルを実行している場合、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ルーターと関連するISPエッジルーターの間で特定の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から、ISPが共通（すべてのVPRN）内部の到達可能性メカニズムと共通のスタブリンクリーチビリティメカニズムを展開できます。最初のケースでは、ISPエッジルーターに実装されたIGP-IGP境界により、ISPは、誤動作スタブリンクプロトコルインスタンスからVPRN内の到達可能性メカニズムを隔離できます。2番目のケースでは、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 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.
特定の顧客サイトが複数のVPRNに同時に属している場合（またはVPRNとインターネットの両方と同時に通信することを希望する場合、ISP Edgeルーターには、特定のVPRNへのスタブリンクアドレスのプレフィックスを明確にマッピングする手段が必要であることに注意してください。簡単な方法は、vprnごとに複数のスタブリンクを持つことです。また、1つのスタブリンクで複数のVPRNを実行することもできます。これは、特定の分離アドレスプレフィックスが別々のVPRNにマッピングされることを確認する（およびISPエッジルーターを適切に構成する）、または適切なVPN識別子を使用してCPEルーターからルーティング広告をタグ付けすることによって実行できます。たとえば、MPLSがスタブリンクの到達可能性情報を伝えるために使用されている場合、異なるMPLSラベルを使用して、特定のVPRNに割り当てられた分離接頭辞を区別します。いずれにせよ、この調整にはいくつかの管理手順が必要になります。
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エッジルーターを介して管理および割り当てられる可能性があります。アドレス割り当ては、PPPやDHCPなどのプロトコル[37]などのプロトコルを使用して実行できます。たとえば、RADIUSクライアントとして機能し、RADIUSサーバーから使用する顧客のIPアドレスを取得するか、DHCPリレーとして機能し、顧客サイトに中継されているDHCP返信メッセージを調べます。このようにして、エッジルーターは、スタブリンクの到達可能性情報のテーブルを構築できます。これらのアドレス割り当てメカニズムは通常、アドレスを単一のホストに割り当てるために使用されますが、一部のベンダーは、「ミニdhcp」サーバーとして機能し、割り当てされたCPEデバイスでアドレスプレフィックスを割り当てることができる拡張機能を追加しました。顧客サイトのホストのアドレス。
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を実行する場合、LDPを使用して、スタブサイトのプレフィックスのセットをVPRNエッジルーターに伝えることができます。ラベル分布の下流の未承諾モードを使用して、CPEルーターはスタブサイトの各ルートのラベルを配布できます。ただし、この場合、エッジルーターによって実行される処理は、標準ルーティングを介して学習した既存のルートの通常の学習ラベルの通常のケースではなく、LDPを介して新しいルートを学習しているため、通常の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.
このIntra-VPRNルーティングプロトコルは、顧客サイトのIGPまたはIPバックボーンのISPが運営するルーティングプロトコルと関係がないことに注意してください。RIPのような単純なプロトコル、またはOSPFのようなより洗練されたプロトコルのいずれかを使用できるVPRNのサイズとスケールに応じて。Intra-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.
Intra-VPRNルーティングプロトコルが実行されるトンネルが特定のVPNに専用（たとえば、各VPNに異なる多重化フィールドが使用される）に専念する場合、ルーティングプロトコル自体に変更は必要ありません。一方、共有トンネルを使用する場合は、ルーティングプロトコルを拡張して、VPN-IDフィールドをルーティングアップデートパケットに含めるようにして、特定のVPNに関連付けられたプレフィックスセットを許可する必要があります。
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.
リンクReachabilityプロトコルは、ポイントツーポイントリンクを介して接続された2つのノードを許可するプロトコルを意味します。完全なメッシュトポロジを考えると、各エッジルーターは、リンクリーチビリティプロトコル、たとえばMPLS CR-LDPのバリエーションを実行できます。トンネルを越えてVPRNの各ピアエッジルーターへのバリエーションは、VPN-IDと各VPRNの到達可能性情報を運びます2つのエッジルーターの間をトンネルを横切って走ります。VPRNメンバーシップ情報がすでにエッジルーターに配布されている場合、近隣のセットがすでに知られているため、従来のルーティングプロトコルの隣接発見の側面は必要ありません。TCP接続を使用して、隣人を相互接続して信頼性を提供することができます。このアプローチは、VPRNあたりの実行ルーティングプロトコルインスタンスの処理の負担を軽減する可能性があり、複数のVPRNをサポートするエッジルーターのセットを接続するために共有トンネルメカニズムを使用する場合、特に利点がある場合があります。
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.
リンクReachabilityプロトコルを開発する別のアプローチは、IBGPに基づいていることです。リンクReachabilityプロトコルによって解決する必要がある問題は、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.
リンクリーチビリティプロトコルを使用すると、完全なメッシュトポロジをサポートするのが簡単です。各エッジルーターは、独自のローカルリーチビリティ情報を他のすべてのルーターに伝えますが、他のルーターから受け取った情報を再配布しません。ただし、任意のトポロジをサポートする必要があると、ループを回避するためのメカニズムを実装する必要があるため、リンクReachabilityプロトコルは完全なルーティングプロトコルに発展する必要があり、これに対処するために別のルーティングプロトコルを再発明することにはほとんど利点がありません。トンネル環境でも部分的に接続されたメッシュが必要になる可能性があるいくつかの理由については、セクション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.
トンネルメッシュをセットアップする1つのアプローチは、ポイントツーポイント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ラベル分布メカニズムは、MPLSラベルの特定のセットを特定の出力ポイント（つまり、エッジルーターのスタブリンク）でサポートする特定のVPRNアドレスプレフィックスと関連付けるために使用でき、したがって、他のエッジルーターが特定の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の魅力の1つは、代替トンネリングメカニズムよりも各エッジルーター内での処理が少ない場合があることです。これは、MPLSネットワーク内のデータセキュリティが、フレームリレーなどの接続指向ネットワークと同様に、明示的なラベルバインディングに暗黙的であるという機能です。したがって、これにより、データセキュリティに関する顧客の懸念が軽減されるため、プロセッサの集中的なセキュリティメカニズムが必要です（IPSECなど）。ただし、MPLSには他の潜在的なセキュリティ上の懸念があります。認証、機密性、非repudiationなどのセキュリティ機能に直接サポートされていないことは、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.
これまでの議論は、スタブルーターが1つの1つのVPRNエッジルーターに接続されていると暗黙的に想定しています。一般に、この制限は、信頼性やその他の理由でマルチホミングに対する一般的な市場の関心を考えると、VPRN操作に変更を加えることなくリラックスできる必要があります。特に、スタブルーターが複数の冗長リンクをサポートしている場合は、同じVPRNエッジルーター、または2つ以上の異なるVPRNエッジルーターに接続されたリンクを使用して、任意の時間で1つの動作を行う場合、スタブリンクの到達可能性メカニズムは、アクティブリンクの損失とバックアップリンクのアクティブ化を発見します。前者の状況では、以前に接続された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.
マルチキャストおよびブロードキャストトラフィックは、エッジレプリケーションまたはバックボーンのネイティブマルチキャストサポートのいずれかによって、VPRN全体でサポートできます。これらの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イントラマルチキャストトラフィックをマッピングする場所です。Intra-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内のマルチキャストグループアドレスをそのVPRNのVPN-IDとプレフィックスに入れてから、これらを再分配することができ、本質的にこのVPN-ID/INTRA-VPRNマルチキャストアドレスTupleを通常のマルチキャストアドレスとして扱います。前述のように、ユニキャストの到達可能性の場合のように、ルーティングプロトコル。次に、MPLSマルチキャストラベル分布メカニズムを使用して、適切なマルチキャストLSPを設定して、特定のマルチキャストグループアドレスをサポートする各VPRN内のサイトを相互接続することができます。ただし、これには、各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トンネルメカニズムには、ネイティブのマルチキャストサポートがありません。IPマルチキャストグループアドレスをVPRN全体に割り当てることにより、そのようなトンネルメカニズムを拡張し、バックボーンマルチキャストパケット内にカプセル化されたVPRN内マルチキャストトラフィックを分散することにより、そのようなトンネルメカニズムを拡張することが可能であることが証明される場合があります。Edge 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の安全なマルチキャストグループ（SMUG）は、プロトタイプソリューションを開発するために設定されており、標準化のために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.
何らかの形のVPRN機能をサポートするために開発されたさまざまな提案は、VPNメンバーシップおよび/または到達可能性情報を配布するためのルーターピギーバックアプローチを利用するグループ（[13]、[15]）と、およびそれを使用したものと、2つのグループに広く分類できます。仮想ルーティングアプローチを使用します（[12]、[14]）。場合によっては、説明されているメカニズムは、単なるIPではなく、特定のインフラストラクチャ（MPLSなど）の特性に依存しています。
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バックボーン上で複数の管理に及ぶ相互運用可能なVPRNをサポートする一連のプロトコルとメカニズムの基礎を提供します。必要な他の主要な機能性 - 顧客の到達可能性情報の学習と配布は、プロトコル拡張を必要とせずに、標準のルーティングプロトコルのインスタンスによって実行できることに注意してください。
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.
今日、多くのコーポレートネットワークは、PSTNを介して作成されたダイヤル接続を介してリモートユーザーへのアクセスを許可しています。ユーザーは、Access Networkを介してネットワークアクセスサーバーにPPP接続を設定しています。[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は、L2TP Access Concencorator（LAC）からリモートL2TPネットワークサーバー（LNS）へのユーザーPPPセッションの拡張を可能にするレイヤー2トンネリングプロトコル（L2TP）[8]を開発しました。L2TPプロトコル自体は、2つの初期プロトコル、レイヤー2転送プロトコル（L2F）[45]、およびポイントツーポイントトンネリングプロトコル（PPTP）[46]に基づいており、これは2つのまったく異なるシナリオに反映されています。どのL2TPを使用できるか - 強制トンネリングと自発的トンネリングについては、以下でさらにセクション6.2および6.3で説明します。
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.
このドキュメントは、IPネットワーク（UDPを使用）を介した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は、単一のリンクを介して異なるユーザーからの複数の呼び出しの多重化に固有のサポートを持っています。同じ2つのIPエンドポイントの間には、トンネルIDで識別される複数のL2TPトンネルと、セッションIDで識別されるトンネル内の複数のセッションがあります。
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].
ユーザーからのPPPの透明な拡張を許可することにより、LACを介してLNSまで、L2TPは、接続セットアップとデータ転送の両方に関して、通常のPPP接続で使用される可能性があります。ただし、これはL2TP制御プロトコル自体のセキュリティを提供しません。この場合、L2TPは、IPバックボーン[47]、[48]、または非IPバックボーンの関連メカニズム[49]を介して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].
L2TPとユーザー認証および承認のためのAAAシステムとの相互作用は、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.
Keepaliveプロトコルは、トンネルの停止とトンネルの不活性の長期間を区別できるように、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の間のパスで使用されているMTUの知識がある場合、LACまたはLNSは断片化を排除するためにPPPを介して交渉された最大受信ユニット（MRU）を調整することができることに注意してください。この目的のために、L2TPトンネルがIPフレームを輸送する場合にMTU発見の使用を許可する提案があります[52]。
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トラフィックを運ぶために使用する必要があります。これにより、UDP、L2TP、およびPPPヘッダーを搭載したデータプレーンと、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として機能するネットワークノード（ダイヤルまたはネットワークアクセスサーバー）がLACとして機能するシナリオを指します。この操作は、PPPセッションをLACに開始するユーザーに対して透明です。これにより、ユーザーがアクセスできるサイトからダイヤルコールを終了するために使用されるモデムプールの場所および/または所有権の分離が可能になります。このシナリオのサポートは、L2F仕様の元の意図であり、その上にL2TP仕様が基づいていました。
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.
可能な限り多くの異なる展開シナリオがあります。下の図に示されている一例は、サブスクライバーのホストがLACとして機能するNASにダイヤルし、IPネットワーク（インターネットなど）を横切ってLNSとして機能するゲートウェイにトンネルを付けます。ゲートウェイは、コーポレートネットワークへのアクセスを提供し、顧客がLNS機能のメンテナンスをISPに外部委託した場合、コーポレートネットワーク自体のデバイスであるか、ISPエッジルーターになる可能性があります。別のシナリオは、ISPがL2TPを使用して、インターネットへのアクセスをサブスクライバーに提供する場所です。サブスクライバーのホストは、LACとして機能するNASにダイヤルし、アクセスネットワークを横切ってLNSとして機能するISPエッジルーターにトンネルを付けられます。このISPエッジルーターは、サブスクライバートラフィックをインターネットに送ります。さらに他のシナリオは、ISPがL2TPを使用して、VPRNへのアクセスをサブスクライバーに提供するか、VPRNとインターネットの両方への同時アクセスを提供する場合です。
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.
強制トンネリングは、元々、卸売ダイヤルサービスをサポートするネットワークアクセスサーバーの展開を目的としており、エンタープライズが独自のダイヤルサーバーを展開する必要性を妨げると同時に、共通の施設を介してリモートダイヤルアクセスを可能にしました。このもう1つの例は、ISPがアクセスネットワークプロバイダー（米国のローカルエクスチェンジキャリア（LEC）など）への独自のダイヤル接続を外部委託し、ISPが独自のダイヤルサーバーを維持する必要性を削除し、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のアイデンティティを決定できるようにする必要があります。[50]に記載されているように、これらの側面には、呼び出しパーティー番号や、完全に資格のあるドメイン名（FQDN）などの呼び出し当事者の属性を含むアクセスネットワークの何らかの側面を通じて決定されるように、ユーザーIDを含めることができます。PPP認証中に請求されたID。
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.
また、2つのL2TPトンネルを接続することも可能です。これにより、LACはこの最初のLACのLNSとして機能し、最終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.
自発的なトンネルとは、以下に示すように、中間ネットワークノードからの関与がなく、ホストに発信するトンネルを使用して個々のホストがリモートサイトに接続する場合を指します。その一部がL2TPに組み込まれているPPTP仕様は、自発的なトンネルモデルに基づいていました。
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がホストに配置できる限り、自発的トンネルをサポートしています。このようなホストには2つのIPアドレスがあります。1つはLAC -LNS IPトンネル用で、もう1つはホストが接続しているネットワークに通常PPPを介して割り当てられています。自発的トンネリングにL2TPを使用する利点は、PPPが使用する既存の認証およびアドレス割り当てメカニズムを変更せずに再利用できることです。たとえば、LNSにはRADIUSクライアントを含め、RADIUSサーバーと通信してPPP PAPまたはCHAP Exchangeを認証し、IPアドレスや使用するDNSサーバーのリストなどのホストの構成情報を取得することもできます。この情報は、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を使用すると、たとえば、次のスタックで実行されることを意味します。
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.
[58]では、次のスタックを使用して、IPSECのみが頭上を減らすために使用されることが提案されています。
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 Edgeデバイス、またはエンタープライズサイトに接続されたプロバイダーエッジルーターのいずれかで終了します。ホストのIPアドレス指定には2つの可能性があります。L2TPケースと同様の方法で、2つのIPアドレスを使用できます。あるいは、ホストは、トラフィックをエンタープライズネットワークに転送する前に、ゲートウェイがネットワークアドレス変換（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の潜在的な問題のもう1つの領域は、L2TP仕様自体で説明されているように、IPバックボーン上にL2TPトンネルを介して実装されたリンクレイヤーの特性がシリアルライン上で実行されるリンクレイヤーとはまったく異なるという事実によるものです。たとえば、選択されていないPPPパラメーターは、特に圧縮が使用されている場合、頻繁なリセットとタイムアウトにつながる可能性があります。これは、L2TPトンネルがパケットを誤って注文する可能性があり、静かにパケットをドロップする可能性があるためですが、どちらも通常シリアルラインで発生しません。ネットワークの混雑により、一般的なパケット損失率も大幅に高くなる可能性があります。L2TPヘッダーのシーケンス番号フィールドを使用すると、誤った順序付けの問題に対処し、LACとLNSがPPPエンドポイントと一致する場合、自発的なトンネルのように、シーケンス番号フィールドを使用して、ドロップされたパケットを検出することもできます。使用中の圧縮エンティティに適切な兆候を渡します。これは通常、圧縮履歴を両端で同期させるためにそのような知識を必要とします。（実際、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によってサポートされていません。リモートアクセスの場合、最も一般的な既存のユーザー認証メカニズムは、ユーザーとアクセスサーバーの間でPPPを使用し、Accessサーバーと認証サーバー間の半径を使用することです。この場合に発生する認証交換、例えばPAPまたはChap Exchangeは非対称です。また、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はマシン認証を強力にサポートしていますが、ユーザー認証に対するサポートは限られており、非対称ユーザー認証のサポートはありません。ユーザーのパスワードを使用して、Presharedキーとして使用されるキーを導き出すことができますが、これは、ユーザーが固定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.
サポートする必要があるPPP機能のもう1つの側面は、IP以外のネットワークレイヤープロトコルを携帯する必要がある可能性があるため、IPSecを介したブリッジングをサポートするために必要なリンクレイヤープロトコル（イーサネットなど）を運ぶ必要があるため、マルチプロトコル操作です。これについては、セクション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.
Legacyユーザー認証とリモートアクセス環境でのホスト構成機能をサポートする方法は、現在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ベースのダイヤルモデルは、接続指向のダイヤルアクセスネットワークに直接接続されたホストを想定しています。DSLなどの新しいアクセス技術に関する最近の研究は、既存のAAAシステムの再利用を可能にするために、このモデル[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.
L2TPをイーサネット上に拡張するために、多くの提案（[56]など）が作成されており、PPPセッションがネットワークホストからネットワークまで、直接接続されたホストとほぼ同じ方法で実行できます。
6.4.2 Extension of PPP Directly to Hosts:
6.4.2 ホストへのPPPの直接拡張：
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.
トポロジー的および操作的にVPLは、各VPLSエッジノードがネットワークレイヤー転送ではなくリンクレイヤーブリッジングを実装することを除いて、VPRNと本質的に同等であると最も簡単にモデル化できます。そのため、以前に説明したVPRNトンネルおよび構成メカニズムのほとんどは、ネットワークレイヤー、パケット、およびアドレス指定情報ではなく、リンクレイヤーに対応するための適切な変更を備えたVPLSにも使用できます。次のセクションでは、VPLSをサポートするために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など）を使用します。VPRNについて前述した同じセットのマルチキャストトンネルメカニズムのセットは、VPLSにも適用されますが、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エッジノードでの転送の性質とは無関係です。そのため、VPRN構成について議論されたVPNメンバー構成と普及のメカニズムは、VPLS構成にも適用できます。また、VPRNと同様に、各VPLSエッジノードでのピアノードの構成を制御することにより、VPLSのトポロジーを簡単に操作できます。ただし、2つのVPLSノード間のトラフィックが別のVPLSノードを通過する必要性を排除するために、典型的なVPLSが完全にメッシュ化される可能性があります。これにより、ループ予防のためにスパニングツリープロトコル[65]を使用する必要があります。
A VPLS can support either bridges or routers as a CPE device.
VPLは、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内のノードを使用してルーターのピアリングを必要とせずに、VPLを互いに透過的に透過して覗き込みます。VPRNのフルメッシュトポロジに適用される同じスケーラビリティの問題は、この場合にも適用されます。これは、ISP Edgeデバイスが集約点として機能しなくなっているため、ピアリングルーターの数が潜在的に大きくなっていることだけです。
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サイトとVPL自体を網羅しています。この場合、パケットの洪水の必要性と、ブリッジドメインのトポロジの変化が局所化されていないが、ドメイン全体に表示されるという事実により、重要なスケーラビリティの制約があります。このように、このシナリオは一般に、不可能なプロトコルのサポートにのみ適しています。
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.
この場合、スタブリンク全体でVPLとの間で送信されたパケットは、リンクレイヤーフレームであり、適切なアクセスリンクのカプセル化があります。最も一般的なケースは、ATMなどの特定のアクセステクノロジーに適したカプセル化を使用して、CPEブリッジをVPLSエッジノードに接続するイーサネットフレームである可能性があります。そのようなフレームは、レイヤー2でVPLSで使用されるトンネルに転送されます。前述のように、これは、そのようなリンクレイヤーフレームを輸送できる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ルーターのリンクレイヤーアドレスに向けられた、スタブリンク全体のVPLとの間のリンクレイヤーパケットを送信します。ただし、以下で説明するように、ルーター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セグメントで動作するマルチネットは可能ですが、はるかに一般的ではありません）。フレームは、リンクレイヤーアドレスに基づいてVPLを介して転送されます。IEEE Macアドレス - 個々のホストに関連付けられています。VPLは、ホストネットワークアドレスをそれぞれのリンクアドレスにマッピングするために使用されるアドレス解像度メカニズムに通常使用されるものなど、ブロードキャストトラフィックをサポートする必要があります。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.
単一のネットワークレイヤーサブネットは、通常、VPL全体でルーターCPEデバイスを相互接続するために使用されます。各CPEルーターの背後には、異なるネットワークレイヤーサブネットのホストがあります。CPEルーター次のホップネットワークレイヤーアドレスをルーターピアのリンクレイヤーアドレスにマッピングして、VPLにパケットを転送します。ブリッジケースと同様に、リンクレイヤーのカプセル化が使用されます。最も一般的にイーサネットです。
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ノードがルーターである場合、VPLSの制約されたアドレス指定スペースのために、通常のMacアドレス指定とは異なるアドレススペースを使用するカプセルを使用することが可能かもしれません。。たとえば、[11]、MPLSネットワークを介したVPLSの提案されたメカニズム、MPLS上のVPRNサポートに関する以前の作業を活用して[38]を参照してください[38]。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アドレス学習である可能性があります。そのため、上記で説明したように、放送メカニズムを洪水にするためのブロードキャストメカニズムが必要になるが、明示的なVPLSINTRA-VPLSリーチビリティプロトコルは必要ありません。一般に、VPLSトポロジがVPLSエッジノードが他のVPLSエッジノード間のトランジットトラフィックに使用されないような場合、VPLSトポロジがVPLSエッジノードが使用されないような場合、VPLSエッジノード間のスパニングツリープロトコルも実装する必要がないことを証明する必要はない場合があります。完全なメッシュ接続とトランジットの両方が明示的に排除されます。一方、CPEブリッジは、VPLを介した接続性をバイパスする「バックドア」パスから保護するために、スパニングツリープロトコルを実装することができます。
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 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.
この場合、標準のブリッジング手法も使用できます。さらに、このようなVPLの小さなリンク層アドレス空間は、CPEルーター間の明示的なリンク層ルートを備えた他の手法を可能にする場合があります。[11]たとえば、すべてのCPE LSRの間に、新しいCPEルーターをVPLに挿入すると、MPLS LSPがセットアップされることを提案します。これにより、パケットの洪水の必要性が排除されます。より一般的なケースでは、スタブリンクの到達可能性メカニズムを使用してVPLSエッジノードを構成するために使用された場合、それらに接続されたCPEルーターのリンクレイヤーアドレスで、VPRNについて説明したVPN内到達可能性メカニズムの修正を使用して伝播することができます。互いにvplsエッジノードへのこの情報。これにより、洪水なしにVPLを横切るパケット転送が可能になります。
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.
VPRNとVPLSの間には大きな共通性があり、可能であれば、開発と構成の複雑さを減らすために、この類似性を悪用する必要があります。特に、VPLSは、VPLSの特定の特性を反映するためにのみ変更を加えて、同じトンネルとメンバーシップの構成メカニズムを利用する必要があります。
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を確立するときのVPN-IDの輸送（3.1.2）
- 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.
Nortel NetworksのAnthony Allesのおかげで、このドキュメントの生成に関する貴重な支援と、このドキュメントの初期バージョンが基づいている資料の多くを開発したことに感謝します。彼の有益なレビューコメントをしてくれたJoel Halpernにも感謝します。
[1] ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000, January 1995.
[1] ATMフォーラム。「ATM 1.0を超えるLANエミュレーション」、AF-Lane-0021.000、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[6] Perkins、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] Hanks、S.、Li、T.、Farinacci、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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G.およびB. Palter、「レイヤー2トンネルプロトコル "L2TP" "、RFC 2661、1999年8月。
[9] Rosen, E., et al., "Multiprotocol Label Switching Architecture", Work in Progress.
[9] Rosen、E.、et al。、「Multiprotocol Label Switching Architecture」、Work in Progress。
[10] Heinanen, J., et al., "MPLS Mappings of Generic VPN Mechanisms", Work in Progress.
[10] Heinanen、J.、et al。、「一般的なVPNメカニズムのMPLSマッピング」、進行中の作業。
[11] Jamieson, D., et al., "MPLS VPN Architecture", Work in Progress.
[11] Jamieson、D.、et al。、「MPLS VPN Architecture」、Work in Progress。
[12] Casey, L., et al., "IP VPN Realization using MPLS Tunnels", Work in Progress.
[12] Casey、L.、et al。、「MPLSトンネルを使用したIP VPN実現」、進行中の作業。
[13] Li, T. "CPE based VPNs using MPLS", Work in Progress.
[13] Li、T。「MPLSを使用したCPEベースのVPN」が進行中です。
[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] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[16] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[16] Fox、B。およびB. Gleeson、「仮想プライベートネットワーク識別子」、RFC 2685、1999年9月。
[17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM Forum, af-mpoa-0129.000.
[17] Petri、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] Harkins、D。およびC. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[19] Calhoun, P., et al., "Tunnel Establishment Protocol", Work in Progress.
[19] Calhoun、P.、et al。、「トンネル確立プロトコル」、進行中の作業。
[20] Andersson, L., et al., "LDP Specification", Work in Progress.
[20] Andersson、L.、et al。、「LDP仕様」、作業進行中。
[21] Jamoussi, B., et al., "Constraint-Based LSP Setup using LDP" Work in Progress.
[21] Jamoussi、B.、et al。、「LDPを使用した制約ベースのLSPセットアップ」が進行中の作業。
[22] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", Work in Progress.
[22] Awduche、D.、et al。、「LSPトンネルのRSVPへの拡張」、進行中の作業。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[23] Kent、S。、およびR. Atkinson、「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] Perez、M.、Liaw、F.、Mankin、A.、Hoffman、E.、Grossman、D。and A. Malis、「ATM上のIPのサポート」、RFC 1755、1995年2月。
[26] Malkin, G. "RIP Version 2 Carrying Additional Information", RFC 1723, November 1994.
[26] マルキン、G。「追加情報を運ぶRIPバージョン2」、RFC 1723、1994年11月。
[27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[27] Moy、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.、Pereira、R。、およびM. Thomas、「IPペイロード圧縮プロトコル（IPComp）」、RFC 2393、1998年12月。
[29] Duffield N., et al., "A Performance Oriented Service Interface for Virtual Private Networks", Work in Progress.
[29] Duffield N.、et al。、「仮想プライベートネットワークのパフォーマンス指向サービスインターフェイス」、進行中の作業。
[30] Jacobson, V., Nichols, K. and B. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[30] Jacobson、V.、Nichols、K。およびB. Poduri、「迅速な転送PHB」、RFC 2598、1999年6月。
[31] Casey, L., "An extended IP VPN Architecture", Work in Progress.
[31] Casey、L。、「拡張IP VPNアーキテクチャ」、進行中の作業。
[32] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[32] Rekhter、Y。、およびT. Li、「A Border Gateway Protocol 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] Grossman、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] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[35] Boyle, J., et al., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[35] Boyle、J.、et al。、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、2000年1月。
[36] MacRae, M. and S. Ayandeh, "Using COPS for VPN Connectivity" Work in Progress.
[36] Macrae、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. Rosen、「MPLSによるVPNサポート」は、進行中の作業です。
[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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and L. wei、 "Protocol Independent Multicast-Sparseモード（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.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[41] Fenner, W., "IGMP-based Multicast Forwarding (IGMP Proxying)", Work in Progress.
[41] Fenner、W。、「IGMPベースのマルチキャスト転送（IGMPプロキシ）」、進行中の作業。
[42] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[42] Wallner、D.、Harder、E。and R. Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、RFC 2627、1999年6月。
[43] Hardjono, T., et al., "Secure IP Multicast: Problem areas, Framework, and Building Blocks", Work in Progress.
[43] Hardjono、T.、et al。、「Secure IP Multicast：問題領域、フレームワーク、およびビルディングブロック」、進行中の作業。
[44] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[44] Rigney、C.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[45] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[45] Valencia、A.、Littlewood、M。and T. Kolar、 "Cisco Layer Two Forwarding（Protocol）" 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.、Pall、G.、Verthein、W.、Taarud、J.、Little、W。and G. Zorn、「ポイントツーポイントトンネルプロトコル（PPTP）」、RFC 2637、1999年7月。
[47] Patel, B., et al., "Securing L2TP using IPSEC", Work in Progress.
[47] Patel、B.、et al。、「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] Calhoun、P.、et al。、「非IPネットワークの2つのトンネリングプロトコル "L2TP"セキュリティ拡張機能 ""レイヤー進行中。
[50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS", Work in progress.
[50] Aboba、B。and Zorn、G。
[51] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[51] Aboba、B。およびG. Zorn、「ローミングプロトコルを評価するための基準」、RFC 2477、1999年1月。
[52] Shea, R., "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in Progress.
[52] Shea、R。、「L2TP-Over-IP Path MTU Discovery（L2TPMTU）」、進行中の作業。
[53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[53] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（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] Richards、C。and K. Smith、「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] Calhoun、P。and K. Peirce、「レイヤー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] Gupta、V。、「IPSECを使用してインターネット上のセキュア、リモートアクセス」は進行中です。
[59] Pereira, R., et al., "The ISAKMP Configuration Method", Work in Progress.
[59] Pereira、R.、et al。、「ISAKMP構成法」、作業進行中。
[60] Pereira, R. and S. Beaulieu, "Extended Authentication Within ISAKMP/Oakley", Work in Progress.
[60] Pereira、R。およびS. Beaulieu、「Isakmp/Oakley内での拡張認証」、進行中の作業。
[61] Litvin, M., et al., "A Hybrid Authentication Mode for IKE", Work in Progress.
[61] Litvin、M.、et al。、「IKEのハイブリッド認証モード」、進行中の作業。
[62] Kelly, S., et al., "User-level Authentication Mechanisms for IPsec", Work in Progress.
[62] Kelly、S.、et al。、「IPSecのユーザーレベルの認証メカニズム」、進行中の作業。
[63] Patel, B., et al., "DHCP Configuration of IPSEC Tunnel Mode", Work in Progress.
[63] Patel、B.、et al。、「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.、Carrel、D.、Simone、D。、およびR. Wheeler、「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/IEE STD 802.1d、1993年版。
Bryan Gleeson Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
ブライアングリーソンノーテルネットワーク4500グレートアメリカパークウェイサンタクララCA 95054 USA
Phone: +1 (408) 548 3711
EMail: bgleeson@shastanets.com
Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland
Juha Heinanen Telia Finland、Inc。Myyrmaentie 2 01600 Vantaa Finland
Phone: +358 303 944 808
EMail: jh@telia.fi
Arthur Lin Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
アーサー・リン・ノーテルネットワーク4500グレートアメリカパークウェイサンタクララCA 95054 USA
Phone: +1 (408) 548 3788
EMail: alin@shastanets.com
Grenville Armitage Bell Labs Research Silicon Valley Lucent Technologies 3180 Porter Drive, Palo Alto, CA 94304 USA
グレンビルアーミテージベルラボスリサーチシリコンバレールーセントテクノロジーズ3180ポータードライブ、パロアルト、カリフォルニア州94304 USA
EMail: gja@lucent.com
Andrew G. Malis Lucent Technologies 1 Robbins Road Westford, MA 01886 USA
Andrew G. Malis Lucent Technologies 1 Robbins Road Westford、MA 01886 USA
Phone: +1 978 952 7414
EMail: amalis@lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。