Section 2.10. PPP

The Point-to-Point Protocol (PPP) is an interface-layer protocol. We usually think of it as the protocol used to carry IP datagrams over serial lines in dial-up connections to an ISP, but as we shall see, PPP can also carry IP over other media. For example, PPP is commonly used to carry data over Ethernet, T1/E1 connections, and ATM. In Chapter 4 and Part 2, we will see that PPP is frequently used in building tunnels. Because of its use in tunneling and because we will use it ourselves in some of the tunnels we build, it is worthwhile spending a little time to understand the rudiments of the protocol.

PPP evolved from two other networking technologies: serial line IP (SLIP) and the High-Level Data Link Control (HDLC) protocol, as shown in Figure 2.32.

SLIP is an extremely simple protocol used to frame IP datagrams on serial lines. It is defined in RFC 1055 [Romkey 1988], which also provides sample C code for sending and receiving IP packets assuming the primitives send_char() and recv_char(), which send and receive a single character over a serial line. The design is straightforward: A special END character (0xc0) is used to begin and end each IP datagram. Any END characters in the data are replaced with the sequence 0xdb 0xdc, where the 0xdb is called the SLIP ESC character. Any SLIP ESC characters are replaced by the sequence 0xdb 0xdd.

SLIP provides no addressing or error detection and can carry only IP datagrams. It also has no built-in compression capabilities, but Van Jacobson's VJ header compression is often used in conjunction with it to compress the TCP and IP headers in TCP segments. VJ compression, which is defined in RFC 1144 [Jacobson 1990], can also be used in PPP connections.

The HDLC protocol was originally developed for use on synchronous leased lines. It specifies both packet-framing formats and a method of transmitting a bit stream on the synchronous digital link that provides the physical medium. The basic HDLC packet is shown in Figure 2.33.

The address field carries the station ID in multidrop lines. Because PPP is a point-to-point protocol, this field is not necessary and is set to 0xff. The control field specifies the type of data in the information field. For PPP, the control field is always set to 0x03. IP datagrams and other data are carried in the information field. The frame check sequence (FCS) field is a standard 16- or 32-bit cyclic redundancy check (CRC).

On synchronous lines, each HDLC frame is preceded by the 8-bit sequence 01111110. This so-called flag is used to synchronize the receiver and tell it that another frame is coming. The synchronous wire protocol ensures that no more than five consecutive 1-bits will appear in the data, so the flag is unique. PPP on asynchronous media uses the same idea: Each PPP frame is terminated with a flag byte of 0x7e. Although not strictly required, most PPP implementations will also start the frame with a flag byte to help prevent interframe line noise, particularly on asynchronous serial lines, from corrupting the following frame.

As with SLIP, a PPP ESC byte (0x7d) is used to escape flag bytes, PPP ESC bytes, and other bytes, such as the ASCII control bytes, that the PPP peers may negotiate. The effect of a PPP ESC is to exclusive-OR 0x20 with the byte being escaped. Thus, a 0x7e (flag) byte in the data will be transmitted as the sequence 0x7d, 0x5e. Similarly, a PPP ESC byte in the data will be transmitted as the sequence 0x7d, 0x5d. This process is illustrated in Figure 2.34, which shows a PPP packet before and after the data is framed and escaped.

The Link Control Protocol (LCP) establishes the basic parameters for the transmission of data over the physical link. Parameters, such as the maximum receive unit (MRU), bytes needing escaping, header compression options, type of CRC to use, authentication protocols, and padding requirements are negotiated in this phase.
The authentication phase identifies the peers to each other, using the protocol or protocols negotiated in the LCP phase. The authentication phase uses protocols such as the Password Authentication Protocol (PAP), the Challenge-Handshake Authentication Protocol (CHAP), and the Extensible Authentication Protocol (EAP) to authenticate the peers.
The Network Control Protocol (NCP) phase negotiates parameters for one or more network protocols, such as IP, that the PPP link will carry. We are interested in using PPP to carry IP datagrams only, but it can also carry other protocols, such as AppleTalk and IPX. When the NCP phase is operating on behalf of IP, it negotiates parameters such as the IP addresses of the peers, domain name system (DNS) servers, and whether to perform VJ compression. Although not really network-layer protocols, the Compression Control Protocol (CCP) and Encryption Control Protocol (ECP) are also considered NCPs. As their names suggest, they are used to negotiate compression and encryption algorithms and their parameters.

The information field can contain IP datagrams or control information used during LCP, authentication, and NCP negotiation. The first 2 bytes of the information field, called the protocol field, indicate the type of data the information field is carrying, as shown in Figure 2.35. The format of the LCP and NCP data is defined in a series of RFCs, but [Carlson 2000] has an excellent discussion of this data and a thorough explanation of the working of PPP.

Because PPP normally makes no use of the address and control fields, the peers can agree during LCP negotiations to omit them in non-LCP frames. Similarly, the peers can agree that they will compress the protocol field to a single byte whenever possible. If the most significant byte of the protocol field is odd, it is compressed; otherwise, the full protocol field is present. Being aware of these optimizations is important because we will see examples of them in our network traces later in the text.

2.10. PPP

Figure 2.32. The PPP Family Tree

Figure 2.33. HDLC Packet Format

Figure 2.34. A PPP Packet Before and After Framing and Escaping

Figure 2.35. PPP Frame Formats