rfc-1661

The Point-to-Point Protocol (PPP)

W. Simpson (Editor)
date1994-07 streamIETF areaint wgpppext statusINTERNET STANDARD pages53 canonicalhttps://www.rfc-editor.org/rfc/rfc1661 doi10.17487/RFC1661 errataview
This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

obsoletes

updated by

also

Extracted elements (30)

design-rationale §4.4

Configure-Nak and Configure-Reject serve distinct purposes despite causing the same automaton state transition: Configure-Nak refuses a specific option value and suggests an acceptable alternative, while Configure-Reject refuses all negotiation of an option (typically because it is unrecognized or administratively prohibited).

design-rationale §5

LCP has no version field. A correctly functioning LCP implementation always responds to unknown Protocols and Codes with recognizable LCP packets, providing a deterministic fallback for implementations of other versions without needing an explicit version negotiation field.

design-rationale §4.2

The Stopped state combines link termination, link configuration failure, and other automaton failure modes into a single junction state. This simplification is justified because the states share the same behavior, and a race condition between the Down event and Receive-Configure-Request is handled by the Down event superseding and returning to Starting state.

interoperability-note §5

LCP Link Configuration, Link Termination, and Code-Reject packets (codes 1-7) are always sent as if no Configuration Options were negotiated, using default values. This ensures LCP packets remain recognizable even when one peer mistakenly believes the link is open with negotiated options.

normative-requirement §3.5 MUST NOT

Advancement from the Authentication phase to the Network-Layer Protocol phase MUST NOT occur until authentication has completed. If authentication fails, the authenticator SHOULD proceed to the Link Termination phase.

security

normative-requirement §2 MUST

All Protocol field values MUST be odd (least significant bit of least significant octet MUST equal 1), and the least significant bit of the most significant octet MUST equal 0. Frames not complying with these rules MUST be treated as having an unrecognized Protocol.

normative-requirement §6.2 MUST NOT

An implementation MUST NOT include multiple Authentication-Protocol Configuration Options in a Configure-Request. It SHOULD attempt the most desirable protocol first and, if Configure-Nak'd, attempt the next most desirable in the subsequent Configure-Request.

security

normative-requirement §3.4 MUST

Any non-LCP packets received during the Link Establishment phase MUST be silently discarded. Similarly, during the Link Termination phase, any non-LCP packets received MUST be silently discarded.

normative-requirement §3.1 MUST

Each end of a PPP link MUST first send LCP packets to configure and test the data link before any network-layer protocol traffic. After LCP reaches Opened state, PPP MUST send NCP packets to configure each desired network-layer protocol.

normative-requirement §5.2 MUST

If every Configuration Option in a Configure-Request is recognizable and all values are acceptable, the implementation MUST transmit a Configure-Ack. The acknowledged options MUST NOT be reordered or modified in any way.

normative-requirement §5.3 MUST

If every received Configuration Option is recognizable but some values are not acceptable, the implementation MUST transmit a Configure-Nak containing only the unacceptable options. If some options are not recognizable or not acceptable for negotiation, the implementation MUST transmit a Configure-Reject.

normative-requirement §5.7 MUST

If the LCP automaton is in the Opened state and a PPP packet with an unknown Protocol field is received, a Protocol-Reject MUST be sent. Upon reception of a Protocol-Reject, the implementation MUST stop sending packets of the indicated protocol at the earliest opportunity.

normative-requirement §2 MUST

New protocol numbers MUST be obtained from IANA. Developers of new protocols must not self-assign Protocol field values.

registry

normative-requirement §4.6 MUST

The Restart timer MUST be configurable but SHOULD default to three seconds. Max-Terminate MUST be configurable but SHOULD default to two transmissions. Max-Configure MUST be configurable but SHOULD default to ten transmissions. Max-Failure MUST be configurable but SHOULD default to five transmissions.

normative-requirement §5.4 MUST NOT

Upon reception of a Configure-Reject, the sender MUST NOT include any of the rejected Configuration Options in any subsequent Configure-Request.

normative-requirement §5.5 MUST

Upon reception of a Terminate-Request, a Terminate-Ack MUST be transmitted. The receiver of a Terminate-Request MUST NOT disconnect until at least one Restart time has passed after sending the Terminate-Ack.

