Like SLIP, PPP is a protocol used to send datagrams across a
serial connection; however, it addresses a couple of the deficiencies
of SLIP. First, it can carry a large number of protocols and is
thus not limited to the IP protocol. It provides error detection
on the link itself, while SLIP accepts and forwards
corrupted datagrams as long as the corruption does not occur in the
header. Equally important, it lets the communicating sides
negotiate options, such as the IP address and the maximum datagram size
at startup time, and provides client authorization. This built-in
negotiation allows reliable automation of the connection
establishment, while the authentication removes the need for the
clumsy user login accounts that SLIP requires. For each of these
capabilities, PPP has a separate protocol. In this chapter, we briefly
cover these basic building blocks of PPP. This discussion of PPP is
far from complete; if you want to know more about PPP, we urge you to
read its RFC specification and the dozen or so companion
RFCs.[1]
There is also a comprehensive O'Reilly book on the topic
of Using & Managing PPP, by Andrew Sun.
At the very bottom of PPP is the High-Level Data Link
Control (HDLC) protocol, which defines the
boundaries around the individual PPP frames and provides a 16-bit
checksum.[2] As opposed to the more primitive SLIP
encapsulation, a PPP frame is capable of holding packets from
protocols other than IP, such as Novell's IPX or Appletalk. PPP
achieves this by adding a protocol field to the basic HDLC frame that
identifies the type of packet carried by the frame.
The Link Control Protocol, (LCP) is used on top of HDLC
to negotiate options pertaining to the data link. For instance, the
Maximum Receive Unit (MRU), states the maximum
datagram size that one side of the link agrees to receive.
An important step at the configuration stage of a PPP link is client
authorization. Although it is not mandatory, it is really a must for
dialup lines in order to keep out intruders. Usually the called host
(the server) asks the client to authorize itself by proving it knows
some secret key. If the caller fails to produce the correct secret,
the connection is terminated. With PPP, authorization works both
ways; the caller may also ask the server to authenticate
itself. These authentication procedures are totally independent of
each other. There are two protocols for different types of
authorization, which we will discuss further in this chapter: Password Authentication Protocol (PAP)
and Challenge Handshake Authentication Protocol
(CHAP).
Each network protocol that is routed across the data link (like IP and
AppleTalk) is configured dynamically using a corresponding
Network Control Protocol (NCP). To
send IP datagrams across the link, both sides running PPP must first
negotiate which IP address each of them uses. The control protocol
used for this negotiation is the Internet Protocol Control
Protocol (IPCP).
Besides sending standard IP datagrams across the link, PPP also supports
Van Jacobson header compression of IP datagrams. This technique
shrinks the headers of TCP packets to as little as three bytes. It is
also used in CSLIP, and is more colloquially referred to as VJ header
compression. The use of compression may be negotiated at startup time
through IPCP, as well.
