PPP Overview
PPP was designed for serial connection protocols and has become the Internet standard for both dial-up and leased (nailed) line connections. PPP’s open standard encouraged wide support by vendors and the Internet explosion, and use of serial links to connect to the Internet have created wide acceptance of the protocol—with very few interoperability problems. PPP is defined in RFC 1661, “The Point-to-Point Protocol (PPP).”
PPP’s format is straightforward and takes advantage of the High-level Data Link Control (HDLC) protocol with the addition of a PPP header made up of one field containing the size of the packet and the protocol field, which defines the type or protocol of the packet being transported. PPP supports hundreds of protocols. Table 7.1 summarizes the common types seen in enterprise environments.
| Value | Protocol |
|---|---|
| 0x0021 | IP |
| 0x002D | Van Jacobson Compressed IP |
| 0x002F | Van Jacobson Uncompressed IP |
| 0x003D | PPP Multilink Protocol (MP) |
| 0x8021 | PPP Internet Protocol Control Protocol (IPCP) |
| 0xC021 | Link Control Protocol (LCP) |
| 0xC023 | Password Authentication Protocol (PAP) |
| 0xC223 | Challenge Handshake Authentication Protocol (CHAP) |
Logical View of PPP
PPP is not just the encapsulation of packets over the link; the PPP stack must support specific functionality throughout the lifetime of a PPP session. RFC 1661 defines this functionality in the term of phases, which are shown in Figure 7.1.
Figure 7.1. PPP phases.
Link Dead Phase
The link dead phase is the phase entered before and after a PPP session. When triggered to leave this phase by the Link Control Protocol (LCP), covered shortly, PPP will enter the link establishment phase.
Link Establishment Phase
LCP provides the link establishment phase. The connection is established with the bare minimum configuration options to bring the link up. Neither peer in the process is aware of particular options supported by the other—with the exception of authentication protocol selection. Should authentication be required for the link, the type of authentication will be determined (negotiated) during the link establishment phase.
LCP is defined in RFC 1661 with some added capabilities in RFC 1570, “PPP LCP Extensions.” The LCP packet is made up of the LCP header and data and is encapsulated within the PPP packet as shown in Figure 7.2.
Figure 7.2. LCP packet.
Link Dead Phase Link Establishment Phase Authentication PhaseLink Termination PhaseNetwork Protocol PhaseCode Identifier Length Data 016318
The LCP header includes an LCP code that identifies the messaging type, which could be a rejection to a particular option request.The LCP codes are listed in Table 7.2.
| Value | Message |
|---|---|
| 1 | Configure-Request |
| 2 | Configure-Ack |
| 3 | Configure-Nak |
| 4 | Configure-Reject |
| 5 | Terminate-Request |
| 6 | Terminate-Ack |
| 7 | Code-Reject |
| 8 | Protocol-Reject |
| 9 | Echo-Request |
| 10 | Echo-Reply |
| 11 | Discard-Request |
The data field is determined by the LCP code. This means that each message has a particular data or payload portion that matches the message.
After the link establishment phase has been accepted by both parties, the authentication phase is entered.
Authentication Phase
Prior to accepting any option parameters, the nodes can authenticate one another. Although not required, there is no good reason to not use authentication. This is unless another form of authentication is deemed adequate, such as caller ID. Once both peers are satisfied with any required authentication, the network layer protocol phase is entered. (Most sites only have the central remote access server authenticate the remote site; however, authentication can be supported in both directions regardless of which node initiated the session.)
PPP supports two authentication methods: Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP).
PAP is a simple username and password mechanism whereby the node sends the username and password in plain text. The user name and password are accepted or rejected by the remote node.
CHAP uses a more complicated 3-way handshake without sending clear text usernames or responses: challenge, response, and acknowledgement.
The node wishing to authenticate the remote host will send a challenge based on a secret phase that is known by itself and that also should be known by the remote node. The remote node uses the challenge and the secret phase with a hash function to compute the response. The response is then sent, and the node checks the response to ensure it is the same calculated response it computes itself and, should it match, acknowledges the authentication and allows the connection to continue.
Unlike PAP, CHAP never sends the secret phase, not even in encrypted form.
Network Layer Protocol Phase
The Network Control Protocol (NCP) determines the appropriate options for the protocols being supported. Each protocol supported by a node will have an NCP for the particular protocol. In addition, these NCPs can run in parallel. For example, IP and IPX options can be negotiated at the same time. Layer 3 traffic can be passed at this point within the phase, assuming the particular protocol was negotiated.
For IP over PPP, RFC 1172,“The PPP Internet Protocol Control Protocol (IPCP)” defines the standard for IP NCP.
IPCP uses the LCP packet format. However, only codes 1 through 7, shown in Table 7.3, are valid.
| Value | Message |
|---|---|
| 1 | Configure-Request |
| 2 | Configure-Ack |
| 3 | Configure-Nak |
| 4 | Configure-Reject |
| 5 | Terminate-Request |
| 6 | Terminate-Ack |
| 7 | Code-Reject |
To distinguish IPCP packets from LCP, the protocol field in the PPP header is set to 0x8021.
In addition to determining that IP is supported on the link, the network layer protocol phase uses specifics of IPCP to determine the IP address of the local IP address of the link and whether compression should be used.
Although the IP address must not be determined with IPCP, most implementations of PPP allow the administrator to determine which IP address is required. Most sites require that the central remote access server provide the IP address to ensure proper routing within the network.
Link Termination Phase
Under ideal conditions, the link termination phase is signaled end-to-end using PPP terminate packets; however, the link termination phase also can be caused by a loss of carrier or an immediate shutdown by the system administrator.
It is interesting to note that although the states seem very sequential, a state can be entered in the “middle” of a session, which would be during the network layer protocol state. For example, authentication could be requested again after having already authenticated once. This is represented by the arrows pointing the various states inb Figure 7.1.
Users tend to think of PPP as a client server protocol because it is often used to connect remote resources (a PC for example) to a central office (a network access server). However, the protocol, at least as defined by the standards, is a peer protocol with all options available to both peers. But despite this support, typical installations will often implement client server-type architectures. For example, the remote PC just mentioned will authenticate with the central resource, but the central Network Attached Storage (NAS) will not authenticate with the PC despite the protocol supporting the option. Additionally, some implementations of PPP will not support the bi-directional functionality on the “client” side.An example of such an implementation is Microsoft Windows Dial-Up networking’s lack of authentication of the peer when dialing in to a remote site.
Advanced Uses of PPP
In addition to the vanilla dial-in access, there are many advanced uses of PPP that provide additional network capability or provide solutions to network problems. These applications and PPP are not dependent on each other from a standards perspective, but many vendors have tied the features so closely to PPP that they are often only supported with PPP or require PPP to take advantage of the full functionality.
Leased/Nailed lines
PPP offers good interoperability for leased lines between various vendor products. HDLC has not been proven successful due to vendor interoperability issues. (HDLC, unlike PPP, does not provide protocol negotiations.)
PPP over ISDN
Integrated digital services network (ISDN) has become very popular in Europe, and ISDN4Linux (http://www.isdn4linux.de/) has become quite popular for running PPP over ISDN connections. ISDN has very quick call setups, so it lends itself well to additional features such as caller identification, caller identification call-back, and some of the specific applications covered in the next sections.
Dial on Demand
When a dial-up connection, such as an asynchronous (modem) or ISDN connection, is used to provide a gateway to another network or the Internet, the router making the connection must initiate the connection.The initiation is usually created by traffic bound for the PPP interface. Besides this basic gateway functionality, dial on demand is often built upon to provide additional functionality such as dial backup and bandwidth on demand.
Dial Backup
Dial backup provides an alternate route to a network based on a network failure. The network failure can be determined based on an interface status or a condition reported by a network protocol, such as a network failure. Although not required, dial backup is usually used to back up a leased line connection.
Consider Figure 7.3. The Linux router,“sleepy,” is connected to the router,“tired,” via a fractional T1 line providing 256Kbps of bandwidth (without compression) for the dedicated connection.
Figure 7.3. Dial backup network.
As shown in Figure 7.4, the leased line has failed. The backup connection has become active, providing continued connectivity between the sites.
Figure 7.4. Dial backup network with failure.
Bandwidth on Demand
Bandwidth on demand uses a dial-up connection to provide additional bandwidth to a network by adding the bandwidth of a dial up to the already existing connection through a load-balancing algorithm.The bandwidth on demand is triggered by a utilization threshold on the main link.
The PPP multilink protocol can be used to bundle multiple PPP links together and is defined in RFC 1990,“The PPP Multilink Protocol (MP).”