idnits 2.17.1 draft-ietf-pppext-deflate-00.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-16) 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 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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 142: '...or, the receiver MAY momentarily force...' RFC 2119 keyword, line 147: '... it SHOULD send a Reset-Request L...' RFC 2119 keyword, line 152: '... The receiver MUST discard all comp...' RFC 2119 keyword, line 169: '... MAY transmit an additional Reset...' RFC 2119 keyword, line 173: '... receiver MUST transmit enough Re...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 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 (September 1995) is 10441 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Woods 3 Internet Draft 4 expires in six months September 1995 6 PPP Deflate Protocol 7 draft-ietf-pppext-deflate-00.txt 9 Status of this Memo 11 This document is the product of the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 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 are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 Please check the 1id-abstracts.txt listing contained in the 29 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 30 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 31 current status of any Internet Draft. 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. 38 The PPP Compression Control Protocol [2] provides a method to 39 negotiate and utilize compression protocols over PPP encapsulated 40 links. 42 This document describes the use of the PPP Deflate compression 43 protocol for compressing PPP encapsulated packets. 45 1. Introduction 47 The 'deflate' compression format[3], as used by the PKZIP and gzip 48 compressors and as embodied in the freely and widely distributed 49 zlib[4] library source code, has the following features: 51 - an apparently unencumbered encoding and compression algorithm, 52 with an open and publically-available specification. 54 - low-overhead escape mechanism for incompressible data. The PPP 55 Deflate specification offers options to reduce that overhead 56 further. 58 - heavily used for many years in networks, on modem and other 59 point-to-point links to transfer files for personal computers 60 and workstations. 62 - easily achieves 2:1 compression on the Calgary corpus[5] using 63 less than 64KBytes of memory on both sender and receive. 65 1.1. Licensing 67 The zlib source is widely and freely available, subject to the 68 following copyright: 69 (C) 1995 Jean-loup Gailly and Mark Adler 71 This software is provided 'as-is', without any express or implied 72 warranty. In no event will the authors be held liable for any 73 damages arising from the use of this software. 75 Permission is granted to anyone to use this software for any 76 purpose, including commercial applications, and to alter it and 77 redistribute it freely, subject to the following restrictions: 79 1. The origin of this software must not be misrepresented; you 80 must not claim that you wrote the original software. If you 81 use this software in a product, an acknowledgment in the 82 product documentation would be appreciated but is not 83 required. 84 2. Altered source versions must be plainly marked as such, and 85 must not be misrepresented as being the original software. 86 3. This notice may not be removed or altered from any source 87 distribution. 89 Jean-loup Gailly Mark Adler 90 gzip@prep.ai.mit.edu madler@alumni.caltech.edu 91 If you use the zlib library in a product, we would appreciate *not* 92 receiving lengthy legal documents to sign. The sources are provided 93 for free but without warranty of any kind. The library has been 94 entirely written by Jean-loup Gailly and Mark Adler; it does not 95 include third-party code. 97 The deflate format and compression algorithm are based on Lempel-Ziv 98 LZ77 compression; extensive research has been done by the GNU Project 99 and the Portable Network Graphics working group supporting its patent 100 free status. 102 2. PPP Deflate Packets 104 Before any PPP Deflate packets may be communicated, PPP must reach 105 the Network-Layer Protocol phase, and the CCP Control Protocol must 106 reach the Opened state. 108 Exactly one PPP Deflate datagram is encapsulated in the PPP 109 Information field, where the PPP Protocol field contains 0xFD or 110 0xFB. 0xFD is used when the PPP multilink protocol is not used or 111 "above" multilink. 0xFB is used "below" multilink, to compress 112 independently on individual links of a multilink bundle. 114 The maximum length of the PPP Deflate datagram transmitted over a PPP 115 link is the same as the maximum length of the Information field of a 116 PPP encapsulated packet. 118 Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF 119 and neither 0xFD nor 0xFB are compressed. Other PPP packets are 120 always sent uncompressed. Control packets are infrequent and should 121 not be compressed for robustness. 123 Padding 125 PPP Deflate packets require the previous negotiation of the Self- 126 Describing-Padding Configuration Option [6] if padding is added to 127 packets. If no padding is added, than Self-Describing-Padding is 128 not required. 130 Reliability and Sequencing 132 PPP Deflate requires the packets to be delivered in sequence. It 133 relies on Reset-Request and Reset-Ack LCP packets or on 134 renegotiation of the Compression Control Protocol [2] to indicate 135 loss of synchronization between the transmitter and receiver. The 136 LCP FCS detects corrupted packets and the normal mechanisms 137 discard them. Missing or out of order packets are detected by the 138 sequence number in each packet. The packet sequence number ought 139 to be checked before decoding the packet. 141 Instead of transmitting a Reset-Request packet when detecting a 142 sequence error, the receiver MAY momentarily force CCP to drop out 143 of the Opened state by transmitting a new CCP Configure-Request. 144 This method is more expensive than using Reset-Requests. 146 When the receiver first encounters an unexpected sequence number 147 it SHOULD send a Reset-Request LCP packet as defined in the 148 Compression Control Protocol. When the transmitter sends the 149 Reset-Ack or when the receiver receives a Reset-ACK, they must 150 reset the sequence number to zero, clear the compression 151 dictionary, and resume sending and receiving compressed packets. 152 The receiver MUST discard all compressed packets after detecting 153 an error and until it receives a Reset-Ack. This strategy can be 154 thought of as abandoning the transmission of one "file" and 155 starting the transmission of a new "file." 157 The transmitter must clear its compression history and respond 158 with a Reset-Ack each time it receives a Reset-Request, because it 159 cannot know if previous Reset-Acks reached the receiver. The 160 receiver need not do anything to its history when it receives a 161 Reset-Ack, because the transmitter will simply not refer to any 162 prior history ('deflate' is a sliding-window compressor). 164 When the link is busy, one decompression error is usually followed 165 by several more before the Reset-Ack can be received. It is 166 undesirable to transmit Reset-Requests more frequently than the 167 round-trip-time of the link, because redundant Reset-Requests 168 cause unnecessary compression dictionary clearing. The receiver 169 MAY transmit an additional Reset-Request each time it receives a 170 compressed or uncompressed packet until it finally receives a 171 Reset-Ack, but the receiver ought not transmit another Reset- 172 Request until the Reset-Ack for the previous one is late. The 173 receiver MUST transmit enough Reset-Request packets to ensure that 174 the transmitter receives at least one. For example, the receiver 175 might choose to not transmit another Reset-Request until after one 176 second (or, of course, a Reset-Ack has been received and 177 decompression resumed). 179 Data Expansion 181 'Deflate', as used in this standard, expands incompressible data 182 by approximately 14-18 bytes (8 bytes worst-case at the 'deflate' 183 level, two further bytes for the 'deflate' end-of-block and the 184 zero-length synchronization block header, two bytes of sequence 185 number, and two bytes to account for adding the PPP Protocol Field 186 to the transmitted data unit). 188 The BSD Compress draft proposal[7] describes an escape mechanism 189 for incompressible data that trades off a layering violation for 190 the irritating complications of variable and potentially 191 unpredictable effective MRU lengths. That direct escape mechanism 192 (and much of the text of its description) is used here as well. 194 If an incompressible data packet does not fit within the MRU of 195 the link, the packet MUST be sent in its original form without CCP 196 encapsulation; PPP packets with significant data expansion that do 197 not exceed the MRU of the link SHOULD be sent in their original 198 form without CCP encapsulation. In both of these cases, the 199 transmitter must increment the sequence number, as future 200 encapsulated packets will depend on the correct reception of some 201 number of unencapsulated packets. 203 When a PPP packet is received with PPP Protocol numbers in the 204 range 0x0000 to 0x3FFF, (except, of course, 0xFD and 0xFB) it is 205 assumed that the packet would have caused expansion. The packet 206 is locally added to the compression history. (Given the 207 definition of the 'deflate' format, a convenient method of doing 208 this is to locally "decompress" a stored-block header of the 209 appropriate length, followed by the actual data block; or the data 210 can simply be appended to the receiver's history, depending on 211 implementation details.) 213 Sending incompressible packets in their native encapsulation 214 avoids maximum transmission unit complications. If uncompressed 215 packets could be larger than their native form, then it would be 216 necessary for the upper layers of an implementation to treat the 217 PPP link as if it had a smaller MTU, to ensure that compressed 218 incompressible packets are never larger than the negotiated PPP 219 MTU. 221 Using native encapsulation for incompressible packets complicates 222 the implementation. The transmitter and the receiver must start 223 putting information into the compression dictionary starting with 224 the same packets, without relying upon seeing a compressed packet 225 for synchronization. The first few packets after clearing the 226 dictionary are usually incompressible, and so are likely to sent 227 in their native encapsulation, just like packets before 228 compression is turned on. If CCP or LCP packets are handled 229 separately from Network-Layer packets (e.g. a "daemon" for control 230 packets and "kernel code" for data packets), care must be taken to 231 ensure that the transmitter synchronizes clearing the dictionary 232 with the transmission of the configure-ACK or Reset-Ack that 233 starts compression, and the receiver must similarly ensure that 234 its dictionary is cleared before it processes the next packet. 236 2.1. Packet Format 238 A summary of the PPP Deflate packet format is shown below. 240 The fields are transmitted from left to right. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | PPP Protocol | Sequence | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Data ... 248 +-+-+-+-+-+-+-+-+ 250 PPP Protocol 252 The PPP Protocol field is described in the Point-to-Point Protocol 253 Encapsulation [1]. 255 When the PPP Deflate compression protocol is successfully 256 negotiated by the PPP Compression Control Protocol [2], the value 257 of the protocol field is 0xFD or 0xFB. This value MAY be 258 compressed when Protocol-Field-Compression is negotiated. 260 Sequence 262 The sequence number is sent most significant octet first. It 263 starts at 0 when the dictionary is cleared, and is incremented by 264 1 for each packet, including uncompressed packets. The sequence 265 number after 65535 is zero. In other words, the sequence number 266 "wraps" in the usual way. 268 The sequence number ensures that lost or out of order packets do 269 not cause the compression databases of the peers to become 270 unsynchronized. When an unexpected sequence number is 271 encountered, the dictionaries must be resynchronized with a CCP 272 Reset-Request or Configure-Request. The packet sequence number 273 can be checked before a compressed packet is decoded. 275 Data 277 The compressed PPP encapsulated packet, consisting of the Protocol 278 and Data fields of the original, uncompressed packet follows. 280 The Protocol field compression MUST be applied to the protocol 281 field in the original packet before the sequence number is 282 computed or the entire packet is compressed, regardless of whether 283 the PPP protocol field compression has been negotiated. Thus, if 284 the original protocol number was less than 0x100, it must be 285 compressed to a single byte. 287 The basic format of the compressed data is precisely described by 288 the 'Deflate' Compressed Data Format Specification[3]. Each 289 transmitted packet must begin at a 'deflate' block boundary, to 290 ensure synchronization when incompressible data resets the 291 transmitter's state; to ensure this, each transmitted packet must 292 be terminated with a zero-length 'deflate' non-compressed block 293 (BTYPE of 00). This means that the last four bytes of the 294 compressed format must be 0x00 0x00 0xFF 0xFF. These bytes MUST 295 be removed before transmission; the receiver can reinsert them if 296 required by the implementation. 298 3. Configuration Option Format 300 Description 302 The CCP PPP Deflate Configuration Option negotiates the use of PPP 303 Deflate on the link. By default or ultimate disagreement, no 304 compression is used. 306 A summary of the PPP Deflate Configuration Option format is shown 307 below. The fields are transmitted from left to right. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length |Window | Method| MBZ |Chk| 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Type 317 24 for PPP Deflate. 319 Length 321 3 323 Window 325 Represents the maximum window size the decompressor is willing to 326 allocate; expressed as the base-2 logarithm of the LZ77 window 327 size, minus 8. 'Deflate' compliant decompressors must be willing 328 to accept the maximum 32KB window size, represented by a value of 329 7. A 'deflate' compliant compressor is at liberty to use a 330 reduced window size, so a PPP Deflate compressor MUST either honor 331 the restriction requested or reject the option. 333 Method 335 Must be the binary number 1000. Represents the 'zlib' Compression 336 Method identifier of '8' for 'deflate' compression with up to 32K 337 window size. 339 MBZ 341 Must be all 0 bits. 343 Chk 345 Must be 00 to specify sequence number check method. 347 Security Considerations 349 Security issues are not discussed in this memo. 351 References 353 [1] Simpson, W.A., "The Point-to-Point Protocol (PPP)", work in 354 progress. 356 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 357 progress. 359 [3] Deutsch, L.P., "'Deflate' Compressed Data Format 360 Specification", draft available in 361 quest.jpl.nasa.gov:/beta/zlib/deflate-1.1.doc and 362 ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc. 364 [4] Gailly, J.-L., "Zlib 0.95 beta", available in 365 quest.jpl.nasa.gov:/beta/zlib/zlib-0.95.tar.gz. 367 [5] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression", 368 Prentice_Hall, Englewood Cliffs NJ, 1990. The compression 369 corpus itself can be found in ftp.uu.net:/pub/archiving/zip/. 371 [6] Simpson, W.A., "PPP LCP Extensions", work in progress. 373 [7] Schryver, V., "PPP BSD Compression Protocol", work in progress. 375 Acknowledgments 377 William Simpson provided 379 the very valuable idea of not using any additional header bytes for 380 incompressible packets. 382 Chair's Address 384 The working group can be contacted via the current chair: 386 Fred Baker 387 Advanced Computer Communications 388 315 Bollay Drive 389 Santa Barbara, California 93117 391 EMail: fbaker@acc.com 393 Author's Address 395 Questions about this memo can also be directed to: 397 John Woods 398 Proteon, Inc. 399 9 Technology Drive 400 Westborough MA 01581-1799 402 (508) 898-2800 ext. 2651 404 EMail: jfw@funhouse.com 405 Table of Contents 407 1. Introduction .......................................... 1 408 1.1 Licensing ....................................... 1 410 2. PPP Deflate Packets ................................... 3 411 2.1 Packet Format ................................... 5 413 3. Configuration Option Format ........................... 8 415 SECURITY CONSIDERATIONS ...................................... 10 417 REFERENCES ................................................... 10 419 ACKNOWLEDGEMENTS ............................................. 10 421 CHAIR'S ADDRESS .............................................. 11 423 AUTHOR'S ADDRESS ............................................. 11