Network Working Group J. Vilhuber INTERNET DRAFT Cisco Systems Inc. Expire in July, 2003 January, 2003 IP header compression in IP tunneling protocols Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Abstract Bandwidth consumption of RTP flows can be reduced by tunneling and compressing headers. This draft defines an IP protocol number and a header which can be used to transport IP Header Compressed [IPHC], Compressed RTP [CRTP], and Enhanced Compressed RTP [ECRTP] packets over an arbitrary IP tunnel (IP-in-IP or ESP, for example) to reduce bandwidth consumption for RTP flows. Vilhuber [Page 1] INTERNET DRAFT January, 2003 Expires July, 2003 1. Introduction IP header compression [IPHC] and RTP compression [CRTP] can be used to reduce bandwidth consumption, but are only defined for single hops over connections with little to no loss and no packet reordering. [ECRTP] extends the definition of IP header compression to be used over lossy links with the possibility of packet reordering. I.e. ECRTP can be used in protocols that run over the Internet at large. In general, it turns out to be useful to carry IP Header Compressed packets over an IP tunnel (IP-in-IP or IPSec tunnel mode, for example), either because the combination (tunnel+HC) is smaller than the original packet, or because the traffic is already flowing over an existing tunnel, which we could take advantage of. This draft recommends that ECRTP is used in the majority of these cases, as it is expected that the underlying network does not meet the criteria for reliable use of IPHC or CRTP. However, this draft does not exclude IPHC and CRTP, as there may be situations where the underlying network is well-known to be robust against loss and reordering. In this document, the key words "MAY", "MUST", "optional", "recommended", "required", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 2. IP header compression packet format [IPHC], [CRTP], and [ECRTP] only define the compression mechanisms and compressed packet formats, but leave defining the transport of this compressed packet to the underlying transport mechanism. In this vein, [PPPHC] extends the PPP Data Link Layer Protocol Field values to include the needed Compression Payload Types. For exactly the same reason, we need to define the Compression Payload Types used when carrying a header-compressed packet over an IP tunnel in this draft. The types of Compression Payloads are scattered over [IPHC], [CRTP], and [ECRTP]. The following table names the Compression Payload Type, gives each a number, and specifies which document to look at for the exact definition of the Compression Type. Header Compression Payload Type Value Defined in ------------------------------------------------------------------ IPHC_FULL_HEADER 0 IPHC/CRTP IPHC_COMPRESSED_NON_TCP 1 IPHC/CRTP IPHC_COMPRESSED_TCP 2 IPHC IPHC_COMPRESSED_TCP_NODELTA 3 IPHC IPHC_CONTEXT_STATE 4 IPHC/ECRTP IPHC_COMPRESSED_UDP_8 5 CRTP/ECRTP IPHC_COMPRESSED_UDP_16 6 CRTP/ECRTP IPHC_COMPRESSED_RTP_8 7 CRTP/ECRTP Vilhuber [Page 2] INTERNET DRAFT January, 2003 Expires July, 2003 IPHC_COMPRESSED_RTP_16 8 CRTP/ECRTP Reserved by IANA 9-255 Table 1: Header Compression Payload Types 2.1. IP header compression packet format in IPv4 When carried over IPv4, IP header compressed packets will have the following header prepended: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ ! Comp Type ! +-+-+-+-+-+-+-+-+ Figure 1: IPv4 IP Header Compression Header "Comp Type" is a 1 byte field that carries the "Header Compression Payload Type" value (as defined in Table 1), that indicates the type of compressed payload that follows the header. Anything following the 1 byte Comp Payload type field is Compression context and data, in accordance with the respective type, as defined in the respective documents (see Table 1). The IPv4 Protocol Number for IP Header compressed packets as defined in this draft shall be XXX [TBD IANA]. 2.2. IP header compression packet format in IPv6 When carried inside IPv6, an IP header compressed packet will be have the IP Header Compression Header prepended. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Header | Comp Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 IP Header Compression Header The Next Header field is a regular IPv6 Next Header field. "Comp Type" is a 1 byte field that carries the "Header Compression Payload Type" value (as defined in Table 1), that indicates the type of compressed payload that follows the header. Anything following the 1 byte Comp Payload type field is Compression context and data, in accordance with the respective type, as defined in the respective documents (see Table 1). The IPv6 Next Header value for IP header compressed packets as Vilhuber [Page 3] INTERNET DRAFT January, 2003 Expires July, 2003 defined in this draft shall be XXX [TBD IANA] 3. Security Considerations This draft does not change the security of any protocol, as it merely provides a mechanism to carry header-compressed packets within another IP protocol. That being said, this draft allows us to carry IP header compressed packets inside IPsec ESP, which provides a way to carry header- compressed packets over the Internet in a secure way. When encryption is used, as in IPsec ESP tunnels, omitting the IP (as well as TCP or UDP/RTP) header removes a large amount of known (or guessable) plaintext from the to-be-encrypted payload. While this can benefit security it still should not be relied upon as a replacement for a strong cryptographic mechanism. 4. IANA Considerations IANA is requested to create a new assignment registry for "Header Compression Payload Type Values", initially allowing values in the range 0 to 255 decimal. Assignment of values in this field require: - the identity of the assignee - a brief description of the new Header Compression Payload type - a reference to a stable document describing the Header Compression Payload in detail. During the first year of existence of this registry, IANA is requested to refer all requests to the IETF WG for review. Subsequently, requests should be reviewed by the IETF Area Directors or by an expert that they designate. If the number of assignments begins to approach 255, the Area Directors should be alerted. 5. Acknowledgments This document is derived in part from discussions with Cheryl Madson, Mark Gillott, Patrick Ruddy, and Dan Wing. 6. References [IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999. [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [PPPHC] Engan, Casner, Bormann, "IP Header Compression over PPP", RFC 2509, February 1999 Vilhuber [Page 4] INTERNET DRAFT January, 2003 Expires July, 2003 [ECRTP] Koren, Casner, Geevarghese, Thompson, Ruddy, "Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering", draft-ietf-avt-crtp-enhance-04.txt, work in progress, February 2002 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload", RFC 2406, November 1998 [IPIP] Perkins, "IP Encapsulation within IP", RFC 2003, October 1996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 7. Editor's Address Jan Vilhuber Cisco Systems, Inc. Vilhuber [Page 5]