Network Working Group A. Minaburo Internet-Draft P. Rawat Expires: August 31, 2006 L. Toutain J-M. Bonnin GET/ENST Bretagne E. Paik KT February 27, 2006 IP Tunneling Header Compression draft-minaburo-hc-tunneling-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The IP tunneling mechanisms are widely used in mobility (NEMO and Mobile IP), security (VPN) and IP transition. They use an IP encapsualation (at least 2 IP headers), which is very expensive for wireliss links. Header compression mechanisms can be used to reduce Minaburo, et al. Expires August 31, 2006 [Page 1] Internet-Draft IP Tunneling Header Compression February 2006 this overhead, independent of the payload type. This document defines the use of normal header compression mechanisms for the tunneled (inner) header together with a new header compression mechanism for the tunneling (outer) transport header to reduce the header size. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Header Compression and Tunneling Compression Protocol . . . . 3 2.1. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Tunneling Compression Profiles . . . . . . . . . . . . . . 4 2.3. General Packet Format . . . . . . . . . . . . . . . . . . 5 2.4. Transfer Sequence Number . . . . . . . . . . . . . . . . . 6 2.5. Overview of the Dual Header Compression . . . . . . . . . 6 3. Tunneling Header Fields Pattern . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Minaburo, et al. Expires August 31, 2006 [Page 2] Internet-Draft IP Tunneling Header Compression February 2006 1. Introduction IP Tunneling [RFC 2003??] encapsulation has been used for many years by ISPs to offer VPNs with private addresses. Nowadays, IP in IP encapsulation is used to support mobility like in NEMO or Mobile IP, when mobile node or mobile router is not at their home networks. Another common use of IP tunneling is for migration to IPv6 and NAT traversal using UDP enscapuslation for IPv6 packets (e.g. using L2TP). IP tunneling adds overhead due to double headers used between the two peers and the wireless nature of the communication. This leads to bad performance in wireless links where bandwidth is scarce. Many header compression algorithms have been studied to reduce the header size, but they give a low performance against errors in wireless links. Also, they focus only on the inner IP encapuslation leaving the outer part of the encapsulation without any compression. This document defines a new header compression mechanism, tunneling compression protocol (TuCP) to compress the outer tunnel headers. And, explains the use of a header compression mechanism such as ROHC, ECRTP and CTCP to compress the ingress (inner) part of the tunneling encapsulation together with the tunneling compression protocol (TuCP). Also, a solution is provided for the problem that occurs due to the disordering of packets between two header compression endpoints. The normal header compression mechanisms do not support disordering of packets and have been defined to work in a point to point link where disordering does not takes place. 2. Header Compression and Tunneling Compression Protocol 2.1. Basics IP Tunneling is the encapsulation of a packet within another packet, both of which supporting the same or different protocols as shown in Figure 1. IP tunneling involves different components: the tunneled protocol which gives the inner encapuslation and the tunneling or transport protocol that reperesents the outer encapsulation. Minaburo, et al. Expires August 31, 2006 [Page 3] Internet-Draft IP Tunneling Header Compression February 2006 Outer Inner Encapsulation Encapsulation +---+---------------------+--------------------+----------+ | |Tunneling Header | Tunneled Header | | Without |IP |Any Tunnel Protocol | IP + Any upper | Payload | Compression | | | layer protocol | | +---+---------------------+--------------------+----------+ Figure 1: Tunneling and Tunneled Encapsualtion As, tunnels are bi-directional, header compression mechanisms will be able to perform at both ends of the tunnel and use feedbacks. The tunneling encapsulation consists of an IP header followed by a combination of tunnel protocols such as GRE, UDP, L2TP, and PPP. The first IP header MUST not be compressed, because it ensures the delivery of the packet to the other end of the tunnel. 2.2. Tunneling Compression Profiles Tunneling protocols add one or more additional headers to the tunneled header and are used to identify different tunnels. Tunneling can be applied at the same or at a different layer. In the tunneling encapsulation (outer IP encapsulation), IP protocol will be used together with one or more protocols or without any protocol. These protocols can be UDP (User Datagram Protocol), L2TP (Layer 2 Tunnel Protocol), and PPP (Point to Point Protocol) etc. Figure 2. shows the generic tunnel headers. For the header compression of outer packet, four tunneling compression profiles have been defined: Profile 0 no tunneling header Profile 1 UDP Profile 2 UDP/L2TP/PPP Profile 3 L2TP/PPP Use when UDP is used for NAT traversal. Minaburo, et al. Expires August 31, 2006 [Page 4] Internet-Draft IP Tunneling Header Compression February 2006 Outer Inner Encapuslation Encapsulation +---+---------------------+--------------------+----------+ | | Tunneling Header | Tunneled Header | | With |IP | TuCP | Header Compression | Payload | Compression | | | Mechanism | | +---+---------------------+--------------------+----------+ Figure 2: Generic Tunnel Headers 2.3. General Packet Format All the tunneling signalling (e.g. L2TP, Mobile IP) packets are not compressed and they are identified by two bits in the header format. Only user data packets will be compressed. Figure 3. shows the general compressed format packet. The first two bits are description type bits (D), which are used to identify the tunneling signalling from header compression (ROHC) negotiation packet and ROHC header compressed packets. TuCP (3 bits) bits are used to indetify the tunneling profile. Transfer Sequence Number is introduced to identify the disordering in the packet delivery. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :IP Header for egress tunneling : : encapsulation : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TuCP | Transfer Seq. Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Variable Length :TuCP hdr compression Hdr & : :Hdr Compression Mech. Hdr or : :Tunneling Signalling Hdr : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Payload : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: General Format Packet D: Description Type Bits 00 Reserved Minaburo, et al. Expires August 31, 2006 [Page 5] Internet-Draft IP Tunneling Header Compression February 2006 01 Tunneling Signalling Packets 10 Header Compression Mechanism Packets 11 Reserved 2.4. Transfer Sequence Number Header compression mechanisms are designed to work over an ordered delivery transmission between the compressor and decompressor. When sending compressed packets in the IP tunneling, many hops will be crossed in different ways and ordered delivery may not be guaranteed. This document gives a solution that does not reduce the performance of header compression mechanisms and at the same time delivers packets in order. This is done by introducing a transfer sequence number in the general format packet as shown in Figure 3. The Transfer Sequence Number will give the decompressor, the transmission order in which packets have been sent. When, there is a disordering in the delivery of packets, before making decompression of an early arriving packet, the decompressor has to wait until the ordered delivery packet arrives or a timer expires. When the timer expires, missing packets are assumed to be lost. The timer value is out of the scope of this draft, it will need to be studied depdending on the congestion in the network. 2.5. Overview of the Dual Header Compression TuCP classifies the tunneling header fields into static and dynamic fields. First, TuCP sends both static and dynamic fields and then compressor sends only the dynamic fields. Section 3. gives a general classification of fields of different tunneling protocols. TuCP profiles can be used together with any header compression mechanism to reduce the header size. If we use a normal header compression mechanism within the complete tunneling encapsulation, we will need to modify the header compression mechanism to take into account tunneling. Also, the first IP header of the outer packet is not compressed because it is used by routers to forward the packet to the tunnel end-point. The header compression can be done into two parts: the first part is the compression of the inner header packet with any header compression mechanism and the second part is the compression of the outer header packet with TuCP. This dual header compression can be used in NEMO networks and this solution can be extended for any tunneling encapsulation. Minaburo, et al. Expires August 31, 2006 [Page 6] Internet-Draft IP Tunneling Header Compression February 2006 3. Tunneling Header Fields Pattern This section gives a first approach for the pattern of the different fields of the tunneling protocols. All fields of different tunneling protocols can be classfied into static and dynamic fields. This section gives a general classification of fields of different tunneling protocols such as GRE, UDP, L2TP and PPP. +-------------------+--------------+ | Field | Pattern | +-------------------+--------------+ | C flag | Static | | Reserved flags | Static | | Version | Static | | Protocol Type | Static | | Checksum | Dynamic | | Reserved1 | Static | +-------------------+--------------+ Figure 4: GRE +-------------------+--------------+ | Field | Pattern | +-------------------+--------------+ | Source Port | Static | | Destination Port | Static | | Datagram Length | Inferred | | Checksum | Dynamic | +-------------------+--------------+ Figure 5: UDP Minaburo, et al. Expires August 31, 2006 [Page 7] Internet-Draft IP Tunneling Header Compression February 2006 +-------------------+---------+ | Field | Pattern | | | | +-------------------+---------+ | T flag | Static | | L flag | Static | | S flag | Static | | O flag | Static | | P flag | Static | | Version | Staitc | | Length | Static | | Tunnel ID | Static | | Session ID | Static | | Ns | Dynamic | | Nr | Dynamic | | Offset Size | Dynamic | | Offset Pad | Static | +-------------------+---------+ Figure 6: L2TP +----------------+------------+ | Field | Pattern | +----------------+------------+ | Address | Static | | Control | Static | | Protocol | Static | | FCS | Dynamic | +----------------+------------+ Figure 7: PPP 4. IANA Considerations This document defines a new IP protocol to identify tunneling compression, which is described in section 3. 5. Security Considerations This document by itself does not add any security risk to the use of header compression as they have already been defined in each mechanism. Minaburo, et al. Expires August 31, 2006 [Page 8] Internet-Draft IP Tunneling Header Compression February 2006 6. References 6.1. Normative References [BCP] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14", RFC 2119, March 1997. [CTCP] Casner, S., Jacobson, V., and B. Thompson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003. [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation", RFC 2784, March 2000. [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protcol", RFC 2661, August 1999. [PPP] Simpson, W., "The Point-to-Point Protcol", RFC 1661, July 1994. [RFC2131] Droms, R., ""Dynamic Host Configuration Protocol"", RFC 2131, March 1997. [RFC2136] Vixie, P., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Baisc Support Protocol", RFC 3963, January 2005. [ROHC] Bromann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., and H. Zheng, ""Robust Header Compression Minaburo, et al. Expires August 31, 2006 [Page 9] Internet-Draft IP Tunneling Header Compression February 2006 (ROHC): Framework and four profiles: RTP,UDP,ESP, and uncompressed"", RFC 3095, July 2001. [UDP] Postel, J., ""User Datagram Protcol"", RFC 768, August 1980. 6.2. Informative References [ENTANA] "IPv6 Enterprise Network Analysis", draft-ietf-v6ops-enst-analysis-03.txt (work in progress), July 2005. [RFC4057] "IPv6 Enterprise Netwrok Scenariosn", RFC 4057, June 2005. [TSP] Blanchet, M. and F. Parent, "Tunnel Setup Protocol", draft-blanchet-v6ops-tunnelbroker-tsp-03.tx (work in progress), March 2006. Minaburo, et al. Expires August 31, 2006 [Page 10] Internet-Draft IP Tunneling Header Compression February 2006 Authors' Addresses Ana Minaburo GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: anacarolina.minaburo@enst-bretagne.fr Priyanka Rawat GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Priyanka.Rawat@enst-bretagne.fr Laurent Toutain GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Laurent.Toutain@enst-bretagne.fr J-M Bonnin GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: jm.bonnin@enst-bretagne.fr Minaburo, et al. Expires August 31, 2006 [Page 11] Internet-Draft IP Tunneling Header Compression February 2006 Eun Kyoung Paik KT Portable Internet Team, Convergence Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Fax: +82 2 526 5200 Email: euna@kt.co.kr Minaburo, et al. Expires August 31, 2006 [Page 12] Internet-Draft IP Tunneling Header Compression February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Minaburo, et al. Expires August 31, 2006 [Page 13]