L2F also arose in the early stages of VPN development. Like PPTP, L2F was designed as a protocol for tunneling traffic from users to their corporate sites. One major difference between PPTP and L2F is that, because L2F tunneling is not dependent on IP, it is able to work directly with other media, such as frame relay or asynchronous transfer mode (ATM). Like PPTP, L2F uses PPP for authentication of the remote user, but it also includes support for terminal access controller access control system (TACACS)+ and RADIUS for authentication. L2F also differs from PPTP in that it allows tunnels to support more than one connection.

Paralleling PPTP's design, L2F utilized PPP for authentication of the dial-up user, but it also included support for TACACS+ and RADIUS for authentication from the beginning. L2F differs from PPTP because it defines connections within a tunnel, allowing a tunnel to support more than one connection. There are also two levels of authentication of the user, first by the ISP prior to setting up the tunnel and then when the connection is set up at the corporate gateway. Because L2TP is a layer-2 protocol, it offers users the same flexibility as PPTP for handling protocols other than IP, such as IPX and NetBEUI.

L2TP is being designed by an IETF working group as the heir apparent to PPTP and L2F, designed to address the shortcomings of these past protocols and become an IETF–approved standard. L2TP uses PPP to provide dial-up access that can be tunneled through the Internet to a site. However, L2TP defines its own tunneling protocol, based on the work done on L2F. L2TP transport is being defined for a variety of packet media, including X.25, frame-relay and ATM. To strengthen the encryption of the data it handles, L2TP uses IPSec's encryption methods.

Because it uses PPP for dial-up links, L2TP includes the authentication mechanisms within PPP, namely PAP and CHAP. Similar to PPTP, L2TP supports PPP's use of the extensible authentication protocol for other authentication systems, such as RADIUS. PPTP, L2F, and L2TP all do not include encryption or processes for managing the cryptographic keys required for encryption in their specifications. The current L2TP draft standard recommends that IPSec be used for encryption and key management in IP environments; future drafts of the PPTP standard may do the same.

The last, but perhaps most important protocol, IPSec, grew out of efforts to secure IP packets as the next generation of IP (IPv6) was being developed; it can now be used with IPv4 protocols as well. Although the requests for comment (RFCs) defining the IPSec protocols have already been part of the IETF's standards track since mid-1995, the protocols are still being refined as engineers learn more as more products appear in the marketplace. The question of which methods to employ for exchanging and managing the cryptographic keys used to encrypt session data has taken more than a year to answer. This challenge has been largely resolved and the ISAKMP/Oakley scheme (now also called Internet key exchange [IKE]) is being readied for acceptance as an IETF standard.

IPSec allows the sender (or a security gateway acting on his behalf) to authenticate or encrypt each IP packet or apply both operations to the packet. Separating the application of packet authentication and encryption has led to two different methods of using IPSec, called modes. In transport mode, only the transport-layer segment of an IP packet is authenticated or encrypted. The other approach, authenticating or encrypting the entire IP packet, is called tunnel mode. While transport-mode IPSec can prove useful in many situations, tunnel-mode IPSec provides even more protection against certain attacks and traffic monitoring that might occur on the Internet.

IPSec is built around a number of standardized cryptographic technologies to provide confidentiality, data integrity, and authentication. For example, IPSec uses:

• Diffie-Hellman key exchanges to deliver secret keys between peers on a public net
• public-key cryptography for signing Diffie-Hellman exchanges, to guarantee the identities of the two parties and avoid man-in-the-middle attacks
• data encryption standard (DES) and other bulk encryption algorithms for encrypting data
• keyed hash algorithms (HMAC, MD5, SHA) for authenticating packets
• digital certificates for validating public keys

There are currently two ways to handle key exchange and management within IPSec's architecture: manual keying and IKE for automated key management. Both of these methods—manual keying and IKE—are mandatory requirements of IPSec. While manual key exchange might be suitable for a VPN with a small number of sites, VPNs covering a large number of sites or supporting many remote users benefit from automated key management.

IPSec is often considered the best VPN solution for IP environments, as it includes strong security measures—notably encryption, authentication, and key management—in its standards set. Because IPSec is designed to handle only IP packets, PPTP and L2TP are more suitable for use in multiprotocol non–IP environments, such as those using NetBEUI, IPX, and AppleTalk.