idnits 2.17.1 draft-degermark-ipv6-hc-08.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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. ** There are 13 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC-1144]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: IPv6 is not meant to be used over links that can deliver a significant fraction of damaged packets to the IPv6 module. This means that links must have a very low bit-error rate or that link-level frames must be protected by strong checksums, forward error correction or something of that nature. Header compression SHOULD not be used for IPv4 without strong link-level checksums. Damaged frames will thus be discarded by the link layer. The link layer implementation might indicate to the header compression module that a frame was damaged, but it cannot say what packet stream it belonged to as it might be the CID that is damaged. Moreover, frames may disappear without the link layer implementation's knowledge, for example if the link is a multi-hop link where frames can be dropped due to congestion at each hop. The kind of link errors that a header compression module should deal with and protect against will thus be packet loss. -- 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 (December 15, 1998) is 9264 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: 'RFC 1144' is mentioned on line 895, but not defined == Unused Reference: 'RFC-791' is defined on line 2006, but no explicit reference was found in the text == Unused Reference: 'RFC-1700' is defined on line 2017, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 2020, but no explicit reference was found in the text == Unused Reference: 'RFC-1827' is defined on line 2023, but no explicit reference was found in the text == Unused Reference: 'ICMPv6' is defined on line 2032, but no explicit reference was found in the text == Unused Reference: 'RFC-2004' is defined on line 2036, but no explicit reference was found in the text ** Obsolete normative reference: RFC 761 (ref. 'RFC-768') (Obsoleted by RFC 793, RFC 7805) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1553 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Downref: Normative reference to an Historic RFC: RFC 1828 ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1885 (ref. 'ICMPv6') (Obsoleted by RFC 2463) -- Possible downref: Non-RFC (?) normative reference: ref. 'CRTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPP-HC' Summary: 20 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mikael Degermark /Lulea University 3 INTERNET-DRAFT Bjorn Nordgren /Telia Research AB 4 Expires: April 1999 Stephen Pink /Swedish Institute of Computer Science 5 Sweden 6 December 15, 1998 8 IP Header Compression 9 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 27 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document describes how to compress multiple IP headers and TCP 34 and UDP headers per-hop over point-to-point links. The methods can be 35 applied to of IPv6 base and extension headers, IPv4 headers, TCP and 36 UDP headers, and encapsulated IPv6 and IPv4 headers. 38 Headers of typical UDP or TCP packets can be compressed down to 4-7 39 octets including the 2 octet UDP or TCP checksum. This largely 40 removes the negative impact of large IP headers and allows efficient 41 use of bandwidth on low- and medium-speed links. 43 The compression algorithms are specifically designed to work well 44 over links with nontrivial packet-loss rates. Several wireless and 45 modem technologies result in such links. 47 TABLE OF CONTENTS 48 1. Introduction..............................................3 49 2. Terminology...............................................5 50 3. Compression method........................................8 51 3.1. Packet types.......................................9 52 3.2. Lost packets in TCP packet streams................10 53 3.3. Lost packets in UDP and non-TCP packet streams....10 54 4. Grouping packets into packet streams.....................14 55 4.1. Guidelines for grouping packets...................15 56 5. Size Issues..............................................17 57 5.1. Context identifiers...............................17 58 5.2. Size of the context...............................18 59 5.3. Size of full headers..............................18 60 5.3.1. Length fields in full TCP headers............19 61 5.3.2. Length fields in full non-TCP headers........19 62 6. Compressed Header Formats................................20 63 7. Compression of subheaders................................23 64 7.1. IPv6 Header.......................................25 65 7.2. IPv6 Extension Headers............................26 66 7.3. Options...........................................26 67 7.4. Hop-by-hop Options Header.........................27 68 7.5. Routing Header....................................28 69 7.6. Fragment Header...................................29 70 7.7. Destination Options Header........................30 71 7.8. No Next Header....................................30 72 7.9. Authentication Header.............................31 73 7.10. Encapsulating Security Payload Header.............31 74 7.11. UDP Header........................................32 75 7.12. TCP Header........................................33 76 7.13. IPv4 Header.......................................35 77 7.14 Minimal Encapsulation header......................37 78 8. Changing context identifiers.............................37 79 9. Rules for dropping or temporarily storing packets........37 80 10. Low-loss header compression for TCP .....................38 81 10.1. The "twice" algorithm............................39 82 10.2. Header Requests..................................39 83 11. Links that reorder packets...............................40 84 11.1. Reordering in non-TCP packet streams.............41 85 11.2. Reordering in TCP packet streams.................41 86 12. Hooks for additional header compression..................42 87 13. Demultiplexing...........................................42 88 14. Configuration Parameters.................................44 89 15. Implementation Status....................................45 90 16. Acknowledgments..........................................45 91 17. Security Considerations..................................46 92 18. Author's Addresses.......................................46 93 19. References...............................................46 95 1. Introduction 97 There are several reasons to do header compression on low- or 98 medium-speed links. Header compression can 100 * Improve interactive response time 102 For very low-speed links, echoing of characters may take longer 103 than 100-200 ms because of the time required to transmit large 104 headers. 100-200 ms is the maximum time people can tolerate 105 without feeling that the system is sluggish. 107 * Allow using small packets for bulk data with good line 108 efficiency 110 This is important when interactive (for example Telnet) and 111 bulk traffic (for example FTP) is mixed because the bulk data 112 should be carried in small packets to decrease the waiting time 113 when a packet with interactive data is caught behind a bulk 114 data packet. 116 Using small packet sizes for the FTP traffic in this case is a 117 global solution to a local problem. It will increase the load 118 on the network as it has to deal with many small packets. A 119 better solution might be to locally fragment the large packets 120 over the slow link. 122 * Allow using small packets for delay sensitive low data-rate 123 traffic 125 For such applications, for example voice, the time to fill a 126 packet with data is significant if packets are large. To get 127 low end-to-end delay small packets are preferred. Without 128 header compression, the smallest possible IPv6/UDP headers (48 129 octets) consume 19.2 kbit/s with a packet rate of 50 packets/s. 130 50 packets/s is equivalent to having 20 ms worth of voice 131 samples in each packet. IPv4/UDP headers consumes 11.2 kbit/s 132 at 50 packets/s. Tunneling or routing headers, for example to 133 support mobility, will increase the bandwidth consumed by 134 headers by 10-20 kbit/s. This should be compared with the 135 bandwidth required for the actual sound samples, for example 13 136 kbit/s with GSM encoding. Header compression can reduce the 137 bandwidth needed for headers significantly, in the example to 138 about 1.7 kbit/s. This enables higher quality voice 139 transmission over 14.4 and 28.8 kbit/s modems. 141 * Decrease header overhead. 143 A common size of TCP segments for bulk transfers over medium- 144 speed links is 512 octets today. When TCP segments are 145 tunneled, for example because Mobile IP is used, the 146 IPv6/IPv6/TCP header is 100 octets. Header compression will 147 decrease the header overhead for IPv6/TCP from 19.5 per cent to 148 less than 1 per cent, and for tunneled IPv4/TCP from 11.7 to 149 less than 1 per cent. This is a significant gain for line- 150 speeds as high as a few Mbit/s. 152 The IPv6 specification prescribes path MTU discovery, so with 153 IPv6 bulk TCP transfers should use segments larger than 512 154 octets when possible. Still, with 1400 octet segments (RFC 894 155 Ethernet encapsulation allows 1500 octet payloads, of which 100 156 octets are used for IP headers), header compression reduces 157 IPv6 header overhead from 7.1% to 0.4%. 159 * Reduce packet loss rate over lossy links. 161 Because fewer bits are sent per packet, the packet loss rate 162 will be lower for a given bit-error rate. This results in 163 higher throughput for TCP as the sending window can open up 164 more between losses, and in fewer lost packets for UDP. 166 The mechanisms described here are intended for a point-to-point link. 167 However, care has been taken to allow extensions for multi-access 168 links and multicast. 170 Headers that can be compressed include TCP, UDP, IPv4, and IPv6 base 171 and extension headers. For TCP packets, the mechanisms of Van 172 Jacobson [RFC-1144] are used to recover from loss. Two additional 173 mechanisms that increase the efficiency of VJ header compression over 174 lossy links are also described. For non-TCP packets, compression 175 slow-start and periodic header refreshes allow minimal periods of 176 packet discard after loss of a header that changes the context. There 177 are hooks for adding header compression schemes on top of UDP, for 178 example compression of RTP headers. 180 Header compression relies on many fields being constant or changing 181 seldomly in consecutive packets belonging to the same packet stream. 182 Fields that do not change between packets need not be transmitted at 183 all. Fields that change often with small and/or predictable values, 184 e.g., TCP sequence numbers, can be encoded incrementally so that the 185 number of bits needed for these fields decrease significantly. Only 186 fields that change often and randomly, e.g., checksums or 187 authentication data, need to be transmitted in every header. 189 The general principle of header compression is to occasionally send a 190 packet with a full header; subsequent compressed headers refer to the 191 context established by the full header and may contain incremental 192 changes to the context. 194 This header compression scheme does not require that all packets in 195 the same stream passes over the compressed link. However, for TCP 196 streams the difference between subsequent headers can become more 197 irregular and the compression rate can decrease. Neither is it 198 required that corresponding TCP data and acknowledgment packets 199 traverse the link in opposite directions. 201 This header compression scheme is useful on first-hop or last-hop 202 links as well as links in the middle of the network. When many packet 203 streams (several hundred) traverse the link, a phenomenon that could 204 be called CID thrashing could occur, where headers seldom can be 205 matched with an existing context and have to be sent uncompressed or 206 as full headers. It is up to an implementation to use techniques such 207 as hysteresis to ensure that the packet streams that give the highest 208 compression rates keep their context. Such techniques are more 209 likely to be needed in the middle of the network. 211 2. Terminology 213 This section explains some terms used in this document. 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC 2119. 219 Subheader 221 An IPv6 base header, an IPv6 extension header, an IPv4 header, 222 a UDP header, or a TCP header. 224 Header 226 A chain of subheaders. 228 Compress 230 The act of reducing the size of a header by removing header 231 fields or reducing the size of header fields. This is done in a 232 way such that a decompressor can reconstruct the header if its 233 context state is identical to the context state used when 234 compressing the header. 236 Decompress 238 The act of reconstructing a compressed header. 240 Context identifier (CID) 242 A small unique number identifying the context that should be 243 used to decompress a compressed header. Carried in full 244 headers and compressed headers. 246 Context 248 The state which the compressor uses to compress a header and 249 the decompressor uses to decompress a header. The context is 250 the uncompressed version of the last header sent (compressor) 251 or received (decompressor) over the link, except for fields in 252 the header that are included "as-is" in compressed headers or 253 can be inferred from, e.g., the size of the link-level frame. 255 The context for a packet stream is associated with a context 256 identifier. The context for non-TCP packet streams is also 257 associated with a generation. 259 Generation 261 For non-TCP packet streams, each new version of the context for 262 a given CID is associated with a generation: a small number 263 that is incremented whenever the context associated with that 264 CID changes. Carried by full and compressed non-TCP headers. 266 Packet stream 268 A sequence of packets whose headers are similar and share 269 context. For example, headers in a TCP packet stream have the 270 same source and final destination address, and the same port 271 numbers in the TCP header. Similarly, headers in a UDP packet 272 stream have the same source and destination address, and the 273 same port numbers in the UDP header. 275 Full header (header refresh) 277 An uncompressed header that updates or refreshes the context 278 for a packet stream. It carries a CID that will be used to 279 identify the context. 281 Full headers for non-TCP packet streams also carry the 282 generation of the context they update or refresh. 284 Regular header 286 A normal, uncompressed, header. Does not carry CID or 287 generation association. 289 Incorrect decompression 291 When a compressed and then decompressed header is different 292 from the uncompressed header. Usually due to mismatching 293 context between the compressor and decompressor or bit errors 294 during transmission of the compressed header. 296 Differential coding 298 A compression technique where the compressed value of a header 299 field is the difference between the current value of the field 300 and the value of the same field in the previous header 301 belonging to the same packet stream. A decompressor can thus 302 obtain the value of the field by adding the value in the 303 compressed header to its context. This technique is used for 304 TCP streams but not for non-TCP streams. 306 3. Compression method 308 Much of the header information stays the same over the life-time of a 309 packet stream. For non-TCP packet streams almost all fields of the 310 headers are constant. For TCP many fields are constant and others 311 change with small and predictable values. 313 To initiate compression of the headers of a packet stream, a full 314 header carrying a context identifier, CID, is transmitted over the 315 link. The compressor and decompressor store most fields of this full 316 header as context. The context consists of the fields of the header 317 whose values are constant and thus need not be sent over the link at 318 all, or change little between consecutive headers so that it uses 319 fewer bits to send the difference from the previous value compared to 320 sending the absolute value. 322 Any change in fields that are expected to be constant in a packet 323 stream will cause the compressor to send a full header again to 324 update the context at the decompressor. As long as the context is the 325 same at compressor and decompressor, headers can be decompressed to 326 be exactly as they were before compression. However, if a full header 327 or compressed header is lost during transmission, the context of the 328 decompressor may become obsolete as it is not updated properly. 329 Compressed headers will then be decompressed incorrectly. 331 IPv6 is not meant to be used over links that can deliver a 332 significant fraction of damaged packets to the IPv6 module. This 333 means that links must have a very low bit-error rate or that link- 334 level frames must be protected by strong checksums, forward error 335 correction or something of that nature. Header compression SHOULD 336 not be used for IPv4 without strong link-level checksums. Damaged 337 frames will thus be discarded by the link layer. The link layer 338 implementation might indicate to the header compression module that a 339 frame was damaged, but it cannot say what packet stream it belonged 340 to as it might be the CID that is damaged. Moreover, frames may 341 disappear without the link layer implementation's knowledge, for 342 example if the link is a multi-hop link where frames can be dropped 343 due to congestion at each hop. The kind of link errors that a header 344 compression module should deal with and protect against will thus be 345 packet loss. 347 So a header compression scheme needs mechanisms to update the context 348 at the decompressor and to detect or avoid incorrect decompression. 349 These mechanisms are very different for TCP and non-TCP streams, and 350 are described in sections 3.2 and 3.3. 352 The compression mechanisms in this document assume that packets are 353 not reordered between the compressor and decompressor. If the link 354 does reorder, section 11 describes mechanisms for ordering the 355 packets before decompression. It is also assumed that the link-layer 356 implementation can provide the length of packets, and that there is 357 no padding in UDP packets or tunneled packets. 359 3.1. Packet types 361 This compression method uses four packet types in addition to the 362 IPv4 and IPv6 packet types. The combination of link-level packet 363 type and the value of the first four bits of the packet uniquely 364 determines the packet type. Details on how these packet types are 365 represented are in section 13. 367 FULL_HEADER - indicates a packet with an uncompressed header, 368 including a CID and, if not a TCP packet, a generation. It 369 establishes or refreshes the context for the packet stream 370 identified by the CID. 372 COMPRESSED_NON_TCP - indicates a non-TCP packet with a compressed 373 header. The compressed header consists of a CID identifying what 374 context to use for decompression, a generation to detect an 375 inconsistent context and the randomly changing fields of the 376 header. 378 COMPRESSED_TCP - indicates a packet with a compressed TCP header, 379 containing a CID, a flag octet indentifying what fields have 380 changed, and the changed fields encoded as the difference from the 381 previous value. 383 COMPRESSED_TCP_NODELTA - indicates a packet with a compressed TCP 384 header where all fields that are normally sent as the difference 385 to the previous value are instead sent as-is. This packet type is 386 only sent as the response to a header request from the 387 decompressor. It must not be sent as the result of a 388 retransmission. 390 In addition to the packet types used for compression, regular IPv4 391 and IPv6 packets are used whenever a compressor decides to not 392 compress a packet. An additional packet type may be used to speed up 393 repair of TCP streams over links where the decompressor can send 394 packets to the compressor. 396 CONTEXT_STATE - indicates a special packet sent from the 397 decompressor to the compressor to communicate a list of (TCP) CIDs 398 for which synchronization has been lost. This packet is only sent 399 over a single link so it requires no IP header. The format is 400 shown in section 10.2. 402 3.2. Lost packets in TCP packet streams 404 Since TCP headers are compressed using the difference from the 405 previous TCP header, loss of a packet with a compressed or full 406 header will cause subsequent compressed headers to be decompressed 407 incorrectly because the context used for decompression was not 408 incremented properly. 410 Loss of a compressed TCP header will cause the TCP sequence numbers 411 of subsequently decompressed TCP headers to be off by k, where k is 412 the size of the lost segment. Such incorrectly decompressed TCP 413 headers will be discarded by the TCP receiver as the TCP checksum 414 reliably catches "off-by-k" errors in the sequence numbers for 415 plausible k. 417 TCP's repair mechanisms will eventually retransmit the discarded 418 segment and the compressor peeks into the TCP headers to detect when 419 TCP retransmits. When this happens, the compressor sends a full 420 header on the assumption that the retransmission was due to 421 mismatching compression state at the decompressor. [RFC-1144] has a 422 good explanation of this mechanism. 424 The mechanisms of section 10 should be used to speed up the repair of 425 the context. This is important over medium speed links with high 426 packet loss rates, for example wireless. Losing a timeout's worth of 427 packets due to inconsistent context after each packet lost over the 428 link is not acceptable, especially when the TCP connection is over 429 the wide area. 431 3.3. Lost packets in UDP and other non-TCP packet streams 433 Incorrectly decompressed headers of UDP packets and other non-TCP 434 packets are not so well-protected by checksums as TCP packets. There 435 are no sequence numbers that become "off-by-k" and virtually 436 guarantees a failed checksum as there are for TCP. The UDP checksum 437 only covers payload, UDP header, and pseudo header. The pseudo 438 header includes the source and destination addresses, the transport 439 protocol type and the length of the transport packet. Except for 440 those fields, large parts of the IPv6 header are not covered by the 441 UDP checksum. Moreover, other non-TCP headers lack checksums 442 altogether, for example fragments. 444 In order to safely avoid incorrect decompression of non-TCP headers, 445 each version of the context for non-TCP packet streams is identified 446 by a generation, a small number that is carried by the full headers 447 that establish and refresh the context. Compressed headers carry the 448 generation value of the context that were used to compress them. 449 When a decompressor sees that a compressed header carries a 450 generation value other than the generation of its context for that 451 packet stream, the context is not up to date and the packet must be 452 discarded or stored until a full header establishes correct context. 454 Differential coding is not used for non-TCP streams, so compressed 455 non-TCP headers do not change the context. Thus, loss of a 456 compressed header does not invalidate subsequent packets with 457 compressed headers. Moreover, the generation changes only when the 458 context of a full header is different from the context of the 459 previous full header. This means that losing a full header will make 460 the context of the decompressor obsolete only when the full header 461 would actually have changed the context. 463 The generation field is 6 bits long so the generation value repeats 464 itself after 64 changes to the context. To avoid incorrect 465 decompression after error bursts or other temporary disruptions, the 466 compressor must not reuse the same generation value after a shorter 467 time than MIN_WRAP seconds. A decompressor which has been 468 disconnected MIN_WRAP seconds or more must wait for the next full 469 header before decompressing. A compressor must wait at least MIN_WRAP 470 seconds after booting before compressing non-TCP headers. Instead of 471 reusing a generation value too soon, a compressor may switch to 472 another CID or send regular headers until MIN_WRAP seconds have 473 passed. The value of MIN_WRAP is found in section 14. 475 3.3.1. Compression Slow-Start 477 To allow the decompressor to recover quickly from loss of a full 478 header that would have changed the context, full headers are sent 479 periodically with an exponentially increasing period after a change 480 in the context. This technique avoids an exchange of messages between 481 compressor and decompressor used by other compression schemes, such 482 as in [RFC-1553]. Such exchanges can be costly for wireless mobiles 483 as more power is consumed by the transmitter and delay can be 484 introduced by switching between sending and receiving. Moreover, 485 techniques that require an exchange of messages cannot be used over 486 simplex links, such as direct-broadcast satellite channels or cable 487 TV systems, and are hard to adapt to multicast over multi-access 488 links. 490 |.|..|....|........|................|.............................. 491 ^ 492 Change Sent packets: | with full header, . with compressed header 494 The picture shows how packets are sent after change. The compressor 495 keeps a variable for each non-TCP packet stream, F_PERIOD, that keeps 496 track of how many compressed headers may be sent between full 497 headers. When the headers of a non-TCP packet stream change so that 498 its context changes, a full header is sent and F_PERIOD is set to 499 one. After sending F_PERIOD compressed headers, a full header is 500 sent. F_PERIOD is doubled each time a full header is sent during 501 compression slow-start. 503 3.3.2. Periodic Header Refreshes 505 To avoid losing too many packets if a receiver has lost its context, 506 there is an upper limit, F_MAX_PERIOD, on the number of non-TCP 507 packets with compressed headers that may be sent between header 508 refreshes. If a packet is to be sent and F_MAX_PERIOD compressed 509 headers have been sent since the last full header for this packet 510 stream was sent, a full header must be sent. 512 To avoid long periods of disconnection for low data rate packet 513 streams, there is also an upper bound, F_MAX_TIME, on the time 514 between full headers in a non-TCP packet stream. If a packet is to be 515 sent and more than F_MAX_TIME seconds have passed since the last full 516 header was sent for this packet stream, a full header must be sent. 517 The values of F_MAX_PERIOD and F_MAX_TIME are found in section 14. 519 3.3.3. Rules for sending Full Headers 521 The following pseudo code can be used by the compressor to determine 522 when to send a full header for a non-TCP packet stream. The code 523 maintains two variables: 525 C_NUM -- a count of the number of compressed headers sent 526 since the last full header was sent. 527 F_LAST -- the time of sending the last full header. 529 and uses the functions 531 current_time() return the current time 532 min(a,b) return the smallest of a and b 534 the procedures send_full_header(), increment_generation_value(), 535 and send_compressed_header() 536 do the obvious thing. 538 if ( ) 540 C_NUM := 0; 541 F_LAST := current_time(); 542 F_PERIOD := 1; 543 increment_generation_value(); 544 send_full_header(); 546 elseif ( C_NUM >= F_PERIOD ) 548 C_NUM := 0; 549 F_LAST := current_time(); 550 F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD); 551 send_full_header(); 553 elseif ( current_time() > F_LAST + F_MAX_TIME ) 555 C_NUM := 0; 556 F_LAST := current_time(); 557 send_full_header(); 559 else 561 C_NUM := C_NUM + 1 562 send_compressed_header(); 564 endif 566 3.3.4. Cost of sending Header Refreshes 568 If every f'th packet carries a full header, H is the size of a full 569 header, and C is the size of a compressed header, the average header 570 size is 572 (H-C)/f + C 574 For f > 1, the average header size is (H-C)/f larger than a 575 compressed header. 577 In a diagram where the average header size is plotted for various f 578 values, there is a distinct knee in the curve, i.e., there is a limit 579 beyond which further increasing f gives diminishing returns. 580 F_MAX_PERIOD should be chosen to be a frequency well to the right of 581 the knee of the curve. For typical sizes of H and C, say 48 octets 582 for the full header (IPv6/UDP) and 4 octets for the compressed 583 header, setting F_MAX_PERIOD > 44 means that full headers will 584 contribute less than an octet to the average header size. With a 585 four-address routing header, F_MAX_PERIOD > 115 will have the same 586 effect. 588 The default F_MAX_PERIOD value of 256 (section 14) puts the full 589 header frequency well to the right of the knee and means that full 590 headers will typically contribute considerably less than an octet to 591 the average header size. For H = 48 and C = 4, full headers 592 contribute about 1.4 bits to the average header size after reaching 593 the steady-state header refresh frequency determined by the default 594 F_MAX_PERIOD. 1.4 bits is a very small overhead. 596 After a change in the context, the exponential backoff scheme will 597 initially send full headers frequently. The default F_MAX_PERIOD 598 will be reached after nine full headers and 255 compressed headers 599 have been sent. This is equivalent to a little over 5 seconds for a 600 typical voice stream with 20 ms worth of voice samples per packet. 602 During the whole backoff period, full headers contribute 1.5 octets 603 to the average header size when H = 48 and C = 4. For 20 ms voice 604 samples, it takes less than 1.3 seconds until full headers contribute 605 less than one octet to the average header size, and during these 606 initial 1.3 seconds full headers add less than 4 octets to the 607 average header size. The cost of the exponential backoff is not 608 great and as the headers of non-TCP packet streams are expected to 609 change seldomly, it will be amortized over a long time. 611 The cost of header refreshes in terms of bandwidth are higher than 612 similar costs for hard state schemes like [RFC-1553] where full 613 headers must be acknowledged by the decompressor before compressed 614 headers may be sent. Such schemes typically send one full header plus 615 a few control messages when the context changes. Hard state schemes 616 require more types of protocol messages and an exchange of messages 617 is necessary. Hard state schemes also need to deal explicitly with 618 various error conditions that soft state handles automatically, for 619 instance the case of one party disappearing unexpectedly, a common 620 situation on wireless links where mobiles may go out of range of the 621 base station. 623 The major advantage of the soft state scheme is that no handshakes 624 are needed between compressor and decompressor, so the scheme can be 625 used over simplex links. The costs in terms of bandwidth are higher 626 than for hard state schemes, but the simplicity of the decompressor, 627 the simplicity of the protocol, and the lack of handshakes between 628 compressor and decompressor justifies this small cost. Moreover, soft 629 state schemes are more easily extended to multicast over multi-access 630 links, for example radio links. 632 4. Grouping packets into packet streams 634 This section explains how packets MAY be grouped together into packet 635 streams for compression. To achieve the best compression rates, 636 packets SHOULD be grouped together such that packets in the same 637 packet stream have similar headers. If this grouping fails, header 638 compression performance will be bad, since the compression algorithm 639 can rarely utilize the existing context for the packet stream and 640 full headers must be sent frequently. 642 Grouping is done by the compressor. A compressor may use whatever 643 criterion it finds appropriate to group packets into packet streams. 644 To determine what packet stream a packet belongs to, a compressor MAY 646 a) examine the compressible chain of subheaders (see section 7), 648 b) examine the contents of an upper layer protocol header that 649 follows the compressible chain of subheaders, for example ICMP 650 headers, DVMRP headers, or tunneled IPX headers, 652 c) use information obtained from a resource manager, for example if a 653 resource manager requests compression for a particular packet 654 stream and provides a way to identify packets belonging to that 655 packet stream, 657 d) use any other relevant information, for example if routes flap and 658 the hop limit (TTL) field in a packet stream changes frequently 659 between n and n+k, a compressor may choose to group the packets 660 into two different packet streams. 662 A compressor is also free not to group packets into packet streams 663 for compression, letting some packets keep their regular headers and 664 passing them through unmodified. 666 As long as the rules for when to send full headers for a non-TCP 667 packet stream are followed and subheaders are compressed as specified 668 in this document, the decompressor is able to reconstruct a 669 compressed header correctly regardless of how packets are grouped 670 into packet streams. 672 4.1 Guidelines for grouping packets 674 In this section we give OPTIONAL guidelines for how a compressor may 675 group packets into packet streams for compression. 677 Defining fields 679 The defining fields of a header should be present and identical 680 in all packets belonging to the same packet stream. These 681 fields are marked DEF in section 7. The defining fields include 682 the flow label, source and destination addresses of IP headers, 683 final destination address in routing headers, the next header 684 fields (for IPv6), the protocol field (IPv4), port numbers (UDP 685 and TCP), and the SPI in authentication and encryption headers. 687 Fragmented packets 689 Fragmented and unfragmented packets should never be grouped 690 together in the same packet stream. The Identification field of 691 the Fragment header or IPv4 header should not be used to 692 identify the packet stream. If it was, the first fragment of a 693 new packet would cause a compression slow-start. 695 No field after a Fragment Header, or an IPv4 header for a 696 fragment, should be used for grouping purposes. 698 Upper protocol identification 700 The first next header field identifying a header not described 701 in section 7 should be used for identifying packet streams, 702 i.e., all packets with the same DEF fields and the same upper 703 protocol should be grouped together. 705 TTL field (Hop Limit field) 707 A sophisticated implementation might monitor the TTL (Hop 708 Limit) field and if it changes frequently use it as a DEF 709 field. This can occur when there are frequent route flaps so 710 that packets traverse different paths through the internet. 712 Traffic Class field (IPv6), Type of Service field (IPv4) 714 It is possible that the Traffic Class field of the IPv6 header 715 and the Type of Service of the IPv4 header will change 716 frequently between packets with otherwise identical DEF fields. 717 A sophisticated implementation should watch out for this and be 718 prepared to use these fields as defining fields. 720 When IP packets are tunneled they are encapsulated with an additional 721 IP header at the tunnel entry point and then sent to the tunnel 722 endpoint. To group such packets into packet streams, the inner 723 headers should also be examined to determine the packet stream. If 724 this is not done, full headers will be sent each time the headers of 725 the inner IP packet changes. So when a packet is tunneled, the 726 identifying fields of the inner subheaders should be considered in 727 addition to the identifying fields of the initial IP header. 729 An implementation can use other fields for identification than the 730 ones described here. If too many fields are used for identification, 731 performance might suffer because more CIDs will be used and the wrong 732 CIDs might be reused when new flows need CIDs. If too few fields are 733 used for identification, performance might suffer because there are 734 too frequent changes to the context. 736 We stress that these guidelines are educated guesses. When IPv6 is 737 widely deployed and IPv6 traffic can be analyzed, we might find that 738 other grouping algorithms perform better. We also stress that if the 739 grouping fails, the result will be bad performance but not incorrect 740 decompression. The decompressor can do its task regardless of how the 741 grouping algorithm works. 743 5. Size Issues 745 5.1. Context Identifiers 747 Context identifiers can be 8 or 16 bits long. Their size is not 748 relevant for finding the context. An 8-bit CID with value two and a 749 16-bit CID with value two are equivalent. 751 The CID spaces for TCP and non-TCP are separate, so a TCP CID and a 752 non-TCP CID never identify the same context. Even if they have the 753 same value. This doubles the available CID space while using the same 754 number of bits for CIDs. It is always possible to tell whether a 755 full or compressed header is for a TCP or non-TCP packet, so no 756 mixups can occur. 758 Non-TCP compressed headers encode the size of the CID using one bit 759 in the second octet of the compressed header. The 8-bit CID allows a 760 minimum compressed header size of 2 octets for non-TCP packets, the 761 CID uses the first octet and the size bit and the 6-bit Generation 762 value fit in the second octet. 764 For TCP the only available CID size is 8 bits as in [RFC-1144]. 8 765 bits is probably sufficient as TCP connections are always point-to- 766 point. 768 The 16 bit CID size may not be needed for point-to-point links; it is 769 intended for use on multi-access links where a larger CID space may 770 be needed for efficient selection of CIDs. 772 The major difficulty with multi-access links is that several 773 compressors share the CID space of a decompressor. CIDs can no 774 longer be selected independently by the compressors as collisions may 775 occur. This problem may be resolved by letting the decompressors 776 have a separate CID space for each compressor. Having separate CID 777 spaces requires that decompressors can identify which compressor sent 778 the compressed packet, perhaps by utilizing link-layer information as 779 to who sent the link-layer frame. If such information is not 780 available, all compressors on the multi-access link may be 781 enumerated, automatically or otherwise, and supply their number as 782 part of the CID. This latter method requires a large CID space. 784 5.2. Size of the context 786 The size of the context SHOULD be limited to simplify implementation 787 of compressor and decompressor, and put a limit on their memory 788 requirements. However, there is no upper limit on the size of an 789 IPv6 header as the chain of extension headers can be arbitrarily 790 long. This is a problem as the context is essentially a stored 791 header. 793 The configurable parameter MAX_HEADER (see section 14) represents the 794 maximum size of the context, expressed as the maximum sized header 795 that can be stored as context. When a header is larger than 796 MAX_HEADER, only part of it is stored as context. An implementation 797 MUST NOT compress more than the initial MAX_HEADER octets of a 798 header. An implementation MUST NOT partially compress a subheader. 799 Thus, the part of the header that is stored as context and is 800 compressed is the longest initial sequence of entire subheaders that 801 is not larger than MAX_HEADER octets. 803 5.3. Size of full headers 805 It is desirable to avoid increasing the size of packets with full 806 headers beyond their original size, as their size may be optimized 807 for the MTU of the link. Since we assume that the link layer 808 implementation provides the length of packets, we can use the length 809 fields in full headers to pass the values of the CID and the 810 generation to the decompressor. 812 This requires that the link-layer must not add padding to the 813 payload, at least not padding that can be delivered to the 814 destination link user. It is also required that no extra padding is 815 added after UDP data or in tunneled packets. This allows values of 816 length fields to be calculated from the length of headers and the 817 length of the link-layer frame. 819 The generation requires one octet and the CID may require up to 2 820 octets. There are length fields of 2 octets in the IPv6 Base Header, 821 the IPv4 header, and the UDP header. 823 A full TCP header will thus have at least 2 octets available in the 824 IP header to pass the 8 bit CID, which is sufficient. There will be 825 more than two octets available if there is more than one IP header. 827 [RFC-1144] uses the 8 bit Protocol field of the IPv4 header to pass 828 the CID. We cannot use the corresponding method as the sequence of 829 IPv6 extension headers is not fixed and CID values are not disjoint 830 from the legal values of Next Header fields. 832 An IPv6/UDP or IPv4/UDP packet will have 4 octets available to pass 833 the generation and the CID, so all CID sizes may be used. Fragmented 834 or encrypted packet streams may have only 2 octets available to pass 835 the generation and CID. Thus, 8-bit CIDs may be the only CID sizes 836 that can be used for such packet streams. When IPv6/IPv4 or 837 IPv4/IPv6 tunneling is used, there will be at least 4 octets 838 available, and both CID sizes may be used. 840 The generation value is passed in the higher order octet of the first 841 length field in the full header. When only one length field is 842 available, the 8-bit CID is passed in the low order octet. When two 843 length fields are available, the lowest two octets of the CID are 844 passed in the second length field and the low order octet of the 845 first length field carries the highest octet of the CID. 847 5.3.1. Use of length fields in full TCP headers 849 Use of first length field: 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Length field | LSB of pkt nr | CID | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Use of second length field if available: 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Second length field | MSB of pkt nr | 0 | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Pkt nr is short for packet sequence number, described in section 862 11.2. 864 5.3.2. Use of length fields in full non-TCP headers 866 Full non-TCP headers with 8-bit CID: 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 First length field |0|D| Generation| CID | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Second length field (if avail.) | 0 | Data (if D=1) | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Full non-TCP headers with 16-bit CID: 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 First length field |1|D| Generation| Data (if D=1) | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Second length field | CID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 The first bit in the first length field indicates the length of the 887 CID. The Data field is zero if D is zero. The use of the D bit and 888 Data field is explained in section 12. 890 6. Compressed Header Formats 892 This section uses some terminology (DELTA, RANDOM) defined in section 893 7. 895 a) COMPRESSED_TCP format (similar to [RFC 1144]): 897 +-+-+-+-+-+-+-+-+ 898 | CID | 899 +-+-+-+-+-+-+-+-+ 900 |R O I P S A W U| 901 +-+-+-+-+-+-+-+-+ 902 | | 903 + TCP Checksum + 904 | | 905 +-+-+-+-+-+-+-+-+ 906 | RANDOM fields, if any (see section 7) (implied) 907 - - - - - - - - 908 | R-octet | (if R=1) 909 - - - - - - - - 910 | Urgent Pointer Value (if U=1) 911 - - - - - - - - 912 | Window Delta (if W=1) 913 - - - - - - - - 914 | Acknowledgment Number Delta (if A=1) 915 - - - - - - - - 916 | Sequence Number Delta (if S=1) 917 - - - - - - - - 918 | IPv4 Identification Delta (if I=1) 919 - - - - - - - - 920 | Options (if O=1) 921 - - - - - - - - 923 The latter flags in the second octet (IPSAWU) have the same meaning 924 as in [RFC-1144], regardless of whether the TCP segments are carried 925 by IPv6 or IPv4. The C bit has been eliminated because the CID is 926 always present. The context associated with the CID keeps track of 927 the IP version and what RANDOM fields are present. The order between 928 delta fields specified here is exactly as in [RFC-1144]. An 929 implementation will typically scan the context from the beginning and 930 insert the RANDOM fields in order. The RANDOM fields are thus placed 931 before the DELTA fields of the TCP header in the same order as they 932 occur in the original uncompressed header. 934 The I flag is zero unless an IPv4 header immediately precedes the TCP 935 header. The combined IPv4/TCP header is then compressed as a unit as 936 described in [RFC-1144]. Identification fields in IPv4 headers that 937 are not immediately followed by a TCP header are RANDOM. 939 If the O flag is set, the Options of the TCP header were not the same 940 as in the previous header. The entire Option field are placed last in 941 the compressed TCP header. 943 If the R flag is set, there were differences between the context and 944 the Reserved field (6 bits) in the TCP header or bit 6 or 7 of the 945 TOS octet (Traffic Class octet) in a IPv4 header (IPv6 header) that 946 immediately precedes the TCP header. An octet with the actual values 947 of the Reserved field and bit 6 and 7 of the TOS or Traffic Class 948 field is then placed immediately after the RANDOM fields. Bits 0-5 949 of the passed octet is the actual value of the Reserved field, and 950 bits 6 and 7 are the actual values of bits 6 and 7 in the TOS or 951 Traffic Class field. If there is no preceding IP header, bits 6 and 7 952 are 0. The octet passed with the R flag MUST NOT update the context. 954 NOTE: The R-octet does not update the context because if it did, the 955 TCP checksum would not guard the receiving TCP from erroneously 956 decompressed headers. Bits 6 and 7 of the TOS octet or Traffic Class 957 octet is expected to change frequently due to Explicit Congestion 958 Notification. 960 See section 7.12 and [RFC-1144] for further information on how to 961 compress TCP headers. 963 b) COMPRESSED_TCP_NODELTA header format 965 +-+-+-+-+-+-+-+-+ 966 | CID | 967 +-+-+-+-+-+-+-+-+ 968 | RANDOM fields, if any (see section 7) (implied) 969 +-+-+-+-+-+-+-+-+ 970 | Whole TCP header except for Port Numbers 971 +-+-+-+-+-+-+-+-+ 973 c) Compressed non-TCP header, 8 bit CID: 974 0 7 975 +-+-+-+-+-+-+-+-+ 976 | CID | 977 +-+-+-+-+-+-+-+-+ 978 |0|D| Generation| 979 +-+-+-+-+-+-+-+-+ 980 | data | (if D=1) 981 - - - - - - - - 982 | RANDOM fields, if any (section 7) (implied) 983 - - - - - - - - 985 d) Compressed non-TCP header, 16 bit CID: 986 0 7 987 +-+-+-+-+-+-+-+-+ 988 | msb of CID | 989 +-+-+-+-+-+-+-+-+ 990 |1|D| Generation| 991 +-+-+-+-+-+-+-+-+ 992 | lsb of CID | 993 +-+-+-+-+-+-+-+-+ 994 | data | (if D=1) 995 - - - - - - - - 996 | RANDOM fields, if any (section 7) (implied) 997 - - - - - - - - 999 The generation, CID and optional one octet data are followed by 1000 relevant RANDOM fields (see section 7) as implied by the compression 1001 state, placed in the same order as they occur in the original 1002 uncompressed header, followed by the payload. 1004 7. Compression of subheaders 1006 This section gives rules for how the compressible chain of subheaders 1007 is compressed. These rules MUST be followed. Subheaders that may be 1008 compressed include IPv6 base and extension headers, TCP headers, UDP 1009 headers, and IPv4 headers. The compressible chain of subheaders 1010 extends from the beginning of the header 1012 a) up to but not including the first header that is not an IPv4 1013 header, an IPv6 base or extension header, a TCP header, or a UDP 1014 header, or 1016 b) up to and including the first TCP header, UDP header, Fragment 1017 Header, Encapsulating Security Payload Header, or IPv4 header for 1018 a fragment, 1020 whichever gives the shorter chain. For example, rules a) and b) both 1021 fit a chain of subheaders that contain a Fragment Header and ends at 1022 a tunneled IPX packet. Since rule b) gives a shorter chain, the 1023 compressible chain of subheaders stops at the Fragment Header. 1025 The following subsections are a systematic classification of how all 1026 fields in subheaders are expected to change. 1028 NOCHANGE The field is not expected to change. Any change means 1029 that a full header MUST be sent to update the context. 1031 DELTA The field may change often but usually the difference 1032 from the field in the previous header is small, so that 1033 it is cheaper to send the change from the previous value 1034 rather than the current value. This type of compression 1035 is only used for TCP packet streams. 1037 RANDOM The field must be included "as-is" in compressed headers, 1038 usually because it changes unpredictably. 1040 INFERRED The field contains a value that can be inferred from 1041 other values, for example the size of the frame carrying 1042 the packet, and thus must not be included in the 1043 compressed header. 1045 The classification implies how a compressed header is constructed. No 1046 field that is NOCHANGE or INFERRED is present in a compressed header. 1047 A compressor obtains the values of NOCHANGE fields from the context 1048 identified by the compression identifier, and obtains the values of 1049 INFERRED fields from the link-layer implementation, e.g., from the 1050 size of the link-layer frame, or from other fields, e.g., by 1051 recalculating the IPv4 header checksum. DELTA fields are encoded as 1052 the difference to the value in the previous packet in the same packet 1053 stream. The decompressor must update the context by adding the value 1054 in the compressed header to the value in its context. The result is 1055 the proper value of the field. RANDOM fields must be sent "as-is" in 1056 the compressed header. RANDOM fields must occur in the same order in 1057 the compressed header as they occur in the full header. 1059 Fields that may optionally be used to identify what packet stream a 1060 packet belongs to according to section 4.1 are marked with the word 1061 DEF. To a compressor using the optional guidelines from section 4.1, 1062 any difference in corresponding DEF fields between two packets 1063 implies that they belong to different packet streams. Moreover, if a 1064 DEF field is present in one packet but not in another, the packets 1065 belong to different packet streams. 1067 7.1. IPv6 Header [IPv6, section 3] 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 |Version| Traffic Class | Flow Label | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Payload Length | Next Header | Hop Limit | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | | 1075 + + 1076 | | 1077 + Source Address + 1078 | | 1079 + + 1080 | | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | | 1083 + + 1084 | | 1085 + Destination Address + 1086 | | 1087 + + 1088 | | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 Version NOCHANGE (DEF) 1092 Traffic Class NOCHANGE (might be DEF, see sect 4.1) 1093 (see also sect 6 a) 1094 Flow Label NOCHANGE (DEF) 1095 Payload Length INFERRED 1096 Next Header NOCHANGE 1097 Hop Limit NOCHANGE (might be DEF, see sect 4.1) 1098 Source Address NOCHANGE (DEF) 1099 Destination Address NOCHANGE (DEF) 1101 The Payload Length field of encapsulated headers must correspond to 1102 the length value of the encapsulating header. If not, the header 1103 chain MUST NOT be compressed. 1105 NOTE: If this the IP header closest to a TCP header, bit 7 of the 1106 Traffic Class field can be passed using the R-flag of the compressed 1107 TCP header. See section 6 a). 1109 This classification implies that the entire IPv6 base header will be 1110 compressed away. 1112 7.2. IPv6 Extension Headers [IPv6, section 4] 1114 What extension headers are present and the relative order of them is 1115 not expected to change in a packet stream. Whenever there is a 1116 change, a full packet header must be sent. All Next Header fields in 1117 IPv6 base header and IPv6 extension headers are NOCHANGE. 1119 7.3. Options [IPv6, section 4.2] 1121 The contents of Hop-by-hop Options and Destination Options extension 1122 headers are encoded with TLV "options" (see [IPv6]): 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1125 | Option Type | Opt Data Len | Option Data 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1128 Option Type and Opt Data Len fields are assumed to be fixed for a 1129 given packet stream, so they are classified as NOCHANGE. The Option 1130 data is RANDOM unless specified otherwise below. 1132 Padding 1134 Pad1 option 1136 +-+-+-+-+-+-+-+-+ 1137 | 0 | 1138 +-+-+-+-+-+-+-+-+ 1140 Entire option is NOCHANGE. 1142 PadN option 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1145 | 1 | Opt Data Len | Option Data 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 1148 All fields are NOCHANGE. 1150 7.4. Hop-by-Hop Options Header [IPv6, section 4.3] 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Next Header | Hdr Ext Len | | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1155 | | 1156 . . 1157 . Options . 1158 . . 1159 | | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Next Header NOCHANGE 1163 Hdr Ext Len NOCHANGE 1165 Options TLV coded values and padding. 1166 Classified according to 7.3 above, unless 1167 being a Jumbo Payload option (see below). 1169 Jumbo Payload option 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | 194 |Opt Data Len=4 | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | Jumbo Payload Length | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 First two fields are NOCHANGE and Jumbo Payload Length INFERRED. 1178 (frame length must be supplied by link layer implementation). 1180 NOTE: It is silly to compress the headers of a packet carrying 1181 a Jumbo Payload Option since the relative header overhead is 1182 negligible. Moreover, it is usually a bad idea to send such 1183 large packets over low- and medium-speed links. 1185 7.5. Routing Header [IPv6, section 4.4] 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | | 1191 . . 1192 . type-specific data . 1193 . . 1194 | | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 All fields of the Routing Header are NOCHANGE. 1199 If the Routing Type is not recognized, it is impossible to determine 1200 the final Destination Address unless the Segments Left field has the 1201 value zero, in which case the Destination Address is the final 1202 Destination Address in the basic IPv6 header. 1204 In the Type 0 Routing Header, the last address is DEF if (Segments 1205 Left > 0). 1207 Routing Headers are compressed away completely. This is a big win as 1208 the maximum size of the Routing Header is 392 octets. Moreover, Type 1209 0 Routing Headers with one address, size 24 octets, are used by 1210 Mobile IP. 1212 7.6. Fragment Header [IPv6, section 4.5] 1214 The first fragment of a packet has Fragment Offset = 0 and the chain 1215 of subheaders extends beyond its Fragment Header. If a fragment is 1216 not the first (Fragment Offset not 0), there are no subsequent 1217 subheaders (unless the chain of subheaders in the first fragment 1218 didn't fit entirely in the first fragment). 1220 Since packets may be reordered before reaching the compression point, 1221 and some fragments may follow other routes through the network, a 1222 compressor cannot rely on seeing the first fragment before other 1223 fragments. This implies that information in subheaders following the 1224 Fragment Header of the first fragment cannot be examined to determine 1225 the proper packet stream for other fragments. 1227 It is possible to design compression schemes that can compress 1228 subheaders after the Fragment Header, at least in the first fragment, 1229 but to avoid complicating the rules for sending full headers and the 1230 rules for compression and decompression, the chain of subheaders that 1231 follow a Fragment Header MUST NOT be compressed. 1233 The fields of the Fragment Header are classified as follows. 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Next Header | Reserved | Fragment Offset |Res|M| 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Identification | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 Next Header NOCHANGE 1242 Reserved NOCHANGE 1243 Res RANDOM 1244 M flag RANDOM 1245 Fragment Offset RANDOM 1246 Identification RANDOM 1248 This classification implies that a Fragment Header is compressed down 1249 to 6 octets. The minimum IPv6 MTU is 576 octets so most fragments 1250 will be at least 576 octets. Since the 6 octet overhead of the 1251 compressed fragment header is amortized over a fairly large packet, 1252 the additional complexity of more sophisticated compression schemes 1253 is not justifiable. 1255 NOTE: The Identification field is RANDOM instead of NOCHANGE to 1256 avoid one compression slow-start per original packet. 1258 Grouping of fragments according to the optional guidelines in section 1259 4.1: 1261 Fragments and unfragmented packets should not be grouped together. 1263 Port numbers cannot be used to identify the packet stream because 1264 port numbers are not present in every fragment. To adhere to the 1265 uniqueness rules for the Identification value, a fragmented packet 1266 stream is identified by the combination of Source Address and 1267 (final) Destination Address. 1269 NOTE: The Identification value is NOT used to identify the 1270 packet stream. This avoids using a new CID for each packet 1271 and saves the cost of the associated compression slow-start. 1272 We expect that the unfragmentable part of the headers will 1273 not change too frequently, if it does thrashing may occur. 1275 7.7. Destination Options Header [IPv6, section 4.6] 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Next Header | Hdr Ext Len | | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1280 | | 1281 . . 1282 . Options . 1283 . . 1284 | | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 Next Header NOCHANGE 1288 Hdr Ext Len NOCHANGE 1290 Options TLV coded values and padding. 1291 Compressed according to 7.3 above. 1293 The only Destination Options defined in [IPv6] are the padding 1294 options. 1296 7.8. No Next Header [IPv6, section 4.7] 1298 Covered by rules for IPv6 Header Extensions (7.2). 1300 7.9. Authentication Header [RFC-1826, section 3.2] 1302 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1303 +---------------+---------------+---------------+---------------+ 1304 | Next Header | Length | RESERVED | 1305 +---------------+---------------+---------------+---------------+ 1306 | Security Parameters Index (SPI) | 1307 +---------------+---------------+---------------+---------------+ 1308 | | 1309 + Authentication Data (variable number of 32-bit words) | 1310 | | 1311 +---------------+---------------+---------------+---------------+ 1313 Next Header NOCHANGE 1314 Length NOCHANGE 1315 Reserved NOCHANGE 1316 SPI NOCHANGE (DEF) 1317 Authentication Data RANDOM 1319 [RFC-1828] specifies how to do authentication with keyed MD5, the 1320 authentication method all IPv6 implementations must support. For 1321 this method, the Authentication Data is 16 octets. 1323 7.10. Encapsulating Security Payload Header [RFC-1827, section 3.1] 1325 This header implies that the subsequent parts of the packet are 1326 encrypted. Thus, no further header compression is possible on 1327 subsequent headers as encryption is typically already performed when 1328 the compressor sees the packet. 1330 However, when the ESP Header is used in tunnel mode an entire IP 1331 packet is encrypted, and the headers of that packet MAY be compressed 1332 before the packet is encrypted at the entry point of the tunnel. 1333 This means that it must be possible to feed an IP packet and its 1334 length to the decompressor, as if it came from the link-layer. The 1335 mechanisms for dealing with reordering described in section 11 MUST 1336 also be used, as packets can be reordered in a tunnel. 1338 +---------------+---------------+---------------+---------------+ 1339 | Security Association Identifier (SPI), 32 bits | 1340 +===============+===============+===============+===============+ 1341 | Opaque Transform Data, variable length | 1342 +---------------+---------------+---------------+---------------+ 1344 SPI NOCHANGE (DEF) 1345 Opaque Transform Data RANDOM 1347 Everything after the SPI is encrypted and is not compressed. 1349 7.11. UDP Header 1351 The UDP header is described in [RFC-768]. 1353 The Next Header field (IPv6) or Protocol field (IPv4) in the 1354 preceding subheader is DEF. 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Source Port | Destination Port | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Length | Checksum | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 Source Port NOCHANGE (DEF) 1363 Destination Port NOCHANGE (DEF) 1364 Length INFERRED 1365 Checksum RANDOM, unless it is zero, 1366 in which case it is NOCHANGE. 1368 The Length field of the UDP header MUST match the Length field(s) of 1369 preceding subheaders, i.e, there must not be any padding after the 1370 UDP payload that is covered by the IP Length. 1372 The UDP header is typically compressed down to 2 octets, the UDP 1373 checksum. When the UDP checksum is zero (which it cannot be with 1374 IPv6), it is likely to be so for all packets in the flow and is 1375 defined to be NOCHANGE. This saves 2 octets in the compressed header. 1377 7.12. TCP Header 1379 The TCP header is described in [RFC-793]. 1381 The Next Header field (IPv6) or Protocol field (IPv4) in the 1382 preceding subheader is DEF. 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Source Port | Destination Port | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Sequence Number | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Acknowledgment Number | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Offset| Reserved |U|A|P|R|S|F| Window | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Checksum | Urgent Pointer | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Options | Padding | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 U, A, P, R, S, and F stands for Urg, Ack, Psh, Rst, Syn, and Fin. 1400 There are two ways to compress the TCP header. 1402 7.12.1. Compressed with differential encoding 1404 Source Port NOCHANGE (DEF) 1405 Destination Port NOCHANGE (DEF) 1406 Sequence Number DELTA 1407 Acknowledgment Number DELTA 1408 Offset NOCHANGE 1409 Reserved DELTA (if differs from context, 1410 set R-flag in flag octet 1411 and send absolute value 1412 as described in 6 a.) 1413 Urg,Psh RANDOM (placed in flag octet) 1414 Ack INFERRED to be 1 1415 Rst,Syn,Fin INFERRED to be 0 1416 Window DELTA (if change in Window, 1417 set W-flag in flag octet 1418 and send difference) 1419 Checksum RANDOM 1420 Urgent Pointer DELTA (if Urg is set, send 1421 absolute value) 1422 Options, Padding DELTA (if change in Options, 1423 set O-flag and send 1424 whole Options, Padding) 1426 A packet with a TCP header compressed according to the above must be 1427 indicated to be of type COMPRESSED_TCP. The compressed header is 1428 described in section 6. 1430 This method is essentially the differential encoding techniques of 1431 Jacobson, described in [RFC-1144], the differences being the 1432 placement of the compressed TCP header fields (see section 6), the 1433 use of the O-flag, the use of the R-flag, and elimination of the C- 1434 flag. The O-flag allows compression of the TCP header when the 1435 Timestamp option is used and the Options fields changes with each 1436 header. 1438 DELTA values (except for Reserved field and Options, Padding) MUST be 1439 coded as in [RFC-1144]. A Reserved field value passed with the R- 1440 flag MUST NOT update the context at compressor or decompressor. 1442 7.12.2. Without differential encoding 1444 Source Port NOCHANGE (DEF) 1445 Destination Port NOCHANGE (DEF) 1447 (all the rest) RANDOM 1449 The Identification field in a preceding IPv4 header is RANDOM. 1451 A packet with a TCP header compressed according to the above must be 1452 indicated to be of type COMPRESSED_TCP_NODELTA. It uses the same CID 1453 space as COMPRESSED_TCP packets, and the header MUST be saved as 1454 context. The compressed header is described in section 6. 1456 This packet type can be sent as the response to a header request 1457 instead of sending a full header, can be used over links that reorder 1458 packets, and can be sent instead of a full header when there are 1459 changes that cannot be represented by a compressed header. A 1460 sophisticated compressor can switch to sending only 1461 COMPRESSED_TCP_NODELTA headers when the packet loss frequency is 1462 high. 1464 7.13. IPv4 header [RFC-791, section 3.1] 1466 0 1 2 3 1467 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 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 |Version| IHL |Type of Service| Total Length | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Identification |Flags| Fragment Offset | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Time to Live | Protocol | Header Checksum | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Source Address | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Destination Address | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Options | Padding | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 There are two ways to compress the IPv4 header 1484 a) If the IPv4 header is not for a fragment (MF flag is not set and 1485 Fragment Offset is zero) and there are no options (IHL is 5), it 1486 is classified as follows 1488 Version NOCHANGE (DEF) 1489 IHL NOCHANGE (DEF, must be 5) 1490 Type of Service NOCHANGE (might be DEF, see sect 4.1) 1491 (see also 6 a) 1492 Total Length INFERRED (from link-layer implementation 1493 or encapsulating IP header) 1495 Identification DELTA/ (If the Protocol field has the 1496 value corresponding to TCP) 1497 RANDOM (otherwise) 1499 Flags NOCHANGE (MF flag must not be set) 1500 Fragment Offset NOCHANGE (must be zero) 1501 Time to Live NOCHANGE (might be DEF, see sect 4.1) 1502 Protocol NOCHANGE 1503 Header Checksum INFERRED (calculated from other fields) 1504 Source Address NOCHANGE (DEF) 1505 Destination Address NOCHANGE (DEF) 1506 Options, Padding (not present) 1508 Note: When a TCP header immediately follows, the IPv4 and TCP 1509 header MUST be compressed as a unit as described in section 6. 1510 Bits 6 and 7 of the Type of Service field (bits 14 and 15 of the 1511 first word) can then be passed using the R-flag (see section 6 a). 1513 b) If the IPv4 header is for a fragment (MF bit set or Fragment 1514 Offset nonzero), or there are options (IHL > 5), all fields are 1515 RANDOM (i.e., if the header is compressed all fields are sent as- 1516 is and not compressed). This classification allows compression of 1517 the tunnel header, but not the fragment header, when fragments are 1518 tunneled. If the IPv4 header is for a fragment it ends the 1519 compressible chain of subheaders, i.e., it must be the last 1520 subheader to be compressed. If the IPv4 header has options but is 1521 not for a fragment it does not end the compressible chain of 1522 subheaders, so subsequent subheaders can be compressed. 1524 A compressor that follows the optional guidelines of section 4.1 will 1525 in case a) use the Version, Source Address and Destination Address to 1526 define the packet stream, together with the fact that there are no 1527 IPv4 options and that this is not a fragment. 1529 Case b) can define two kinds of packet streams depending on whether 1530 the IPv4 header is for a fragment or not. 1532 If the IPv4 header in case b) is for a fragment, a compressor 1533 following the optional guidelines will use that fact together with 1534 the Version, Source Address, and Destination Address to determine the 1535 packet stream. 1537 If the IPv4 header in case b) is not for a fragment, it must have 1538 options. A compressor following the optional guidelines will use that 1539 fact, but not the size of the options, together with the Version, 1540 Source Address, and Destination Address to determine the packet 1541 stream. 1543 7.14. Minimal Encapsulation header [RFC-2004, section 3.1] 1545 0 1 2 3 1546 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 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Protocol |S| reserved | Header Checksum | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Original Destination Address | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 : (if present) Original Source Address : 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 Protocol NOCHANGE 1556 Original Source Address Present (S) NOCHANGE 1557 reserved NOCHANGE 1558 Header Checksum INFERRED (calculated from 1559 other values) 1560 Original Destination Address NOCHANGE 1561 Original Source Address NOCHANGE (present only 1562 if S=1) 1564 This header is likely to be used by Mobile IP. 1566 8. Changing context identifiers 1568 On a point-to-point link, the compressor has total knowledge of what 1569 CIDs are in use at the decompressor and may change what CID a packet 1570 stream uses or reuse CIDs at will. 1572 Each non-TCP CID is associated with a context with a generation 1573 value. To avoid too rapid generation wrap-around and potential 1574 incorrect decompression, an implementation MUST avoid wrap-around of 1575 the generation value in less than MIN_WRAP seconds (see section 14). 1577 To aid in avoiding wrap-around, the generation value associated with 1578 a CID MUST NOT be reset when changing to a new packet stream. 1579 Instead, a compressor MUST increment the generation value by one when 1580 using the CID for a new non-TCP packet stream. 1582 9. Rules for dropping or temporarily storing packets 1584 When a decompressor receives a packet with a compressed TCP header 1585 with CID C, it MUST be discarded when the context for C has not been 1586 initialized by a full header. 1588 When a decompressor receives a packet with a compressed non-TCP 1589 header with CID C and generation G, the header must not be 1590 decompressed using the current context when 1591 a) the decompressor has been disconnected from the compressor for 1592 more than MIN_WRAP seconds, because the context might be 1593 obsolete even if it has generation G. 1595 b) the context for C has a generation other than G. 1597 In case a) and b) the packet may either be 1599 i) discarded immediately, or else 1601 ii) stored temporarily until the context is updated by a packet 1602 with a full non-TCP header with CID C and generation G, after 1603 which the header can be decompressed. 1605 Packets stored in this manner MUST be discarded when 1607 *) receiving full or compressed non-TCP headers with CID C 1608 and a generation other than G, 1610 *) the decompressor has not received packets with CID C in 1611 the last MIN_WRAP seconds. 1613 When full headers are lost, a decompressor can receive compressed 1614 non-TCP headers with a generation value other than the generation of 1615 its context. Rule ii) allows the decompressor to store such headers 1616 until they can be decompressed using the correct context. 1618 10. Low-loss header compression for TCP 1620 Since fewer bits are transmitted per packet with header compression, 1621 the packet loss rate is lower with header compression than without, 1622 for a fixed bit-error rate. This is beneficial for links with high 1623 bit-error rates such as wireless links. 1625 However, since TCP headers are compressed using differential 1626 encoding, a single lost TCP segment can ruin an entire TCP sending 1627 window because the context is not incremented properly at the 1628 decompressor. Subsequent headers will therefore be decompressed to 1629 be different than before compression and discarded by the TCP 1630 receiver because the TCP checksum fails. 1632 A TCP connection in the wide area where the last hop is over a 1633 medium-speed lossy link, for example a wireless LAN, will then have 1634 poor performance with traditional header compression because the 1635 delay-bandwidth product is relatively large and the bit-error rate 1636 relatively high. For a 2 Mbit/s wireless LAN and an end-to-end RTT of 1637 200 ms, the delay-bandwidth product is 50 kbyte. That is equivalent 1638 to about 97 512-octet segments with compressed headers. Each loss 1639 can thus be multiplied by a factor of 100. 1641 This section describes two simple mechanisms for quick repair of the 1642 context. With these mechanisms header compression will improve TCP 1643 throughput over lossy links as well as links with low bit-error 1644 rates. 1646 10.1. The "twice" algorithm 1648 The decompressor may compute the TCP checksum to determine if its 1649 context is not updated properly. If the checksum fails, the error is 1650 assumed to be caused by a lost segment that did not update the 1651 context properly. The delta of the current segment is then added to 1652 the context again on the assumption that the lost segment contained 1653 the same delta as the current. By decompressing and computing the TCP 1654 checksum again, the decompressor checks if the repair succeeded or if 1655 the delta should be applied once more. 1657 Analysis of traces of various TCP bulk transfers show that applying 1658 the delta of the current segment one or two times will repair the 1659 context for between 83 and 99 per cent of all single-segment losses 1660 in the data stream. For the acknowledgment stream, the success rate 1661 is smaller due to the delayed ack mechanism of TCP. The "twice" 1662 mechanism repairs the context for 53 to 99 per cent of the losses in 1663 the acknowledgment stream. A sophisticated implementation of this 1664 idea would determine whether the TCP stream is an acknowledgment or 1665 data stream and determine the segment size by observing the stream of 1666 full and compressed headers. Trying deltas that are small multiples 1667 of the segment size will result in even higher rates of successful 1668 repairs for acknowledgment streams. 1670 10.2. Header Requests 1672 The relatively low success rate for the "twice" algorithm for TCP 1673 acknowledgment streams calls for an additional mechanism for 1674 repairing the context at the decompressor. When the decompressor 1675 fails to repair the context after a loss, the decompressor may 1676 optionally request a full header from the compressor. This is 1677 possible on links where the decompressor can identify the compressor 1678 and send packets to it. 1680 On such links, a decompressor may send a CONTEXT_STATE packet back to 1681 the compressor to indicate that one or more contexts are invalid. A 1682 decompressor SHOULD NOT transmit a CONTEXT_STATE packet every time a 1683 compressed packet refers to an invalid context, but instead should 1684 limit the rate of transmission of CONTEXT_STATE packets to avoid 1685 flooding the reverse channel. A CONTEXT_STATE packet can indicate 1686 that several contexts are out of date, this technique SHOULD be used 1687 instead of sending several separate packets. The following diagram 1688 shows the format of a CONTEXT_STATE packet. 1690 0 1 2 3 4 5 6 7 1691 +---+---+---+---+---+---+---+---+ 1692 | TCP header request = 3 | 1693 +---+---+---+---+---+---+---+---+ 1694 | CID count | 1695 +---+---+---+---+---+---+---+---+ 1696 | CID | 1697 +---+---+---+---+---+---+---+---+ 1698 | CID | 1699 +---+---+---+---+---+---+---+---+ 1700 ... 1701 +---+---+---+---+---+---+---+---+ 1702 | CID | 1703 +---+---+---+---+---+---+---+---+ 1705 The first octet is a type code to allow the CONTEXT_STATE packet type 1706 to be shared for other compression protocols that are (see [CRTP]) or 1707 may be defined in parallel with this one. When used for TCP header 1708 requests the type code has the value 3, and the remainder of the 1709 packet is a sequence of CIDs preceded by a one-octet count of the 1710 number of CIDs. 1712 On receipt of a CONTEXT_STATE packet, the compressor MUST mark the 1713 CIDs invalid to ensure that the next packet emitted in those packet 1714 streams are FULL_HEADER or COMPRESSED_TCP_NODELTA packets. 1716 Header requests are an optimization, so loss of a CONTEXT_STATE 1717 packet does not affect the correct operation of TCP header 1718 compression. When a CONTEXT_STATE packet is lost, eventually a new 1719 one will be transmitted or TCP will timeout and retransmit. The big 1720 advantage of using header requests is that TCP acknowledgment streams 1721 can be repaired after a roundtrip-time over the lossy link. This 1722 will typically avoid a TCP timeout and unnecessary retransmissions. 1723 The lower packet loss rate due to smaller packets will then result in 1724 higher throughput because the TCP window can grow larger between 1725 losses. 1727 11. Links that reorder packets 1729 Some links reorder packets, for example multi-hop radio links that 1730 use deflection routing to route around congested nodes. Packets 1731 routed different ways can then arrive at the destination in a 1732 different order than they were sent. 1734 11.1. Reordering in non-TCP packet streams 1736 Compressed non-TCP headers do not change the context, and neither do 1737 full headers that refresh it. There can be problems only when a full 1738 header that changes the context arrives out of order. There are two 1739 cases: 1741 - A packet with a full header with generation G arrives *after* a 1742 packet with a compressed header with generation G. This case 1743 is covered by rule b) ii) in section 9. 1745 - A packet with a full header with generation G arrives *before* a 1746 packet with a compressed header with generation G-1 (modulo 1747 64). The decompressor MAY then keep both versions of the 1748 context around for a while to be able to decompress subsequent 1749 compressed headers with generation G-1 (modulo 64). The old 1750 context MUST be discarded after MIN_WRAP seconds. 1752 11.2. Reordering in TCP packet streams 1754 A compressor may avoid sending COMPRESSED_TCP headers and only send 1755 COMPRESSED_TCP_NODELTA headers when there is reordering over the 1756 link. Compressed headers will typically be 17 octets with that 1757 method, significantly larger than the usual 4-7 octets. 1759 To achieve better compression rates the following method, adding only 1760 two octets to the compressed header for a total of 6-9 octets, may be 1761 used. A packet sequence number, incremented by one for every packet 1762 in the TCP stream, is then associated with each compressed and full 1763 header. This allows the decompressor to place the packets in the 1764 correct sequence and apply their deltas to the context in the correct 1765 order. A simple sliding window scheme is used to place the packets 1766 in the correct order. 1768 Two octets are needed for the packet sequence numbers. One octet 1769 gives only 256 sequence numbers. In a sliding window scheme the 1770 window should be no larger than half of the sequence number space, so 1771 packets can not arrive more than 127 positions out-of-sequence. This 1772 is equivalent to a delay of 260 ms on 2 Mbit/s links with 512 octet 1773 segments. Delays of that order are not uncommon over wide-area 1774 Internet connections. However, two octets giving 2^16 = 65536 values 1775 should be sufficient. 1777 Full TCP/IP headers will only have space for one octet of sequence 1778 number when there is no tunneling. It is not feasible to increase the 1779 size of full headers since the packet size might be optimized for the 1780 MTU of the link. Therefore only the least significant octet of the 1781 packet sequence number can be placed in such full headers. We believe 1782 that such full headers can be positioned correctly frequently enough 1783 with only the least significant octet of the packet sequence number 1784 available. 1786 The packet sequence number zero MUST be skipped over. Avoiding zero 1787 takes care of a problem that can occur when the TCP window scale 1788 option is used to enlarge the TCP window. When exactly 2^16 octets of 1789 TCP data is lost, a compressed header will be decompressed 1790 incorrectly without being detected by the TCP checksum. TCP segment 1791 sizes are often a power of two. So by using a packet sequence number 1792 space that is not a power of two either the TCP sequence number or 1793 the packet sequence number will differ when 2^16 octets are lost. 1794 Whenever a compressor sees the window scale option on a SYN segment, 1795 it MUST use packet sequence numbers when subsequently compressing 1796 that packet stream. 1798 In compressed TCP headers the two octet packet sequence number MUST 1799 be placed immediately after the TCP Checksum. See section 5.3 for 1800 placement of packet sequence numbers in full headers. 1802 12. Hooks for additional header compression 1804 The following hook is supplied to allow additional header compression 1805 schemes for headers on top of UDP. The initial chain of subheaders is 1806 then compressed as described here, and the other header compression 1807 scheme is applied to the header above the UDP header. An example of 1808 such additional header compression is Compressed RTP by Casner and 1809 Jacobson [CRTP]. To allow some error detection, such schemes 1810 typically need a sequence number that may need to be passed in full 1811 headers as well as compressed UDP headers. 1813 The D-bit and Data octet (see section 6) provides the necessary 1814 mechanism. When a sequence number, say, needs to be passed in a 1815 FULL_HEADER or COMPRESSED_NON_TCP header, the D-bit is set and the 1816 sequence number is placed in the Data field. The decompressor must 1817 then extract and make the Data field available to the additional 1818 header compression scheme. 1820 Use of additional header compression schemes like CRTP must be 1821 negotiated. The D-bit and Data octet mechanism must automatically be 1822 enabled whenever use of additional header compression schemes has 1823 been negotiated. 1825 13. Demultiplexing 1827 For each link layer, there must be a document specifying how the 1828 various packet types used by IP header compression is indicated. 1829 Such a document exists for PPP [PPP-HC]. This section gives OPTIONAL 1830 guidelines on how packet types may be indicated by a specific link- 1831 layer. 1833 It is necessary to distinguish packets with regular IPv4 headers, 1834 regular IPv6 headers, full IPv6 packets, full IPv4 packets, 1835 compressed TCP packets, compressed non-TCP packets, and CONTEXT_STATE 1836 packets. 1838 The decision to use a distinct ethertype (or equivalent) for IPv6 has 1839 already been taken, which means that link-layers must be able to 1840 indicate that a packet is an IPv6 packet. 1842 IP header compression requires that the link-layer implementation can 1843 indicate four kinds of packets: COMPRESSED_TCP for format a) in 1844 section 6, COMPRESSED_TCP_NODELTA for format b), COMPRESSED_NON_TCP 1845 for formats c) and d), and CONTEXT_STATE as described in section 1846 11.2. It is also desirable to indicate FULL_HEADERS at the link 1847 layer. 1849 Full headers can be indicated by setting the first bit of the Version 1850 field in a packet indicated to be an IPv6 packet. In addition, one 1851 bit of the Version field is used to indicate if the first subheader 1852 is an IPv6 or an IPv4 header, and one bit is used to indicate if this 1853 full header carries a TCP CID or a non-TCP CID. The first four bits 1854 are encoded as follows: 1856 Version Meaning 1857 ------- ------- 1859 0110 regular IPv6 header 1861 1T*0 T=1 indicates a TCP header, T=0 indicates a non-TCP header 1862 1*V0 V=1 indicates a IPv6 header, V=0 indicates a IPv4 header 1864 If a link-layer cannot indicate the packet types for the compressed 1865 headers or CONTEXT_STATE, packet types that cannot be indicated could 1866 start with an octet indicating the packet type, followed by the 1867 header. 1869 First octet Type of compressed header 1870 ----------- ------------------------- 1872 0 COMPRESSED_TCP 1873 1 COMPRESSED_TCP_NODELTA 1874 2 COMPRESSED_NON_TCP 1875 3 CONTEXT_STATE 1877 The currently assigned CONTEXT_STATE type values are 1879 Value Type Reference 1880 ----- ----- ---------- 1881 0 Reserved - 1882 1 IP/UDP/RTP w. 8-bit CID [CRTP] 1883 2 IP/UDP/RTP w. 16-bit CID [CRTP] 1884 3 TCP header request Section 10.2 1886 14. Configuration Parameters 1888 Header compression parameters are negotiated in a way specific to the 1889 link-layer implementation. Such procedures for link-layer xxx needs 1890 to be specified in a document "IP header compression over xxx". Such 1891 a document exists for PPP [PPP-HC]. 1893 The following parameter is fixed for all implementations of this 1894 header compression scheme. 1896 MIN_WRAP - minimum time of generation value wrap around 1898 3 seconds. 1900 The following parameters can be negotiated between the compressor and 1901 decompressor. If not negotiated their values must be as specified by 1902 DEFAULT. 1904 F_MAX_PERIOD - Largest number of compressed non-TCP headers that 1905 may be sent without sending a full header. 1907 DEFAULT is 256 1909 F_MAX_PERIOD must be at least 1 and at most 65535. 1911 F_MAX_TIME - Compressed headers may not be sent more than 1912 F_MAX_TIME seconds after sending last full header. 1914 DEFAULT is 5 1916 F_MAX_TIME must be at least 1 and at most 255. 1918 NOTE: F_MAX_PERIOD and F_MAX_TIME should be lower when it is 1919 likely that a decompressor loses its state. 1921 MAX_HEADER - The largest header size in octets that may 1922 be compressed. 1924 DEFAULT is 168 octets, which covers 1926 - Two IPv6 base headers 1927 - A Keyed MD5 Authentication Header 1928 - A maximum-sized TCP header 1930 MAX_HEADER must be at least 60 octets and 1931 at most 65535 octets. 1933 TCP_SPACE - Maximum CID value for TCP. 1935 DEFAULT is 15 (which gives 16 CID values) 1937 TCP_SPACE must be at least 3 and at most 255. 1939 NON_TCP_SPACE - Maximum CID value for non-TCP. 1941 DEFAULT is 15 (which gives 16 CID values) 1943 NON_TCP_SPACE must be at least 3 and at most 65535. 1945 EXPECT_REORDERING - The mechanisms in section 11 are used. 1947 DEFAULT no. 1949 15. Implementation Status 1951 A prototype using UDP as the link layer has been operational since 1952 March 1996. A NetBSD implementation for PPP has been operational 1953 since October 1996. 1955 16. Acknowledgments 1957 This protocol uses many ideas originated by Van Jacobson in the 1958 design of header compression for TCP/IP over slow-speed links [RFC- 1959 1144]. It has benefited from discussions with Stephen Casner and 1960 Carsten Bormann. 1962 We thank Craig Partridge for pointing out a problem that can occur 1963 when the TCP window scale option is used. A solution to this problem 1964 relying on the packet sequence numbers used for reordering is 1965 described in section 11.2. 1967 17. Security Considerations 1969 The compression protocols in this document run on top of a link-layer 1970 protocol. The compression protocols themselves introduce no new 1971 additional vulnerabilities beyond those associated with the specific 1972 link-layer technology being used. 1974 Denial-of-service attacks are possible if an intruder can introduce 1975 (for example) bogus Full Header packets onto the link. However, an 1976 intruder having the ability to inject arbitrary packets at the link- 1977 layer in this manner raises additional security issues that dwarf 1978 those related to the use of header compression. 1980 We advise implementors against identifying packet streams with the 1981 aid of information that is encrypted, even if such information 1982 happens to be available to the compressor. Doing so may expose 1983 traffic patterns. 1985 18. Author's Addresses 1987 Mikael Degermark Tel: +46 920 91188 1988 CDT/Dept of Computer Communication Fax: +46 920 72801 1989 Lulea University Mobile: +46 70 833 8933 1990 S-971 87 Lulea, Sweden EMail: micke@sm.luth.se 1992 Bjorn Nordgren Tel: +46 920 75400 1993 CDT/Telia Research AB Fax: +46 920 75490 1994 Aurorum 6 EMail: bcn@lulea.trab.se 1995 S-977 75 Lulea, Sweden 1997 Stephen Pink Tel: +46 8 752 15 59 1998 CDT/Swedish Institute of Computer Science Fax: +46 8 751 72 30 1999 PO Box 1263 Mobile: +46 70 532 0007 2000 S-164 28 Kista, Sweden EMail: steve@sics.se 2002 19. References 2004 [RFC-768] J. Postel, User Datagram Protocol, RFC 761, August 1980. 2006 [RFC-791] J. Postel, Internet Protocol, RFC 791, September 1981. 2008 [RFC-793] J. Postel, Transmission Control Protocol, RFC 793, 2009 September 1981. 2011 [RFC-1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed 2012 Serial Links, RFC 1144, February 1990. 2014 [RFC-1553] A. Mathur, M. Lewis, Compressing IPX Headers Over WAN 2015 Media (CIPX), RFC 1553, December 1993. 2017 [RFC-1700] J. Reynolds and J. Postel, Assigned Numbers, RFC-1700, 2018 October 1994. 2020 [RFC-1826] R. Atkinson, IP Authentication Header, RFC 1826, August 2021 1995. 2023 [RFC-1827] R. Atkinson, IP Encapsulating Security Protocol (ESP), 2024 RFC 1827, August 1995. 2026 [RFC-1828] Metzger, W. Simpson, IP Authentication using Keyed MD5, 2027 RFC 1828, August 1995. 2029 [IPv6] S. Deering, R. Hinden, Internet Protocol, Version 6 2030 (IPv6) Specification, RFC 1883, December 1995. 2032 [ICMPv6] A. Conta, S. Deering, Internet Control Message Protocol 2033 (ICMPv6) for the Internet Protocol Version 6 (IPv6), RFC 2034 1885, December 1995. 2036 [RFC-2004] C. Perkins, Minimal Encapsulation within IP, RFC 2004, 2037 October 1996. 2039 [CRTP] S. Casner, V. Jacobson, Compressing IP/UDP/RTP Headers 2040 for Low-Speed Serial Links. Internet-Draft (Work in 2041 progress), November 21, 1997. 2043 [PPP-HC] M. Engan, S. Casner, C. Bormann, IP Header Compression 2044 for PPP. Internet-Draft (Work in progress), December 17, 2045 1997. 2047 This draft expires in April 1999.