PPP Link Negotiation with LCP

The PPP Link Control Protocol (LCP) is documented in RFC 1661. LPC negotiates link and PPP parameters to dynamically configure the data link layer of a PPP connection. Common LCP options include the PPP MRU, the authentication protocol, compression of PPP header fields, callback, and multilink options.

LCP Packet Structure

LCP uses the PPP Protocol ID of 0xC0-21. The packet structure of LCP is illustrated in Figure 7.11. Each LCP packet is a single LCP message consisting of an LCP Code field identifying the type of LCP packet, an Identifier field so that requests and replies can be matched, a Length field indicating the size of the LCP packet and LCP packet type–specific data.

Figure 7.11 LCP Packet Structure

Table 7.7 lists the LCP packet types documented in RFC 1661.

Table 7.7 LCP Packet Types

LCP Code LCP Packet Type Description
1 Configure-Request Sent to open or reset a PPP connection. Configure-Request contains a list of LCP options with changes to default option values.
2 Configure-Ack Sent when all of the values of all of the LCP options in the last Configure-Request received are recognized and acceptable.

When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete.

3 Configure-Nack Sent when all the LCP options are recognized, but the values of some options are not acceptable. Configure-Nack includes the offending options and their acceptable values.
4 Configure-Reject Sent when LCP options are not recognized or not acceptable for negotiation. Configure-Reject includes the unrecognized or non-negotiable options.
5 Terminate-Request Optionally sent to close the PPP connection.
6 Terminate-Ack Sent in response to the Terminate-Request.
7 Code-Reject Sent when the LCP code is unknown. The Code-Reject message includes the offending LCP packet.
8 Protocol-Reject Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the offending LCP packet.

Protocol-Reject is typically sent by a PPP peer in response to a PPP NCP for a LAN protocol not enabled on the PPP peer.

9 Echo-Request Optionally sent to test the PPP connection.
10 Echo-Reply Sent in response to an Echo-Request.

The PPP Echo-Request and Echo-Reply are not related to the ICMP Echo Request and Echo Reply messages.

11 Discard-Request Optionally sent to exercise the link in the outbound direction.

LCP Options

When using the Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject LCP packet types, the LCP data portion of the LCP packet consists of one or more LCP options as illustrated in Figure 7.12. Each LCP option consists of an option Type field, a Length field indicating the total length in bytes of the option and the data associated with the option.

Figure 7.12 LCP Options

Table 7.8 lists common LCP options negotiated by Microsoft PPP peers. For information about other LCP options, see RFC 1661.

Table 7.8 LCP Options

Option Name

Maximum Receive Unit (MRU) 1 4 The maximum size (up to 65,535) of the PPP frame. The default MRU is 1,500. If neither peer is changing the default, this option is not negotiated.
Asynchronous Control Character Map (ACCM) 2 6 A bit map that enables (bit set to 1) or disables (bit set to 0) the use of character escapes for asynchronous links for the 32 ASCII control characters from 0x00 to 0x20. By default, character escapes are used. The ACCM bit map is set to 0x00-00-00-00 for links with XON/XOFF software flow control.
Authentication Protocol 3 5 or 6 Indicates the authentication protocol used during the authentication phase of the connection.

Values for this field for Microsoft PPP peers are 0xC2-27 for EAP, 0xC2-23-80 for MS-CHAP version 1, 0xC2-23-81 for MS-CHAP version 2, 0xC2-23-05 for MD5-CHAP, 0xC0-27 for SPAP, and 0xC0-23 for PAP.

Magic Number 5 6 A random number chosen to distinguish a peer and detect looped back lines.
Protocol Compression 7 2 A flag indicating that the PPP protocol ID be compressed to a single octet when the 2-byte protocol ID is in the range 0x00-00 to 0x00-FF.
Address and Control Field Compression 8 2 A flag indicating that the PPP Address field (always set to 0xFF) and the PPP Control field (always set to 0x03) be removed from the PPP header.
Callback 13 or 0x0D 3 A 1-octet indicator of how callback is to be determined. For remote access clients and server running Microsoft® Windows 32-bit operating systems, the callback option octet is set to 0x06, indicating that the callback is determined during Callback Control Protocol (CBCP) negotiation.

LCP Negotiation Process

The LCP negotiation is a series of LCP packets exchanged between PPP peers to negotiate a set of options and option values when sending data. The LCP negotiation is actually two separate dialogs between two PPP peers (Peer 1 and Peer 2):

  1. Peer 1 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to Peer 2. This dialog starts with Peer 1 sending a Configure-Request message and ends when Peer 2 sends a Configure-Ack message.
  2. Peer 2 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to peer 1. This dialog starts with Peer 2 sending a Configure-Request message and ends when Peer 1 sends a Configure-Ack message.

Peer 1 and Peer 2 do not have to use the same set of LCP options.

When a PPP peer sends its initial Configure-Request, the response is any of the following:

  • A Configure-Nack message because one or more options have unacceptable values.
  • A Configure-Reject message because one or more of the options are unknown or not negotiable.
  • A Configure-Ack message because all of the options have acceptable values.

When a PPP peer receives a Configure-Nack message or Configure-Reject message in response to its Configure-Request message, it sends a new Configure-Request message with modified options or option values. When a Configure-Ack message is received, the PPP peer is ready to send data.

Figure 7.13 shows a hypothetical LCP negotiation process for Peer 1 using the fictional options W, X, Y, Z.

Figure 7.13 Sample LCP Negotiation

From the LCP messages in Figure 7.13:

  1. Peer 1 sends a Configure-Request message requesting option W, option X set to 100, option Y set to 0, and option Z. Options W and Z are flag options.
  2. Peer 2 does not understand option Z so it sends a Configure-Reject message containing option Z.
  3. Peer 1 sends a new Configure-Request message requesting option W, option X set to 100, and option Y set to 0.
  4. Peer 2 prefers that option X be set to 200 so it sends a Configure-Nack message containing option X and its preferred value.
  5. Peer 1 sends a new Configure-Request message requesting option W, option X set to 200, and option Y set to 0.
  6. Peer 2 sends a Configure-Ack message.

Each time Peer 1 sends a new Configure-Request message, it changes the Identifier value in the LCP header so that Configure-Request messages can be matched with their responses.

The previous process only configures how Peer 1 sends data to Peer 2. A separate LCP negotiation must be done so that Peer 2 can be configured to send data to Peer 1. Very often, the LCP packets for the two dialogs are intermixed during the connection process. Peer 1 is configuring the way it sends data at the same time as Peer 2.

Please send all comment to info@rambuk.dk