Network Working Group W A Simpson Internet Draft Daydreamer expires in six months September 1994 IPv6 Header Compression draft-simpson-ipv6-hc-00.txt Status of this Memo Another in a series of "mad ravings of the lunatic engineer" [Malamud]. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within. Comments should be submitted to the ipng@sunroof.eng.sun.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes a mechanism to improve IP performance over low and medium speed (300 bps to 155.2 Kbps and beyond) point-to- point links. Simpson expires in six months [Page i] DRAFT IPv6 Header Compression September 1994 1. Introduction Once upon a time, the combined TCP and IP headers were considered so large that they required compression to achieve acceptable performance over serial links readily available for homes and small businesses [RFC-1144]. The IPv6 Header is more than twice the IPv4 header size, and more headers have been added for improved options, fragmentation, routing, and security. Also, TCPng itself may increase in size. This results in a typical combined header of 4 to 16 times the earlier size. On the other hand, the available bandwidth has merely doubled on the low end, through the introduction of newer modem standards. The latest modems operate at 28.8 Kbps, but many lines will not support that rate. Most current links still use the older technologies, or are limited by treaty, custom, and carrier deployment. Effective speeds of 1200 bps, 9600 bps, and 14.4 Kbps are typical. Costs for links at 57.6 Kbps or greater are still out of the reach of the common user. 1.1. Interactive Response Earlier header compression was motivated by the need for good interactive response. Human factors studies cited in [RFC-1144], from [Shneiderman], show that users perceive interactive responsiveness to be poor when the response time for visible events (such as the echo of typed characters) rises above 100 to 200 milliseconds. Also, [RFC-1144] cites [Salthouse] that a maximum typing speed is about 5 characters per second. This limits the required Round Trip Time to 200 ms. Typing bursts or multiple character keystrokes such as cursor keys can exceed this average rate by factors of 2 to 4. However, the TCP Nagle algorithm [RFC-896] aggregates keystrokes which arrive while a previous acknowledgement is pending, and the improved header-to-data ratio compensates for the increased data. The needed header allowances are 48 bytes for IPv6, 48 or more bytes for a Routing Header, 24 or more bytes for an Authentication Header, 48 or more bytes for TCPng, and usually 4 bytes for Point-to-Point Protocol (PPP) link layer encapsulation. Fragmentation Headers, Hop-by-Hop or End-to-End Headers would increase the size further. Simpson expires in six months [Page 1] DRAFT IPv6 Header Compression September 1994 The Round Trip budget for a single character echo would be a minimum of 348 bytes. The needed full duplex asynchronous link speed would be 34.8 Kbps for a 100 ms response, and must be at least 17.4 Kbps for a 200 ms response. Most deployed desktop or laptop computer environments cannot sustain serial speeds of 38.4 Kbps without overrun errors. In any case, this will exceed the link speeds which are actually available to mobile users, homes, and small businesses. Therefore, interactive service requires header compression to be viable. 1.2. Bulk Transfer It was previously thought that the efficiency of data transfers for FTP, NNTP, SMTP, and the like could be improved by simply making datagrams larger. However, most links can only transmit datagrams of a maximum 1500 bytes. At that size, the efficiency is about 88%. Moreover, IPv6 assumes a minimum link MTU of 576 bytes. The efficiency drops to less than 70%. These increased inefficiencies are sufficiently gross as to be readily apparent to the user. The IPv6 Fragmentation Header, Hop- by-Hop Options, or End-to-End Options would decrease the efficiency further. Therefore, bulk traffic will also benefit from header compression. 1.3. Interleaved Traffic Even with queuing which gives priority to interactive traffic, any bulk data traffic interleaved with interactive traffic will introduce a queuing delay related to half its size. For example, a 576 byte packet at 14.4 Kbps will add an average 200 ms delay. In order to maintain the response time for interactive traffic, the header compression must reduce the delay to acceptable bounds. This may be accomplished when the sum of the sizes of compressed interactive and bulk traffic headers is less than the size of the uncompressed bulk traffic header. NOTE: IPv6 requires that the minimum MTU of 576 bytes be supported Simpson expires in six months [Page 2] DRAFT IPv6 Header Compression September 1994 without Fragmentation. Since the payload comprises 70% of the datagram, header compression alone will not be enough to bring the interleaved delay within budget for 9600 bps or slower links. 1.4. Asymmetric Traffic Some modem techniques expect that the rate of traffic in one direction will be much less than the rate in the other direction. The flow of large packets in both directions can cause these modems to "thrash", wasting considerable time in turnaround. The [RFC-1144] target was to reduce this asymmetric traffic to 300 bps. At a typing rate of 5 characters per second, that leaves 25 bytes for headers, or 5 bytes per packet. Since PPP normally uses a minimum overhead of 4 bytes per packet, only 1 byte remains. This leaves no budget for any compression algorithm overhead when carrying a character of data and the end-to- end checksum. Some PPP implementations can negotiate away the FCS, which allows a minimum overhead of 2 bytes, leaving 3 bytes for data and checksum, but still no compression algorithm overhead. However, although the target cannot be reached, empirical evidence suggests that "thrashing" is considerably alleviated when header compression is in use. Special consideration must be taken for common operations such as single character typing, and bulk traffic acknowlegements which carry no data. NOTE: The [RFC-1144] target of 5 bytes was not achievable for the same reasons. The author forgot to budget link-layer overhead. 1.5. Shared State The compression protocol must be based solely on information guaranteed to be known to both ends of a single serial link [RFC- 1144]. Consider the topology where communicating hosts A and B are on separate Local Area Networks, and these LANs are connected by two serial links, between routers A1--B1 and A2--B2. Because of routing transients or multipathing, it's entirely possible that some of the A--B traffic will follow the A-A1-B1-B path and some will follow the Simpson expires in six months [Page 3] DRAFT IPv6 Header Compression September 1994 A-A2-B2-B path. Similarly, it's possible that A->B traffic will flow A->A1->B1->B and B->A traffic will flow B->B2->A2->A. None of the routers can count on seeing all the packets in a particular conversation. Although any compression scheme involves shared state, this state is spatially and temporally local to the peers which communicate over the link. This adheres to Dave Clark's principle of fate sharing [Clark]. The two ends can only disagree on the shared state when the link connecting them is failing. The design should take graceful failure into account. 1.6. Link Data Compression Note that it is possible, and many times desirable, to use this type of header compression in conjunction with some type of link-layer data compression. After intelligently compressing the packet header, link data compression can be effective in reducing packet size further. It is important that link data compression should be done after header compression, as the compressed header indications may have a useful effect on selection of an appropriate data compression history. However, experience has shown that transport-layer data compression is far more effective in improving overall efficiency for bulk data transfers [RFC-1144]. 1.7. Fewer Headers Another technique for reducing the header size is simply to send fewer intermediate headers. The Authentication Header could be sent only for "critical" datagrams, such as TCP SYN and FIN. This is described in [#1]. When a Routing Header is used for mobility, it could be removed by the Foreign Agent prior to forwarding the datagram to the Mobile Node. This is described in [#2]. Simpson expires in six months [Page 4] DRAFT IPv6 Header Compression September 1994 1.8. Heterogeneity IPv4 and IPv6 traffic will be intermixed for some time to come. Minimal effort results in compatibility with compression for IPv4. IPv4 Headers may be concurrently compressed by the same mechanisms. 1.9. Complexity The strategies proposed here are considerably more complicated than earlier header compression design. This is warranted by the desperate need to reduce the header size in as many situations as possible. Simpson expires in six months [Page 5] DRAFT IPv6 Header Compression September 1994 2. The Headers Because IPv6 splits options, authentication, and routing loci into separate headers before the final payload, the transport header does not necessarily immediately follow the IPv6 header. Also, the payload itself may be encrypted. However, when present, these headers are expected to appear in a specified order. This facilitates compression and decompression of the ordered headers. 2.1. IPv6 Header The IPv6 header is described in [#0]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Source ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Destination ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Version is always constant for a given conversation. The Source and Destination identify the conversation end-points. The Flow Label identifies a particular conversation. For the purposes of this compression method, changes to any sub-fields within the Flow Label cause a separate conversation to be assigned. The Hop Limit is assumed to be the same for a given pair of end- points. The Next Header is assumed to be the same for a given conversation. This leaves only the Payload Length as a potentially changing field. In order to compress and reconstitute this field, the link-layer implementation MUST indicate the length of a received message. Simpson expires in six months [Page 6] DRAFT IPv6 Header Compression September 1994 Therefore, the entire 48 byte IPv6 Header is compressible to a single byte, which indicates an established conversation. 2.2. Hop-by-Hop Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Options ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Every implementation is expected to recognize this header, even when the interior Options are not recognized. The Next Header and Length are assumed to be the same for a given conversation. Any changes cause the conversation history to be re- initialized. The Options are treated as an opaque series of bytes. Any changes cause the conversation history to be re-initialized. 2.3. Routing Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Routing Type=0 | Num Addrs | Next Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Address[Num Addrs - 1] ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Routing Header is problematic, in that it does not have a consistent length field. This header MAY terminate the chain of recognized headers. However, a minimal implementation MUST recognize at least one specific format, the "Loose" Routing Type 0. Simpson expires in six months [Page 7] DRAFT IPv6 Header Compression September 1994 The Address(es) are treated as an opaque series of bytes. Any changes cause the conversation history to be re-initialized. 2.4. Fragment header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since any following headers and payload are not necessarily contained entirely within first fragment, processing further headers is difficult or futile. When present, this header MUST terminate the chain of recognized headers. The Next Header is assumed to be the same for a given conversation. Any changes cause the conversation history to be re-initialized. The Identification cannot change except when the Offset is zero. The change information can be represented by 2 bits, and one Change Value. M A copy of the "More" bit. F First Fragment. The Identification is incremented by the Change Value, and the Offset is set to zero. Otherwise, the Offset, Reserved field, and More bit are entirely replaced by the Change Value. When the value of the Identification decreases, or the Offset decreases or remains the same, a duplicate or delayed datagram is assumed, and cause the conversation history to be re-initialized. Simpson expires in six months [Page 8] DRAFT IPv6 Header Compression September 1994 2.5. Authentication header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Auth Data Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Next Header, Length, reserved, and Security Association, are assumed to be the same for a given conversation. Different Security Associations have the same effect as different Flow Labels for a given pair of end-points. The Reserved field is normally zero. When not zero, it cannot be compressed. The Authentication Data changes in each datagram in an unpredicatable fashion. Therefore, the Authentication Data MUST be included in its entirety. While this is only a reduction of 6 or 8 bytes, every bit counts. 2.6. End-to-End Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Options ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Every implementation is expected to recognize this header, even when the interior Options are not recognized. The Next Header and Length are assumed to be the same for a given conversation. Any changes cause the conversation history to be re- initialized. The Options are treated as an opaque series of bytes. Any changes Simpson expires in six months [Page 9] DRAFT IPv6 Header Compression September 1994 cause the conversation history to be re-initialized. 2.7. UDP header The UDP header is described in [RFC-768]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Source Port and Destination Port are assumed to be the same for a given conversation. Different Ports have the same effect as different Flow Labels for a given pair of end-points. The Length can be calculated from the reconstituted IPv6 Payload Length. The lengths of all intervening headers are known. The Checksum MUST be included in its entirety. 2.8. TCP header The TCP header is described in [RFC-793]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset| Reserved |U|A|P|R|S|F| Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Source Port and Destination Port are assumed to be the same for a given conversation. Different Ports have the same effect as different Flow Labels for a given pair of end-points. The Sequence Number and Acknowledgment Number change in most Simpson expires in six months [Page 10] DRAFT IPv6 Header Compression September 1994 datagrams. IPv6 specifies a minimum link MTU of 576 bytes. Most interactive traffic will be single character, while most data transfer traffic will be in units of 256 or greater, up to the 65535 (2**16-1) IPv6 Payload Length. Changes of 2 to 255 are less frequent, and an incrementing field size of 16-bits should be adequate in cases that utilize header compression, allowing a reduction of these fields by half. When the value of either the Sequence or Acknowledgment decreases, or both values remain the same, a duplicate or delayed datagram is assumed, and the conversation history is re-initialized. Whenever the Offset (header length) or Reserved fields change, the conversation history is re-initialized. The Urgent bit is rarely used, and signifies the presence of an Urgent Pointer. The Ack bit is usually set, except during conversation establishment. Whenever the Ack bit is not set, the conversation history is re- initialized. This test is theoretically redundant, since a standard conforming implementation must set Ack in all packets except for the initial Syn packet. The test avoids turning a bogus packet into a valid one. The Push bit changes frequently. It needs a copy in each compressed datagram. Whenever the Reset, Syn, or Fin bits are set, the conversation history is re-initialized. Syn packets are not compressed, because only half of them contain a valid Ack field. Also, they usually contain a TCP option (the Maximum Segment Size), which is not in the following packets. Fin packets are not compressed. Since connections tend to last for many packets, it seemed unreasonable to dedicate an entire bit to a flag that would appear once in the lifetime of the connection. The Window can increase or decrease, but usually does not change. It can be replaced when it changes. The Checksum MUST be included in its entirety. The Urgent Pointer is rarely used. Whenever the Urgent Pointer Simpson expires in six months [Page 11] DRAFT IPv6 Header Compression September 1994 changes, but the Urgent bit is not set, the conversation history is re-initialized. The Urgent Pointer shouldn't change when the Urgent bit is clear, but this is not explicitly required, and therefore is permitted. The Options and Padding are treated as an opaque series of bytes. Any changes cause the conversation history to be re-initialized. There are two important special cases: (1) The Sequence Number changes by the amount of data in the previous packet, but the Acknowledgment Number does not change. This is the case for the sending side of non-echoed interactive traffic or unidirectional data transfer. (2) The Sequence Number and Acknowledgment Number both change by the amount of data in the previous packet. This is the case for echoed interactive traffic. In order to provide a special flag for these circumstances, whenever all three of the Window and Urgent Pointer and Sequence Number change, the conversation history is re-initialized. Simpson expires in six months [Page 12] DRAFT IPv6 Header Compression September 1994 3. Compression Algorithms Two strategies are described below for compressing IPv6 headers. This specification requires that implementations MUST support these IPv6 Header Compression strategies, and provides a mechanism for future extensions. The first strategy is to compress only the IPv6 header, and such following headers which are recognized and compressable. This compression algorithm can be used to compress any IPv6 packet, without affecting the transport protocol. In addition, those specific transport headers which are most commonly used, but which are not sequenced, are also compressed as a natural extension of the IPv6 Header Compression. Currently, only the UDP datagram header is compressed by this method. The other strategy is to compress those headers which include end- to-end reliability and sequencing. This algorithm is simpler, and able to respond faster to changes in traffic. Currently, only the TCP datagram header is compressed by this method. IPv6 Header Compression must be negotiated by some means (such as PPP IPCP [RFC-1332]). Each peer must negotiate the desired options, such as the maximum number of concurrent conversation slots which will be maintained in each direction. Implementations of this header compression protocol will maintain send and receive tables indicating the state of each conversation. A separate pair of tables is maintained for each direction that header compression is enabled. The original header for each conversation is stored in a "slot" in the tables. Both peers keep a copy of the full IPv6 Headers corresponding to each slot. The sending side (compressor) uses this information to determine the fields that have changed. The receiving side (decompressor) uses this information to reconstruct the original packet header. The index into the table is termed the "Conversation Slot Number", or simply "Slot" for short. Simpson expires in six months [Page 13] DRAFT IPv6 Header Compression September 1994 3.1. Compressing Datagram Headers Compression of the IPv6 Headers and unreliable transport datagrams (such as UDP) requires a handshake to ensure that both peers have arrived at the same state. A Confirmation Request packet is sent to propose compression of a specific conversation. Should a Confirmation Request packet be lost, if the sender sends a compressed packet, the receiver cannot decompress the packet correctly. It is necessary that the sender of a Confirmation Request packet be assured that the packet has been received before sending compressed packets. The peer Confirms the receipt of the Confirmation Request packet, and indicated which of the headers it is capable of decompressing. There is not sufficient information in the IPv6 headers alone to determine when a subsequent loss of state has occured. When state is lost through reinitialization of a sender, new Confirmation Request packets are easily sent to renew the state. If state is lost for a link receiver, previously confirmed conversations will not be decompressed correctly. Whenever any error packet is received, or the link fails, the receiver clears all of its Confirmed slots. When compressed packets are received for an uninitialized slot, a Reset indication is returned to indicate the loss of state. On receipt of a Reset, the compressor clears all of its Confirmed slots. Simpson expires in six months [Page 14] DRAFT IPv6 Header Compression September 1994 3.2. Compressing Sequenced Headers Compression of sequenced transport headers (such as TCP) does not require any handshake. An Unconfirmed Initialization packet is sent to indicate compression of a specific conversation. No confirmation is required. Compressed datagrams can be sent immediately. Should an Unconfirmed Initialization packet be lost, when the sender sends a following compressed packet, the receiver cannot decompress the packet correctly. When compressed packets are received for an uninitialized slot, the packet is dropped, and a Reset indication returned, but only Confirmed slots are cleared. In the event of any other loss of state, an incorrect checksum will be detected at the destination. Retransmission will be triggered by the normal transport-layer mechanisms. The re-transmitted datagram can be easily identified, by comparing the Sequence and Acknowlegment Numbers (as described previously). 4. Control Packets The IPv6 Compression Packet Header specifies the type of the packet, and any options for that packet. The low order bits specify the packet type. Compressed packets have a most significant bit of one. Simpson expires in six months [Page 15] DRAFT IPv6 Header Compression September 1994 4.1. Confirmation Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Slot | Number | Proposed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Slot The Slot to be assigned. Slots are numbered starting at zero and continue to the maximum number of slots minus one. Number The Incarnation of the use of this Slot. This is used to associate requests with replies. For each Slot, the Number will increment with every Confirmation Request sent which includes any changes in header information. Different slots may have the same Number. The combination of Slot and Number uniquely identify a header. In practice, the Number octet can be any value which is unique for a "reasonably long period" of time. A reasonably long period is a function of transmission speed, round trip delays, and network load. There must be very little chance of duplicate Numbers within this period. Otherwise, there is ambiguity as to which header is being identified. Proposed The final Next Header value which is proposed for compression. When only the IPv6 Header can be compressed, the value is zero, even when Hop-by-Hop Options are not present. The Confirmation Request is used by the compressor to inform the decompressor of the original packet header which will be used for subsequent compression, and request Confirmation. It is sent each time a different header format is sent for a given slot, or when the compressor has not received a Confirmation Reply from the decompressor. A Confirmation Request header is followed by a complete IPv6 packet. Simpson expires in six months [Page 16] DRAFT IPv6 Header Compression September 1994 4.2. Confirmation Reply +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Slot | Number | Accepted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Slot Copied from the request. Number Copied from the request. Accepted The final Next Header value which is acceptable for compression. This MUST be a header which appears at or before the Proposed header. The Confirmation Reply is used by the decompressor to tell the compressor that it has received the Confirmation Request. When the compressor receives this, it can start sending Compressed datagrams. Simpson expires in six months [Page 17] DRAFT IPv6 Header Compression September 1994 4.3. Reset +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ Type 3 The Reset is used by the decompressor to tell the compressor that it has received a Compressed packet which it does not understand how to process, or that it has received any otherwise uninterpretable packet. See "Error Handling" for further details. When the compressor receives this packet, it must clear any slots initialized by Confirmed Requests. Simpson expires in six months [Page 18] DRAFT IPv6 Header Compression September 1994 4.4. Unconfirmed Initialization +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Slot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Slot The Slot to be assigned. Slots are numbered starting at zero and continue to the maximum number of slots minus one. The Unconfirmed Initialization is used by the compressor to inform the decompressor of the original packet header which will be used for subsequent compression, without requesting confirmation. After sending an Unconfirmed Initialization packet, the compressor may immediately send Compressed packets. An Unconfirmed Initialization header is followed by a complete IPv6 packet. Simpson expires in six months [Page 19] DRAFT IPv6 Header Compression September 1994 4.5. Reject +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Slot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Slot Copied from the Unconfirmed Initialization. The Reject is used by the decompressor to tell the compressor that it has received an Unconfirmed Initialization which it does not understand how to process. This is provided for future expansion. When the compressor receives this packet, it should record the IPv6 Next Header associated with that Slot as uncompressible. Future packets of this type should be sent with only Confirmed Requests. Simpson expires in six months [Page 20] DRAFT IPv6 Header Compression September 1994 4.6. Compressed Simple Headers +-+-+-+-+-+-+-+-+- - - - - - - -+- - - - - - - - - - - - - - - -+ |1|C| 0 | Slot | Authentication ... +-+-+-+-+-+-+-+-+- - - - - - - -+- - - - - - - - - - - - - - - -+ | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C Conversation specified. When this bit is set, the Flag byte is immediately followed by the Conversation Slot byte. Otherwise, the previous Slot is assumed. By default, Slot compression is disabled, and every packet has the slot number included. Slot compression MUST only be enabled in a receiver which can account for all erroneous and discarded packets. When a packet has been discarded, the Slot is indeterminate for future packets. The decompressor MUST discard all further packets until a new Slot is received. Slot When present, specifies the number of the slot assigned by prior initialization. The Compressed Simple Headers control fields MAY be followed by several value fields. Authentication Whenever an Authentication Header is present, its data fields are included. If not zero, the Reserved field is included. The Authentication Data field is included. UDP Checksum Whenever the UDP Header is present, the Checksum is always included, even when zero. The UDP Checksum is always followed by the UDP data. Simpson expires in six months [Page 21] DRAFT IPv6 Header Compression September 1994 4.7. Compressed Fragmentation Header +-+-+-+-+-+-+-+-+- - - - - - - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|C|F|M| 0 | Slot | Change Value | +-+-+-+-+-+-+-+-+- - - - - - - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C Conversation specified. See above. F First. Indicates that the Fragment Offset field is zero. M More. When the "F" bit is set, a copy of the More fragments bit. Otherwise, this bit is set to zero, and ignored on receipt. Slot When present, specifies the number of the slot assigned by prior initialization. Change Value Always present. When the "F" bit is set, used as an increment to the Identification field. Otherwise, used to replace the Offset, reserved, and M-bit, as previously described. The Compressed Fragmentation Header control fields are followed by the remainder of the fragment, without interpretation. Simpson expires in six months [Page 22] DRAFT IPv6 Header Compression September 1994 4.8. Compressed TCP +-+-+-+-+-+-+-+-+- - - - - - - -+- - - - - - - - - - - - - - - -+ |1|C|I|P|S|A|W|U| Slot | Authentication ... +-+-+-+-+-+-+-+-+- - - - - - - -+- - - - - - - - - - - - - - - -+ | TCP Checksum | IPv4 Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+ | Sequence Increment | Acknowledgment Increment | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ | Window Replacement | Urgent Replacement | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ C Conversation specified. See above. I Identifier specified, for compatibility with IPv4. IPv4 has the Fragment Identifier in the IPv4 Header. When set, the IPv4 Identifier field is present. Otherwise, the IPv4 Identifier is incremented by one. This has no effect on the IPv6 Fragment Identification. P Push bit. This is copied directly to/from the TCP Header. S When set, the Sequence Increment is present, except in the special cases described below. A When set, the Acknowledgment Increment is present, except in the special cases described below. W When set, the Window Replacement is present, except in the special cases described below. U When set, the Urgent Replacement is present, except in the special cases described below. SWU This special case indicates that the Sequence Number increments by one, and the Acknowledgment Number remains unchanged (this is reversed from [RFC- 1144]). SAWU This special case indicates that both the Sequence Number and Acknowledgment Number increment by one Simpson expires in six months [Page 23] DRAFT IPv6 Header Compression September 1994 (this is reversed from [RFC-1144]). Slot When present, specifies the number of the slot assigned by prior initialization. Authentication Whenever an Authentication Header is present, its data fields are included. If not zero, the Reserved field is included. The Authentication Data field is included. TCP Checksum Whenever the TCP Header is present, the Checksum is always included, even when zero. IPv4 Identifier When present, this field is copied to/from the IPv4 Header. Sequence Increment When present, this field is added to the TCP Sequence Number. Acknowledgment Increment When present, this field is added to the TCP Acknowledgment Number. Window Replacement When present, this field is copied to/from the TCP Header. Urgent Replacement When present, this field is copied to/from the TCP Header. The Compressed TCP control fields are followed by the TCP data. Simpson expires in six months [Page 24] DRAFT IPv6 Header Compression September 1994 5. Compression Negotiation over PPP Links For PPP links [RFC-1661], the use of header compression can be negotiated by IPCP [RFC-1332]. By default, no compression is enabled. The IP-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. A summary of the IP-Compression-Protocol Configuration Option format to negotiate IPv6 Header Compression (IP6HC) is shown below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 6 IP-Compression-Protocol 004f IPv6 Header Compression Max-Slot Indicates the largest Slot number. This is one less than the actual number of slots; the Slot has values from zero to Max-Slot. Implementations MUST correctly handle Slot numbers from 0 to 3, and SHOULD handle numbers from 0 to 15. Support for more Slots are not prohibited, and negotiation MUST gracefully fall back to fewer Slots. Options This field is comprised of the "logical or" of the following values: 1 The slot identifer may be compressed. Simpson expires in six months [Page 25] DRAFT IPv6 Header Compression September 1994 Security Considerations Security issues are not discussed in this memo. References [Clark] Clark, D. D., "The design philosophy of the DARPA Internet protocols", In Proceedings of SIGCOMM '88 (Stanford, CA, August 1988), ACM. [Malamud] Malamud, C., "Exploring the Internet", pp 149-150, 1992. [Salthouse]Salthouse, T. A., "The skill of typing", Scientific American 250, 2 (Feb. 1984), 128--135. [Shneiderman] Shneiderman, B., "Designing the User Interface", Addison- Wesley, 1987. [RFC-768] [RFC-793] [RFC-896] Nagle, J., "Congestion Control in IP/TCP Internetworks", SRI International, Menlo Park, CA, January 1984. [RFC-1144]Jacobson, V., "Compressing TCP/IP Headers", January 1990. [RFC-1332]McGregor, G., "PPP Internet Protocol Control Protocol (IPCP)", Merit, May 1992. [RFC-1661]Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", Daydreamer, May 1994. [#0] Deering, "IPv6", work in progress. [#1] Atkinson, "Authentication", work in progress. [#2] Simpson, "Mobility", work in progress. Author's Address Questions about this memo can also be directed to: Simpson expires in six months [Page 26] DRAFT IPv6 Header Compression September 1994 William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Simpson expires in six months [Page 27] DRAFT IPv6 Header Compression September 1994 Table of Contents 1. Introduction .......................................... 1 1.1 Interactive Response ............................ 1 1.2 Bulk Transfer ................................... 2 1.3 Interleaved Traffic ............................. 2 1.4 Asymmetric Traffic .............................. 3 1.5 Shared State .................................... 3 1.6 Link Data Compression ........................... 4 1.7 Fewer Headers ................................... 4 1.8 Heterogeneity ................................... 5 1.9 Complexity ...................................... 5 2. The Headers ........................................... 6 2.1 IPv6 Header ..................................... 6 2.2 Hop-by-Hop Options .............................. 7 2.3 Routing Header .................................. 7 2.4 Fragment header ................................. 8 2.5 Authentication header ........................... 9 2.6 End-to-End Options .............................. 9 2.7 UDP header ...................................... 10 2.8 TCP header ...................................... 10 3. Compression Algorithms ................................ 13 3.1 Compressing Datagram Headers .................... 14 3.2 Compressing Sequenced Headers ................... 15 4. Control Packets ....................................... 15 4.1 Confirmation Request ............................ 16 4.2 Confirmation Reply .............................. 17 4.3 Reset ........................................... 18 4.4 Unconfirmed Initialization ...................... 19 4.5 Reject .......................................... 20 4.6 Compressed Simple Headers ....................... 21 4.7 Compressed Fragmentation Header ................. 22 4.8 Compressed TCP .................................. 23 5. Compression Negotiation over PPP Links ................ 25 SECURITY CONSIDERATIONS ...................................... 26 REFERENCES ................................................... 26 AUTHOR'S ADDRESS ............................................. 26 DRAFT IPv6 Header Compression September 1994