summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2393.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2393.txt')
-rw-r--r--doc/rfc/rfc2393.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2393.txt b/doc/rfc/rfc2393.txt
new file mode 100644
index 0000000..1efe5ae
--- /dev/null
+++ b/doc/rfc/rfc2393.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group A. Shacham
+Request for Comments: 2393 Cisco
+Category: Standards Track R. Monsour
+ Hi/fn
+ R. Pereira
+ TimeStep
+ 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.
+
+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. 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",
+ "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 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
+ layer protocol (ULP) payload of the IP datagram. No portion of the
+ IP header or the IP header options is compressed.
+
+ In the IPv6 context, IPComp is viewed as an end-to-end payload, and
+ MUST not apply to hop-by-hop, routing, and fragmentation extension
+ headers. The compression is applied starting at the first IP Header
+ Option field that 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, generated by the compression
+ algorithm, 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 (IPv6) or
+ protocol (IPv4) 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 total size of a compressed ULP payload and the IPComp header,
+ as defined in section 3, is not smaller than the size of the original
+ ULP payload, 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.
+
+
+
+
+Shacham, et. al. Standards Track [Page 3]
+
+RFC 2393 IPComp December 1998
+
+
+ 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. Such an adaptive algorithm,
+ including all the related thresholds, is implementation dependent.
+
+ 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 algorithm 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 before transmitting the
+ compressed IP datagram:
+
+ 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].
+
+
+
+
+Shacham, et. al. Standards Track [Page 4]
+
+RFC 2393 IPComp December 1998
+
+
+ Header Checksum
+
+ The Internet Header checksum [RFC-0791] of the IP header.
+
+ All other IPv4 header fields are kept unchanged, including any header
+ options.
+
+3.2. IPv6 Header Modifications
+
+ The following IPv6 header fields are set before transmitting the
+ compressed IP datagram:
+
+ 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 precede the IPComp header in the packet.
+
+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.
+ MUST be ignored by the receiving node.
+
+
+
+Shacham, et. al. Standards Track [Page 5]
+
+RFC 2393 IPComp December 1998
+
+
+ Compression Parameter Index (CPI)
+
+ 16-bit index. The CPI is stored in network order. The values
+ 0-63 define well-known compression algorithms, which require no
+ additional information, and are used for manual setup. The
+ values themselves are identical to IPCOMP Transform identifiers
+ as defined in [SECDOI]. Consult [SECDOI] for an initial set of
+ defined values and for instructions on how to assign new values.
+ The values 64-255 are reserved for future use. The values
+ 256-61439 are negotiated between the two nodes in definition of
+ an IPComp Association, as defined in section 4. Note: When
+ negotiating one of the well-known algorithms, the nodes MAY
+ select a CPI in the pre-defined range 0-63. The values
+ 61440-65535 are for private use among mutually consenting
+ parties. Both nodes participating can select a CPI value
+ independently of each other and there is no relationships
+ between the two separately chosen CPIs. The outbound IPComp
+ header MUST use the CPI value chosen by the decompressing node.
+ The CPI in combination with the destination IP address uniquely
+ identifies the compression algorithm characteristics for the
+ datagram.
+
+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 manual
+ 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.
+
+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
+
+
+
+Shacham, et. al. Standards Track [Page 6]
+
+RFC 2393 IPComp December 1998
+
+
+ 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), 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. Manual Configuration
+
+ Nodes may establish IPComp Associations using manual 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
+
+ When IPComp is used in the context of IPSec, it is believed not to
+ have an effect on the underlying security functionality provided 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.
+
+ When IPComp is used without IPSec, IP payload compression potentially
+ reduces the security of the Internet, similar to the effects of IP
+ encapsulation [RFC-2003]. For example, IPComp may make 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 layer 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.
+
+
+
+
+
+Shacham, et. al. Standards Track [Page 7]
+
+RFC 2393 IPComp December 1998
+
+
+6. References
+
+ [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+ RFC 1700, October 1994. Or see:
+ http://www.iana.org/numbers.html
+
+ [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [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", BCP 14, RFC 2119, March 1997.
+
+ [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
+ "Internet Security Association and Key Management Protocol
+ (ISAKMP)", RFC 2408, November 1998.
+
+ [SECDOI] Piper, D., "The Internet IP Security Domain of
+ Interpretation for ISAKMP", RFC 2407, November 1998.
+
+ [V42BIS] CCITT, "Data Compression Procedures for Data Circuit
+ Terminating Equipment (DCE) Using Error Correction
+ Procedures", Recommendation V.42 bis, January 1990.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et. al. Standards Track [Page 8]
+
+RFC 2393 IPComp December 1998
+
+
+Authors' Addresses
+
+ Abraham Shacham
+ Cisco Systems
+ 170 West Tasman Drive
+ San Jose, California 95134
+ 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
+
+
+ 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, et. al. Standards Track [Page 9]
+
+RFC 2393 IPComp December 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et. al. Standards Track [Page 10]
+