IP Payload Compression Protocol Working Group A. Shacham
INTERNET-DRAFT Cisco Systems
Expires in six months July 1997
IP Payload Compression Protocol (IPComp)
<draft-ietf-ippcp-protocol-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This memo describes a protocol intended to provide compression
services for IP datagrams in an Internet environment.
1. Introduction
IP compression is a mechanism to reduce the size of IP datagrams.
This protocol will increase the overall communication performance
between a pair of communicating hosts/gateways by compressing the
datagrams, provided the hosts/gateways have sufficient CPU capacity
and the communication is over slow or congested links. IP
compression is especially useful when encryption is applied to IP
datagrams and therefore layer 2 (e.g., PPP) compression is not
effective.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119
[RFC-2119].
Shacham [Page 1]
INTERNET DRAFT IPComp July 1997
2. Compression Policy Negotiations
A policy of compression of IP datagram is negotiated as part of a
Security Association (SA) using the Internet Security Association and
Key Management Protocol (ISAKMP) [ISAKMP].
When the negotiated SA includes IP Encapsulating Security Payload
(ESP), IP datagram compression MUST be negotiated. IP datagram
compression MAY be negotiated even when encryption is not part of the
SA, when the hosts try to preserve communication bandwidth.
In the Internet IP Security Domain of Interpretation (DOI) [SECDOI],
the following SA compression attribute is used in phase II of
an ISAKMP/Oakley negotiations:
Class: Compression Format (algorithm).
Value: 12.
Type: Basic (B).
The Compression Format value of zero (0) is "no compression".
The Compression Format values 1-255 are identical to the PPP
compression types, where up-to-date values of the Type are specified
in the most recent "Assigned Numbers" RFC [RFC-1700]. Values
256-61439 are reserved to IANA. Values 61440-65535 are for private
use among mutually consenting parties.
A different compression algorithm may be negotiated in each
direction, or only one direction may be compressed. The default
value is "no compression".
3. 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.
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. 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.
Processing of inbound IP datagrams MUST support both Compressed and
non-compressed IP datagrams.
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. The Compression is applied to the
whole IP datagram, including the IP header and the upper layer
protocol (ULP) payload. The size of a Compressed datagram is always
in whole octet units.
Shacham [Page 2]
INTERNET DRAFT IPComp July 1997
If the size of a Compressed IP datagram, including the encapsulating
IP header as defined in section 4, is not smaller than the size of
the original IP datagram, the IP datagram MUST be sent in the
original non-compressed form. This policy ensures saving the
Decompression processing cycles and avoiding incurring IP datagram
fragmentation when the expanded datagram is larger than MTU.
Small IP datagrams are likely to expand as a result of Compression.
Therefore, a numeric threshold SHOULD be applied before Compression,
where IP datagrams of size smaller than the threshold are sent in
the original form without attempting Compression. The numeric
threshold is implementation dependent.
An IP datagram with payload, which has been previously compressed,
tends not to compress any further. Such previously compressed
payload may be the result of external processes, such as compression
applied by an upper layer in the communication stack, or by an
off-line compression utility. An adaptive algorithm, SHOULD be
implemented in order to avoid the performance hit. The adaptive
algorithm is implementation dependent.
4. Compressed IP Datagram Structure
A compressed IP datagram is encapsulated by inserting an outer IP
header before the datagram's existing (inner) IP header, similar to
the method of IP Encapsulation within IP [RFC-2003]. Each compressed
IP datagram encapsulates a single IP datagram.
4.1. IP version 4
The following outer IP header version 4 [RFC-0791] fields are kept
from the original inner IP header:
Version.
The Type of Service (TOS).
Identification, Flags, Fragment Offset.
The Time To Live (TTL).
Source Address.
Destination Address.
The following outer IP header version 4 fields are set after a
successful compression:
The Internet Header Length (IHL).
The length of the outer IP header measured in 32-bit words
[RFC-0791].
Total Length
The length of the entire encapsulated IP datagram, including
the outer IP header and the compressed IP datagram.
Shacham [Page 3]
INTERNET DRAFT IPComp July 1997
Protocol
The Protocol field is set to 106, Compressed IP Datagram,
[RFC-1700].
Header Checksum
The Internet Header checksum [RFC-0791] of the outer IP header.
Options
No options present in the inner IP header are copied to the
outer IP header.
4.2. IP version 6
The following outer IP header version 6 [RFC-1833] fields are kept
from the original inner IP header:
Version.
Priority.
Flow Label.
Hop Limit.
Source Address.
Destination Address.
IPv6 Extension Headers.
The following outer IP header version 6 fields are set after a
successful compression:
Payload Length
The length of the compressed IP datagram.
Next Header
The Next Header field is set to 106, Compressed IP Datagram,
[RFC-1700].
5. Security Considerations
IP compression potentially reduces the security of the Internet,
similar to the effects of IP encapsulation [RFC-2003]. For example,
IP compression makes it difficult for border routers to filter
datagrams based on header fields. In particular, the original value
of the Protocol field in the IP header, and any transport header
fields within the datagram, such as port numbers, are neither
located in their normal positions within the datagram nor presented
in their original values after compression. Filtering border router
can filter the datagram only if it shares the security association
used for the compression. To allow this sort of compression in
environments in which all packets need to be filtered (or at least
accounted for), a mechanism must be in place for the receiving node
to securely communicate the security association to the border
Shacham [Page 4]
INTERNET DRAFT IPComp July 1997
router. This might, more rarely, also apply to the security
association used for outgoing datagrams.
6. References
[RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
October 1994.
[RFC-1883] Deering, S. , Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, April 1996.
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC-2119] Bradner, S. , "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
"Internet Security Association and Key Management
Protocol (ISAKMP)", Internet-Draft:
draft-ietf-ipsec-isakmp-07.txt, Work in Progress,
February 1997.
[SECDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", Internet-Draft:
draft-ietf-ipsec-ipsec-doi-02.txt, Work in Progress,
February 1997.
Author's Address
Abraham Shacham
Cisco Systems
101 Cooper Street
Santa Cruz, California 95060
United States of America
Phone: +1 408 457 5200
EMail: shacham@cisco.com
Shacham Expires in six months [Page 5]
