PPP and PPP over Ethernet

The first protocol used for carrying IP packets over dial-up lines was Serial Line IP (SLIP). SLIP is an almost embarrassingly simple protocol. Basically, you send packets down a serial link delimited with special END characters (0xC0). Because the END character might appear in the data stream, there is an escape character to signal that a sequence of 0xDB, 0xDC should be translated back to an END character at the other end of the link. Finally, if there is an escape (0xDB) character in the input data, the special 0xDB, 0xDD sequence indicates that the output should be the escape character only. This is all there is to SLIP.

SLIP doesn't do a number of desirable things that data-link protocols can do. It's customary (and when connecting lines are noisy , essential) to perform error checking at layer 2. It's commonly desirable to authenticate users who are dialing in to an access router. Two computers connected with a serial link may want to pass traffic formed with protocols other than IP. Because it deals with these issues, the Point-to-Point Protocol (PPP) has become the predominant protocol for modem-based access to the Internet. Furthermore, a multilink version of PPP is the most common ISDN access protocol; it is also employed for inverse multiplexing analog phone lines. And even on high-speed optical lines, PPP is the protocol of choice for those who want to disintermediate ATM on point-to-point links.

PPP is one of the many variants of an early, internationally standardized data-link protocol known as the High-level Data Link Protocol (HDLC). HDLC was derived from a proprietary protocol developed by IBM called the Synchronous Data Link Protocol (SDLC).

The HDLC-derived parts of PPP are its frame definition and its ability to support asynchronous data streams (that is, those with start and stop bits) and byte-synchronous data streams, as well as the most commonly encountered bit-synchronous data. The HDLC frame is shown in Figure 1. The Frame Check Sequence (FCS) field in an HDLC frame provides the potential for layer-2 error checking, one of the significant missing capabilities in SLIP. The two-byte Protocol field permits the identification of a layer-3 protocol in the payload, thus providing part of the necessary capability for multiprotocol support.

Figure 1: PPP frames are composed of six fields. The flag is a fixed pattern that delimits frames. The Address and Control fields are also fixed values. The Protocol field provides a layer of indirection so that the Data field can represent actions as well as user data. The Frame Check Sequence (FCS) field provides 16- or 32-bit error tracking.

LCP And NC

The protocols that differentiate PPP from HDLC are the Link Control Protocol (LCP) and the Network Control Protocol (NCP). LCP establishes, configures, maintains, and terminates point-to-point links. It kicks in before any data transfer operations can begin. The protocol opens the connection, negotiates the configuration details of the link, and passes a configuration acknowledgment frame. LCP can also optionally test link quality prior to data transmission. User authentication is generally performed by LCP as soon as the link is established. Finally, LCP tears down connections when a session is finished.

LCP supports two authentication protocols, the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP sends a password across the link in the clear, so the circumstances where it can play a useful role are seriously limited. CHAP, at least in principal, has the ability to provide reliable, secure authentication.

For CHAP, the authenticator and the authenticatee share a secret, typically a password. However, unlike PAP, the password never goes over the link. Instead, the authenticator sends the authenticatee a "challenge" in the form of a random number. The authenticatee uses the challenge number and the secret to create a "hash," a message digest unique to the challenge, by means of mathematical functions that are difficult to apply inversely and thereby derive the secret.

The message digest is then transmitted to the authenticator, who applies the same algorithms to the secret and the challenge. If the results of this local operation match the value of the transmitted message digest, then the authenticator acknowledges that the authenticatee has been successfully authenticated, and the next connection stage can proceed.

Though CHAP is a much more credible authentication method than PAP, it's not perfect. Like other "shared secret" arrangements, the secret must be conveyed via a parallel communications channel. Thus, potentially onerous administrative procedures are necessary, and in many cases new authenticatees can't be set up immediately. Furthermore, Message Digest 5 (MD5), the prevalent technology for CHAP, has recently been subject to unexpectedly rapid brute force attacks.

With an established, authenticated link, NCP takes over. PPP has specific layer-3 protocol support for IPX, SNA, DECnet, Banyan VINES, and AppleTalk, as well as IP. One typical IP-specific function is the provision of dynamic IP addresses for remote dial-in users. ISPs commonly employ this PPP feature to assign temporary IP addresses to their modem-based customers.

The IP-specific NCP protocol is the IP Control Protocol (IPCP). Aside from dealing with the calling peer's IP address, this protocol can also negotiate whether or not to use header compression, providing a significant speed improvement for low-speed links. If the calling peer has an IP address, it tells the called peer what it is; if the calling peer doesn't have an IP address, the called peer can assign the caller one from a pool of addresses.

The PPP mechanism is not as complete as DHCP, which can set up a lease period and provide such things as subnet masks, default router addresses, DNS server addresses, domain names , and much more to a newly connected computer. An ISP or other provider of remote connectivity services can use DHCP as the source of IP addresses that NCP hands out.

