idnits 2.17.00 (12 Aug 2021) /tmp/idnits12234/draft-ietf-rohc-ip-only-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 28, 2002) is 7144 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: 'END' is mentioned on line 168, but not defined ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L-E. Jonsson 3 INTERNET-DRAFT Ericsson 4 Expires: April 2003 October 28, 2002 6 RObust Header Compression (ROHC): 7 A Compression Profile for IP 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is a submission of the IETF ROHC WG. Comments should be 31 directed to the ROHC WG mailing list, rohc@ietf.org. 33 Abstract 35 The original RObust Header Compression (ROHC) RFC, RFC 3095, defines 36 a framework for header compression, along with compression protocols 37 (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed 38 packet streams. However, no profile was defined for compression of IP 39 only, which has been identified as a flaw in RFC 3095. This document 40 addresses that problem and defines a ROHC compression profile for IP, 41 similar to the IP/UDP profile defined by RFC 3095, but simplified to 42 exclude UDP. 44 Table of Contents 46 1. Introduction..................................................2 47 2. Terminology...................................................2 48 3. ROHC IP Compression (Profile 0x0004)..........................3 49 4. Security Considerations.......................................4 50 5. IANA Considerations...........................................4 51 6. References....................................................4 52 7. Author's Address..............................................4 54 1. Introduction 56 The original RObust Header Compression (ROHC) RFC [RFC-3095] defines 57 a framework for header compression, along with compression protocols 58 (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed 59 packet streams. The profile for uncompressed data was defined to 60 provide means to encapsulate all traffic over a link within ROHC 61 packets. Through this profile, the lower layers do not have to 62 provide multiplexing for different packet types, but instead ROHC can 63 handle any packet stream, even if compression profiles for all kinds 64 of packet streams have yet not been defined or implemented over the 65 link. 67 Although the profile without compression is simple and can tunnel 68 arbitrary packets, it has of course a major weakness in that it does 69 not compress the headers at all. When considering that normally all 70 packets are expected to be IP [RFC-791, RFC-1883] packets, and that 71 the IP header often represent a major part of the total header, a 72 useful alternative to no compression would for most packets be 73 compression of the IP header only. Unfortunately, such a profile was 74 not defined in [RFC-3095], and this has thus been identified as an 75 important missing piece in the ROHC toolbox. 77 This document addresses this missing compression support and defines 78 a ROHC compression profile for IP [RFC-791, RFC-1883] only, similar 79 to the IP/UDP profile defined by [RFC-3095], but simplified to 80 exclude UDP. Due to the similarities with the IP/UDP profile, the IP 81 compression profile is described based on the IP/UDP profile, mainly 82 covering differences. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC-2119]. 90 ROHC UDP 92 "ROHC UDP" in this document refers to the IP/UDP profile 93 (Profile 0x0002) as defined in [RFC-3095]. 95 3. ROHC IP Compression (Profile 0x0004) 97 In principle, there is no real difference between the ROHC UDP 98 profile and the IP profile defined in this document, since the 99 removal of UDP does not at all effect the compression mechanisms. As 100 for ROHC UDP, the compressor generates a 16-bit sequence number which 101 increases by one for each packet compressed in the packet stream, 102 called SN or IP SN below. Unless stated explicitly below, mechanisms 103 and formats are as for ROHC UDP. 105 3.1. Initialization 107 The static context for ROHC IP compression can be initialized in 108 either of two ways: 110 1) By using an IR packet as in ROHC UDP, where the profile is 111 0x0004 and the static chain ends with the static part of an 112 IP header. 114 ********************************************************************* 115 * Note: An open issue is how to terminate the static chain. Any * 116 * NextHdr/Protocol other than 4 (IPinIP) or 41 (IPv6) would * 117 * terminate the chain, but so would also a third IP header. * 118 ********************************************************************* 120 At the compressor, IP SN is initialized to a random 121 value when the IR packet is sent. 123 2) By reusing an existing context where the existing static chain 124 contains the static part of an IP header. 126 ********************************************************************* 127 * Note: This will have to be revised based on what is decided for * 128 * the above issue. * 129 ********************************************************************* 131 As for ROHC UDP, this is done with an IR-DYN packet, identifying 132 profile 0x0004, where the dynamic chain corresponds to the prefix 133 of the existing static chain that ends with the IP header. 135 ********************************************************************* 136 * Note: This will have to be revised based on what is decided for * 137 * the above issue. * 138 ********************************************************************* 140 At the compressor, IP SN is initialized to a random value. 142 For ROHC IP, the dynamic part of a compressed packet is similar to 143 the one for ROHC UDP, with a two-octet field containing the SN added 144 to the end of the chain. This affects the format of dynamic chains in 145 IR and IR-DYN packets. 147 4. Security Considerations 149 The security considerations of [RFC-3095] apply equally to this 150 document, without exceptions or additions. 152 5. IANA Considerations 154 ROHC profile identifier 0x0004 has been reserved by the IANA for the 155 profile defined in this document. 157 [TO BE REMOVED BEFORE PUBLICATION] 158 A ROHC profile identifier must be reserved by the IANA for the 159 profile defined in this document. Profile number 0x0004 has 160 previously been saved for this purpose, and should thus be used. 161 As for previous ROHC profiles, profile numbers 0xnnXX must also be 162 reserved for future updates of this profile. A suggested 163 registration in the "RObust Header Compression (ROHC) Profile 164 Identifiers" name space would then be: 166 0x0004 ROHC IP [RFCXXXX (this)] 167 0xnn04 Reserved 168 [END] 170 6. References 172 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", RFC 2119, March 1997. 175 [RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 176 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 177 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 178 K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust 179 Header Compression (ROHC)", RFC 3095, July 2001. 181 [RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981. 183 [RFC-1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 184 (IPv6) Specification", RFC 1883, December 1995. 186 7. Author's Address 188 Lars-Erik Jonsson Tel: +46 920 20 21 07 189 Ericsson AB Fax: +46 920 20 20 99 190 Box 920 191 SE-971 28 Lulea 192 Sweden EMail: lars-erik.jonsson@ericsson.com 194 Full Copyright Statement 196 Copyright (C) The Internet Society (2001). All Rights Reserved. 198 This document and translations of it may be copied and furnished to 199 others, and derivative works that comment on or otherwise explain it 200 or assist in its implementation may be prepared, copied, published 201 and distributed, in whole or in part, without restriction of any 202 kind, provided that the above copyright notice and this paragraph are 203 included on all such copies and derivative works. However, this 204 document itself may not be modified in any way, such as by removing 205 the copyright notice or references to the Internet Society or other 206 Internet organizations, except as needed for the purpose of 207 developing Internet standards in which case the procedures for 208 copyrights defined in the Internet Standards process must be 209 followed, or as required to translate it into languages other than 210 English. 212 The limited permissions granted above are perpetual and will not be 213 revoked by the Internet Society or its successors or assigns. 215 This document and the information contained herein is provided on an 216 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 217 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 218 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 219 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 220 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 222 This Internet-Draft expires April 28, 2003.