Network Working Group Wang Hui INTERNET-DRAFT Li Jinsheng Expires: May 29 2003 Hong Peiling Infonet Lab,USTC Nov. 29, 2002 RObust Header Compression (ROHC): A Compression Profile for Mobile IPv6 Status of this memo This document is an Internet-Draft and is in full conformance with 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to the ROHC WG mailing list, rohc@ietf.org. Abstract The original RObust Header Compression (ROHC) RFC, RFC 3095, defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed packet streams. And another draft [IPPROFILE] posted by Jonsson deals with the IP only profile. However, no profile was defined for compression of IP extension headers. But in the coming wireless applications, mobile IP will play an important role. In mobile IPv4, there is no difference to the packet's IP header, so we don't have to make a profile for mobile IPv4; while as to mobile IPv6[MIPV6], there is difference, since some specific IPv6 extension headers will be included in almost every packet in the mobile IPv6 packets. The extension headers will also cost a lot of bandwidth, and we should do compression over them. This document addresses this issue and defines a ROHC compression profile for mobile IPv6, which may work as a complementarity to the profiles defined by RFC3095. Wang [Page 1] INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002 Table of Contents 1. Introduction..................................................2 2. Terminology...................................................2 3. Changes to packets sent and received within a MN..............3 4. ROHC MIPv6 Compression (Profile 0x????).......................4 4.1 The HAO structure and its compression.....................4 4.2 The type 2 routing header structure and its compression...5 4.3 Initialization............................................5 4.4 Other considerations......................................5 5. Security Considerations.......................................6 6. IANA Considerations...........................................6 7. References....................................................6 8. Author's Address..............................................6 1. Introduction The original RObust Header Compression (ROHC) RFC [RFC3095] defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also for uncompressed packet streams. The ROHC framework is designed to apply to wireless environment, while in the experiment of deploying the wireless IP network, we found mobile IP will play a more and more important role. Mobile IP will bring some changes to the IP header. There is a need for a ROHC profile to deal with these changes. In mobile IPv4 [MIPv4], there is no difference to the packet's IP header, so we don't have to make a profile for mobile IPv4; while as to mobile IPv6[MIPV6], there is difference, for some specific IPv6 extension headers will be included in almost every packet in the mobile IPv6 packets. These extension headers will also cost a lot of bandwidth, and we should do compression over them. In my experience of implementing mobile IPv6, I made a integration with the ROHC to enhance the performance. In the integration, I defined a special 'profile' to deal with the mobile IPv6 extension headers. And in this document, I will introduce this special profile, and I hope it would be included into the main ROHC profile tree after some revisions. This document addresses this issue and defines a ROHC compression profile for mobile IPv6, which may work as a complementarity to the profiles defined by RFC3095. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. The mobile IPv6 related terms are the same as defined in section 3.2 in [MIPv6]. Please refer to it. Wang [Page 2] INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002 3. Changes to packets sent and received within a MN [MIPv6] has introduced some new IPv6 protocol, message Types, and destination option. The detailed description of these changes can be found in section 6 in [MIPv6]. Here we have a brief review of these changes. When the mobile node (MN) is in its home network, there is no difference and the MN acts as normal Internet node. For packets sent by a mobile node while it is at home, no special Mobile IPv6 processing is required. While a mobile node is away from home, it continues to use its home address, as well as also using one or more care-of addresses. For packets sent by the mobile node sent while away from home using the mobile node's home address as the source, special Mobile IPv6 processing of the packet is required. Usually the MN will directly delivery the packets to its CN. In this case, the MN SHOULD arrange to supply the home address in a Home Address option, and allowing the IPv6 header's Source Address field to be set to one of the mobile node's care-of addresses; the correspondent node will then use the address supplied in the Home Address option to serve the function traditionally done by the Source IP address in the IPv6 header. The mobile node's home address is then supplied to higher protocol layer and applications. The Home Address Option(HAO) is carried in the Destination Header. Usually the CN will has a Binding Cache entry for the MN and so packets sent by a correspondent node to the MN will be sent by the correspondent node using a type 2 routing header. The packet will be addressed to mobile node's care-of address, with the final hop in the routing header directing the packet to the mobile node's home address; the processing of this last hop of the routing header is entirely internal to the mobile node, since the care-of address and home address are both addresses within the mobile node. Detailed operations on the packets in the above mobile IPv6 node can be found in [MIPv6]. See from the above discussions, we could tell that when the MN is away from its home network and plugs to the foreign network access router, the packets sent and received by the MN will be modified by the MIPv6 layer, according to [MIPv6], as to gain the mobility. Here are a brief summarization : While MN is away from home network, commonly o packets sent from a MN will be modified to include a 'Home Address Option'(HAO for short) in the Destination Header. o packets received by a MN sent from the CN will contain a type 2 routing header. Wang [Page 3] INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002 Except the above tow kinds of packets, there are other packets including the mobility header. The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. But as to the header compression considerations, these messages act as signaling message and are only sent in a very low frequency so we do not need to compress them. So in the ROHC MIPv6 profile we only compress the HAO and the type 2 routing header. 4. ROHC MIPv6 Compression (Profile 0x????) From the above analysis, we can see what the ROHC profile would deal with are the destination header(HAO) and the type 2 routing header. And the other headers, such as IPv6 basic header, UDP header and RTP header etc. , will be treated the same as the normal IPv6 packets. So what we should do is to define a special profile to cope with the destination header and the type 2 routing header and this special profile would work as a supplement to the profiles defined in RFC3095. For example, the 'IPv6/MIPv6/UDP/RTP' will be considered as 'IPv6/UDP/RTP' profile(defined in RFC3095) plus 'MIPv6' profile. The profile ID is TBD . 4.1 The HAO structure and its compression The Home Address option is carried by the Destination Option extension header (Next Header value = 60). It is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node's home address. The Home Address option is encoded in type-length-value (TLV) format as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Ext Len | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'Next Header', 8-bit selector, identifies the type of header immediately following the routing header, which uses the same values as the IPv6 Next Header field [IPv6]. 'Header Ext Len' is the length of this Destination Header. 'Option Type' would be '0xC9', and 'Option Length' MUST be set to 16 [MIPv6]. So the four fields are Wang [Page 4] INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002 all static within a stream packets. The 'Home Address' indicates the MN's home address, which in a specific UDP or TCP stream is static too. So the whole HAO header of one stream would all be static context. We can compress this header to be 0-bit. 4.2 The type 2 routing header structure and its compression Mobile IPv6 defines a new routing header variant, the type 2 routing header, to allow the packet to be routed directly from a correspondent to the mobile node's care-of address. This routing header type (type 2) is restricted to carry only one IPv6 address, which is the MN's home address. The type 2 routing header has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'Next Header', 8-bit selector, identifies the type of header immediately following the routing header, which uses the same values as the IPv6 Next Header field [IPv6]. For a type 2 routing header, the values of the 'Hdr Ext Len','Routing Type',and 'Segments Left' are all fixed value as described in the figure. So the whole type 2 routing header of one stream would all be static context. We can compress this header to be 0-bit. 4.3 Initialization The static context for ROHC MIPv6 compression can be initialized by adding the mobile IPv6 static field to the static chain in the existing IR packet of ROHC UDP/RTP profile, where the profile id should be modified to be 0x????(TBD). In other word, the MIPv6 profile static field should be inserted into the static chain of original static chain of ROHC IP/UDP/RTP profile. The other parts, except the MIPv6 fields, should be treated as standard IP/UDP/RTP profile as defined in RFC3095. 4.4 Other considerations Since the signaling message will be sent a very low frequency, we don't need to compress the Mobility Header. We only transfer it directly. Wang [Page 5] INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002 5. Security Considerations The security considerations of [RFC3095] apply equally to this document, without exceptions or additions. 6. IANA Considerations ROHC MIPv6 profile identifier 0x???? has been reserved by the IANA for the profile defined in this document. [TO BE REMOVED BEFORE PUBLICATION] A ROHC profile identifier must be reserved by the IANA for the profile defined in this document. Profile number 0x???? has previously been saved for this purpose, and should thus be used. As for previous ROHC profiles, profile numbers 0xnnXX must also be reserved for future updates of this profile. A suggested registration in the "RObust Header Compression (ROHC) Profile Identifiers" name space would then be: 0x???? ROHC MIPv6 [RFCXXXX (this)] 0xnn?? Reserved [END] 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3095] Bormann, 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., Yoshimura, T. and H. Zheng, "Robust Header Compression (ROHC)", RFC 3095, July 2001. [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [MIPv6] David B. Johnson, Charles E. Perkins and Jari Arkko, "Mobility Support in IPv6", IETF draft: draft-ietf-mobileip-ipv6-19.txt,Oct 2002,working in progress [IPPROFILE] L-E. Jonsson,"RObust Header Compression (ROHC):A Compression Profile for IP",IETF draft: draft-ietf-rohc- ip-only-00.txt, Oct. 2002, working in progress 8. Author's Address Wang Hui Tel: +86 551 360 7041 Infonet Lab,EEIS Fax: +86 551 360 1334 University of Sci. & Tech. of China P.O.Box 4 Hefei,Anhui http://mail.ustc.edu.cn/~whui China,230027 EMail: whui@mail.ustc.edu.cn Wang [Page 6] INTERNET-DRAFT A ROHC Compression Profile for MIPv6 Nov 29, 2002 9. Patents Infonet Lab USTC is in the process of filing one or more patent applications that may be relevant to this IETF draft. Wang [Page 7]