MIP6 WG Yuzhi Ma Jian Zhang Internet Draft Huawei Technologies CO.,LTD Expires: October 12, 2006 April 12, 2006 Improve communication between Mobile Nodes draft-yuchi-mip6-mntomn-improve-01.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 October 12, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 Ma & Zhang Expires August 12, 2006 [Page 1] Internet-Draft Improve communication between MN April 2006 either a stationary node or a mobile node. Communication between 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 4. Protocol Operations.........................................5 4.1. Home Agent Operations..................................5 4.2. Mobile Correspondent Node Operations...................5 4.3. Mobile Node Operations.................................5 5. IANA Considerations.........................................5 6. Security Considerations.....................................6 7. Acknowledgments.............................................6 8. Normative References........................................7 Author's Addresses.............................................7 Intellectual Property Statement................................7 Disclaimer of Validity.........................................8 Copyright Statement............................................8 Acknowledgment.................................................8 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 & Zhang Expires October 12, 2006 [Page 2] Internet-Draft Improve communication between MN April 2006 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, the signaling messages, exchanged between mobile nodes, have additional complexity when using the third and fourth modes, as described above. This document specifies a solution to improve signaling messages of 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. Ma & Zhang Expires October 12, 2006 [Page 3] Internet-Draft Improve communication between MN April 2006 The figure below shows the typical relationship among three node in mobile IPv6 network. Node1 Node2 +---------------+ +-------------------------+ | |-----------|Mobile Correspondent Node| | Mobile Node | | | | | | Mobile Node | +---------------+ +-------------------------| | | | +-------------------------+ | | | Correspondent Node | | | +-------------------------+ Node3 If Node1 initiate a correspondent registration for Node2, then it act as a mobile node for Node2. If Node2 initiate a correspondent registration for Node3, then it act mobile node for Node2, and it act as mobile correspondent node for Node1 at the same time. Node2 should maintain Binding Cash and Binding Update List respectively. A mobile correspondent node SHOULD inform the mobile node of its new address, when its address is changed for some reason. 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 used to inform the mobile node of a mobile correspondent node's address when its address has changed or will change. The following options are valid in a BRR message: Ma & Zhang Expires October 12, 2006 [Page 4] Internet-Draft Improve communication between MN April 2006 The Home Address option is used to carry home address of the mobile correspondent node and the Alternate Care-of address option is used to carry its Care-of address. The encoding and format of these two option are described in [2]. 4. Protocol Operations 4.1. Home Agent Operations The home agent's operations are according to [2]. 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, the Alternate Care-of address 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 For delay-insensitive applications, when a mobile node receives a BRR message containing a Alternate Care-of 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 Alternate Care-of address option. Other operations of the mobile node are according to [2]. For delay-sensitive applications, the return-routability procedure can lead to a handoff delay unacceptable. Optimizations for reduced signaling overhead between mobile nodes should be considered more detail in future. 5. IANA Considerations This document has no actions for IANA. Ma & Zhang Expires October 12, 2006 [Page 5] Internet-Draft Improve communication between MN April 2006 6. Security Considerations Section 15 of [2] outlines the Mobile IPv6 security considerations. Detailed security considerations will be listed in future. 7. Acknowledgments Ma & Zhang Expires October 12, 2006 [Page 6] Internet-Draft Improve communication between MN April 2006 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 Yuzhi Ma Huawei Bld.,No.3 Xinxi Rd., Shang Di Information Industry Base, Hai-Dian District Beijing P.R.China Email: myz@huawei.com Jian Li Huawei Bld.,No.3 Xinxi Rd., Shang Di Information Industry Base, Hai-Dian District Beijing P.R.China Email: hwzhj@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 Ma & Zhang Expires October 12, 2006 [Page 7] Internet-Draft Improve communication between MN April 2006 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. Ma & Zhang Expires October 12, 2006 [Page 8]