The Point-to-Point Protocol (PPP): An Overview

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
By Thomas Spencer, Support Engineer--Microsoft Enterprise Systems Support

Remote Access Service (RAS)


The Point-to-Point Protocol (PPP) is a data link layer protocol which encapsulates other network layer protocols for transmission on synchronous and asynchronous communication lines.

Two precise definitions of "point-to-point" in the context of data communications follow:

  1. A network configuration in which a connection is established between two, and only two points. The connection may include switching facilities.

  2. A circuit connecting two points without the use of any intermediate terminal or computer.1Technical Aspects of Data Communication (3rd ed. Digital Press, 1988) p. 355.

This definition explains the point-to-point aspect of PPP. The protocol aspect lies in the fact that PPP is the intermediate packet structure which facilitates transmission of higher level protocols, such as TCP/IP, across diverse communication links.

PPP was first proposed as an Internet standard in the early 1990's by a working group of the Internet Activities Board's Internet Engineering Task Force (IETF).2Network World April 2, 1990: 2. The original purpose was to allow one uniform, standardized way to encapsulate the IP Protocol for point-to-point communications in a mixed environment of varying vendors and devices.

Many of the original proponents of the PPP protocol were router vendors who found that the many existing data link protocols used to envelop transport protocols were proprietary in nature. Hence, internetwork connectivity was difficult and limited. In particular, router vendors could not interoperate over serial dial-up or leased lines because no standard for high-speed synchronous communications had yet been defined.3

Today the PPP protocol standard finds wide use in asynchronous and synchronous connections between computers, bridges, routers, and other intermediate devices. PPP is gaining acceptance as a standard for Integrated Services Digital Network (ISDN), and many implementations of X.25 also support PPP connections.


(Improvements over SLIP)

RFC 1171, "The Point-to Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links," was the original RFC in response to the IETF working group proposal for PPP. This RFC defined PPP in terms of three major components:

  1. A method for encapsulating datagrams over serial links.

  2. An extensible Link Control Protocol(LCP).

  3. A family of Network Control Protocols(NCPs) for establishing and configuring different network layer protocols.4

Encapsulating datagrams was not new to the networking world, but establishing a standard to do so was new and was needed. Up to this point Serial Line IP (SLIP) had established itself as a defacto standard of sorts. Many users were able to connect their home computer to the Internet using SLIP through an RS-232 serial port and connected modem. SLIP was originally implemented in 1984.

But SLIP is a very simple implementation of encapsulation for IP datagrams. Some of the drawbacks of SLIP include:

  1. Operator intervention is required during connection, since SLIP cannot automatically communicate IP addresses during link initialization.

  2. SLIP uses only one protocol at a time over a serial link.

  3. SLIP does not perform any error checking for frames corrupted in transmission. Error checking is normally implemented as a check sum in PPP, but SLIP has no checksum.5TCP/IP Illustrated, Volume 1, The Protocols (Reading, MA: Addison-Wesley, 1994) 24.

PPP addresses these shortcomings of SLIP and more. PPP can assign and manage IP addresses. PPP is much better suited for high speed synchronous links6, and it is more adaptable to circuit switched networks.7 PPP can encapsulate more than one protocol in a given session, and it can keep active links over each of the multiple protocols.

PPP adds the Link Control Protocol to perform other functions missing in SLIP. Using the LCP, PPP has the ability to verify whether the line has a good enough quality to reliably support the connection. After the LCP component of PPP establishes the link, then the NCP component will negotiate the network layer protocol that PPP actually encapsulates and transports. For example, if the PPP link is configured to connect with IP, then the Internet Protocol Control Protocol (IPCP) will negotiate and configure the link to carry IP.8Data Link Protocols (Englewood Cliffs, NJ: PTR Prentice Hall, 1993) 243-244. An NCP, such as IPCP, may close the link over the network layer protocol, and yet the PPP connection can remain open. But if LCP closes the link, then all communication layers terminate, including the network layer, NCP fraffic, and the PPP connection itself.

Using LCP, "PPP can termintate the link at anytime. This might happen because of the loss of carrier, authentication failure, link quality failure, the expiration of an idle-period timer, or the admintrative closing of the link."9

