1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2394.txt b/doc/rfc/rfc2394.txt
new file mode 100644
index 0000000..0aa7c18
--- /dev/null
+++ b/doc/rfc/rfc2394.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       R. Pereira
+Request for Comments: 2394                        TimeStep Corporation
+Category: Informational                                  December 1998
+
+
+                  IP Payload Compression Using DEFLATE
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This document describes a compression method based on the DEFLATE
+   compression algorithm.  This document defines the application of the
+   DEFLATE algorithm to the IP Payload Compression Protocol.
+
+Table of Contents
+
+   1. Introduction...................................................2
+     1.1 The DEFLATE Compression Algorithm...........................2
+     1.2 Licensing...................................................2
+     1.3 Specification of Requirements...............................3
+   2. DEFLATE Algorithm Implementation...............................3
+     2.1 Compression.................................................3
+     2.2 Decompression...............................................4
+   3. Thresholds.....................................................4
+   4. IPSec Transform Identifier.....................................4
+   5. Security Considerations........................................4
+   6. References.....................................................5
+   7. Acknowledgments................................................5
+   8. Editor's Address...............................................5
+   9. Full Copyright Statement.......................................6
+
+
+
+
+
+
+
+
+
+
+
+
+Pereira                      Informational                      [Page 1]
+
+RFC 2394          IP Payload Compression Using DEFLATE     December 1998
+
+
+1. Introduction
+
+   The IP Payload Compression Protocol allows the compression of IP
+   datagrams by supporting different compression algorithms.  This
+   document describes how to integrate the DEFLATE compression algorithm
+   [Deutsch96] into IPCOMP [IPCOMP].
+
+   This document SHOULD be read in conjunction with [IPCOMP] and MUST be
+   taken in its context.
+
+1.1 The DEFLATE Compression Algorithm
+
+   The 'deflate' compression format [Deutsch96], as used by the PKZIP
+   and gzip compressors and as embodied in the freely and widely
+   distributed zlib [Gailly95] library source code, has the following
+   features:
+
+   o an apparently unencumbered encoding and compression algorithm,
+     with an open and publicly-available specification.
+
+   o low-overhead escape mechanism for incompressible data.  The PPP
+     Deflate specification offers options to reduce that overhead
+     further.
+
+   o heavily used for many years in networks, on modem and other point-
+     to-point links to transfer files for personal computers and
+     workstations.
+
+   o easily achieves 2:1 compression on the Calgary corpus [Corpus90]
+     using less than 64KBytes of memory on both sender and receive.
+
+1.2 Licensing
+
+   The zlib source is widely and freely available, subject to the
+   following copyright:
+
+      (C) 1995 Jean-Loup Gailly and Mark Adler
+
+      This software is provided 'as-is', without any express or implied
+      warranty.  In no event will the authors be held liable for any
+      damages arising from the use of this software.
+
+      Permission is granted to anyone to use this software for any
+      purpose, including commercial applications, and to alter it and
+      redistribute it freely, subject to the following restrictions:
+
+
+
+
+
+
+Pereira                      Informational                      [Page 2]
+
+RFC 2394          IP Payload Compression Using DEFLATE     December 1998
+
+
+      1. The origin of this software must not be misrepresented; you
+         must not claim that you wrote the original software. If you use
+         this software in a product, an acknowledgment in the product
+         documentation would be appreciated but is not required.
+
+      2. Altered source versions must be plainly marked as such, and
+         must not be misrepresented as being the original software.
+
+   3. This notice may not be removed or altered from any source
+         distribution.
+
+         Jean-Loup Gailly        Mark Adler
+         gzip@prep.ai.mit.edu    madler@alumni.caltech.edu
+
+      If you use the zlib library in a product, we would appreciate
+      *not* receiving lengthy legal documents to sign. The sources are
+      provided for free but without warranty of any kind.  The library
+      has been entirely written by Jean-Loup Gailly and Mark Adler; it
+      does not include third-party code.
+
+   The deflate format and compression algorithm are based on Lempel-Ziv
+   LZ77 compression; extensive research has been done by the GNU Project
+   and the Portable Network Graphics working group supporting its patent
+   free status.
+
+1.3 Specification of Requirements
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   and "MAY" that appear in this document are to be interpreted as
+   described in [Bradner97].
+
+2. DEFLATE Algorithm Implementation
+
+   The DEFLATE compression algorithm was designed by Phil Katz and its
+   details are publicly available in [Deutsch96].  Thus it is a good
+   freely available algorithm to implement within IPCOMP.
+
+   Compression and decompression algorithm details should be followed as
+   outlined in [Deutsch96] or the use of a software library may be
+   preferable.  Since IPComp is a stateless protocol, history MUST be
+   cleared between packets when either compressing or decompressing.
+
+2.1 Compression
+
+   As defined in [IPCOMP], the compression process is determined by the
+   IP Compression Association (IPCA).  The IPCA MUST define the DEFLATE
+   algorithm for the process within this document to take place.
+
+
+
+
+Pereira                      Informational                      [Page 3]
+
+RFC 2394          IP Payload Compression Using DEFLATE     December 1998
+
+
+   The compression process entails compressing the data from the IP
+   datagram and placing the result after the IPComp header.  For
+   example, compressing a TCP datagram;
+
+   Before:  IP TCP ...
+   After:   IP IPCOMP (TCP ...)
+
+   Please note how everything after the IPCOMP header is compressed.
+
+   DEFLATE allows for a number of compression levels ranging from best
+   compression but slow to fast compression.  The level that one
+   compresses data is implementation dependant since it is always
+   compatible with the decompression algorithm.
+
+2.2 Decompression
+
+   As in the compression process, the IPCA defines the parameters and
+   algorithm to utilize for the decompression process.
+
+   As defined in [IPCOMP] the data after the IPComp header is
+   decompressed and replaces the IPComp header within the IP header.
+
+   Decompression using the DEFLATE algorithm follows the decompression
+   process defined in [Deutsch96].
+
+3. Thresholds
+
+   As stated in [IPCOMP], compression on small buffers does not usually
+   work as well as on fast links since the time it takes to compress is
+   slower than the time to transport the data.  Informal tests show that
+   the average buffer size that produces larger results is around 90
+   bytes.  Thus implementations SHOULD NOT attempt to compress buffers
+   smaller than 90 bytes.
+
+   Other than a packet size limit, no compressibility test as defined in
+   [IPCOMP] is outlined in this document.
+
+4. IPSec Transform Identifier
+
+   [IPDOI] states that the ISAKMP IPCOMP transform ID for the DEFLATE
+   compression algorithm is IPCOMP_DEFLATE.  No other ISAKMP parameters
+   are required for the IPCOMP DEFLATE algorithm.
+
+5. Security Considerations
+
+   This document does not add any further security considerations that
+   [IPCOMP] and [Deutsch96] have already declared.
+
+
+
+
+Pereira                      Informational                      [Page 4]
+
+RFC 2394          IP Payload Compression Using DEFLATE     December 1998
+
+
+6. References
+
+   [IPCOMP]    Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
+               Payload Compression Protocol (IPComp)", RFC 2393,
+               December 1998.
+
+   [Deutsch96] Deutsch, P., "DEFLATE Compressed Data Format
+               Specification version 1.3", RFC 1951, May 1996.
+
+   [IPDOI]     Piper, D., "The Internet IP Security Domain of
+               Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [Corpus90]  Bell, T.C., Cleary, G. G. and Witten, I.H., "Text
+               Compression", Prentice_Hall, Englewood Cliffs NJ, 1990.
+               The compression corpus itself can be found in
+               ftp://ftp.uu.net/pub/archiving/zip/
+
+   [Gailly95]  Gailly, J.-L., "Zlib 0.95 beta"
+
+7. Acknowledgments
+
+   The author wishes to thank all of the active members of the IPPCP
+   working group especially Abraham Shacham and Naganand Doraswamy.
+
+8. Editor's Address
+
+   Roy Pereira
+   TimeStep Corporation
+
+   Phone: +1 (613) 599-3610 x 4808
+   EMail: rpereira@timestep.com
+
+
+   The IP Payload Compression Protocol (IPPCP) working group can be
+   contacted via email (ippcp@cisco.com) or through its chair:
+
+   Naganand Dorswamy
+   Bay Networks
+
+   EMail: naganand@baynetworks.com
+
+
+
+
+
+
+
+
+
+
+
+Pereira                      Informational                      [Page 5]
+
+RFC 2394          IP Payload Compression Using DEFLATE     December 1998
+
+
+9.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pereira                      Informational                      [Page 6]
+