rfc-1332

The PPP Internet Protocol Control Protocol (IPCP)

G. McGregor
date1992-05 streamIETF areaint wgpppext statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc1332 doi10.17487/RFC1332 errataview
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (20)

design-rationale §3.1

The IP-Addresses Configuration Option (Type 1) has been deprecated. Implementation experience showed it is difficult to ensure negotiation convergence in all cases using this option. The IP-Address option (Type 3) replaces it and its use is preferred.

ip

design-rationale §4.1

There may be implementations that have problems with only one slot (Max-Slot-Id = 0). The example implementation in RFC 1144 will only work with 3 through 254 slots, which informs the recommended minimum of 4 slots.

ip, tcp

interoperability-note §3.1 MAY

Backward compatibility with RFC 1172 implementations requires support for the deprecated IP-Addresses option (Type 1). Support for this option MAY be removed after the IPCP protocol status advances to Internet Draft Standard.

ip

normative-requirement §2 SHOULD

An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.

tcp, ip

normative-requirement §2.1 MUST

Before any IP packets may be communicated, PPP must reach the Network-Layer Protocol phase and the IP Control Protocol must reach the Opened state.

tcp, ip

normative-requirement §3.3 SHOULD

If negotiation about the remote IP-address is required and the peer did not provide the option in its Configure-Request, the IP-Address option SHOULD be appended to a Configure-Nak with a value acceptable as the remote IP-address or all-zeros to request the peer provide it.

ip

normative-requirement §2 SHOULD NOT

IPCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPCP packets received before this phase is reached should be silently discarded.

tcp, ip

normative-requirement §2 SHOULD

Only IPCP Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.

tcp, ip

normative-requirement §3.1 SHOULD NOT

The IP-Addresses option SHOULD NOT be sent in a Configure-Request if a Configure-Request has been received which includes either an IP-Addresses or IP-Address option. It MAY be sent if a Configure-Reject is received for the IP-Address option.

ip

normative-requirement §4.1 MUST NOT

The slot identifier must not be compressed if there is no ability for the PPP link level to indicate an error in reception to the decompression module, as synchronization after errors depends on receiving a packet with the slot identifier.

ip, tcp

protocol-element §2

IPCP is the NCP responsible for configuring, enabling, and disabling the IP protocol modules on both ends of a PPP point-to-point link. It uses the same packet exchange mechanism as LCP and is identified by PPP Protocol field value 0x8021.

tcp, ip

protocol-element §3.2

The IP-Compression-Protocol Configuration Option provides a way to negotiate the use of a specific compression protocol. By default, compression is not enabled. Value 0x002d designates Van Jacobson Compressed TCP/IP.

ip, tcp

protocol-element §4

Van Jacobson TCP/IP header compression reduces TCP/IP headers to as few as three bytes, providing significant improvement on slow serial lines, particularly for interactive traffic. Each end must separately request this option for bi-directional compression.

tcp, ip

registry §3

IPCP Configuration Option Type field assignments: 1 = IP-Addresses (deprecated), 2 = IP-Compression-Protocol, 3 = IP-Address. Current values are maintained in the Assigned Numbers RFC.

registry, ip

security-consideration §Security Considerations

Security issues are not discussed in this memo. The document explicitly defers all security considerations.

security, ip

wire-format §2.1

Exactly one IP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0021 (Internet Protocol). Larger IP datagrams must be fragmented as necessary.

tcp, ip

wire-format §3.3

IP-Address Configuration Option (Type 3): Type (1 octet) = 3, Length (1 octet) = 6, IP-Address (4 octets) containing the desired local address. All-zeros requests that the peer provide the IP-Address information.

ip

wire-format §3.2

IP-Compression-Protocol Configuration Option (Type 2): Type (1 octet) = 2, Length (1 octet) >= 4, IP-Compression-Protocol (2 octets) identifying the compression protocol using PPP Data Link Layer Protocol field values, followed by optional Data field.

ip

wire-format §4

PPP Protocol field values for IP packet types: 0x0021 = Type IP (non-TCP, fragment, or uncompressible), 0x002d = Compressed TCP (TCP/IP headers replaced by compressed header), 0x002f = Uncompressed TCP (IP protocol field replaced by slot identifier).

ip, tcp

wire-format §4.1

Van Jacobson compression Configuration Option: Type (1 octet) = 2, Length (1 octet) = 6, IP-Compression-Protocol (2 octets) = 0x002d, Max-Slot-Id (1 octet) = maximum slot identifier (actual slots minus one), Comp-Slot-Id (1 octet) = whether slot identifier may be compressed (0 = must not, 1 = may).

ip, tcp