| The Point-to-Point protocol (PPP) can be used by two computers connected directly (i.e., not over a local area network) to communicate. PPP is defined in RFC 1661 [Simp94a]. A typical application for PPP is dialing into the Internet over a modem; see Figure 8-1. In this case, it increasingly replaces the older SLIP protocol (see Chapter 7), which has proven to be not as flexible as modern applications demand. Figure 8-1. Scenario for the use of PPP. 
In contrast to SLIP, PPP is multiprotocol enabled. In addition to IPv4, IPv6, and a large number of other network protocols, PPP also supports several subprotocols, which handle authentication and configuration tasks (e.g., negotiating important connection parameters and allocating dynamic IP addresses). The architecture of PPP is basically designed for peer-to-peer communication. Nevertheless, in the case of a dialup connection to the Internet, the point of presence is often called server and the dialing computer is called client. Though the protocol allows both ends of a connection to expect that the peer authenticate itself and allocates it a dynamic IP address, this would naturally not make much sense when dialing into the Internet. Linux distinguishes between synchronous and asynchronous PPP, depending on whether the underlying TTY device supports packet-oriented data transmission (synchronous for example, in ISDN with HDLC as the layer-2 protocol) or it works with a continuous byte stream (asynchronous e.g., in a modem connection). We will discuss the asynchronous transmission over a serial interface in more detail later, because it requires more protocol functionality than synchronous PPP. The ISDN subsystem of Linux has its own, independent PPP implementation, which is not discussed here. 8.1.1 Subprotocols Figure 8-2 shows the structure of a (synchronous) PPP packet. Synchronous PPP always processes entire frames of the lower-layer protocol, which is the reason why it is not necessary to specify the length. Asynchronous PPP additionally requires a frame detection, similar to SLIP. (See Section 7.1.1.) Section 8.3.5 describes how this frame detection is implemented in PPP. Figure 8-2. Structure of a PPP packet. 
The first 16 bits of a PPP packet specify the content encapsulated in the payload field. Table 8-1 gives an overview of the protocol numbers used. These numbers are built by the address-extension scheme of the HDLC protocol [ISO93], so that the protocols most frequently used can be encoded in one single byte. This means that all protocols have numbers where the first bit of the higher-order byte is deleted and the first bit of the lower-order byte is set (i.e., all have odd numbers). However, truncating the protocol field to 8 bits means that both communicating peers have to support this mode. Linux doesn't know this short version, and such configuration attempts of the peer are blocked off. Table 8-1. Protocol numbers for PPP packets.Number | Protocol |
|---|
0x0001-0x3FFF | network-layer protocols (e.g., IPv4, IPv6, IPX) | 0x4001-0x7FFF | transmission of small payload amounts without network-layer protocol (low-volume traffic) | 0x8001-0xBFFF | subprotocols to configure the network layer (network-control protocols e.g., IPCP) | 0xC001-0xFFFF | subprotocols to establish a PPP connection (link-layer control protocols e.g., LCP, PAP, CHAP) |
The current PPP implementation in Linux can transport four layer-3 protocols: IP, IPv6, IPX, and AppleTalk which are exactly the protocols that the network layer can handle. The higher-layer network protocol of PPP is handled transparently, so it is easy to add new protocols. In addition, PPP has so-called subprotocols, which are handled directly by the PPP instance, rather than by forwarding them to the network layer. The most important subprotocols are the following: LCP (Link Control Protocol): Subprotocol to configure PPP instances. PAP (Password Authentication Protocol): Authenticates the user by clear-text password (often used by Internet service providers). CHAP (Challenge Handshake Authentication Protocol): Secure user authentication over a challenge-response mechanism, where the user's password is not transmitted in clear text. IPCP (IP Configuration Protocol): Subprotocol to configure the IP layer (e.g., to allocate IP addresses once a PPP connection has been established).
8.1.2 Components of the Linux Implementation The Linux PPP implementation is composed of four parts: a generic PPP driver, one TTY line discipline (see Section 7.2.1) each for asynchronous and synchronous TTY devices, and a user-space daemon, pppd. Figure 8-3 gives a rough overview of how these components interact. Some of the communication channels represented in this figure are used, if at all, only during the establishment and teardown of connections; they are shown by dashed lines in the figure. Figure 8-3. Interaction of the PPP components. 
While the generic PPP driver is communicating with the network layer and one of the drivers (for asynchronous or synchronous PPP) is serving the underlying TTY device, pppd is responsible for the correct interaction of all components. It is also responsible for establishing and tearing down connections and handling the subprotocols described in Section 8.1.1. Each instance of pppd corresponds to exactly one PPP network device ppp0, ppp1, etc.). This allows several independent PPP interfaces, each having its own settings. To let the PPP daemon communicate with the generic PPP driver, a special character-oriented device with major number PPP_MAJOR (108) is set up; normally, it is embedded under /dev/ppp in the file system. The close interaction of all of these components makes it absolutely necessary to always use the pppd matching the Linux kernel. Otherwise, pppd will report a version conflict when the system starts. | 
