[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ippcp-protocol-01.txt
As the IP Payload Compression Protocol WG is a spin-off of IPSec, the
attached draft may be of interest to this WG. The document reflects the
resolutions of the IPPCP WG meeting in IETF 39 on August 13, 1997.
To keep the separation of the WGs, please forward your comments to the IPPCP
WG at ippcp@external.cisco.com
Cheers,
avram
==== I-D start ===
INTERNET-DRAFT A. Shacham, Cisco
IP Payload Compression Protocol Working Group R. Monsour, Hi/fn
Expires in six months R. Pereira, TimeStep
M. Thomas, AltaVista Internet
September 1997
IP Payload Compression Protocol (IPComp)
<draft-ietf-ippcp-protocol-01.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 view the entire list of current Internet-Drafts, 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 document describes a protocol intended to provide lossless
compression for Internet Protocol datagrams in an Internet
environment.
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, causing the data to be random in nature,
rendering compression at lower protocol layers (e.g., PPP Compression
Control Protocol [RFC-1962]) ineffective.
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.
Shacham, Monsour, Pereira, Thomas [Page 1]
INTERNET DRAFT IPComp September 1997
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].
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 datagram.
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-1883], 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.
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
layer protocol (ULP) payload of the IP datagram. No portion of the
IP header or the IP header options is compressed.
Shacham, Monsour, Pereira, Thomas [Page 2]
INTERNET DRAFT IPComp September 1997
In the IPv6 context, IPComp is viewed as an end-to-end payload, and
therefore MUST apply after hop-by-hop, routing, and fragmentation
extension headers. The compression is applied starting at the first
IP Header Option field which does not carry information that must be
examined and processed by nodes along a packet's delivery path, if
such IP Header Option field exists, and continues to the ULP payload
of the IP datagram.
The size of a compressed payload MUST be in whole octet units.
As defined in section 3, an IPComp header is inserted immediately
preceding the compressed payload. The original IP header is modified
to indicate the usage of the IPComp protocol and the reduced size of
the IP datagram. The original content of the Next Header field is
stored in the IPComp header.
The decompression is applied to a single contiguous array of octets
in the IP datagram. The start of the array of octets immediately
follows the IPComp header and ends at the last octet of the IP
payload. If the decompression process is successfully completed, the
IP header is modified to indicate the size of the decompressed IP
datagram, and the original next header as stored in the IPComp
header. The IPComp header is removed from the IP datagram and the
decompressed payload immediately follows the IP header.
2.2. Non-Expansion Policy
If the size of a compressed IP datagram, including the IP header,
the IPComp header as defined in section 3, and the compressed
payload, is not smaller than the size of the original IP datagram,
the IP datagram MUST be sent in the original non-compressed form.
To clarify: If an IP datagram is sent non-compressed, no IPComp
header is added to the datagram. 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 that has been previously compressed
tends not to compress any further. The 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 to
avoid the performance hit. For example, if the compression of i
consecutive IP datagrams of an IPCA fails, the next k IP datagrams
are sent without attempting compression. If the next j datagrams
are also failing to compress, the next k+n datagrams are sent without
attempting compression. Once a datagram is compressed successfully,
the normal process of IPComp restarts. The adaptive algorithm
including all the related thresholds is implementation dependent.
Shacham, Monsour, Pereira, Thomas [Page 3]
INTERNET DRAFT IPComp September 1997
During the processing of the payload, the compression algorithm
MAY periodically apply a test to determine the compressibility of
the processed data, similar to the requirements of [V42BIS]. The
nature of the test is implementation dependent. Once the
compression algorithm detects that the data is non-compressible,
the algorithm SHOULD stop processing the data, and the payload is
sent in the original non-compressed form.
3. Compressed IP Datagram Header Structure
A compressed IP datagram is encapsulated by modifying the IP header
and inserting an IPComp header immediately preceding the compressed
payload. This section defines the IP header modifications both in
IPv4 and IPv6, and the structure of the IPComp header.
3.1. IPv4 Header Modifications
The following IPv4 header fields are set:
Total Length
The length of the entire encapsulated IP datagram, including
the IP header, the IPComp header and the compressed payload.
Protocol
The Protocol field is set to 108, IPComp Datagram, [RFC-1700].
All other IPv4 header fields are kept unchanged, including any header
options.
3.2. IPv6 Header Modifications
The following IPv6 header fields are set:
Payload Length
The length of the compressed IP payload.
Next Header
The Next Header field is set to 108, IPComp Datagram,
[RFC-1700].
All other IPv6 header fields are kept unchanged, including any
non-compressed header options.
The IPComp header is placed in an IPv6 packet using the same rules as
the IPv6 Fragment Header. However if an IPv6 packet contains both an
IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header
MUST preceed the IPComp header in the packet.
Shacham, Monsour, Pereira, Thomas [Page 4]
INTERNET DRAFT IPComp September 1997
3.3. IPComp Header Structure
The four octet header has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Flags | Compression Parameter Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8-bit selector. Stores the IPv4 Protocol field or the IPv6
Next Header field of the original IP header.
Flags
8-bit field. Reserved for future use. Must be set to zero.
Compression Parameter Index (CPI)
16-bit index. The CPI is stored in network order. The values
0-63 are defined by IANA and are used for manual setup, which
requires no additional information. The values 64-61439 are
negotiated between the two nodes in definition of an IPComp
Association, as defined in section 4. The values 61440-65535
are for private use among mutually consenting parties.
4. IPComp Association (IPCA) Negotiation
To utilize the IPComp protocol, two nodes MUST first establish an
IPComp Association (IPCA) between them. The IPCA includes all
required information for the operation of IPComp, including the
Compression Parameter Index (CPI), the mode of operation, the
compression algorithm to be used, and any required parameter for the
selected compression algorithm. The IPComp mode of operation is
either a node-to-node policy where IPComp is applied to every IP
packet between the nodes, or an ULP session based policy where only
selected ULP sessions between the nodes are using IPComp. For each
IPCA, a different compression algorithm may be negotiated in each
direction, or only one direction may be compressed. The default is
"no IPComp compression".
The IPCA is established by dynamic negotiations or by static
configuration. The dynamic negotiations SHOULD use the Internet
Security Association and Key Management Protocol [ISAKMP], where
IPSec is present. The dynamic negotiations MAY be implemented
through a different protocol.
Shacham, Monsour, Pereira, Thomas [Page 5]
INTERNET DRAFT IPComp September 1997
4.1. Use of ISAKMP
For IPComp in the context of IP Security, ISAKMP provides the
necessary mechanisms to establish IPCA. IPComp Association is
negotiated by the initiator using a Proposal Payload, which would
include one or more Transform Payloads. The Proposal Payload would
specify a compression protocol in the protocol id field and each
Transform Payload would contain the specific compression method(s)
being offered to the responder.
In the Internet IP Security Domain of Interpretation (DOI) [SECDOI],
IPComp is negotiated as the Protocol ID PROTO_IPCOMP. The
compression algorithm is negotiated as one of the defined IPCOMP
Transform Identifiers.
4.2. Use of Non-ISAKMP Protocol
The dynamic negotiations MAY be implemented through a protocol other
than ISAKMP. Such protocol is beyond the scope of this document.
4.3. Static Configuration
Nodes may establish IPComp Associations using static configuration.
For this method, a limited number of Compression Parameters Indexes
(CPIs) is designated to represent a list of specific compression
methods.
5. Security Considerations
IP payload compression potentially reduces the security of the
Internet, similar to the effects of IP encapsulation [RFC-2003]. For
example, IPComp 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 is not located in its normal
positions within the datagram, 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. A filtering border router can filter the
datagram only if it shares the IPComp 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 IPComp Association to the border router. This might,
more rarely, also apply to the IPComp Association used for outgoing
datagrams.
When IPComp is used in the context of IPSec, it is not believed to
have an effect on the underlying security functionality provide by
the IPSec protocol; i.e., the use of compression is not known to
degrade or alter the nature of the underlying security architecture
or the encryption technologies used to implement it.
Shacham, Monsour, Pereira, Thomas [Page 6]
INTERNET DRAFT IPComp September 1997
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-1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
RFC 1962, June 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-08.txt, Work in Progress,
July 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.
[V42BIS] CCITT, "Data Compression Procedures for Data Circuit
Terminating Equipment (DCE) Using Error Correction
Procedures", Recommendation V.42 bis, January 1990.
Authors' Information
Abraham Shacham
Cisco Systems
101 Cooper Street
Santa Cruz, California 95060
United States of America
Email: shacham@cisco.com
Robert Monsour
Hi/fn Inc.
2105 Hamilton Avenue, Suite 230
San Jose, California 95125
United States of America
Email: rmonsour@hifn.com
Shacham, Monsour, Pereira, Thomas [Page 7]
INTERNET DRAFT IPComp September 1997
Roy Pereira
TimeStep Corporation
362 Terry Fox Drive
Kanata, Ontario K2K 2P5
Canada
Email: rpereira@timestep.com
Matt Thomas
AltaVista Internet Software
30 Porter Road
Littleton, Massachusetts 01460
United States of America
Email: matt.thomas@altavista-software.com
Working Group
The IP Payload Compression Protocol (IPPCP) working group can be
contacted through its chair:
Naganand Dorswamy
Bay Networks
Email: naganand@baynetworks.com
Shacham, Monsour, Pereira, Thomas Expires in six months [Page 8]
=== I-D end ===