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 |
Option Type |
Option Length |
Description |
|---|---|---|---|
| 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
|
| 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):
- 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.
- 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:
- 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.
- Peer 2 does not understand option Z so it sends a Configure-Reject message containing option Z.
- Peer 1 sends a new Configure-Request message requesting option W, option X set to 100, and option Y set to 0.
- Peer 2 prefers that option X be set to 200 so it sends a Configure-Nack message containing option X and its preferred value.
- Peer 1 sends a new Configure-Request message requesting option W, option X set to 200, and option Y set to 0.
- 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.