PPP Architecture

PPP works at the network access layer of the Transmission Control Protocol (TCP)/IP suite for point-to-point (P2P) data transmission over full-duplex synchronous and asynchronous links.

Figure 8-45 Location of PPP in the TCP/IP suite

PPP Packet Format

Figure 8-46 shows the PPP packet format.

Figure 8-46 PPP packet format

A PPP packet contains the following fields:

• Flag field

  The Flag field identifies the start and end of a physical frame and is always 0x7E.

• Address field

  The Address field uniquely identifies a peer. PPP is used on P2P links, so two devices communicating using PPP do not need to know the link-layer address of each other. This field must be filled with a broadcast address of all 1s and is of no significance to PPP.

• Control field

  The Control field value defaults to 0x03, indicating an unsequenced frame. By default, PPP does not use sequence numbers or acknowledgement mechanisms to ensure transmission reliability.

  The Address and Control fields together identify a PPP packet. That is, a PPP packet header is FF03 by default.

• Protocol field

  The Protocol field identifies the protocol of the data encapsulated in the Information field of a PPP packet.

  The structure of this field complies with the International Organization for Standardization (ISO) 3309 extension mechanism for address fields. All Protocol field values must be odd. The least significant bit of the least significant byte must be "1". The least significant bit of the most significant byte must be "0".

  If a device receives a data packet that does not comply with these rules, the device considers the packet unrecognizable and sends a Protocol-Reject packet padded with the protocol code of the rejected packet to the sender.

  Table 8-7 Common protocol codes

  Protocol Code	Protocol Type
  0021	Internet Protocol
  002b	Novell IPX
  002d	Van Jacobson Compressed TCP/IP
  002f	Van Jacobson Uncompressed TCP/IP
  8021	Internet Protocol Control Protocol
  802b	Novell IPX Control Protocol
  8031	Bridging NC
  C021	Link Control Protocol
  C023	Password Authentication Protocol
  C223	Challenge Handshake Authentication Protocol

• Information field

  The Information field contains the data. The maximum length of the Information field, including the Padding content, is equivalent to the maximum receive unit (MRU) length. The MRU defaults to 1500 bytes and can be negotiated.

  In the Information field, the Padding content is optional. If data is padded, the communicating devices can communicate only when they can identify the padding information as well as the payload to be transmitted.

• Frame check sequence (FCS) field

  The FCS field checks whether PPP packets contain errors.

  Some mechanisms used to ensure proper data transmission increase the transmission cost and cause delay in data exchange at the application layer.

LCP Packet Format

Figure 8-46 shows the LCP packet format.

Two devices exchange LCP packets to establish a PPP link. An LCP packet is encapsulated into the Information field of a PPP packet as the payload. The value of the Protocol field of a PPP packet is always 0xC021.

During the establishment of a PPP link, the Information field is variable and can contain various LCP packets, which are identified using the Code field.

The following describes the cold field in the Information field:

• Code field

  The 1–byte-long Code field identifies the LCP packet type.

  If a receiver receives an LCP packet with an unknown Code field from a sender, the receiver sends a Code-Reject packet to the sender.

  Table 8-8 Code field values

  Code Value	Packet Type
  0x01	Configure-Request
  0x02	Configure-Ack
  0x03	Configure-Nak
  0x04	Configure-Reject
  0x05	Terminate-Request
  0x06	Terminate-Ack
  0x07	Code-Reject
  0x08	Protocol-Reject
  0x09	Echo-Request
  0x0A	Echo-Reply
  0x0B	Discard-Request
  0x0C	Reserved

• Identifier field

  The Identifier field is 1 byte long. It is used to match requests and replies. If a packet with an invalid Identifier field is received, the packet is discarded.

  The sequence number of a Configure-Request packet usually starts at 0x01 and increases by 1 each time the Configure-Request packet is sent. After a receiver receives a Configure-Request packet, it must send a reply packet with the same sequence number as the received Configure-Request packet.

• Length field

  The Length field specifies the length of a negotiation packet, including the length of the Code, Identifier, Length, and Data fields.

  The Length field value cannot exceed the MRU of the link. Bytes outside the range of the Length field are treated as padding and are ignored after they are received.

• Data field

  The Data field contains the contents of a negotiation packet and includes the following fields:

  • Type field: specifies the negotiation option type.

  • Length field: specifies the total length of the Data field.

  • Data field: contains the contents of the negotiation option.

  Table 8-9 Negotiation options in the Type field

  Negotiation Option Value	Negotiation Packet Type
  0x01	Maximum-Receive-Unit
  0x02	Async-Control-Character-Map
  0x03	Authentication-Protocol
  0x04	Quality-Protocol
  0x05	Magic-Number
  0x06	RESERVED
  0x07	Protocol-Field-Compression
  0x08	Address-and-Control-Field-Compression

Dead Phase

The physical layer is unavailable during the Dead phase. A PPP link begins and ends with this phase.

When two devices detect that the physical link between them has been activated, for example, when carrier signals are detected on the physical link, the two devices move from the Dead phase to the Establish phase.

After the PPP link is terminated, the two devices enter the Dead phase.

Establish Phase

In the Establish phase, the two devices perform an LCP negotiation to negotiate the working mode (SP or MP), MRU, authentication mode, and magic number. After the LCP negotiation is complete, the two devices enter the next phase.

In the Establish phase, the LCP status changes as follows:

• If the link is unavailable (in the Dead phase), LCP is in the Initial or Starting state. When the physical layer detects that the link is available, the physical layer sends an Up event to the link layer. Upon receipt, the link layer changes the LCP status to Request-Sent. Then, the devices at both ends send Configure-Request packets to each other to configure a data link.

