RFC 6846
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
8.3. Feedback Formats and Options
8.3.1. Feedback Formats
This section describes the feedback formats for the ROHC-TCP profile, following the general ROHC feedback format described in Section 5.2.4 of [RFC5795]. All feedback formats carry a field labeled MSN. The MSN field contains LSBs of the MSN control field described in Section 6.1.1. The sequence number to use is the MSN corresponding to the last header that was successfully CRC-8 validated or CRC verified. FEEDBACK-1 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | MSN | +---+---+---+---+---+---+---+---+ MSN: The LSB-encoded master sequence number. A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used. FEEDBACK-2 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |Acktype| MSN | +---+---+---+---+---+---+---+---+ | MSN | +---+---+---+---+---+---+---+---+ | CRC | +---+---+---+---+---+---+---+---+ / Feedback options / +---+---+---+---+---+---+---+---+ Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used for parsability)
MSN: The LSB-encoded master sequence number.
CRC: 8-bit CRC computed over the entire feedback element (as
defined in Section 5.3.1.1 of [RFC5795]). For the purpose of
computing the CRC, the CRC field is zero. The CRC is calculated
using the polynomial defined in [RFC5795].
Feedback options: A variable number of feedback options, see
Section 8.3.2. Options may appear in any order.
A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an
acknowledgment for a successfully decompressed packet, which packet
corresponds to the MSN of the feedback element, unless the MSN-NOT-
VALID option (Section 8.3.2.2) appears in the feedback element.
The FEEDBACK-2 format always carries a CRC and is thus more robust
than the FEEDBACK-1 format. When receiving FEEDBACK-2, the
compressor MUST verify the information by computing the CRC and by
comparing the result with the CRC carried in the feedback format. If
the two are not identical, the feedback element MUST be discarded.
8.3.2. Feedback Options
A ROHC-TCP feedback option has variable length and the following
general format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Length (octets)
+---+---+---+---+---+---+---+---+
Each ROHC-TCP feedback option can appear at most once within a
FEEDBACK-2.
8.3.2.1. The REJECT Option
The REJECT option informs the compressor that the decompressor does
not have sufficient resources to handle the flow.
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor MUST stop compressing the packet flow, and SHOULD refrain from attempting to increase the number of compressed packet flows for some time. The REJECT option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.8.3.2.2. The MSN-NOT-VALID Option
The MSN-NOT-VALID option indicates that the MSN of the feedback is not valid. +---+---+---+---+---+---+---+---+ | Opt Type = 3 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ A compressor MUST ignore the MSN of the feedback element when this option is present. Consequently, a NACK or a STATIC-NACK feedback type sent with the MSN-NOT-VALID option is equivalent to a STATIC- NACK with respect to the semantics of the feedback message. The MSN-NOT-VALID option MUST NOT appear more than once in the FEEDBACK-2 format and MUST NOT appear in the same feedback element as the MSN option; otherwise, the compressor MUST discard the entire feedback element.8.3.2.3. The MSN Option
The MSN option provides 2 additional bits of MSN. +---+---+---+---+---+---+---+---+ | Opt Type = 4 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | MSN | Reserved | +---+---+---+---+---+---+---+---+ These 2 bits are the least significant bits of the MSN and are thus concatenated with the 14 bits already present in the FEEDBACK-2 format. The MSN option MUST NOT appear more than once in the FEEDBACK-2 format and MUST NOT appear in the same feedback element as the MSN- NOT-VALID option; otherwise, the compressor MUST discard the entire feedback element.
8.3.2.4. The CONTEXT_MEMORY Feedback Option
The CONTEXT_MEMORY option means that the decompressor does not have sufficient memory resources to handle the context of the packet flow, as the flow is currently compressed. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 9 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet flow in a way that requires less decompressor memory resources, or stop compressing the packet flow. The CONTEXT_MEMORY option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.8.3.2.5. Unknown Option Types
If an option type unknown to the compressor is encountered, the compressor MUST continue parsing the rest of the FEEDBACK element, which is possible since the length of the option is explicit, but MUST otherwise ignore the unknown option.9. Changes from RFC 4996
This RFC revises RFC 4996. It is mostly backwards-compatible with RFC 4996, except for two cases that did not interoperate as described below.9.1. Functional Changes
o The SACK option compression in [RFC4996] assumed that multiple SACK blocks within the same option would be in sorted order so that the block starts were LSB-encoded from the end of the previous block. This meant that SACK blocks that are not in sorted order could be impossible to compress in some cases. Therefore, the SACK compression in the formal notation has changed and therefore also the bits-on-the-wire. o The ESP NULL header compression has been deprecated due to interoperability problems with needing to know information from the trailer. The ESP NULL compression was already removed from ROHCv2 [RFC5225] for the same reason and it was considered better to remove it from this profile rather than try to fix the interoperability issue.
9.2. Non-functional Changes
o The way sequential IP-ID compression was described in the FN code was incorrect and the code used for ROHCv2 [RFC5225] has been imported into this specification (e.g., offset is made into a global control field). This does not change the bits-on-the-wire. The only change is how this encoding is described in the formal notation, not how the compression occurs. o Default encoding for the 'df' and 'ip_id' fields have been added for IPv6 with 0-bit uncompressed format to clarify that these never appear in IPv6. o The scaled encoding of the Acknowledgment Number and Sequence Number were incorrectly described in the FN code in [RFC4996] and have been updated in the same style as in ROHCv2 [RFC5225]. This does not change the bits-on-the-wire, only the way the compression is described in the FN code. o The external arguments to ipv4 and co_baseheader have been updated. This is again only a change for FN correctness and does not affect interoperability. o Errata for [RFC4996] related to minor errors in the FN and textual errors have also been corrected.10. Security Considerations
A malfunctioning or malicious header compressor could cause the header decompressor to reconstitute packets that do not match the original packets but still have valid IP and TCP headers, and possibly also valid TCP checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms that will not be affected by the compression. Moreover, this header compression scheme uses an internal checksum for verification of reconstructed headers. This reduces the probability of producing decompressed headers not matching the original ones without this being noticed. Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR, CO, or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression.
11. IANA Considerations
The reference for the ROHC profile identifier 0x0006 has been updated to reference this document instead of RFC 4996. A ROHC profile identifier has been reserved by IANA for the profile defined in this document. Profiles 0x0000-0x0005 have previously been reserved; this profile is 0x0006. As for previous ROHC profiles, profile numbers 0xnn06 have been reserved for future updates of this profile. Profile Usage Document identifier 0x0006 ROHC TCP [RFC6846] 0xnn06 Reserved12. Acknowledgments
The authors would like to thank Qian Zhang, Hong Bin Liao, Richard Price, and Fredrik Lindstroem for their work with early versions of this specification. Thanks also to Robert Finking and Carsten Bormann for valuable input and to Carl Knutsson and Gilbert Strom for suggestions and review of the updates made in this document. Additional thanks: this document was reviewed during working group last-call by committed reviewers Joe Touch and Ted Faber, as well as by Sally Floyd, who provided a review at the request of the Transport Area Directors.13. References
13.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context Replication for ROHC Profiles", RFC 4164, August 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007. [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.13.2. Informative References
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999. [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004. [RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005. [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006. [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006. [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007. [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008. [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
Authors' Addresses
Ghyslain Pelletier InterDigital Communications 1000, Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada Phone: +46 (0) 70 609 27 73 EMail: ghyslain.pelletier@interdigital.com Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden Phone: +46 (0) 8 404 41 58 EMail: kristofer.sandlund@ericsson.com Lars-Erik Jonsson Optand 737 Ostersund SE-831 92 Sweden Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com Mark A West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hampshire SO51 0ZN UK Phone: +44 1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk