Network Working Group J. Vilhuber
INTERNET DRAFT Cisco Systems Inc.
Expire in July, 2003 January, 2003
IP header compression in IP tunneling protocols
<draft-vilhuber-hcoip-00.txt>
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 <TBD> WG for review.
Subsequently, requests should be reviewed by the IETF <TBD> Area
Directors or by an expert that they designate.
If the number of assignments begins to approach 255, the <TBD> 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
<vilhuber@cisco.com>
Cisco Systems, Inc.
Vilhuber [Page 5]