IP Payload Compression Protocol (IPComp)
RFC 2393

Document Type RFC - Proposed Standard (December 1998; No errata)
Obsoleted by RFC 3173
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2393 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         A. Shacham
Request for Comments: 2393                                         Cisco
Category: Standards Track                                     R. Monsour
                                                              R. Pereira
                                                               M. Thomas
                                                      AltaVista Internet
                                                           December 1998

                IP Payload Compression Protocol (IPComp)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document describes a protocol intended to provide lossless
   compression for Internet Protocol datagrams in an Internet

1. Introduction

   IP payload compression is a protocol to reduce the size of IP
   datagrams.  This protocol will increase the overall communication
   performance between a pair of communicating hosts/gateways ("nodes")
   by compressing the datagrams, provided the nodes have sufficient
   computation power, through either CPU capacity or a compression
   coprocessor, and the communication is over slow or congested links.

   IP payload compression is especially useful when encryption is
   applied to IP datagrams.  Encrypting the IP datagram causes the data
   to be random in nature, rendering compression at lower protocol
   layers (e.g., PPP Compression Control Protocol [RFC-1962])
   ineffective.  If both compression and encryption are required,
   compression MUST be applied before encryption.

Shacham, et. al.            Standards Track                     [Page 1]
RFC 2393                         IPComp                    December 1998

   This document defines the IP payload compression protocol (IPComp),
   the IPComp packet structure, the IPComp Association (IPCA), and
   several methods to negotiate the IPCA.

   Other documents shall specify how a specific compression algorithm
   can be used with the IP payload compression protocol.  Such
   algorithms are beyond the scope of this document.

1.1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC-2119].

2. Compression Process

   The compression processing of IP datagrams has two phases:
   compressing of outbound IP datagrams ("compression") and
   decompressing of inbound datagrams ("decompression").  The
   compression processing MUST be lossless, ensuring that the IP
   datagram, after being compressed and decompressed, is identical to
   the original IP datagram.

   Each IP datagram is compressed and decompressed by itself without any
   relation to other datagrams ("stateless compression"), as IP
   datagrams may arrive out of order or not arrive at all.  Each
   compressed IP datagram encapsulates a single IP payload.

   Processing of inbound IP datagrams MUST support both compressed and
   non-compressed IP datagrams, in order to meet the non-expansion
   policy requirements, as defined in section 2.2.

   The compression of outbound IP datagrams MUST be done before any IP
   security processing, such as encryption and authentication, and
   before any fragmentation of the IP datagram.  In addition, in IP
   version 6 [RFC-2460], the compression of outbound IP datagrams MUST
   be done before the addition of either a Hop-by-Hop Options header or
   a Routing Header, since both carry information that must be examined
   and processed by possibly every node along a packet's delivery path,
   and therefore MUST be sent in the original form.

   Similarly, the decompression of inbound IP datagrams MUST be done
   after the reassembly of the IP datagrams, and after the completion of
   all IP security processing, such as authentication and decryption.

Shacham, et. al.            Standards Track                     [Page 2]
RFC 2393                         IPComp                    December 1998

2.1. Compressed Payload

   The compression is applied to a single array of octets, which are
   contiguous in the IP datagram.  This array of octets always ends at
   the last octet of the IP packet payload.  Note: a contiguous array of
   octets in the IP datagram may be not contiguous in physical memory.

   In IP version 4 [RFC-0791], the compression is applied to the upper
Show full document text