Virtual private network

See also: Tunneling protocol

See also: Cloud computing

A virtual private network (VPN) is a set of sites, owned by customers, which 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.

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.

Sites connect to the "(inter-site) backbone" through customer edge (CE) devices or functions, which 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. 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. It is a wise provider that arms its sales personnel with a set of basic questions to determine the customer requirement.

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. 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.

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) or Open Shortest Path First (OSPF)