One document matched: draft-vilhuber-hcoip-00.txt

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]