• If the local device first receives a Configure-Ack packet from the peer, the LCP status changes from Request-Sent to Ack-Received. After the local device sends a Configure-Ack packet to the peer, the LCP status changes from Ack-Received to Open.

• If the local device first sends a Configure-Ack packet to the peer, the LCP status changes from Request-Sent to Ack-Sent. After the local device receives a Configure-Ack packet from the peer, the LCP status changes from Ack-Sent to Open.

• After LCP enters the Open state, the next phase starts.

The next phase is the Authentication or Network phase, depending on whether authentication is required.

Authentication Phase

The Authentication phase is optional. By default, PPP does not perform authentication during PPP link establishment. If authentication is required, the authentication protocol must be specified in the Establish phase.

PPP provides two password authentication modes: PAP authentication and CHAP authentication.

Two authentication methods are available: unidirectional authentication and bidirectional authentication. In unidirectional authentication, the device on one end functions as the authenticating device, and the device on the other end functions as the authenticated device. In bidirectional authentication, each device functions as both the authenticating and authenticated device. In practice, only unidirectional authentication is used.

PAP Authentication Process

PAP is a two-way handshake authentication protocol that transmits passwords in simple text.

Figure 8-48 shows the PAP authentication process.

Figure 8-48 PAP authentication process

1. The authenticated device sends the local user name and password to the authenticating device.

2. The authenticating device checks whether the received user name is in the local user list.

   • If the received user name is in the local user list, the authenticating device checks whether the received password is correct.
     • If the password is correct, the authentication succeeds.
     • If the password is incorrect, the authentication fails.
   • If the received user name is not in the local user list, the authentication fails.

PAP Packet Format

A PAP packet is encapsulated into the Information field of a PPP packet with the Protocol field value 0xC023. Figure 8-49 shows the PAP packet format.

Figure 8-49 PAP packet format

CHAP Authentication Process

CHAP is a three-way handshake authentication protocol. CHAP transmits only user names but not passwords, so it is more secure than PAP.

Figure 8-50 shows the CHAP authentication process.

Figure 8-50 CHAP authentication process

Unidirectional CHAP authentication applies to the following scenarios:(The first scenario is recommended, so that the authenticated device can check the user name of the authenticating device.)

• The authenticating device is configured with a user name. In this scenario:

  1. The authenticating device initiates an authentication request by sending a Challenge packet that carries a random number and the local user name to the authenticated device.

  2. After receiving the Challenge packet through an interface, the authenticated device checks whether a CHAP password is configured on the interface.

     • If the password is configured, the authenticated device uses the hash algorithm to calculate a hash value based on the packet ID, the CHAP password, and the random number in the packet, and then sends a Response packet carrying the hash value and the local user name to the authenticating device.
     • If the password is not configured, the authenticated device searches the local user table for the password matching the user name of the authenticating device in the received packet, uses the hash algorithm to calculate a hash value based on the packet ID, the password matching the user name, and the random number in the packet, and then sends a Response packet carrying the hash value and the local user name to the authenticating device.

  3. The authenticating device uses the hash algorithm to calculate a hash value based on the packet ID, the locally saved password of the authenticated device, and the random number in the Challenge packet, and then compares the hash value with that in the Response packet. If the two hash values are the same, the authentication succeeds. Otherwise, the authentication fails.

• The authenticating device is not configured with a user name. In this scenario:

  1. The authenticating device initiates an authentication request by sending a Challenge packet that carries a random number to the authenticated device.

  2. After receiving the Challenge packet, the authenticated device uses the hash algorithm to calculate a hash value based on the packet ID, the CHAP password configured using the ppp chap password command, and the random number in the packet, and then sends a Response packet carrying the hash value and the local user name to the authenticating device.

  3. The authenticating device uses the hash algorithm to calculate a hash value based on the packet ID, the locally saved password of the authenticated device, and the random number in the Challenge packet, and then compares the hash value with that in the Response packet. If the two hash values are the same, the authentication succeeds. Otherwise, the authentication fails.

CHAP Packet Format

A CHAP packet is encapsulated into the Information field of a PPP packet with the Protocol field value 0xC223. Figure 8-51 shows the CHAP packet format.

Figure 8-51 CHAP packet format

The differences between PAP and CHAP authentication are as follows:

• In PAP authentication, passwords are sent over links in simple text. After a PPP link is established, the authenticated device repeatedly sends the user name and password until authentication finishes. PAP authentication is used on networks that do not require high security.

• CHAP is a three-way handshake authentication protocol. In CHAP authentication, the authenticated device sends only a user name to the authenticating device. Compared with PAP, CHAP features higher security because passwords are not transmitted. CHAP authentication is used on networks that require high security.

Network Phase

In the Network phase, NCP negotiation is performed to select a network-layer protocol and to negotiate network-layer parameters. An NCP can enter the Open or Closed state at any time. After an NCP enters the Open state, network-layer data can be transmitted over the PPP link.

Termination Phase

PPP can terminate a link at any time. A link can be terminated manually by an administrator or be terminated due to carrier loss, an authentication failure, or other causes.

How MP Works

The Multilink protocol bundles multiple PPP links into an MP link to increase link bandwidth and reliability. MP fragments packets exceeding the maximum transmission unit (MTU) and sends these fragments to the PPP peer over the PPP links in the MP-group. The PPP peer then reassembles these fragments into packets and forwards these packets to the network layer. For packets that do not exceed the MTU, MP directly sends these packets over the PPP links in the MP-group to the PPP peer, which in turn forwards these packets to the network layer.

MP Implementation

An MP-group interface is dedicated to MP applications. MP is implemented by adding multiple PPP interfaces to an MP-group interface.

MP Link Negotiation Process

Certain MP options, such as the maximum receive reconstructed unit (MRRU) and endpoint discriminator, are determined through Link Control Protocol (LCP) negotiation.

Benefits