The PPP Compression Control Protocol (CCP)

A different compression algorithm may be negotiated in each direction of the link for speed, cost, memory, or other considerations, or only one direction may be compressed. This asymmetric design allows implementations to optimize per-direction independently.

A proprietary OUI-based Configuration Option (type 0) was created to allow vendors to negotiate proprietary compression algorithms without encumbering IANA with proprietary number requests. The OUI mechanism reuses IEEE 802 vendor identifiers already assigned to vendors.

registry

Reset-Request/Reset-Ack codes were added (beyond the standard LCP codes 1-7) to enable signaling a decompression failure in one direction of a compressed link without affecting or tearing down traffic in the other direction, which would occur if LCP were renegotiated.

Unassigned CCP Option Type values 4-15 are explicitly reserved for freely available compression algorithms with no license fees, distinguishing them from the named proprietary/licensed options (16-21) which may have licensing restrictions.

CCP uses the same packet exchange mechanism as LCP with codes 1-7 (Configure-Request through Code-Reject) plus two additional codes 14 and 15. Other unrecognized codes should result in Code-Rejects, maintaining LCP-compatible behavior.

If no compression algorithm can be agreed upon during negotiation, no compression will be used and the link continues to operate without compression. If link reliability was separately negotiated, it continues until LCP is re-negotiated.

Since the first matching compression option will be used, it is recommended that any known OUI compression options be transmitted first, before common options, to ensure proprietary algorithms are preferred when mutually supported.

After receiving a Configure-Nak, a new Configure-Request SHOULD be sent with only the single preferred option, adjusted as specified in the Configure-Nak.

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. An implementation should give up only after user intervention or a configurable amount of time.

Before any compressed packets may be communicated, PPP must reach the Network-Layer Protocol phase and CCP must reach the Opened state. Only one primary compression algorithm in each direction is in use at a time, negotiated prior to sending the first compressed frame.

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

If a CCP Configuration Option is unrecognized, a Configure-Reject MUST be sent. If an option is recognized but not acceptable due to values, a Configure-NAK MUST be sent with the option modified appropriately and MUST contain only those options that will be acceptable.

Individual link compressed datagrams MUST use PPP Protocol field type hex 00FB when using multiple PPP links to a single destination with per-link compression.

On transmission, the Identifier field MUST be changed whenever the content of the Data field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MAY remain unchanged.

Since there may be several Reset-Acks in the pipe, the decompressor MUST be reset for each Reset-Ack which matches the currently expected identifier.

Upon reception of a Reset-Request, the transmitting compressor is reset to an initial state, and a CCP packet MUST be transmitted with Code 15 (Reset-Ack), with the Identifier field copied from the Reset-Request.

Vendors are strongly encouraged to employ a method of validating the compressed data or recognizing out-of-sync compressor/decompressor pairs. Each compression algorithm must supply a way of determining if data is being passed reliably, or must require use of a reliable transport such as LAPB.

Reset-Request (Code 14) and Reset-Ack (Code 15) provide a mechanism for indicating a decompression failure in one direction without affecting traffic in the other direction. Once a Reset-Request is sent, compressed packets received are discarded and another Reset-Request with the same Identifier is sent until a valid Reset-Ack is received.

The Compression Control Protocol (CCP) is responsible for configuring, enabling, and disabling data compression algorithms on both ends of a PPP link. It uses the same packet exchange mechanism as LCP, extended with Reset-Request and Reset-Ack codes (14 and 15) for decompression failure signaling.

email

CCP Option Type field values: 0=OUI (proprietary), 1=Predictor type 1, 2=Predictor type 2, 3=Puddle Jumper, 4-15=unassigned (reserved for freely available algorithms with no license fees), 16=HP PPC, 17=Stac Electronics LZS, 18=Microsoft PPC, 19=Gandalf FZA, 20=V.42bis, 21=BSD LZW Compress, 255=Reserved.

registry

The RFC explicitly states that security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are defined for the compression negotiation or compressed data stream itself.

security

CCP must reach the Opened state (analogous to LCP Opened) before compressed datagrams can be sent. The trigger to enter Opened state is completion of Configure-Request/Configure-Ack exchange. A decompression failure triggers transition to sending Reset-Request until Reset-Ack received, then returns to normal operation.

CCP is encapsulated in the PPP Information field with PPP Protocol field value 0x80FD for standard CCP, or 0x80FB (Individual Link Compression Control Protocol) when individual link data compression is used in a multiple-link connection.

Compressed datagrams use PPP Protocol field 0x00FD. When individual link compression is used in a multiple-link connection, the PPP Protocol field MUST be 0x00FB (Individual link compressed datagram).

Other Compression Type Configuration Option format: Type (1 octet, values 1-254), Length (1 octet, >= 2), Values (variable, zero or more octets as determined by the compression protocol).

Proprietary Compression OUI Configuration Option format: Type (1 octet, value 0), Length (1 octet, >= 6), IEEE OUI (3 octets, most-significant-first, canonical bit order), Subtype (1 octet, OUI-specific), Values (variable, vendor-defined).

Reset-Request and Reset-Ack packets contain: Code (1 octet, 14 or 15), Identifier (1 octet), Length (2 octets), and Data (variable, zero to peer's MRU minus four octets of uninterpreted data).