Finally, PPP includes a method for error checking. Two trailing bytes of the PPP frame perform a cyclical redundacy check (CRC), or as it is also known: a frame check sequence (FCS).

In summary, the most important improvements of PPP in comparison to SLIP are:

  1. The ability to dynamically negotiate IP addresses.

  2. The ability to transport multiple protocols on a single serial connection.

  3. The addition of a Link Control Protocol to establish link options.

  4. The addition of network control protocols to negotiate the choices of network layer protocols.

  5. The addition of error checking for each PPP frame.


The correct understanding of PPP involves considering where it resides in the wider classification of data link protocols. Data link protocols may be grouped into three broad categories depending on the packet framing method associated with the given protocol. The three types are character-oriented, byte count-oriented, and bit-oriented. Character oriented protocols use special characters to delimit the packet frame structure. An example of this type of protocol is IBM's Binary Synchronous Communications Protocol, or BISYNC.

Byte count-oriented protocols identify the packet structure with a special character in the beginning followed by a count of the bytes for the data part of the packet. Kermit is an example of this type of protocol.

PPP uses the third type, the bit-orineted protocol. This protocol identifies the beginning and end of a packet with a specialized sequence of bits called a flag character. Suppose you specify that no bit pattern shall have more than six "1" bits in a row unless it is a flag character. So the bit pattern of 01111110 will always specify a flag, and this flag will always delimit the beginning and the end of a packet. The High (level) Data Link Control (HDLC) protocol as specified by the International Standards Organization (ISO) uses beginning and ending flags exactly as described above.10

PPP is one of many derivative protocols from HDLC. HDLC is defined by a number of ISO specifications: notably the documents ISO 3309, ISO 4335, and ISO 7809 among others. The following is a listing of some of the most important implementations of HDLC (with the technology they support in parentheses): LAPB(x.25), LAPD(ISDN), LAPX(TELETEX), PPP(many technologies), SDLC(SNA). Frame relay is also a derivative of HDLC, but frame relay does not support an overlying network layer.11

The consequence of PPP's relationship to HDLC is that the basic packet structure of PPP resembles very closely the structure of the HDLC packet.

In HDLC terms the data packet transmitted across the link is called a frame, and a frame will consist of the following elements:



Flag fields

8 bits

Address field

8, or multiples of 8 bits

Control fields

8, or multiples of 8 bits

Information field

variable length, not used in some frames

Frame check sequence field (FCS) or CRC.

16 bits1

1 Black, 104.

PPP adds one significant field to its frame, the protocol field that appears after the control field and before the information field. Hence, the PPP frame structure looks like this:


Notice that some of these values are fixed:

  • The flag field always has the HDLC pattern of

    01111110 (Hex7e).

  • The address field is all ones to signify all stations:

    11111111(Hex ff).

  • The control field signifies the HDLC unnumbered information command with a fixed value of:

    00000011 (Hex 03).

The protocol field is two bytes long and identifies the protocol data unit (PDU) that the PPP frame has encapsulated. The following table shows some of the values that may be assigned to the protocol field. The values are sub-classified according to the hexadecimal values of 0, 8, and "C" appearing in the first octet. If the first octet begins with zero (0), then this octet identifies the protocol in the information field. If the first protocol octet begins with an eight (8), then the octet identifies a control protocol that will negotiate the actual network protocol to be used over the link. If the protocol octet begins with the hexadecimal number "C", then the protocol field indicates that a Link Control Protocol is encapsulated in the information field of this frame.12

Protocol Field Values (Hex)


Padding Protocol

0003 to 001f



Internet Protocol


OSI Network Layer


Xerox NS IDP


DECnet Phase IV




Novell IPX


Van Jacobson Compressed TCP/IP


Van Jacobson Uncompressed TCP/IP


Bridging PDU


Stream Protocol (ST-II)


Banyan Vines




AppleTalk EDDP


AppleTalk SmartBuffered








1st choice compression




Internet Protocol Control Protocol


OSI Network Layer Control Protocol


Xerox NS IDP Control Protocol


DECnet Phase IV Control Protocol


Appletalk Control Protocol


Novell IPX Control Protocol






Bridging NCP


Stream Protocol Control Protocol


Banyan Vines Control Protocol








