Network Working Group G. Daley Internet-Draft E. Wu Expires: September 2, 2005 A. Sekercioglu Monash University CTIE S. Narayanan Panasonic March 2005 Packet Tunneling for Route Optimization in MN-to-MN Communications draft-ewu-mip6-mn-mn-tunnel-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 September 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv6 provides mobility support for mobile devices moving around the Internet. It specifies that when a mobile host wishes for peers to communicate directly to its visited location, that the peer Daley, et al. Expires September 2, 2005 [Page 1] Internet-Draft MN-to-MN Packet Tunneling March 2005 send packets using a Routing Header, Type 2. Corresponding packets from the mobile use a Home Address option. When two moving devices communicate, they may wish to use a the most direct data path between their respective locations. Use of this direct data path incurs the cost of both Routing Header and Home Address Options, in each direction. This document provides a simple means of reducing this overhead. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Existing Mobile IPv6 Operations . . . . . . . . . . . . . 3 1.1.1 Using care-of address as source address . . . . . . . 3 1.1.2 Using care-of address as destination address . . . . . 3 1.2 Reducing per packet overhead using Tunnels . . . . . . . . 4 2. Changes to IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . 5 2.1 Binding Update Message . . . . . . . . . . . . . . . . . . 5 3. Sending data packets . . . . . . . . . . . . . . . . . . . . . 6 4. Receiving data packets . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Daley, et al. Expires September 2, 2005 [Page 2] Internet-Draft MN-to-MN Packet Tunneling March 2005 1. Introduction Overhead in wireless environments is a critical issue. Where there is per-packet overhead for mobile devices, various ways of reducing the cost of packet transmission should be used in order to make better utilization of constrained bandwidth resources. This document investigates a previously identified issue in Mobile IPv6 (see Section 5) and presents a way to negotiate service with lower per-packet overhead. Existing Mobile IPv6 operation and a case for reducing overhead are presented in Section 1.1. The target overhead and formats are specified in Section 1.2, and protocol changes and negotiation parameters are described in Section 2. 1.1 Existing Mobile IPv6 Operations Mobile IPv6 [1] specifies "route optimization" which enables packets from the correspondent node be routed directly to the care-of address of the mobile node. This requires signalling from the Mobile Node (MN) to its peer Correspondent Node (CN), to map the host's global identity (a Home Address) to its location (a Care-of Address). This information is stored in a Binding Cache on the correspondent node. The Mobile Node maintains a Binding update List to control for which correspondent nodes the route optimized communication is enabled. The mobile and correspondent nodes perform the following operations when sending packets to any IPv6 destination: 1.1.1 Using care-of address as source address The mobile node checks its binding update list for an entry for the packet's destination address. If then entry is found for this destination, the node replaces its home address in the packet's source address with its care-of address and adds a Home Address Option in the packet to include its home address. 1.1.2 Using care-of address as destination address The correspondent node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. The node also adds Type 2 Routing Header to the packet for carrying the mobile node's home address. Daley, et al. Expires September 2, 2005 [Page 3] Internet-Draft MN-to-MN Packet Tunneling March 2005 1.2 Reducing per packet overhead using Tunnels To achieve route optimization between two communicating nodes that are simultaneously moving, both nodes send packets using their own care-of address as a source directly to the other's care-of address. Hence, Type 2 Routing Header carrying correspondent node's home address and a Home Address Option carrying mobile node's home address are both included in the packet. +---------------+----------------+---------------+------------------ | IPv6 header | Type 2 routing | Home address | TCP/UDP header + | | header | option | data | Src=CoAMN | | | | Dst=CoACN | Dst=HoACN | Src=HoAMN | | 40 bytes | 24 bytes | 24 bytes | +---------------+----------------+---------------+------------------ Figure 1: Original Headers for data communications in simultaneous movement Therefore a header length of 88 bytes is essentially needed for the mobile node to send data packets directly to its correspondent node under the situation of simultaneous mobility. Previously when Mobile IPv6 was being standardized it was proposed to use IPv6 in IPv6 tunnels instead of RH2 and HAO headers between pairs of mobile nodes. Problems with interactions between MNs and fixed nodes, as well as negotiation of tunnels instead of extension headers were cited for deferring consideration of this solution (see Section 5). In this document, we (re)suggest to use IPv6 header instead of Type 2 Routing Header and Home Address Option to carry both mobile and correspondent node's home addresses. We present a mechanism to provide tunneled packets only for MN-to-MN communications, without incurring overheads for non mobile devices. The target packet formats are outlined below: Daley, et al. Expires September 2, 2005 [Page 4] Internet-Draft MN-to-MN Packet Tunneling March 2005 +---------------+----------------+--------------------- | IPv6 header | IPv6 header | TCP/UDP header + | | | data | | | | 40 bytes | 40 bytes | +---------------+----------------+--------------------- Figure 2: New Headers for data communications in simultaneous movement Since IPv6 header length is 40 bytes, this mechanism reduces 8 bytes for the data packets. 2. Changes to IPv6 Mobile Nodes To support the use of an IPv6 header for route optimized communications in simultaneous movement, we suggest to store a flag, indicating the support of such mechanism in each Binding Update List. We also add a flag, indicating the support of the mechanism from the peer node in the corresponding binding cache entry. While retaining all of the original fields in the Binding Cache entry as specified in the Mobile IPv6 specification [1], each entry will have an additional field: o A flag indicating whether or not the mobile node supports data packet tunneling for route optimization When sending a Binding Update message, the mobile node checks a flag and sets an additional bit, 'T', accordingly. When receiving a Binding Update Message with the 'T' bit set to 1, the mobile node enables the flag in the Binding Cache entry for the source address of the Binding Update message. If flags residing in both the Binding Update List entry and a specific Binding Cache entry, Tunnels may be used between the care-of address of the mobile node and the care-of address of the correspondent node specified in that Binding Cache entry. 2.1 Binding Update Message The new format of the Message Data field in the Mobility Header is as follows: Daley, et al. Expires September 2, 2005 [Page 5] Internet-Draft MN-to-MN Packet Tunneling March 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|T| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tunneling (T) The Tunneling (A) bit is set when the support for the use of IPv6 header is enabled to replace Type 2 Routing Header and Home Address Option. 3. Sending data packets When receiving packets from upper layer, we suggest to encapsulate them with an IPv6 header before consulting the Binding Cache and Binding Update List. The source address is the mobile node's home address and the destination address is the correspondent node's home address (as is recognised by the upper layer). The mobile node first checks if it supports the use of IPv6 header for route optimized communications. If not, Type 2 Routing Header and Home Address Option are used according to the operations of the base base Mobile IPv6 specification. If so, the mobile node then checks if the communicating node also supports such mechanism by consulting the Binding Cache for an entry that matches with the destination address. While the support in the entry is enabled, the mobile node then encapsulate the datagram with an additional IPv6 header with mobile node's care-of address as source address and correspondent node's care-of address as destination address. Daley, et al. Expires September 2, 2005 [Page 6] Internet-Draft MN-to-MN Packet Tunneling March 2005 +-----------------------------+--------------------------+-------- | IPv6 header | IPv6 header | Data | | | | Src = MN's care-of address | Src = MN's home address | | Dest = CN's care-of address | Dest = CN's home address | +-----------------------------+--------------------------+-------- MN = Mobile Node CN = Correspondent Node Figure 4: Addresses in the new header 4. Receiving data packets When receiving data packets from the peer node, the mobile node looks up the Binding Cache for an entry that matches with the source address and checks if the flag for the support of packet data tunneling is enabled. While the flag is set to true, we use the Binding Update List to validate the packets. The packets are supported in the data packet tunneling with the peer node ONLY if all of the following conditions are satisfied: o the source address of the SECOND IPv6 header matches the sender's home address in the Binding Cache entry o the destination address of the SECOND IPv6 header matches the recipient's home address which is present in the Binding Update List for the correspondent node o the source address of the FIRST IPv6 header matches the sender's care-of address in the same Binding Cache entry as above. o the destination address of the FIRST IPv6 header matches the recipient's care-of address in the same Binding Update List entry as above. The base Mobile IPv6 specification should be followed if any of the above is not satisfied. Should all of the above conditions be satisfied, the packet is then decapsulated, leaving the second IPv6 header and the upper layer data along to be further processed. 5. Acknowledgments During development of Mobile IPv6 Markku Savela suggested using tunnels instead of RH2 and HAO. At the time this proposal was rejected, not because it was a bad idea, but because of timeliness issues for issuing the MIPv6 specification. Daley, et al. Expires September 2, 2005 [Page 7] Internet-Draft MN-to-MN Packet Tunneling March 2005 A summary of this issue is available at: http://users.piuha.net/jarkko/publications/mipv6/issues/issue286.txt 6. References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 Email: greg.daley@@eng.monash.edu.au Eric Wu Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4996 Email: eric.wu@@eng.monash.edu.au Ahmet Sekercioglu Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 3503 Email: ahmet.sekercioglu@@eng.monash.edu.au Daley, et al. Expires September 2, 2005 [Page 8] Internet-Draft MN-to-MN Packet Tunneling March 2005 Sathya Narayanan Panasonic Digital Networking Lab 2 Research Way Princeton, NJ 08540 U.S.A. Phone: (609) 734 7599 Email: sathya@@Research.Panasonic.COM Daley, et al. Expires September 2, 2005 [Page 9] Internet-Draft MN-to-MN Packet Tunneling March 2005 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 (2005). 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. Daley, et al. Expires September 2, 2005 [Page 10]