RFC2764 日本語訳
2764 A Framework for IP Based Virtual Private Networks. B. Gleeson, A.Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. (Format: TXT=163215 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
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
コメントを求めるワーキンググループB.グリーソンの要求をネットワークでつないでください: 2764年のA.リンカテゴリ: 情報のノーテルはG.アーミテージA.Malisルーセントテクノロジーズ2000年2月にJ.Heinanen Teliaフィンランドをネットワークでつなぎます。
A Framework for IP Based Virtual Private Networks
IPのためのフレームワークは仮想私設網を基礎づけました。
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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.
このドキュメントは、Virtual兵士のNetworks(VPNs)のためにIPバックボーンに出くわしながら、フレームワークについて説明します。 それは、VPNsの様々な異なったタイプ、彼らのそれぞれの要件について議論して、存在か提案された仕様を使用することでVPNの各タイプを実装するのに使用できた特定のメカニズムを提案します。 このドキュメントの目的は共同利用できるVPNソリューションの広範囲の展開に必要である仕様のフルセットを開発するために関連するプロトコル開発のためのフレームワークとして機能することです。
Gleeson, et al. Informational [Page 1] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[1ページ]のRFC2764IP
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
1.0序論… 4 2.0 VPNアプリケーションと実装要件… 5 2.1 一般VPN要件… 5 2.1 .1 パケット輸送について不透明にしてください: ................................. 6 2.1 .2データ機密保護… 7 2.1 .3 サービスの質保証… 7 2.1 .4トンネリングメカニズム… 8 2.2のCPEとネットワークはVPNsを基礎づけました… 8 2.3のVPNsとエクストラネット… 9 3.0 VPNトンネリング… 10 3.1 VPNsのためのトンネリングプロトコル要件… 11 3.1 .1 多重送信します… 11 3.1 .2 合図プロトコル… 12 3.1 .3データ機密保護… 13 3.1 .4 Multiprotocol輸送… 14 3.1 .5 配列を縁どってください… 14 3.1 .6 メインテナンスにトンネルを堀ってください… 15 3.1 .7 大きいMTUs… 16 3.1 .8 トンネルオーバーヘッドの最小化… 16 3.1 .9 流れと混雑は制御されます… 17 3.1 .10のQoS/輸送管理… 17 3.2の推薦… 18 4.0 VPNはタイプします: 仮想の専用線… 18 5.0 VPNはタイプします: 仮想の私設の発送されたネットワーク… 20 5.1 VPRNの特性… 20 5.1 .1トポロジー… 23 5.1 .2 扱います。 24 5.1 .3 進めます。 24 5.1 .4 複数の同時発生のVPRNの接続性… 24 5.2 VPRNは仕事を関係づけました… 24 5.3 VPRNジェネリック要件… 25 5.3 .1VPN識別子… 26 5.3 .2VPN会員資格情報構成… 27 5.3 .2 .1ディレクトリルックアップ… 27 5.3 .2 .2の明白な管理構成… 28 5.3 .2 .3 ルーティング・プロトコルでは、便乗します… 28 5.3 .3 リンク可到達性情報を引き抜いてください… 30 5.3 .3 .1 リンク接続性シナリオを引き抜いてください… 30 5.3 .3 .1 .1の二元的なVPRNとインターネットの接続性… 30 5.3 .3 .1 .2VPRNの接続性専用… 30 5.3 .3 .1 .3は接続性をMultihomedしました… 31 5.3 .3 .1 .4裏口はリンクされます… 31 5.3 .3 .1ルーティング・プロトコルインスタンス… 31 5.3 .3 .2構成… 33 5.3 .3 .3 ISPの管理されたアドレス… 33 5.3 .3 .4MPLSがプロトコルと分配をラベルします… 33
Gleeson, et al. Informational [Page 2] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[2ページ]のRFC2764IP
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
5.3.4 イントラ-VPN可到達性情報… 34 5.3 .4 .1ディレクトリルックアップ… 34 5.3 .4 .2の明白な構成… 34 5.3 .4 .3 ローカルのイントラ-VPRNルート設定具体化… 34 5.3 .4 .4 可到達性プロトコルをリンクしてください… 35 5.3 .4 .5 IPバックボーンルーティング・プロトコルでは、便乗します… 36 5.3 .5 トンネリングメカニズム… 36 5.4はスタッブルータをMultihomedしました… 37 5.5 マルチキャストサポート… 38 5.5 .1 模写を斜めに進ませてください… 38 5.5 .2 ネイティブのマルチキャストサポート… 39 5.6の推薦… 40 6.0 VPNはタイプします: 仮想の私設のダイヤルネットワーク… 41 6.1 L2TPは特性について議定書の中で述べます… 41 6.1 .1 多重送信します… 41 6.1 .2 合図します… 42 6.1 .3データ機密保護… 42 6.1 .4 Multiprotocol輸送… 42 6.1 .5 配列します。 42 6.1 .6 メインテナンスにトンネルを堀ってください… 43 6.1 .7 大きいMTUs… 43 6.1 .8 オーバーヘッドにトンネルを堀ってください… 43 6.1 .9 流れと混雑は制御されます… 43 6.1 .10のQoS/輸送管理… 43 6.1 .11その他… 44 6.2 強制的なトンネリング… 44 6.3 自発的のTunnels… 46 6.3 L2TPの自発的のTunnelsの使用の.1冊… 46 6.3 IPSecの自発的のTunnelsの使用の.2冊… 48 6.4はホストサポートをネットワークでつなぎました… 49 6.4 .1 L2TPを通したホストへのpppの拡大… 49 6.4 .2 直接ホストへのpppの拡大: ...................... 49 6.4 .3 IPSecの使用… 50 6.5の推薦… 50 7.0 VPNはタイプします: 仮想の個人的なLANセグメント… 50 7.1のVPLS要件… 51 7.1 .1 トンネリングプロトコル… 51 7.1 .2マルチキャストと放送サポート… 52 7.1の.3VPLS会員資格構成とトポロジー… 52 7.1 .4 CPEはノード種別を引き抜きます… 52 7.1 .5 リンクパケットカプセル化を引き抜いてください… 53 7.1 .5 .1 CPEをブリッジしてください… 53 7.1 .5 .2 ルータCPE… 53 7.1 .6のCPEアドレシングとアドレス解決… 53 7.1 .6 .1 CPEをブリッジしてください… 53 7.1 .6 .2 ルータCPE… 54 7.1 .7VPLSがノード推進と可到達性メカニズムを斜めに進ませます… 54 7.1 .7 .1 CPEをブリッジしてください… 54
Gleeson, et al. Informational [Page 3] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[3ページ]のRFC2764IP
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
7.1.7.2 ルータCPE… 54 7.2の推薦… 55 推薦の8.0概要… 55 9.0 セキュリティ問題… 56 10.0の承認… 56 11.0の参照箇所… 56 12.0 情報を書いてください… 61 13.0 完全な著作権宣言文… 62
1.0 Introduction
1.0 序論
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.
このドキュメントは、Virtual兵士のNetworks(VPNs)のためにIPバックボーンに出くわしながら、フレームワークについて説明します。 それは、VPNsの様々な異なったタイプ、彼らのそれぞれの要件について議論して、存在か提案された仕様を使用することで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バックボーン施設のむこうにあります。 VPNsの広範囲の展開は妨げられて、共同利用できる実装の不足によって、しかしながら、どれが定義での一般協定の不足と広いバラエティーの解決の上のVPNsと混乱の範囲からそれを順番に引き出すかは、VPNという用語によってすべて説明されています。 このドキュメントの文脈では、VPNは単に'IP施設を使用する個人的なワイドエリアネットワーク(WAN)施設のエミュレーション'(公共のインターネット、またはプライベートアイピーバックボーンを含んでいる)と定義されます。 そういうものとして、VPNsのWANのタイプがあるのと同じくらい多くのタイプ、したがって、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
本書ではVPNは接続性オブジェクトとしてモデル化されます。 ホストはVPNに付けられるかもしれません、そして、同じ方法で一緒にインタコネクトされていて、ホストが今日物理ネットワークに付くとき、VPNsはインタコネクトするかもしれません、そして、物理ネットワークは一緒に(ブリッジか例えば、ルータで)インタコネクトされます。 アドレシングや、推進メカニズムや、学習や広告の可到達性などのようにサービスの質(QoS)をネットワークでつなぐ多くの局面、セキュリティ、およびfirewallingは物理的で仮想のネットワークとVPNsの議論で起こる多くの問題の両方の向こう側の一般的なソリューションに物理ネットワークで実装されるようにそれらの問題があるダイレクトアナログを持たせます。 VPNsの導入はネットワークを再発明するか、または既存の物理ネットワークと共にどんなダイレクトアナログも持っていない完全に新しいパラダイムを紹介する必要性を作成しません。 代わりに、最初に特定の問題が物理ネットワーク環境でどう扱われるかを調べて、次に、同じ原則を環境に適用するのがしばしば役に立つ、どれ、含有
Gleeson, et al. Informational [Page 4] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[4ページ]のRFC2764IP
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.
仮想、物理ネットワークとして噴出してください、そして、必要であるときには展開するために、拡大と増進を当ててください。 明確に物理的なものと同様に仮想のネットワークの向こう側に一般的なメカニズムを持っているのは、VPNsの導入を既存のネットワークに容易にして、また、規格と商品開発の両方に必要である取り組みを減少させます、既存のソリューションを利用することができるので。
This framework document proposes a taxonomy of a specific set of VPN types, showing the specific applications of each, their specific requirements, and the specific types of mechanisms that may be most appropriate for their implementation. The intent of this document is to serve as a framework to guide a coherent discussion of the specific modifications that may be needed to existing IP mechanisms in order to develop a full range of interoperable VPN solutions.
このフレームワークドキュメントは特定のVPNタイプの分類学を提案します、それぞれの特定のアプリケーション、それらの決められた一定の要求、およびそれらの実装に、最も適切であるかもしれないメカニズムの特定のタイプを見せて。 このドキュメントの意図は最大限の範囲の共同利用できるVPN解決策を見いだすために既存のIPメカニズムに必要であるかもしれない特定の変更の一貫性を持っている議論を誘導するフレームワークとして機能することです。
The document first discusses the likely expectations customers have of any type of VPN, and the implications of these for the ways in which VPNs can be implemented. It also discusses the distinctions between Customer Premises Equipment (CPE) based solutions, and network based solutions. Thereafter it presents a taxonomy of the various VPN types and their respective requirements. It also outlines suggested approaches to their implementation, hence also pointing to areas for future standardization.
ドキュメントは最初に、ありそうな期待顧客について議論します。VPNのどんなタイプ、およびVPNsを実装することができる方法のためのこれらの含意についても。 また、それはCustomer Premises Equipmentの(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バックボーンの向こう側にVPNsの実装について議論するだけであることに注意してください、プライベートアイピーネットワーク、または公共のインターネットであることにかかわらず。 ここで説明されたモデルとメカニズムがIPV4とIPV6バックボーンの両方に適用することを意図します。 このドキュメントは明確に切り換えられたバックボーンに固有のマッピングを使用することでVPNsを組み立てる手段について議論しません--例えばATMバックボーンの上で作動しながらATM(MPOA)[2]プロトコルの上でATM(レーン)[1]かMultiprotocolの上でLAN Emulationを使用することで組み立てられたVPNs。 IPバックボーンがVPNsが切り換えられたバックボーンの上でルータとインタコネクトすることによって議論したそのようなプロトコルを使用することで構成されるところでは、このIPネットワークの上で作動してください、そして、したがって、直接基本的なバックボーンの固有のメカニズムを利用しないでください。 ネイティブのVPNsは基本的なバックボーンの範囲に制限されますが、IPのベースのVPNsはIPの可到達性の範囲に達することができます。 固有のVPNプロトコルは、明確にIETFの範囲の外にあって、ATM Forumのようなボディーによって取り組まれるかもしれません。
2.0 VPN Application and Implementation Requirements
2.0 VPNアプリケーションと実装要件
2.1 General VPN Requirements
2.1 一般VPN要件
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 VPNsの使用で関心ですか?
Gleeson, et al. Informational [Page 5] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[5ページ]のRFC2764IP
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つのタイプに分類できます--永久に接続するWANを捧げる、一緒にいる、複数のサイト、ネットワークにダイヤルしてください、とそれは1つ以上への(PSTN)が私設のネットワークで位置させるPublic Switched Telephone Networkを通した要求次第の接続を許します。
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は専用線を使用するか、専用回線であると通常実装されます--複数のサイトの間の例えば、Frame Relayか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つ以上の主要なサイトでNetwork Access Servers(NASs)の展開でこれをします。 ユーザがそのようなNASsにダイヤルするので、ユーザが受信するのに権限を与えられます。(NASsは、ユーザのアイデンティティ、およびサービスのセットについて確かめるためにAuthentication、Authorization、およびAccounting(AAA)サーバと対話します)。
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のベースのVPNsの展開へのインターネットの向こう側に稼働する重要な関心がありました。 これが偏在を通常通り過ぎて、現在のインターネットのサービスの神経の鈍い価格設定を遠ざけることである、それはひたむきであるか専用線の典型的なサービスよりかなり低いコストをもたらすことができます。
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]に使用されました。 しかしながら、近代においてだけ、VPNsのための顧客の要求を満たすのが必要である適切な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ネットワークは非ユニークなプライベートアイピーアドレシング[4]を使用するかもしれません。
Gleeson, et al. Informational [Page 6] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[6ページ]のRFC2764IP
2.1.2 Data Security
2.1.2 データ機密保護
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.
一般に、VPNsを使用している顧客が何らかのフォームのデータ機密保護を必要とします。 VPNsの使用に適切な異なった信頼モデルがあります。 そのようなモデルのひとりは顧客がサービスプロバイダーがどんなフォームのセキュリティも提供すると信じないで、代わりにファイアウォールの機能性を実装して、安全なトンネルを使用することで一緒に接続される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サービスを提供すると信じるところです。 これは権限のないパーティーによってトラヒック分析に顧客が公共の切り換えられたFrame Relayか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 Securityプロトコル群(IPSec)[5]によって提供されたものなどの強いセキュリティー対策はバックボーンノードの間のトンネルに必要でないかもしれません。 VPNトラフィックが複数の政権によって所有されていたネットワークか設備を横断するなら、強いセキュリティー対策は適切であるかもしれません。 また、強いレベルのセキュリティも、プロバイダーによって顧客トラフィックに適用されて、IPがネットワークでつなぐ顧客知覚、および特にインターネットを扱うかもしれなくて、不安定です。 この知覚が正しいか否かに関係なく、それはVPN実装で扱わなければならないものです。
2.1.3 Quality of Service Guarantees
2.1.3 サービスの質保証
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とFrame Relayには同様の保証のための大規模なメカニズムがあるように特に、賃貸されてダイヤルアップの系列は帯域幅と捧げられる間の潜在保証の両方に接続技術を提供します。 IPのベースのVPNsが広くより配布されるようになるので、同様の保証を求める市場の需要があるでしょう、アプリケーション透明を終わらせるために終わりを確実にするために。 また、IPのベースのVPNsがそのような保証を提供する能力が等しい能力に大いによっている間、基本的なIPバックボーンでは、それらが発展するとき、VPNフレームワークはVPNシステムがそのような能力を利用できる手段を扱わなければなりません。
Gleeson, et al. Informational [Page 7] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[7ページ]のRFC2764IP
2.1.4 Tunneling Mechanism
2.1.4 トンネリングメカニズム
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つの最初の要件が、何らかのフォームのIPトンネリングメカニズムを通してVPNsを実装しなければならないのを一緒に、含意します。そこでは、パケット・フォーマット、そして/または、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.
これらの或るものはVPNアプリケーションによく合っています、セクション3.0で議論するように。その上、また、後で議論するように、発展しているIP輸送管理メカニズムにそのようなトンネリングメカニズムを写像できます。多くのIPトンネリングメカニズムが既に定義されます。
2.2 CPE and Network Based VPNs
2.2 CPEとネットワークのベースのVPNs
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能力はさまざまなCPEデバイスと統合されています、ファイアウォールからWAN縁のルータと専門化しているVPN終了デバイスまで及んで。 そのような設備は、顧客によって買われて、配布されるか、またはアウトソーシング・サービスでサービスプロバイダーによって配布されるかもしれません(そして、しばしば離れて管理されます)。
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.
また、'ネットワークはVPNsを基礎づけたこと'へのVPNの操作がインターネットサービスプロバイダ(ISP)に社外調達されて、CPE設備と対照的にネットワークで実装される重要な関心があります。 サポートコストを削減しようとしている顧客と新しい財源を求めるISPによるそのようなソリューションへの重要な関心があります。 ネットワークでVPNsをサポートすると、高能率的で費用効率がよい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が基礎づけたどちらかに適用するか、またはベースのVPNsをネットワークでつなぐことができます。 しかしながら、特定のメカニズムは後者だけに適切であると判明しそうです、ISPだけにアクセスしやすいツール(例えば、ルーティング・プロトコルでは、便乗する)を利用して、どれによって何か顧客にとって利用可能であるか、またはISPで接待されてさえいるのに作られていそうにないかが、CPEを所有して、操作したので、ISPと顧客の両方でCPEギヤの合弁を調整するという問題のため。 このドキュメントは、どのテクニックが単にベースのVPNsをネットワークでつなぐのに申し込みそうであるかを示すでしょう。
Gleeson, et al. Informational [Page 8] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[8ページ]のRFC2764IP
2.3 VPNs and Extranets
2.3 VPNsとエクストラネット
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は、例えば輸出管理法に従うために内部的に、ある地理的な位置のグループへの機密保護ソフトウェアへのアクセスを制限するかもしれません。
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.
その結果、エクストラネットに関する重要な特色はだれが、データ、およびこれがものであるのにアクセスできるかに関するコントロールです。本質的には政策決定。 政策決定は今日、異なったドメインか、例えば、私設のネットワークとインターネットか、ソフトウェアテスト研究室と会社のネットワークの残りの間のインタコネクトポイントで通常励行されます。 トランジットトラフィックへの方針を適用できるファイアウォール、アクセスリストの機能性があるルータ、アプリケーションゲートウェイ、またはどんな同様のデバイスを通しても実施するかもしれません。 に加えて方針管理が企業ネットワークの中で実施されるかもしれない、企業ネットワークの間で。 また、ネットワークの間のインタコネクトは、1セットの双方のリンクであるかもしれない、または恐らく産業共同体によって維持された別々のネットワークであるかもしれません。 この別々のネットワークがそうすることができた、それ自体、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.
ネットワークにVPNsを取り入れるのはこのモデルへの少しの変化も必要としません。 2VPNsか、VPNとインターネットで方針を励行されることができます、まさに今日VPNsなしで行われるのと同じ方法で。 例えば2VPNs(各管理が局所的にそれ自身の方針を課して、制御する)がインタコネクトされることができました、ファイアウォールで、外部からVPNに入るすべてのトラフィックで、別のVPN、または、インターネットにかかわらず。
This model of a VPN provides for a separation of policy from the underlying mode of packet transport used. For example, a router may direct voice traffic to ATM Virtual Channel Connections (VCCs) for guaranteed QoS, non-local internal company traffic to secure tunnels, and other traffic to a link to the Internet. In the past the secure tunnels may have been frame relay circuits, now they may also be secure IP tunnels or MPLS Label Switched Paths (LSPs)
VPNのこのモデルは輸送が使用したパケットの基本的なモードから方針の分離に備えます。 例えば、ルータは保証されたQoS、安全なトンネル、およびインターネットへのリンクへの他のトラフィックへの非地方の内部の会社のトラフィックのためにATM Virtual Channelコネクションズ(VCCs)への音声トラヒックを指示するかもしれません。 過去に安全なトンネルがフレームリレーサーキットであったかもしれない、また、現在、それらは、安全なIPのトンネルかMPLS Label Switched Pathsであるかもしれません。(LSPs)
Gleeson, et al. Informational [Page 9] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[9ページ]のRFC2764IP
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の他のモデルも可能です。 例えば、1セットのアプリケーション流れがVPNに写像されるモデルがあります。 ネットワーク管理者によって課された政策ルールがかなり複雑になることができるのに従って、その結果、方針rulebaseで使用される異なったアプリケーション流れの数、およびしたがって、VPNsの数はかなり大きくなることができます、そして、複数の重なっているVPNsがあることができます。 しかしながら、そのような新しい複雑さをネットワークに取り入れることによって獲得するために、少ししかありません。 代わりに、VPNはダイレクトアナログとして物理ネットワークにおいて見なされるべきです、これがネットワーク管理者と顧客の既存のプロトコルと手順の力を入れ、現在の専門的技術、およびスキルセットを許容するとき。
3.0 VPN Tunneling
3.0 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では、何らかのフォームのトンネリングメカニズムを使用することでVPNsを実装しなければなりません。 このセクションはそのような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トンネルと前進のパケットを終えるかもしれません。 VPNsの異なったタイプの議論、このドキュメントの後のセクションでは、これらの異なったタイプのプライマリ区別の特性はパケットがインタフェース(例えば、ブリッジされるか、または発送される)の間に送られる方法です。 既存のネットワークデバイスが今日どう特徴付けられるかへのダイレクト類推があります。 2ポートのリピータは、ただポートの間にパケットを送って、パケットのコンテンツを調べません。 ブリッジはパケットに含まれたメディアAccess Control(MAC)層の情報を使用することでパケットを進めます、ルータがパケットに含まれた層3のアドレス指定情報を使用することでパケットを進めますが。 それぞれのこれらの3つのシナリオには、ダイレクトVPNアナログが後で議論するようにあります。 ただの種類のリンク(別のリンクで連結できる)がブリッジ推進テーブルに固まったので、IPトンネルが見られることに注意するか、またはIP推進テーブルにバウンドしてください、VPNのタイプに頼っていて。
Gleeson, et al. Informational [Page 10] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[10ページ]のRFC2764IP
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.
以下のセクションはVPNsの異なったタイプを構成するのに基本的なブロックとして使用できるジェネリックIPトンネリングプロトコルのための要件を見ます。
3.1 Tunneling Protocol Requirements for VPNs
3.1 VPNsのためのトンネリングプロトコル要件
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/IP[6](Genericルート設定Encapsulation(GRE)トンネル[7]、Layer2Tunnelingプロトコル(L2TP)[8]、IPSec[5]、およびMultiprotocol Label Switching(MPLS)[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つの重要な区別があることに注意してください。 IPのための特定のリンクレイヤとしてMPLSを見なすことができます、MPLSの特定のメカニズムがMPLSネットワークの範囲だけの中で適用されますが、IPのベースのメカニズムがIPの可到達性の範囲に達する限り。 そういうものとして、直接MPLSトンネリングメカニズムに造られたVPNメカニズムは定義上例えば、レーンなどのATMのベースのメカニズムがATMネットワークの外で広げることができるよりしたがってMPLSの範囲がそれ以上ネットワークでつなぐ外部を広げることができません。 しかしながら、MPLSネットワークが多くの異なったリンクレイヤ技術にかかることができるのでIPネットワークのように、範囲が特定のリンクによって制限されないのが使用されていた状態で層にされることに注意してください。 また、特にMPLSネットワークに関して共同利用できるVPNsを考慮するために1セットのメカニズムを定義するための多くの提案が生産された([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トンネリングメカニズムのための多くの望ましい必要条件があって、しかしながら、それはメカニズムにトンネルを堀る存在ですべて会われません。これらの要件は:
3.1.1 Multiplexing
3.1.1 マルチプレクシング
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
ケースが複数のVPNトンネルが同じ2つのIP終点の間で必要であるかもしれないところにあります。 例えば、これがVPNsが基づくネットワークであり、各エンドポイントが複数の顧客をサポートする場合で必要であるかもしれません。 異なった顧客のためのトラフィックは同じ2個のフィジカル・デバイスの間の別々のトンネルの上を移動します。 マルチプレクシング分野が、パケットが属するものを区別するのに必要です(トンネルを堀ります)。 また、トンネルを共有すると、この様に、設立されたトンネルのレイテンシと処理負担は減少するかもしれません。 既存のIPトンネリングメカニズムでは、L2TP(トンネルイドとセッションイド分野を通る)、MPLS(ラベルを通した)、およびIPSec(Security Parameter Index(SPI)分野を通る)はマルチプレクシングメカニズムを持っています。 厳密に言うと、GREには、マルチプレクシング分野がありません。 しかしながら、キーフィールド、どれがあったか。
Gleeson, et al. Informational [Page 11] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[11ページ]のRFC2764IP
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.
認証に使用されることを意図して、パケットの源はマルチプレクシング分野として時々使用されています。 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.
[16]とATM Forum[17]がグローバルにユニークな識別子のためのただ一つの形式で標準化したIETFは以前は、よくVPN(VPN-ID)を特定していました。 トンネル設立時間、またはデータ飛行機のVPNにトンネルを縛って、パケットに関連しているVPNを特定するのに制御飛行機でVPN-IDを使用できます、1パケットあたり1個のベースで。 データ飛行機では、VPNカプセル化ヘッダーはMPLS、MPOA、および他のトンネリングメカニズムによって使用されて、単一のトンネルにわたる異なったVPNsのためにパケットに集めることができます。 この場合、あらゆるパケットでVPN-IDの明白なしるしを含んでいます、そして、どんなトンネルの特定のマルチプレクシング分野でも無駄をします。 制御飛行機では、VPNと共にトンネル(例えば、SPI分野によって特定されるように)の協会を考慮するためにどんなトンネル設立合図プロトコルにもVPN-ID分野を含むことができます。 この場合、VPN-IDがあらゆるデータ・パケットで含まれる必要は全くありません。 セクション5.3.1で、より詳しくこれについて議論します。
3.1.2 Signalling Protocol
3.1.2 合図プロトコル
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つの方法の1つ、管理操作かトンネルがダイナミックに確立されるのを許容する合図プロトコルで終了できます。
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.
管理操作に関する例はIPSecのための様々なトンネリングパラメタか例えば、MPLSラベルかIP/IPかGREトンネルに使用するソースアドレスかL2TPトンネルイドとセッションイドか、セキュリティ協会パラメタを構成するのに、SNMP Management Information基地(MIB)を使用するだろうことです。
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が複数の管理ドメインにかかるなら必要である管理コーディネーションを減少させます。 例えば、最初に、管理局に構成されて、次に、関連ノードに分配されるよりむしろ上で説明されたマルチプレクシング分野の値は、値を割り当てるノードに地方であり、合図プロトコルで分配されるなら、地方に保つことができます。 また、合図プロトコルで、モバイルである、または断続的に接続されるだけであるノードはオンデマンドのトンネルを確立できます。
Gleeson, et al. Informational [Page 12] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[12ページ]のRFC2764IP
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に関連しているのを許容するのを許容するべきです。 また、それは、トンネル属性を交換するか、または交渉するのを許容するべきです、例えば、「マルチ-プロトコル」輸送のフレーム配列か使用の使用。 合図プロトコルの役割がトンネルがどう使用されているかの情報を運ぶのではなく、トンネル属性を交渉することであるだけでよいことに注意してください、例えば、トンネルで運ばれたフレームが層2か層3で進められることになっているか否かに関係なく。 (これはQ.2931 ATM合図と同様です--同じ合図プロトコルは、レーンの見習われたLANのようにまた、ClassicalのIPの論理的なサブネットワークをセットアップするのに使用されます。
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トンネリングプロトコルでは、以下のものはこのために適合させることができた合図プロトコルをサポートします: インターネット・キー・エクスチェンジ(IKE)は[18])、およびGREについて議定書の中で述べます。L2TP(L2TP制御プロトコル)、IPSec、((モバイル-ipと共に[19])にトンネルを堀りながら使用されるように。 また、LSPトンネルを証明するのに使用できる2つのMPLS合図プロトコルがあります。 MPLS Label Distributionプロトコル(自由民主党)への1つの用途拡大がベースのConstraintルート設定自由民主党(CR-自由民主党)[21]と呼ばれる[20]について議定書の中で述べます、そして、もう片方がLSPトンネル[22]にResource予約プロトコル(RSVP)に拡張子を使用します。
3.1.3 Data Security
3.1.3 データ機密保護
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、Frame RelayまたはATMの仮想の回路)の上で実装されたVPNsにおいて、層twoのスイッチインフラストラクチャはデータ機密保護をそれとなく提供します。
Overall VPN security is not just a capability of the tunnels alone, but has to be viewed in the broader context of how packets are forwarded onto those tunnels. For example with VPRNs implemented with virtual routers, the use of separate routing and forwarding table instances ensures the isolation of traffic between VPNs. Packets on one VPN cannot be misrouted to a tunnel on a second VPN since those tunnels are not visible to the forwarding table of the first VPN.
総合的なVPNセキュリティは、まさしくトンネルの能力であるだけではありませんが、どうそれらのトンネルにパケットを送るかの、より広い文脈で見られなければなりません。 例えば、VPRNsが仮想のルータで実装されている状態で、別々のルーティングと推進テーブルインスタンスの使用はVPNsの間のトラフィックの分離を確実にします。 それらのトンネルが最初のVPNの推進テーブルに目に見えないので、第2のVPNの上のトンネルに1VPNの上のパケットをmisroutedされることができません。
Gleeson, et al. Informational [Page 13] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[13ページ]のRFC2764IP
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.
暗号化か認証か両方のどちらかをサポートするSAsを証明するのに現在の、IPSec Encapsulating Security有効搭載量(超能力)プロトコル[23]を使用できます。 しかしながら、プロトコル仕様は暗号化も認証も使用されていないSAの使用を排除します。 VPN環境で、この「ヌルかヌル」のオプションは役に立ちます、プロトコルの他の局面以来(例えば、それ、それ、サポートトンネリングとマルチプレクシング) 必要であるすべてがそうです。 ただのレベルのデータ機密保護として事実上「ヌルかヌル」のオプションを見なすことができます。
3.1.4 Multiprotocol Transport
3.1.4 Multiprotocol輸送
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.
VPNsの多くのアプリケーションでは、VPNは不透明な「マルチ-プロトコル」トラフィックを運ぶかもしれません。 また、そういうものとして、使用されるトンネリングプロトコルは、「マルチ-プロトコル」が輸送であるとサポートしなければなりません。 L2TPをPointからポイントへのプロトコル(PPP)[24]パケットを輸送するように設計して、その結果、PPP自身が「マルチ-プロトコル」であるので「マルチ-プロトコル」トラフィックを運ぶのに使用できます。 また、GREはトンネルを堀られるプロトコルの識別に備えます。 トンネルを堀られるトラフィックがIPであると思われるので、IP/IPとIPSecトンネルには、どんなそのようなプロトコル識別分野もありません。
It is possible to extend the IPSec protocol suite to allow for the transport of multiprotocol packets. This can be achieved, for example, by extending the signalling component of IPSec - IKE, to indicate the protocol type of the traffic being tunneled, or to carry a packet multiplexing header (e.g., an LLC/SNAP header or GRE header) with each tunneled packet. This approach is similar to that used for the same purpose in ATM networks, where signalling is used to indicate the encapsulation used on the VCC, and where packets sent on the VCC can use either an LLC/SNAP header or be placed directly into the AAL5 payload, the latter being known as VC-multiplexing (see [25]).
「マルチ-プロトコル」パケットの輸送を考慮するためにIPSecプロトコル群を広げるのは可能です。 例えば、IPSecの合図の部品を広げることによって、これを達成できます--IKE、トンネルを堀られるトラフィックのプロトコルタイプを示すか、または運ぶために、それぞれがあるパケット多重ヘッダー(例えば、LLC/SNAPヘッダーかGREヘッダー)はパケットにトンネルを堀りました。 このアプローチは同じ目的に合図がVCCで使用されるカプセル化を示すのに使用されて、パケットがVCCはLLC/SNAPヘッダーを使用するか、または直接AAL5ペイロードに置くことができるのを転送したATMネットワークに使用されるそれと同様です、後者がVC-マルチプレクシングとして知られていて。([25])を見てください。
3.1.5 Frame Sequencing
3.1.5 フレーム配列
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
VPNの顧客によって必要とされた1つのサービスの質の属性はフレーム配列であるかもしれません、物理的な専用線かひたむきな接続の同等な特性を合わせて。 配列はそうです。
Gleeson, et al. Informational [Page 14] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[14ページ]のRFC2764IP
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.
特定の終わりの効率的な操作がプロトコルかアプリケーションを終わらせるのが必要です。 フレーム配列を実装するために、トンネリングメカニズムは配列分野をサポートしなければなりません。 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を使用することによって、これを達成できます。
3.1.6 Tunnel Maintenance
3.1.6 トンネルメインテナンス
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]かオープンShortest Path First(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と共に、Security Association(SA)の設立は、そのSAの生涯に使用されるために適所にキーを置きます。
Gleeson, et al. Informational [Page 15] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[15ページ]のRFC2764IP
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目的のためにネットワークでトンネルのためのリソースを割り当てているなら、このアプローチは特に役に立ちます。 別のアプローチは、静的なトンネル設定情報がインストールされるときはいつも、トンネル設立の引き金となって、絶えずトンネルを維持するのを試みることです。
3.1.7 Large MTUs
3.1.7 大きいMTUs
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トンネルには、まさしく通常のリンクのような関連Maximum Transmission Unit(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データグラムに写像されると、MTUがIPトンネルのMTUより小さい状態でIPデータグラムがホップに達すると、通常のIP断片化は起こるでしょう。 これはそのような中間のトンネル断片化を実行するルータで望ましくない性能意味を持つことができます。
An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism.
代替的アプローチは、トンネリングプロトコル自体が分割を取り入れて、トンネルレベルで作動する能力を再アセンブリすることです、恐らくトンネル一連番号とある種のメッセージのエンドマーカーを使用して。 (マルチリンクPPPがパケットを断片化するのにこれと同様のメカニズムを使用することに注意します。) これはトンネル自体の中でIPの平らな断片化を避けます。 プロトコルにトンネルを堀る存在のいずれもそのようなメカニズムをサポートしません。
3.1.8 Minimization of Tunnel Overhead
3.1.8 トンネルオーバーヘッドの最小化
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.
どんなトンネリングメカニズムのオーバーヘッドも最小にするのにおいて利益が明確にあります。ジターと潜在の敏感なトラフィックのpacketized声やビデオなどの輸送には、これは特に重要です。 したがって、目的は、他方では、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で、より詳しくこれについて議論します。
Gleeson, et al. Informational [Page 16] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[16ページ]のRFC2764IP
3.1.9 Flow and congestion control
3.1.9 流れと輻輳制御
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有効搭載量Compressionプロトコル(IPComp)[28]と異なってstatefulです)。 別の動機はわずか、が例えば低速ダイヤルアップ系列を終えるのにおいてバッファリングしていて、使用されていた状態でデバイスを収容することでした。 しかしながら、制御機構が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のLink Characteristics(PILC)ワーキンググループのパフォーマンスImplicationsの仕事に注意してください。IETFは異なったネットワークリンクの特性がどうそれらのリンクの上に作動するインターネットプロトコルの性能に影響を与えることができるかを調べています。
3.1.10 QoS / Traffic Management
3.1.10 QoS/輸送管理
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.
上で述べたように、顧客は、VPNsが損失が評定するような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
このドキュメントの範囲の外にQoSとVPNsの十分な議論があります、しかしながら、ただのタイプのリンクレイヤとしてVPNトンネルをモデル化することによって、また、物理的なリンクの上にQoSを確実にするために開発された既存のメカニズムの多くは適用できます。 そして例えば、VPNノード、取り締まっていて、マークしている列を作り、形成のメカニズム。
Gleeson, et al. Informational [Page 17] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[17ページ]のRFC2764IP
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.
まさしく非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トンネル処理をモデル化できます。
3.2 Recommendations
3.2 推薦
IPSec is needed whenever there is a requirement for strong encryption or strong authentication. It also supports multiplexing and a signalling protocol - IKE. However extending the IPSec protocol suite to also cover the following areas would be beneficial, in order to better support the tunneling requirements of a VPN environment.
強い暗号化か強い認証のための要件があるときはいつも、IPSecが必要です。 また、それはマルチプレクシングと合図プロトコルをサポートします--IKE。 しかしながら、また、以下の領域をカバーするためにIPSecプロトコル群を広げるのは有益でしょう、トンネリングがVPN環境の要件であるとサポートするほうがよいために。
- the transport of a VPN-ID when establishing an SA (3.1.2)
- SAを設立するときの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ワーキンググループのための仕事項目です。
4.0 VPN Types: Virtual Leased Lines
4.0 VPNはタイプします: 仮想の専用線
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の最も簡単なフォームは'仮想のLeased線'(VLL)サービスです。 この場合、以下で例証されるように2台のCPEデバイスを接続して、ポイントツーポイント接続を顧客に提供します。 何かリンクレイヤがタイプ、例えば、ATM VCCであったかもしれないならCPEデバイスをISPノードに接続するのに使用されるリンクレイヤタイプかFrame Relay回路。 CPEデバイスは、ルータブリッジかホストのどちらかであるかもしれません。
Gleeson, et al. Informational [Page 18] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[18ページ]のRFC2764IP
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 Adaptation Layer5(AAL5)ペイロードは、IPSecトンネルで取られて、カプセル化されます、そして、逆もまた同様です。 AAL5ペイロードの内容は、ISPノードに不透明であり、そこで調べられません。
+--------+ ----------- +--------+
+---+ | ISP | ( IP ) | ISP | +---+
|CPE|-------| edge |-----( backbone ) -----| edge |------|CPE|
+---+ ATM | node | ( ) | node | ATM +---+
VCC +--------+ ----------- +--------+ VCC
+--------+ ----------- +--------+ +---+ | ISP| (IP) | ISP| +---+ |CPE|-------| 縁|-----(バックボーン) -----| 縁|------|CPE| +---+ 気圧| ノード| ( ) | ノード| 気圧+---+ VCC+--------+ ----------- +--------+ VCC
<--------- IP Tunnel -------->
<。--------- IPトンネル-------->。
10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6
Addressing used by customer (transparent to provider)
10.1.1.5 .6Addressingが顧客で使用した10.1.1.4/30 10.1サブネット=.1(プロバイダーに透明)です。
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.
顧客にとって、まるで独身のATM VCCかFrame Relay回路がCPEデバイスとインタコネクトするのに使用されるかのように同じに見えます、そして、顧客は事実上、回路の一部がIPバックボーンの上で実装されたのを気づかないかもしれません。 これが役に立つかもしれない、例えば、プロバイダーであるなら、LANを提供するという願望は連結しますが、ネットワークには直接すべての可能な顧客サイトとインタコネクトするATMネットワークがないので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とFrame Relay)の間の織り込むデバイスを機能を実行して、NLPID変換へのLLC/SNAPなどの機能を実行しなければなりません、CPEデバイス(例えば、ATM OAMセル取り扱いかFrame Relay XID交換)によって予想されるかもしれないARPプロトコル異形とどんなメディアも実行するとき特定のマッピングが処理されて。
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は、「マルチ-プロトコル」が操作であるとサポートしなければならなくて、配列をサポートする必要があるかもしれません、その特性が顧客トラフィックに重要であるなら。 トンネルが合図プロトコルを使用することで確立されるなら、それらはデータ駆動の方法でセットアップされるかもしれません、顧客リンクからフレームを受け取って、トンネルが全く存在していないか、トンネルが時間に食糧を供給するのに確立されて、永久に維持されるとき。
Gleeson, et al. Informational [Page 19] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[19ページ]のRFC2764IP
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 Behaviour(EF-PHB)[30]の定義に使用されるそれに異なっていることに注意してください。 そのドキュメントでは、VLLは、低遅延(低い説明されたPHBを使用することで供給できる帯域幅経路が保証されたジター)を意味するのに使用されます。 したがって、そこの焦点が主として現実に時のリンクの特性にあります。 本書ではVLLという用語はDiffservの、または、そうでないどんな特定のQoSメカニズムの使用も含意しません。 代わりに、焦点が主として自然(例えば、リンクの1つのセグメントとしてIPトンネルを含んでいるリンクを組み立てるとしてのそのようなもの)で、より位相的なリンクの特性にあります。 リンクレイヤの本当に完全なエミュレーションのために、両方の時の、そして、位相的な局面は、考慮に入れられる必要があります。
5.0 VPN Types: Virtual Private Routed Networks
5.0 VPNはタイプします: 仮想の私設の発送されたネットワーク
5.1 VPRN Characteristics
5.1 VPRNの特性
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.
Virtual兵士のRouted Network(VPRN)は、マルチサイトの広い領域発送されたネットワークのエミュレーションになるようにIP施設を使用することで定義されます。 このセクションはどうネットワークベースのVPRNサービスを提供できるかを見ます。 CPEベースのVPRNsについてまた、可能ですが、ここで明確に議論しません。 ネットワークベースのVPRNsと共に、扱われる必要がある問題の多くが構成と操作上の問題に関係があります。(問題はサービスプロバイダーとサービス利用者の間の行政責任における分裂を考慮に入れなければなりません)。
The distinguishing characteristic of a VPRN, in comparison to other types of VPNs, is that packet forwarding is carried out at the network layer. A VPRN consists of a mesh of IP tunnels between ISP routers, together with the routing capabilities needed to forward traffic received at each VPRN node to the appropriate destination site. Attached to the ISP routers are CPE routers connected via one or more links, termed 'stub' links. There is a VPRN specific forwarding table at each ISP router to which members of the VPRN are connected. Traffic is forwarded between ISP routers, and between ISP routers and customer sites, using these forwarding tables, which contain network layer reachability information (in contrast to a Virtual Private LAN Segment type of VPN (VPLS) where the forwarding tables contain MAC layer reachability information - see section 7.0).
VPNsの他のタイプとの比較における、VPRNの区別の特性はパケット推進がネットワーク層で行われるということです。 VPRNはISPルータの間のIPトンネルのメッシュから成ります、それぞれのVPRNノードに適切な目的地サイトに受け取られたトラフィックを進めるのに必要であるルーティング能力と共に。 'スタッブ'リンクと呼ばれた1個以上のリンクを通して接続されたCPEルータをISPルータに付けます。 VPRNのメンバーが関連しているそれぞれのISPルータにはVPRNの特定の推進テーブルがあります。 ISPルータの間と、そして、ISPルータと顧客サイトの間にトラフィックを送ります、これらの推進テーブル(ネットワーク層可到達性情報を含んでいる)を使用して(推進テーブルがMAC層の可到達性情報を含むVPN(VPLS)のVirtual兵士のLAN Segmentタイプと対照して--セクション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
VPRNがイラスト入りである以下が図解する例(縁のルータがIPトンネルの完全なメッシュを通して接続したのを3ISPに示す)は以前はよく4つのCPEルータとインタコネクトしていました。 CPEルータの1つはISPネットワークと「マルチ-家へ帰」ります。 「マルチ-家へ帰」っている場合では、すべてのスタッブリンクがアクティブであるかもしれませんか、または予備選挙の失敗の場合に使用されるべき1個のプライマリリンクと1個以上のバックアップリンクが示されるようにあるかもしれません。 用語'裏口'リンクは、2つの顧客サイトの間のリンクについて言及するのに使用されます。
Gleeson, et al. Informational [Page 20] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[20ページ]のRFC2764IP
that does not traverse the ISP network.
それはISPネットワークを横断しません。
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
10.1.1.0/30 +--------+ +--------+ 10.2.2.0/30 +---+ | ISP| IPトンネル| ISP| +---+ |CPE|-------| 縁| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 縁|-------|CPE| +---+ スタッブ| ルータ| 10.9.9.4/30 | ルータ| スタッブ+---+ リンク+--------+ +--------+ リンク: | ^ | | ^ : | | | --------------- | | : | | +----( )----+ | : | | (IPバックボーン) | : | | ( ) | : | | --------------- | : | | | | : | |IPトンネル+--------+ IPトンネル| : | | | ISP| | : | +---------->| 縁| <、-、-、-、-、-、-、-、-、--+ : | 10.9.9.8/30 | ルータ| 10.9.9.12/30 : バックアップ| +--------+ 裏口: リンク| | | 以下をリンクしてください。 | スタッブリンク| | リンクを引き抜いてください: | | | : | +---+ +---+ : +-------------|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に社外調達されます。 さらに、多くの潜在的に異種のCPEデバイスよりむしろ少ない数のISP縁のルータはファイアウォールに関する条項などのVPNの操作に必要である他のサービスとQoS処理を扱うことができます。 また、より容易に新種業務の序論と管理を扱うことができます、どんなCPE設備もアップグレードさせる必要性なしでこれを達成できるとき。 多くの住宅の加入者がいるとき、この後者の利益は、私設の企業ネットワークにアクセスするのにVPNサービスを利用することで特に重要です。 この点で、モデルは加入者設備における変化なしで新種業務(例えば、キャッチホン)を導入できる電話サービスに使用されるそれといくらか同様です。
Gleeson, et al. Informational [Page 21] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[21ページ]のRFC2764IP
The VPRN type of VPN is in contrast to one where the tunnel mesh extends to the CPE routers, and where the ISP network provides layer 2 connectivity alone. The latter case can be implemented either as a set of VLLs between CPE routers (see section 4.0), in which case the ISP network provides a set of layer 2 point-to-point links, or as a VPLS (see section 7.0), in which case the ISP network is used to emulate a multiaccess LAN segment. With these scenarios a customer may have more flexibility (e.g., any IGP or any protocol can be run across all customer sites) but this usually comes at the expense of a more complex configuration for the customer. Thus, depending on customer requirements, a VPRN or a VPLS may be the more appropriate solution.
VPNのVPRNタイプはトンネルメッシュがCPEルータに達して、ISPネットワークが単独で層2の接続性を提供するものと対照的になっています。 CPEルータ(セクション4.0を見る)の間のVLLsの1セット、その場合、ISPネットワークが1セットの層2に二地点間リンクを供給するか、またはその場合、ISPネットワークが多重処理LANセグメントを見習うのにVPLS(セクション7.0を見る)として使用されるとき、後者のケースを実装することができます。 これらのシナリオによって、顧客には、より多くの柔軟性があるかもしれませんが(すべての顧客サイトの向こう側に例えばどんな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プロトコルはIP VPRNの上でトンネルを堀りました)、または層2の接続性だけを提供するのにあるいはまたISPネットワークを使用できました、以上のようであるVPLSなどのように。
The issues to be addressed for VPRNs include initial configuration, determination by an ISP edge router of the set of links that are in each VPRN, the set of other routers that have members in the VPRN, and the set of IP address prefixes reachable via each stub link, determination by a CPE router of the set of IP address prefixes to be forwarded to an ISP edge router, the mechanism used to disseminate stub reachability information to the correct set of ISP routers, and the establishment and use of the tunnels used to carry the data traffic. Note also that, although discussed first for VPRNs, many of these issues also apply to the VPLS scenario described later, with the network layer addresses being replaced by link layer addresses.
VPRNsのために扱われる問題は各VPRNにあるリンクのセット、メンバーがVPRNにいる他のルータのセット、およびそれぞれのスタッブリンクを通して届いているIPアドレス接頭語のセットのISP縁のルータで初期の構成、決断を含んでいます; トンネルのISP縁のルータに送られる、IPアドレス接頭語のセット、正しいセットのISPルータにスタッブ可到達性情報を広めるのに使用されるメカニズム、確立、および使用のCPEルータによる決断は以前はよくデータ通信量を運びました。 また、また、これらの問題の多くが後で説明されたVPLSシナリオに適用されます、最初に、VPRNsのために議論しますがネットワーク層アドレスをリンクレイヤアドレスに取り替えていて注意してください。
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つのドメインに分けて、ファイアウォールの機能性を提供するのに原因となります。
Gleeson, et al. Informational [Page 22] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[22ページ]のRFC2764IP
5.1.1 Topology
5.1.1 トポロジー
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ノードの間のトンネルの完全なメッシュから成るかもしれないか、または任意のトポロジーであるかもしれません、最も近い地方のサイトにつなげられた1セットの地理的に分散したオフィスなどのように、これらの地方のサイトが完全であるか部分的なメッシュを通して一緒につなげられている状態で。 VPRNsがIPトンネルを使用していて、まして、物理資源(例えば、専用線)をそれぞれの接続組のサイトに割り当てなければならないケースの中、または、トンネリングメソッドが、リソースが縁のルータ(例えば、Frame Relay DLCIs)とインタコネクトするのに使用されるデバイスに割り当てられるのを必要とすることで完全なメッシュで想定された費用があります。 完全なメッシュトポロジーは最適ルーティングをもたらします、2つのサイトの間のトラフィックが3分の1を横断する必要性を排除するので。 完全なメッシュの別のアトラクションはVPRNのためのトポロジー情報を構成する必要は全くないということです。 VPRNのメンバールータを考えて、代わりに、トポロジーは暗黙です。 しかしながら、VPRNのISP縁のルータの数が非常に大きいなら、完全なメッシュトポロジーは適切でないかもしれません、例えば問題がかかわったスケーリング、サイトの間で必要であるトンネルの数における成長(nサイトへのn(n-1)/2である)のため、または、ルーティングの数はルータ単位でじっと見ます。 また、ネットワーク方針は非完全なメッシュtopologiesに通じるかもしれません、例えば、管理者が2つのリモートサイトの間のトラフィックが直接リモートサイトを取り持つよりむしろ主要なサイトを通り抜けるように、トポロジーをセットアップしたがっているかもしれません。 また、部分的な接続性しかIPバックボーンのむこうに方針ルーティングが使用されているなら起こることができるあるエラー条件(例えば、AはBに達することができます、そして、BはCに達することができますが、Aは直接Cに達することができない)の下にないシナリオに対処するのも必要です。
For a network-based VPRN, it is assumed that each customer site CPE router connects to an ISP edge router through one or more point-to- point stub links (e.g. leased lines, ATM or Frame Relay connections). The ISP routers are responsible for learning and disseminating reachability information amongst themselves. The CPE routers must learn the set of destinations reachable via each stub link, though this may be as simple as a default route.
ネットワークベースのVPRNに関しては、それぞれの顧客サイトCPEルータが1ポイント以上からポイントへのスタッブリンク(例えば、専用線、ATMまたはFrame Relay接続)を通してISP縁のルータに接続すると思われます。 ISPルータは自分たちの中で可到達性情報を学んで、広めるのに原因となります。 CPEルータはそれぞれのスタッブリンクを通して届いている目的地のセットを学ばなければなりません、これがデフォルトルートと同じくらい簡単であるかもしれませんが。
The stub links may either be dedicated links, set up via provisioning, or may be dynamic links set up on demand, for example using PPP, voluntary tunneling (see section 6.3), or ATM signalling. With dynamic links it is necessary to authenticate the subscriber, and determine the authorized resources that the subscriber can access (e.g. which VPRNs the subscriber may join). Other than the way the subscriber is initially bound to the VPRN, (and this process may involve extra considerations such as dynamic IP address assignment), the subsequent VPRN mechanisms and services can be used for both types of subscribers in the same way.
スタッブリンクは、専用リンクであるかもしれない、食糧を供給することを通してセットアップするか、または要求に応じてセットアップされた、ダイナミックなリンクであるかもしれません、例えば、PPP、自発的のトンネリング(セクション6.3を見る)、またはATM合図を使用して。 ダイナミックなリンクがあるので、加入者を認証して、加入者がアクセスできる(例えば、加入者はどのVPRNsに加わるかもしれませんか)認可されたリソースを決定するのが必要です。 道を除いて、加入者が初めはVPRNに縛られる、(このプロセスは動的IPアドレス課題などの付加的な問題にかかわるかもしれません)、同様に、両方のタイプの加入者にその後のVPRNメカニズムとサービスを利用できます。
Gleeson, et al. Informational [Page 23] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[23ページ]のRFC2764IP
5.1.2 Addressing
5.1.2 アドレシング
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バックボーンで使用されるアドレシングに関係がないかもしれません。 非ユニークなプライベートアイピーアドレシングは特に、中古の[4]であるかもしれません。 複数のVPRNsが同じセットのフィジカル・デバイスの上に例示されるかもしれません、そして、それらは同じであるか重なっているアドレス空間を使用するかもしれません。
5.1.3 Forwarding
5.1.3 推進
For a VPRN the tunnel mesh forms an overlay network operating over an
IP backbone. Within each of the ISP edge routers there must be VPN
specific forwarding state to forward packets received from stub links
('ingress traffic') to the appropriate next hop router, and to
forward packets received from the core ('egress traffic') to the
appropriate stub link. For cases where an ISP edge router supports
multiple stub links belonging to the same VPRN, the tunnels can, as a
local matter, either terminate on the edge router, or on a stub link.
In the former case a VPN specific forwarding table is needed for
egress traffic, in the latter case it is not. A VPN specific
forwarding table is generally needed in the ingress direction, in
order to direct traffic received on a stub link onto the correct IP
tunnel towards the core.
VPRNに関しては、トンネルメッシュはIPバックボーンの上で作動するオーバレイネットワークを形成します。 中では、そこのそれぞれのISP縁のルータがスタッブリンク('イングレストラフィック')から受け取られたパケットを次の適切なホップルータに送って、コア('出口トラフィック')から適切なスタッブリンクまで受け取られたパケットを送るVPNの特定の推進状態であるに違いありません。 ISP縁のルータが複数のスタッブが同じVPRNに属すリンクであるとサポートするケースのために、地域にかかわる事柄として、トンネルは縁のルータの上、または、スタッブリンクの上に終わることができます。 前の場合では、VPNの特定の推進テーブルが出口トラフィックに必要であり、後者の場合では、それはそうではありません。 一般に、VPNの特定の推進テーブルがイングレス方向に必要です、スタッブリンクの上に正しいIPトンネルに受け取られたトラフィックをコアに向けるために。
Also since a VPRN operates at the internetwork layer, the IP packets sent over a tunnel will have their Time to Live (TTL) field decremented in the normal manner, preventing packets circulating indefinitely in the event of a routing loop within the VPRN.
VPRNがインターネットワーク層でまた、作動するので、トンネルの上に送られたIPパケットは正常な方法で減少するLive(TTL)分野にそれらのTimeを持つでしょう、パケットがルーティング輪の場合、VPRNの中を無期限に循環するのを防いで。
5.1.4 Multiple concurrent VPRN connectivity
5.1.4 複数の同時発生の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.
また、ただ一つの顧客サイトが同時に複数のVPRNsに属して、ともに1VPRNsにトラフィックを伝えたがっているかもしれないことに注意してください、そして、同じスタッブの上では、デフォルトインターネットに、リンクしてください。 この問題への多くの可能なアプローチがありますが、このドキュメントの範囲の外にこれらはあります。
5.2 VPRN Related Work
5.2 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つの番目ものの1つは[10]でした。(その[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
メカニズムが会員資格と可到達性の機能性をVPRNに供給するのに使用したあいさつとして2つの主な異形があります--オーバレイと便乗。 セクションで詳細によりすばらしいこれらについて議論します。
Gleeson, et al. Informational [Page 24] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[24ページ]のRFC2764IP
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).
以下に オーバレイモデルに関する例は[14]とどれが1VPNあたりの別々のルーティング・プロトコルインスタンスとルートによるVPRNの機能性の支給について議論するか、そして、別の方法で仮想のルーティングとして知られている推進テーブル具体化で説明されます。 それぞれのVPNルーティングインスタンスはいかなる他のVPNルーティングインスタンスと、ルーティングからもバックボーンの向こう側に使用される隔離されます。 その結果、どんなルーティングも議定書を作る、(例えば、OSPF、RIP2、-、)、どんなVPRNと共にも実行できます、他のVPRNs、またはバックボーン自体に使用されるルーティング・プロトコルの如何にかかわらず。 また、[12]で説明されたVPNモデルは仮想のルーティングを使用しているオーバレイVPRNモデルです。 そのドキュメントはMPLSバックボーンの上で明確にVPRNの機能性の支給に向かって連動します、そして、MPLSバックボーンの上でどうVPRN会員資格普及を自動化できるかを説明します、ベースMPLSトンネルメッシュの上のVPN隣人発見を実行することによって。 [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の機能性の支給について説明します、この情報がボーダ・ゲイトウェイ・プロトコル4(BGP)[32]パケットで背負われている状態で。 VPNsは、BGP方針(どのサイトが互いにコミュニケートできるかを制御するのに使用される)を使用することで組み立てられます。 [13]もMPLS LSPsを証明するのに使用されるプロトコル(CR-自由民主党か拡張RSVP)で、会員資格情報を背負うのにBGPを使用して、可到達性情報を背負います。 しかしながら、他の提案と異なって、この提案は、VPNの機能性を実装するためにCPEルータで参加を必要とします。
5.3 VPRN Generic Requirements
5.3 VPRNジェネリック要件
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) リンク可到達性情報を引き抜いてください。 縁のルータはそれぞれのスタッブリンクを通して届いているアドレスとアドレス接頭語のセットを学ばなければなりません。
Gleeson, et al. Informational [Page 25] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[25ページ]のRFC2764IP
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にいる他のルータに必要なトンネルを建築しなければならなくて、トンネルの上でパケットを送って、受けるのに必要なカプセル化と被膜剥離術を実行しなければなりません。
5.3.1 VPN Identifier
5.3.1 VPN識別子
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.
[16]とATM Forum[17]がグローバルにユニークな識別子のためのただ一つの形式で標準化したIETFは以前はよくVPNを特定していました--VPN-ID。 VPN-IDの書式だけがその意味論かどんな用法でも定義されていません。 目的がさまざまな目的の使用を許すことであり、技術とメカニズム例えば、異なるのによるVPN-ID中古の缶に同じ識別子を許容するために、管理目的のためにVPNを特定するMIBで含められてください。 例えばトンネル設立時間にVPNにトンネルを縛るのに規制飛行機プロトコルにVPN-IDを使用できます。 そして、トンネルを横断するすべてのパケットがそれとなく特定されたVPNに関連づけられます。 パケットに関連しているVPNの1パケットあたり1つの明白な識別を考慮するのにデータ飛行機カプセル化にVPN-IDを使用できます。 VPNがネットワークに異なった技術(例えば、IPとATM)を使用することで実装されるなら、異なった技術の向こう側にVPNを特定するのに同じ識別子を使用できます。 また、VPNが複数の管理ドメインにかかっているなら、いたる所で同じ識別子を使用できます。
Most of the VPN schemes developed (e.g. [11], [12], [13], [14]) require the use of a VPN-ID that is carried in control and/or data packets, which is used to associate the packet with a particular VPN. Although the use of a VPN-ID in this manner is very common, it is not universal. [15] describes a scheme where there is no protocol field used to identify a VPN in this manner. In this scheme the VPNs as understood by a user, are administrative constructs, built using BGP policies. There are a number of attributes associated with VPN routes, such as a route distinguisher, and origin and target "VPN", that are used by the underlying protocol mechanisms for disambiguation and scoping, and these are also used by the BGP policy mechanism in the construction of VPNs, but there is nothing corresponding with the VPN-ID as used in the other documents.
VPN体系の大部分が展開した、([11] [12] [13] [14]) 例えば、コントロール、そして/または、データ・パケットで運ばれるVPN-IDの使用を必要としてください。(それは、特定のVPNにパケットを関連づけるのに使用されます)。 VPN-IDの使用はこの様に非常に一般ですが、それは普遍的ではありません。 この様にVPNを特定するのに使用されるプロトコル分野が全くないところで[15]は体系について説明します。 この体系では、ユーザによって理解されているVPNsは管理構造物であり、組立の使用はBGP方針です。 それが曖昧さの解消に基本的なプロトコルメカニズムによって使用されて、見られて、"VPN"を狙って、ルートdistinguisherや、発生源などのVPNルートに関連している多くの属性があります、そして、また、これらはBGP方針メカニズムによってVPNsの構造に使用されますが、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の上の使用のために「マルチ-プロトコル」カプセル化を定義することに注意してください。
Gleeson, et al. Informational [Page 26] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[26ページ]のRFC2764IP
5.3.2 VPN Membership Information Configuration and Dissemination
5.3.2 VPN会員資格情報構成と普及
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縁のルータよりむしろ外部認証サーバであるかもしれないことに注意してください。 リンクが静的かダイナミックに作成されたか否かに関係なく、それがどのVPRNであるかに制限されていた状態で意味するようにVPN-IDをそのリンクに関連づけることができます。
After learning which stub links are bound to which VPRN, each edge router must learn either the identity of, or, at least, the route to, each other edge router supporting other stub links in that particular VPRN. Implicit in the latter is the notion that there exists some mechanism by which the configured edge routers can then use this edge router and/or stub link identity information to subsequently set up the appropriate tunnels between them. The problem of VPRN member dissemination between participating edge routers, can be solved in a variety of ways, discussed below.
どれのスタッブリンクがVPRN、それぞれが必須がアイデンティティについて知るルータ、または少なくともルートをどれに斜めに進ませるかに制限されていて、互いが他のスタッブがリンクであるとサポートする縁のルータであるかを学んだ後そんなに特定のVPRN 後者で暗黙であることは、次に構成された縁のルータが次にそれらの間の適切なトンネルを設立するのにこの縁のルータ、そして/または、スタッブリンクアイデンティティ情報を使用できる何らかのメカニズムが存在しているという概念です。 参加している縁のルータの間のVPRNメンバー普及の問題は、以下でさまざまな方法で解決して、議論できます。
5.3.2.1 Directory Lookup
5.3.2.1 ディレクトリルックアップ
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でスタッブリンクを支える縁のルータのアイデンティティ、および縁のルータあたりのVPRNに制限された静的なスタッブリンクのセット)をディレクトリに構成できました、何らかの定義されたメカニズムを使用して。(縁のルータはディレクトリについて質問できました)。(例えば、始動でのライトウェイト・ディレクトリ・アクセス・プロトコル(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のメンバールータに関する完全リストはいたる所で分配されます。 任意のトポロジーに関しては、異なったルータは異なったメンバーリストを受け取るかもしれません。
Gleeson, et al. Informational [Page 27] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[27ページ]のRFC2764IP
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会員資格情報を広める前に、許可検査はVPRNsが複数の管理ドメインにかかるところで考慮されます。 また、このような場合には、複数の管理ドメインのディレクトリシステムの間の認可された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.
また、そこでは、すべての縁のルータがアクティブなVPRNに挿入された新たに構成されたサイトのアイデンティティを学ぶためには何らかのフォームのデータベース同期メカニズム(例えば、縁のルータによるディレクトリの引き起こされたか定期的な世論調査、またはディレクトリによる縁のルータへのアップデート情報をアクティブな押す)であり、また、VPRNから取り除かれたサイトを知るのが必要です。
5.3.2.2 Explicit Management Configuration
5.3.2.2 明白な管理構成
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に縛ったアイデンティティでそれぞれの縁のルータを構成できるでしょう)。 ディレクトリの使用のように、このメカニズムは、完全なメッシュと任意のtopologiesの両方が構成されるのを許容します。 集中的管理システムを使用する別のメカニズムは、方針サーバを使用して、VPRN会員資格と方針情報を分配するのにCommonオープンPolicy Service(COPS)プロトコル[35]を使用することです、トンネルを確立するとき使用するトンネル属性などのように、[36]で説明されるように。
Note that this mechanism allows the management station to impose strict authorization control; on the other hand, it may be more difficult to configure edge routers outside the scope of the management system. The management configuration model can also be considered a subset of the directory method, in that the management directories could use MIBs to push VPRN membership information to the participating edge routers, either subsequent to, or as part of, the local stub link configuration process.
このメカニズムが厳しい承認規制を設けるために管理局を許容することに注意してください。 他方では、マネージメントシステムの範囲の外で縁のルータを構成するのは、より難しいかもしれません。 また、ディレクトリメソッドの部分集合であると管理構成モデルを考えることができます、管理ディレクトリが参加への情報が部分部分、または、としてその後のルータを斜めに進ませるプッシュVPRN会員資格にMIBsを使用するかもしれないので、ローカルのスタッブリンクコンフィギュレーションプロセス。
5.3.2.3 Piggybacking in Routing Protocols
5.3.2.3 ルーティング・プロトコルでは便乗すること。
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
IPバックボーンの向こう側にそれぞれの縁のルータによって実行されたルーティング・プロトコルにVPRN会員資格情報を背負うことができました、これがネットワーク中で自動的に他の参加している縁のルータに情報を伝播する効率的な手段であることで。 明確に、それぞれの縁のルータによるそれぞれのルート広告は最小限でアイデンティティを決定する他の縁のルータ、そして/または、ルートを許容するそれぞれの縁のルータ、および適切な情報に関連しているVPN識別子のセットを含むかもしれません、特定の縁のルータ。 ルータが調べる他の縁は、何か含まれた情報がそうであったかどうか決定するためにルート広告を受け取りました。
Gleeson, et al. Informational [Page 28] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[28ページ]のRFC2764IP
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に関連する。 局所的に構成された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か、VPRNsとの静的なスタッブリンクの結合か、認証と承認情報をサポートすることができる縁のルータのセットなどのように注意してください。 この情報は、何らかのフォームに関するデータベースに構成されて、保存される必要があります、そして/または、そのような情報の構成を縁のルータに容易にするのに必要である追加ステップがそのような情報への縁のルータアクセスを容易にするように過度に煩わしくないかもしれません。
Gleeson, et al. Informational [Page 29] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[29ページ]のRFC2764IP
5.3.3 Stub Link Reachability Information
5.3.3 スタッブリンク可到達性情報
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縁のルータによって必要とされた情報は同じです--しかし、顧客サイト、情報で届いているアドレスがCPEルータで必要としたVPRNのセットは異なります。
5.3.3.1 Stub Link Connectivity Scenarios
5.3.3.1 スタッブリンク接続性シナリオ
5.3.3.1.1 Dual VPRN and Internet Connectivity
5.3.3.1.1 二元的なVPRNとインターネットの接続性
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.
これはCPEルータのための最も簡単なそうです、ただISP縁のルータを示すデフォルトルートを必要とするとき。
5.3.3.1.2 VPRN Connectivity Only
5.3.3.1.2 VPRNの接続性専用
The CPE router is connected via one link to an ISP edge router, which provides VPRN, but not Internet, connectivity.
CPEルータはインターネット、接続性ではなく、VPRNを提供するISP縁のルータへの1個のリンクを通して接続されます。
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ルータは、この情報によって静的に構成されるか、またはInteriorゲートウェイプロトコル(IGP)のインスタンスを実行することによって、ダイナミックにそれを学ぶかもしれません。 簡単さにおいて、それはどんなIGPであるかもしれませんがも、このために使用されるIGPがRIPであると思われます。 ISP縁のルータはそれがセクション5.3.4で説明されたイントラ-VPRN可到達性メカニズムの1つによって学ぶVRPNルートをRIPのこのインスタンスに注入するでしょう。 RIPのインスタンスがCPE、およびイントラ-VPRNの可到達性を学ぶのに使用されるルーティング・プロトコルのどんなインスタンスにも駆けつけることに注意してください、(RIPも)、分離してください、ISP縁のルータが1つのインスタンスから別のインスタンスまでルートを再配付していて。
Gleeson, et al. Informational [Page 30] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[30ページ]のRFC2764IP
5.3.3.1.3 Multihomed Connectivity
5.3.3.1.3 Multihomed接続性
The CPE router is multihomed to the ISP network, which provides VPRN connectivity.
CPEルータはISPネットワークと「マルチ-家へ帰」ります。(それは、VPRNの接続性を提供します)。
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ルータに広告を出します。
5.3.3.1.4 Backdoor Links
5.3.3.1.4 裏口のリンク
The CPE router is connected to the ISP network, which provides VPRN connectivity, but also has a backdoor link to another customer site
CPEルータは、ISPネットワークに関連づけられますが、別の顧客サイトに裏口のリンクをまた持っています。(ネットワークはVPRNの接続性を提供します)。
In this case the ISP edge router will advertise VPRN routes as in case 2 to the CPE device. However now the same destination is reachable via both the ISP edge router and via the backdoor link. If the CPE routers connected to the backdoor link are running the customer's IGP, then the backdoor link may always be the favored link as it will appear an an 'internal' path, whereas the destination as injected via the ISP edge router will appear as an 'external' path (to the customer's IGP). To avoid this problem, assuming that the customer wants the traffic to traverse the ISP network, then a separate instance of RIP should be run between the CPE routers at both ends of the backdoor link, in the same manner as an instance of RIP is run on a stub or backup link between a CPE router and an ISP edge router. This will then also make the backdoor link appear as an external path, and by adjusting the link costs appropriately, the ISP path can always be favored, unless it goes down, when the backdoor link is then used.
この場合、ISP縁のルータはCPEデバイスへのケース2のようにVPRNルートの広告を出すでしょう。 しかしながら、現在同じ目的地はISP縁のルータと裏口のリンクを通した両方を通して届いています。 裏口のリンクに接続されたCPEルータが顧客のIGPを実行しているなら、いつも裏口のリンクは'内部'経路に現れるように好評なリンクであるかもしれませんが、ISP縁のルータで注入される目的地は'外部'の経路(顧客のIGPへの)として現れるでしょう。 顧客が、トラフィックに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ルータをカバーしていて、この情報を伝えるのに使用されるメカニズムのいくつかについて議論します。 その他の詳細のこれらのメカニズムへの一見の下のセクション。
5.3.3.1 Routing Protocol Instance
5.3.3.1 ルーティング・プロトコルインスタンス
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ルータがプロバイダーネットワークを通して届いている目的地を学ぶのを許容します。
Gleeson, et al. Informational [Page 31] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[31ページ]のRFC2764IP
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縁のルータとドメインはまた、顧客サイトがIGPと同じ実行しているプロトコルであるなら顧客サイトに広がるかもしれませんが、CPEルータです。 顧客サイトが異なったルーティング・プロトコルを実行しているなら、CPEルータはISP縁のルータに駆けつけるインスタンスと、顧客サイトを出くわすインスタンスの間のルートを再配付します。
Given the typically restricted scope of this routing instance, a simple protocol will generally suffice. RIP is likely to be the most common protocol used, though any routing protocol, such as OSPF, or BGP run in internal mode (IBGP), could also be used.
一般に、このルーティングインスタンスの通常制限された範囲を考えて、簡単なプロトコルは十分でしょう。 RIPは使用される中で最も一般的なプロトコル、もっとも、OSPFなどのどんなルーティング・プロトコルまたはBGPであることも内部のモード(IBGP)に立候補して、また、使用できた傾向があります。
Note that the instance of the stub link routing protocol is different from any instance of a routing protocol used for intra-VPRN reachability. For example, if the ISP edge router uses routing protocol piggybacking to disseminate VPRN membership and reachability information across the core, then it may redistribute suitably labeled routes from the CPE routing instance to the core routing instance. The routing protocols used for each instance are decoupled, and any suitable protocol can be used in each case. There is no requirement that the same protocol, or even the same stub link reachability information gathering mechanism, be run between each CPE router and associated ISP edge router in a particular VPRN, since this is a purely local matter.
スタッブリンクルーティング・プロトコルのインスタンスがイントラ-VPRNの可到達性に使用されるルーティング・プロトコルのどんなインスタンスとも異なっていることに注意してください。 例えば、ISP縁のルータがコアの向こう側にVPRN会員資格と可到達性情報を広めるのにルーティング・プロトコル便乗を使用するなら、それはCPEルーティングインスタンスからコアルーティングインスタンスまで適当にラベルされたルートを再配付するかもしれません。 各インスタンスに使用されるルーティング・プロトコルの衝撃を吸収します、そして、その都度どんな適当なプロトコルも使用できます。 同じプロトコル、または同じスタッブさえ可到達性情報収集メカニズムをリンクするという要件が全くなくて、特定のVPRNのそれぞれのCPEルータと関連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はこのデカップリングで一般的な(すべてのVPRNsの向こう側の)イントラ-VPRN可到達性メカニズム、および一般的なスタッブリンク可到達性メカニズムを配布することができます、互いと、特定のIGPから顧客ネットワークに使用される孤立しているこれらのメカニズムで。 前者の場合、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
うるさい顧客サイトが同時に複数のVPRNs(または、同時にVPRNとインターネットの両方で交信することを願っている)に属すならISP縁のルータには明白にスタッブリンクアドレス接頭語を特定のVPRNsに写像するいくつかの手段がなければならないことに注意してください。 簡単な道は複数のスタッブリンク、1VPRNあたり1つを持つことです。 また、複数のVPRNsの1つ以上のスタッブのリンクを動かすのも可能です。 確実にすることによってこれができるだろう、(適切に構成であること
Gleeson, et al. Informational [Page 32] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[32ページ]のRFC2764IP
ISP edge router to know) that particular disjoint address prefixes are mapped into separate VPRNs, or by tagging the routing advertisements from the CPE router with the appropriate VPN identifier. For example if MPLS was being used to convey stub link reachability information, different MPLS labels would be used to differentiate the disjoint prefixes assigned to particular VPRNs. In any case, some administrative procedure would be required for this coordination.
知るISP縁のルータ) 事項は別々のVPRNsに写像されるか、または適切なVPN識別子でCPEルータからルーティング広告にタグ付けをするアドレス接頭語をばらばらにならせます。 例えば、MPLSがスタッブリンク可到達性情報を伝えるのに使用されているなら、異なったMPLSラベルが差別化するのに使用される、特定のVPRNsに割り当てられた接頭語をばらばらにならせてください。 どのような場合でも、何らかの行政手続がこのコーディネートに必要でしょう。
5.3.3.2 Configuration
5.3.3.2 構成
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.
手動で、それぞれのスタッブリンクの向こう側の可到達性情報(アドレスか接頭語のセットが小さくて、静的であるなら、適切であるかもしれない)を構成できました。
5.3.3.3 ISP Administered Addresses
5.3.3.3 ISPの管理されたアドレス
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クライアントと顧客のIPを検索するのがDHCPリレーとしてRadiusサーバからの使用に演説するか、または演じられるので行動して、それが顧客サイトにリレーされるのでDHCP応答メッセージを調べていて。 この様に、縁のルータはスタッブリンク可到達性情報のテーブルを確立できます。 これらのアドレス割当機構は独身のホストにアドレスを割り当てるのに通常使用されますが、いくつかのベンダーがアドレス接頭語を割り当てることができる拡大を加えました、いくつかの場合におけるCPEデバイスが「ミニDHCP」サーバとして機能して、顧客サイトのホストのためにアドレスを割り当てていて。
Note that with these schemes it is the responsibility of the address allocation server to ensure that each site in the VPN received a disjoint address space. Note also that an ISP would typically only use this mechanism for small stub sites, which are unlikely to have backdoor links.
これらの体系で、VPNの容認されたaの各サイトがアドレス空間をばらばらにならせるのを保証するのが、アドレス配分サーバの責任であることに注意してください。 また、ISPが小さいスタッブサイトにこのメカニズムを通常使用するだけであることに注意してください。(サイトには裏口のリンクがありそうにはありません)。
5.3.3.4 MPLS Label Distribution Protocol
5.3.3.4 MPLSラベル分配プロトコル
In cases where the CPE router runs MPLS, LDP can be used to convey the set of prefixes at a stub site to a VPRN edge router. Using the downstream unsolicited mode of label distribution the CPE router can distribute a label for each route in the stub site. Note however that the processing carried out by the edge router in this case is more than just the normal LDP processing, since it is learning new routes via LDP, rather than the usual case of learning labels for existing routes that it has learned via standard routing mechanisms.
CPEルータがMPLSを実行する場合では、スタッブサイトをVPRN縁のルータまで接頭語のセットを運ぶのに自由民主党を使用できます。 ラベル分配の川下の求められていない方法を使用して、CPEルータはスタッブサイトの各ルートにラベルを分配できます。 しかしながら、この場合縁のルータによって行われている処理がまさしく自由民主党を通して新しいルートを学んで以来の通常の自由民主党の処理よりさらに、既存のルートにラベルについて知る普通のケースよりむしろ、標準のルーティングメカニズムで学んだということであることに注意してください。
Gleeson, et al. Informational [Page 33] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[33ページ]のRFC2764IP
5.3.4 Intra-VPN Reachability Information
5.3.4 イントラ-VPN可到達性情報
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スタッブリンク(負荷分割法を実行しない)は、アドレス空間がいかなる他のもばらばらになると主張します、明白なルーティングを可能にするために。 必要ではありませんが、また、実際的な言い方をするなら、一般に、このアドレス空間がよく仕切られるのも、望ましく、すなわち、特定であることで、ルータを1縁あたりのアドレス接頭語的にばらばらにならせてください、多くのホストルートを維持して、広める必要性を排除するために。
The problem of intra-VPN reachability information dissemination can be solved in a number of ways, some of which include the following:
多くの方法でイントラ-VPN可到達性情報普及の問題を解決できます:その或るものは以下を含んでいます。
5.3.4.1 Directory Lookup
5.3.4.1 ディレクトリルックアップ
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で議論した同じディレクトリ同期問題がこの場合適用されることに注意してください。
5.3.4.2 Explicit Configuration
5.3.4.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.
互いに構成されて、それぞれの縁のルータに関連しているアドレス空間は明らかにそうであるかもしれません。ルータ。 これは、特に任意のtopologiesが使用されているときの明確に非スケーラブルなソリューションであり、また、第一に、マネージメントシステムがどうそのような情報を学ぶかに関する疑問を挙げます。
5.3.4.3 Local Intra-VPRN Routing Instantiations
5.3.4.3 ローカルのイントラ-VPRNルート設定具体化
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.
このアプローチでは、それぞれの縁のルータは1VPRNあたり1つのルーティング・プロトコル('仮想のルータ')のインスタンスを実行します、イントラ-VPRN可到達性情報を広めるためにVPRNトンネルの向こう側にそれぞれの同輩縁のルータに稼働していて。 ルーティング・プロトコル自体がどんなトポロジーも中を走らせることができるので、容易に完全なメッシュと任意のVPRN topologiesの両方をサポートすることができます。 イントラ-VPRNルーティング広告は直接同輩縁のルータに扱われるか、またはトンネルの特定のメカニズムによって正常なトンネルデータ・パケットと区別されるかもしれません。
Gleeson, et al. Informational [Page 34] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[34ページ]のRFC2764IP
Note that this intra-VPRN routing protocol need have no relationship either with the IGP of any customer site or with the routing protocols operated by the ISPs in the IP backbone. Depending on the size and scale of the VPRNs to be supported either a simple protocol like RIP or a more sophisticated protocol like OSPF could be used. Because the intra-VPRN routing protocol operates as an overlay over the IP backbone it is wholly transparent to any intermediate routers, and to any edge routers not within the VPRN. This also implies that such routing information can remain opaque to such routers, which may be a necessary security requirements in some cases. Also note that if the routing protocol runs directly over the same tunnels as the data traffic, then it will inherit the same level of security as that afforded the data traffic, for example strong encryption and authentication.
このイントラ-VPRNルーティング・プロトコルにはどんな顧客サイトのIGPかIPバックボーンにおけるISPによって操作されるルーティング・プロトコルとの関係も全くある必要はないことに注意してください。 RIPのような簡単なプロトコルかOSPFのように、より精巧なプロトコルのどちらかであるとサポートされるためにVPRNsのサイズとスケールに依存するのを使用できました。 イントラ-VPRNルーティング・プロトコルがオーバレイとしてIPバックボーンの上で作動するので、それは完全にどんな中間的ルータとも、そして、VPRNの中のどんな縁のルータにも透明です。 また、これは、そのようなルーティング情報がいくつかの場合、必要なセキュリティ要件であるかもしれないそのようなルータに不透明なままで残ることができるのを含意します。 また、ルーティング・プロトコルが直接データ通信量と同じトンネル中を走らせるとそれがデータ通信量、例えば、強い暗号化、および認証を提供したとき同じレベルのセキュリティを相続することに注意してください。
If the tunnels over which an intra-VPRN routing protocol runs are dedicated to a specific VPN (e.g. a different multiplexing field is used for each VPN) then no changes are needed to the routing protocol itself. On the other hand if shared tunnels are used, then it is necessary to extend the routing protocol to allow a VPN-ID field to be included in routing update packets, to allow sets of prefixes to be associated with a particular VPN.
イントラ-VPRNルーティング・プロトコルが稼働するトンネルが特定のVPNに捧げられるなら(例えば異なったマルチプレクシング分野は各VPNに使用されます)、変化は全くルーティング・プロトコル自体に必要ではありません。 他方では、共有されたトンネルが使用されているなら、VPN-ID分野がルーティングアップデートパケットに含まれているのを許容するためにルーティング・プロトコルを広げるのが、接頭語のセットが特定のVPNに関連しているのを許容するのに必要です。
5.3.4.4 Link Reachability Protocol
5.3.4.4 リンク可到達性プロトコル
By link reachability protocol is meant a protocol that allows two nodes, connected via a point-to-point link, to exchange reachability information. Given a full mesh topology, each edge router could run a link reachability protocol, for instance some variation of MPLS CR-LDP, across the tunnel to each peer edge router in the VPRN, carrying the VPN-ID and the reachability information of each VPRN running across the tunnel between the two edge routers. If VPRN membership information has already been distributed to an edge router, then the neighbor discovery aspects of a traditional routing protocol are not needed, as the set of neighbors is already known. TCP connections can be used to interconnect the neighbors, to provide reliability. This approach may reduce the processing burden of running routing protocol instances per VPRN, and may be of particular benefit where a shared tunnel mechanism is used to connect a set of edge routers supporting multiple VPRNs.
リンクのそばでは、可到達性プロトコルは意味されて、それがポイントツーポイント接続を通して接続された2つのノードを許容するプロトコルが可到達性情報を交換するということです。 完全なメッシュトポロジーを考えて、それぞれの縁のルータはリンク可到達性プロトコル、例えばMPLS CR-自由民主党の何らかの変化を実行するかもしれません、VPRNのそれぞれの同輩縁のルータへのトンネルの向こう側に、2つの縁のルータの間のトンネルの向こう側にVPN-IDとそれぞれのVPRN稼働の可到達性情報を運んで。 VPRN会員資格情報が既に縁のルータに分配されたなら、伝統的なルーティング・プロトコルの隣人発見局面は必要ではありません、隣人のセットが既に知られているように。 隣人とインタコネクトして、信頼性を提供するのにTCP接続を使用できます。 このアプローチは、VPRN単位で実行しているルーティング・プロトコルインスタンスの処理負担を減少させて、共有されたトンネルメカニズムが複数のVPRNsをサポートする1セットの縁のルータを接続するのに使用されるところの特別の利益のものであるかもしれません。
Another approach to developing a link reachability protocol would be to base it on IBGP. The problem that needs to be solved by a link reachability protocol is very similar to that solved by IBGP - conveying address prefixes reliably between edge routers.
リンク可到達性プロトコルを開発することへの別のアプローチはそれをIBGPに基礎づけるだろうことです。 リンク可到達性プロトコルによって解決される必要がある問題は縁のルータの間にアドレス接頭語を確かに伝えて、IBGPによって解決されたそれと非常に同様です。
Gleeson, et al. Informational [Page 35] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[35ページ]のRFC2764IP
Using a link reachability protocol it is straightforward to support a full mesh topology - each edge router conveys its own local reachability information to all other routers, but does not redistribute information received from any other router. However once an arbitrary topology needs to be supported, the link reachability protocol needs to develop into a full routing protocol, due to the need to implement mechanisms to avoid loops, and there would seem little benefit in reinventing another routing protocol to deal with this. Some reasons why partially connected meshes may be needed even in a tunneled environment are discussed in section 5.1.1.
リンク可到達性プロトコルを使用して、完全なメッシュトポロジーをサポートするのは簡単です--それぞれの縁のルータは、それ自身のローカルの可到達性情報を他のすべてのルータに伝えますが、いかなる他のルータからも受け取られた情報を再配付しません。 任意のトポロジーが、どんなに一度サポートされる必要があっても、リンク可到達性プロトコルは、完全なルーティング・プロトコルの上に伸びる必要があります、輪を避けるためにメカニズムを実装する必要性のため、そして、これは対処する別のルーティング・プロトコルを再発明する際に利益にほとんど見えないでしょう。 セクション5.1.1で部分的に接続されたメッシュがトンネルを堀られた環境でさえ必要であるかもしれないいくつかの理由について議論します。
5.3.4.5 Piggybacking in IP Backbone Routing Protocols
5.3.4.5 IPバックボーンルーティング・プロトコルでは便乗すること。
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の特定の推進メカニズムを実装して、正しい出口のスタッブリンクを決定する必要があるでしょう。 この利点は組み立てられて、維持される必要がある異なったトンネルかトンネルラベル情報の数をかなり減少させるかもしれないということです。 この選択が純粋にローカルの方法であり、リモート縁のルータに目に見えないことに注意してください。
5.3.5 Tunneling Mechanisms
5.3.5 トンネリングメカニズム
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
トンネルメッシュをセットアップすることへの1つのアプローチが二地点間IPトンネルを使用することであり、セクション3.0でそのようなトンネルへの要件と問題について議論しました。 例えば、手動の構成を通してトンネル設立ができますが、これはします。
Gleeson, et al. Informational [Page 36] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[36ページ]のRFC2764IP
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.
かみ合っているリンクの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によって提供された'トンネル'を指すのに多点を使用することです。 IPトンネリングのフォームであるとMPLSを考えることができます、[38]で有名であることでMPLSパケットのラベルがルーティングのために、パケット自体に関するアドレス指定情報から衝撃を吸収されるという決定を許すので。 特定の出口ポイント(すなわち、縁のルータのスタッブリンク)の上でサポートされる特定のVPRNアドレス接頭語に特定のセットのMPLSラベルを関連づけて、したがって、明らかにラベルする他の縁のルータとルートトラフィックを特定のVPRNスタッブリンクに許容するのにMPLSラベル分配メカニズムを使用できます。
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ネットワークの中のデータ機密保護が接続指向のネットワークのように固まる明白なラベルで暗に示されているという事実の関数です、Frame Relayなどのように。 これは、したがって、データ機密保護に関する顧客心配を少なくして、したがって、より少ないプロセッサの徹底的なセキュリティー対策(例えば、IPSec)を必要とするかもしれません。 しかしながら、MPLSがある他の潜在的安全上の配慮があります。 認証や、秘密性や、非拒否などのセキュリティ機能のどんなダイレクトサポートもありません、そして、信頼はそんなに中間的なMPLS手段のために(異なった管理ドメインに属すかもしれません) ルータ、まさしくどの会員資格と接頭語可到達性情報を伝えられて、信じなければならないかを通していずれの縁のルータ自体もモデル化しません。
5.4 Multihomed Stub Routers
5.4 Multihomedスタッブルータ
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つの唯一無二のVPRN縁のルータに関連づけられるとそれとなく仮定しました。 一般に、この制限はVPRN操作への少しも変化なしでリラックスできるべきです、信頼性のためのマルチホーミングと他の理由への一般市場関心を考えて。 特定スタッブルータが複数の余分なリンクを支えて、次に、スタッブリンク可到達性メカニズムが同じVPRN縁のルータ、または、2つ以上の異なったVPRN縁のルータに接続されたリンクでそうする与えられた何時でも操作上の1つだけで、両方がアクティブなリンクの損失、およびバックアップリンクの起動を発見する場合で。 前の状況で、以前接続されたVPRN縁のルータは、スタッブノードに可到達性の広告を出すのをやめるでしょう、現在アクティブなリンクがあるVPRN縁のルータが可到達性の広告を出し始めるでしょうが、したがって、接続性を回復して。
Gleeson, et al. Informational [Page 37] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[37ページ]のRFC2764IP
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の向こう側に可到達性に関するどんな問題も引き起こすべきでなくて、排除する適切な手段は輪にされます--例えば、それぞれの広告を出している接頭語に関連しているベクトル測定基準を遠ざけてください。
5.5 Multicast Support
5.5 マルチキャストサポート
Multicast and broadcast traffic can be supported across VPRNs either by edge replication or by native multicast support in the backbone. These two cases are discussed below.
VPRNsの向こう側に縁の模写かバックボーンにおけるネイティブのマルチキャストサポートでマルチキャストと放送トラフィックをサポートすることができます。 以下でこれらの2つのケースについて議論します。
5.5.1 Edge Replication
5.5.1 縁の模写
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縁のルータで実行されるかもしれません。 標準のマルチキャストルーティング・プロトコルの実行しているインスタンスでこれができました、例えば、プロトコル無党派Multicast(PIM)[39]かディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(DVMRP)[40]、オンであり、同様に、VPRNトンネルを通って、それぞれのVPRN縁のルータの間では、プロトコルを発送するそのユニキャストはイントラ-VPNユニキャストの可到達性を決定するためにそれぞれのVPRN縁のルータで実行されるかもしれません、セクション5.3.4で議論するように。 あるいはまた、また、リンク可到達性プロトコルがイントラ-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
どちらの場合ではも、そこでは、VPRN縁のルータがどの特定のマルチキャストグループが各サイトで要求されたか、そして、どのソースが各サイトに出席していたかを決定するのを許容する何らかのメカニズムであることが必要でしょう。 一般に、どうこれができたかは、各サイトのCPEスタッブルータの能力の機能でしょう。 これらがマルチキャストルーティング・プロトコルを実行するなら、それらはそれぞれのVPRN縁のルータで直接同等なプロトコルと対話できます。 CPEデバイスがマルチキャストルーティング・プロトコルを実行しないなら、インターネットGroup Managementプロトコル(IGMP)がないとき[41] 顧客サイトをproxyingするのはブリッジするデバイスを通してVPRN縁のルータに関連づけられたただ一つのサブネットに制限されるでしょう、IGMPメッセージの範囲がそうように
Gleeson, et al. Informational [Page 38] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[38ページ]のRFC2764IP
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.
ただ一つのサブネットに制限されています。 強制的なtopologiesのマルチキャストルーティング・プロトコルを実行しないで、しかしながら、IGMP-proxyingを使用して、CPEルータはマルチキャスト推進に従事できます。 顧客サイトへのインタフェースに、CPEルータはIGMPのルータ機能を実行します、そして、VPRN縁のルータへのインタフェースに、それはIGMPのホスト機能を実行します。
5.5.2 Native Multicast Support
5.5.2 ネイティブのマルチキャストサポート
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縁のルータがバックボーンの向こう側にイントラ-VPRNマルチキャストトラフィックを固有のIPマルチキャスト分配メカニズムに写像するところです。 イントラ-VPRNマルチキャストにはイントラ-VPRNユニキャストトラフィックとしての一般的なバックボーントラフィックからの分離のための同じ要件があることに注意してください。 現在の、マルチキャストのネイティブのサポートを持っている唯一のIPトンネリングメカニズムがMPLSです。 他方では、MPLSがIPマルチキャストパケットのネイティブの輸送をサポートしている間、追加メカニズムがイントラ-VPRNマルチキャストのサポートのためにこれらのメカニズムを利用するのが必要でしょう。
For instance, each VPRN router could prefix multicast group addresses within each VPRN with the VPN-ID of that VPRN and then redistribute these, essentially treating this VPN-ID/intra-VPRN multicast address tuple as a normal multicast address, within the backbone multicast routing protocols, as with the case of unicast reachability, as discussed previously. The MPLS multicast label distribution mechanisms could then be used to set up the appropriate multicast LSPs to interconnect those sites within each VPRN supporting particular multicast group addresses. Note, however, that this would require each of the intermediate LSRs to not only be aware of each intra-VPRN multicast group, but also to have the capability of interpreting these modified advertisements. Alternatively, mechanisms could be defined to map intra-VPRN multicast groups into backbone multicast groups.
例えば、それぞれのVPRNルータは、そのVPRNのVPN-IDと共に各VPRNの中にマルチキャストグループアドレスを前に置いて、次に、これらを再配付するかもしれません、正常なマルチキャストアドレスとして本質的にはこのイントラVPN-ID/VPRNマルチキャストアドレスtupleを扱って、バックボーンマルチキャストルーティング・プロトコルの中で、ユニキャストの可到達性に関するケースのように、以前に議論するように。 そして、特定のマルチキャストグループアドレスをサポートしながら各VPRNの中でそれらのサイトとインタコネクトするために適切なマルチキャストLSPsをセットアップするのにMPLSマルチキャストラベル分配メカニズムを使用できました。 しかしながら、これが、それぞれの中間的LSRsがそれぞれのイントラ-VPRNマルチキャストグループを意識しているだけではないのを必要とするでしょうが、これらを解釈する能力を持っているのが広告をまた変更したことに注意してください。 あるいはまた、イントラ-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マルチキャストトラフィックを分配することによってそのようなトンネリングメカニズムを広げるのが可能であると判明するかもしれません。 縁のVPRNルータは求められていないマルチキャストグループを無視するかもしれません。 あるいはまた、また、バックボーンマルチキャストグループアドレスの配分が特定のイントラ-VPRNマルチキャストグループ、次に、これらを利用するのを許容するためにメカニズムを定義できました、バックボーンマルチキャストプロトコルを通して、グループの中でイントラ-VPRNマルチキャストトラフィックの推進をそれらのノードだけに制限するために上で議論するように。
Gleeson, et al. Informational [Page 39] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[39ページ]のRFC2764IP
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のSecure Multicast Group(SMuG)は、プロトタイプ解決策を見いだすためにセットアップされました。(次に、解決策は標準化のためにIETF IPSecワーキンググループに通過されるでしょう)。
However considerably more development is needed before scalable secure native multicast mechanisms can be generally deployed.
しかしながら、一般に、スケーラブルな安全な固有のマルチキャストメカニズムを配布することができる前にかなり多くの開発が必要です。
5.6 Recommendations
5.6 推薦
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の機能性をサポートするために開発された様々な提案は2つのグループに露骨に分類できます--仮想のルーティングアプローチ([12]([14]))を使用するVPN会員資格、そして/または、可到達性情報([13]を分配するためのアプローチを背負いながらルータを利用するもの、[15])、およびもの。 メカニズムが説明したいくつかの場合では、まさしく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に基づく会員資格分配プロトコルを開発するのは役に立つかもしれません。 IPのためのセクション3.2で概説されたプロトコルにトンネルを堀るプロトコル拡大に結合されると、これはIPバックボーンの上でプロトコルの完全なセットの基礎と共同利用できるVPRNsがその長さであるとサポートするメカニズムに複数の政権を供給するでしょう。 他の主要な機能性が必要とした注意--顧客可到達性情報の学習と分配、標準のルーティング・プロトコルのインスタンスで実行できます、どんなプロトコル拡大の必要性なしでも。
Also for the constrained case of a full mesh topology, the usefulness of developing a link reachability protocol could be examined, however the limitations and scalability issues associated with this topology may not make it worthwhile to develop something specific for this case, as standard routing will just work.
しかしながら、完全なメッシュトポロジーの制約つきケースがないかどうかも、リンク可到達性プロトコルを開発する有用性を調べることができて、このトポロジーに関連している制限とスケーラビリティ問題でこのような場合何か特定のものを開発するのは価値があるようにならないかもしれません、標準のルーティングがただ利くとき。
Extending routing protocols to allow a VPN-ID to carried in routing update packets could also be examined, but is not necessary if VPN specific tunnels are used.
ルーティングアップデートパケットで運ばれるのにVPN-IDを許容するためにルーティング・プロトコルを広げるのは、また、調べることができましたが、VPNの特定のトンネルが使用されているなら、必要ではありません。
Gleeson, et al. Informational [Page 40] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[40ページ]のRFC2764IP
6.0 VPN Types: Virtual Private Dial Networks
6.0 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.
Virtual兵士の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を通して作られたダイヤル接続にリモート・ユーザーへのアクセスの通ることを許します、ユーザがアクセスネットワークの向こう側にネットワークアクセス・サーバーにPPP接続をセットアップしていて。そのポイントでは、PPPセッションは、Radius[44]のような標準プロトコルを実行するAAAシステムを使用することで認証されます。 そのようなシステムの普及している展開を考えて、どんな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 Concentrator(LAC)からリモートa L2TP Network Server(LNS)までのユーザPPPセッションについて拡大を考慮するLayer2Tunnelingプロトコル(L2TP)[8]を開発しました。 これはL2TPを使用できる2つの全く異なったシナリオに反映されます--L2TPプロトコル自体が2つの以前のプロトコル、Layer2Forwardingプロトコル(L2F)[45]、およびPointからポイントへのTunnelingプロトコル(PPTP)[46]に基づいて、以下でセクション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ネットワークの上でL2TPの使用に焦点を合わせますが(UDPを使用して)、また、L2TPはATMかFrame Relayなどの他のプロトコルの直接上に実行されるかもしれません。 明確にどうそのようなトンネルを固定などかなどの非IPネットワークの上の実行しているL2TPに関連する問題はここで扱われません。
6.1 L2TP protocol characteristics
6.1 L2TPプロトコルの特性
This section looks at the characteristics of the L2TP tunneling protocol using the categories outlined in section 3.0.
このセクションは、セクション3.0で概説されたカテゴリを使用することでL2TPトンネリングプロトコルの特性を見ます。
6.1.1 Multiplexing
6.1.1 マルチプレクシング
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終点の間に、複数のL2TPトンネルがあることができます、トンネルイド、およびトンネルの中の複数のセッションで特定されるように、セッションイドによって特定されるように。
Gleeson, et al. Informational [Page 41] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[41ページ]のRFC2764IP
6.1.2 Signalling
6.1.2 合図
This is supported via the inbuilt control connection protocol, allowing both tunnels and sessions to be established dynamically.
トンネルとセッションの両方がダイナミックに確立されるのを許容して、これはinbuiltコントロール接続プロトコルでサポートされます。
6.1.3 Data Security
6.1.3 データ機密保護
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制御プロトコル自体にセキュリティを提供しません。 この場合、IPSecからIPへのバックボーン[47]、[48]、または関連するメカニズムと組み合わせて非IPのバックボーン[49]にそれを実行することによって、L2TPをさらに固定できるでしょう。
The interaction of L2TP with AAA systems for user authentication and authorization is a function of the specific means by which L2TP is used, and the nature of the devices supporting the LAC and the LNS. These issues are discussed in depth in [50].
ユーザー認証と承認のAAAシステムとのL2TPの相互作用は、L2TPが使用されている特定の手段の機能と、LACとLNSをサポートするデバイスの自然です。 [50]でこれらの問題について徹底的に議論します。
The means by which the host determines the correct LAC to connect to, and the means by which the LAC determines which users to further tunnel, and the LNS parameters associated with each user, are outside the scope of the operation of a VPDN, but may be addressed, for instance, by evolving Internet roaming specifications [51].
各ユーザに関連しているホストが、正しいLACが接続するとどれに決心するか、そして、LACがどのユーザを向こうのトンネルに決定する手段、およびLNSパラメタによる手段は、VPDNの操作の範囲の外にありますが、例えば、インターネットローミング仕様[51]を発展することによって、扱われるかもしれません。
6.1.4 Multiprotocol Transport
6.1.4 Multiprotocol輸送
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自身が「マルチ-プロトコル」であるので「マルチ-プロトコル」トラフィックを運ぶのに使用できます。
6.1.5 Sequencing
6.1.5 配列
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)に対処できることを決定するなら、それは配列の使用を無効にするかもしれません。
Gleeson, et al. Informational [Page 42] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[42ページ]のRFC2764IP
6.1.6 Tunnel Maintenance
6.1.6 トンネルメインテナンス
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によって使用されます。
6.1.7 Large MTUs
6.1.7 大きいMTUs
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自身には、分割と再アセンブリ能力のinbuiltサポートが全くありませんが、ひかれると、必要なら、UDP/IP IP断片化は行われるでしょう。 LACかLNSが断片化を排除するためにPPPを通して交渉されたMaximum Receive Unit(MRU)を調整するかもしれないことに注意してください、LACとLNSの間の経路でそれでMTUに関する知識を使用するなら。 このために、MTU発見のケースの使用を許すという提案がL2TPトンネルがIPフレーム[52]を輸送するところにあります。
6.1.8 Tunnel Overhead
6.1.8 トンネルオーバーヘッド
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で、より詳しくこれについて議論します。
6.1.9 Flow and Congestion Control
6.1.9 流れと輻輳制御
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を見てください。
6.1.10 QoS / Traffic Management
6.1.10 QoS/輸送管理
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ビットの優先権分野を含んでいます。(地方の列を作りとトランスミッションの間に優遇(例えば、keepalives)を必要とするかもしれないパケットにそれを設定できます)。 L2TPには、また、透過的にPPPを広げることによって、マルチリンクPPP[53]のようなPPPメカニズムとその関連制御プロトコル[54]の固有のサポートがあります。(制御プロトコルは、オンデマンドの帯域幅がユーザ要件を満たすのを許容します)。
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]を許容する提案があります。
Gleeson, et al. Informational [Page 43] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[43ページ]のRFC2764IP
6.1.11 Miscellaneous
6.1.11 その他
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に関連している正常なアドレス割当機構に取って代わるのを試みません。 LNSによるアドレスは、PPP手順を用いることでしたがって、あいまいな言葉でPPPセッションを開始するホストに割り当てられるでしょう。 このアドレシングはLACとLNSとのコミュニケーションに使用されるアドレシングに関係がないかもしれません。 また、LNSは、ホストと、そして、リモートホストから発送するメカニズムが必要であるどんな推進にもトラフィックをサポートする必要があるでしょう。
6.2 Compulsory Tunneling
6.2 強制的なトンネリング
Compulsory tunneling refers to the scenario in which a network node - a dial or network access server, for instance - acting as a LAC, extends a PPP session across a backbone using L2TP to a remote LNS, as illustrated below. This operation is transparent to the user initiating the PPP session to the LAC. This allows for the decoupling of the location and/or ownership of the modem pools used to terminate dial calls, from the site to which users are provided access. Support for this scenario was the original intent of the L2F specification, upon which the L2TP specification was based.
強制的なトンネリングは例えば、ダイヤルかネットワークがサーバにアクセスするというLACとして機能するネットワーク・ノードがバックボーンの向こう側にリモートLNSにL2TPを使用することでPPPセッションを延ばすシナリオを参照します、以下で例証されるように。 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.
可能な多くの異なった展開シナリオがあります。 以下のダイヤグラムで示された1つの例が、加入者ホストがLACとして機能するNASにダイヤルするところであり、IPネットワーク(例えば、インターネット)の向こう側にLNSとして作動するゲートウェイにトンネルを堀られます。 ゲートウェイは、企業ネットワークへのアクセスを提供して、企業ネットワーク自体におけるデバイスであるかもしれない、または顧客がLNSの機能性のメインテナンスをISPに社外調達した場合でISP縁のルータであるかもしれません。 別のシナリオはISPがインターネットへのアクセスを加入者に提供するのにL2TPを使用するところです。 加入者ホストは、LACとして機能するNASにダイヤルして、アクセスネットワークの向こう側にLNSとして機能するISP縁のルータにトンネルを堀られます。 そして、このISP縁のルータは加入者トラフィックをインターネットに入れます。 しかし、他のシナリオはISPがVPRN、またはVPRNとインターネットの両方への同時発生のアクセスと共にアクセスを加入者に提供するのにL2TPを使用するところです。
A VPDN, whether using compulsory or voluntary tunneling, can be viewed as just another type of access method for subscriber traffic, and as such can be used to provide connectivity to different types of networks, e.g. a corporate network, the Internet, or a VPRN. The last scenario is also an example of how a VPN service as provided to a customer may be implemented using a combination of different types of VPN.
VPDN、強制的であるか自発的のトンネリングを使用するか否かに関係なく、加入者トラフィックのためにただのタイプのアクセスをメソッドとみなして、異なったタイプのネットワーク、例えば、企業ネットワーク、インターネット、またはVPRNに接続性を供給するのにそういうものとして使用できるということであることができます。 また、最後のシナリオは顧客に提供されるVPNサービスがVPNの異なったタイプの組み合わせを使用することでどう実装されるかもしれないかに関する例です。
Gleeson, et al. Informational [Page 44] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[44ページ]のRFC2764IP
10.0.0.1
+----+
|Host|----- LAC ------------- LNS 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
10.0.0.1 +----+ |ホスト|----- ラック------------- LNS10.0.0.0/8+----+ / +-----+ ( ) +-----+ --------- /----| NAS|---(IPバックボーン)---| GW|----(社) ダイヤル+-----+ ( ) +-----+ (ネットワーク)接続------------- ---------
<------- L2TP Tunnel ------->
<。------- L2TPトンネル------->。
<--------------------- PPP Session ------->
<。--------------------- pppセッション------->。
Figure 6.1: Compulsory Tunneling Example
図6.1: 強制的なトンネリングの例
Compulsory tunneling was originally intended for deployment on network access servers supporting wholesale dial services, allowing for remote dial access through common facilities to an enterprise site, while precluding the need for the enterprise to deploy its own dial servers. Another example of this is where an ISP outsources its own dial connectivity to an access network provider (such as a Local Exchange Carrier (LEC) in the USA) removing the need for an ISP to maintain its own dial servers and allowing the LEC to serve multiple ISPs. More recently, compulsory tunneling mechanisms have also been proposed for evolving Digital Subscriber Line (DSL) services [56], [57], which also seek to leverage the existing AAA infrastructure.
強制的なトンネリングは元々展開のために大量のダイヤルサービスをサポートするネットワークアクセス・サーバーで意図しました、企業サイトへの共同施設を通したリモートダイヤルアクセスを考慮して企業がそれ自身のダイヤルサーバを配布する必要性を排除していて。 別のこの例はISPがそれ自身のダイヤルサーバを維持する必要性を取り除いて、LECが複数のISPに役立つのを許容しながらISPがアクセスネットワーク内の提供者(米国のLocal Exchange Carrier(LEC)などの)にそれ自身のダイヤルの接続性を社外調達するところです。 また、より最近、強制的なトンネリングメカニズムは、また、既存のAAAインフラストラクチャを利用しようとするDigital Subscriber線(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.
強制的なトンネルへの呼び出しルーティングは、LACがLNSのアイデンティティを決定するのを許容するのにセットアップされた初期のPPP呼び出しの何らかの局面を使用できるのを必要とします。 [50]に述べられるように、これらの局面はユーザアイデンティティを含むことができます、アクセスネットワークの何らかの局面を通して決定するように、起呼側番号、または被呼者の何らかの属性を含んでいて、PPP認証の間に要求されたアイデンティティのFully Qualified Domain Name(FQDN)などのように。
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はLNSとしてこの最初のLACに作動する中間的リレーデバイスへのトンネルを開始して、LACとして最終的なLNSに機能します)。 いくつかの場合、これがアクセスネットワーク内の提供者と、IPバックボーンプロバイダーと法人顧客の間の分裂に関係する管理の、または、組織的であるか規定の問題のため必要であるかもしれません。
Gleeson, et al. Informational [Page 45] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[45ページ]のRFC2764IP
6.3 Voluntary Tunnels
6.3 自発的のTunnels
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.
自発的のトンネリングは個々のホストがホストの上で起因するトンネルを使用することでリモートサイトに接続するケースを示します、中間ネットワークノードからのかかわり合いなしで、以下で例証されるように。 PPTP仕様(それの部品をL2TPに組み入れてある)は自発的のトンネリングモデルに基づきました。
As with compulsory tunneling there are different deployment scenarios possible. The diagram below shows a subscriber host accessing a corporate network with either L2TP or IPSec being used as the voluntary tunneling mechanism. Another scenario is where voluntary tunneling is used to provide a subscriber with access to a VPRN.
強制的なトンネリングのように、可能な異なった展開シナリオがあります。 以下のダイヤグラムは、L2TPかIPSecのどちらかが自発的のトンネリングメカニズムとして使用されている状態で加入者ホストが企業ネットワークにアクセスするのを示します。 別のシナリオは自発的のトンネリングがVPRNへのアクセスを加入者に提供するのに使用されるところです。
6.3.1 Issues with Use of L2TP for Voluntary Tunnels
6.3.1 L2TPの自発的のTunnelsの使用の問題
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アドレスがあることに注意してください--ホストが接続しているLAC-LNS IPトンネルへのもの、およびネットワークのためのPPPを通して通常割り当てられた別のもの。 自発的のトンネリングにL2TPを使用する利益は変更なしでPPPによって使用された既存の認証とアドレス割当機構は再利用できるということです。 例えば、LNSは、PPP PAPかCHAP交換を認証して、IPアドレスやDNSサーバのリストなどのホストが使用する設定情報を検索するためにまた、Radiusクライアントを含めて、Radiusサーバとコミュニケートするかもしれません。 そして、PPP IPCPプロトコルでこの情報をホストに渡すことができます。
10.0.0.1
+----+
|Host|----- ------------- 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
10.0.0.1 +----+ |ホスト|----- ------------- 10.0.0.0/8 +----+ / +-----+ ( ) +-----+ --------- /----| NAS|---(IPバックボーン)---| GW|----(社) ダイヤル+-----+ ( ) +-----+ (ネットワーク)接続------------- ---------
<-------------- L2TP Tunnel -------------->
with LAC on host
<-------------- PPP Session --------------> LNS on gateway
<。-------------- L2TPトンネル--------------LACがホスト<にある>。-------------- pppセッション--------------ゲートウェイの上の>LNS
or
または
<-------------- IPSEC Tunnel -------------->
<。-------------- IPSECトンネル-------------->。
Figure 6.2: Voluntary Tunneling Example
図6.2: 自発的のトンネリングの例
Gleeson, et al. Informational [Page 46] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[46ページ]のRFC2764IP
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/超能力/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/超能力/IP/ppp/AHDLC
In this case IPSec is used in tunnel mode, with the tunnel terminating either on an IPSec edge device at the enterprise site, or on the provider edge router connected to the enterprise site. There are two possibilities for the IP addressing of the host. Two IP addresses could be used, in a similar manner to the L2TP case. Alternatively the host can use a single public IP address as the source IP address in both inner and outer IP headers, with the gateway performing Network Address Translation (NAT) before forwarding the traffic to the enterprise network. To other hosts in the enterprise network the host appears to have an 'internal' IP address. Using NAT has some limitations and restrictions, also pointed out in [58].
この場合、IPSecはトンネルモードで使用されます、トンネルが企業サイトのIPSecエッジデバイスの上、または、企業サイトに接続されたプロバイダー縁のルータの上で終わっていて。 ホストのIPアドレシングのための2つの可能性があります。 同じようにL2TPケースに2つのIPアドレスを使用できました。 あるいはまた、ホストはソースIPアドレスとして内側の、そして、外側の両方のIPヘッダーでただ一つの公共のIPアドレスを使用できます、トラフィックを企業網に送る前にゲートウェイがNetwork Address Translation(NAT)を実行していて。 企業網の他のホストにとって、ホストは、'内部'の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の潜在的な問題の別の領域はIPバックボーンの上のL2TPトンネルを通って実装されたリンクレイヤの特性がシリアル・ラインで動かされたリンクレイヤに全く異なっているという事実のためです、L2TP仕様自体で議論するように。 例えば、特に圧縮が使用中であるなら、不十分に選ばれたPPPパラメタは頻繁なリセットとタイムアウトにつながるかもしれません。 これがL2TPトンネルがそうするかもしれないからであるmisorderパケット、静かに、パケットを下げるかもしれません。通常、そのどちらもシリアル・ラインの上に起こりません。 また、一般的なパケット損失率もネットワークの混雑のためにかなり高いかもしれません。 L2TPヘッダーの一連番号分野を使用すると、misordering問題は扱われます、そして、また、LACとLNSが自発的のトンネリングのようにPPP終点があるコインシデンスであるケースにおいて、下げられたパケットを検出して、使用中のどんな圧縮実体にも適当な指示を通過するのに一連番号分野は使用できます。(実体は、両端での同期における圧縮歴史を保管するためにそのような知識を通常必要とします)。 (事実上、LACがパケット損失のしるしを与えるために故意にPPPホストに崩壊したフレームを発行しなければならないかもしれないので、これは強制的なトンネリングの問題の以上です、そして、何らかのハードウェアはこれを許容しないかもしれません。)
Gleeson, et al. Informational [Page 47] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[47ページ]のRFC2764IP
6.3.2 Issues with Use of IPSec for Voluntary Tunnels
6.3.2 IPSecの自発的のTunnelsの使用の問題
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マシンからお金を得ています--あなたはカードと暗証番号番号を必要とします。) 現在ユーザー認証を実行するために使用中の既存のレガシー体系の多くが、現実に非対称であり、IKEによってサポートされません。 最も一般的な既存のユーザー認証メカニズムは、ユーザとアクセス・サーバーの間でPPPを使用して、アクセス・サーバーと認証サーバの間でRadiusを使用することです。遠隔アクセスのために、この場合起こる認証交換(例えば、PAPかCHAP交換)は、非対称です。 また、初期のセッションが現在のユーザがセッションを開始したのと同じ人であることを保証するために確立された後にCHAPは、いつでも、reauthenticateへのネットワークのための能力がユーザであるとサポートします。
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はマシン認証の強力な支持を提供しますが、それには、どんなフォームのユーザー認証のサポートも制限するだけであり、非対称のユーザー認証のサポートが全くありません。 前共有されたキーとして使用されるキーを引き出すのにユーザパスワードを使用できる間、リモートアクセス環境にこれをIKE Main Modeと共に使用できません、ユーザには固定IPアドレスがなくて、また代わりにAggressive Modeを使用できますが、これがアイデンティティ保護を全く提供しないとき。 このために、IPSecとのユーザのレガシーの非対称のレベル認証体系のサポートを考慮するという多くの提案がありました。 [59]は新しいIKE交換処理を定義します--トランザクション交換(Request/回答とSet/の両方を考慮する)はメッセージ系列を承認します、そして、また、それはクライアントIPスタック構成に使用できる属性を定義します。 [60]と[61]は、ユーザー認証を実行するためにIKE Phase1とPhase2回の交換の間に行われたトランザクション交換処理を使用するメカニズム、またはそのような一連の交換について説明します。 異なるアプローチであり、それは、IKEプロトコル自体を広げていなくて、[62]で説明されます。 このアプローチによるユーザはセキュリティゲートウェイとその時がある1SAがセットアップするPhaseを設立します。ゲートウェイへのPhase2SA。(存在認証プロトコルはそれに実行されます)。 ゲートウェイは、プロキシとして務めて、認証サーバにプロトコルメッセージをリレーします。
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
また、さらに、IPSecの上にリモートホストがIPアドレスと他の設定情報によって構成されるのを許容するという提案がありました。 例えば、[63]はリモートホストが最初にPhaseを設立するメソッドを説明します。セキュリティゲートウェイとその時がある1SAがPhase2SAをゲートウェイにセットアップする、終わっている、どれ、DHCP
Gleeson, et al. Informational [Page 48] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[48ページ]のRFC2764IP
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.
プロトコルは実行されます。 ゲートウェイは、プロキシとして務めて、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の機能性のもう一つの側面は「マルチ-プロトコル」操作です、IPSecの上のブリッジすることをサポートするのが必要でしょう、したがって、IP以外のネットワーク層プロトコルを運んで、リンクレイヤプロトコルを運ぶのさえ必要(例えば、イーサネット)があるかもしれません。 セクション3.1.4でこれについて議論します。
The methods of supporting legacy user authentication and host configuration capabilities in a remote access environment are currently being discussed in the IPSec working group.
リモートアクセス環境におけるレガシーユーザー認証とホスト構成能力をサポートするメソッドは現在、IPSecワーキンググループで議論することです。
6.4 Networked Host Support
6.4 ネットワークでつながれたホストサポート
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などの近作は、このモデル[57]を模写するのを試みました、既存のAAAシステムの再使用を考慮するために。しかしながら、パーソナルコンピュータの増殖、ホームと中小企業におけるプリンタと他のネットワーク器具、およびネットワークのかつて険悪なコストはますます直接接続されたホストモデルに挑戦しています。 ますます、ほとんどのホストが小さいことを通したインターネット、通常イーサネット、ローカル・エリア・ネットワークにアクセスするでしょう。
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情報は対話で交換されます)。 このシナリオを扱うのを多くの提案をしました:
6.4.1 Extension of PPP to Hosts Through L2TP
6.4.1 L2TPを通したホストへのpppの拡大
A number of proposals (e.g. [56]) have been made to extend L2TP over Ethernet so that PPP sessions can run from networked hosts out to the network, in much the same manner as a directly attached host.
多くの提案、([56]) 例えば、作られていて、イーサネットの上でL2TPを広げてください。そうすれば、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.
また、直接ホストが接続するのが適切であるアクセス・サーバーを見つけるのを許容するのに放送メカニズムを使用するイーサネット(PPPOE)[64]にPPPを写像するための仕様があります。 そして、PPPセッションがL2TPか同様のメカニズムを使用して、必要であるなら、そのようなサーバはさらにトンネルを堀るかもしれません。
Gleeson, et al. Informational [Page 49] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[49ページ]のRFC2764IP
6.4.3 Use of IPSec
6.4.3 IPSecの使用
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のどちらかがクライアントの機能性であると実装します)。
6.5 Recommendations
6.5 推薦
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.
明確にリモートホストのサポートに関連するいかなる他の問題と共にも。 現在、多くの異なった非共同利用できる独占溶液がこの領域にあるので。
7.0 VPN Types: Virtual Private LAN Segment
7.0 VPNはタイプします: 仮想の個人的なLANセグメント
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.
Virtual兵士のLAN Segment(VPLS)はインターネット施設を使用するLANセグメントのエミュレーションです。 また複数のスタッブCPEノードとインタコネクトするのに使用できるTransparent LAN Service(TLS)がブリッジするとき時々知られていることかプロトコルのルータに見え透いた方法を提供するのにVPLSを使用できます。 VPLSはIPの上でLANセグメントを見習います、レーンなどのプロトコルがATMの上でLANセグメントを見習うのと同様に。 VPLSの主要便益は完全なプロトコル透明です。(その透明は「マルチ-プロトコル」輸送と規定の理由で特定のサービスプロバイダー文脈で重要であるかもしれません)。
Gleeson, et al. Informational [Page 50] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[50ページ]のRFC2764IP
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
+---+
10.1.1.1 +--------+ +--------+ 10.1.1.2 +---+ | ISP| IPトンネル| ISP| +---+ |CPE|-------| 縁|-----------------------| 縁|-------|CPE| +---+ スタッブ| ノード| | ノード| スタッブ+---+ リンク+--------+ +--------+ リンク^| | ^ | | --------------- | | | | ( ) | | | +----(IPバックボーン)----+ | | ( ) | | --------------- | | | | |IPトンネル+--------+ IPトンネル| | | ISP| | +-----------| 縁|-----------+ | ノード| +--------+ サブネット=10.1.1.0/24| スタッブリンク| | +---+ |CPE| 10.1.1.3 +---+
Figure 7.1: VPLS Example
図7.1: VPLSの例
7.1 VPLS Requirements
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.
位相的に、そして操作上、本質的にはVPRNに同等であるとして最も容易にVPLSをモデル化できます、それぞれのVPLS縁のノードがネットワーク層推進よりむしろリンクレイヤのブリッジすることを実装するのを除いて。 また、そういうものとして、以前に議論したVPRNトンネリングと構成メカニズムの大部分はVPLSに適切な変化で使用されて、ネットワーク層、パケット、およびアドレス指定情報よりむしろリンクレイヤを収容できます。 以下のセクションはVPRN操作でVPLSsをサポートするのが必要であるプライマリ変化について論じます。
7.1.1 Tunneling Protocols
7.1.1 トンネリングプロトコル
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の中で使用して、これが以下で想定されるのと同じである場合があります。
Gleeson, et al. Informational [Page 51] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[51ページ]のRFC2764IP
7.1.2 Multicast and Broadcast Support
7.1.2 マルチキャストと放送サポート
A VPLS needs to have a broadcast capability. This is needed both for broadcast frames, and for link layer packet flooding, where a unicast frame is flooded because the path to the destination link layer address is unknown. The address resolution protocols that run over a bridged network typically use broadcast frames (e.g. ARP). The same set of possible multicast tunneling mechanisms discussed earlier for VPRNs apply also to a VPLS, though the generally more frequent use of broadcast in VPLSs may increase the pressure for native multicast support that reduces, for instance, the burden of replication on VPLS edge nodes.
VPLSは放送能力を必要とします。 これが放送フレーム、およびリンクレイヤパケット大量送信に必要です、送付先リンクレイヤアドレスへの経路が未知であるのでユニキャストフレームが水につかっているところで。 ブリッジしているネットワークをひくアドレス解決プロトコルは放送フレーム(例えば、ARP)を通常使用します。 また、VPRNsのために、より早く議論した同じセットの可能なマルチキャストトンネリングメカニズムはVPLSに適用されます、VPLSsにおける放送の一般により頻繁な使用が例えば減少するネイティブのマルチキャストサポートに対する圧力を増強するかもしれませんが、VPLS縁のノードにおける模写の負担。
7.1.3 VPLS Membership Configuration and Topology
7.1.3 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の課題もノード、およびアイデンティティを斜めに進ませる地方のVPNリンクに関する唯一の知識、またはルートがそうするのを一般に必要とするので、VPLS会員資格の構成はVPRNsのものに類似していて、他はVPLSのノードを斜めに進ませます。 そのような構成はそれぞれのVPN縁のノードで推進の本質から特に、独立しています。 また、そういうものとして、VPNメンバー構成とVPRN構成のために議論した普及のためのメカニズムのいずれもVPLS構成に適用できます。 また、VPRNsなら、VPLSのトポロジーはそれぞれのVPLS縁のノードで同輩ノードの構成を制御することによって、容易に操られるかもしれません、会員資格普及のメカニズムがこれを可能にするようにものであったと仮定して。 しかしながら、典型的なVPLSsは、2つのVPLSノードの間のトラフィックの必要性を別のVPLSノードを通したトランジットに排除するために完全に網の目にかけられそうでしょう。次に、ノードはSpanning Treeプロトコル[65]の輪の防止の使用を必要とするでしょう。
7.1.4 CPE Stub Node Types
7.1.4 CPEスタッブノード種別
A VPLS can support either bridges or routers as a CPE device.
VPLSはCPEデバイスとしてブリッジかルータのどちらかをサポートすることができます。
CPE routers would peer transparently across a VPLS with each other without requiring any router peering with any nodes within the VPLS. The same scalability issues that apply to a full mesh topology for VPRNs, apply also in this case, only that now the number of peering routers is potentially greater, since the ISP edge device is no longer acting as an aggregation point.
ルータを必要としないで、CPEルータは、互いと共にVPLSの中にどんなノードもある状態でじっと見ながら、VPLSの向こう側に透過的にじっと見るでしょう。 VPRNsのために完全なメッシュトポロジーに申し込んで、またこの場合申し込まれるのと同じスケーラビリティ問題、現在ISPエッジデバイス以来じっと見るルータの数が潜在的により大きいだけであるのはもう集合ポイントとして機能していません。
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
CPEブリッジデバイスで、放送ドメインはVPLS自身と同様にすべてのCPEサイトを包含します。 そしてこの場合、重要なスケーラビリティ規制がパケット大量送信の必要性のためにある。
Gleeson, et al. Informational [Page 52] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[52ページ]のRFC2764IP
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.
ブリッジしているドメインのどんなトポロジー変化もローカライズされませんが、ドメイン中で目に見えるという事実。 一般に、そういうものとして、このシナリオは非ルータブル・プロトコルのサポートに合っているだけです。
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の中でカプセル化、アドレシング、推進、および可到達性プロトコルの本質に影響を与えて、別々に以下で議論します。
7.1.5 Stub Link Packet Encapsulation
7.1.5 スタッブリンクパケットカプセル化
7.1.5.1 Bridge CPE
7.1.5.1 ブリッジCPE
In this case, packets sent to and from the VPLS across stub links are link layer frames, with a suitable access link encapsulation. The most common case is likely to be ethernet frames, using an encapsulation appropriate to the particular access technology, such as ATM, connecting the CPE bridges to the VPLS edge nodes. Such frames are then forwarded at layer 2 onto a tunnel used in the VPLS. As noted previously, this does mandate the use of an IP tunneling protocol which can transport such link layer frames. Note that this does not necessarily mandate, however, the use of a protocol identification field in each tunnel packet, since the nature of the encapsulated traffic (e.g. ethernet frames) could be indicated at tunnel setup.
この場合、VPLSとスタッブリンクの向こう側のVPLSから送られたパケットはリンクレイヤフレームです、適当なアクセスリンクカプセル化で。 最も一般的なケースはイーサネットフレームである傾向があります、特定のアクセス技術に適切なカプセル化を使用して、ATMなどのように、VPLS縁のノードにCPEブリッジを接続して。 そして、層2でVPLSで使用されるトンネルにそのようなフレームを送ります。 以前に注意されるように、これはそのようなリンクレイヤフレームを輸送できるIPトンネリングプロトコルの使用を強制します。 しかしながら、これが必ずそれぞれのトンネルパケットにおけるプロトコル識別分野の使用を強制するというわけではないことに注意してください、トンネルセットアップでカプセル化されたトラフィック(例えば、イーサネットフレーム)の本質を示すことができたので。
7.1.5.2 Router CPE
7.1.5.2 ルータCPE
In this case, typically, CPE routers send link layer packets to and from the VPLS across stub links, destined to the link layer addresses of their peer CPE routers. Other types of encapsulations may also prove feasible in such a case, however, since the relatively constrained addressing space needed for a VPLS to which only router CPE are connected, could allow for alternative encapsulations, as discussed further below.
この場合、通常、CPEルータはそれらの同輩CPEルータのリンクレイヤアドレスに運命づけられたスタッブリンクの向こう側にVPLSとVPLSからリンクレイヤパケットを送ります。 しかしながら、ルータだけCPEが接続されているVPLSに必要である比較的強制的なアドレシングスペース以来、他のタイプのカプセル化は、また、可能であるとこのような場合には判明して、代替のカプセル化を考慮するかもしれません、以下でさらに議論するように。
7.1.6 CPE Addressing and Address Resolution
7.1.6 CPEアドレシングとアドレス解決
7.1.6.1 Bridge CPE
7.1.6.1 ブリッジCPE
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
VPLSがリンクレイヤで作動するので、ブリッジCPEの場合には、同じネットワーク層サブネットにすべてのスタッブサイトの中のすべてのホストが通常いるでしょう。 (マルチネッティング(複数のサブネットが同じLANセグメントの上で作動する)は、可能ですが、あまりそれほど一般的ではありません。) VPLSの向こう側に個々のホストに関連しているリンクレイヤアドレス(例えば、IEEE MACアドレス)に基づくVPLSの中でフレームを進めます。 VPLSは、使用されるアドレス解決メカニズムに通常使用されるそれなどの放送トラフィックをサポートする必要があります。
Gleeson, et al. Informational [Page 53] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[53ページ]のRFC2764IP
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推進と可到達性アルゴリズムは、水につかっているトラフィックを収容できる必要があります。
7.1.6.2 Router CPE
7.1.6.2 ルータCPE
A single network layer subnet is generally used to interconnect router CPE devices, across a VPLS. Behind each CPE router are hosts in different network layer subnets. CPE routers transfer packets across the VPLS by mapping next hop network layer addresses to the link layer addresses of a router peer. A link layer encapsulation is used, most commonly ethernet, as for the bridge case.
一般に、ただ一つのネットワーク層サブネットは、VPLSの向こう側にルータCPEデバイスとインタコネクトするのに使用されます。 それぞれのCPEルータの後ろに、異なったネットワーク層サブネットにおけるホストはいます。 CPEルータは、VPLSの向こう側に次のホップネットワーク層アドレスをルータ同輩のリンクレイヤアドレスに写像することによって、パケットを移します。 使用されるリンクレイヤカプセル化、最も一般的にブリッジケースのようなイーサネット。
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の強制的なアドレシングスペースのために、上で述べたように、その時、VPLSに接続されたCPEノードのすべてがルータである場合では、しかしながら、それは、異なったアドレス空間を使用するカプセル化を使用するために正常なMACアドレシングより可能であるかもしれません。 例えば、[11] CPE LSRルータを特定するために体系を扱うリンクレイヤがVPLSに接続したときMPLSネットワークの上のVPLSsのための提案されたメカニズムのためにVPRNサポートに対するトンネリングメカニズムとしてMPLSを提案するMPLS[38]と局所的に割り当てられたMPLSの上の以前の仕事にラベルを利用して、見てください。
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms
7.1.7 VPLS縁のノード推進と可到達性メカニズム
7.1.7.1 Bridge CPE
7.1.7.1 ブリッジCPE
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縁のノード推進メカニズムが標準のリンクレイヤパケット大量送信とMACアドレス学習である傾向があります、[65]に従って。 そういうものとして、どんな明白なイントラ-VPLS可到達性プロトコルも必要でないでしょう、放送メカニズムがトラフィックをあふれさせる必要があるでしょうが、上で議論するように。 一般に、また、VPLS縁のノードの間のSpanning Treeプロトコルを実装するのが必要であると判明しないかもしれません、VPLSトポロジーがVPLS縁のノードが全くいかなる他のVPLS縁のノードの間のトランジットトラフィックに使用されないようにものであるなら--言い換えれば、完全なメッシュの接続性とトランジットの両方がどこにあるかは明らかに排除されます。 他方では、CPEブリッジは、VPLSを通して'裏口'の経路に対してその迂回の接続性を保護するためにたぶんスパニングツリープロトコルを実装するでしょう。
7.1.7.2 Router CPE
7.1.7.2 ルータCPE
Standard bridging techniques can also be used in this case. In addition, the smaller link layer address space of such a VPLS may also permit other techniques, with explicit link layer routes between CPE routers. [11], for instance, proposes that MPLS LSPs be set up, at the insertion of any new CPE router into the VPLS, between all CPE
また、この場合標準のブリッジすることのテクニックを使用できます。 また、さらに、そのようなVPLSの、より小さいリンクレイヤアドレス空間は他のテクニックを可能にするかもしれません、CPEルータの間には、明白なリンクレイヤルートがある状態で。 例えば、[11]は、MPLS LSPsがセットアップされるよう提案します、VPLSへのどんな新しいCPEルータの挿入のときにも、すべてのCPEの間で
Gleeson, et al. Informational [Page 54] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[54ページ]のRFC2764IP
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.
LSRs。 そして、これはパケット大量送信の必要性を排除します。 より一般的な場合では、CPEルータのリンクレイヤアドレスがあるVPLS縁のノードがそれらに接続して、次に、この情報を互いに伝播するのにVPRNsのために議論したイントラ-VPN可到達性メカニズムのどれかの変更は使用できたのを構成するのにおいてスタッブリンク可到達性メカニズムが使用されていたなら、VPLSがノードを斜めに進ませます。 そして、これはVPLSの向こう側に氾濫なしでパケット推進を考慮するでしょう。
Mechanisms could also be developed to further propagate the link layer addresses of peer CPE routers and their corresponding network layer addresses across the stub links to the CPE routers, where such information could be inserted into the CPE router's address resolution tables. This would then also preclude the need for broadcast address resolution protocols across the VPLS.
また、さらに、同輩CPEルータのリンクレイヤアドレスとCPEルータへのスタッブリンクの向こう側のそれらの対応するネットワーク層アドレスを伝播するためにメカニズムを開発できました。(そこでは、CPEルータのアドレス解決テーブルにそのような情報を挿入できました)。 そして、また、これはVPLSの向こう側に放送演説解決プロトコルの必要性を排除するでしょう。
Clearly there would be no need for the support of spanning tree protocols if explicit link layer routes were determined across the VPLS. If normal flooding mechanisms were used then spanning tree would only be required if full mesh connectivity was not available and hence VPLS nodes had to carry transit traffic.
明確に、明白なリンクレイヤルートがVPLSの向こう側に決定するなら、スパニングツリープロトコルのサポートの必要は全くないでしょうに。 正常な氾濫メカニズムが使用されるなら、完全なメッシュの接続性が利用可能でなく、したがって、VPLSノードがトランジットトラフィックを載せなければならない場合にだけ、スパニングツリーが必要でしょうに。
7.2 Recommendations
7.2 推薦
There is significant commonality between VPRNs and VPLSs, and, where possible, this similarity should be exploited in order to reduce development and configuration complexity. In particular, VPLSs should utilize the same tunneling and membership configuration mechanisms, with changes only to reflect the specific characteristics of VPLSs.
VPRNsとVPLSsの間には、重要な共通点があります、そして、可能であるところでは、この類似性が、開発と構成の複雑さを抑えるのに利用されるべきです。 特に、VPLSsは変化に伴う同じトンネリングと会員資格構成メカニズムを利用するはずですが、VPLSsの特定の特性を反映します。
8.0 Summary of Recommendations
8.0 推薦の概要
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.
多くの一般的な要件とVPNsのすべてのタイプに適用されるメカニズムがあります、そして、個別にVPNsの本書では異なったタイプについて議論しましたが、多くのネットワークがVPNsの異なったタイプのミックスを含むでしょう。 同じくらい多くの共通点をこれらの異なったVPNタイプの向こう側に可能にするのは役に立ちます。 比較的少ない数のメカニズムを標準化することによって、さまざまなVPNsが実装されるのを許容するのは特に、可能です。
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)
Gleeson, et al. Informational [Page 55] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[55ページ]のRFC2764IP
- 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をサポートするのに使用されると、IPSecの運転モードを定義します。(3.2)
For VPNs generally:
VPNs、一般に:
- defining a VPN membership information configuration and
dissemination mechanism, that uses some form of directory or MIB
(5.3.2)
- VPN会員資格情報構成と普及のメカニズムを定義して、それはディレクトリかMIBの何らかのフォームを使用します。(5.3.2)
- 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.
- できるだけ見いだされた解決策が確実にむしろVPNsのVPNの単独のタイプに特定であるのと異なったタイプに適切になるようにしてください。
9.0 Security Considerations
9.0 セキュリティ問題
Security considerations are an integral part of any VPN mechanisms, and these are discussed in the sections describing those mechanisms.
セキュリティ問題はどんなVPNメカニズムの不可欠の部分です、そして、それらのメカニズムについて説明するセクションでこれらについて議論します。
10.0 Acknowledgements
10.0 承認
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.
彼の非常に貴重な支援をこのドキュメントの世代でノーテルNetworksのアンソニーAllesをありがとうございます、だれがこのドキュメントのどの早めのバージョンで材料の多くを発生したかは基づきました。 また、彼の役立っているレビューコメントをジョエル・アルペルンをありがとうございます。
11.0 References
11.0の参照箇所
[1] ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000,
January 1995.
[1] 気圧フォーラム。 「ATMの上のLAN Emulation、1インチ、af車線0021.000、1995インチ年1月。
[2] ATM Forum. "Multi-Protocol Over ATM Specification v1.0", af-
mpoa-0087.000, June 1997.
[2] 気圧フォーラム。 「マルチプロトコルOver ATM Specification 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は何ですか?」、Revision1、1998年4月1日。 http://www.employees.org/~ferguson/vpn.pdf 。
Gleeson, et al. Informational [Page 56] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[56ページ]のRFC2764IP
[4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[4] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[5] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[6] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[7] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
[7]一かせとS.と李とT.とファリナッチとD.とP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC1701 1994年10月。
[8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[8] Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらわれます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[9] Rosen, E., et al., "Multiprotocol Label Switching Architecture",
Work in Progress.
[9] ローゼン、E.、他、「Multiprotocolラベル切り換えアーキテクチャ」、ProgressのWork。
[10] Heinanen, J., et al., "MPLS Mappings of Generic VPN Mechanisms",
Work in Progress.
[10]Heinanen、J.、他、「ジェネリックVPNメカニズムに関するMPLSマッピング」、ProgressのWork。
[11] Jamieson, D., et al., "MPLS VPN Architecture", Work in Progress.
[11] ジェーミソン、D.、他、「MPLS VPNアーキテクチャ」、ProgressのWork。
[12] Casey, L., et al., "IP VPN Realization using MPLS Tunnels", Work
in Progress.
[12] ケーシー、L.、他、「MPLS Tunnelsを使用するIP VPN実現」、ProgressのWork。
[13] Li, T. "CPE based VPNs using MPLS", Work in Progress.
[13] T. 李、「CPEはMPLSを使用することでVPNsを基礎づけた」ProgressのWork。
[14] Muthukrishnan, K. and A. Malis, "Core MPLS IP VPN Architecture",
Work in Progress.
[14] 「コアMPLS IP VPNアーキテクチャ」というMuthukrishnan、K.、およびA.Malisは進行中で働いています。
[15] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[15] ローゼンとE.と1999年のY.Rekhter、「BGP/MPLS VPNs」、RFC2547行進。
[16] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[16]フォックスとB.とB.グリーソン、「仮想私設網識別子」、RFC2685、1999年9月。
[17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM
Forum, af-mpoa-0129.000.
[17] ペトリ、B.(エディタ)「VPNサポートでのMPOA v1.1 Addendum」、ATM Forum、af-mpoa-0129.000。
[18] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[18] ハーキンとD.とC.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[19] Calhoun, P., et al., "Tunnel Establishment Protocol", Work in
Progress.
[19] カルフーン、P.、他、「トンネル設立プロトコル」、ProgressのWork。
Gleeson, et al. Informational [Page 57] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[57ページ]のRFC2764IP
[20] Andersson, L., et al., "LDP Specification", Work in Progress.
[20] アンデション、L.、他、「自由民主党仕様」、ProgressのWork。
[21] Jamoussi, B., et al., "Constraint-Based LSP Setup using LDP"
Work in Progress.
[21]Jamoussi、B.、他、Progressの「自由民主党を使用する規制ベースのLSPセットアップ」Work。
[22] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", Work
in Progress.
[22]Awduche、D.、他、「LSP TunnelsのためのRSVPへの拡大」、ProgressのWork。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol
(ESP)", RFC 2406, November 1998.
[23] ケントとS.とR.アトキンソン、「セキュリティがプロトコル(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[24] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[24] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
[25] ペレスとM.とLiawとF.とマンキンとA.とホフマンとE.とグロースマン、D.とA.Malis、「気圧でのIPの気圧合図サポート」RFC1755(1995年2月)。
[26] Malkin, G. "RIP Version 2 Carrying Additional Information",
RFC 1723, November 1994.
[26] マルキン、G.「裂け目のバージョン2携帯追加情報」、RFC1723、1994年11月。
[27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[27]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[28] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, December 1998.
[28]ShachamとA.とMonsourとR.とペレイラとR.とM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC2393 1998年12月。
[29] Duffield N., et al., "A Performance Oriented Service Interface
for Virtual Private Networks", Work in Progress.
[29] ダッフィールドN.、他、「仮想私設網のためのパフォーマンスの指向のサービスインタフェース」、ProgressのWork。
[30] Jacobson, V., Nichols, K. and B. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[30] ジェーコブソンとV.とニコルズとK.とB.Poduri、「完全優先転送PHB」、RFC2598 1999年6月。
[31] Casey, L., "An extended IP VPN Architecture", Work in Progress.
[31] ケーシー、L.、「拡張IP VPN Architecture」、ProgressのWork。
[32] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4),"
RFC 1771, March 1995.
[32]Rekhter、Y.、および1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[33] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over
ATM Adaptation Layer 5", RFC 2684, September 1999.
[33] グロースマン、D.、およびJ.Heinanen、「気圧適合の上のMultiprotocolカプセル化は1999年9月に5インチ、RFC2684を層にします」。
[34] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[34] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[35] Boyle, J., et al., "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[35] ボイル、J.、他、「巡査(一般的なオープンポリシーサービス)は議定書を作る」RFC2748、2000年1月。
[36] MacRae, M. and S. Ayandeh, "Using COPS for VPN Connectivity"
Work in Progress.
[36] 「VPNの接続性に巡査を使用する」マックレイ、M.、およびS.Ayandehが進行中で働いています。
Gleeson, et al. Informational [Page 58] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[58ページ]のRFC2764IP
[37] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[37]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[38] Heinanen, J. and E. Rosen, "VPN Support with MPLS", Work in
Progress.
[38] 「MPLSとのVPNサポート」というHeinanen、J.、およびE.ローゼンは進行中で働いています。
[39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[39] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[40] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[40]WaitzmanとD.とヤマウズラ、C.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、1988年11月。
[41] Fenner, W., "IGMP-based Multicast Forwarding (IGMP Proxying)",
Work in Progress.
[41] フェナー、W.、「IGMPベースのマルチキャスト推進(IGMP Proxying)」が進行中で働いています。
[42] Wallner, D., Harder, E. and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999.
[42] ウォルナー、D.、ハーダー、E.、およびR.エージー、「マルチキャストのための管理を合わせてください」 「問題とアーキテクチャ」、RFC2627、6月1999日
[43] Hardjono, T., et al., "Secure IP Multicast: Problem areas,
Framework, and Building Blocks", Work in Progress.
[43]Hardjono、T.、他、「IPマルチキャストを保証してください」 「問題領域、Framework、およびビルBlocks」、ProgressのWork。
[44] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[44]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[45] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[45] バレンシア、A.、リトルウッド、M.、およびT.コラール(「コクチマス層Twoの推進(プロトコル)"L2F"」、RFC2341)は1998がそうするかもしれません。
[46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
July 1999.
[46]HamzehとK.と祭服とG.とVertheinとW.とTaarudとJ.と少しとw.とG.ゾルン、「二地点間トンネリングプロトコル(PPTP)」、RFC2637、1999年7月。
[47] Patel, B., et al., "Securing L2TP using IPSEC", Work in
Progress.
[47] パテル、B.、他、「IPSECを使用することでL2TPを固定します」、ProgressのWork。
[48] Srisuresh, P., "Secure Remote Access with L2TP", Work in
Progress.
[48] P.、「L2TPがある安全な遠隔アクセス」というSrisureshは進行中で働いています。
[49] Calhoun, P., et al., "Layer Two Tunneling Protocol "L2TP"
Security Extensions for Non-IP networks", Work in Progress.
[49] カルフーン、P.、他、「Non-IPネットワークのためにプロトコル"L2TP"Security Extensionsにトンネルを堀る層Two」、ProgressのWork。
[50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory
Tunneling via RADIUS", Work in progress.
G. [50]AbobaとB.とゾルン、「RADIUSを通したPPTP/L2TPコンパルソリーTunnelingの実装」、進行中のWork。
[51] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[51]AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、1999年1月。
Gleeson, et al. Informational [Page 59] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[59ページ]のRFC2764IP
[52] Shea, R., "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in
Progress.
[52] シーア、R.、「L2TP過剰IP経路MTU発見(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.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。
[54] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
(BACP)", RFC 2125, March 1997.
[54] リチャーズ、C.、およびK.スミス、「ppp帯域幅配分は(BAP)ppp帯域幅調節プロトコル(BACP)について議定書の中で述べます」、RFC2125、1997年3月。
[55] Calhoun, P. and K. Peirce, "Layer Two Tunneling Protocol "L2TP"
IP Differential Services Extension", Work in Progress.
[55] 「層Twoのトンネリングプロトコル"L2TP"IPの特異なサービス拡大」というカルフーン、P.、およびK.ピアスは進行中で働いています。
[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] グプタ、「安全で、IPSecを使用するインターネットの上で遠隔アクセスである」V.は進行中で働いています。
[59] Pereira, R., et al., "The ISAKMP Configuration Method", Work in
Progress.
[59] ペレイラ、R.、他、「ISAKMP構成メソッド」、ProgressのWork。
[60] Pereira, R. and S. Beaulieu, "Extended Authentication Within
ISAKMP/Oakley", Work in Progress.
[60] 「ISAKMP/オークリーの中の拡張認証」というペレイラ、R.、およびS.ボーリューは進行中で働いています。
[61] Litvin, M., et al., "A Hybrid Authentication Mode for IKE", Work
in Progress.
[61] リトビン、M.、他、「IKEのためのハイブリッド認証モード」、ProgressのWork。
[62] Kelly, S., et al., "User-level Authentication Mechanisms for
IPsec", Work in Progress.
[62] ケリー、S.、他、「IPsecのためのユーザレベル認証機構」、ProgressのWork。
[63] Patel, B., et al., "DHCP Configuration of IPSEC Tunnel Mode",
Work in Progress.
[63] パテル、B.、他、「IPSECトンネル・モードのDHCP構成」、ProgressのWork。
[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.とエバーツとJ.と個人閲覧室とD.とシモンとD.とR.ウィーラー、「イーサネット(PPPoE)の上にpppを伝えるためのメソッド」、RFC2516、1999年2月。
[65] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology -
Telecommunications and information exchange between systems -
Local area networks - Media access control (MAC) bridges,
ANSI/IEEE Std 802.1D, 1993 Edition.
[65] ANSI/IEEE--10038、: 1993(ISO/IEC)情報技術--システムの間のテレコミュニケーションと情報交換--ローカル・エリア・ネットワーク--メディアアクセスは(MAC)ブリッジを制御します、ANSI/IEEE Std 802.1D、1993Edition。
Gleeson, et al. Informational [Page 60] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[60ページ]のRFC2764IP
12.0 Author Information
12.0 作者情報
Bryan Gleeson Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
ブライアングリーソンノーテルネットワーク4500グレート・アメリカ公園道路サンタクララカリフォルニア95054米国
Phone: +1 (408) 548 3711 EMail: bgleeson@shastanets.com
以下に電話をしてください。 +1(408) 548 3711はメールされます: bgleeson@shastanets.com
Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland
ユハHeinanen冬胞子堆フィンランドInc.Myyrmaentie2 01600バンターフィンランド
Phone: +358 303 944 808 EMail: jh@telia.fi
以下に電話をしてください。 +358 303 944 808はメールされます: jh@telia.fi
Arthur Lin Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
アーサーリンノーテルネットワーク4500グレート・アメリカ公園道路サンタクララカリフォルニア95054米国
Phone: +1 (408) 548 3788 EMail: alin@shastanets.com
以下に電話をしてください。 +1(408) 548 3788はメールされます: alin@shastanets.com
Grenville Armitage Bell Labs Research Silicon Valley Lucent Technologies 3180 Porter Drive, Palo Alto, CA 94304 USA
3180年のグレンビルのアーミテージベル研究所の研究シリコンバレールーセントテクノロジーズのポータードライブ、パロアルト、カリフォルニア94304米国
EMail: gja@lucent.com
メール: gja@lucent.com
Andrew G. Malis Lucent Technologies 1 Robbins Road Westford, MA 01886 USA
アンドリューG.Malisルーセントテクノロジーズ1ロビンス・Road MA01886ウェストフォード(米国)
Phone: +1 978 952 7414 EMail: amalis@lucent.com
以下に電話をしてください。 +1 7414年の978 952メール: amalis@lucent.com
Gleeson, et al. Informational [Page 61] RFC 2764 IP Based Virtual Private Networks February 2000
グリーソン、他 仮想私設網2000年2月に基づいた情報[61ページ]のRFC2764IP
13.0 Full Copyright Statement
13.0 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gleeson, et al. Informational [Page 62]
グリーソン、他 情報[62ページ]
一覧
スポンサーリンク