A Multilink PPP (MP) session begins with an LCP negotiation that determines that both ends of the link have the ability to support MP. The protocol supports independent authentication of multiple links. In effect, an MP layer interspersed between the Network layer and PPP is created.

PPP Over Ethernet

It's common for small offices or home users to want to share an Internet or enterprise access link. The sharing urge is particularly strong with high-speed lines like Digital Subscriber Line (DSL). (I'll leave cable modems out of the discussion because they don't use point-to-point links.) DSLs don't particularly cry out for PPP because of customer need to configure IP addresses at connect timeafter all, DSL is generally configured as an "always on" service. Nor is the multilink support likely to be especially valuable , as the throughput capacity is typically high enough to push the most significant bottlenecks elsewhere on the network.

A typical DSL network looks like Figure 2. On the customer premises, there is an Ethernet network, which connects to an Ethernet port on the DSL modem. The modem acts as a MAC layer bridge, relaying traffic to a DSL Access Multiplexer (DSLAM) in a phone company's central office over an ATM Permanent Virtual Circuit (PVC). From the central office to an ISP or an enterprise facility, the connection may continue to run over ATM, or it may be converted to frame relay or a leased line TDM protocol for slower-speed links.

Figure 2: Practically every Digital Subscriber Line (DSL) modem uses ATM to link to a DSL Access Multiplexer (DSLAM) at the central office of a Local Exchange Carrier (LEC). In many cases, ATM Permanent Virtual Circuits (PVC) will be provisioned all the way from an ISP or an enterprise network to the DSL modem at the customer premises.

The main problems pushing PPP over Ethernet (PPPoE) adoption include the shortage of IP addresses and the problem of connecting multiple users on a network efficiently through a shared DSL. There are multiple potential solutions, but a number of major ISPs and product manufacturers are convinced that PPPoE offers the best combination of parsimony with IP addresses, easy configuration, efficient use of the ATM network, and low-cost customer premises equipment.

ISPs typically have a limited number of IP addresses. When these scarce resources can be pooled and shared among users who dial in and stay online for an hour or two, the ISP can get by with fewer addresses than it can with fixed-address, always-on customers.

In fact, DHCP doesn't really accomplish much with DSL customers who leave their computers on all the timeDHCP leases automatically renew themselves as their expiration time approaches. So one principal thing PPPoE does is emulate the dial-up networking experience, in the sense that you can log off from Internet connectivity even though the computer remains on.

PPPoE maps individual PPP sessions onto Ethernet-connected computers. Thus, each user gets his or her own IP address, if only for the duration of a session. The alternatives to this approach have worse problems: Customer premises Network Address Translation (NAT) software is getting easier to use all the time but is nevertheless too esoteric for ordinary mortals , and static IP addresses are perhaps too precious to be tied up around the clockunless users are willing to pay extra for them.

If multiple Ethernet clients need to access the DSL link concurrently, an ATM PVC will have to be provisioned for each user-destination pair. That is, if an Ethernet user has more than one ISP or needs to connect over a VPN to an enterprise site, then PVCs will be required for every combination. NAT gets around this problem by running all the traffic through a single IP address, and thus a single PVC. Another dubious solution is to install a customer premises ATM switch between the DSL modem and the DSL line.

PPPoE requires special client software for users, and the service providers' termination equipment (DSLAMs) must also be configured to support PPPoE. This additional layer of protocol software may prove troublesome . Furthermore, as PPPoE solutions roll out, software will primarily be available for Windows and Macintosh clients, although Linux support will also be available.

Perhaps more significantly, users accustomed to static IP addresses or DHCP are likely to be unhappy with their pooled and shared addresses. Many new PPPoE users are convinced that their ISPs are the primary beneficiaries of the protocol, while the customers are rather worse off than before.

Resources

The PPPoE specifications are spelled out in RFC 2516. As of this writing, this RFC is informational only and has not been put on a standards track.

RFC 1661 has the specifications for PPP; RFC 1332 covers IPCP; RFC 1334 covers PPP authentication protocols; and RFC 1990 covers Multilink PPP (MP).

There are extended accounts of HDLC and PPP in Computer Networks, Third Edition , by Andrew S. Tanenbaum, Upper Saddle River, NJ, Prentice-Hall PTR, 1996. HDLC and related data-link protocols are discussed in Data & Computer Communications, Sixth Edition , by William Stallings, Upper Saddle River, NJ, Prentice-Hall, 2000.

ACC, now a unit of Ericsson, has a good white paper on PPP here: www.acc.com/internet/about_apu/userprofiles_whitepapers/white_papers/ppp/ppp.html .

This tutorial, number 139, by Steve Steinke, was originally published in the February 2000 issue of Network Magazine.