rfc-1570

PPP LCP Extensions

W. Simpson (Editor)
date1994-01 streamIETF areaint wgpppext statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc1570 doi10.17487/RFC1570
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]

updated by

updates

Extracted elements (26)

design-rationale §2.4.1

Compound-Frames minimizes negotiation latency by reducing the number of frames exchanged: the peer SHOULD respond with a Configure-Ack followed in a compound frame by its own LCP Configure-Request and any desired NCP Configure-Requests, reducing the minimum configuration round-trips to 4 frames.

design-rationale §1.1

Identification is defined as part of LCP rather than a separate PPP Protocol so its benefits are available during the earliest stage of Link Establishment, enabling operator identification of the peer even when negotiation is not converging.

design-rationale §1.2

Time-Remaining is defined as a separate LCP Code rather than a Configuration-Option so that changes and warning messages may occur dynamically during a session and after authentication has determined session limits.

interoperability-note §2.1.2

The Null FCS SHOULD only be used with network-layer and transport protocols that have an end-to-end checksum available (e.g., TCP/IP, or UDP/IP with checksum enabled). In a heterogeneous environment, Null FCS SHOULD be negotiated together with a non-null FCS option.

normative-requirement §2.4 MUST

Compound-Frames MUST be negotiated together with the Self-Describing-Padding option. Additionally, if FCS-Alternatives has been negotiated, self-describing padding MUST always be added to compound frames.

normative-requirement §2.1 MUST

Frames sent during any phase other than Authentication and Network-Layer Protocol phases MUST contain the default FCS, regardless of any FCS-Alternatives negotiation.

normative-requirement §2.1.1 MUST

On receipt of a LCP Configure-Request or Terminate-Request packet, the implementation MUST change to the default FCS for both transmission and reception.

normative-requirement §2.2 MUST

The first self-describing pad octet MUST contain the value one (1). When no padding would otherwise be required but the final octet of the PPP Information field contains a value in the range 1 through MPV, at least one self-describing pad octet MUST be added.

normative-requirement §1.1 MUST

The Identifier field in an Identification packet MUST be changed for each Identification sent.

normative-requirement §1.1 MUST NOT

The Message field in Identification and Time-Remaining packets MUST NOT affect operation of the protocol; it is intended to be human readable only.

normative-requirement §1.1 MUST

Until the Magic-Number Configuration Option has been successfully negotiated, the Magic-Number in both Identification and Time-Remaining packets MUST be transmitted as zero.

normative-requirement §2.1.2 MUST

When using Null FCS, any configuration (LCP or NCP) or authentication packet sent MUST include the FCS, and when received MUST have the FCS verified.

protocol-element §2.3

Callback (Configuration Option Type 13) allows a PPP implementation to request a dial-up peer to call back. When successfully negotiated and authentication is complete, the link immediately proceeds to the Termination phase; the peer then re-establishes the link without negotiating Callback.

protocol-element §2.4

Compound-Frames (Configuration Option Type 15) allows multiple PPP encapsulated packets with determinate lengths to be aggregated into a single frame. The PPP Protocol value of 1 is reserved as the Padding Protocol, signaling the end of data in a compound frame.

protocol-element §2.1

FCS-Alternatives (Configuration Option Type 9) allows negotiating a different FCS format (Null, CCITT 16-bit, or CCITT 32-bit) or eliminating the FCS altogether. It is negotiated independently in each direction and takes effect only during Authentication and Network-Layer Protocol phases.

protocol-element §1.1

Identification (Code 12) is a new LCP Link Maintenance packet that allows an implementation to identify itself to its peer. It may be sent at any time, including before LCP reaches the Opened state, and requires no response.

protocol-element §2.2

Self-Describing-Padding (Configuration Option Type 10) allows an implementation to indicate it understands self-describing pads appended to the PPP Information field. Each pad octet contains its 1-based index; the final octet gives the total pad count to remove. The Maximum-Pad-Value (MPV) limits the maximum number of pad octets.

protocol-element §1.2

Time-Remaining (Code 13) is a Link Maintenance packet for notifying the peer of seconds remaining in the session. It is advisory only, may only be sent in the LCP Opened state, and requires no response. A value of 0xffffffff in the Seconds-Remaining field indicates no timeout.

registry §1

This document assigns LCP Code field values 12 (Identification) and 13 (Time-Remaining), and LCP Configuration Option Type field values 9 (FCS-Alternatives), 10 (Self-Describing-Padding), 13 (Callback), and 15 (Compound-Frames), as referenced in the Assigned Numbers RFC.

registry

security-consideration §2.3

Security issues related to Callback center on authentication: a peer agreeing to Callback SHOULD request the Authentication-Protocol Configuration Option so that user information from authentication can be used to determine or restrict callback locations and billing. Mutual authentication SHOULD also be requested when the link is called back.

security

wire-format §2.3

Callback option format: Type (1 octet, value 13), Length (1 octet, >= 3), Operation (1 octet: 0=auth-determined, 1=dialing string, 2=location identifier, 3=E.164 number, 4=distinguished name), followed by variable-length Message.

wire-format §2.4

Compound-Frames option format: Type (1 octet, value 15), Length (1 octet, value 2). No additional fields; option presence alone signals capability.

wire-format §2.1

FCS-Alternatives option format: Type (1 octet, value 9), Length (1 octet, value 3), Options (1 octet bitmask: bit 1=Null FCS, bit 2=CCITT 16-bit FCS, bit 4=CCITT 32-bit FCS).

wire-format §1.1

Identification packet format: Code (1 octet, value 12), Identifier (1 octet), Length (2 octets, >= 8), Magic-Number (4 octets), followed by a variable-length Message field.

wire-format §2.2

Self-Describing-Padding option format: Type (1 octet, value 10), Length (1 octet, value 3), Maximum (1 octet, range 1–255, typical values 2, 4, or 8).

wire-format §1.2

Time-Remaining packet format: Code (1 octet, value 13), Identifier (1 octet), Length (2 octets, >= 12), Magic-Number (4 octets), Seconds-Remaining (4 octets, unsigned, MSB first), followed by a variable-length Message field.