idnits 2.17.1 draft-vilhuber-hcoesp-01.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 13 longer pages, the longest (page 3) being 79 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([CRTP], [HCOIP], [ECRTP], [IPHC], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: 'RFC2507' is mentioned on line 270, but not defined == Missing Reference: 'RFC2508' is mentioned on line 182, but not defined == Missing Reference: 'TBD IANA' is mentioned on line 497, but not defined == Unused Reference: 'IPIP' is defined on line 560, but no explicit reference was found in the text == 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) ** Obsolete normative reference: RFC 2401 (ref. 'SECARCH') (Obsoleted by RFC 4301) -- Possible downref: Normative reference to a draft: ref. 'HCOIP' ** Obsolete normative reference: RFC 2509 (ref. 'PPPHC') (Obsoleted by RFC 3544) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Vilhuber 2 INTERNET DRAFT Cisco Systems Inc. 3 Expire in December, 2004 January, 2003 5 IP header compression in IPsec ESP 6 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Distribution of this memo is unlimited. 31 Abstract 33 This draft outlines how to use IP Header compression over IP tunnels 34 [HCOIP] inside IPsec ESP [ESP]. 36 1. Introduction 38 [HCOIP] defines a new IP protocol number (and IPv6 Next Header) value 39 for IP Header Compressed payloads for use in tunneling protocols over 40 IP. This draft outlines exactly how to encapsulate IP Header 41 Compressed packets into an ESP packet. 43 In this document, the key words "MAY", "MUST", "optional", 44 "recommended", "required", "SHOULD", and "SHOULD NOT", are to be 45 interpreted as described in [RFC2119]. 47 2. IP header compressed packets in ESP 49 [HCOIP] defines a number-space for the "Header Compression Payload 50 Type" as well as a new IP protocol number, which can be used to 51 indicate that a packet inside ESP has been previously header 52 compressed. 54 Note that not all packets that fall under a certain ESP SA may be 55 header compressed. Whether a packet is header compressed or not 56 depends on whether the compressor has an empty slot for a flow, and 57 whether the packet is deemed compressible by the compressor. Hence, 58 we can not simply assume that all packets under an ESP SA with header 59 compression will be compressed. We need an explicit indication, hence 60 the need for the new IP protocol number in [HCOIP]. 62 2.1. Order of processing of outbound packets 64 On outbound processing, the relevant SA bundle is found in whatever 65 manner the implementation uses. The SA bundle MUST indicate that 66 header compression needs to be attempted for this packet. The SA 67 should contain enough information to retrieve the relevant 68 compression context for this flow. 70 Header compression MUST be done before any other ESP or IPCOMP 71 processing. Any fragmentation decisions MUST be made on the result of 72 the header-compressed packet, rather than on the original (un-header- 73 compressed packet). 75 Original (pre-IPsec packet): 77 +-------------+ 78 | IP | Data | 79 +-------------+ 81 Header Compression is done, which removes the IP (and possibly other) 82 headers, replacing it with the appropriate compression context as 83 defined by [IPHC], [CRTP], and/or [ECRTP]: 85 +----------------------------+ 86 | Comp ID and context | Data | 87 +----------------------------+ 89 [HCOIP] header is prepended: 91 +---------------------------------+ 92 | Comp Type | Comp context | Data | 93 +---------------------------------+ 95 [ESP] is performed (including fragmentation decisions and possibly 96 [IPCOMP]) as usual, with next header set to IPHC: 98 +---------------------------------------------------------------------+ 99 | IP | ESP-SPI | SEQ | IV | Comp Type | Comp context | Data | Trailer | 100 +---------------------------------------------------------------------+ 102 An example of an ESP packet carrying a header compressed packet is as 103 follows: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Security Parameters Index (SPI) | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Sequence Number | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 112 | IV (depends on the cipher used; variable) | ^ ESP 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload 114 | Comp Type | Header Compressed Data (variable) | | Data 115 +-+-+-+-+-+-+-+-+ + | 116 ~ ~ | 117 | | | 118 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 119 | | Padding (0-255 bytes) | v 120 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 121 | | Pad Length | IPHC Proto | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Authentication Data (variable) | 124 ~ ~ 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Depending on the cipher used, the start of the ESP Payload data is 129 used as the IV. The length (and presence or absence) of the IV is 130 implicit knowledge, known to both sides. 132 "Comp Type" is the [HCOIP] header, and will be the first byte of the 133 plaintext payload. The rest of the Payload Data is the compressed 134 packet, the format of which conforms to the relevant RFC that covers 135 the type indicated in Comp Type (see [HCOIP] table 1). 137 2.2. Order of processing of inbound packets 139 On receiving an IPsec packet, the regular SA-lookup is used to 140 determine the SA bundle needed for decryption (decapsulation and 141 decompression). The SA bundle should carry enough information to 142 retrieve the decompression context. 144 If the receiver gets a packet with IP protocol IPHC, but the SA 145 bundle does not indicate that compression has been negotiated for 146 this SA, the packet MUST be dropped. 148 Since Header compression is the first thing done during 149 encryption/encapsulation, decompression is the last thing done. After 150 decapsulation and decryption (and maybe IPCOMP decompression), if the 151 resulting packet has a protocol type of IPHC, then the [HCOIP] header 152 is removed, and the packet along with the [HCOIP] type (from the 153 header), along with the decompression context stored with the IPsec 154 SA, MUST be handed to the decompressor. 156 After decompression, the decompressed packet MUST be checked against 157 the SADB as normal, and dropped, if the packet does not match the 158 SADB. 160 2.3. Decompressor Error handling 162 In the event that the decompressor has no appropriate compression 163 slot (as identified by the compression ID; see [IPHC]) for the packet 164 handed to it, the packet MUST be dropped. There is no error 165 indication that can be communicated to the peer. 167 In the event that the decompressor is out of sync with the compressor 168 (i.e. a decompression context for this Compression ID exists, but 169 packet loss has occurred), the decompressor may need to communicate a 170 CONTEXT_STATE packet back to the compressor. This packet MUST be sent 171 back through the IPsec Tunnel, i.e. must be encrypted and 172 encapsulated using the correct SA, i.e. the SA we would use to send 173 ESP packets to the peer. The out-of-sync packet MUST be dropped. 175 Should the Compressor receive a CONTEXT_STATE packet that has not 176 been authenticated via IPsec, then, as per [SECARCH], the packet MUST 177 be dropped and ignored. 179 On receipt of a valid CONTEXT_STATE packet, the receiver, who was the 180 sender of the packet that failed to decompress, will invalidate any 181 contexts listed in the CONTEXT_STATE packet, as per [RFC2507] (and 182 various addenda in [RFC2508] and [ECRTP]). 184 3. Security Considerations 186 3.1. Removing plain-text 188 Omitting the IP (as well as TCP or UDP/RTP) header removes a large 189 amount of known (or guess-able) plaintext from the to-be-encrypted 190 payload. While this can benefit security it still should not be 191 relied upon as a replacement for a strong cryptographic mechanism. 193 3.2. Active Attack Analysis 195 There is some concern about what an attacker can or can not do to the 196 decompressor, even when protected with ESP. We assume that an 197 attacker can not modify packets, because of ESP protection. For this 198 reason, it is recommended that ESP not be run without authentication, 199 even when esp-null is used. 201 Whether an attacker can look at the packets (i.e. a passive attacker) 202 has no immediate relevance to header compression. 204 An active attacker can drop packets, or insert fake ones. Fake ones 205 will be discarded by IPsec, but dropped packets can have an influence 206 on the decompressor as outlined in the following sections. 208 3.2.1 COMPRESSED_TCP, COMPRESSED_UDP, and COMPRESSED_RTP packets 210 DELTA fields depend on the number of packets we receive and send, 211 i.e. DELTA fields depend on the value of sent in the preceding 212 FULL_HEADER packet, and we increment the field value by a fixed, 213 known delta for each packet received. There are well-defined 214 algorithms that try to help detect dropped packets and correct in 215 those situations. However, to be conservative, we should assume that 216 dropped packets MAY influence DELTA fields (however, see below). 218 Likewise, any INFERRED fields that depend on DELTA fields could be 219 decompressed wrong (but most INFERRED fields do not, in fact, depend 220 on DELTA fields). 222 An attacker can NOT influence any NOCHANGE fields, as those are 223 explicitely copied from the compression context set up (and 224 refreshed) via FULL_HEADER packets, which can not be tampered with. 225 Examples of NOCHANGE fields are IP addresses (src and dst), protocol, 226 and src and dst ports. RANDOM fields are carried explicitely in the 227 compressed packet and thus can not be tampered with, either. Examples 228 of RANDOM fields are checksums. 230 An attacker can also not change any of the data in the packet by 231 selectively dropping packets, as the header compression mechanisms do 232 not affect the data. 234 So the best an attacker could do is influence DELTA fields, which are 235 generally sequence numbers, by selectively and intelligently dropping 236 packets. If the higher level protocol uses checksums (as TCP does, 237 and, mostly, UDP as well), then mis-decompression due to dropped 238 packets will be detected by the recipient of the mis-decompressed 239 packet. 241 For TCP packets, it is presumed that the end-host will detect and 242 discard any "off-by-k" sequence numbers via the TCP checksum. Neither 243 TCP nor UDP checksums cover anything in the IP header other than the 244 pseudo-header, which doesn't cover parts of the IPv4 header, nor 245 large parts of the IPv6 headers. 247 [CRTP] contains a 4 bit sequence number, to detect dropped packets 248 within a 16 packet window. 250 As long as the affected DELTA fields are covered by a higher level 251 checksum (i.e. UDP or TCP checksum), then attacking the data-stream 252 by selectively dropping some packets amounts to a denial of service 253 attack, which the attacker could perpetrate anyway, if he can drop 254 packets at will. 256 If the DELTA fields are not covered by a higher level i.e. UDP or 257 TCP) checksum, then these fields could be wrong after decompression 258 and the recipient may not notice. A new kind of HDRCKSUM similar to 259 the one defined in [ECRTP] should be devised to counteract this. 261 3.2.2 COMPRESSED_NON_TCP and COMPRESSED_TCP_NODELTA 263 As per [RFC2507], COMPRESSED_NON_TCP packets do not use differential 264 coding, and all fields are assumed to be NOCHANGE. If a NOCHANGE 265 field changes, a FULL_HEADER packet is sent, instead. Thus dropping 266 packets in this case has no effect on the values of the decompressed 267 packets. 269 COMPRESSED_TCP_NODELTA "is only sent in response to a header request 270 from the decompressor" [RFC2507]. Since there are no DELTA fields in 271 this packet type, dropping this packet (which, in any case is not 272 sent during normal operation) has no effect (except causing more 273 drops, i.e. more denial of service). 275 3.2.3 Future compressed headers 277 This analysis covers only known header-compression types known at the 278 time of this writing (see section 6. References). Any future new 279 compressed types of additional compressed headers should consider the 280 impact separately, following a similar analysis as in the previous 281 sections. 283 NOCHANGE and RANDOM fields can be safely ignored. They are safe. 284 INFERRED fields are safe as long as they do not depend on DELTA 285 fields. DELTA fields need to be considered on a case by case basis, 286 and should be covered by some checksum. 288 Checksums should never be optional. Alternatively, a scheme like 289 [ECRTP]'s HDRCKSUM should be used (see 3.2.3 as well). 291 3.2.3 Future work 293 As eluded to earlier, a simple way to fix this entire dilemma of 294 DELTA headers and decompression, is to define a checksum similar to 295 [ECRTP] HDRCKSUM, which covers the entire header that was compressed, 296 but none of the data, define the TCP and UDP checksums as INFERRED, 297 and carry ONLY the HDRCKSUM in the compressed packet. Since ESP 298 packets, when used with authentication, already verify that the data 299 hasn't been tampered with, we can re-calculate the TCP and UDP 300 checksums during decompression, as long as we have a way to verify 301 that the decompressed headers are exactly the same as they were prior 302 to compression. The HDRCKSUM gives us this assurance, and thus the 303 mechanism is secure. 305 The cost is extra processing at the decompressor (who needs to 306 calculate TCP or UDP checksums, which include the data of the 307 packet). 309 4. IANA Considerations 311 There are no IANA Considerations. 313 5. Acknowledgments 315 This document is derived in part from discussions with Cheryl Madson, 316 David McGrew, Mark Gillott, Patrick Ruddy, and Dan Wing. 318 6. References 320 [IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header 321 Compression for IP", RFC 2507, February 1999. 323 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 324 Headers for Low-Speed Serial Links", RFC 2508, February 325 1999. 327 [ECRTP] Koren, Casner, Geevarghese, Thompson, Ruddy, "Compressing 328 IP/UDP/RTP headers on links with high delay, packet loss 329 and reordering", draft-ietf-avt-crtp-enhance-04.txt, work in 330 progress, February 2002 332 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 333 Payload", RFC 2406, November 1998 335 [SECARCH] Kent, S., Atkinson, R., "Security Architecture for the Internet 336 Protocol", RFC 2401, November 1998 338 [HCOIP] Vilhuber, "IP header compression in IP tunneling protocols", 339 draft-vilhuber-hcoip-00.txt, work in progress, July, 2004 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 342 Levels", RFC 2119, March 1997 344 [IPCOMP] Shacham, Monsour, Pereira, Thomas, "IP Payload Compression 345 Protocol (IPComp)", RFC 3173, September 2001 347 7. Editor's Address 349 Jan Vilhuber 350 351 Cisco Systems, Inc. 353 Network Working Group J. Vilhuber 355 Expire in December, 2004 July, 2004 357 IP header compression in IP tunneling protocols 358 360 Status of this Memo 362 This document is an Internet-Draft and is subject to all provisions 363 of Section 10 of RFC2026. 365 Internet-Drafts are working documents of the Internet Engineering 366 Task Force (IETF), its areas, and its working groups. Note that 367 other groups may also distribute working documents as Internet- 368 Drafts. 370 Internet-Drafts are draft documents valid for a maximum of six months 371 and may be updated, replaced, or obsoleted by other documents at any 372 time. It is inappropriate to use Internet- Drafts as reference 373 material or to cite them other than as "work in progress." 375 The list of current Internet-Drafts can be accessed at 376 http://www.ietf.org/1id-abstracts.html 378 The list of Internet-Draft Shadow Directories can be accessed at 379 http://www.ietf.org/shadow.html 381 Distribution of this memo is unlimited. 383 Abstract 385 Bandwidth consumption of RTP flows can be reduced by tunneling and 386 compressing headers. This draft defines an IP protocol number and a 387 header which can be used to transport IP Header Compressed [IPHC], 388 Compressed RTP [CRTP], and Enhanced Compressed RTP [ECRTP] packets 389 over an arbitrary IP tunnel (IP-in-IP or ESP, for example) to reduce 390 bandwidth consumption for RTP flows. 392 1. Introduction 394 IP header compression [IPHC] and RTP compression [CRTP] can be used 395 to reduce bandwidth consumption, but are only defined for single hops 396 over connections with little to no loss and no packet reordering. 398 [ECRTP] extends the definition of IP header compression to be used 399 over lossy links with the possibility of packet reordering. I.e. 400 ECRTP can be used in protocols that run over the Internet at large. 402 In general, it turns out to be useful to carry IP Header Compressed 403 packets over an IP tunnel (IP-in-IP or IPSec tunnel mode, for 404 example), either because the combination (tunnel+HC) is smaller than 405 the original packet, or because the traffic is already flowing over 406 an existing tunnel, which we could take advantage of. 408 This draft recommends that ECRTP is used in the majority of these 409 cases, as it is expected that the underlying network does not meet 410 the criteria for reliable use of IPHC or CRTP. However, this draft 411 does not exclude IPHC and CRTP, as there may be situations where the 412 underlying network is well-known to be robust against loss and 413 reordering. 415 In this document, the key words "MAY", "MUST", "optional", 416 "recommended", "required", "SHOULD", and "SHOULD NOT", are to be 417 interpreted as described in [RFC2119]. 419 2. IP header compression packet format 421 [IPHC], [CRTP], and [ECRTP] only define the compression mechanisms 422 and compressed packet formats, but leave defining the transport of 423 this compressed packet to the underlying transport mechanism. 425 In this vein, [PPPHC] extends the PPP Data Link Layer Protocol Field 426 values to include the needed Compression Payload Types. For exactly 427 the same reason, we need to define the Compression Payload Types used 428 when carrying a header-compressed packet over an IP tunnel in this 429 draft. 431 The types of Compression Payloads are scattered over [IPHC], [CRTP], 432 and [ECRTP]. The following table names the Compression Payload Type, 433 gives each a number, and specifies which document to look at for the 434 exact definition of the Compression Type. 436 Header Compression Payload Type Value Defined in 437 ------------------------------------------------------------------ 438 IPHC_FULL_HEADER 0 IPHC/CRTP 439 IPHC_COMPRESSED_NON_TCP 1 IPHC/CRTP 440 IPHC_COMPRESSED_TCP 2 IPHC 441 IPHC_COMPRESSED_TCP_NODELTA 3 IPHC 442 IPHC_CONTEXT_STATE 4 IPHC/ECRTP 443 IPHC_COMPRESSED_UDP_8 5 CRTP/ECRTP 444 IPHC_COMPRESSED_UDP_16 6 CRTP/ECRTP 445 IPHC_COMPRESSED_RTP_8 7 CRTP/ECRTP 446 IPHC_COMPRESSED_RTP_16 8 CRTP/ECRTP 447 Reserved by IANA 9-255 449 Table 1: Header Compression Payload Types 451 2.1. IP header compression packet format in IPv4 453 When carried over IPv4, IP header compressed packets will have the 454 following header prepended: 456 0 1 2 3 4 5 6 7 457 +-+-+-+-+-+-+-+-+ 458 ! Comp Type ! 459 +-+-+-+-+-+-+-+-+ 461 Figure 1: IPv4 IP Header Compression Header 463 "Comp Type" is a 1 byte field that carries the "Header Compression 464 Payload Type" value (as defined in Table 1), that indicates the type 465 of compressed payload that follows the header. 467 Anything following the 1 byte Comp Payload type field is Compression 468 context and data, in accordance with the respective type, as defined 469 in the respective documents (see Table 1). 471 The IPv4 Protocol Number for IP Header compressed packets as defined 472 in this draft shall be XXX [TBD IANA]. 474 2.2. IP header compression packet format in IPv6 476 When carried inside IPv6, an IP header compressed packet will be have 477 the IP Header Compression Header prepended. 479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 ! Next Header | Comp Type ! 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 2: IPv6 IP Header Compression Header 486 The Next Header field is a regular IPv6 Next Header field. 488 "Comp Type" is a 1 byte field that carries the "Header Compression 489 Payload Type" value (as defined in Table 1), that indicates the type 490 of compressed payload that follows the header. 492 Anything following the 1 byte Comp Payload type field is Compression 493 context and data, in accordance with the respective type, as defined 494 in the respective documents (see Table 1). 496 The IPv6 Next Header value for IP header compressed packets as 497 defined in this draft shall be XXX [TBD IANA] 499 3. Security Considerations 501 This draft does not change the security of any protocol, as it merely 502 provides a mechanism to carry header-compressed packets within 503 another IP protocol. 505 That being said, this draft allows us to carry IP header compressed 506 packets inside IPsec ESP, which provides a way to carry header- 507 compressed packets over the Internet in a secure way. 509 When encryption is used, as in IPsec ESP tunnels, omitting the IP (as 510 well as TCP or UDP/RTP) header removes a large amount of known (or 511 guessable) plaintext from the to-be-encrypted payload. While this can 512 benefit security it still should not be relied upon as a replacement 513 for a strong cryptographic mechanism. 515 4. IANA Considerations 517 IANA is requested to create a new assignment registry for "Header 518 Compression Payload Type Values", initially allowing values in the 519 range 0 to 255 decimal. 521 Assignment of values in this field require: 522 - the identity of the assignee 523 - a brief description of the new Header Compression Payload type 524 - a reference to a stable document describing the Header 525 Compression Payload in detail. 527 During the first year of existence of this registry, IANA is 528 requested to refer all requests to the IETF WG for review. 529 Subsequently, requests should be reviewed by the IETF Area 530 Directors or by an expert that they designate. 532 If the number of assignments begins to approach 255, the Area 533 Directors should be alerted. 535 5. Acknowledgments 537 This document is derived in part from discussions with Cheryl Madson, 538 Mark Gillott, Patrick Ruddy, and Dan Wing. 540 6. References 542 [IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header 543 Compression for IP", RFC 2507, February 1999. 545 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 546 Headers for Low-Speed Serial Links", RFC 2508, February 547 1999. 549 [PPPHC] Engan, Casner, Bormann, "IP Header Compression over PPP", 550 RFC 2509, February 1999 552 [ECRTP] Koren, Casner, Geevarghese, Thompson, Ruddy, "Compressing 553 IP/UDP/RTP headers on links with high delay, packet loss 554 and reordering", draft-ietf-avt-crtp-enhance-04.txt, work in 555 progress, February 2002 557 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 558 Payload", RFC 2406, November 1998 560 [IPIP] Perkins, "IP Encapsulation within IP", RFC 2003, October 1996 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 563 Levels", RFC 2119, March 1997 565 7. Editor's Address 567 Jan Vilhuber 568 569 Cisco Systems, Inc.