Virtual Private Networks

The Internet has become for most corporations, campuses, and other isolated networks a shared infrastructure to provide connectivity for their mobile workers or to interconnect distributed locations. Private networks over a shared infrastructure have been deployed since the infancy of the Internet and even before with proprietary protocols or standards such as X.25. After all, 20 years ago, one could dial from home in to his corporate network and upload or download data. What has changed is the virtualization of the links providing the connectivity. Furthermore, the method used for sharing these logical links has moved up from layer 1 (using Time Division Multiplexing, TDM) to layer 2 (X.25, Frame Relay, or ATM Virtual Circuits) to layer 3 (PPP IP tunnels).

While so many corporate networks started to use this shared infrastructure, they inevitably started to worry about security. Their sensitive data is being exposed to others on the shared links. Their hosts and servers, connected to a public shared network, can be reached from anywhere by anybody, including malicious hackers.

The VPN technology enables telecommuters to connect to their office network (and enterprises to connect their sites together) over a public infrastructure. It has mechanisms that offer security and quality of service.

For a complete and detailed presentation on this topic, refer to VPN Applications Guide by David McDysan, and MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard.

A review of the reasons for deploying IPv4 VPNs is a useful step toward analyzing whether the concept of VPN applies to IPv6 networks. Here is a nonexhaustive list of some of the VPN benefits, whether real or perceived as such:

• Cost savings The Internet has become so ubiquitous, almost everybody can plug into it, potentially enabling connectivity with everybody else. Because it is geographically spread everywhere, corporate users do not need anymore to dial long distance to reach remote corporate resources.

• Extended connectivity This is the concept of distributed and dynamic "closed user groups," where the VPN includes various networks with different privileges and excludes others. In a controlled way, this can include telecommuters and temporary users such as customers, partners, and so on.

• Easy address-allocation process Addresses can be allocated from the IPv4 private address range. There is no need to coordinate the allocation through a control organism as long as the communications stay in the VPN.

• Simplification of the renumbering process Private addresses are less sensitive to external events, such as public addressing changes.

• Services VPN can be used to deploy services not offered by the public network on a general scale.

• Security VPNs have some built-in mechanisms to provide secure communications over the public infrastructure. One could argue that the deployment of VPNs is creating the problem that it then claims to solve. A bit of a sophism here!

• Privacy The internal addresses are private to some extent because they are not published outside the private infrastructure.

• Growth options Using small roads to interconnect remote sites makes it difficult to transport a lot of traffic when needed. Using shared highways provides opportunities to grow and to handle peaks as needed.

• Address-depletion protection Some big organization might need more addresses than the IANA is ready to give up. VPNs enable it to use private address space and not worry about exposing these addresses over the public network.

Out of these benefits provided by VPN, some are perceived benefits, in the sense that they are not directly provided by VPN technologies. The protection against address depletion, for instance, is in fact achieved through NAT. Nodes in a private site are likely to require public resources access and will need public addresses to do so. To limit the number of these public addresses required, some other technology is needed, to expose a public address on these nodes behalf (one for many). This can be NAT or an application proxy.

So, are VPNs still useful with IPv6? The question is worth asking. Why would IPv6 customers ever need to deploy VPNs when they can get all the addresses they want? Why split the global address space into smaller chunks, if it is guaranteed that none of these addresses will ever overlap? In an ideal world full of honest people, that is probably true. This is precisely what VPN technology does not assume. It does not deal with issues of overlapping address space, but rather intends to isolate address spaces, and communications, to protect against malicious users. With IPv4, address-space overlapping simply becomes a by-product of VPN and NAT.

VPN is not about addressing. It is about security and policing: security of data, achieved through encryption, and policing of routing, achieved by routing domain isolation. From these perspectives, IPv6 and IPv4 are the same: identical requirements that lead to similar solutions. VPNs are still useful in IPv6 networks.

However, IPv6 differs from IPv4 for two reasons that have consequences on IPv6 VPN deployments. First, the IPv6 address space is large enough to allow address uniqueness, even across private networks. Second, by design, IPv6 does not support NAT. These differences do not drive fundamental requirement or technology divergence. But, they do have some consequences in various deployment scenarios. Chapter 7, "VPN IPv6 Architecture and Services," reviews IPv6 VPN technologies in detail and addresses the differences with IPv4. Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network," provides in-depth VPN deployment hints.