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
Network Working Group B. Gleeson
Request for Comments: 2764 A. Lin
Category: Informational Nortel Networks
J. Heinanen
Telia Finland
G. Armitage
A. Malis
Lucent Technologies
February 2000
A Framework for IP Based Virtual Private Networks
一种基于IP的虚拟专用网框架
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
IESG Note
IESG注释
This document is not the product of an IETF Working Group. The IETF currently has no effort underway to standardize a specific VPN framework.
本文件不是IETF工作组的产品。IETF目前没有对特定VPN框架进行标准化的工作。
Abstract
摘要
This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.
本文档描述了跨IP主干运行的虚拟专用网络（VPN）的框架。它讨论了各种不同类型的VPN及其各自的需求，并提出了可用于使用现有或拟议规范实现每种类型VPN的具体机制。本文档的目的是作为相关协议开发的框架，以开发广泛部署可互操作VPN解决方案所需的全套规范。
Table of Contents
目录
1.0 Introduction ................................................ 4
2.0 VPN Application and Implementation Requirements ............. 5
2.1 General VPN Requirements .................................... 5
2.1.1 Opaque Packet Transport: ................................. 6
2.1.2 Data Security ............................................. 7
2.1.3 Quality of Service Guarantees ............................. 7
2.1.4 Tunneling Mechanism ....................................... 8
2.2 CPE and Network Based VPNs .................................. 8
2.3 VPNs and Extranets .......................................... 9
3.0 VPN Tunneling ............................................... 10
3.1 Tunneling Protocol Requirements for VPNs .................... 11
3.1.1 Multiplexing .............................................. 11
3.1.2 Signalling Protocol ....................................... 12
3.1.3 Data Security ............................................. 13
3.1.4 Multiprotocol Transport ................................... 14
3.1.5 Frame Sequencing .......................................... 14
3.1.6 Tunnel Maintenance ........................................ 15
3.1.7 Large MTUs ................................................ 16
3.1.8 Minimization of Tunnel Overhead ........................... 16
3.1.9 Flow and congestion control ............................... 17
3.1.10 QoS / Traffic Management ................................. 17
3.2 Recommendations ............................................. 18
4.0 VPN Types: Virtual Leased Lines ............................ 18
5.0 VPN Types: Virtual Private Routed Networks ................. 20
5.1 VPRN Characteristics ........................................ 20
5.1.1 Topology .................................................. 23
5.1.2 Addressing ................................................ 24
5.1.3 Forwarding ................................................ 24
5.1.4 Multiple concurrent VPRN connectivity ..................... 24
5.2 VPRN Related Work ........................................... 24
5.3 VPRN Generic Requirements ................................... 25
5.3.1 VPN Identifier ............................................ 26
5.3.2 VPN Membership Information Configuration .................. 27
5.3.2.1 Directory Lookup ........................................ 27
5.3.2.2 Explicit Management Configuration ....................... 28
5.3.2.3 Piggybacking in Routing Protocols ....................... 28
5.3.3 Stub Link Reachability Information ........................ 30
5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30
5.3.3.1.2 VPRN Connectivity Only ................................ 30
5.3.3.1.3 Multihomed Connectivity ............................... 31
5.3.3.1.4 Backdoor Links ........................................ 31
5.3.3.1 Routing Protocol Instance ............................... 31
5.3.3.2 Configuration ........................................... 33
5.3.3.3 ISP Administered Addresses .............................. 33
5.3.3.4 MPLS Label Distribution Protocol ........................ 33
1.0 Introduction ................................................ 4
2.0 VPN Application and Implementation Requirements ............. 5
2.1 General VPN Requirements .................................... 5
2.1.1 Opaque Packet Transport: ................................. 6
2.1.2 Data Security ............................................. 7
2.1.3 Quality of Service Guarantees ............................. 7
2.1.4 Tunneling Mechanism ....................................... 8
2.2 CPE and Network Based VPNs .................................. 8
2.3 VPNs and Extranets .......................................... 9
3.0 VPN Tunneling ............................................... 10
3.1 Tunneling Protocol Requirements for VPNs .................... 11
3.1.1 Multiplexing .............................................. 11
3.1.2 Signalling Protocol ....................................... 12
3.1.3 Data Security ............................................. 13
3.1.4 Multiprotocol Transport ................................... 14
3.1.5 Frame Sequencing .......................................... 14
3.1.6 Tunnel Maintenance ........................................ 15
3.1.7 Large MTUs ................................................ 16
3.1.8 Minimization of Tunnel Overhead ........................... 16
3.1.9 Flow and congestion control ............................... 17
3.1.10 QoS / Traffic Management ................................. 17
3.2 Recommendations ............................................. 18
4.0 VPN Types: Virtual Leased Lines ............................ 18
5.0 VPN Types: Virtual Private Routed Networks ................. 20
5.1 VPRN Characteristics ........................................ 20
5.1.1 Topology .................................................. 23
5.1.2 Addressing ................................................ 24
5.1.3 Forwarding ................................................ 24
5.1.4 Multiple concurrent VPRN connectivity ..................... 24
5.2 VPRN Related Work ........................................... 24
5.3 VPRN Generic Requirements ................................... 25
5.3.1 VPN Identifier ............................................ 26
5.3.2 VPN Membership Information Configuration .................. 27
5.3.2.1 Directory Lookup ........................................ 27
5.3.2.2 Explicit Management Configuration ....................... 28
5.3.2.3 Piggybacking in Routing Protocols ....................... 28
5.3.3 Stub Link Reachability Information ........................ 30
5.3.3.1 Stub Link Connectivity Scenarios ........................ 30
5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30
5.3.3.1.2 VPRN Connectivity Only ................................ 30
5.3.3.1.3 Multihomed Connectivity ............................... 31
5.3.3.1.4 Backdoor Links ........................................ 31
5.3.3.1 Routing Protocol Instance ............................... 31
5.3.3.2 Configuration ........................................... 33
5.3.3.3 ISP Administered Addresses .............................. 33
5.3.3.4 MPLS Label Distribution Protocol ........................ 33
5.3.4 Intra-VPN Reachability Information ........................ 34
5.3.4.1 Directory Lookup ........................................ 34
5.3.4.2 Explicit Configuration .................................. 34
5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34
5.3.4.4 Link Reachability Protocol .............................. 35
5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36
5.3.5 Tunneling Mechanisms ...................................... 36
5.4 Multihomed Stub Routers ..................................... 37
5.5 Multicast Support ........................................... 38
5.5.1 Edge Replication .......................................... 38
5.5.2 Native Multicast Support .................................. 39
5.6 Recommendations ............................................. 40
6.0 VPN Types: Virtual Private Dial Networks ................... 41
6.1 L2TP protocol characteristics ............................... 41
6.1.1 Multiplexing .............................................. 41
6.1.2 Signalling ................................................ 42
6.1.3 Data Security ............................................. 42
6.1.4 Multiprotocol Transport ................................... 42
6.1.5 Sequencing ................................................ 42
6.1.6 Tunnel Maintenance ........................................ 43
6.1.7 Large MTUs ................................................ 43
6.1.8 Tunnel Overhead ........................................... 43
6.1.9 Flow and Congestion Control ............................... 43
6.1.10 QoS / Traffic Management ................................. 43
6.1.11 Miscellaneous ............................................ 44
6.2 Compulsory Tunneling ........................................ 44
6.3 Voluntary Tunnels ........................................... 46
6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 46
6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 48
6.4 Networked Host Support ...................................... 49
6.4.1 Extension of PPP to Hosts Through L2TP .................... 49
6.4.2 Extension of PPP Directly to Hosts: ...................... 49
6.4.3 Use of IPSec .............................................. 50
6.5 Recommendations ............................................. 50
7.0 VPN Types: Virtual Private LAN Segment ..................... 50
7.1 VPLS Requirements ........................................... 51
7.1.1 Tunneling Protocols ....................................... 51
7.1.2 Multicast and Broadcast Support ........................... 52
7.1.3 VPLS Membership Configuration and Topology ................ 52
7.1.4 CPE Stub Node Types ....................................... 52
7.1.5 Stub Link Packet Encapsulation ............................ 53
7.1.5.1 Bridge CPE .............................................. 53
7.1.5.2 Router CPE .............................................. 53
7.1.6 CPE Addressing and Address Resolution ..................... 53
7.1.6.1 Bridge CPE .............................................. 53
7.1.6.2 Router CPE .............................................. 54
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 54
7.1.7.1 Bridge CPE .............................................. 54
5.3.4 Intra-VPN Reachability Information ........................ 34
5.3.4.1 Directory Lookup ........................................ 34
5.3.4.2 Explicit Configuration .................................. 34
5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34
5.3.4.4 Link Reachability Protocol .............................. 35
5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36
5.3.5 Tunneling Mechanisms ...................................... 36
5.4 Multihomed Stub Routers ..................................... 37
5.5 Multicast Support ........................................... 38
5.5.1 Edge Replication .......................................... 38
5.5.2 Native Multicast Support .................................. 39
5.6 Recommendations ............................................. 40
6.0 VPN Types: Virtual Private Dial Networks ................... 41
6.1 L2TP protocol characteristics ............................... 41
6.1.1 Multiplexing .............................................. 41
6.1.2 Signalling ................................................ 42
6.1.3 Data Security ............................................. 42
6.1.4 Multiprotocol Transport ................................... 42
6.1.5 Sequencing ................................................ 42
6.1.6 Tunnel Maintenance ........................................ 43
6.1.7 Large MTUs ................................................ 43
6.1.8 Tunnel Overhead ........................................... 43
6.1.9 Flow and Congestion Control ............................... 43
6.1.10 QoS / Traffic Management ................................. 43
6.1.11 Miscellaneous ............................................ 44
6.2 Compulsory Tunneling ........................................ 44
6.3 Voluntary Tunnels ........................................... 46
6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 46
6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 48
6.4 Networked Host Support ...................................... 49
6.4.1 Extension of PPP to Hosts Through L2TP .................... 49
6.4.2 Extension of PPP Directly to Hosts: ...................... 49
6.4.3 Use of IPSec .............................................. 50
6.5 Recommendations ............................................. 50
7.0 VPN Types: Virtual Private LAN Segment ..................... 50
7.1 VPLS Requirements ........................................... 51
7.1.1 Tunneling Protocols ....................................... 51
7.1.2 Multicast and Broadcast Support ........................... 52
7.1.3 VPLS Membership Configuration and Topology ................ 52
7.1.4 CPE Stub Node Types ....................................... 52
7.1.5 Stub Link Packet Encapsulation ............................ 53
7.1.5.1 Bridge CPE .............................................. 53
7.1.5.2 Router CPE .............................................. 53
7.1.6 CPE Addressing and Address Resolution ..................... 53
7.1.6.1 Bridge CPE .............................................. 53
7.1.6.2 Router CPE .............................................. 54
7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 54
7.1.7.1 Bridge CPE .............................................. 54
7.1.7.2 Router CPE .............................................. 54
7.2 Recommendations ............................................. 55
8.0 Summary of Recommendations .................................. 55
9.0 Security Considerations ..................................... 56
10.0 Acknowledgements ........................................... 56
11.0 References ................................................. 56
12.0 Author Information ......................................... 61
13.0 Full Copyright Statement ................................... 62
7.1.7.2 Router CPE .............................................. 54
7.2 Recommendations ............................................. 55
8.0 Summary of Recommendations .................................. 55
9.0 Security Considerations ..................................... 56
10.0 Acknowledgements ........................................... 56
11.0 References ................................................. 56
12.0 Author Information ......................................... 61
13.0 Full Copyright Statement ................................... 62
This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.
本文档描述了跨IP主干运行的虚拟专用网络（VPN）的框架。它讨论了各种不同类型的VPN及其各自的需求，并提出了可用于使用现有或拟议规范实现每种类型VPN的具体机制。本文档的目的是作为相关协议开发的框架，以开发广泛部署可互操作VPN解决方案所需的全套规范。
There is currently significant interest in the deployment of virtual private networks across IP backbone facilities. The widespread deployment of VPNs has been hampered, however, by the lack of interoperable implementations, which, in turn, derives from the lack of general agreement on the definition and scope of VPNs and confusion over the wide variety of solutions that are all described by the term VPN. In the context of this document, a VPN is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN.
目前，人们对跨IP主干设施部署虚拟专用网络非常感兴趣。然而，由于缺乏可互操作的实现，VPN的广泛部署受到了阻碍，这反过来又源于对VPN的定义和范围缺乏普遍共识，以及对VPN一词所描述的各种解决方案的混淆。在本文档的上下文中，VPN仅定义为“使用IP设施（包括公共互联网或专用IP主干网）模拟专用广域网（WAN）设施”。因此，虚拟专用网络的类型与广域网的类型一样多，因此，人们对虚拟专用网络究竟是什么构成的感到困惑。
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，VPN可以互连在一起，其方式与今天的主机连接到物理网络的方式相同，并且物理网络互连在一起（例如，通过网桥或路由器）。网络的许多方面，如寻址、转发机制、学习和广告可达性、服务质量（QoS）、安全性和防火墙，在物理和虚拟网络中都有通用的解决方案，在讨论VPN时出现的许多问题与在物理网络中实现的这些问题有直接的相似之处。VPN的引入并不需要重新设计网络，也不需要引入与现有物理网络没有直接相似性的全新模式。相反，首先检查在物理网络环境中如何处理特定问题，然后将相同的原则应用于包含
virtual as well as physical networks, and to develop appropriate extensions and enhancements when necessary. Clearly having mechanisms that are common across both physical and virtual networks facilitates the introduction of VPNs into existing networks, and also reduces the effort needed for both standards and product development, since existing solutions can be leveraged.
虚拟网络和物理网络，并在必要时开发适当的扩展和增强功能。显然，在物理网络和虚拟网络中使用通用的机制有助于将VPN引入现有网络，同时也减少了标准和产品开发所需的工作量，因为可以利用现有的解决方案。
This framework document proposes a taxonomy of a specific set of VPN types, showing the specific applications of each, their specific requirements, and the specific types of mechanisms that may be most appropriate for their implementation. The intent of this document is to serve as a framework to guide a coherent discussion of the specific modifications that may be needed to existing IP mechanisms in order to develop a full range of interoperable VPN solutions.
本框架文档提出了一组特定VPN类型的分类，显示了每种类型的特定应用程序、它们的特定要求以及最适合它们实现的特定类型的机制。本文档的目的是作为一个框架，指导对现有IP机制可能需要的具体修改进行一致的讨论，以开发全套可互操作的VPN解决方案。
The document first discusses the likely expectations customers have of any type of VPN, and the implications of these for the ways in which VPNs can be implemented. It also discusses the distinctions between Customer Premises Equipment (CPE) based solutions, and network based solutions. Thereafter it presents a taxonomy of the various VPN types and their respective requirements. It also outlines suggested approaches to their implementation, hence also pointing to areas for future standardization.
本文档首先讨论了客户对任何类型VPN的可能期望，以及这些期望对VPN实现方式的影响。它还讨论了基于客户场所设备（CPE）的解决方案与基于网络的解决方案之间的区别。此后，它给出了各种VPN类型及其各自需求的分类。它还概述了建议的实施方法，因此也指出了未来标准化的领域。
Note also that this document only discusses implementations of VPNs across IP backbones, be they private IP networks, or the public Internet. The models and mechanisms described here are intended to apply to both IPV4 and IPV6 backbones. This document specifically does not discuss means of constructing VPNs using native mappings onto switched backbones - e.g., VPNs constructed using the LAN Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2] protocols operating over ATM backbones. Where IP backbones are constructed using such protocols, by interconnecting routers over the switched backbone, the VPNs discussed operate on top of this IP network, and hence do not directly utilize the native mechanisms of the underlying backbone. Native VPNs are restricted to the scope of the underlying backbone, whereas IP based VPNs can extend to the extent of IP reachability. Native VPN protocols are clearly outside the scope of the IETF, and may be tackled by such bodies as the ATM Forum.
还请注意，本文档仅讨论跨IP主干网的VPN实现，无论是专用IP网络还是公共Internet。此处描述的模型和机制旨在应用于IPV4和IPV6主干网。本文档具体不讨论使用交换主干上的本机映射构建VPN的方法，例如，使用ATM上的LAN仿真（LANE）[1]或ATM上的多协议（MPOA）[2]协议在ATM主干上运行构建VPN。如果IP主干是使用此类协议构建的，则通过在交换主干上互连路由器，所讨论的VPN在该IP网络上运行，因此不直接利用底层主干的本机机制。本机VPN仅限于底层主干的范围，而基于IP的VPN可以扩展到IP可达性的范围。本机VPN协议显然不在IETF的范围内，可以由ATM论坛等机构解决。
There is growing interest in the use of IP VPNs as a more cost effective means of building and deploying private communication networks for multi-site communication than with existing approaches.
与现有方法相比，使用IP VPN作为构建和部署多站点通信专用通信网络的更具成本效益的方法越来越受到人们的关注。
Existing private networks can be generally categorized into two types - dedicated WANs that permanently connect together multiple sites, and dial networks, that allow on-demand connections through the Public Switched Telephone Network (PSTN) to one or more sites in the private network.
现有的专用网络一般可分为两类：永久连接多个站点的专用WAN和拨号网络，前者允许通过公共交换电话网（PSTN）按需连接到专用网络中的一个或多个站点。
WANs are typically implemented using leased lines or dedicated circuits - for instance, Frame Relay or ATM connections - between the multiple sites. CPE routers or switches at the various sites connect these dedicated facilities together and allow for connectivity across the network. Given the cost and complexity of such dedicated facilities and the complexity of CPE device configuration, such networks are generally not fully meshed, but instead have some form of hierarchical topology. For example remote offices could be connected directly to the nearest regional office, with the regional offices connected together in some form of full or partial mesh.
WAN通常使用多个站点之间的租用线路或专用电路（例如，帧中继或ATM连接）来实现。不同站点的CPE路由器或交换机将这些专用设施连接在一起，并允许通过网络进行连接。鉴于此类专用设施的成本和复杂性以及CPE设备配置的复杂性，此类网络通常不是完全网状的，而是具有某种形式的分层拓扑结构。例如，远程办公室可以直接连接到最近的区域办公室，区域办公室以某种形式的完全或部分网状连接在一起。
Private dial networks are used to allow remote users to connect into an enterprise network using PSTN or Integrated Services Digital Network (ISDN) links. Typically, this is done through the deployment of Network Access Servers (NASs) at one or more central sites. Users dial into such NASs, which interact with Authentication, Authorization, and Accounting (AAA) servers to verify the identity of the user, and the set of services that the user is authorized to receive.
专用拨号网络用于允许远程用户使用PSTN或综合业务数字网（ISDN）链路连接到企业网络。通常，这是通过在一个或多个中心站点部署网络访问服务器（NAS）来实现的。用户拨入此类NASs，NASs与身份验证、授权和计费（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的VPN产生了极大的兴趣。这主要是由于当前互联网服务的普遍性和对距离不敏感的定价，这可能导致比典型的专用或专线服务的成本显著更低。
The notion of using the Internet for private communications is not new, and many techniques, such as controlled route leaking, have been used for this purpose [3]. Only in recent times, however, have the appropriate IP mechanisms needed to meet customer requirements for VPNs all come together. These requirements include the following:
使用互联网进行私人通信的概念并不新鲜，许多技术（如受控路由泄漏）已用于此目的[3]。然而，直到最近，才有了满足客户对VPN要求所需的适当IP机制。这些要求包括：
2.1.1 Opaque Packet Transport:
2.1.1 不透明数据包传输：
The traffic carried within a VPN may have no relation to the traffic on the IP backbone, either because the traffic is multiprotocol, or because the customer's IP network may use IP addressing unrelated to that of the IP backbone on which the traffic is transported. In particular, the customer's IP network may use non-unique, private IP addressing [4].
VPN中承载的流量可能与IP主干上的流量无关，这可能是因为流量是多协议的，也可能是因为客户的IP网络可能使用与传输流量的IP主干无关的IP地址。特别是，客户的IP网络可以使用非唯一的专用IP地址[4]。
In general customers using VPNs require some form of data security. There are different trust models applicable to the use of VPNs. One such model is where the customer does not trust the service provider to provide any form of security, and instead implements a VPN using CPE devices that implement firewall functionality and that are connected together using secure tunnels. In this case the service provider is used solely for IP packet transport.
通常，使用VPN的客户需要某种形式的数据安全。vpn的使用有不同的信任模型。其中一种模式是，客户不信任服务提供商提供任何形式的安全，而是使用实现防火墙功能并使用安全隧道连接在一起的CPE设备实现VPN。在这种情况下，服务提供商仅用于IP数据包传输。
An alternative model is where the customer trusts the service provider to provide a secure managed VPN service. This is similar to the trust involved when a customer utilizes a public switched Frame Relay or ATM service, in that the customer trusts that packets will not be misdirected, injected into the network in an unauthorized manner, snooped on, modified in transit, or subjected to traffic analysis by unauthorized parties.
另一种模式是，客户信任服务提供商提供安全的托管VPN服务。这类似于客户使用公共交换帧中继或ATM服务时所涉及的信任，因为客户相信数据包不会被错误定向、以未经授权的方式注入网络、窥探、在传输过程中修改或受到未经授权方的流量分析。
With this model providing firewall functionality and secure packet transport services is the responsibility of the service provider. Different levels of security may be needed within the provider backbone, depending on the deployment scenario used. If the VPN traffic is contained within a single provider's IP backbone then strong security mechanisms, such as those provided by the IP Security protocol suite (IPSec) [5], may not be necessary for tunnels between backbone nodes. If the VPN traffic traverses networks or equipment owned by multiple administrations then strong security mechanisms may be appropriate. Also a strong level of security may be applied by a provider to customer traffic to address a customer perception that IP networks, and particularly the Internet, are insecure. Whether or not this perception is correct it is one that must be addressed by the VPN implementation.
使用此模型，提供防火墙功能和安全的数据包传输服务是服务提供商的责任。提供商主干网内可能需要不同级别的安全性，具体取决于所使用的部署场景。如果VPN流量包含在单个提供商的IP主干内，则主干节点之间的隧道可能不需要强大的安全机制，如IP安全协议套件（IPSec）[5]提供的安全机制。如果VPN流量穿越多个管理机构拥有的网络或设备，则可能需要强大的安全机制。此外，提供商还可以对客户流量应用强大的安全级别，以解决客户认为IP网络，特别是互联网不安全的看法。无论这种看法是否正确，VPN实现都必须解决这一问题。
In addition to ensuring communication privacy, existing private networking techniques, building upon physical or link layer mechanisms, also offer various types of quality of service guarantees. In particular, leased and dial up lines offer both bandwidth and latency guarantees, while dedicated connection technologies like ATM and Frame Relay have extensive mechanisms for similar guarantees. As IP based VPNs become more widely deployed, there will be market demand for similar guarantees, in order to ensure end to end application transparency. While the ability of IP based VPNs to offer such guarantees will depend greatly upon the commensurate capabilities of the underlying IP backbones, a VPN framework must also address the means by which VPN systems can utilize such capabilities, as they evolve.
除了确保通信隐私外，基于物理或链路层机制的现有私有网络技术还提供各种类型的服务质量保证。特别是，租用线路和拨号线路提供带宽和延迟保证，而ATM和帧中继等专用连接技术具有广泛的机制来提供类似的保证。随着基于IP的VPN的部署越来越广泛，市场将需要类似的担保，以确保端到端应用程序的透明度。虽然基于IP的VPN提供此类保障的能力将在很大程度上取决于底层IP主干网的相应能力，但VPN框架还必须解决VPN系统在发展过程中利用此类能力的方法。
Together, the first two of the requirements listed above imply that VPNs must be implemented through some form of IP tunneling mechanism, where the packet formats and/or the addressing used within the VPN can be unrelated to that used to route the tunneled packets across the IP backbone. Such tunnels, depending upon their form, can provide some level of intrinsic data security, or this can also be enhanced using other mechanisms (e.g., IPSec).
总之，上面列出的前两项要求意味着必须通过某种形式的IP隧道机制来实现VPN，其中VPN中使用的数据包格式和/或寻址可能与用于在IP主干上路由隧道数据包的格式和/或寻址无关。根据其形式，此类隧道可以提供某种程度的内在数据安全性，或者也可以使用其他机制（例如，IPSec）增强这种安全性。
Furthermore, as discussed later, such tunneling mechanisms can also be mapped into evolving IP traffic management mechanisms. There are already defined a large number of IP tunneling mechanisms. Some of these are well suited to VPN applications, as discussed in section 3.0.
此外，如下文所述，此类隧道机制也可以映射到演进的IP流量管理机制中。已经定义了大量的IP隧道机制。其中一些非常适合VPN应用，如第3.0节所述。
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.
人们对“基于网络的VPN”也很感兴趣，VPN的运营外包给互联网服务提供商（ISP），并在网络上实施，而不是在CPE设备上实施。寻求降低支持成本的客户和寻求新收入来源的ISP对此类解决方案都非常感兴趣。在网络中支持VPN允许使用特定的机制，这可能导致高效、经济的VPN解决方案，公共设备和运营支持在大量客户中分摊。
Most of the mechanisms discussed below can apply to either CPE based or network based VPNs. However particular mechanisms are likely to prove applicable only to the latter, since they leverage tools (e.g., piggybacking on routing protocols) which are accessible only to ISPs and which are unlikely to be made available to any customer, or even hosted on ISP owned and operated CPE, due to the problems of coordinating joint management of the CPE gear by both the ISP and the customer. This document will indicate which techniques are likely to apply only to network based VPNs.
下面讨论的大多数机制可以应用于基于CPE或基于网络的VPN。然而，特定机制可能仅适用于后者，因为它们利用的工具（例如，路由协议上的背驮）仅可供ISP访问，且不可能提供给任何客户，甚至不可能托管在ISP拥有和运营的CPE上，由于ISP和客户在协调CPE设备的联合管理方面存在问题。本文档将说明哪些技术可能仅适用于基于网络的VPN。
The term 'extranet' is commonly used to refer to a scenario whereby two or more companies have networked access to a limited amount of each other's corporate data. For example a manufacturing company might use an extranet for its suppliers to allow it to query databases for the pricing and availability of components, and then to order and track the status of outstanding orders. Another example is joint software development, for instance, company A allows one development group within company B to access its operating system source code, and company B allows one development group in company A to access its security software. Note that the access policies can get arbitrarily complex. For example company B may internally restrict access to its security software to groups in certain geographic locations to comply with export control laws, for example.
术语“外联网”通常用于指两个或多个公司通过网络访问彼此有限数量的公司数据的情况。例如，一家制造公司可能会为其供应商使用一个外联网，以允许其查询数据库中组件的定价和可用性，然后订购和跟踪未完成订单的状态。另一个例子是联合软件开发，例如，A公司允许B公司内的一个开发组访问其操作系统源代码，B公司允许A公司内的一个开发组访问其安全软件。请注意，访问策略可能会变得任意复杂。例如，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.
因此，外联网的一个关键特性是控制谁可以访问什么数据，这本质上是一个政策决定。今天，通常在不同域之间的互连点强制执行策略决策，例如在专用网络和Internet之间，或者在软件测试实验室和公司网络的其余部分之间。可通过防火墙、具有访问列表功能的路由器、应用网关或能够将策略应用于传输流量的任何类似设备来执行。策略控制可以在公司网络内实施，也可以在公司网络之间实施。此外，网络之间的互连可以是一组双边链路，也可以是一个单独的网络，可能由一个行业联盟维护。这个独立的网络本身可以是VPN或物理网络。
Introducing VPNs into a network does not require any change to this model. Policy can be enforced between two VPNs, or between a VPN and the Internet, in exactly the same manner as is done today without VPNs. For example two VPNs could be interconnected, which each administration locally imposing its own policy controls, via a firewall, on all traffic that enters its VPN from the outside, whether from another VPN or from the Internet.
将VPN引入网络不需要对此模型进行任何更改。策略可以在两个VPN之间或VPN与Internet之间强制执行，执行方式与今天没有VPN时完全相同。例如，两个VPN可以互连，每个管理部门通过防火墙在本地对从外部进入其VPN的所有流量（无论是从另一个VPN还是从Internet）实施自己的策略控制。
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模型提供了策略与所用数据包传输的底层模式的分离。例如，路由器可以将语音通信定向到ATM虚拟信道连接（VCC）以保证QoS，将非本地内部公司通信定向到安全隧道，并将其他通信定向到到互联网的链路。过去，安全隧道可能是帧中继电路，现在它们也可能是安全IP隧道或MPLS标签交换路径（LSP）
Other models of a VPN are also possible. For example there is a model whereby a set of application flows is mapped into a VPN. As the policy rules imposed by a network administrator can get quite complex, the number of distinct sets of application flows that are used in the policy rulebase, and hence the number of VPNs, can thus grow quite large, and there can be multiple overlapping VPNs. However there is little to be gained by introducing such new complexity into a network. Instead a VPN should be viewed as a direct analogue to a physical network, as this allows the leveraging of existing protocols and procedures, and the current expertise and skill sets of network administrators and customers.
VPN的其他模型也是可能的。例如，有一个模型将一组应用程序流映射到VPN中。由于网络管理员施加的策略规则可能变得非常复杂，因此策略规则库中使用的不同应用程序流集的数量以及VPN的数量可能会因此变得相当大，并且可能存在多个重叠的VPN。然而，在网络中引入这种新的复杂性并没有什么好处。相反，VPN应被视为与物理网络的直接模拟，因为这允许利用现有协议和程序，以及网络管理员和客户当前的专业知识和技能。
As noted above in section 2.1, VPNs must be implemented using some form of tunneling mechanism. This section looks at the generic requirements for such VPN tunneling mechanisms. A number of characteristics and aspects common to any link layer protocol are taken and compared with the features offered by existing tunneling protocols. This provides a basis for comparing different protocols and is also useful to highlight areas where existing tunneling protocols could benefit from extensions to better support their operation in a VPN environment.
如上文第2.1节所述，VPN必须使用某种形式的隧道机制来实现。本节介绍此类VPN隧道机制的一般要求。任何链路层协议都具有许多共同的特性和方面，并与现有隧道协议提供的特性进行了比较。这为比较不同协议提供了基础，也有助于突出现有隧道协议可以从扩展中获益的领域，从而更好地支持其在VPN环境中的操作。
An IP tunnel connecting two VPN endpoints is a basic building block from which a variety of different VPN services can be constructed. An IP tunnel operates as an overlay across the IP backbone, and the traffic sent through the tunnel is opaque to the underlying IP backbone. In effect the IP backbone is being used as a link layer technology, and the tunnel forms a point-to-point link.
连接两个VPN端点的IP隧道是一个基本构建块，可以从中构建各种不同的VPN服务。IP隧道作为覆盖层在IP主干上运行，通过隧道发送的流量对底层IP主干是不透明的。实际上，IP主干网被用作链路层技术，隧道形成点对点链路。
A VPN device may terminate multiple IP tunnels and forward packets between these tunnels and other network interfaces in different ways. In the discussion of different types of VPNs, in later sections of this document, the primary distinguishing characteristic of these different types is the manner in which packets are forwarded between interfaces (e.g., bridged or routed). There is a direct analogy with how existing networking devices are characterized today. A two-port repeater just forwards packets between its ports, and does not examine the contents of the packet. A bridge forwards packets using Media Access Control (MAC) layer information contained in the packet, while a router forwards packets using layer 3 addressing information contained in the packet. Each of these three scenarios has a direct VPN analogue, as discussed later. Note that an IP tunnel is viewed as just another sort of link, which can be concatenated with another link, bound to a bridge forwarding table, or bound to an IP forwarding table, depending on the type of VPN.
VPN设备可以终止多个IP隧道，并以不同的方式在这些隧道和其他网络接口之间转发数据包。在本文件后面章节讨论不同类型的VPN时，这些不同类型VPN的主要区别特征是在接口之间转发数据包的方式（例如桥接或路由）。这与现有网络设备的特点有直接的相似之处。双端口中继器只在其端口之间转发数据包，而不检查数据包的内容。网桥使用包中包含的媒体访问控制（MAC）层信息转发包，而路由器使用包中包含的第3层寻址信息转发包。这三个场景中的每一个都有一个直接的VPN模拟，如下文所述。请注意，IP隧道仅被视为另一种链路，可以与另一种链路连接、绑定到网桥转发表或绑定到IP转发表，具体取决于VPN的类型。
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.
以下各节介绍了通用IP隧道协议的要求，该协议可用作构建不同类型VPN的基本构建块。
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]、通用路由封装（GRE）隧道[7]、第二层隧道协议（L2TP）[8]、IPSec[5]和多协议标签交换（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之间有一个显著的区别。MPLS可以被视为IP的特定链路层，因为MPLS特定的机制仅适用于MPLS网络的范围，而基于IP的机制扩展到IP可达性的范围。因此，根据定义，直接建立在MPLS隧道机制之上的VPN机制不能扩展到MPLS网络的范围之外，就像基于ATM的机制（如LANE）可以扩展到ATM网络之外一样。然而，请注意，MPLS网络可以跨越许多不同的链路层技术，因此，与IP网络一样，其范围不受所使用的特定链路层的限制。还提出了一些建议，以定义一套机制，允许专门通过MPLS网络进行互操作的VPN（[10][11][12][13]、[14]和[15]）。
There are a number of desirable requirements for a VPN tunneling mechanism, however, that are not all met by the existing tunneling mechanisms. These requirements include:
然而，VPN隧道机制有许多可取的要求，而现有的隧道机制并不能完全满足这些要求。这些要求包括：
There are cases where multiple VPN tunnels may be needed between the same two IP endpoints. This may be needed, for instance, in cases where the VPNs are network based, and each end point supports multiple customers. Traffic for different customers travels over separate tunnels between the same two physical devices. A multiplexing field is needed to distinguish which packets belong to which tunnel. Sharing a tunnel in this manner may also reduce the latency and processing burden of tunnel set up. Of the existing IP tunneling mechanisms, L2TP (via the tunnel-id and session-id fields), MPLS (via the label) and IPSec (via the Security Parameter Index (SPI) field) have a multiplexing mechanism. Strictly speaking GRE does not have a multiplexing field. However the key field, which was
在某些情况下，相同的两个IP端点之间可能需要多个VPN隧道。例如，在VPN基于网络且每个端点支持多个客户的情况下，可能需要这样做。不同客户的流量通过相同两个物理设备之间的单独隧道传输。需要一个多路复用字段来区分哪些数据包属于哪个隧道。以这种方式共享隧道还可以减少隧道设置的延迟和处理负担。在现有的IP隧道机制中，L2TP（通过隧道id和会话id字段）、MPLS（通过标签）和IPSec（通过安全参数索引（SPI）字段）具有多路复用机制。严格来说，GRE没有多路复用字段。然而，关键领域是
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.
IETF[16]和ATM论坛[17]已经对用于识别VPN（VPN-ID）的全球唯一标识符的单一格式进行了标准化。VPN-ID可在控制平面中用于在隧道建立时将隧道绑定到VPN，或在数据平面中用于基于每个分组识别与分组相关联的VPN。在数据平面中，MPLS、MPOA和其他隧道机制可以使用VPN封装头在单个隧道上聚合不同VPN的数据包。在这种情况下，每个数据包都包含VPN-ID的明确指示，并且不使用任何特定于隧道的多路复用字段。在控制平面中，VPN-ID字段可以包括在任何隧道建立信令协议中，以允许隧道（例如，由SPI字段标识）与VPN的关联。在这种情况下，不需要将VPN-ID包括在每个数据包中。第5.3.1节对此进行了进一步讨论。
There is some configuration information that must be known by an end point in advance of tunnel establishment, such as the IP address of the remote end point, and any relevant tunnel attributes required, such as the level of security needed. Once this information is available, the actual tunnel establishment can be completed in one of two ways - via a management operation, or via a signalling protocol that allows tunnels to be established dynamically.
在建立隧道之前，端点必须知道一些配置信息，例如远程端点的IP地址，以及所需的任何相关隧道属性，例如所需的安全级别。一旦该信息可用，实际的隧道建立可以通过两种方式之一完成——通过管理操作，或通过允许动态建立隧道的信令协议。
An example of a management operation would be to use an SNMP Management Information Base (MIB) to configure various tunneling parameters, e.g., MPLS labels, source addresses to use for IP/IP or GRE tunnels, L2TP tunnel-ids and session-ids, or security association parameters for IPSec.
管理操作的一个示例是使用SNMP管理信息库（MIB）配置各种隧道参数，例如，MPLS标签、用于IP/IP或GRE隧道的源地址、L2TP隧道ID和会话ID，或用于IPSec的安全关联参数。
Using a signalling protocol can significantly reduce the management burden however, and as such, is essential in many deployment scenarios. It reduces the amount of configuration needed, and also reduces the management co-ordination needed if a VPN spans multiple administrative domains. For example, the value of the multiplexing field, described above, is local to the node assigning the value, and can be kept local if distributed via a signalling protocol, rather than being first configured into a management station and then distributed to the relevant nodes. A signalling protocol also allows nodes that are mobile or are only intermittently connected to establish tunnels on demand.
然而，使用信令协议可以显著减少管理负担，因此在许多部署场景中是必不可少的。它减少了所需的配置量，并且还减少了VPN跨越多个管理域时所需的管理协调。例如，如上所述的多路复用字段的值对于分配该值的节点是本地的，并且如果通过信令协议分发，则可以保持本地的，而不是首先配置到管理站，然后分发到相关节点。信令协议还允许移动节点或仅间歇连接的节点按需建立隧道。
When used in a VPN environment a signalling protocol should allow for the transport of a VPN-ID to allow the resulting tunnel to be associated with a particular VPN. It should also allow tunnel attributes to be exchanged or negotiated, for example the use of frame sequencing or the use of multiprotocol transport. Note that the role of the signalling protocol need only be to negotiate tunnel attributes, not to carry information about how the tunnel is used, for example whether the frames carried in the tunnel are to be forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM signalling - the same signalling protocol is used to set up Classical IP logical subnetworks as well as for LANE emulated LANs.
在VPN环境中使用时，信令协议应允许传输VPN-ID，以允许生成的隧道与特定VPN相关联。它还应允许交换或协商隧道属性，例如使用帧排序或使用多协议传输。注意，信令协议的作用只需要协商隧道属性，而不需要携带关于如何使用隧道的信息，例如隧道中携带的帧是在第2层还是第3层转发。（这类似于Q.2931 ATM信令-相同的信令协议用于建立经典IP逻辑子网以及车道模拟LAN。
Of the various IP tunneling protocols, the following ones support a signalling protocol that could be adapted for this purpose: L2TP (the L2TP control protocol), IPSec (the Internet Key Exchange (IKE) protocol [18]), and GRE (as used with mobile-ip tunneling [19]). Also there are two MPLS signalling protocols that can be used to establish LSP tunnels. One uses extensions to the MPLS Label Distribution Protocol (LDP) protocol [20], called Constraint-Based Routing LDP (CR-LDP) [21], and the other uses extensions to the Resource Reservation Protocol (RSVP) for LSP tunnels [22].
在各种IP隧道协议中，以下协议支持可用于此目的的信令协议：L2TP（L2TP控制协议）、IPSec（互联网密钥交换（IKE）协议[18]）和GRE（与移动IP隧道一起使用[19]）。还有两种MPLS信令协议可用于建立LSP隧道。一个使用对MPLS标签分发协议（LDP）协议的扩展[20]，称为基于约束的路由LDP（CR-LDP）[21]，另一个使用对LSP隧道的资源预留协议（RSVP）的扩展[22]。
A VPN tunneling protocol must support mechanisms to allow for whatever level of security may be desired by customers, including authentication and/or encryption of various strengths. None of the tunneling mechanisms discussed, other than IPSec, have intrinsic security mechanisms, but rely upon the security characteristics of the underlying IP backbone. In particular, MPLS relies upon the explicit labeling of label switched paths to ensure that packets cannot be misdirected, while the other tunneling mechanisms can all be secured through the use of IPSec. For VPNs implemented over non-IP backbones (e.g., MPOA, Frame Relay or ATM virtual circuits), data security is implicitly provided by the layer two switch infrastructure.
VPN隧道协议必须支持各种机制，以允许客户需要任何级别的安全性，包括各种强度的身份验证和/或加密。除了IPSec之外，讨论的隧道机制都没有内在的安全机制，而是依赖于底层IP主干的安全特性。特别是，MPLS依赖于标签交换路径的显式标记，以确保数据包不会被误导，而其他隧道机制都可以通过使用IPSec来保护。对于通过非IP主干网（例如MPOA、帧中继或ATM虚拟电路）实现的VPN，数据安全由第二层交换机基础设施隐式提供。
Overall VPN security is not just a capability of the tunnels alone, but has to be viewed in the broader context of how packets are forwarded onto those tunnels. For example with VPRNs implemented with virtual routers, the use of separate routing and forwarding table instances ensures the isolation of traffic between VPNs. Packets on one VPN cannot be misrouted to a tunnel on a second VPN since those tunnels are not visible to the forwarding table of the first VPN.
总体VPN安全性不仅仅是隧道的一种能力，还必须从更广泛的角度来看待如何将数据包转发到这些隧道。例如，对于使用虚拟路由器实现的VPRN，使用单独的路由和转发表实例可确保VPN之间的流量隔离。一个VPN上的数据包不能错误路由到第二个VPN上的隧道，因为这些隧道对于第一个VPN的转发表不可见。
If some form of signalling mechanism is used by one VPN end point to dynamically establish a tunnel with another endpoint, then there is a requirement to be able to authenticate the party attempting the tunnel establishment. IPSec has an array of schemes for this purpose, allowing, for example, authentication to be based on pre-shared keys, or to use digital signatures and certificates. Other tunneling schemes have weaker forms of authentication. In some cases no authentication may be needed, for example if the tunnels are provisioned, rather than dynamically established, or if the trust model in use does not require it.
如果一个VPN端点使用某种形式的信令机制与另一个端点动态建立隧道，则需要能够对尝试建立隧道的一方进行身份验证。IPSec为此目的提供了一系列方案，例如，允许基于预共享密钥进行身份验证，或者使用数字签名和证书。其他隧道方案具有较弱的身份验证形式。在某些情况下，可能不需要身份验证，例如，如果提供了隧道，而不是动态建立，或者如果使用的信任模型不需要身份验证。
Currently the IPSec Encapsulating Security Payload (ESP) protocol [23] can be used to establish SAs that support either encryption or authentication or both. However the protocol specification precludes the use of an SA where neither encryption or authentication is used. In a VPN environment this "null/null" option is useful, since other aspects of the protocol (e.g., that it supports tunneling and multiplexing) may be all that is required. In effect the "null/null" option can be viewed as just another level of data security.
目前，IPSec封装安全有效负载（ESP）协议[23]可用于建立支持加密或身份验证或两者兼有的SAs。但是，协议规范禁止在不使用加密或身份验证的情况下使用SA。在VPN环境中，此“null/null”选项非常有用，因为协议的其他方面（例如，它支持隧道和多路复用）可能是所需的全部。实际上，“null/null”选项可以看作是数据安全的另一个级别。
In many applications of VPNs, the VPN may carry opaque, multiprotocol traffic. As such, the tunneling protocol used must also support multiprotocol transport. L2TP is designed to transport Point-to-Point Protocol (PPP) [24] packets, and thus can be used to carry multiprotocol traffic since PPP itself is multiprotocol. GRE also provides for the identification of the protocol being tunneled. IP/IP and IPSec tunnels have no such protocol identification field, since the traffic being tunneled is assumed to be IP.
在VPN的许多应用中，VPN可能承载不透明的多协议流量。因此，所使用的隧道协议还必须支持多协议传输。L2TP设计用于传输点对点协议（PPP）[24]数据包，因此可用于承载多协议流量，因为PPP本身是多协议的。GRE还提供正在隧道中的协议的标识。IP/IP和IPSec隧道没有这样的协议标识字段，因为隧道中的流量被假定为IP。
It is possible to extend the IPSec protocol suite to allow for the transport of multiprotocol packets. This can be achieved, for example, by extending the signalling component of IPSec - IKE, to indicate the protocol type of the traffic being tunneled, or to carry a packet multiplexing header (e.g., an LLC/SNAP header or GRE header) with each tunneled packet. This approach is similar to that used for the same purpose in ATM networks, where signalling is used to indicate the encapsulation used on the VCC, and where packets sent on the VCC can use either an LLC/SNAP header or be placed directly into the AAL5 payload, the latter being known as VC-multiplexing (see [25]).
可以扩展IPSec协议套件以允许多协议数据包的传输。例如，可以通过扩展IPSec-IKE的信令组件来实现这一点，以指示正在隧道传输的通信量的协议类型，或者通过每个隧道传输的数据包携带数据包多路复用报头（例如，LLC/SNAP报头或GRE报头）。该方法类似于ATM网络中用于相同目的的方法，其中信令用于指示VCC上使用的封装，并且在VCC上发送的数据包可以使用LLC/SNAP报头或直接放入AAL5有效负载，后者称为VC多路复用（见[25]）。
One quality of service attribute required by customers of a VPN may be frame sequencing, matching the equivalent characteristic of physical leased lines or dedicated connections. Sequencing may be
VPN客户需要的一个服务质量属性可能是帧排序，与物理租用线路或专用连接的等效特性相匹配。排序可能是
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来协商是否使用排序，并定义保留数据包排序的端点行为来实现这一点。
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.
有两种可能的方法。一种是隧道协议本身定期检查带内的连接丢失，并提供故障的明确指示。例如，L2TP有一个可选的保持活动机制来检测非运行隧道。
The other approach does not require the tunneling protocol itself to perform this function, but relies on the operation of some out-of-band mechanism to determine loss of connectivity. For example if a routing protocol such as Routing Information Protocol (RIP) [26] or Open Shortest Path First (OSPF) [27] is run over a tunnel mesh, a failure to hear from a neighbor within a certain period of time will result in the routing protocol declaring the tunnel to be down. Another out-of-band approach is to perform regular ICMP pings with a peer. This is generally sufficient assurance that the tunnel is operational, due to the fact the tunnel also runs across the same IP backbone.
另一种方法不需要隧道协议本身来执行此功能，而是依赖于某些带外机制的操作来确定连接丢失。例如，如果诸如路由信息协议（RIP）[26]或开放最短路径优先（OSPF）[27]之类的路由协议在隧道网格上运行，则在特定时间段内未能听到邻居的消息将导致路由协议宣布隧道关闭。另一种带外方法是与对等机执行常规ICMP ping。这通常足以保证隧道正常运行，因为隧道也运行在同一IP主干上。
When tunnels are established dynamically a distinction needs to be drawn between the static and dynamic tunnel information needed. Before a tunnel can be established some static information is needed by a node, such as the identify of the remote end point and the attributes of the tunnel to propose and accept. This is typically put in place as a result of a configuration operation. As a result of the signalling exchange to establish a tunnel, some dynamic state is established in each end point, such as the value of the multiplexing field or keys to be used. For example with IPSec, the establishment of a Security Association (SA) puts in place the keys to be used for the lifetime of that SA.
当动态建立隧道时，需要区分所需的静态和动态隧道信息。在建立隧道之前，节点需要一些静态信息，例如远程端点的标识以及要提议和接受的隧道属性。这通常是配置操作的结果。作为建立隧道的信令交换的结果，在每个端点中建立一些动态状态，例如要使用的多路复用字段或密钥的值。例如，对于IPSec，安全关联（SA）的建立将在该SA的生命周期内使用密钥。
Different policies may be used as to when to trigger the establishment of a dynamic tunnel. One approach is to use a data-driven approach and to trigger tunnel establishment whenever there is data to be transferred, and to timeout the tunnel due to inactivity. This approach is particularly useful if resources for the tunnel are being allocated in the network for QoS purposes. Another approach is to trigger tunnel establishment whenever the static tunnel configuration information is installed, and to attempt to keep the tunnel up all the time.
关于何时触发动态隧道的建立，可以使用不同的策略。一种方法是使用数据驱动的方法，在有数据要传输时触发隧道建立，并由于不活动而使隧道超时。如果为了QoS目的在网络中分配隧道资源，则此方法特别有用。另一种方法是在安装静态隧道配置信息时触发隧道建立，并尝试始终保持隧道正常运行。
An IP tunnel has an associated Maximum Transmission Unit (MTU), just like a regular link. It is conceivable that this MTU may be larger than the MTU of one or more individual hops along the path between tunnel endpoints. If so, some form of frame fragmentation will be required within the tunnel.
IP隧道具有相关的最大传输单元（MTU），就像常规链路一样。可以想象，该MTU可以大于沿着隧道端点之间的路径的一个或多个单独跳的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.
如果要传输的帧映射到一个IP数据报，则当IP数据报到达MTU小于IP隧道MTU的跃点时，将发生正常的IP碎片。这可能会对执行这种中间通道分段的路由器产生不良的性能影响。
An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism.
另一种方法是隧道协议本身包含在隧道级别运行的分段和重组功能，可能使用隧道序列号和某种类型的消息结束标记。（请注意，多链路PPP使用类似于此的机制来分割数据包）。这避免了隧道本身内的IP级碎片。现有的隧道协议都不支持这种机制。
There is clearly benefit in minimizing the overhead of any tunneling mechanisms. This is particularly important for the transport of jitter and latency sensitive traffic such as packetized voice and video. On the other hand, the use of security mechanisms, such as IPSec, do impose their own overhead, hence the objective should be to minimize overhead over and above that needed for security, and to not burden those tunnels in which security is not mandatory with unnecessary overhead.
将任何隧道机制的开销降至最低显然是有益的。这对于传输抖动和延迟敏感的流量（如分组语音和视频）尤为重要。另一方面，安全机制（如IPSec）的使用确实会增加其自身的开销，因此目标应该是最大限度地减少超出安全所需的开销，并且不会给那些安全不是强制性的隧道带来不必要的开销。
One area where the amount of overhead may be significant is when voluntary tunneling is used for dial-up remote clients connecting to a VPN, due to the typically low bandwidth of dial-up links. This is discussed further in section 6.3.
由于拨号链路的带宽通常较低，当使用自愿隧道连接到VPN的拨号远程客户端时，开销可能很大。这将在第6.3节中进一步讨论。
During the development of the L2TP protocol procedures were developed for flow and congestion control. These were necessitated primarily because of the need to provide adequate performance over lossy networks when PPP compression is used, which, unlike IP Payload Compression Protocol (IPComp) [28], is stateful across packets. Another motivation was to accommodate devices with very little buffering, used for example to terminate low speed dial-up lines. However the flow and congestion control mechanisms defined in the final version of the L2TP specification are used only for the control channels, and not for data traffic.
在L2TP协议的开发过程中，开发了流量和拥塞控制程序。这主要是因为在使用PPP压缩时需要在有损网络上提供足够的性能，而PPP压缩不同于IP有效负载压缩协议（IPComp）[28]，它是跨数据包的有状态的。另一个动机是容纳缓冲很少的设备，例如用于终止低速拨号线路。然而，L2TP规范最终版本中定义的流量和拥塞控制机制仅用于控制信道，而不用于数据流量。
In general the interactions between multiple layers of flow and congestion control schemes can be very complex. Given the predominance of TCP traffic in today's networks and the fact that TCP has its own end-to-end flow and congestion control mechanisms, it is not clear that there is much benefit to implementing similar mechanisms within tunneling protocols. Good flow and congestion control schemes, that can adapt to a wide variety of network conditions and deployment scenarios are complex to develop and test, both in themselves and in understanding the interaction with other schemes that may be running in parallel. There may be some benefit, however, in having the capability whereby a sender can shape traffic to the capacity of a receiver in some manner, and in providing the protocol mechanisms to allow a receiver to signal its capabilities to a sender. This is an area that may benefit from further study.
一般来说，多层流量和拥塞控制方案之间的相互作用可能非常复杂。鉴于TCP流量在当今网络中占主导地位，并且TCP有自己的端到端流量和拥塞控制机制，在隧道协议中实现类似机制是否有多大好处尚不清楚。能够适应各种网络条件和部署场景的良好流量和拥塞控制方案的开发和测试非常复杂，无论是在其自身还是在理解与可能并行运行的其他方案的交互方面。然而，在具有发送方能够以某种方式将通信量塑造成接收机容量的能力，以及在提供协议机制以允许接收机向发送方发送其能力的信号方面，可能存在一些益处。这是一个可以从进一步研究中受益的领域。
Note also the work of the Performance Implications of Link Characteristics (PILC) working group of the IETF, which is examining how the properties of different network links can have an impact on the performance of Internet protocols operating over those links.
另请注意IETF链路特性性能影响（PILC）工作组的工作，该工作组正在研究不同网络链路的特性如何影响通过这些链路运行的互联网协议的性能。
As noted above, customers may require that VPNs yield similar behaviour to physical leased lines or dedicated connections with respect to such QoS parameters as loss rates, jitter, latency and bandwidth guarantees. How such guarantees could be delivered will, in general, be a function of the traffic management characteristics of the VPN nodes themselves, and the access and backbone networks across which they are connected.
如上所述，客户可能要求VPN在丢失率、抖动、延迟和带宽保证等QoS参数方面产生与物理租用线路或专用连接类似的行为。通常，如何提供此类保障将取决于VPN节点本身的流量管理特性以及它们所连接的接入和骨干网络。
A full discussion of QoS and VPNs is outside the scope of this document, however by modeling a VPN tunnel as just another type of link layer, many of the existing mechanisms developed for ensuring QoS over physical links can also be applied. For example at a VPN node, the mechanisms of policing, marking, queuing, shaping and
对QoS和VPN的全面讨论超出了本文档的范围，但是，通过将VPN隧道建模为另一种类型的链路层，也可以应用为确保物理链路上的QoS而开发的许多现有机制。例如，在VPN节点上，监控、标记、排队、整形和
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流量一样。在MPLS中为Diffserv、Intserv和流量工程开发的技术也适用。有关QoS和VPN的讨论，请参见[29]。
It should be noted, however, that this model of tunnel operation is not necessarily consistent with the way in which specific tunneling protocols are currently modeled. While a model is an aid to comprehension, and not part of a protocol specification, having differing models can complicate discussions, particularly if a model is misinterpreted as being part of a protocol specification or as constraining choice of implementation method. For example, IPSec tunnel processing can be modeled both as an interface and as an attribute of a particular packet flow.
然而，应该注意的是，隧道操作的这种模型不一定与当前特定隧道协议的建模方式一致。虽然模型有助于理解，而不是协议规范的一部分，但具有不同的模型可能会使讨论复杂化，特别是当模型被误解为协议规范的一部分或限制实现方法的选择时。例如，可以将IPSec隧道处理建模为接口和特定数据包流的属性。
IPSec is needed whenever there is a requirement for strong encryption or strong authentication. It also supports multiplexing and a signalling protocol - IKE. However extending the IPSec protocol suite to also cover the following areas would be beneficial, in order to better support the tunneling requirements of a VPN environment.
只要需要强加密或强身份验证，就需要IPSec。它还支持多路复用和信令协议IKE。但是，为了更好地支持VPN环境的隧道要求，扩展IPSec协议套件以涵盖以下领域将是有益的。
- the transport of a VPN-ID when establishing an SA (3.1.2)
- 建立SA时VPN-ID的传输（3.1.2）
- a null encryption and null authentication option (3.1.3)
- 空加密和空身份验证选项（3.1.3）
- multiprotocol operation (3.1.4)
- 多协议操作（3.1.4）
- frame sequencing (3.1.5)
- 帧排序（3.1.5）
L2TP provides no data security by itself, and any PPP security mechanisms used do not apply to the L2TP protocol itself, so that in order for strong security to be provided L2TP must run over IPSec. Defining specific modes of operation for IPSec when it is used to support L2TP traffic will aid interoperability. This is currently a work item for the proposed L2TP working group.
L2TP本身不提供数据安全性，并且使用的任何PPP安全机制都不适用于L2TP协议本身，因此为了提供强安全性，L2TP必须通过IPSec运行。当IPSec用于支持L2TP通信时，为其定义特定的操作模式将有助于互操作性。这是拟议L2TP工作组目前的一个工作项目。
The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service. In this case a point-to-point link is provided to a customer, connecting two CPE devices, as illustrated below. The link layer type used to connect the CPE devices to the ISP nodes can be any link layer type, for example an ATM VCC or a Frame Relay circuit. The CPE devices can be either routers bridges or hosts.
VPN最简单的形式是“虚拟专线”（VLL）服务。在这种情况下，向客户提供点对点链路，连接两个CPE设备，如下所示。用于将CPE设备连接到ISP节点的链路层类型可以是任何链路层类型，例如ATM VCC或帧中继电路。CPE设备可以是路由器、网桥或主机。
The two ISP nodes are both connected to an IP network, and an IP tunnel is set up between them. Each ISP node is configured to bind the stub link and the IP tunnel together at layer 2 (e.g., an ATM VCC and the IP tunnel). Frames are relayed between the two links. For example the ATM Adaptation Layer 5 (AAL5) payload is taken and encapsulated in an IPSec tunnel, and vice versa. The contents of the AAL5 payload are opaque to the ISP node, and are not examined there.
两个ISP节点都连接到IP网络，并在它们之间建立IP隧道。每个ISP节点配置为在第2层将存根链路和IP隧道绑定在一起（例如，ATM VCC和IP隧道）。帧在两个链路之间中继。例如，ATM适配层5（AAL5）有效负载被获取并封装在IPSec隧道中，反之亦然。AAL5有效负载的内容对于ISP节点来说是不透明的，并且没有在那里进行检查。
+--------+ ----------- +--------+
+---+ | ISP | ( IP ) | ISP | +---+
|CPE|-------| edge |-----( backbone ) -----| edge |------|CPE|
+---+ ATM | node | ( ) | node | ATM +---+
VCC +--------+ ----------- +--------+ VCC
+--------+ ----------- +--------+
+---+ | ISP | ( IP ) | ISP | +---+
|CPE|-------| edge |-----( backbone ) -----| edge |------|CPE|
+---+ ATM | node | ( ) | node | ATM +---+
VCC +--------+ ----------- +--------+ VCC
<--------- IP Tunnel -------->
<--------- IP Tunnel -------->
10.1.1.5 subnet = 10.1.1.4/30 10.1.1.6 Addressing used by customer (transparent to provider)
10.1.1.5 子网=10.1.1.4/30客户使用的10.1.1.6寻址（对提供商透明）
Figure 4.1: VLL Example
图4.1：VLL示例
To a customer it looks the same as if a single ATM VCC or Frame Relay circuit were used to interconnect the CPE devices, and the customer could be unaware that part of the circuit was in fact implemented over an IP backbone. This may be useful, for example, if a provider wishes to provide a LAN interconnect service using ATM as the network interface, but does not have an ATM network that directly interconnects all possible customer sites.
对于客户来说，这看起来就像使用单个ATM VCC或帧中继电路互连CPE设备一样，客户可能不知道部分电路实际上是通过IP主干实现的。例如，如果提供商希望提供使用ATM作为网络接口的LAN互连服务，但没有直接互连所有可能客户站点的ATM网络，则这可能很有用。
It is not necessary that the two links used to connect the CPE devices to the ISP nodes be of the same media type, but in this case the ISP nodes cannot treat the traffic in an opaque manner, as described above. Instead the ISP nodes must perform the functions of an interworking device between the two media types (e.g., ATM and Frame Relay), and perform functions such as LLC/SNAP to NLPID conversion, mapping between ARP protocol variants and performing any media specific processing that may be expected by the CPE devices (e.g., ATM OAM cell handling or Frame Relay XID exchanges).
用于将CPE设备连接到ISP节点的两个链路不必具有相同的媒体类型，但是在这种情况下，ISP节点不能以不透明的方式处理通信量，如上所述。相反，ISP节点必须在两种媒体类型（例如ATM和帧中继）之间执行互通设备的功能，并执行诸如LLC/SNAP-to-NLPID转换、ARP协议变体之间的映射以及执行CPE设备可能期望的任何媒体特定处理等功能（例如，ATM OAM信元处理或帧中继XID交换）。
The IP tunneling protocol used must support multiprotocol operation and may need to support sequencing, if that characteristic is important to the customer traffic. If the tunnels are established using a signalling protocol, they may be set up in a data driven manner, when a frame is received from a customer link and no tunnel exists, or the tunnels may be established at provisioning time and kept up permanently.
使用的IP隧道协议必须支持多协议操作，如果该特性对客户流量很重要，则可能需要支持排序。如果使用信令协议建立隧道，则当从客户链路接收到帧且不存在隧道时，可以以数据驱动的方式建立隧道，或者可以在供应时建立隧道并永久保持。
Note that the use of the term 'VLL' in this document is different to that used in the definition of the Diffserv Expedited Forwarding Per Hop Behaviour (EF-PHB) [30]. In that document a VLL is used to mean a low latency, low jitter, assured bandwidth path, which can be provided using the described PHB. Thus the focus there is primarily on link characteristics that are temporal in nature. In this document the term VLL does not imply the use of any specific QoS mechanism, Diffserv or otherwise. Instead the focus is primarily on link characteristics that are more topological in nature, (e.g., such as constructing a link which includes an IP tunnel as one segment of the link). For a truly complete emulation of a link layer both the temporal and topological aspects need to be taken into account.
请注意，本文件中术语“VLL”的使用与Diffserv每跳快速转发行为（EF-PHB）定义中使用的术语不同[30]。在该文档中，VLL用于表示可使用所述PHB提供的低延迟、低抖动、有保证的带宽路径。因此，这里的重点主要是在性质上是暂时的链路特性上。在本文档中，术语VLL并不意味着使用任何特定的QoS机制，区分服务或其他。相反，重点主要放在更具拓扑性质的链路特性上（例如，构建包含IP隧道作为链路一段的链路）。为了真正完整地模拟链路层，需要考虑时间和拓扑方面。
A Virtual Private Routed Network (VPRN) is defined to be the emulation of a multi-site wide area routed network using IP facilities. This section looks at how a network-based VPRN service can be provided. CPE-based VPRNs are also possible, but are not specifically discussed here. With network-based VPRNs many of the issues that need to be addressed are concerned with configuration and operational issues, which must take into account the split in administrative responsibility between the service provider and the service user.
虚拟专用路由网络（VPRN）定义为使用IP设施模拟多站点广域路由网络。本节介绍如何提供基于网络的VPRN服务。基于CPE的VPRN也是可能的，但此处不具体讨论。对于基于网络的VPRN，许多需要解决的问题与配置和操作问题有关，这些问题必须考虑到服务提供商和服务用户之间的管理责任划分。
The distinguishing characteristic of a VPRN, in comparison to other types of VPNs, is that packet forwarding is carried out at the network layer. A VPRN consists of a mesh of IP tunnels between ISP routers, together with the routing capabilities needed to forward traffic received at each VPRN node to the appropriate destination site. Attached to the ISP routers are CPE routers connected via one or more links, termed 'stub' links. There is a VPRN specific forwarding table at each ISP router to which members of the VPRN are connected. Traffic is forwarded between ISP routers, and between ISP routers and customer sites, using these forwarding tables, which contain network layer reachability information (in contrast to a Virtual Private LAN Segment type of VPN (VPLS) where the forwarding tables contain MAC layer reachability information - see section 7.0).
与其他类型的VPN相比，VPRN的区别特征是在网络层执行分组转发。VPRN包括ISP路由器之间的IP隧道网，以及将每个VPRN节点接收到的流量转发到适当的目标站点所需的路由功能。连接到ISP路由器的是通过一个或多个链路（称为“存根”链路）连接的CPE路由器。VPRN成员连接到的每个ISP路由器上都有一个特定于VPRN的转发表。使用包含网络层可达性信息的转发表在ISP路由器之间以及ISP路由器和客户站点之间转发流量（与虚拟专用LAN段类型的VPN（VPLS）相反，其中转发表包含MAC层可达性信息-参见第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，其中显示了3个ISP边缘路由器，通过IP隧道的全网连接，用于互连4个CPE路由器。其中一个CPE路由器连接到ISP网络。在多址情况下，所有存根链路都可能处于活动状态，或者如图所示，可能有一个主链路和一个或多个备份链路在主链路出现故障时使用。术语“后门”链接用于指两个客户站点之间的链接
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 tunnel | ISP | +---+
|CPE|-------| edge |<--------------------->| edge |-------|CPE|
+---+ stub | router | 10.9.9.4/30 | router | stub +---+
link +--------+ +--------+ link :
| ^ | | ^ :
| | | --------------- | | :
| | +----( )----+ | :
| | ( IP BACKBONE ) | :
| | ( ) | :
| | --------------- | :
| | | | :
| |IP tunnel +--------+ IP tunnel| :
| | | ISP | | :
| +---------->| edge |<----------+ :
| 10.9.9.8/30 | router | 10.9.9.12/30 :
backup| +--------+ backdoor:
link | | | link :
| stub link | | stub link :
| | | :
| +---+ +---+ :
+-------------|CPE| |CPE|.......................:
10.3.3.0/30 +---+ +---+ 10.4.4.0/30
Figure 5.1: VPRN Example
图5.1:VPRN示例
The principal benefit of a VPRN is that the complexity and the configuration of the CPE routers is minimized. To a CPE router, the ISP edge router appears as a neighbor router in the customer's network, to which it sends all traffic, using a default route. The tunnel mesh that is set up to transfer traffic extends between the ISP edge routers, not the CPE routers. In effect the burden of tunnel establishment and maintenance and routing configuration is outsourced to the ISP. In addition other services needed for the operation of a VPN such as the provision of a firewall and QoS processing can be handled by a small number of ISP edge routers, rather than a large number of potentially heterogeneous CPE devices. The introduction and management of new services can also be more easily handled, as this can be achieved without the need to upgrade any CPE equipment. This latter benefit is particularly important when there may be large numbers of residential subscribers using VPN services to access private corporate networks. In this respect the model is somewhat akin to that used for telephony services, whereby new services (e.g., call waiting) can be introduced with no change in subscriber equipment.
VPRN的主要优点是最小化了CPE路由器的复杂性和配置。对于CPE路由器，ISP边缘路由器显示为客户网络中的邻居路由器，使用默认路由向其发送所有流量。用于传输流量的隧道网格在ISP边缘路由器之间延伸，而不是在CPE路由器之间延伸。实际上，隧道建设、维护和路由配置的负担都外包给了ISP。此外，VPN运行所需的其他服务（如提供防火墙和QoS处理）可由少量ISP边缘路由器处理，而不是由大量潜在异构CPE设备处理。新服务的引入和管理也更容易处理，因为这可以在不需要升级任何CPE设备的情况下实现。当可能有大量住宅用户使用VPN服务访问私有公司网络时，后一种好处尤为重要。在这方面，该模型在某种程度上类似于用于电话服务的模型，因此可以在不改变用户设备的情况下引入新的服务（例如呼叫等待）。
The VPRN type of VPN is in contrast to one where the tunnel mesh extends to the CPE routers, and where the ISP network provides layer 2 connectivity alone. The latter case can be implemented either as a set of VLLs between CPE routers (see section 4.0), in which case the ISP network provides a set of layer 2 point-to-point links, or as a VPLS (see section 7.0), in which case the ISP network is used to emulate a multiaccess LAN segment. With these scenarios a customer may have more flexibility (e.g., any IGP or any protocol can be run across all customer sites) but this usually comes at the expense of a more complex configuration for the customer. Thus, depending on customer requirements, a VPRN or a VPLS may be the more appropriate solution.
VPRN类型的VPN与隧道网延伸到CPE路由器的VPN不同，而ISP网络仅提供第2层连接。后一种情况可以实现为CPE路由器之间的一组VLL（参见第4.0节），在这种情况下，ISP网络提供一组第2层点到点链路，或者实现为VPL（参见第7.0节），在这种情况下，ISP网络用于模拟多址LAN段。在这些情况下，客户可能具有更大的灵活性（例如，任何IGP或任何协议都可以在所有客户站点上运行），但这通常是以牺牲客户更复杂的配置为代价的。因此，根据客户需求，VPRN或VPLS可能是更合适的解决方案。
Because a VPRN carries out forwarding at the network layer, a single VPRN only directly supports a single network layer protocol. For multiprotocol support, a separate VPRN for each network layer protocol could be used, or one protocol could be tunneled over another (e.g., non-IP protocols tunneled over an IP VPRN) or alternatively the ISP network could be used to provide layer 2 connectivity only, such as with a VPLS as mentioned above.
由于VPRN在网络层执行转发，因此单个VPRN仅直接支持单个网络层协议。对于多协议支持，可以为每个网络层协议使用一个单独的VPRN，或者一个协议可以在另一个协议上隧道传输（例如，通过IP VPRN隧道传输的非IP协议），或者ISP网络可以仅用于提供第2层连接，例如使用如上所述的VPLS。
The issues to be addressed for VPRNs include initial configuration, determination by an ISP edge router of the set of links that are in each VPRN, the set of other routers that have members in the VPRN, and the set of IP address prefixes reachable via each stub link, determination by a CPE router of the set of IP address prefixes to be forwarded to an ISP edge router, the mechanism used to disseminate stub reachability information to the correct set of ISP routers, and the establishment and use of the tunnels used to carry the data traffic. Note also that, although discussed first for VPRNs, many of these issues also apply to the VPLS scenario described later, with the network layer addresses being replaced by link layer addresses.
要为VPRN解决的问题包括初始配置、由ISP边缘路由器确定每个VPRN中的链路集、在VPRN中具有成员的其他路由器集以及可通过每个存根链路访问的IP地址前缀集，由CPE路由器确定要转发到ISP边缘路由器的IP地址前缀集、用于将存根可达性信息传播到正确的ISP路由器集的机制，以及用于承载数据流量的隧道的建立和使用。还请注意，尽管首先讨论了VPRN，但其中许多问题也适用于后面描述的VPLS场景，其中网络层地址被链路层地址替换。
Note that VPRN operation is decoupled from the mechanisms used by the customer sites to access the Internet. A typical scenario would be for the ISP edge router to be used to provide both VPRN and Internet connectivity to a customer site. In this case the CPE router just has a default route pointing to the ISP edge router, with the latter being responsible for steering private traffic to the VPRN and other traffic to the Internet, and providing firewall functionality between the two domains. Alternatively a customer site could have Internet connectivity via an ISP router not involved in the VPRN, or even via a different ISP. In this case the CPE device is responsible for splitting the traffic into the two domains and providing firewall functionality.
请注意，VPRN操作与客户站点访问Internet所使用的机制是分离的。典型的情况是，ISP边缘路由器用于向客户站点提供VPRN和Internet连接。在这种情况下，CPE路由器只有一个指向ISP边缘路由器的默认路由，后者负责将私人流量引导到VPRN，并将其他流量引导到Internet，并提供两个域之间的防火墙功能。或者，客户站点可以通过VPRN中未涉及的ISP路由器进行Internet连接，甚至可以通过其他ISP进行连接。在这种情况下，CPE设备负责将流量分成两个域并提供防火墙功能。
The topology of a VPRN may consist of a full mesh of tunnels between each VPRN node, or may be an arbitrary topology, such as a set of remote offices connected to the nearest regional site, with these regional sites connected together via a full or partial mesh. With VPRNs using IP tunnels there is much less cost assumed with full meshing than in cases where physical resources (e.g., a leased line) must be allocated for each connected pair of sites, or where the tunneling method requires resources to be allocated in the devices used to interconnect the edge routers (e.g., Frame Relay DLCIs). A full mesh topology yields optimal routing, since it precludes the need for traffic between two sites to traverse a third. Another attraction of a full mesh is that there is no need to configure topology information for the VPRN. Instead, given the member routers of a VPRN, the topology is implicit. If the number of ISP edge routers in a VPRN is very large, however, a full mesh topology may not be appropriate, due to the scaling issues involved, for example, the growth in the number of tunnels needed between sites, (which for n sites is n(n-1)/2), or the number of routing peers per router. Network policy may also lead to non full mesh topologies, for example an administrator may wish to set up the topology so that traffic between two remote sites passes through a central site, rather than go directly between the remote sites. It is also necessary to deal with the scenario where there is only partial connectivity across the IP backbone under certain error conditions (e.g. A can reach B, and B can reach C, but A cannot reach C directly), which can occur if policy routing is being used.
VPRN的拓扑可以由每个VPRN节点之间的隧道的完整网格组成，或者可以是任意拓扑，例如连接到最近区域站点的一组远程办公室，这些区域站点通过完整或部分网格连接在一起。对于使用IP隧道的VPRN，与必须为每对连接的站点分配物理资源（例如，租用线路）的情况相比，或者隧道方法要求在用于互连边缘路由器（例如，帧中继DLCI）的设备中分配资源的情况相比，全网格化假设的成本要低得多。全网状拓扑产生最佳路由，因为它排除了两个站点之间的通信需要穿越第三个站点。完整网格的另一个优点是不需要为VPRN配置拓扑信息。相反，给定VPRN的成员路由器，拓扑是隐式的。但是，如果VPRN中ISP边缘路由器的数量非常大，则全网状拓扑可能不合适，因为涉及到扩展问题，例如，站点之间所需隧道数量的增长（对于n个站点，为n（n-1）/2）或每个路由器的路由对等方数量。网络策略还可能导致非全网状拓扑，例如，管理员可能希望设置拓扑，以便两个远程站点之间的通信通过中心站点，而不是直接在远程站点之间进行。还需要处理在某些错误条件下（例如，A可以到达B，B可以到达C，但A不能直接到达C）仅通过IP主干进行部分连接的情况，如果使用策略路由，则可能发生这种情况。
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路由器通过一个或多个点对点存根链路（例如租用线路、ATM或帧中继连接）连接到ISP边缘路由器。ISP路由器负责在它们之间学习和传播可达性信息。CPE路由器必须学习通过每个存根链路可到达的目的地集，尽管这可能与默认路由一样简单。
The stub links may either be dedicated links, set up via provisioning, or may be dynamic links set up on demand, for example using PPP, voluntary tunneling (see section 6.3), or ATM signalling. With dynamic links it is necessary to authenticate the subscriber, and determine the authorized resources that the subscriber can access (e.g. which VPRNs the subscriber may join). Other than the way the subscriber is initially bound to the VPRN, (and this process may involve extra considerations such as dynamic IP address assignment), the subsequent VPRN mechanisms and services can be used for both types of subscribers in the same way.
存根链路可以是通过供应设置的专用链路，也可以是按需设置的动态链路，例如使用PPP、自愿隧道（见第6.3节）或ATM信令。对于动态链路，有必要对订阅者进行身份验证，并确定订阅者可以访问的授权资源（例如订阅者可以加入的VPRN）。除了订阅者最初绑定到VPRN的方式（该过程可能涉及额外的考虑，例如动态IP地址分配），后续的VPRN机制和服务可以以相同的方式用于这两种类型的订阅者。
The addressing used within a VPRN may have no relation to the addressing used on the IP backbone over which the VPRN is instantiated. In particular non-unique private IP addressing may be used [4]. Multiple VPRNs may be instantiated over the same set of physical devices, and they may use the same or overlapping address spaces.
VPRN中使用的寻址可能与VPRN在其上实例化的IP主干上使用的寻址无关。特别地，可以使用非唯一的专用IP地址[4]。可以在同一组物理设备上实例化多个VPRN，并且它们可以使用相同或重叠的地址空间。
For a VPRN the tunnel mesh forms an overlay network operating over an IP backbone. Within each of the ISP edge routers there must be VPN specific forwarding state to forward packets received from stub links ('ingress traffic') to the appropriate next hop router, and to forward packets received from the core ('egress traffic') to the appropriate stub link. For cases where an ISP edge router supports multiple stub links belonging to the same VPRN, the tunnels can, as a local matter, either terminate on the edge router, or on a stub link. In the former case a VPN specific forwarding table is needed for egress traffic, in the latter case it is not. A VPN specific forwarding table is generally needed in the ingress direction, in order to direct traffic received on a stub link onto the correct IP tunnel towards the core.
对于VPRN，隧道网形成在IP主干上运行的覆盖网络。在每个ISP边缘路由器内，必须具有VPN特定的转发状态，以将从存根链路（“入口流量”）接收的数据包转发到适当的下一跳路由器，并将从核心（“出口流量”）接收的数据包转发到适当的存根链路。对于ISP边缘路由器支持属于同一VPRN的多个存根链路的情况，作为本地事项，隧道可以在边缘路由器上或存根链路上终止。在前一种情况下，出口流量需要VPN特定的转发表，而在后一种情况下则不需要。在入口方向上通常需要一个特定于VPN的转发表，以便将存根链路上接收到的流量引导到正确的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数据包的生存时间（TTL）字段将以正常方式递减，从而防止数据包在VPRN内发生路由循环时无限循环。
Note also that a single customer site may belong concurrently to multiple VPRNs and may want to transmit traffic both onto one or more VPRNs and to the default Internet, over the same stub link. There are a number of possible approaches to this problem, but these are outside the scope of this document.
还请注意，单个客户站点可能同时属于多个VPRN，并且可能希望通过同一存根链路将流量传输到一个或多个VPRN和默认Internet。对于这个问题有许多可能的方法，但这些方法不在本文档的范围之内。
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要求和机制已在许多不同的文件中讨论过。第一个是[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成员资格和可达性功能的机制，有两种主要变体—覆盖和搭载。这些将在第节中进行更详细的讨论
5.3.2, 5.3.3 and 5.3.4 below. An example of the overlay model is described in [14], which discusses the provision of VPRN functionality by means of a separate per-VPN routing protocol instance and route and forwarding table instantiation, otherwise known as virtual routing. Each VPN routing instance is isolated from any other VPN routing instance, and from the routing used across the backbone. As a result any routing protocol (e.g. OSPF, RIP2, IS-IS) can be run with any VPRN, independently of the routing protocols used in other VPRNs, or in the backbone itself. The VPN model described in [12] is also an overlay VPRN model using virtual routing. That document is specifically geared towards the provision of VPRN functionality over MPLS backbones, and it describes how VPRN membership dissemination can be automated over an MPLS backbone, by performing VPN neighbor discovery over the base MPLS tunnel mesh. [31] extends the virtual routing model to include VPN areas, and VPN border routers which route between VPN areas. VPN areas may be defined for administrative or technical reasons, such as different underlying network infrastructures (e.g. ATM, MPLS, IP).
5.3.2、5.3.3和5.3.4。[14]中描述了覆盖模型的一个示例，其中讨论了通过单独的每VPN路由协议实例和路由和转发表实例（也称为虚拟路由）提供VPRN功能。每个VPN路由实例都与任何其他VPN路由实例以及跨主干使用的路由隔离。因此，任何路由协议（如OSPF、RIP2、IS-IS）都可以与任何VPRN一起运行，独立于其他VPRN中使用的路由协议或主干网本身。[12]中描述的VPN模型也是使用虚拟路由的覆盖VPRN模型。该文档专门针对在MPLS主干上提供VPRN功能，并描述了如何通过在基本MPLS隧道网格上执行VPN邻居发现，在MPLS主干上自动分发VPRN成员资格。[31]扩展了虚拟路由模型，包括VPN区域，以及在VPN区域之间路由的VPN边界路由器。VPN区域的定义可能出于管理或技术原因，例如不同的底层网络基础设施（如ATM、MPLS、IP）。
In contrast [15] describes the provision of VPN functionality using a piggybacking approach for membership and reachability dissemination, with this information being piggybacked in Border Gateway Protocol 4 (BGP) [32] packets. VPNs are constructed using BGP policies, which are used to control which sites can communicate with each other. [13] also uses BGP for piggybacking membership information, and piggybacks reachability information on the protocol used to establish MPLS LSPs (CR-LDP or extended RSVP). Unlike the other proposals, however, this proposal requires the participation on the CPE router to implement the VPN functionality.
与此相反，[15]描述了使用成员资格和可达性传播的背驮方法提供VPN功能，该信息背驮在边界网关协议4（BGP）[32]数据包中。VPN使用BGP策略构建，BGP策略用于控制哪些站点可以相互通信。[13] 还使用BGP来承载成员信息，并在用于建立MPLS LSP（CR-LDP或扩展RSVP）的协议上承载可达性信息。然而，与其他提案不同，该提案要求CPE路由器参与实施VPN功能。
There are a number of common requirements which any network-based VPRN solution must address, and there are a number of different mechanisms that can be used to meet these requirements. These generic issues are
任何基于网络的VPRN解决方案都必须满足许多共同需求，并且可以使用许多不同的机制来满足这些需求。这些一般性问题是：
1) The use of a globally unique VPN identifier in order to be able to refer to a particular VPN.
1) 使用全局唯一的VPN标识符，以便能够引用特定的VPN。
2) VPRN membership determination. An edge router must learn of the local stub links that are in each VPRN, and must learn of the set of other routers that have members in that VPRN.
2) VPRN成员确定。边缘路由器必须了解每个VPRN中的本地存根链路，并且必须了解在该VPRN中具有成员的其他路由器集。
3) Stub link reachability information. An edge router must learn the set of addresses and address prefixes reachable via each stub link.
3) 存根链接可达性信息。边缘路由器必须学习可通过每个存根链路访问的地址集和地址前缀。
4) Intra-VPRN reachability information. Once an edge router has determined the set of address prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN.
4) VPRN内部可达性信息。一旦边缘路由器确定了与其每个存根链路相关联的地址前缀集，则必须将此信息分发给VPRN中的其他边缘路由器。
5) Tunneling mechanism. An edge router must construct the necessary tunnels to other routers that have members in the VPRN, and must perform the encapsulation and decapsulation necessary to send and receive packets over the tunnels.
5) 隧道机制。边缘路由器必须构造到VPRN中具有成员的其他路由器的必要隧道，并且必须执行通过隧道发送和接收数据包所需的封装和去封装。
The IETF [16] and the ATM Forum [17] have standardized on a single format for a globally unique identifier used to identify a VPN - a VPN-ID. Only the format of the VPN-ID has been defined, not its semantics or usage. The aim is to allow its use for a wide variety of purposes, and to allow the same identifier to used with different technologies and mechanisms. For example a VPN-ID can be included in a MIB to identify a VPN for management purposes. A VPN-ID can be used in a control plane protocol, for example to bind a tunnel to a VPN at tunnel establishment time. All packets that traverse the tunnel are then implicitly associated with the identified VPN. A VPN-ID can be used in a data plane encapsulation, to allow for an explicit per-packet identification of the VPN associated with the packet. If a VPN is implemented using different technologies (e.g., IP and ATM) in a network, the same identifier can be used to identify the VPN across the different technologies. Also if a VPN spans multiple administrative domains the same identifier can be used everywhere.
IETF[16]和ATM论坛[17]已对用于标识VPN的全球唯一标识符的单一格式进行了标准化，即VPN-ID。仅定义了VPN-ID的格式，未定义其语义或用法。其目的是允许其用于多种用途，并允许同一标识符用于不同的技术和机制。例如，可以在MIB中包含一个VPN-ID，以识别用于管理目的的VPN。VPN-ID可用于控制平面协议中，例如在隧道建立时将隧道绑定到VPN。然后，通过隧道的所有数据包都隐式地与标识的VPN关联。VPN-ID可用于数据平面封装，以允许与分组相关联的VPN的显式每分组标识。如果VPN在网络中使用不同的技术（例如，IP和ATM）实现，则可以使用相同的标识符跨不同的技术识别VPN。此外，如果VPN跨越多个管理域，则可以在任何地方使用相同的标识符。
Most of the VPN schemes developed (e.g. [11], [12], [13], [14]) require the use of a VPN-ID that is carried in control and/or data packets, which is used to associate the packet with a particular VPN. Although the use of a VPN-ID in this manner is very common, it is not universal. [15] describes a scheme where there is no protocol field used to identify a VPN in this manner. In this scheme the VPNs as understood by a user, are administrative constructs, built using BGP policies. There are a number of attributes associated with VPN routes, such as a route distinguisher, and origin and target "VPN", that are used by the underlying protocol mechanisms for disambiguation and scoping, and these are also used by the BGP policy mechanism in the construction of VPNs, but there is nothing corresponding with the VPN-ID as used in the other documents.
大多数开发的VPN方案（例如[11]、[12]、[13]、[14]）要求使用控制和/或数据包中携带的VPN-ID，用于将数据包与特定VPN关联。尽管以这种方式使用VPN-ID非常常见，但它并不通用。[15] 描述一种方案，其中没有用于以这种方式标识VPN的协议字段。在该方案中，用户理解的VPN是使用BGP策略构建的管理结构。有许多与VPN路由相关的属性，如路由识别器、源和目标“VPN”，这些属性由底层协议机制用于消歧和范围界定，BGP策略机制也使用这些属性来构建VPN，但是没有与其他文档中使用的VPN-ID对应的内容。
Note also that [33] defines a multiprotocol encapsulation for use over ATM AAL5 that uses the standard VPN-ID format.
还要注意的是[33]定义了一个多协议封装，用于使用标准VPN-ID格式的ATM AAL5。
In order to establish a VPRN, or to insert new customer sites into an established VPRN, an ISP edge router must determine which stub links are associated with which VPRN. For static links (e.g. an ATM VCC) this information must be configured into the edge router, since the edge router cannot infer such bindings by itself. An SNMP MIB allowing for bindings between local stub links and VPN identities is one solution.
为了建立VPRN或将新的客户站点插入已建立的VPRN，ISP边缘路由器必须确定哪些存根链路与哪个VPRN关联。对于静态链路（例如ATM VCC），必须将此信息配置到边缘路由器中，因为边缘路由器本身无法推断此类绑定。SNMP MIB允许在本地存根链接和VPN标识之间进行绑定，这是一种解决方案。
For subscribers that attach to the network dynamically (e.g. using PPP or voluntary tunneling) it is possible to make the association between stub link and VPRN as part of the end user authentication processing that must occur with such dynamic links. For example the VPRN to which a user is to be bound may be derived from the domain name the used as part of PPP authentication. If the user is successfully authenticated (e.g. using a Radius server), then the newly created dynamic link can be bound to the correct VPRN. Note that static configuration information is still needed, for example to maintain the list of authorized subscribers for each VPRN, but the location of this static information could be an external authentication server rather than on an ISP edge router. Whether the link was statically or dynamically created, a VPN-ID can be associated with that link to signify to which VPRN it is bound.
对于动态连接到网络的订户（例如，使用PPP或自愿隧道），可以将存根链路和VPRN之间的关联作为最终用户身份验证处理的一部分，这必须与此类动态链路一起进行。例如，用户要绑定到的VPRN可以从用作PPP身份验证一部分的域名派生。如果用户成功通过身份验证（例如使用Radius服务器），则新创建的动态链接可以绑定到正确的VPRN。请注意，仍然需要静态配置信息，例如维护每个VPRN的授权订户列表，但此静态信息的位置可以是外部身份验证服务器，而不是ISP边缘路由器。无论链接是静态创建的还是动态创建的，VPN-ID都可以与该链接相关联，以表示它绑定到哪个VPRN。
After learning which stub links are bound to which VPRN, each edge router must learn either the identity of, or, at least, the route to, each other edge router supporting other stub links in that particular VPRN. Implicit in the latter is the notion that there exists some mechanism by which the configured edge routers can then use this edge router and/or stub link identity information to subsequently set up the appropriate tunnels between them. The problem of VPRN member dissemination between participating edge routers, can be solved in a variety of ways, discussed below.
在了解哪些存根链路绑定到哪个VPRN之后，每个边缘路由器必须了解支持该特定VPRN中的其他存根链路的每个边缘路由器的标识，或者至少了解到到彼此的路由。后者隐含的概念是，存在某种机制，通过该机制，配置的边缘路由器可以使用此边缘路由器和/或存根链路标识信息，随后在它们之间建立适当的隧道。参与边缘路由器之间的VPRN成员分发问题可以通过多种方式解决，如下所述。
The members of a particular VPRN, that is, the identity of the edge routers supporting stub links in the VPRN, and the set of static stub links bound to the VPRN per edge router, could be configured into a directory, which edge routers could query, using some defined mechanism (e.g. Lightweight Directory Access Protocol (LDAP) [34]), upon startup.
特定VPRN的成员，即支持VPRN中存根链路的边缘路由器的标识，以及每个边缘路由器绑定到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中成员路由器的完整列表分布在任何地方。对于任意拓扑，不同的路由器可能接收不同的成员列表。
Using a directory allows for authorization checking prior to disseminating VPRN membership information, which may be desirable where VPRNs span multiple administrative domains. In such a case, directory to directory protocol mechanisms could also be used to propagate authorized VPRN membership information between the directory systems of the multiple administrative domains.
使用目录允许在传播VPRN成员资格信息之前进行授权检查，这在VPRN跨越多个管理域时可能是可取的。在这种情况下，还可以使用目录到目录协议机制在多个管理域的目录系统之间传播授权的VPRN成员信息。
There also needs to be some form of database synchronization mechanism (e.g. triggered or regular polling of the directory by edge routers, or active pushing of update information to the edge routers by the directory) in order for all edge routers to learn the identity of newly configured sites inserted into an active VPRN, and also to learn of sites removed from a VPRN.
还需要某种形式的数据库同步机制（例如，边缘路由器触发或定期轮询目录，或通过目录向边缘路由器主动推送更新信息），以便所有边缘路由器了解插入活动VPRN的新配置站点的身份，以及了解从VPRN中删除的站点。
A VPRN MIB could be defined which would allow a central management system to configure each edge router with the identities of each other participating edge router and the identity of each of the static stub links bound to the VPRN. Like the use of a directory, this mechanism allows both full mesh and arbitrary topologies to be configured. Another mechanism using a centralized management system is to use a policy server and use the Common Open Policy Service (COPS) protocol [35] to distribute VPRN membership and policy information, such as the tunnel attributes to use when establishing a tunnel, as described in [36].
可以定义VPRN MIB，该MIB允许中央管理系统使用每个参与边缘路由器的身份以及绑定到VPRN的每个静态存根链路的身份配置每个边缘路由器。与使用目录一样，此机制允许配置全网格和任意拓扑。使用集中管理系统的另一种机制是使用策略服务器并使用公共开放策略服务（COPS）协议[35]来分发VPRN成员资格和策略信息，如[36]中所述，在建立隧道时使用的隧道属性。
Note that this mechanism allows the management station to impose strict authorization control; on the other hand, it may be more difficult to configure edge routers outside the scope of the management system. The management configuration model can also be considered a subset of the directory method, in that the management directories could use MIBs to push VPRN membership information to the participating edge routers, either subsequent to, or as part of, the local stub link configuration process.
注意，该机制允许管理站实施严格的授权控制；另一方面，在管理系统范围之外配置边缘路由器可能更困难。管理配置模型也可以被视为目录方法的子集，因为管理目录可以在本地存根链路配置过程之后或作为本地存根链路配置过程的一部分，使用mib将VPRN成员资格信息推送到参与的边缘路由器。
VPRN membership information could be piggybacked into the routing protocols run by each edge router across the IP backbone, since this is an efficient means of automatically propagating information throughout the network to other participating edge routers. Specifically, each route advertisement by each edge router could include, at a minimum, the set of VPN identifiers associated with each edge router, and adequate information to allow other edge routers to determine the identity of, and/or, the route to, the particular edge router. Other edge routers would examine received route advertisements to determine if any contained information was
VPRN成员资格信息可以通过IP骨干网由每个边缘路由器运行的路由协议进行承载，因为这是一种通过网络自动将信息传播到其他参与边缘路由器的有效方法。具体地，每个边缘路由器的每个路由公告可以至少包括与每个边缘路由器相关联的VPN标识符集，以及允许其他边缘路由器确定特定边缘路由器的身份和/或到特定边缘路由器的路由的足够信息。其他边缘路由器将检查接收到的路由广告，以确定是否存在任何包含的信息
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的边缘路由器集、到VPRN的静态存根链接的绑定、，或通过dynamics链接访问网络的用户的身份验证和授权信息。该信息需要配置并存储在某种形式的数据库中，以便为便利将此类信息配置到边缘路由器和/或便利边缘路由器访问此类信息而需要的附加步骤可能不会过于繁重。
There are two aspects to stub site reachability - the means by which VPRN edge routers determine the set of VPRN addresses and address prefixes reachable at each stub site, and the means by which the CPE routers learn the destinations reachable via each stub link. A number of common scenarios are outlined below. In each case the information needed by the ISP edge router is the same - the set of VPRN addresses reachable at the customer site, but the information needed by the CPE router differs.
存根站点可访问性有两个方面-VPRN边缘路由器确定在每个存根站点可访问的VPRN地址和地址前缀集的方法，以及CPE路由器通过每个存根链路学习可访问目的地的方法。下面概述了一些常见场景。在每种情况下，ISP边缘路由器所需的信息都是相同的——在客户站点上可访问的VPRN地址集，但CPE路由器所需的信息不同。
The CPE router is connected via one link to an ISP edge router, which provides both VPRN and Internet connectivity.
CPE路由器通过一条链路连接到ISP边缘路由器，该路由器提供VPRN和Internet连接。
This is the simplest case for the CPE router, as it just needs a default route pointing to the ISP edge router.
这是CPE路由器最简单的情况，因为它只需要指向ISP边缘路由器的默认路由。
The CPE router is connected via one link to an ISP edge router, which provides VPRN, but not Internet, connectivity.
CPE路由器通过一条链路连接到ISP边缘路由器，该路由器提供VPRN连接，但不提供互联网连接。
The CPE router must know the set of non-local VPRN destinations reachable via that link. This may be a single prefix, or may be a number of disjoint prefixes. The CPE router may be either statically configured with this information, or may learn it dynamically by running an instance of an Interior Gateway Protocol (IGP). For simplicity it is assumed that the IGP used for this purpose is RIP, though it could be any IGP. The ISP edge router will inject into this instance of RIP the VRPN routes which it learns by means of one of the intra-VPRN reachability mechanisms described in section 5.3.4. Note that the instance of RIP run to the CPE, and any instance of a routing protocol used to learn intra-VPRN reachability (even if also RIP) are separate, with the ISP edge router redistributing the routes from one instance to another.
CPE路由器必须知道可通过该链路到达的非本地VPRN目的地集。这可以是单个前缀，也可以是多个不相交的前缀。CPE路由器可以静态地配置该信息，或者可以通过运行内部网关协议（IGP）的实例来动态地学习该信息。为简单起见，假设用于此目的的IGP为RIP，尽管它可以是任何IGP。ISP边缘路由器将通过第5.3.4节所述的VPRN内部可达性机制之一，将VRPN路由注入RIP实例中。请注意，RIP实例运行到CPE，用于学习VPRN内部可达性（即使也是RIP）的任何路由协议实例都是独立的，ISP边缘路由器将路由从一个实例重新分配到另一个实例。
The CPE router is multihomed to the ISP network, which provides VPRN connectivity.
CPE路由器与ISP网络连接，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边缘路由器都可以向CPE路由器通告相同的VPRN路由，然后CPE路由器会看到所有VPRN前缀都可以通过所有链路平等地到达。还可以进行更具体的路由重新分配，由此每个ISP边缘路由器向CPE路由器播发不同的前缀集。
The CPE router is connected to the ISP network, which provides VPRN connectivity, but also has a backdoor link to another customer site
CPE路由器连接到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边缘路由器将像情况2一样向CPE设备公布VPRN路由。但是，现在可以通过ISP边缘路由器和后门链路访问相同的目的地。如果连接到后门链路的CPE路由器正在运行客户的IGP，则后门链路可能始终是首选链路，因为它将显示为“内部”路径，而通过ISP边缘路由器注入的目的地将显示为“外部”路径（到客户的IGP）。为避免此问题，假设客户希望流量通过ISP网络，则应在后门链路两端的CPE路由器之间运行单独的RIP实例，方式与在CPE路由器和ISP边缘路由器之间的存根或备份链路上运行RIP实例相同。这也将使后门链接显示为一条外部路径，通过适当调整链接成本，ISP路径始终会受到青睐，除非它在使用后门链接时下降。
The description of the above scenarios covers what reachability information is needed by the ISP edge routers and the CPE routers, and discusses some of the mechanisms used to convey this information. The sections below look at these mechanisms in more detail.
上述场景的描述涵盖了ISP边缘路由器和CPE路由器所需的可达性信息，并讨论了用于传递该信息的一些机制。以下各节将更详细地介绍这些机制。
A routing protocol can be run between the CPE edge router and the ISP edge router to exchange reachability information. This allows an ISP edge router to learn the VPRN prefixes reachable at a customer site, and also allows a CPE router to learn the destinations reachable via the provider network.
可以在CPE边缘路由器和ISP边缘路由器之间运行路由协议，以交换可达性信息。这允许ISP边缘路由器了解可在客户站点访问的VPRN前缀，还允许CPE路由器了解可通过提供商网络访问的目的地。
The extent of the routing domain for this protocol instance is generally just the ISP edge router and the CPE router although if the customer site is also running the same protocol as its IGP, then the domain may extend into customer site. If the customer site is running a different routing protocol then the CPE router redistributes the routes between the instance running to the ISP edge router, and the instance running into the customer site.
此协议实例的路由域范围通常仅限于ISP边缘路由器和CPE路由器，尽管如果客户站点也运行与其IGP相同的协议，则该域可能扩展到客户站点。如果客户站点正在运行不同的路由协议，则CPE路由器将在运行到ISP边缘路由器的实例和运行到客户站点的实例之间重新分配路由。
Given the typically restricted scope of this routing instance, a simple protocol will generally suffice. RIP is likely to be the most common protocol used, though any routing protocol, such as OSPF, or BGP run in internal mode (IBGP), could also be used.
鉴于此路由实例的范围通常受到限制，一个简单的协议通常就足够了。RIP可能是最常用的协议，但也可以使用任何路由协议，如OSPF或内部模式下运行的BGP（IBGP）。
Note that the instance of the stub link routing protocol is different from any instance of a routing protocol used for intra-VPRN reachability. For example, if the ISP edge router uses routing protocol piggybacking to disseminate VPRN membership and reachability information across the core, then it may redistribute suitably labeled routes from the CPE routing instance to the core routing instance. The routing protocols used for each instance are decoupled, and any suitable protocol can be used in each case. There is no requirement that the same protocol, or even the same stub link reachability information gathering mechanism, be run between each CPE router and associated ISP edge router in a particular VPRN, since this is a purely local matter.
请注意，存根链路路由协议的实例不同于用于VPRN内部可达性的路由协议的任何实例。例如，如果ISP边缘路由器使用路由协议背驮来跨核心传播VPRN成员资格和可达性信息，那么它可以将适当标记的路由从CPE路由实例重新分发到核心路由实例。用于每个实例的路由协议是解耦的，并且在每种情况下都可以使用任何合适的协议。不要求在特定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部署通用（跨所有VPRN）VPRN内可达性机制和通用存根链路可达性机制，这些机制彼此隔离，并且与客户网络中使用的特定IGP隔离。在第一种情况下，由于在ISP边缘路由器上实现了IGP-IGP边界，ISP可以将VPRN内可达性机制与行为不端的存根链路协议实例隔离。在第二种情况下，ISP不需要知道客户站点中运行的特定IGP。其他情况也是可能的，其中ISP边缘路由器在与客户的IGP相同的实例中运行路由协议，但不太可能是实际的，因为它不符合VPRN简化CPE路由器配置的目的。在客户希望跨多个站点运行IGP的情况下，VPLS解决方案更合适。
Note that if a particular customer site concurrently belongs to multiple VPRNs (or wishes to concurrently communicate with both a VPRN and the Internet), then the ISP edge router must have some means of unambiguously mapping stub link address prefixes to particular VPRNs. A simple way is to have multiple stub links, one per VPRN. It is also possible to run multiple VPRNs over one stub link. This could be done either by ensuring (and appropriately configuring the
请注意，如果某个特定客户站点同时属于多个VPRN（或希望同时与VPRN和Internet通信），则ISP边缘路由器必须具有某种将存根链路地址前缀明确映射到特定VPRN的方法。一种简单的方法是拥有多个存根链接，每个VPRN一个。还可以在一个存根链路上运行多个VPRN。这可以通过确保（并适当地配置
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边缘路由器（需要知道）特定的不相交地址前缀映射到单独的VPRN，或者通过使用适当的VPN标识符标记来自CPE路由器的路由公告。例如，如果使用MPLS传输存根链路可达性信息，则将使用不同的MPLS标签来区分分配给特定VPRN的不相交前缀。无论如何，这种协调都需要一些行政程序。
The reachability information across each stub link could be manually configured, which may be appropriate if the set of addresses or prefixes is small and static.
可以手动配置每个存根链路上的可达性信息，如果地址或前缀集很小且是静态的，这可能是合适的。
The set of addresses used by each stub site could be administered and allocated via the VPRN edge router, which may be appropriate for small customer sites, typically containing either a single host, or a single subnet. Address allocation can be carried out using protocols such as PPP or DHCP [37], with, for example, the edge router acting as a Radius client and retrieving the customer's IP address to use from a Radius server, or acting as a DHCP relay and examining the DHCP reply message as it is relayed to the customer site. In this manner the edge router can build up a table of stub link reachability information. Although these address assignment mechanisms are typically used to assign an address to a single host, some vendors have added extensions whereby an address prefix can be assigned, with, in some cases, the CPE device acting as a "mini-DHCP" server and assigning addresses for the hosts in the customer site.
每个存根站点使用的地址集可以通过VPRN边缘路由器进行管理和分配，这可能适用于小型客户站点，通常包含单个主机或单个子网。地址分配可以使用诸如PPP或DHCP[37]等协议来执行，例如，边缘路由器充当Radius客户端并从Radius服务器检索要使用的客户IP地址，或者充当DHCP中继并在将DHCP应答消息中继到客户站点时检查DHCP应答消息。通过这种方式，边缘路由器可以建立存根链路可达性信息表。尽管这些地址分配机制通常用于将地址分配给单个主机，但一些供应商添加了扩展，从而可以分配地址前缀，在某些情况下，CPE设备充当“迷你DHCP”服务器，并为客户站点中的主机分配地址。
Note that with these schemes it is the responsibility of the address allocation server to ensure that each site in the VPN received a disjoint address space. Note also that an ISP would typically only use this mechanism for small stub sites, which are unlikely to have backdoor links.
请注意，对于这些方案，地址分配服务器负责确保VPN中的每个站点都接收到不相交的地址空间。还请注意，ISP通常只对小型存根站点使用此机制，这些站点不太可能有后门链接。
In cases where the CPE router runs MPLS, LDP can be used to convey the set of prefixes at a stub site to a VPRN edge router. Using the downstream unsolicited mode of label distribution the CPE router can distribute a label for each route in the stub site. Note however that the processing carried out by the edge router in this case is more than just the normal LDP processing, since it is learning new routes via LDP, rather than the usual case of learning labels for existing routes that it has learned via standard routing mechanisms.
在CPE路由器运行MPLS的情况下，LDP可用于将存根站点处的前缀集传送到VPRN边缘路由器。使用下游未经请求的标签分发模式，CPE路由器可以为存根站点中的每个路由分发标签。然而，请注意，在这种情况下，边缘路由器执行的处理不仅仅是正常的LDP处理，因为它是通过LDP学习新路由，而不是通过标准路由机制学习现有路由的标签的通常情况。
Once an edge router has determined the set of prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN. Note also that there is an implicit requirement that the set of reachable addresses within the VPRN be locally unique that is, each VPRN stub link (not performing load sharing) maintain an address space disjoint from any other, so as to permit unambiguous routing. In practical terms, it is also generally desirable, though not required, that this address space be well partitioned i.e., specific, disjoint address prefixes per edge router, so as to preclude the need to maintain and disseminate large numbers of host routes.
一旦边缘路由器确定了与其每个存根链路相关联的前缀集，则必须将此信息分发给VPRN中的其他边缘路由器。还请注意，存在一个隐含的要求，即VPRN内的可到达地址集在本地是唯一的，即每个VPRN存根链路（不执行负载共享）保持一个与任何其他地址不相交的地址空间，以便允许明确的路由。实际上，通常还希望（尽管不是必需的）对该地址空间进行良好分区，即每个边缘路由器的特定、不相交的地址前缀，以便排除维护和传播大量主机路由的需要。
The problem of intra-VPN reachability information dissemination can be solved in a number of ways, some of which include the following:
VPN内部可达性信息传播的问题可以通过多种方式解决，其中一些方式包括：
Along with VPRN membership information, a central directory could maintain a listing of the address prefixes associated with each customer site. Such information could be obtained by the server through protocol interactions with each edge router. Note that the same directory synchronization issues discussed above in section 5.3.2 also apply in this case.
除了VPRN成员信息外，中心目录还可以维护与每个客户站点相关联的地址前缀列表。服务器可以通过与每个边缘路由器的协议交互来获取此类信息。请注意，上述第5.3.2节中讨论的相同目录同步问题也适用于这种情况。
The address spaces associated with each edge router could be explicitly configured into each other router. This is clearly a non-scalable solution, particularly when arbitrary topologies are used, and also raises the question of how the management system learns such information in the first place.
与每个边缘路由器关联的地址空间可以显式地配置到每个其他路由器中。这显然是一个不可扩展的解决方案，特别是在使用任意拓扑时，而且还提出了管理系统首先如何学习此类信息的问题。
In this approach, each edge router runs an instance of a routing protocol (a 'virtual router') per VPRN, running across the VPRN tunnels to each peer edge router, to disseminate intra-VPRN reachability information. Both full-mesh and arbitrary VPRN topologies can be easily supported, since the routing protocol itself can run over any topology. The intra-VPRN routing advertisements could be distinguished from normal tunnel data packets either by being addressed directly to the peer edge router, or by a tunnel specific mechanism.
在这种方法中，每个边缘路由器为每个VPRN运行一个路由协议实例（“虚拟路由器”），该实例跨VPRN隧道运行到每个对等边缘路由器，以传播VPRN内可达性信息。由于路由协议本身可以在任何拓扑上运行，因此可以轻松支持全网状拓扑和任意VPRN拓扑。通过直接寻址到对等边缘路由器或通过特定于隧道的机制，可以将内部VPRN路由播发与正常隧道数据分组区分开来。
Note that this intra-VPRN routing protocol need have no relationship either with the IGP of any customer site or with the routing protocols operated by the ISPs in the IP backbone. Depending on the size and scale of the VPRNs to be supported either a simple protocol like RIP or a more sophisticated protocol like OSPF could be used. Because the intra-VPRN routing protocol operates as an overlay over the IP backbone it is wholly transparent to any intermediate routers, and to any edge routers not within the VPRN. This also implies that such routing information can remain opaque to such routers, which may be a necessary security requirements in some cases. Also note that if the routing protocol runs directly over the same tunnels as the data traffic, then it will inherit the same level of security as that afforded the data traffic, for example strong encryption and authentication.
请注意，此VPRN内部路由协议不需要与任何客户站点的IGP或IP主干中由ISP操作的路由协议有任何关系。根据要支持的VPRN的大小和规模，可以使用简单的协议（如RIP）或更复杂的协议（如OSPF）。由于VPRN内部路由协议作为IP主干上的覆盖层运行，因此它对任何中间路由器以及不在VPRN内的任何边缘路由器都是完全透明的。这也意味着这样的路由信息对这样的路由器来说仍然是不透明的，这在某些情况下可能是必要的安全要求。还请注意，如果路由协议与数据通信直接在相同的隧道上运行，那么它将继承与数据通信相同的安全级别，例如强加密和身份验证。
If the tunnels over which an intra-VPRN routing protocol runs are dedicated to a specific VPN (e.g. a different multiplexing field is used for each VPN) then no changes are needed to the routing protocol itself. On the other hand if shared tunnels are used, then it is necessary to extend the routing protocol to allow a VPN-ID field to be included in routing update packets, to allow sets of prefixes to be associated with a particular VPN.
如果运行内部VPRN路由协议的隧道专用于特定VPN（例如，每个VPN使用不同的多路复用字段），则无需更改路由协议本身。另一方面，如果使用共享隧道，则有必要扩展路由协议以允许在路由更新包中包括VPN-ID字段，以允许前缀集与特定VPN相关联。
By link reachability protocol is meant a protocol that allows two nodes, connected via a point-to-point link, to exchange reachability information. Given a full mesh topology, each edge router could run a link reachability protocol, for instance some variation of MPLS CR-LDP, across the tunnel to each peer edge router in the VPRN, carrying the VPN-ID and the reachability information of each VPRN running across the tunnel between the two edge routers. If VPRN membership information has already been distributed to an edge router, then the neighbor discovery aspects of a traditional routing protocol are not needed, as the set of neighbors is already known. TCP connections can be used to interconnect the neighbors, to provide reliability. This approach may reduce the processing burden of running routing protocol instances per VPRN, and may be of particular benefit where a shared tunnel mechanism is used to connect a set of edge routers supporting multiple VPRNs.
链路可达性协议是指允许通过点到点链路连接的两个节点交换可达性信息的协议。给定一个全网状拓扑，每个边缘路由器可以跨隧道运行链路可达性协议，例如MPLS CR-LDP的一些变体，到VPRN中的每个对等边缘路由器，携带VPN-ID和跨隧道在两个边缘路由器之间运行的每个VPRN的可达性信息。如果VPRN成员资格信息已经分发到边缘路由器，则不需要传统路由协议的邻居发现方面，因为邻居集已经已知。TCP连接可用于互连邻居，以提供可靠性。这种方法可以减少每个VPRN运行路由协议实例的处理负担，并且在使用共享隧道机制连接支持多个VPRN的一组边缘路由器时可能具有特别的好处。
Another approach to developing a link reachability protocol would be to base it on IBGP. The problem that needs to be solved by a link reachability protocol is very similar to that solved by IBGP - conveying address prefixes reliably between edge routers.
开发链路可达性协议的另一种方法是基于IBGP。链路可达性协议需要解决的问题与IBGP解决的问题非常相似——在边缘路由器之间可靠地传输地址前缀。
Using a link reachability protocol it is straightforward to support a full mesh topology - each edge router conveys its own local reachability information to all other routers, but does not redistribute information received from any other router. However once an arbitrary topology needs to be supported, the link reachability protocol needs to develop into a full routing protocol, due to the need to implement mechanisms to avoid loops, and there would seem little benefit in reinventing another routing protocol to deal with this. Some reasons why partially connected meshes may be needed even in a tunneled environment are discussed in section 5.1.1.
使用链路可达性协议可以直接支持全网状拓扑-每个边缘路由器将其自身的本地可达性信息传送给所有其他路由器，但不重新分发从任何其他路由器接收的信息。然而，一旦需要支持任意拓扑，由于需要实现避免循环的机制，链路可达性协议就需要发展成完整的路由协议，而重新设计另一个路由协议来处理这一问题似乎没有什么好处。第5.1.1节讨论了即使在隧道环境中也可能需要部分连接网格的一些原因。
As with VPRN membership, the set of address prefixes associated with each stub interface could also be piggybacked into the routing advertisements from each edge router and propagated through the network. Other edge routers extract this information from received route advertisements in the same way as they obtain the VPRN membership information (which, in this case, is implicit in the identification of the source of each route advertisement). Note that this scheme may require, depending upon the nature of the routing protocols involved, that intermediate routers, e.g. border routers, cache intra-VPRN routing information in order to propagate it further. This also has implications for the trust model, and for the level of security possible for intra-VPRN routing information.
与VPRN成员身份一样，与每个存根接口相关联的地址前缀集也可以从每个边缘路由器携带到路由公告中，并通过网络传播。其他边缘路由器从接收到的路由公告中提取该信息的方式与它们获取VPRN成员信息的方式相同（在这种情况下，该信息隐含在每个路由公告的源的标识中）。注意，根据所涉及的路由协议的性质，该方案可能要求中间路由器（例如边界路由器）缓存VPRN内路由信息以进一步传播它。这也对信任模型以及VPRN内路由信息可能的安全级别有影响。
Note that in any of the cases discussed above, an edge router has the option of disseminating its stub link prefixes in a manner so as to permit tunneling from remote edge routers directly to the egress stub links. Alternatively, it could disseminate the information so as to associate all such prefixes with the edge router, rather than with specific stub links. In this case, the edge router would need to implement a VPN specific forwarding mechanism for egress traffic, to determine the correct egress stub link. The advantage of this is that it may significantly reduce the number of distinct tunnels or tunnel label information which need to be constructed and maintained. Note that this choice is purely a local manner and is not visible to remote edge routers.
注意，在上面讨论的任何情况下，边缘路由器具有以允许从远程边缘路由器直接到出口存根链路的隧道的方式传播其存根链路前缀的选项。或者，它可以传播信息，以便将所有这样的前缀与边缘路由器相关联，而不是与特定的存根链路相关联。在这种情况下，边缘路由器需要为出口流量实现特定于VPN的转发机制，以确定正确的出口存根链路。这样做的优点是，它可以显著减少需要构建和维护的不同隧道或隧道标签信息的数量。请注意，此选择纯粹是本地方式，对远程边缘路由器不可见。
Once VPRN membership information has been disseminated, the tunnels comprising the VPRN core can be constructed.
一旦分发了VPRN成员信息，就可以构建包含VPRN核心的隧道。
One approach to setting up the tunnel mesh is to use point-to-point IP tunnels, and the requirements and issues for such tunnels have been discussed in section 3.0. For example while tunnel establishment can be done through manual configuration, this is
设置隧道网格的一种方法是使用点对点IP隧道，此类隧道的要求和问题已在第3.0节中讨论。例如，虽然可以通过手动配置建立隧道，但这是
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）问题，显然不太可能是一个可伸缩的解决方案。因此，隧道设置应使用某种形式的信令协议，以允许两个节点构建一个只知道彼此身份的隧道。
Another approach is to use the multipoint to point 'tunnels' provided by MPLS. As noted in [38], MPLS can be considered to be a form of IP tunneling, since the labels of MPLS packets allow for routing decisions to be decoupled from the addressing information of the packets themselves. MPLS label distribution mechanisms can be used to associate specific sets of MPLS labels with particular VPRN address prefixes supported on particular egress points (i.e., stub links of edge routers) and hence allow other edge routers to explicitly label and route traffic to particular VPRN stub links.
另一种方法是使用MPLS提供的多点对点“隧道”。如[38]所述，MPLS可被视为IP隧道的一种形式，因为MPLS数据包的标签允许路由决策与数据包本身的寻址信息分离。MPLS标签分发机制可用于将特定的MPLS标签集与特定出口点（即边缘路由器的存根链路）上支持的特定VPRN地址前缀相关联，从而允许其他边缘路由器明确标记流量并将流量路由到特定VPRN存根链路。
One attraction of MPLS as a tunneling mechanism is that it may require less processing within each edge router than alternative tunneling mechanisms. This is a function of the fact that data security within a MPLS network is implicit in the explicit label binding, much as with a connection oriented network, such as Frame Relay. This may hence lessen customer concerns about data security and hence require less processor intensive security mechanisms (e.g., IPSec). However there are other potential security concerns with MPLS. There is no direct support for security features such as authentication, confidentiality, and non-repudiation and the trust model for MPLS means that intermediate routers, (which may belong to different administrative domains), through which membership and prefix reachability information is conveyed, must be trusted, not just the edge routers themselves.
MPLS作为隧道机制的一个吸引力在于，与其他隧道机制相比，它在每个边缘路由器内需要的处理更少。这是MPLS网络中的数据安全性隐含在显式标签绑定中这一事实的一个功能，就像面向连接的网络（如帧中继）一样。因此，这可能会减少客户对数据安全性的担忧，因此需要较少的处理器密集型安全机制（如IPSec）。然而，MPLS还有其他潜在的安全问题。不直接支持身份验证、机密性和不可否认性等安全功能，MPLS的信任模型意味着必须信任中间路由器（可能属于不同的管理域），通过中间路由器传递成员资格和前缀可达性信息，不仅仅是边缘路由器本身。
The discussion thus far has implicitly assumed that stub routers are connected to one and only one VPRN edge router. In general, this restriction should be capable of being relaxed without any change to VPRN operation, given general market interest in multihoming for reliability and other reasons. In particular, in cases where the stub router supports multiple redundant links, with only one operational at any given time, with the links connected either to the same VPRN edge router, or to two or more different VPRN edge routers, then the stub link reachability mechanisms will both discover the loss of an active link, and the activation of a backup link. In the former situation, the previously connected VPRN edge router will cease advertising reachability to the stub node, while the VPRN edge router with the now active link will begin advertising reachability, hence restoring connectivity.
到目前为止的讨论隐含地假设存根路由器连接到一个且仅连接到一个VPRN边缘路由器。一般来说，鉴于市场对多宿系统的普遍兴趣，出于可靠性和其他原因，在不改变VPRN运行的情况下，应能够放宽这一限制。特别是，在存根路由器支持多个冗余链路的情况下，在任何给定时间只有一个可用链路，链路连接到同一个VPRN边缘路由器或两个或多个不同的VPRN边缘路由器，则存根链路可达性机制都将发现活动链路的丢失，以及激活备份链接。在前一种情况下，先前连接的VPRN边缘路由器将停止对存根节点的播发可达性，而具有当前活动链路的VPRN边缘路由器将开始播发可达性，从而恢复连接。
An alternative scenario is where the stub node supports multiple active links, using some form of load sharing algorithm. In such a case, multiple VPRN edge routers may have active paths to the stub node, and may so advertise across the VPRN. This scenario should not cause any problem with reachability across the VPRN providing that the intra-VPRN reachability mechanism can accommodate multiple paths to the same prefix, and has the appropriate mechanisms to preclude looping - for instance, distance vector metrics associated with each advertised prefix.
另一种情况是，存根节点使用某种形式的负载共享算法支持多个活动链路。在这种情况下，多个VPRN边缘路由器可以具有到存根节点的活动路径，并且可以在VPRN上进行广告。如果VPRN内部可达性机制可以容纳到同一前缀的多条路径，并且具有适当的机制来防止循环，例如，与每个播发前缀相关联的距离向量度量，则此场景不应导致VPRN的可达性出现任何问题。
Multicast and broadcast traffic can be supported across VPRNs either by edge replication or by native multicast support in the backbone. These two cases are discussed below.
可以通过边缘复制或主干中的本机多播支持跨VPRN支持多播和广播流量。下面讨论这两种情况。
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边缘路由器上运行，以确定多播流量的分布树，从而减少不必要的洪水流量。这可以通过在每个VPRN边缘路由器上和之间通过VPRN隧道运行标准多播路由协议的实例来实现，例如协议独立多播（PIM）[39]或距离向量多播路由协议（DVMRP）[40]，正如第5.3.4节所讨论的，单播路由协议可能在每个VPRN边缘路由器上运行，以确定VPN内单播可达性。或者，如果在VPRN隧道中运行链路可达性协议以实现VPRN内可达性，则还可以对其进行扩充，以允许VPRN边缘路由器指示在每个边缘节点处请求接收的特定多播组以及每个边缘站点处的多播源。
In either case, there would need to be some mechanism to allow for the VPRN edge routers to determine which particular multicast groups were requested at each site and which sources were present at each site. How this could be done would, in general, be a function of the capabilities of the CPE stub routers at each site. If these run multicast routing protocols, then they can interact directly with the equivalent protocols at each VPRN edge router. If the CPE device does not run a multicast routing protocol, then in the absence of Internet Group Management Protocol (IGMP) proxying [41] the customer site would be limited to a single subnet connected to the VPRN edge router via a bridging device, as the scope of an IGMP message is
在任何一种情况下，都需要某种机制，以允许VPRN边缘路由器确定每个站点请求了哪些特定的多播组，以及每个站点存在哪些源。一般来说，如何做到这一点取决于每个站点的CPE存根路由器的能力。如果它们运行多播路由协议，那么它们可以直接与每个VPRN边缘路由器上的等效协议交互。如果CPE设备不运行多播路由协议，则在没有Internet组管理协议（IGMP）代理的情况下[41]，客户站点将被限制为通过桥接设备连接到VPRN边缘路由器的单个子网，因为IGMP消息的范围是有限的
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.
仅限于一个子网。然而，使用IGMP代理，CPE路由器可以在受限拓扑中进行多播转发，而无需运行多播路由协议。CPE路由器在其与客户站点的接口上执行IGMP的路由器功能，在其与VPRN边缘路由器的接口上执行IGMP的主机功能。
This is where VPRN edge routers map intra-VPRN multicast traffic onto a native IP multicast distribution mechanism across the backbone. Note that intra-VPRN multicast has the same requirements for isolation from general backbone traffic as intra-VPRN unicast traffic. Currently the only IP tunneling mechanism that has native support for multicast is MPLS. On the other hand, while MPLS supports native transport of IP multicast packets, additional mechanisms would be needed to leverage these mechanisms for the support of intra-VPRN multicast.
这是VPRN边缘路由器将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内的多播组地址前面加上该VPRN的VPN-ID，然后重新分配这些地址，基本上将该VPN-ID/VPRN内多播地址元组视为主干多播路由协议内的正常多播地址，就像单播可达性的情况一样，如前所述。然后，可以使用MPLS多播标签分发机制来设置适当的多播LSP，以便在支持特定多播组地址的每个VPRN内互连这些站点。然而，请注意，这将要求每个中间lsr不仅知道每个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内多播通信量。
A particular issue with the use of native multicast support is the provision of security for such multicast traffic. Unlike the case of edge replication, which inherits the security characteristics of the underlying tunnel, native multicast mechanisms will need to use some form of secure multicast mechanism. The development of architectures and solutions for secure multicast is an active research area, for example see [42] and [43]. The Secure Multicast Group (SMuG) of the IRTF has been set up to develop prototype solutions, which would then be passed to the IETF IPSec working group for standardization.
使用本机多播支持的一个特殊问题是为此类多播流量提供安全性。边缘复制继承了底层隧道的安全特性，与此不同，本机多播机制需要使用某种形式的安全多播机制。安全多播体系结构和解决方案的开发是一个活跃的研究领域，例如参见[42]和[43]。IRTF的安全多播组（SMuG）已经成立，以开发原型解决方案，然后将其提交给IETF IPSec工作组进行标准化。
However considerably more development is needed before scalable secure native multicast mechanisms can be generally deployed.
然而，在可扩展的安全本机多播机制可以普遍部署之前，还需要进行更多的开发。
The various proposals that have been developed to support some form of VPRN functionality can be broadly classified into two groups - those that utilize the router piggybacking approach for distributing VPN membership and/or reachability information ([13],[15]) and those that use the virtual routing approach ([12],[14]). In some cases the mechanisms described rely on the characteristics of a particular infrastructure (e.g. MPLS) rather than just IP.
为支持某种形式的VPRN功能而开发的各种方案可大致分为两类——使用路由器搭载方法分发VPN成员资格和/或可达性信息的方案（[13]，[15]）和使用虚拟路由方法的方案（[12]，[14]）。在某些情况下，所描述的机制依赖于特定基础设施（例如MPLS）的特性，而不仅仅是IP。
Within the context of the virtual routing approach it may be useful to develop a membership distribution protocol based on a directory or MIB. When combined with the protocol extensions for IP tunneling protocols outlined in section 3.2, this would then provide the basis for a complete set of protocols and mechanisms that support interoperable VPRNs that span multiple administrations over an IP backbone. Note that the other major pieces of functionality needed - the learning and distribution of customer reachability information, can be performed by instances of standard routing protocols, without the need for any protocol extensions.
在虚拟路由方法的上下文中，开发基于目录或MIB的成员资格分发协议可能很有用。当与第3.2节中概述的IP隧道协议的协议扩展相结合时，这将为支持跨IP主干网的多个管理的可互操作VPRN的一整套协议和机制提供基础。请注意，所需的其他主要功能（客户可达性信息的学习和分发）可以由标准路由协议的实例执行，而无需任何协议扩展。
Also for the constrained case of a full mesh topology, the usefulness of developing a link reachability protocol could be examined, however the limitations and scalability issues associated with this topology may not make it worthwhile to develop something specific for this case, as standard routing will just work.
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.translate error, please retry
Extending routing protocols to allow a VPN-ID to carried in routing update packets could also be examined, but is not necessary if VPN specific tunnels are used.
还可以检查扩展路由协议以允许在路由更新数据包中携带VPN-ID，但如果使用特定于VPN的隧道，则没有必要这样做。
A Virtual Private Dial Network (VPDN) allows for a remote user to connect on demand through an ad hoc tunnel into another site. The user is connected to a public IP network via a dial-up PSTN or ISDN link, and user packets are tunneled across the public network to the desired site, giving the impression to the user of being 'directly' connected into that site. A key characteristic of such ad hoc connections is the need for user authentication as a prime requirement, since anyone could potentially attempt to gain access to such a site using a switched dial network.
虚拟专用拨号网络（VPDN）允许远程用户按需通过特设隧道连接到另一个站点。用户通过拨号PSTN或ISDN链路连接到公共IP网络，用户数据包通过公共网络传输到所需站点，给用户留下“直接”连接到该站点的印象。这种特殊连接的一个关键特征是需要用户身份验证，因为任何人都可能试图使用交换拨号网络访问这样的站点。
Today many corporate networks allow access to remote users through dial connections made through the PSTN, with users setting up PPP connections across an access network to a network access server, at which point the PPP sessions are authenticated using AAA systems running such standard protocols as Radius [44]. Given the pervasive deployment of such systems, any VPDN system must in practice allow for the near transparent re-use of such existing systems.
如今，许多公司网络允许通过PSTN进行拨号连接访问远程用户，用户通过接入网络建立PPP连接到网络接入服务器，此时PPP会话使用运行Radius等标准协议的AAA系统进行身份验证[44]。鉴于此类系统的普遍部署，任何VPDN系统在实践中都必须允许此类现有系统的近乎透明的重复使用。
The IETF have developed the Layer 2 Tunneling Protocol (L2TP) [8] which allows for the extension of of user PPP sessions from an L2TP Access Concentrator (LAC) to a remote L2TP Network Server (LNS). The L2TP protocol itself was based on two earlier protocols, the Layer 2 Forwarding protocol (L2F) [45], and the Point-to-Point Tunneling Protocol (PPTP) [46], and this is reflected in the two quite different scenarios for which L2TP can be used - compulsory tunneling and voluntary tunneling, discussed further below in sections 6.2 and 6.3.
IETF开发了第2层隧道协议（L2TP）[8]，允许用户PPP会话从L2TP访问集中器（LAC）扩展到远程L2TP网络服务器（LNS）。L2TP协议本身基于两个早期协议，即第2层转发协议（L2F）[45]和点对点隧道协议（PPTP）[46]，这反映在L2TP可用于的两个完全不同的场景中——强制隧道和自愿隧道，将在下文第6.2节和第6.3节中进一步讨论。
This document focuses on the use of L2TP over an IP network (using UDP), but L2TP may also be run directly over other protocols such as ATM or Frame Relay. Issues specifically related to running L2TP over non-IP networks, such as how to secure such tunnels, are not addressed here.
本文档重点介绍通过IP网络（使用UDP）使用L2TP，但L2TP也可以直接通过其他协议（如ATM或帧中继）运行。与在非IP网络上运行L2TP特别相关的问题，如如何保护此类隧道的安全，在此不作说明。
This section looks at the characteristics of the L2TP tunneling protocol using the categories outlined in section 3.0.
本节使用第3.0节中概述的类别来查看L2TP隧道协议的特性。
L2TP has inherent support for the multiplexing of multiple calls from different users over a single link. Between the same two IP endpoints, there can be multiple L2TP tunnels, as identified by a tunnel-id, and multiple sessions within a tunnel, as identified by a session-id.
L2TP固有地支持在单个链路上多路复用来自不同用户的多个呼叫。在相同的两个IP端点之间，可以存在由隧道id标识的多个L2TP隧道，以及由会话id标识的隧道内的多个会话。
This is supported via the inbuilt control connection protocol, allowing both tunnels and sessions to be established dynamically.
这通过内置控制连接协议得到支持，允许动态建立隧道和会话。
By allowing for the transparent extension of PPP from the user, through the LAC to the LNS, L2TP allows for the use of whatever security mechanisms, with respect to both connection set up, and data transfer, may be used with normal PPP connections. However this does not provide security for the L2TP control protocol itself. In this case L2TP could be further secured by running it in combination with IPSec through IP backbones [47], [48], or related mechanisms on non-IP backbones [49].
通过允许从用户通过LAC到LNS的PPP的透明扩展，L2TP允许在连接设置和数据传输方面使用任何安全机制，可与正常PPP连接一起使用。但是，这并不能为L2TP控制协议本身提供安全性。在这种情况下，L2TP可以通过IP主干网[47]、[48]或非IP主干网[49]上的相关机制与IPSec一起运行来进一步保护。
The interaction of L2TP with AAA systems for user authentication and authorization is a function of the specific means by which L2TP is used, and the nature of the devices supporting the LAC and the LNS. These issues are discussed in depth in [50].
L2TP与AAA系统的交互用于用户身份验证和授权是L2TP使用的具体方式以及支持LAC和LNS的设备性质的函数。这些问题在[50]中进行了深入讨论。
The means by which the host determines the correct LAC to connect to, and the means by which the LAC determines which users to further tunnel, and the LNS parameters associated with each user, are outside the scope of the operation of a VPDN, but may be addressed, for instance, by evolving Internet roaming specifications [51].
主机确定要连接到的正确LAC的方法、LAC确定要进一步隧道的用户的方法以及与每个用户相关联的LNS参数不在VPDN的操作范围内，但可以通过例如演进互联网漫游规范来解决[51]。
L2TP transports PPP packets (and only PPP packets) and thus can be used to carry multiprotocol traffic since PPP itself is multiprotocol.
L2TP传输PPP数据包（且仅传输PPP数据包），因此可用于承载多协议流量，因为PPP本身是多协议的。
L2TP supports sequenced delivery of packets. This is a capability that can be negotiated at session establishment, and that can be turned on and off by an LNS during a session. The sequence number field in L2TP can also be used to provide an indication of dropped packets, which is needed by various PPP compression algorithms to operate correctly. If no compression is in use, and the LNS determines that the protocols in use (as evidenced by the PPP NCP negotiations) can deal with out of sequence packets (e.g. IP), then it may disable the use of sequencing.
L2TP支持数据包的顺序传递。这是一种可以在会话建立时协商的能力，并且可以在会话期间由LNS打开和关闭。L2TP中的序列号字段还可用于提供丢包指示，这是各种PPP压缩算法正确运行所需的。如果没有使用压缩，并且LNS确定正在使用的协议（如PPP NCP协商所证明的）可以处理无序数据包（例如IP），那么它可以禁用排序的使用。
A keepalive protocol is used by L2TP in order to allow it to distinguish between a tunnel outage and prolonged periods of tunnel inactivity.
L2TP使用keepalive协议来区分隧道中断和隧道长时间不活动。
L2TP itself has no inbuilt support for a segmentation and reassembly capability, but when run over UDP/IP IP fragmentation will take place if necessary. Note that a LAC or LNS may adjust the Maximum Receive Unit (MRU) negotiated via PPP in order to preclude fragmentation, if it has knowledge of the MTU used on the path between LAC and LNS. To this end, there is a proposal to allow the use of MTU discovery for cases where the L2TP tunnel transports IP frames [52].
L2TP本身没有对分段和重组功能的内置支持，但在UDP/IP上运行时，必要时将发生IP分段。注意，如果LAC或LNS知道在LAC和LNS之间的路径上使用的MTU，则可以调整通过PPP协商的最大接收单元（MRU），以排除碎片。为此，有一项建议允许在L2TP隧道传输IP帧的情况下使用MTU发现[52]。
L2TP as used over IP networks runs over UDP and must be used to carry PPP traffic. This results in a significant amount of overhead, both in the data plane with UDP, L2TP and PPP headers, and also in the control plane, with the L2TP and PPP control protocols. This is discussed further in section 6.3
IP网络上使用的L2TP通过UDP运行，必须用于承载PPP流量。这会导致大量开销，包括UDP、L2TP和PPP头的数据平面，以及L2TP和PPP控制协议的控制平面。这将在第6.3节中进一步讨论
L2TP supports flow and congestion control mechanisms for the control protocol, but not for data traffic. See section 3.1.9 for more details.
L2TP支持控制协议的流量和拥塞控制机制，但不支持数据流量。详见第3.1.9节。
An L2TP header contains a 1-bit priority field, which can be set for packets that may need preferential treatment (e.g. keepalives) during local queuing and transmission. Also by transparently extending PPP, L2TP has inherent support for such PPP mechanisms as multi-link PPP [53] and its associated control protocols [54], which allow for bandwidth on demand to meet user requirements.
L2TP报头包含一个1位优先级字段，可以为本地排队和传输期间可能需要优先处理（例如keepalives）的数据包设置该字段。同样通过透明地扩展PPP，L2TP对诸如多链路PPP[53]及其相关控制协议[54]等PPP机制具有内在支持，这些机制允许按需带宽以满足用户需求。
In addition L2TP calls can be mapped into whatever underlying traffic management mechanisms may exist in the network, and there are proposals to allow for requests through L2TP signalling for specific differentiated services behaviors [55].
此外，L2TP呼叫可以映射到网络中可能存在的任何底层流量管理机制中，并且有建议允许通过L2TP信令请求特定的区分服务行为[55]。
Since L2TP is designed to transparently extend PPP, it does not attempt to supplant the normal address assignment mechanisms associated with PPP. Hence, in general terms the host initiating the PPP session will be assigned an address by the LNS using PPP procedures. This addressing may have no relation to the addressing used for communication between the LAC and LNS. The LNS will also need to support whatever forwarding mechanisms are needed to route traffic to and from the remote host.
由于L2TP旨在透明地扩展PPP，因此它不会试图取代与PPP相关的正常地址分配机制。因此，一般来说，发起PPP会话的主机将由LNS使用PPP程序分配一个地址。该寻址可能与用于LAC和LN之间通信的寻址无关。LNS还需要支持将流量路由到远程主机或从远程主机路由到远程主机所需的任何转发机制。
Compulsory tunneling refers to the scenario in which a network node - a dial or network access server, for instance - acting as a LAC, extends a PPP session across a backbone using L2TP to a remote LNS, as illustrated below. This operation is transparent to the user initiating the PPP session to the LAC. This allows for the decoupling of the location and/or ownership of the modem pools used to terminate dial calls, from the site to which users are provided access. Support for this scenario was the original intent of the L2F specification, upon which the L2TP specification was based.
强制隧道是指网络节点（例如拨号或网络访问服务器）充当LAC，使用L2TP将PPP会话跨主干扩展到远程LNS的场景，如下所示。该操作对于发起到LAC的PPP会话的用户是透明的。这允许将用于终止拨号呼叫的调制解调器池的位置和/或所有权与提供用户访问的站点分离。对该场景的支持是L2F规范的初衷，L2TP规范就是基于此。
There are a number of different deployment scenarios possible. One example, shown in the diagram below, is where a subscriber host dials into a NAS acting as a LAC, and is tunneled across an IP network (e.g. the Internet) to a gateway acting as an LNS. The gateway provides access to a corporate network, and could either be a device in the corporate network itself, or could be an ISP edge router, in the case where a customer has outsourced the maintenance of LNS functionality to an ISP. Another scenario is where an ISP uses L2TP to provide a subscriber with access to the Internet. The subscriber host dials into a NAS acting as a LAC, and is tunneled across an access network to an ISP edge router acting as an LNS. This ISP edge router then feeds the subscriber traffic into the Internet. Yet other scenarios are where an ISP uses L2TP to provide a subscriber with access to a VPRN, or with concurrent access to both a VPRN and the Internet.
可能存在许多不同的部署场景。下图所示的一个示例是，订户主机拨入充当LAC的NAS，并通过IP网络（如互联网）隧道连接到充当LNS的网关。网关提供对公司网络的访问，并且可以是公司网络本身中的设备，也可以是ISP边缘路由器（如果客户已将LNS功能的维护外包给ISP）。另一种情况是，ISP使用L2TP向用户提供对Internet的访问。用户主机拨入作为LAC的NAS，并通过接入网络传输到作为LNS的ISP边缘路由器。然后，ISP边缘路由器将用户流量送入Internet。还有一些情况是，ISP使用L2TP向用户提供对VPRN的访问，或者同时访问VPRN和Internet。
A VPDN, whether using compulsory or voluntary tunneling, can be viewed as just another type of access method for subscriber traffic, and as such can be used to provide connectivity to different types of networks, e.g. a corporate network, the Internet, or a VPRN. The last scenario is also an example of how a VPN service as provided to a customer may be implemented using a combination of different types of VPN.
VPDN，无论是使用强制隧道还是自愿隧道，都可以被视为用户流量的另一种访问方法，因此可以用于提供到不同类型网络的连接，例如公司网络、互联网或VPRN。最后一个场景也是如何使用不同类型的VPN的组合来实现提供给客户的VPN服务的示例。
10.0.0.1
+----+
|Host|----- LAC ------------- LNS 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
10.0.0.1
+----+
|Host|----- LAC ------------- LNS 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
<------- L2TP Tunnel ------->
<------- L2TP Tunnel ------->
<--------------------- PPP Session ------->
<--------------------- PPP Session ------->
Figure 6.1: Compulsory Tunneling Example
图6.1：强制隧道示例
Compulsory tunneling was originally intended for deployment on network access servers supporting wholesale dial services, allowing for remote dial access through common facilities to an enterprise site, while precluding the need for the enterprise to deploy its own dial servers. Another example of this is where an ISP outsources its own dial connectivity to an access network provider (such as a Local Exchange Carrier (LEC) in the USA) removing the need for an ISP to maintain its own dial servers and allowing the LEC to serve multiple ISPs. More recently, compulsory tunneling mechanisms have also been proposed for evolving Digital Subscriber Line (DSL) services [56], [57], which also seek to leverage the existing AAA infrastructure.
强制隧道最初旨在部署在支持批发拨号服务的网络访问服务器上，允许通过公用设施远程拨号访问企业站点，同时企业无需部署自己的拨号服务器。这方面的另一个例子是，ISP将自己的拨号连接外包给接入网络提供商（如美国的本地交换运营商（LEC）），从而消除了ISP维护自己的拨号服务器的需要，并允许LEC为多个ISP提供服务。最近，还为发展数字用户线（DSL）服务提出了强制隧道机制[56]，[57]，这也寻求利用现有的AAA基础设施。
Call routing for compulsory tunnels requires that some aspect of the initial PPP call set up can be used to allow the LAC to determine the identity of the LNS. As noted in [50], these aspects can include the user identity, as determined through some aspect of the access network, including calling party number, or some attribute of the called party, such as the Fully Qualified Domain Name (FQDN) of the identity claimed during PPP authentication.
强制隧道的呼叫路由要求初始PPP呼叫设置的某些方面可用于允许LAC确定LN的身份。如[50]中所述，这些方面可以包括通过接入网络的某些方面（包括主叫方号码）确定的用户身份，或者被叫方的某些属性，例如在PPP认证期间声明的身份的完全限定域名（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.
还可以将两个L2TP隧道链接在一起，由此LAC发起到中间中继设备的隧道，中间中继设备充当到第一个LAC的LN，并充当到最终LN的LAC。在某些情况下，由于与接入网络提供商、IP主干网提供商和企业客户之间的划分有关的管理、组织或监管问题，可能需要这样做。
Voluntary tunneling refers to the case where an individual host connects to a remote site using a tunnel originating on the host, with no involvement from intermediate network nodes, as illustrated below. The PPTP specification, parts of which have been incorporated into L2TP, was based upon a voluntary tunneling model.
自愿性隧道是指单个主机使用源自主机的隧道连接到远程站点，而不涉及中间网络节点的情况，如下所示。PPTP规范的一部分已纳入L2TP，该规范基于自愿隧道模型。
As with compulsory tunneling there are different deployment scenarios possible. The diagram below shows a subscriber host accessing a corporate network with either L2TP or IPSec being used as the voluntary tunneling mechanism. Another scenario is where voluntary tunneling is used to provide a subscriber with access to a VPRN.
与强制隧道一样，可能存在不同的部署场景。下图显示了使用L2TP或IPSec作为自愿隧道机制访问公司网络的订户主机。另一种情况是使用自愿隧道为订户提供对VPRN的访问。
The L2TP specification has support for voluntary tunneling, insofar as the LAC can be located on a host, not only on a network node. Note that such a host has two IP addresses - one for the LAC-LNS IP tunnel, and another, typically allocated via PPP, for the network to which the host is connecting. The benefits of using L2TP for voluntary tunneling are that the existing authentication and address assignment mechanisms used by PPP can be reused without modification. For example an LNS could also include a Radius client, and communicate with a Radius server to authenticate a PPP PAP or CHAP exchange, and to retrieve configuration information for the host such as its IP address and a list of DNS servers to use. This information can then be passed to the host via the PPP IPCP protocol.
L2TP规范支持自愿隧道，只要LAC可以位于主机上，而不仅仅是网络节点上。请注意，这样的主机有两个IP地址——一个用于LAC-LNS IP隧道，另一个通常通过PPP分配，用于主机所连接的网络。将L2TP用于自愿隧道的好处是，PPP使用的现有身份验证和地址分配机制可以重用，无需修改。例如，LNS还可以包括Radius客户端，并与Radius服务器通信以验证PPP-PAP或CHAP交换，并检索主机的配置信息，例如其IP地址和要使用的DNS服务器列表。然后可以通过PPP IPCP协议将此信息传递给主机。
10.0.0.1
+----+
|Host|----- ------------- 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
10.0.0.1
+----+
|Host|----- ------------- 10.0.0.0/8
+----+ / +-----+ ( ) +-----+ ---------
/----| NAS |---( IP Backbone )---| GW |----( Corp. )
dial +-----+ ( ) +-----+ ( Network )
connection ------------- ---------
<-------------- L2TP Tunnel -------------->
with LAC on host
<-------------- PPP Session --------------> LNS on gateway
<-------------- L2TP Tunnel -------------->
with LAC on host
<-------------- PPP Session --------------> LNS on gateway
or
或
<-------------- IPSEC Tunnel -------------->
<-------------- IPSEC Tunnel -------------->
Figure 6.2: Voluntary Tunneling Example
图6.2：自愿性隧道示例
The above procedure is not without its costs, however. There is considerable overhead with such a protocol stack, particularly when IPSec is also needed for security purposes, and given that the host may be connected via a low-bandwidth dial up link. The overhead consists of both extra headers in the data plane and extra control protocols needed in the control plane. Using L2TP for voluntary tunneling, secured with IPSec, means a web application, for example, would run over the following stack
然而，上述程序并非没有成本。这种协议栈有相当大的开销，特别是当出于安全目的还需要IPSec时，并且考虑到主机可以通过低带宽拨号链路连接。开销包括数据平面中的额外头和控制平面中需要的额外控制协议。例如，将L2TP用于自愿隧道（由IPSec保护）意味着web应用程序将在以下堆栈上运行
HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC
HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC
It is proposed in [58] that IPSec alone be used for voluntary tunnels reducing overhead, using the following stack.
[58]中建议单独使用IPSec用于自愿隧道，使用以下堆栈减少开销。
HTTP/TCP/IP/ESP/IP/PPP/AHDLC
HTTP/TCP/IP/ESP/IP/PPP/AHDLC
In this case IPSec is used in tunnel mode, with the tunnel terminating either on an IPSec edge device at the enterprise site, or on the provider edge router connected to the enterprise site. There are two possibilities for the IP addressing of the host. Two IP addresses could be used, in a similar manner to the L2TP case. Alternatively the host can use a single public IP address as the source IP address in both inner and outer IP headers, with the gateway performing Network Address Translation (NAT) before forwarding the traffic to the enterprise network. To other hosts in the enterprise network the host appears to have an 'internal' IP address. Using NAT has some limitations and restrictions, also pointed out in [58].
在这种情况下，IPSec以隧道模式使用，隧道在企业站点的IPSec边缘设备或连接到企业站点的提供商边缘路由器上终止。主机的IP地址有两种可能。可以使用两个IP地址，方式与L2TP类似。或者，主机可以使用单个公共IP地址作为内部和外部IP报头中的源IP地址，网关在将流量转发到企业网络之前执行网络地址转换（NAT）。对于企业网络中的其他主机，该主机似乎具有“内部”IP地址。[58]中也指出，使用NAT有一些限制和限制。
Another area of potential problems with PPP is due to the fact that the characteristics of a link layer implemented via an L2TP tunnel over an IP backbone are quite different to a link layer run over a serial line, as discussed in the L2TP specification itself. For example, poorly chosen PPP parameters may lead to frequent resets and timeouts, particularly if compression is in use. This is because an L2TP tunnel may misorder packets, and may silently drop packets, neither of which normally occurs on serial lines. The general packet loss rate could also be significantly higher due to network congestion. Using the sequence number field in an L2TP header addresses the misordering issue, and for cases where the LAC and LNS are coincident with the PPP endpoints, as in voluntary tunneling, the sequence number field can also be used to detect a dropped packet, and to pass a suitable indication to any compression entity in use, which typically requires such knowledge in order to keep the compression histories in synchronization at both ends. (In fact this is more of an issue with compulsory tunneling since the LAC may have to deliberately issue a corrupted frame to the PPP host, to give an indication of packet loss, and some hardware may not allow this).
PPP潜在问题的另一个方面是，如L2TP规范本身所述，通过IP主干上的L2TP隧道实现的链路层的特性与通过串行线路运行的链路层的特性大不相同。例如，选择不当的PPP参数可能导致频繁重置和超时，尤其是在使用压缩时。这是因为L2TP隧道可能会对数据包进行错误排序，并且可能会无声地丢弃数据包，这两种情况通常都不会发生在串行线路上。由于网络拥塞，一般的数据包丢失率也会显著提高。在L2TP报头中使用序列号字段可解决乱序问题，对于LAC和LN与PPP端点一致的情况，如在自愿隧道中，序列号字段还可用于检测丢弃的数据包，并将适当的指示传递给正在使用的任何压缩实体，这通常需要这些知识，以便在两端保持压缩历史同步。（事实上，这是强制隧道的一个更大的问题，因为LAC可能不得不故意向PPP主机发出损坏的帧，以指示数据包丢失，并且一些硬件可能不允许这样做）。
If IPSec is used for voluntary tunneling, the functions of user authentication and host configuration, achieved by means of PPP when using L2TP, still need to be carried out. A distinction needs to be drawn here between machine authentication and user authentication. ' Two factor' authentication is carried out on the basis of both something the user has, such as a machine or smartcard with a digital certificate, and something the user knows, such as a password. (Another example is getting money from an bank ATM machine - you need a card and a PIN number). Many of the existing legacy schemes currently in use to perform user authentication are asymmetric in nature, and are not supported by IKE. For remote access the most common existing user authentication mechanism is to use PPP between the user and access server, and Radius between the access server and authentication server. The authentication exchanges that occur in this case, e.g. a PAP or CHAP exchange, are asymmetric. Also CHAP supports the ability for the network to reauthenticate the user at any time after the initial session has been established, to ensure that the current user is the same person that initiated the session.
如果使用IPSec进行自愿隧道，那么在使用L2TP时通过PPP实现的用户认证和主机配置功能仍然需要执行。这里需要区分机器身份验证和用户身份验证。”双因素认证是基于用户拥有的东西（如带有数字证书的机器或智能卡）和用户知道的东西（如密码）进行的。（另一个例子是从银行自动柜员机取款——你需要一张卡和一个PIN码）。目前用于执行用户身份验证的许多现有遗留方案本质上是不对称的，IKE不支持这些方案。对于远程访问，最常见的现有用户身份验证机制是在用户和访问服务器之间使用PPP，在访问服务器和身份验证服务器之间使用Radius。在这种情况下发生的身份验证交换（例如PAP或CHAP交换）是不对称的。CHAP还支持网络在初始会话建立后随时重新验证用户的能力，以确保当前用户与发起会话的用户相同。
While IKE provides strong support for machine authentication, it has only limited support for any form of user authentication and has no support for asymmetric user authentication. While a user password can be used to derive a key used as a preshared key, this cannot be used with IKE Main Mode in a remote access environment, as the user will not have a fixed IP address, and while Aggressive Mode can be used instead, this affords no identity protection. To this end there have been a number of proposals to allow for support of legacy asymmetric user level authentication schemes with IPSec. [59] defines a new IKE message exchange - the transaction exchange - which allows for both Request/Reply and Set/Acknowledge message sequences, and it also defines attributes that can be used for client IP stack configuration. [60] and [61] describe mechanisms that use the transaction message exchange, or a series of such exchanges, carried out between the IKE Phase 1 and Phase 2 exchanges, to perform user authentication. A different approach, that does not extend the IKE protocol itself, is described in [62]. With this approach a user establishes a Phase 1 SA with a security gateway and then sets up a Phase 2 SA to the gateway, over which an existing authentication protocol is run. The gateway acts as a proxy and relays the protocol messages to an authentication server.
虽然IKE提供了对机器身份验证的强大支持，但它对任何形式的用户身份验证的支持都是有限的，并且不支持非对称用户身份验证。虽然用户密码可用于派生用作预共享密钥的密钥，但这不能与远程访问环境中的IKE主模式一起使用，因为用户将没有固定的IP地址，并且虽然可以使用攻击模式，但这不提供身份保护。为此，有许多建议允许支持具有IPSec的传统非对称用户级身份验证方案。[59]定义了一个新的IKE消息交换——事务交换——它允许请求/应答和设置/确认消息序列，并且还定义了可用于客户端IP堆栈配置的属性。[60]和[61]描述了使用在IKE阶段1和阶段2交换之间执行的事务消息交换或一系列此类交换来执行用户身份验证的机制。[62]中描述了一种不扩展IKE协议本身的不同方法。使用这种方法，用户使用安全网关建立阶段1 SA，然后为网关建立阶段2 SA，在该网关上运行现有的身份验证协议。网关充当代理并将协议消息中继到身份验证服务器。
In addition there have also been proposals to allow the remote host to be configured with an IP address and other configuration information over IPSec. For example [63] describes a method whereby a remote host first establishes a Phase 1 SA with a security gateway and then sets up a Phase 2 SA to the gateway, over which the DHCP
此外，还有一些建议允许通过IPSec为远程主机配置IP地址和其他配置信息。例如[63]描述了一种方法，其中远程主机首先通过安全网关建立阶段1 SA，然后通过该网关建立阶段2 SA，DHCP通过该网关
protocol is run. The gateway acts as a proxy and relays the protocol messages to the DHCP server. Again, like [62], this proposal does not involve extensions to the IKE protocol itself.
协议正在运行。网关充当代理并将协议消息中继到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功能的另一个方面是多协议操作，因为可能需要携带除IP以外的网络层协议，甚至需要携带支持IPSec桥接所需的链路层协议（例如以太网）。第3.1.4节对此进行了讨论。
The methods of supporting legacy user authentication and host configuration capabilities in a remote access environment are currently being discussed in the IPSec working group.
IPSec工作组目前正在讨论在远程访问环境中支持传统用户身份验证和主机配置功能的方法。
The current PPP based dial model assumes a host directly connected to a connection oriented dial access network. Recent work on new access technologies such as DSL have attempted to replicate this model [57], so as to allow for the re-use of existing AAA systems. The proliferation of personal computers, printers and other network appliances in homes and small businesses, and the ever lowering costs of networks, however, are increasingly challenging the directly connected host model. Increasingly, most hosts will access the Internet through small, typically Ethernet, local area networks.
当前基于PPP的拨号模型假设主机直接连接到面向连接的拨号访问网络。最近关于新接入技术（如DSL）的工作试图复制此模型[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信息。为解决这一情况，已经提出了一些建议：
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.
还有一个将PPP直接映射到以太网（PPPOE）[64]的规范，该规范使用广播机制允许主机找到适当的接入服务器进行连接。如果需要，这样的服务器可以使用L2TP或类似的机制进一步隧道PPP会话。
The IPSec based voluntary tunneling mechanisms discussed above can be used either with networked or directly connected hosts.
上面讨论的基于IPSec的自愿隧道机制可用于联网或直接连接的主机。
Note that all of these methods require additional host software to be used, which implements either LAC, PPPOE client or IPSec client functionality.
请注意，所有这些方法都需要使用额外的主机软件，以实现LAC、PPPOE客户端或IPSec客户端功能。
The L2TP specification has been finalized and will be widely used for compulsory tunneling. As discussed in section 3.2, defining specific modes of operation for IPSec when used to secure L2TP would be beneficial.
L2TP规范已最终确定，并将广泛用于强制掘进。如第3.2节所述，当用于保护L2TP时，为IPSec定义特定的操作模式将是有益的。
Also, for voluntary tunneling using IPSec, completing the work needed to provide support for the following areas would be useful
此外，对于使用IPSec的自愿隧道，完成为以下领域提供支持所需的工作将非常有用
- asymmetric / legacy user authentication (6.3)
- 非对称/传统用户身份验证（6.3）
- host address assignment and configuration (6.3)
- 主机地址分配和配置（6.3）
along with any other issues specifically related to the support of remote hosts. Currently as there are many different non-interoperable proprietary solutions in this area.
以及与远程主机支持相关的任何其他问题。目前，在这个领域有许多不同的不可互操作的专有解决方案。
A Virtual Private LAN Segment (VPLS) is the emulation of a LAN segment using Internet facilities. A VPLS can be used to provide what is sometimes known also as a Transparent LAN Service (TLS), which can be used to interconnect multiple stub CPE nodes, either bridges or routers, in a protocol transparent manner. A VPLS emulates a LAN segment over IP, in the same way as protocols such as LANE emulate a LAN segment over ATM. The primary benefits of a VPLS are complete protocol transparency, which may be important both for multiprotocol transport and for regulatory reasons in particular service provider contexts.
虚拟专用LAN段（VPLS）是使用Internet设施对LAN段进行的仿真。VPLS可用于提供有时也称为透明LAN服务（TLS）的服务，该服务可用于以协议透明的方式互连多个存根CPE节点（网桥或路由器）。VPLS通过IP模拟LAN网段，与LANE等协议通过ATM模拟LAN网段的方式相同。VPLS的主要好处是完全的协议透明性，这对于多协议传输和特定服务提供商环境中的监管原因都很重要。
10.1.1.1 +--------+ +--------+ 10.1.1.2
+---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |-----------------------| edge |-------|CPE|
+---+ stub | node | | node | stub +---+
link +--------+ +--------+ link
^ | | ^
| | --------------- | |
| | ( ) | |
| +----( IP BACKBONE )----+ |
| ( ) |
| --------------- |
| | |
|IP tunnel +--------+ IP tunnel|
| | ISP | |
+-----------| edge |-----------+
| node |
+--------+ subnet = 10.1.1.0/24
|
stub link |
|
+---+
|CPE| 10.1.1.3
+---+
10.1.1.1 +--------+ +--------+ 10.1.1.2
+---+ | ISP | IP tunnel | ISP | +---+
|CPE|-------| edge |-----------------------| edge |-------|CPE|
+---+ stub | node | | node | stub +---+
link +--------+ +--------+ link
^ | | ^
| | --------------- | |
| | ( ) | |
| +----( IP BACKBONE )----+ |
| ( ) |
| --------------- |
| | |
|IP tunnel +--------+ IP tunnel|
| | ISP | |
+-----------| edge |-----------+
| node |
+--------+ subnet = 10.1.1.0/24
|
stub link |
|
+---+
|CPE| 10.1.1.3
+---+
Figure 7.1: VPLS Example
图7.1:VPLS示例
Topologically and operationally a VPLS can be most easily modeled as being essentially equivalent to a VPRN, except that each VPLS edge node implements link layer bridging rather than network layer forwarding. As such, most of the VPRN tunneling and configuration mechanisms discussed previously can also be used for a VPLS, with the appropriate changes to accommodate link layer, rather than network layer, packets and addressing information. The following sections discuss the primary changes needed in VPRN operation to support VPLSs.
在拓扑和操作上，VPLS最容易建模为本质上等同于VPRN，除了每个VPLS边缘节点实现链路层桥接而不是网络层转发。因此，前面讨论的大多数VPRN隧道和配置机制也可以用于VPLS，并进行适当的更改以适应链路层（而不是网络层）、数据包和寻址信息。以下各节讨论支持VPLSs的VPRN操作所需的主要更改。
The tunneling protocols employed within a VPLS can be exactly the same as those used within a VPRN, if the tunneling protocol permits the transport of multiprotocol traffic, and this is assumed below.
如果隧道协议允许多协议通信量的传输，则VPLS中使用的隧道协议可以与VPRN中使用的隧道协议完全相同，这在下面假设。
A VPLS needs to have a broadcast capability. This is needed both for broadcast frames, and for link layer packet flooding, where a unicast frame is flooded because the path to the destination link layer address is unknown. The address resolution protocols that run over a bridged network typically use broadcast frames (e.g. ARP). The same set of possible multicast tunneling mechanisms discussed earlier for VPRNs apply also to a VPLS, though the generally more frequent use of broadcast in VPLSs may increase the pressure for native multicast support that reduces, for instance, the burden of replication on VPLS edge nodes.
VPLS需要具有广播功能。这对于广播帧和链路层分组泛洪都是必需的，其中单播帧被泛洪，因为到目的链路层地址的路径未知。在桥接网络上运行的地址解析协议通常使用广播帧（例如ARP）。先前针对VPRN讨论的同一组可能的多播隧道机制也适用于VPLS，尽管通常在VPLSs中更频繁地使用广播可能会增加本机多播支持的压力，从而降低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成员资格的配置类似于VPRN的配置，因为这通常只需要了解任何给定VPLS边缘节点处的本地VPN链路分配，以及VPLS中其他边缘节点的身份或路由；特别地，这种配置独立于每个VPN边缘节点处的转发的性质。因此，针对VPRN配置讨论的任何VPN成员配置和分发机制也可以应用于VPLS配置。同样与VPRN一样，通过控制每个VPLS边缘节点上对等节点的配置，可以轻松操纵VPLS的拓扑结构，前提是成员资格分发机制允许这样做。然而，为了避免两个VPLS节点之间的通信需要通过另一个VPLS节点传输，这可能需要使用生成树协议[65]来防止环路，典型的VPLS将被完全网格化。
A VPLS can support either bridges or routers as a CPE device.
VPLS可以支持网桥或路由器作为CPE设备。
CPE routers would peer transparently across a VPLS with each other without requiring any router peering with any nodes within the VPLS. The same scalability issues that apply to a full mesh topology for VPRNs, apply also in this case, only that now the number of peering routers is potentially greater, since the ISP edge device is no longer acting as an aggregation point.
CPE路由器将在VPLS之间透明地相互对等，而不需要任何路由器与VPLS内的任何节点对等。适用于VPRN的全网状拓扑的可伸缩性问题也适用于这种情况，只是现在对等路由器的数量可能更大，因为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网桥设备，广播域包括所有CPE站点以及VPL本身。在这种情况下，由于需要数据包泛洪，存在显著的可伸缩性限制，以及
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内的封装、寻址、转发和可达性协议的性质，下文将单独讨论。
In this case, packets sent to and from the VPLS across stub links are link layer frames, with a suitable access link encapsulation. The most common case is likely to be ethernet frames, using an encapsulation appropriate to the particular access technology, such as ATM, connecting the CPE bridges to the VPLS edge nodes. Such frames are then forwarded at layer 2 onto a tunnel used in the VPLS. As noted previously, this does mandate the use of an IP tunneling protocol which can transport such link layer frames. Note that this does not necessarily mandate, however, the use of a protocol identification field in each tunnel packet, since the nature of the encapsulated traffic (e.g. ethernet frames) could be indicated at tunnel setup.
在这种情况下，通过存根链路发送到VPL和从VPL发送的数据包是链路层帧，具有适当的访问链路封装。最常见的情况可能是以太网帧，使用适合于特定接入技术（例如ATM）的封装，将CPE网桥连接到VPLS边缘节点。然后在第2层将这些帧转发到VPLS中使用的隧道上。如前所述，这确实要求使用可传输此类链路层帧的IP隧道协议。注意，然而，这并不一定要求在每个隧道分组中使用协议标识字段，因为封装的通信量（例如以太网帧）的性质可以在隧道设置时指示。
In this case, typically, CPE routers send link layer packets to and from the VPLS across stub links, destined to the link layer addresses of their peer CPE routers. Other types of encapsulations may also prove feasible in such a case, however, since the relatively constrained addressing space needed for a VPLS to which only router CPE are connected, could allow for alternative encapsulations, as discussed further below.
在这种情况下，通常，CPE路由器通过存根链路向vpl发送链路层分组，并从vpl发送链路层分组，目的地为其对等CPE路由器的链路层地址。然而，在这种情况下，其他类型的封装也可能被证明是可行的，因为只有路由器CPE连接到的vpl所需的相对受限的寻址空间可以允许替代封装，如下所述。
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网段上运行，是可能的，但不太常见）。帧根据与各个主机关联的链路层地址（例如IEEE MAC地址）在VPL之间和内部转发。VPLS需要支持广播流量，例如通常用于所用地址解析机制的广播流量
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转发和可达性算法还需要能够适应洪水流量。
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路由器通过将下一跳网络层地址映射到路由器对等方的链路层地址，跨VPL传输数据包。使用链路层封装，最常见的是以太网，如桥接器。
As noted above, however, in cases where all of the CPE nodes connected to the VPLS are routers, then it may be possible, due to the constrained addressing space of the VPLS, to use encapsulations that use a different address space than normal MAC addressing. See, for instance, [11], for a proposed mechanism for VPLSs over MPLS networks, leveraging earlier work on VPRN support over MPLS [38], which proposes MPLS as the tunneling mechanism, and locally assigned MPLS labels as the link layer addressing scheme to identify the CPE LSR routers connected to the VPLS.
然而，如上所述，在连接到vpl的所有CPE节点都是路由器的情况下，由于vpl的有限寻址空间，可能使用使用不同于正常MAC寻址的地址空间的封装。例如，请参见[11]，了解针对MPLS网络上的VPLSs的建议机制，利用先前关于MPLS上的VPRN支持的工作[38]，该工作建议将MPLS作为隧道机制，并将本地分配的MPLS标签作为链路层寻址方案，以识别连接到VPLS的CPE LSR路由器。
The only practical VPLS edge node forwarding mechanism in this case is likely to be standard link layer packet flooding and MAC address learning, as per [65]. As such, no explicit intra-VPLS reachability protocol will be needed, though there will be a need for broadcast mechanisms to flood traffic, as discussed above. In general, it may not prove necessary to also implement the Spanning Tree protocol between VPLS edge nodes, if the VPLS topology is such that no VPLS edge node is used for transit traffic between any other VPLS edge nodes - in other words, where there is both full mesh connectivity and transit is explicitly precluded. On the other hand, the CPE bridges may well implement the spanning tree protocol in order to safeguard against 'backdoor' paths that bypass connectivity through the VPLS.
根据[65]，在这种情况下，唯一实用的VPLS边缘节点转发机制可能是标准链路层数据包泛洪和MAC地址学习。因此，将不需要显式的VPLS内部可达性协议，尽管如上所述，将需要广播机制来淹没流量。通常，如果VPLS拓扑结构使得任何其他VPLS边缘节点之间的传输流量都不使用VPLS边缘节点，也就是说，在存在完全网状连接且明确排除传输的情况下，可能没有必要在VPLS边缘节点之间实现生成树协议。另一方面，CPE网桥可以很好地实现生成树协议，以防止绕过通过vpl的连接的“后门”路径。
Standard bridging techniques can also be used in this case. In addition, the smaller link layer address space of such a VPLS may also permit other techniques, with explicit link layer routes between CPE routers. [11], for instance, proposes that MPLS LSPs be set up, at the insertion of any new CPE router into the VPLS, between all CPE
在这种情况下，也可以使用标准桥接技术。此外，这样的vpl的较小链路层地址空间还可以允许其他技术，在CPE路由器之间具有显式链路层路由。[11] 例如，建议在将任何新的CPE路由器插入VPLS时，在所有CPE之间建立MPLS LSP
LSRs. This then precludes the need for packet flooding. In the more general case, if stub link reachability mechanisms were used to configure VPLS edge nodes with the link layer addresses of the CPE routers connected to them, then modifications of any of the intra-VPN reachability mechanisms discussed for VPRNs could be used to propagate this information to each other VPLS edge node. This would then allow for packet forwarding across the VPLS without flooding.
LSR。这就排除了数据包泛洪的需要。在更一般的情况下，如果使用存根链路可达性机制来配置具有连接到它们的CPE路由器的链路层地址的VPLS边缘节点，则可以使用针对VPRNs讨论的任何VPN内可达性机制的修改来将该信息传播到彼此的VPLS边缘节点。这将允许在VPL之间进行数据包转发，而不会导致泛洪。
Mechanisms could also be developed to further propagate the link layer addresses of peer CPE routers and their corresponding network layer addresses across the stub links to the CPE routers, where such information could be inserted into the CPE router's address resolution tables. This would then also preclude the need for broadcast address resolution protocols across the VPLS.
还可以开发机制来进一步将对等CPE路由器的链路层地址及其对应的网络层地址跨存根链路传播到CPE路由器，其中可以将此类信息插入到CPE路由器的地址解析表中。这样也就不需要跨VPL使用广播地址解析协议。
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.
显然，如果跨VPL确定了显式链路层路由，就不需要支持生成树协议。如果使用正常的泛洪机制，则仅当全网状连接不可用时才需要生成树，因此VPLS节点必须承载过境流量。
There is significant commonality between VPRNs and VPLSs, and, where possible, this similarity should be exploited in order to reduce development and configuration complexity. In particular, VPLSs should utilize the same tunneling and membership configuration mechanisms, with changes only to reflect the specific characteristics of VPLSs.
VPRNs和VPLSs之间有着显著的共性，在可能的情况下，应该利用这种相似性来降低开发和配置的复杂性。特别是，VPLSs应使用相同的隧道和成员配置机制，更改仅反映VPLSs的特定特征。
In this document different types of VPNs have been discussed individually, but there are many common requirements and mechanisms that apply to all types of VPNs, and many networks will contain a mix of different types of VPNs. It is useful to have as much commonality as possible across these different VPN types. In particular, by standardizing a relatively small number of mechanisms, it is possible to allow a wide variety of VPNs to be implemented.
在本文档中，已分别讨论了不同类型的VPN，但有许多通用需求和机制适用于所有类型的VPN，并且许多网络将混合使用不同类型的VPN。在这些不同的VPN类型中尽可能多地具有通用性是很有用的。特别是，通过标准化相对较少的机制，可以实现多种VPN。
The benefits of adding support for the following mechanisms should be carefully examined.
应仔细研究为以下机制添加支持的好处。
For IKE/IPSec:
对于IKE/IPSec：
- the transport of a VPN-ID when establishing an SA (3.1.2)
- 建立SA时VPN-ID的传输（3.1.2）
- a null encryption and null authentication option (3.1.3)
- 空加密和空身份验证选项（3.1.3）
- multiprotocol operation (3.1.4)
- 多协议操作（3.1.4）
- frame sequencing (3.1.5)
- 帧排序（3.1.5）
- asymmetric / legacy user authentication (6.3)
- 非对称/传统用户身份验证（6.3）
- host address assignment and configuration (6.3)
- 主机地址分配和配置（6.3）
For L2TP:
对于L2TP：
- defining modes of operation of IPSec when used to support L2TP (3.2)
- 定义用于支持L2TP（3.2）时IPSec的操作模式
For VPNs generally:
对于VPN，通常：
- defining a VPN membership information configuration and dissemination mechanism, that uses some form of directory or MIB (5.3.2)
- 定义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.
- 确保开发的解决方案尽可能适用于不同类型的VPN，而不是特定于单一类型的VPN。
Security considerations are an integral part of any VPN mechanisms, and these are discussed in the sections describing those mechanisms.
安全考虑是任何VPN机制不可分割的一部分，在描述这些机制的章节中讨论了这些问题。
Thanks to Anthony Alles, of Nortel Networks, for his invaluable assistance with the generation of this document, and who developed much of the material on which early versions of this document were based. Thanks also to Joel Halpern for his helpful review comments.
感谢Nortel Networks的Anthony Alles，感谢他在编写本文档时提供的宝贵帮助，感谢他开发了本文档早期版本所依据的大部分材料。还要感谢Joel Halpern提供的有用的评论。
[1] ATM Forum. "LAN Emulation over ATM 1.0", af-lane-0021.000, January 1995.
[1] ATM论坛。“ATM 1.0上的局域网仿真”，af-lane-0021.000，1995年1月。
[2] ATM Forum. "Multi-Protocol Over ATM Specification v1.0", af-mpoa-0087.000, June 1997.
[2] ATM论坛。“ATM多协议规范v1.0”，af-mpoa-0087.000，1997年6月。
[3] Ferguson, P. and Huston, G. "What is a VPN?", Revision 1, April 1 1998; http://www.employees.org/~ferguson/vpn.pdf.
[3] Ferguson，P.和Huston，G.“什么是VPN？”，第1版，1998年4月1日；http://www.employees.org/~ferguson/vpn.pdf。
[4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[4] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[6] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[7] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[7] Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“通用路由封装（GRE）”，RFC 17011994年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] 汤斯利，W.，巴伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[9] Rosen, E., et al., "Multiprotocol Label Switching Architecture", Work in Progress.
[9] Rosen，E.等人，“多协议标签交换体系结构”，正在进行中。
[10] Heinanen, J., et al., "MPLS Mappings of Generic VPN Mechanisms", Work in Progress.
[10] Heinanen，J.等人，“通用VPN机制的MPLS映射”，正在进行中。
[11] Jamieson, D., et al., "MPLS VPN Architecture", Work in Progress.
[11] Jamieson，D.等人，“MPLS VPN架构”，正在进行中。
[12] Casey, L., et al., "IP VPN Realization using MPLS Tunnels", Work in Progress.
[12] Casey，L.等人，“使用MPLS隧道实现IP VPN”，正在进行的工作。
[13] Li, T. "CPE based VPNs using MPLS", Work in Progress.
[13] Li，T.“使用MPLS的基于CPE的VPN”，正在进行中。
[14] Muthukrishnan, K. and A. Malis, "Core MPLS IP VPN Architecture", Work in Progress.
[14] Muthukrishnan，K.和A.Malis，“核心MPLS IP VPN架构”，正在进行中。
[15] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[15] Rosen，E.和Y.Rekhter，“BGP/MPLS VPN”，RFC 2547，1999年3月。
[16] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[16] Fox，B.和B.Gleeson，“虚拟专用网络标识符”，RFC 26851999年9月。
[17] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM Forum, af-mpoa-0129.000.
[17] Petri，B.（编辑）“MPOA v1.1 VPN支持附录”，ATM论坛，af-MPOA-0129.000。
[18] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[18] Harkins，D.和C.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[19] Calhoun, P., et al., "Tunnel Establishment Protocol", Work in Progress.
[19] Calhoun，P.等人，“隧道建立协议”，正在进行的工作。
[20] Andersson, L., et al., "LDP Specification", Work in Progress.
[20] Andersson，L.等人，“LDP规范”，正在进行的工作。
[21] Jamoussi, B., et al., "Constraint-Based LSP Setup using LDP" Work in Progress.
[21] Jamoussi，B.等人，“使用LDP的基于约束的LSP设置”正在进行中。
[22] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", Work in Progress.
[22] Awduche，D.等人，“LSP隧道RSVP的扩展”，正在进行的工作。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.
[23] Kent，S.和R.Atkinson，“IP封装安全协议（ESP）”，RFC 2406，1998年11月。
[24] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[24] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995.
[25] Perez，M.，Liaw，F.，Mankin，A.，Hoffman，E.，Grossman，D.和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[26] Malkin, G. "RIP Version 2 Carrying Additional Information", RFC 1723, November 1994.
[26] Malkin，G.“携带附加信息的RIP版本2”，RFC 1723，1994年11月。
[27] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[27] Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[28] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[28] Shacham，A.，Monsour，R.，Pereira，R.和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 23931998年12月。
[29] Duffield N., et al., "A Performance Oriented Service Interface for Virtual Private Networks", Work in Progress.
[29] Duffield N.等人，“面向性能的虚拟专用网络服务接口”，正在进行中。
[30] Jacobson, V., Nichols, K. and B. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[30] Jacobson，V.，Nichols，K.和B.Poduri，“快速转发PHB”，RFC 25981999年6月。
[31] Casey, L., "An extended IP VPN Architecture", Work in Progress.
[31] Casey，L.，“扩展IP VPN架构”，正在进行中。
[32] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[32] Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 1771，1995年3月。
[33] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[33] Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[34] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[34] Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[35] Boyle, J., et al., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[35] Boyle，J.等人，《共同开放政策服务协议》，RFC 2748，2000年1月。
[36] MacRae, M. and S. Ayandeh, "Using COPS for VPN Connectivity" Work in Progress.
[36] MacRae，M.和S.Ayandeh，“使用COP进行VPN连接”的工作正在进行中。
[37] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[37] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[38] Heinanen, J. and E. Rosen, "VPN Support with MPLS", Work in Progress.
[38] Heinanen，J.和E.Rosen，“MPLS支持VPN”，正在进行中。
[39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[39] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[40] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[40] Waitzman，D.，Partridge，C.和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[41] Fenner, W., "IGMP-based Multicast Forwarding (IGMP Proxying)", Work in Progress.
[41] Fenner，W.，“基于IGMP的多播转发（IGMP代理）”，正在进行中。
[42] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[42] Wallner，D.，Harder，E.和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1999年6月。
[43] Hardjono, T., et al., "Secure IP Multicast: Problem areas, Framework, and Building Blocks", Work in Progress.
[43] Hardjono，T.等人，“安全IP多播：问题领域、框架和构建块”，正在进行的工作。
[44] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[44] Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[45] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[45] Valencia，A.，Littlewood，M.和T.Kolar，“思科第二层转发（协议）“L2F”，RFC 23411998年5月。
[46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[46] Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[47] Patel, B., et al., "Securing L2TP using IPSEC", Work in Progress.
[47] Patel，B.等人，“使用IPSEC保护L2TP”，正在进行中。
[48] Srisuresh, P., "Secure Remote Access with L2TP", Work in Progress.
[48] Srisuresh，P.，“L2TP的安全远程访问”，正在进行中。
[49] Calhoun, P., et al., "Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IP networks", Work in Progress.
[49] Calhoun，P.等人，“第二层隧道协议”L2TP“非IP网络的安全扩展”，正在进行中。
[50] Aboba, B. and Zorn, G. "Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS", Work in progress.
[50] Aboba，B.和Zorn，G.“通过半径实施PPTP/L2TP强制隧道”，正在进行的工作。
[51] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[51] Aboba，B.和G.Zorn，“评估漫游协议的标准”，RFC 2477，1999年1月。
[52] Shea, R., "L2TP-over-IP Path MTU Discovery (L2TPMTU)", Work in Progress.
[52] Shea，R.，“L2TP-over-IP路径MTU发现（L2TPMTU）”，正在进行中。
[53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[53] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[54] Richards, C. and K. Smith, "The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)", RFC 2125, March 1997.
[54] Richards，C.和K.Smith，“PPP带宽分配协议（BAP）PPP带宽分配控制协议（BACP）”，RFC 21251997年3月。
[55] Calhoun, P. and K. Peirce, "Layer Two Tunneling Protocol "L2TP" IP Differential Services Extension", Work in Progress.
[55] Calhoun，P.和K.Peirce，“第二层隧道协议”L2TP“IP差分服务扩展”，工作正在进行中。
[56] ADSL Forum. "An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0)", ADSL Forum 97- 215.
[56] ADSL论坛。“ADSL系统上可互操作的端到端宽带服务架构（3.0版）”，ADSL论坛97-215。
[57] ADSL Forum. "Core Network Architectures for ADSL Access Systems (Version 1.01)", ADSL Forum 98-017.
[57] ADSL论坛。“ADSL接入系统的核心网络架构（1.01版）”，ADSL论坛98-017。
[58] Gupta, V., "Secure, Remote Access over the Internet using IPSec", Work in Progress.
[58] Gupta，V.，“使用IPSec通过互联网进行安全、远程访问”，正在进行中。
[59] Pereira, R., et al., "The ISAKMP Configuration Method", Work in Progress.
[59] Pereira，R.等人，“ISAKMP配置方法”，正在进行中。
[60] Pereira, R. and S. Beaulieu, "Extended Authentication Within ISAKMP/Oakley", Work in Progress.
[60] Pereira，R.和S.Beaulieu，“ISAKMP/Oakley中的扩展认证”，正在进行中。
[61] Litvin, M., et al., "A Hybrid Authentication Mode for IKE", Work in Progress.
[61] Litvin，M.等人，“IKE的混合认证模式”，正在进行中。
[62] Kelly, S., et al., "User-level Authentication Mechanisms for IPsec", Work in Progress.
[62] Kelly，S.等人，“IPsec的用户级身份验证机制”，正在进行中。
[63] Patel, B., et al., "DHCP Configuration of IPSEC Tunnel Mode", Work in Progress.
[63] Patel，B.等人，“IPSEC隧道模式的DHCP配置”，正在进行中。
[64] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[64] Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[65] ANSI/IEEE - 10038: 1993 (ISO/IEC) Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges, ANSI/IEEE Std 802.1D, 1993 Edition.
[65] ANSI/IEEE-10038:1993（ISO/IEC）信息技术-系统间电信和信息交换-局域网-媒体访问控制（MAC）网桥，ANSI/IEEE标准802.1D，1993年版。
Bryan Gleeson Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
布莱恩·格雷森北电网络4500美国加州圣克拉拉大美洲大道95054
Phone: +1 (408) 548 3711
EMail: bgleeson@shastanets.com
Phone: +1 (408) 548 3711
EMail: bgleeson@shastanets.com
Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland
Juha Heinanen Telia Finland，Inc.Myyrmaentie 2 01600 VANTAA Finland
Phone: +358 303 944 808
EMail: jh@telia.fi
Phone: +358 303 944 808
EMail: jh@telia.fi
Arthur Lin Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA
Arthur Lin Nortel Networks 4500美国加州圣克拉拉大美洲大道95054号
Phone: +1 (408) 548 3788
EMail: alin@shastanets.com
Phone: +1 (408) 548 3788
EMail: alin@shastanets.com
Grenville Armitage Bell Labs Research Silicon Valley Lucent Technologies 3180 Porter Drive, Palo Alto, CA 94304 USA
格雷维尔·阿米蒂奇·贝尔实验室研究硅谷朗讯科技公司美国加利福尼亚州帕洛阿尔托波特大道3180号，邮编94304
EMail: gja@lucent.com
EMail: gja@lucent.com
Andrew G. Malis Lucent Technologies 1 Robbins Road Westford, MA 01886 USA
Andrew G.Malis Lucent Technologies美国马萨诸塞州韦斯特福德罗宾斯路1号01886
Phone: +1 978 952 7414
EMail: amalis@lucent.com
Phone: +1 978 952 7414
EMail: amalis@lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。