Multi-Link Control Protocol


Compression Control Protocol




Link Control Protocol


Password Authentication Protocol


Link Quality Report


Challenge Handshake Authentication Protocol13

On the packet level a PPP connection, or link operation, takes place through an exchange of requests and acknowledgments between the two end points of the connection. First the LCP sends requests and acknowledgments to open the link. The network control protocols (NCPs) negotiate which network layer protocol will be used over the link. When that negotiation is complete, the link carries the network layer session in which the two end points exchange high level protocol packets.

The diagram below shows a very simplified version of how such a link operation might take place. The exchange of information is depicted in time from the top so that first LCP sets up the link, and then the NCP negotiates the protocol. In this example, the NCP is the IP Control Protocol (IPCP). After the transfer of data at the network layer completes, LCP terminates the link.


Notice that NCP only terminates the network layer and NCP link. In this case the PPP link remains up. If LCP had terminated the session, the PPP link would be terminated also.

The actual details of establishing and maintaining the link are a very much more complex interaction of some thirteen events whose effect may result in one of ten different states in the link. The list of

possible states follow:

  1. Initial

  2. Starting

  3. Closed

  4. Stopped

  5. Closing

  6. Stopping

  7. Request-Sent

  8. Ack-Received

  9. Ack-Sent

  10. Opened

To illustrate the interaction between an event and a state, suppose the event Active Open occurs, and this event occurs against the link state of Closed. The resultant state of the link will be Request-Sent. A complete table defining the interaction of the PPP link events and states may be found in RFC 1661.14


LPC serves as a useful example of how a control protocol can be encapsulated in a PPP frame. To understand this encapsulation better, we need to take a closer look at the structure of LPC in relationship to the PPP frame as a whole


Link Control Protocol (LCP) Packet

Each LCP packet has a specific function in the exchange of configuration information depending on its packet type. The code field of the LCP packet identifies the packet type according to this table:

Code Number

Packet Type























1 Perkins, 20.

The identifier byte keeps track of matching requests and replies.

This byte can be thought of as the packet sequence ID. The length byte indicates the total length of the LCP packet to include the code, identifier, length, and data/options fields.15

Interestingly the options field has a format of its own as shown below:


The one byte type field specifies the LCP configuration option according to this table:

Type Number

















Address-and-Control-Field- Compression1

1 Simpson RFC 1548, 40

The length field shows the length of this configuration option to include the type, length, and data fields. The data field may be variable in length.


To show the usefulness of our previous study, let's examine just a few lines from a Windows NT PPP log file. Such a log file will be generated during a Windows NT Remote Access Service (RAS) session if you configure the appropriate option in the Windows NT Registry. To enable PPP logging set the Logging parameter to 1 in the following Registry location:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RasMan \PPP

You can get more detailed and useful information if you set this parameter to verbose mode using the value of 2. The PPP log will then be recorded in the following location on your hard disk:


Consider these lines from such a log:

<PPP packet sent at 21:51:961
<Protocol=LCP, Type=Configure-Req, Length= 0xC, Id=0x0, Port=0x0
<C0 21 01 00 00 0A 02 06 00 00 00 00

The log record plainly shows that a packet was sent, that the packet was an LCP packet, and that the packet type is a configuration request.16

Notice also the third line of cryptic hexadecimal numbers. This is where our knowledge of PPP and LPC packet structure will help.

Observe that each pair of characters represents one byte. So let's number off the bytes from left to right. As we analyze the bytes, let's group them according to the fields in the PPP frame and the LCP packet structure.

Bytes 1-2: C0 21

Notice this information begins with the protocol field of the PPP frame. From the previously listed table of protocol field values, we know that C0 21 designates an LPC packet.

Byte 3: 01

This is the code byte of the LPC packet. From the LPC code table above, 01 identifies a Configure-Request.

Byte 4: 00

This is the packet sequence number. In this case the number is zero since it is the first frame sent.

Byte 5-6: 00 0A

This is the length field of the LPC packet, and it shows ten bytes as the total length of the LPC packet. Notice this excludes the two bytes of the protocol field identifier. The "Length" value in the first line includes the protocol field so its value is twelve.

Byte 7: 02