normative-requirement §5.8 MUST

Upon reception of an Echo-Request in the LCP Opened state, an Echo-Reply MUST be transmitted. Echo-Request and Echo-Reply packets MUST only be sent in the LCP Opened state.

normative-requirement §5.8 MUST

When the Magic-Number Configuration Option has not been successfully negotiated, the Magic-Number field MUST be transmitted as zero in Echo-Request, Echo-Reply, and Discard-Request packets.

protocol-element §6

LCP Configuration Option types defined: 0=RESERVED, 1=Maximum-Receive-Unit, 3=Authentication-Protocol, 4=Quality-Protocol, 5=Magic-Number, 7=Protocol-Field-Compression, 8=Address-and-Control-Field-Compression. Options apply half-duplex in the receive direction of the Configure-Request sender.

registry

registry §5

LCP Code field values: 1=Configure-Request, 2=Configure-Ack, 3=Configure-Nak, 4=Configure-Reject, 5=Terminate-Request, 6=Terminate-Ack, 7=Code-Reject, 8=Protocol-Reject, 9=Echo-Request, 10=Echo-Reply, 11=Discard-Request. Unknown Code values trigger a Code-Reject response.

registry

registry §2

PPP Protocol field values are assigned by IANA. Ranges: 0x0000-0x3fff (network-layer protocols), 0x8000-0xbfff (associated NCPs), 0x4000-0x7fff (low-volume protocols with no NCP), 0xc000-0xffff (link-layer control protocols). Reserved values include 0xc021 (LCP), 0xc023 (PAP), 0xc025 (Link Quality Report), 0xc223 (CHAP).

registry

security-consideration §SECURITY CONSIDERATIONS

PPP provides no inherent data confidentiality or integrity protection for user data. Authentication via PAP or CHAP is optional and negotiated during the Authentication phase; when authentication fails, the link SHOULD be terminated to prevent attack by repetition and denial of service to other users.

security

state-machine §3.2

PPP link passes through five phases: Dead (physical layer not ready), Establish (LCP negotiation), Authenticate (optional peer authentication), Network (NCP configuration and data transfer), and Terminate (link shutdown). Transitions are triggered by LCP/NCP events and external signals such as carrier loss.

state-machine §4.1

The LCP Option Negotiation Automaton has ten states: Initial, Starting, Closed, Stopped, Closing, Stopping, Request-Sent, Ack-Received, Ack-Sent, and Opened. Events include Up/Down/Open/Close, Timeout (TO+/TO-), and received packet types (RCR+/RCR-/RCA/RCN/RTR/RTA/RUC/RXJ+/RXJ-/RXR); actions include sending configure/terminate/reject packets and notifying upper/lower layers.

wire-format §6.2

Authentication-Protocol Configuration Option: Type=3, Length>=4, Authentication-Protocol field is 2 octets (same value as corresponding PPP Protocol field), followed by variable Data. Defined values: 0xc023 (PAP), 0xc223 (CHAP).

security

wire-format §6

Configuration Option format: Type (1 octet), Length (1 octet, includes Type/Length/Data), and Data (variable). Used in Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject packets.

wire-format §5

LCP packet format: Code (1 octet identifying packet type), Identifier (1 octet for request/reply matching), Length (2 octets, includes Code/Identifier/Length/Data, MUST NOT exceed link MRU), and Data (variable). Octets beyond Length are treated as padding and ignored.

wire-format §6.4

Magic-Number Configuration Option: Type=5, Length=6, Magic-Number field is 4 octets chosen as randomly as possible. Used to detect looped-back links; if received Magic-Number equals the last sent Magic-Number, a Configure-Nak MUST be sent with a different value.

wire-format §6.1

Maximum-Receive-Unit (MRU) Configuration Option: Type=1, Length=4, Maximum-Receive-Unit field is 2 octets specifying the maximum number of octets in the Information and Padding fields, excluding framing, Protocol field, FCS, and transparency bytes. Default is 1500 octets.

wire-format §2

PPP encapsulation consists of three fields transmitted left to right: Protocol (8 or 16 bits), Information (variable, up to MRU), and Padding (optional). The Protocol field identifies the encapsulated datagram; default MRU for Information plus Padding is 1500 octets.

ip