idnits 2.17.1 draft-vilhuber-hcoip-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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 63 lines 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. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([CRTP], [ECRTP], [IPHC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'TBD IANA' is mentioned on line 146, but not defined == Unused Reference: 'ESP' is defined on line 206, but no explicit reference was found in the text == Unused Reference: 'IPIP' is defined on line 209, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2509 (ref. 'PPPHC') (Obsoleted by RFC 3544) == Outdated reference: A later version (-07) exists of draft-ietf-avt-crtp-enhance-04 ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Vilhuber 3 INTERNET DRAFT Cisco Systems Inc. 4 Expire in July, 2003 January, 2003 6 IP header compression in IP tunneling protocols 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 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 to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Distribution of this memo is unlimited. 32 Abstract 34 Bandwidth consumption of RTP flows can be reduced by tunneling and 35 compressing headers. This draft defines an IP protocol number and a 36 header which can be used to transport IP Header Compressed [IPHC], 37 Compressed RTP [CRTP], and Enhanced Compressed RTP [ECRTP] packets 38 over an arbitrary IP tunnel (IP-in-IP or ESP, for example) to reduce 39 bandwidth consumption for RTP flows. 41 1. Introduction 43 IP header compression [IPHC] and RTP compression [CRTP] can be used 44 to reduce bandwidth consumption, but are only defined for single hops 45 over connections with little to no loss and no packet reordering. 47 [ECRTP] extends the definition of IP header compression to be used 48 over lossy links with the possibility of packet reordering. I.e. 49 ECRTP can be used in protocols that run over the Internet at large. 51 In general, it turns out to be useful to carry IP Header Compressed 52 packets over an IP tunnel (IP-in-IP or IPSec tunnel mode, for 53 example), either because the combination (tunnel+HC) is smaller than 54 the original packet, or because the traffic is already flowing over 55 an existing tunnel, which we could take advantage of. 57 This draft recommends that ECRTP is used in the majority of these 58 cases, as it is expected that the underlying network does not meet 59 the criteria for reliable use of IPHC or CRTP. However, this draft 60 does not exclude IPHC and CRTP, as there may be situations where the 61 underlying network is well-known to be robust against loss and 62 reordering. 64 In this document, the key words "MAY", "MUST", "optional", 65 "recommended", "required", "SHOULD", and "SHOULD NOT", are to be 66 interpreted as described in [RFC2119]. 68 2. IP header compression packet format 70 [IPHC], [CRTP], and [ECRTP] only define the compression mechanisms 71 and compressed packet formats, but leave defining the transport of 72 this compressed packet to the underlying transport mechanism. 74 In this vein, [PPPHC] extends the PPP Data Link Layer Protocol Field 75 values to include the needed Compression Payload Types. For exactly 76 the same reason, we need to define the Compression Payload Types used 77 when carrying a header-compressed packet over an IP tunnel in this 78 draft. 80 The types of Compression Payloads are scattered over [IPHC], [CRTP], 81 and [ECRTP]. The following table names the Compression Payload Type, 82 gives each a number, and specifies which document to look at for the 83 exact definition of the Compression Type. 85 Header Compression Payload Type Value Defined in 86 ------------------------------------------------------------------ 87 IPHC_FULL_HEADER 0 IPHC/CRTP 88 IPHC_COMPRESSED_NON_TCP 1 IPHC/CRTP 89 IPHC_COMPRESSED_TCP 2 IPHC 90 IPHC_COMPRESSED_TCP_NODELTA 3 IPHC 91 IPHC_CONTEXT_STATE 4 IPHC/ECRTP 92 IPHC_COMPRESSED_UDP_8 5 CRTP/ECRTP 93 IPHC_COMPRESSED_UDP_16 6 CRTP/ECRTP 94 IPHC_COMPRESSED_RTP_8 7 CRTP/ECRTP 95 IPHC_COMPRESSED_RTP_16 8 CRTP/ECRTP 96 Reserved by IANA 9-255 98 Table 1: Header Compression Payload Types 100 2.1. IP header compression packet format in IPv4 102 When carried over IPv4, IP header compressed packets will have the 103 following header prepended: 105 0 1 2 3 4 5 6 7 106 +-+-+-+-+-+-+-+-+ 107 ! Comp Type ! 108 +-+-+-+-+-+-+-+-+ 110 Figure 1: IPv4 IP Header Compression Header 112 "Comp Type" is a 1 byte field that carries the "Header Compression 113 Payload Type" value (as defined in Table 1), that indicates the type 114 of compressed payload that follows the header. 116 Anything following the 1 byte Comp Payload type field is Compression 117 context and data, in accordance with the respective type, as defined 118 in the respective documents (see Table 1). 120 The IPv4 Protocol Number for IP Header compressed packets as defined 121 in this draft shall be XXX [TBD IANA]. 123 2.2. IP header compression packet format in IPv6 125 When carried inside IPv6, an IP header compressed packet will be have 126 the IP Header Compression Header prepended. 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 ! Next Header | Comp Type ! 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 2: IPv6 IP Header Compression Header 135 The Next Header field is a regular IPv6 Next Header field. 137 "Comp Type" is a 1 byte field that carries the "Header Compression 138 Payload Type" value (as defined in Table 1), that indicates the type 139 of compressed payload that follows the header. 141 Anything following the 1 byte Comp Payload type field is Compression 142 context and data, in accordance with the respective type, as defined 143 in the respective documents (see Table 1). 145 The IPv6 Next Header value for IP header compressed packets as 146 defined in this draft shall be XXX [TBD IANA] 148 3. Security Considerations 150 This draft does not change the security of any protocol, as it merely 151 provides a mechanism to carry header-compressed packets within 152 another IP protocol. 154 That being said, this draft allows us to carry IP header compressed 155 packets inside IPsec ESP, which provides a way to carry header- 156 compressed packets over the Internet in a secure way. 158 When encryption is used, as in IPsec ESP tunnels, omitting the IP (as 159 well as TCP or UDP/RTP) header removes a large amount of known (or 160 guessable) plaintext from the to-be-encrypted payload. While this can 161 benefit security it still should not be relied upon as a replacement 162 for a strong cryptographic mechanism. 164 4. IANA Considerations 166 IANA is requested to create a new assignment registry for "Header 167 Compression Payload Type Values", initially allowing values in the 168 range 0 to 255 decimal. 170 Assignment of values in this field require: 171 - the identity of the assignee 172 - a brief description of the new Header Compression Payload type 173 - a reference to a stable document describing the Header 174 Compression Payload in detail. 176 During the first year of existence of this registry, IANA is 177 requested to refer all requests to the IETF WG for review. 178 Subsequently, requests should be reviewed by the IETF Area 179 Directors or by an expert that they designate. 181 If the number of assignments begins to approach 255, the Area 182 Directors should be alerted. 184 5. Acknowledgments 186 This document is derived in part from discussions with Cheryl Madson, 187 Mark Gillott, Patrick Ruddy, and Dan Wing. 189 6. References 191 [IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header 192 Compression for IP", RFC 2507, February 1999. 194 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 195 Headers for Low-Speed Serial Links", RFC 2508, February 196 1999. 198 [PPPHC] Engan, Casner, Bormann, "IP Header Compression over PPP", 199 RFC 2509, February 1999 201 [ECRTP] Koren, Casner, Geevarghese, Thompson, Ruddy, "Compressing 202 IP/UDP/RTP headers on links with high delay, packet loss 203 and reordering", draft-ietf-avt-crtp-enhance-04.txt, work in 204 progress, February 2002 206 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 207 Payload", RFC 2406, November 1998 209 [IPIP] Perkins, "IP Encapsulation within IP", RFC 2003, October 1996 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 212 Levels", RFC 2119, March 1997 214 7. Editor's Address 216 Jan Vilhuber 217 218 Cisco Systems, Inc.