This is the type field for the options section of the LCP packet. Type 2 designates an Async-Control-Character-Map. Please refer to RFC 1548, pages 41-42 to learn more about this option.

Byte 8: 06

This is the length for this option for a total of six bytes.

Bytes 9-12: 00 00 00 00

The values are all set to zero. This is the default signifying no mapping is needed for any control characters.

Naturally, complete PPP logs are much more extensive than these few lines, but the important point here is the method we used to decipher the PPP log. Our understanding of the PPP frame structure and the structure of encapsulated protocol data unit (PDU), helped us to read information from a very useful troubleshooting tool, the Windows NT RAS PPP log.


The purposes intended for PPP have all been achieved and more. PPP has gained widespread acceptance by the networking industry as a standard for synchronous and asynchronous communications. Since the first draft for the protocol in 1990 by the IETF, industry vendors have worked together to iron out differences in implementing the PPP standard.17Network World July 6, 1992: 29. Now virtually all of the major router vendors enjoy seamless PPP connections with other vendor's intermediate systems. Information system managers no longer have to choose between differing proprietary equipment which would limit access on their LAN or WAN connections.

As noted earlier that PPP is making substantial progress in becoming a standard for ISDN communications, but that's not all. With the rapid expansion of Internet users, PPP is sure to increase in importance. The development of new PPP related technologies will enhance this importance. For example, the Point-to-Point Tunneling Protocol (PPTP)will use a PPP link to the Internet to provide a secure link to a remote LAN. Connections that once required an on-site remote access server will now be made by merely dialing into a local Internet Service Provider (ISP). Because of advances in encryption technology, the link will remain private, and a remote client will simply be able to access the LAN from the home office through an Internet connection. The PPTP protocol was recently announced by a consortium of developers that include 3COM, Microsoft, and US Robotics.18


Black, Uyless. Data Link Protocols. Englewood Cliffs, NJ: PTR Prentice Hall, 1993.

Brown, Bob. "Vendors Unite to Back PPP Router-to-Router Protocol," Network World July 6, 1992: 29.

Burton, Craig. "Burton Group News Analysis: An Analysis of Significant Events in the Network Computing Industry." March 12, 1996.

McNamara, John E. Technical Aspects of Data Communication. 3rd Edition, Dgital Press, 1988.

Perkins, Drew D. "The Point-toPoint Protocol for the Transmission of Multi-Protocol datagrams Over Point-to-Point Linkds," RFC 1171, July 1990.

Seabourne, Roy. "Windows NT 3.51 PPP Logging Worksheet, Remote Access Service (RAS)." Microsoft Coporate Networking Support. Unpublished Paper, 1995.

Simpson, William A. "The Point-toPoint Protocol(PPP)," RFC 1548, Dec. 1993.

---, "The Point-to-Point Protocol(PPP)," RFC 1661, July 1994.

Smith, Tom. "Router Firms Rally Round Interoperability Protocol, Vendors Back Internet's Proposed PPP Protocol." Network World April 2, 1990: 29.

Stevens, W. Richard. TCP/IP Illustrated, Volume1, The Protocols. New York: Addison-Wesley, 1994.

1John E. McNamara,
2Tom Smith, "Router Firms Rally Round Interoperability Protocol, Vendors Back Internet's Proposed PPP Protocol,"
3Smith, 2.
4Drew D. Perkins, "The Point-to Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links," RFC 1171, July 1990: 1.
5W. Richard Stevens,
6Smith2; Stevens, 22.
7Perkins, pg. 1.
8Uyless Black,
9William A. Simpson, "The Point-to-Point Protocol (PPP), "RFC 1661, July 1994 Pg. 8
10McNamara, 174.
11Black, 100-101.
12Black, 242.
13William A. Simpson, "The Point-to-Point Protocol (PPP) ," RFC 1548, Dec. 1993: 5-6.
14Simpson, RFC 1661, 11.
15Simpson, RFC 1661, 26.
16Windows NT 3.51 PPP Logging Worksheet, Roy Seabourne, CNS.
17Bob Brown, "Vendors Unite to Back PPP Router-to-Router Protocol,"
18Craig Burton, "Burton Group News Analysis: An Analysis of Significant Events in the Network Computing Industry," March 12, 1996.