Virtual private network: Difference between revisions
imported>Howard C. Berkowitz No edit summary |
imported>Howard C. Berkowitz No edit summary |
||
| Line 30: | Line 30: | ||
Initially, think of the sites speaking to the backbone through some mutually agreed [[protocol (computer)|protocol]]; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are '''tunneled''' through the provider backbone. | Initially, think of the sites speaking to the backbone through some mutually agreed [[protocol (computer)|protocol]]; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are '''tunneled''' through the provider backbone. | ||
===Site connectivity=== | |||
Sites connect to the "(inter-site) backbone" through '''customer edge (CE)''' devices or functions. The CE need not be a physicial device. In a customer-provided VPN, the customer manages connectivity among the CE. | |||
===Provider provisioning=== | |||
[[Image:PPVPN, 2 VPN, no P.png|thumb|250 px|Two VPNs via provider facilities]] | |||
In a provider-provisioned VPN, the CE provide reachability information to '''provider edge (PE)''' devices or functions that are aware of both the VPN, and the provider backbone onto which the VPNs are mapped. Again, a PE need not be a physical device. The PEs are aware of the VPNs, but also of the interconnection of PEs, which is hidden from the customers. | |||
Internal to the provider backbone may be '''provider (P)''' devices or functions that maintain connectivity in the provider backbone, but are themselves unaware of the VPNs. | |||
==Administrative scope== | ==Administrative scope== | ||
Revision as of 21:59, 13 March 2010
- See also: Tunneling protocol
- See also: Cloud computing
A virtual private network (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..." [1]
In almost all cases, however, a VPN is an overlay network onto a lower-level connectivity network, such as the Internet, a non-public set of IP nodes over a private routed network, or IP over on-demand services such as dialup.
Often, a VPN is a service; a set of sites, owned by customers are connected through some type of backbone. The backbone is operated by a service provider, who provides VPN service to the customers. A customer may be a single enterprise, a set of enterprises, an Internet Service Provider (ISP), an Application Service Provider (ASP), another SP that offers the same kind of VPN service to its own customers (i.e., a VPN "wholesaler"), etc. [2]
Initially, think of the sites speaking to the backbone through some mutually agreed protocol; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are tunneled through the provider backbone.
Site connectivity
Sites connect to the "(inter-site) backbone" through customer edge (CE) devices or functions. The CE need not be a physicial device. In a customer-provided VPN, the customer manages connectivity among the CE.
Provider provisioning
In a provider-provisioned VPN, the CE provide reachability information to provider edge (PE) devices or functions that are aware of both the VPN, and the provider backbone onto which the VPNs are mapped. Again, a PE need not be a physical device. The PEs are aware of the VPNs, but also of the interconnection of PEs, which is hidden from the customers.
Internal to the provider backbone may be provider (P) devices or functions that maintain connectivity in the provider backbone, but are themselves unaware of the VPNs.
Administrative scope
If all the sites are under the control of a single network administration authority, such as an enterprise, the VPN is called an intranet. If the sites are under the control of multiple administrators that have agreed to technical and operational policies, the VPN is called an extranet.
While it might seem counterintuitive, the global Internet is under the control of multiple administrators that agree to exchange reachability to a set of addresses under the authority of the Internet Assigned Numbers Authority (IANA), using the Border Gateway Protocol. Returning to the idea of a SP backbone, a number of large SPs are treating their customers' public Internet connectivity as "just another VPN", yet one that is totally isolated from the intranets and extranets.
Backbone provider
Customer organizations may have a network support group that runs an SP backbone, through which multiple, administratively isolated, VPNs can run. For example, an enterprise with multiple physical sites, connected by satellite links, might have separate VPNs for finance, manufacturing, research, and human resources. When a backbone is administered in this manner, the VPNs are called customer-provisioned VPNs (CPVPN).
It is possible and common to have CPVPNs tunnel among customer sites using a secure tunneling protocol, such as IPSec, over physical connections to Internet Service Providers. The ISP, in such cases, will be completely unaware of the VPNs.
Alternatively, the enterprise(s) can contract with a SP to operate the VPNs. The customer needs to tell the SP how many isolated VPNs are needed, the address spaces that each will use, and the quality of service, availability, and bandwidth that will be required. In this case, if the customer has no involvement in the SP backbone, the VPNs are called provider-provisioned VPNs (PPVPN)s.[3] It is a wise provider that arms its sales personnel with a set of basic questions to determine the customer requirement. [4]
There are many situations where a given enterprise, or set of enterprises forming an extranet, may use a combination of CPVPNs and PPVPNs.
Connectivity to the CE and PE
While the first VPNs used Internet Protocol version 4 (IPv4) for connectivity to the CE if the CE was an onsite physical device operated by the SP, or from the CE to the PE if the CE belongs to the customer, the VPN is not limited to running as a routed network. In a given environment, there may be:
- Routed (OSI Layer 3) VPNs using IPv4 or Internet Protocol version 6 (IPv6). IPv4 address space is becoming scarce, so a very practical application may be to run IPv4 VPNs over an IPv6 backbone; only CEs and PEs would need to support IPv6.
- Layer 2 VPNs (L2VPN), which present frame relay or Asynchronous Transfer Mode (ATM) interfaces to the customer equipment.[5] This is very useful to keep supporting old equipment that only has FR or ATM interfaces. "Layer 2.5" VPNs can present Multi-Protocol Label Switching (MPLS) interfaces to customer-owned equipment that understands that protocol; even commercial FR and ATM services frequently run over MPLS internal to the SP backbone. It is also possible for the VPN to run a local area network protocol such as IEEE 802.3 or a virtual LAN protocol such as IEEE 802.1Q.
- Layer 1 VPNs, where the VPN interface appears as an 802.3 or serial communications interface that accepts bit streams.[6]
Some L2 offerings are called virtual private LAN service, while other L1 offerings are called virtual private line service, both having the abbreviation VPLS. Using L2VPN and L1VPN is much less likely to lead to confusion.
L2VPNs and L1VPNs usually need a routing protocol to pass VPN administration information, although there are provider-provisioned autodiscovery mechanisms that will isolate the customer from this requirement.
Communicating policies and reachability between customer and provider
Depending on the type of VPN in use, the customer may run a routing protocol internal to the customer sites, of which the SP need not be aware.
If the customer needs to tell the PE what VPNs exist, what address spaces each support, and even if there are restrictions on connectivity within a single VPN, then this needs to be manually configured, which is maintenance-intensive, or the information can be sent through extensions to a routing protocol such as the Border Gateway Protocol (BGP)[2] or Open Shortest Path First (OSPF) [5]
References
- ↑ B. Gleeson, A. Lin, J. Heinanen, G. Armitage & A. Malis (February 2000), A Framework for IP Based Virtual Private Networks, Internet Engineering Task Force, RFC2764
- ↑ 2.0 2.1 Rosen, E. and Rekhter, Y. (February 2006), BGP/MPLS IP Virtual Private Networks (VPNs), Internet Engineering Task Force, RFC4364
- ↑ Andersson L. and Madsen T. (March 2005), Provider Provisioned Virtual Private Network (VPN) Terminology, Internet Engineering Task Force, RFC4026
- ↑ Berkowitz, H. (May 23-25, 1999), So Your Customer Wants a VPN From You, North American Network Operators Group
- ↑ 5.0 5.1 Rosen E. and Andersson L., ed. (September 2006), Framework for Layer 2 Virtual Private Networks (L2VPNs), Internet Engineering Task Force, RFC4664 Cite error: Invalid
<ref>tag; name "rfc4577" defined multiple times with different content - ↑ Takeda, T., ed. (September 2006), Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode, Internet Engineering Task Force, RFC5253