idnits 2.17.1 draft-ietf-ippcp-deflate-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '... This document SHOULD be read in conjunction with [IPCOMP] and MUST...' RFC 2119 keyword, line 155: '...tion (IPCA). The IPCA MUST define the...' RFC 2119 keyword, line 192: '... implementations SHOULD NOT attempt to...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 121 has weird spacing: '...mit.edu mad...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 1998) is 9564 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Bradner97' is mentioned on line 139, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-ippcp-protocol-04 ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. 'Deutsch96') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'IPDOI') -- Possible downref: Non-RFC (?) normative reference: ref. 'Corpus90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Gailly95' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Payload Compression Protocol Working Group TimeStep Corporation 3 Internet Draft 4 Expires in six months 5 February 18, 1998 7 IP Payload Compression Using DEFLATE 8 10 Status of this Memo 12 This document is a submission to the IETF Internet Protocol Payload 13 Compression Protocol (IPPCP) Working Group. Comments are solicited 14 and should be addressed to the working group mailing list or to the 15 editor. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six 23 months and may be updated, replaced, or obsolete by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes a compression method based on the DEFLATE 39 compression algorithm. This document defines the application of 40 the DEFLATE algorithm to the IP Payload Compression Protocol. 42 Internet Draft IP Payload Compression Using DEFLATE Feb-98 44 Table of Contents 46 1. Introduction...................................................2 47 1.1 The DEFLATE Compression Algorithm...........................2 48 1.2 Licensing...................................................3 49 1.3 Specification of Requirements...............................3 50 2. DEFLATE Algorithm Implementation...............................4 51 2.1 Compression.................................................4 52 2.2 Decompression...............................................4 53 3. Thresholds.....................................................5 54 4. IPSec Transform Identifier.....................................5 55 5. Security Considerations........................................5 56 6. References.....................................................5 57 7. Acknowledgments................................................5 58 8. Editor's Address...............................................6 60 1. Introduction 62 The IP Payload Compression Protocol allows the compression of IP 63 datagrams by supporting different compression algorithms. This 64 document describes how to integrate the DEFLATE compression 65 algorithm [Deutsch96] into IPCOMP [IPCOMP]. 67 This document SHOULD be read in conjunction with [IPCOMP] and MUST 68 be taken in its context. 70 1.1 The DEFLATE Compression Algorithm 72 The 'deflate' compression format [Deutsch96], as used by the PKZIP 73 and gzip compressors and as embodied in the freely and widely 74 distributed zlib [Gailly95] library source code, has the following 75 features: 77 o an apparently unencumbered encoding and compression algorithm, 78 with an open and publicly-available specification. 80 o low-overhead escape mechanism for incompressible data. The PPP 81 Deflate specification offers options to reduce that overhead 82 further. 84 o heavily used for many years in networks, on modem and other 85 point-to-point links to transfer files for personal computers 86 and workstations. 88 o easily achieves 2:1 compression on the Calgary corpus[Corpus90] 89 using less than 64KBytes of memory on both sender and receive. 91 Internet Draft IP Payload Compression Using DEFLATE Feb-98 93 1.2 Licensing 95 The zlib source is widely and freely available, subject to the 96 following copyright: 98 (C) 1995 Jean-Loup Gailly and Mark Adler 100 This software is provided 'as-is',without any express or implied 101 warranty. In no event will the authors be held liable for any 102 damages arising from the use of this software. 104 Permission is granted to anyone to use this software for any 105 purpose, including commercial applications, and to alter it and 106 redistribute it freely, subject to the following restrictions: 108 1. The origin of this software must not be misrepresented; you 109 must not claim that you wrote the original software. If you 110 use this software in a product, an acknowledgment in the 111 product documentation would be appreciated but is not 112 required. 114 2. Altered source versions must be plainly marked as such, and 115 must not be misrepresented as being the original software. 117 3. This notice may not be removed or altered from any source 118 distribution. 120 Jean-Loup Gailly Mark Adler 121 gzip@prep.ai.mit.edu madler@alumni.caltech.edu 123 If you use the zlib library in a product, we would appreciate 124 *not* receiving lengthy legal documents to sign. The sources are 125 provided for free but without warranty of any kind. The library 126 has been entirely written by Jean-Loup Gailly and Mark Adler; it 127 does not include third-party code. 129 The deflate format and compression algorithm are based on Lempel- 130 Ziv LZ77 compression; extensive research has been done by the GNU 131 Project and the Portable Network Graphics working group supporting 132 its patent free status. 134 1.3 Specification of Requirements 136 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 137 NOT", and "MAY" that appear in this document are to be interpreted 138 as described in [Bradner97]. 140 Internet Draft IP Payload Compression Using DEFLATE Feb-98 142 2. DEFLATE Algorithm Implementation 144 The DEFLATE compression algorithm was designed by Phil Katz and its 145 details are publicly available in [Deutsch96]. Thus it is a good 146 freely available algorithm to implement within IPCOMP. 148 Compression and decompression algorithm details should be followed 149 as outlined in [Deutsch96] or the use of a software library may be 150 preferable. 152 2.1 Compression 154 As defined in [IPCOMP], the compression process is determined by 155 the IP Compression Association (IPCA). The IPCA MUST define the 156 DEFLATE algorithm for the process within this document to take 157 place. 159 The compression process entails compressing the data from the IP 160 datagram and placing the result after the IPComp header. For 161 example, compressing a TCP datagram; 163 Before: IP TCP ... 164 After: IP IPCOMP (TCP ...) 166 Please note how everything after the IPCOMP header is compressed. 168 DEFLATE allows for a number of compression levels ranging from best 169 compression but slow to fast compression. The level that one 170 compresses data is implementation dependant since it is always 171 compatible with the decompression algorithm. 173 2.2 Decompression 175 As in the compression process, the IPCA defines the parameters and 176 algorithm to utilize for the decompression process. 178 As defined in [IPCOMP] the data after the IPComp header is 179 decompressed and replaces the IPComp header within the IP header. 181 Decompression using the DEFLATE algorithm follows the decompression 182 process defined in [Deutsch96]. 184 Internet Draft IP Payload Compression Using DEFLATE Feb-98 186 3. Thresholds 188 As stated in [IPCOMP], small buffers do not compress well or at all 189 as well as fast links since the time it takes to compress is slower 190 than the time to transport the data. Informal tests show that the 191 average buffer size that produces larger results is around 90 192 bytes. Thus implementations SHOULD NOT attempt to compress buffers 193 smaller than 90 bytes. 195 4. IPSec Transform Identifier 197 [IPDOI] states that the ISAKMP IPCOMP transform ID for the DEFLATE 198 compression algorithm is 2. No other ISAKMP parameters are 199 required for the IPCOMP DEFLATE algorithm. 201 5. Security Considerations 203 This document does not add any further security considerations that 204 [IPCOMP] and [Deutsch96] have already declared. 206 6. References 208 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP 209 Payload Compression Protocol (IPComp)", draft-ietf- 210 ippcp-protocol-04 212 [Deutsch96] P. Deutsch, "DEFLATE Compressed Data Format 213 Specification version 1.3", RFC1951, May 1996 215 [IPDOI] Pipper, D. "The Internet IP Security Domain of 216 Interpretation for ISAKMP", draft-ietf-ipsec-ipsec-doi- 217 06 219 [Corpus90] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text 220 Compression", Prentice_Hall, Englewood Cliffs NJ, 1990. 221 The compression corpus itself can be found in 222 ftp://ftp.uu.net/pub/archiving/zip/ 224 [Gailly95] Gailly, J.-L., "Zlib 0.95 beta" 226 7. Acknowledgments 228 The author wishes to thank all of the active members of the IPPCP 229 working group especially Abraham Shacham and Naganand Dorswamy. 231 Internet Draft IP Payload Compression Using DEFLATE Feb-98 233 8. Editor's Address 235 Roy Pereira 236 237 TimeStep Corporation 238 +1 (613) 599-3610 x 4808 240 The IP Payload Compression Protocol (IPPCP) working group can be 241 contacted via email (ippcp@cisco.com) or through its chair: 243 Naganand Dorswamy 244 Bay Networks 245