idnits 2.17.1 draft-engan-ip-compress-02.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-19) 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 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 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 93 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC1332,RFC2023], [RFC1661], [CRTP], [IPHC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 16 has weird spacing: '...ment is an I...' == Line 17 has weird spacing: '...cuments of t...' == Line 18 has weird spacing: '...ups may also ...' == Line 22 has weird spacing: '... and may be...' == Line 23 has weird spacing: '...me. It is i...' == (88 more instances...) -- 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 17, 1997) is 9620 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: 'RFC1331' is mentioned on line 91, but not defined ** Obsolete undefined reference: RFC 1331 (Obsoleted by RFC 1548) == Unused Reference: 'RFC1144' is defined on line 340, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2023 (Obsoleted by RFC 2472) ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IPng, ISSLL and AVT Working Groups 3 INTERNET-DRAFT Mathias Engan 4 draft-engan-ip-compress-02.txt CDT/Lulea University of Technology 5 S. Casner 6 Precept Software 7 C. Bormann 8 Universitaet Bremen TZI 9 December 17, 1997 10 Expires: 6/98 12 IP Header Compression over PPP 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Distribution of this document is unlimited. 34 Abstract 35 This document describes an option for negotiating the use of 36 header compression on IP datagrams transmitted over the Point-to- 37 Point Protocol [RFC1661]. It defines extensions to the PPP Control 38 Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression 39 may be applied to IPv4 and IPv6 datagrams in combination with TCP, 40 UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. 42 [Note to IANA, to be removed before publication: The PPP protocol 43 type assignments suggested in this document were selected from those 44 unassigned in ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers 45 on December 7, 1997. These selections were presented to the PPPEXT 46 working group at IETF in Washington, DC on December 9, 1997 and were 47 approved as being in the appropriate ranges for this protocol.] 49 1. Introduction 51 The IP Header Compression (IPHC) defined in [IPHC] may be used for 52 compression of both IPv4 and IPv6 datagrams or packets encapsulated 53 with multiple IP headers. IPHC is also capable of compressing both 54 TCP and UDP transport protocol headers. The IP/UDP/RTP header 55 compression defined in [CRTP] fits within the framework defined by 56 IPHC so that it may also be applied to both IPv4 and IPv6 packets. 58 In order to establish compression of IP datagrams sent over a PPP 59 link each end of the link must agree on a set of configuration param- 60 eters for the compression. The process of negotiating link parameters 61 for network layer protocols is handled in PPP by a family of network 62 control protocols (NCPs). Since there are separate NCPs for IPv4 and 63 IPv6, this document defines configuration options to be used in both 64 NCPs to negotiate parameters for the compression scheme. 66 IPHC relies on the link layer's ability to indicate the types of 67 datagrams carried in the link layer frames. In this document nine new 68 types for the PPP Data Link Layer Protocol Field are defined along 69 with their meaning. 71 In general, header compression schemes that use delta encoding of 72 compressed packets require that the lower layer does not reorder 73 packets between compressor and decompressor. IPHC uses delta encoding 74 of compressed packets for TCP and RTP. The IPHC specification [IPHC] 75 includes methods that allow link layers that may reorder packets to 76 be used with IPHC. Since PPP does not reorder packets these mechan- 77 isms are disabled by default. When using reordering mechanisms such 78 as multiclass multilink PPP [MCML], care must be taken so that pack- 79 ets that share the same compression context are not reordered. 81 2. Configuration Option 83 This document specifies a new compression protocol value for the IPCP 84 IP-Compression-Protocol option as specified in [RFC1332]. The new 85 value and the associated option format are described in section 2.1. 87 The option format is structured to allow future extensions to the 88 IPHC scheme. 90 NOTE: The specification of link and network layer parame- 91 ter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] 92 does not prohibit multiple instances of one configuration 93 option but states that the specification of a configuration 94 option must explicitly allow multiple instances. From the 95 current specification of the IPCP IP-Compression-Protocol 96 configuration option [RFC1332, p 6] it follows that it can 97 only be used to select a single compression protocol at any 98 given time. 100 NOTE: [RFC1332] is not explicit about whether the option 101 negotiates the capabilities of the receiver or of the 102 sender. In keeping with current practice, we assume that 103 the option describes the capabilities of the decompressor 104 (receiving side) of the peer that sends the Config-Req. 106 2.1. Configuration Option Format 108 Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 109 NCP, IPV6CP [RFC2023] may be used to negotiate IP Header Compression 110 parameters for their respective protocols. The format of the configura- 111 tion option is the same for both IPCP and IPV6CP. 113 Description 115 This NCP configuration option is used to negotiate parameters for 116 IP Header Compression. The option format is summarized below. 117 The fields are transmitted from left to right. 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Type | Length | IP-Compression-Protocol | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | TCP_SPACE | NON_TCP_SPACE | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | F_MAX_PERIOD | F_MAX_TIME | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | MAX_HEADER | suboptions... 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Type 132 2 134 Length 135 >= 14 137 The length may be increased if the presence of additional parame- 138 ters is indicated by additional suboptions. 140 IP-Compression-Protocol 141 0061 (hex) 143 TCP_SPACE 144 The TCP_SPACE field is two octets and indicates the maximum 145 value of a context identifier in the space of context identifiers 146 allocated for TCP. 148 Suggested value: 15 150 TCP_SPACE must be at least 0 and at most 255 (The value 0 implies 151 having one context). 153 NON_TCP_SPACE 154 The NON_TCP_SPACE field is two octets and indicates the maximum 155 value of a context identifier in the space of context identifiers 156 allocated for non-TCP. These context identifiers are carried in 157 COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet 158 headers. 160 Suggested value: 15 162 NON_TCP_SPACE must be at least 0 and at most 65535 (The value 0 163 implies having one context). 165 F_MAX_PERIOD 166 Maximum interval between full headers. No more than F_MAX_PERIOD 167 COMPRESSED_NON_TCP headers may be sent between FULL_HEADER 168 headers. 170 Suggested value: 256 172 A value of zero implies infinity, i.e. there is no limit to the 173 number of consecutive COMPRESSED_NON_TCP headers. 175 F_MAX_TIME 176 Maximum time interval between full headers. COMPRESSED_NON_TCP 177 headers may not be sent more than F_MAX_TIME seconds after sending 178 the last FULL_HEADER header. 180 Suggested value: 5 seconds 182 A value of zero implies infinity. 184 MAX_HEADER 185 The largest header size in octets that may be compressed. 187 Suggested value: 168 octets 189 The value of MAX_HEADER should be large enough so that at least 190 the outer network layer header can be compressed. To increase 191 compression efficiency MAX_HEADER should be set to a value large 192 enough to cover common combinations of network and transport layer 193 headers. 195 suboptions 196 The suboptions field consists of zero or more suboptions. Each 197 suboption consists of a type field, a length field and zero or 198 more parameter octets, as defined by the suboption type. The 199 value of the length field indicates the length of the suboption in 200 its entirety, including the lengths of the type and length fields. 202 0 1 2 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | Parameters... 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 2.2 RTP-Compression Suboption 210 The RTP-Compression suboption is included in the NCP IP-Compression- 211 Protocol option for IPHC if IP/UDP/RTP compression is to be enabled. 213 After successful negotiation of parameters for IP Header Compression 214 the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, 215 COMPRESSED_TCP_NODELTA and COMPRESSED_NON_TCP is enabled, regardless 216 of the prescence of an RTP-Compression suboption. 218 Description 220 Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP 221 and CONTEXT_STATE as specified in [CRTP]. 223 0 1 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Type 230 1 232 Length 233 2 235 3. Multiple Network Control Protocols 237 The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. 238 Both IPCP and IPV6CP are able to negotiate option parameter values 239 for IPHC. These values apply to the compression of packets where the 240 outer header is an IPv4 header and an IPv6 header, respectively. 242 3.1. Sharing Context Identifier Space 244 For the compression and decompression of IPv4 and IPv6 datagram 245 headers the context identifier space is shared. While the parameter 246 values are independently negotiated, sharing the context identifier 247 spaces becomes more complex when the parameter values differ. Since 248 the compressed packets share context identifier space, the compres- 249 sion engine must allocate context identifiers out of a common pool; 250 for compressed packets, the decompressor has to examine the context 251 state to determine what parameters to use for decompression. 253 Context identifier spaces are not shared between TCP and non- 254 TCP/UDP/RTP. Doing so would require additional mechanisms to ensure 255 that no error can occur when switching from using a context identif- 256 ier for TCP to non-TCP. 258 4. Demultiplexing of Datagrams 260 The IPHC specification [IPHC] defines four header formats for dif- 261 ferent types of compressed headers. They are compressed TCP, 262 compressed TCP with no delta encoding, compressed non-TCP with 8 bit 263 CID and compressed non-TCP with 16 bit CID. The two non-TCP formats 264 may be distinguished by their contents so both may use the same 265 link-level identifier. A fifth header format, the full header is 266 distinct from a regular header in that it carries additional informa- 267 tion to establish shared context between the compressor and 268 decompressor. 270 The specification of IP/UDP/RTP Header Compression [CRTP] defines 271 four additional formats of compressed headers. They are for 272 compressed UDP and compressed RTP (on top of UDP), both with either 273 8- or 16-bit CIDs. In addition, there is an explicit error message 274 from the decompressor to the compressor. 276 The link layer must be able to indicate these header formats with 277 distinct values. Nine PPP Data Link Layer Protocol Field values are 278 specified below. 280 FULL_HEADER 281 The frame contains a full header as specified in [CRTP] Section 282 3.3.1. This is the same as the FULL_HEADER specified in [IPHC] 283 Section 5.3. 284 Value: 0061 (hex) 286 COMPRESSED_TCP 287 The frame contains a datagram with a compressed header with the 288 format as specified in [IPHC] Section 6a. 289 Value: 0063 (hex) 291 COMPRESSED_TCP_NODELTA 292 The frame contains a datagram with a compressed header with the 293 format as specified in [IPHC] Section 6b. 294 Value: 2063 (hex) 296 COMPRESSED_NON_TCP 297 The frame contains a datagram with a compressed header with the 298 format as specified in either Section 6c or Section 6d of [IPHC]. 299 Value: 0065 (hex) 301 COMPRESSED_RTP_8 302 The frame contains a datagram with a compressed header with the 303 format as specified in [CRTP] Section 3.3.2, using 8-bit CIDs. 304 Value: 0069 (hex) 306 COMPRESSED_RTP_16 307 The frame contains a datagram with a compressed header with the 308 format as specified in [CRTP] Section 3.3.2, using 16-bit CIDs. 309 Value: 2069 (hex) 311 COMPRESSED_UDP_8 312 The frame contains a datagram with a compressed header with the 313 format as specified in [CRTP] Section 3.3.3, using 8-bit CIDs. 314 Value: 0067 (hex) 316 COMPRESSED_UDP_16 317 The frame contains a datagram with a compressed header with the 318 format as specified in [CRTP] Section 3.3.3, using 16-bit CIDs. 319 Value: 2067 (hex) 321 CONTEXT_STATE 322 The frame is a link-level message sent from the decompressor to 323 the compressor as specified in [CRTP] Section 3.3.5. 324 Value: 2065 (hex) 326 5. References 328 [CRTP] Casner, S., Jacobson, V., "Compressing IP/UDP/RTP Headers 329 for Low-Speed Serial Links", Internet-Draft 330 draft-ietf-avt-crtp (work in progress), November 21, 1997, 331 expires May 1998. 333 [IPHC] Degermark, M., Nordgren, B., Pink, S., "Header Compression 334 for IP", Internet-Draft draft-degermark-ipv6-hc (work in 335 progress), November 18, 1997, expires May 1998. 337 [RFC2023] Haskin, E., Allan, E., "IP Version 6 over PPP", RFC 2023, 338 October 1996. 340 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- 341 Speed Serial Links", RFC 1144, February 1990. 343 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 344 (IPCP)", RFC 1332, May 1992. 346 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, 347 V., "RTP: A Transport Protocol for real-time applica- 348 tions", RFC 1889, January 1996. 350 [RFC1661] Simpson, W., ed., "The Point-To-Point Protocol (PPP)", 351 RFC 1661, July 1994. 353 [MCML] Bormann, C., "The Multi-Class Extension to Multi-Link 354 PPP", Internet-Draft draft-ietf-issll-isslow-mcml (work in 355 progress), May 1997, expires November 1997. 357 6. Security Considerations 359 Negotiation of the option defined here imposes no additional security 360 considerations beyond those that otherwise apply to PPP [RFC1661]. 362 The use of header compression can, in rare cases, cause the mis- 363 delivery of packets. If necessary, confidentiality of packet contents 364 should be assured by encryption. Encryption applied at the IP layer 365 (e.g., using IPSEC mechanisms) precludes header compression of the 366 encrypted headers, though compression of the outer IP header and 367 authentication/security headers is still possible as described in 368 [IPHC]. For RTP packets, full header compression is possible if the 369 RTP payload is encrypted by itself without encrypting the UDP or RTP 370 headers, as described in [RFC1889]. This method is appropriate when 371 the UDP and RTP header information need not be kept confidential. 373 7. Authors' Addresses 375 Mathias Engan 376 CDT/Dept of Computer Communication 377 Lulea University of Technology 378 S-971 87 Lulea, Sweden 379 Phone: +46 920 72288 380 Mobile: +46 70 522 8109 381 Fax: +46 920 72801 382 EMail: engan@cdt.luth.se 384 Stephen L. Casner 385 Precept Software, Inc. 386 1072 Arastradero Road 387 Palo Alto, CA 94304 388 United States 389 EMail: casner@precept.com 391 Carsten Bormann 392 Universitaet Bremen FB3 TZI 393 Postfach 330440 394 D-28334 Bremen, GERMANY 395 EMail: cabo@tzi.uni-bremen.de 396 Phone: +49.421.218-7024 397 Fax: +49.421.218-7000