MIP6 WG Ma Yuzhi Internet Draft Huawei Technologies CO.,LTD Expires: April 12, 2006 October 13, 2005 Improve communication between Mobile Nodes draft-yuchi-mip6-mntomn-improve-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 April 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Any node communicating with a mobile node in Mobile IPv6 is referred to as a "correspondent node" of the mobile node, and may itself be either a stationary node or a mobile node. Communication between Ma Expires April 13, 2006 [Page 1] Internet-Draft Improve communication between MN October 2005 mobile nodes has additional complexity. This document specifies a solution to improve communication procedure between mobile nodes. Table of Contents 1. Introduction.................................................2 2. Terminology..................................................3 3. Overview of the solution.....................................3 3.1. Mobile Correspondent Node...............................3 3.2. Binding Refresh Request Message.........................4 3.3. Correspondent Address Option............................4 4. Protocol Operations..........................................4 4.1. Home Agent Operations...................................4 4.2. Mobile Correspondent Node Operations....................5 4.3. Mobile Node Operations..................................5 5. IANA Considerations..........................................5 6. Security Considerations......................................5 7. Acknowledgments..............................................5 8. Normative References.........................................6 Author's Addresses..............................................6 Intellectual Property Statement.................................6 Disclaimer of Validity..........................................7 Copyright Statement.............................................7 Acknowledgment..................................................7 1. Introduction The Mobile IPv6 base protocol does not specially specify the communication procedure between two mobile nodes. According to the procedure defined for mobile node and correspondent node, the communication between two mobile nodes MN1 and MN2 can be described as follows: o Mode1: Both MN1 and MN2 are at home. They communicate with each other using conventional Internet routing mechanisms. o Mode2: One is at home and one is away from home. Their communication procedure is same as the procedure between a mobile node and a stationary correspondent node. Ma Expires April 13, 2006 [Page 2] Internet-Draft Improve communication between MN October 2005 o Mode3: Both MN1 and NM2 are away from home, and finish home registration respectively. If they don't register their care-of address with each other, then they communicate with each other using bidirectional tunneling mode. Packets from MN1 are routed to its home agent, then routed to the home agent of MN2, and finally tunneled to the care-of address of MN2. Packets from MN2 to MN1 use the reverse procedure. o Mode4: MN1 is away from home first and finishes home registration, it then initiates a correspondent registration for MN2 which acts as correspondent node now. MN2 moves to foreign link subsequently and finishes home registration, then it may initiate a correspondent registration for MN1. Finally, MN1 and MN2 can communicate using route optimization. A mobile node has dual nature when it communicates with another mobile node. Sometimes its role is mobile node, and sometimes its role is correspondent node. For this reason, communication between mobile nodes has additional complexity when using the third and fourth modes, as described above. This document specifies a solution to improve the fourth mode. How to improve the third mode is beyond the scope of this specification. 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 [1]. This document uses terminology specific to Mobile IPv6 as defined in section "Terminology" of RFC 3775. 3. Overview of the solution 3.1. Mobile Correspondent Node In order to differentiate between the two communicating mobile nodes, a new concept called "mobile correspondent node" is introduced. The initiator of a correspondent registration acts as a mobile node, and the receiver acts as a mobile correspondent node. The receiver SHOULD NOT initiate a correspondent registration for the initiator, and both sides SHOULD maintain this relationship in future communication. A mobile correspondent node SHOULD inform the mobile node of its new Ma Expires April 13, 2006 [Page 3] Internet-Draft Improve communication between MN October 2005 address, when it moves to a new link. The method for doing this is specified below. 3.2. Binding Refresh Request Message A Binding Refresh Request (BRR) is used by a correspondent node to request a mobile node to re-establish its binding with the correspondent node. This message is typically used when the cached binding is in active use but the binding's lifetime is close to expiration. In this solution, this message is extended to inform the mobile node of a correspondent node's address when its address has changed or will change. 3.3. Correspondent Address Option A new option called "Correspondent Address Option" is defined for the BRR message. This option is used to carry the correspondent address and its format is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Correspondent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Protocol Operations 4.1. Home Agent Operations The home agent's operations are according to [2]. Ma Expires April 13, 2006 [Page 4] Internet-Draft Improve communication between MN October 2005 4.2. Mobile Correspondent Node Operations Due to movement, reconfiguration, or other reason, a correspondent node's address may change. As a result, the correspondent node SHOULD send a BRR message to the mobile node. If a correspondent node sends BRR message after its address has changed, this option contains its previous address; otherwise this option contains its prospective address. Obtaining a prospective address is according to [3]. 4.3. Mobile Node Operations When a mobile node receives a BRR message containing a correspondent address option and the mobile node has a Binding Update List entry for the address carried by the option, then the mobile node should start the return routability procedure which is sent to the source of the BRR message. If the mobile node has a Binding Update List entry for the source of the BRR, then the mobile node should start the return routability procedure which is sent to the address carried by the correspondent address option. Other operations of the mobile node are according to [2]. 5. IANA Considerations IANA is requested to assign a mobility option code for the correspondent address option. 6. Security Considerations Section 15 of [RFC 3775] outlines the Mobile IPv6 security considerations. This option does not change these in any significant way. Detailed security of this option will be considered in future. 7. Acknowledgments Ma Expires April 13, 2006 [Page 5] Internet-Draft Improve communication between MN October 2005 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC3775, June 2004. [3] Koodli, R., "Fast Handover for Mobile IPv6", RFC4068, July 2005. Author's Addresses Ma Yuzhi Huawei Bld., No.3 Xinxi Rd., Shang Di Information Industry Base, Hai-Dian District Beijing P.R.China Email: myz@huawei.com 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 Ma Expires April 13, 2006 [Page 6] Internet-Draft Improve communication between MN October 2005 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. Ma Expires April 13, 2006 [Page 7]