Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links
obsoleted by
- rfc-1331 — The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links
obsoletes
- rfc-1134 — Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links
Extracted elements (27)
LCP packets are always sent in their full standard form regardless of negotiated Configuration Options. This ensures Configure-Request packets remain recognizable even when one end mistakenly believes the link to be Open.
PPP does not require modem control signals (RTS, CTS, DCD, DTR), though using them when available allows greater functionality and performance. This minimizes physical-layer requirements so PPP can operate across any DTE/DCE interface.
The PPP Protocol field is defined to be consistent with the ISO 3309 extension mechanism for Address fields, even though it is not part of the HDLC standard. This maintains standards alignment while enabling multi-protocol multiplexing.
There is no version field in the LCP packet format. If a new version of LCP is needed, a new Data Link Layer Protocol field value is intended to differentiate it from Version 1. A Version 1 implementation will always respond to unknown Protocols with a recognizable Version 1 packet, providing a deterministic fallback.
On asynchronous links, character stuffing is used for transparency. The Control Escape octet (0x7d) causes the following octet to be XOR'd with 0x20. All octets less than 0x20, plus 0x7e and 0x7d, are escaped. The receiver strips escape sequences prior to FCS computation.
The FCS field is calculated over all bits of the Address, Control, Protocol, and Information fields, excluding start/stop bits, transparency-inserted bits or octets, Flag Sequences, and the FCS field itself. The FCS is transmitted with the coefficient of the highest term first.
All Protocol field values MUST be odd; the least significant bit of the least significant octet MUST equal '1'. Additionally, the least significant bit of the most significant octet MUST equal '0'. Frames violating these rules must be treated as having an unrecognized Protocol.
Before any IP packets may be communicated, both LCP and IPCP must reach the Open state. Larger IP datagrams exceeding the PPP maximum Information field length must be fragmented as necessary.
Each nak'd Configuration Option in a Configure-Nak MUST be modified to a value acceptable to the Configure-Nak sender. Acceptable options must be filtered out; unacceptable options must not be reordered.
Max-Restarts MUST be configurable but should default to 10 retransmissions. It indicates the number of packet retransmissions required before reasonable assurance that the link is closed. Any timeout used for loop detection MUST also be configurable.
Reception of a packet with an unknown Code MUST be reported back by transmitting a Code-Reject (Code=7) with the inducing packet copied into the Rejected-Packet field. Upon reception of a Code-Reject, an implementation should immediately transition to the Closed state.
The acknowledged Configuration Options in a Configure-Ack MUST NOT be reordered or modified in any way. A Configure-Ack with a mismatched Identifier or altered options is invalid and should be silently discarded.
The Magic-Number field in Echo-Request, Echo-Reply, and Discard-Request packets MUST always be transmitted as zero and MUST always be ignored on reception unless modified by a Configuration Option. It aids in detecting loopbacked links.
The Restart timer MUST be configurable but should default to 3 seconds. It is used to time out transmissions of Configure-Request and Terminate-Request packets, triggering retransmission on expiration.
Upon reception of a Configure-Request, an appropriate reply MUST be transmitted. A LCP implementation wishing to open a connection MUST transmit a Configure-Request packet with Code=1 and any desired changes to default Configuration Options.
Upon reception of a Terminate-Request, a LCP packet MUST be transmitted with Code=6 (Terminate-Ack), the Identifier copied from the request, and any desired data. Terminate-Request packets should continue to be sent until a Terminate-Ack is received or the physical layer goes down.
Upon reception of an Echo-Request, a LCP packet MUST be transmitted with Code=10 (Echo-Reply), the Identifier copied from the request, and the Data field copied from the request. Echo-Request and Echo-Reply packets may only be sent in the LCP Open state.
When the LCP state machine is in the Open state and a frame with an unknown Protocol is received, that error MUST be reported back by transmitting a Protocol-Reject (Code=8). Protocol-Reject packets may only be sent in the LCP Open state; those received in any other state should be discarded.
LCP defines eleven packet codes: Configure-Request (1), Configure-Ack (2), Configure-Nak (3), Configure-Reject (4), Terminate-Request (5), Terminate-Ack (6), Code-Reject (7), Protocol-Reject (8), Echo-Request (9), Echo-Reply (10), and Discard-Request (11).
LCP operates through four sequential phases: (1) Link Establishment and Configuration Negotiation, (2) Link Quality Determination (optional), (3) Network-Layer Protocol Configuration Negotiation, and (4) Link Termination. Network-layer datagrams may only be exchanged after LCP reaches the Open state.
The IP Control Protocol (IPCP) uses Protocol field value 0x8021 and configures, enables, and disables IP on both ends of the link. IPCP is identical to LCP except it only uses Codes 1-7; other codes result in Code-Rejects. IPCP packets may not be exchanged until LCP has reached the Network-Layer Protocol Configuration Negotiation phase.
The Protocol field (2 octets) identifies the encapsulated network-layer protocol. Values in the 0xxx range identify network protocols (e.g., 0x0021 = IP), 8xxx range identifies NCPs (e.g., 0x8021 = IPCP), and cxxx range identifies LCP or associated protocols (e.g., 0xc021 = LCP).
Security issues are not discussed in this memo. The Security Considerations section is explicitly empty, leaving authentication and confidentiality to be addressed by separate Configuration Options such as the User/Password Authentication Protocol (Protocol field 0xc023).
The LCP automaton has seven states: Closed (1), Listen (2), Request-Sent (3), Ack-Received (4), Ack-Sent (5), Open (6), and Closing (7). Transitions are triggered by events including Active-Open, Passive-Open, Close, Timeout, Physical-Layer-Down, and receipt of Configure-Request/Ack/Nak, Terminate-Request/Ack, Code-Reject, and Echo-Request packets.
The LCP Configuration Option format consists of: Type (1 octet, identifying the option type), Length (1 octet, total option length including Type, Length, and Data fields), and Data (variable). If a negotiable option is received with an invalid Length, a Configure-Nak should be sent with the correct Length.
The LCP packet format consists of: Code (1 octet, identifying packet type), Identifier (1 octet, for matching requests and replies), Length (2 octets, total packet length including Code/Identifier/Length/Data), and Data (variable). The Protocol field value 0xc021 identifies LCP packets.
The PPP frame consists of: Flag (1 octet, 0x7e), Address (1 octet, 0xff), Control (1 octet, 0x03), Protocol (2 octets), Information (variable, default max 1500 octets), FCS (2 or 4 octets), and closing Flag (0x7e). Fields are transmitted left to right, most significant octet first.