MIP6 R. Jaksa Internet-Draft C. Williams Expires: December 27, 2006 B. Sarikaya S. Dawkins Huawei USA June 25, 2006 Discussion on Requesting a mobile nodes binding information draft-jaksa-mn-busolict-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 December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft documents an idea whereby a Mobile IPv6 supported correspondent node (CN) may request or solicit binding information about a Mobile IPv6 node (MN) either directly or by way of its respective Home Agent. Jaksa, et al. Expires December 27, 2006 [Page 1] Internet-Draft Requesting MN binding info June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Mobility Message Solicitation Request option . . . . . . . . . 4 4.1. Background on Binding Refresh Request (BRR) Message . . . . 4 4.2. Binding Solicitation Request (BSR) Message . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative references . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Jaksa, et al. Expires December 27, 2006 [Page 2] Internet-Draft Requesting MN binding info June 2006 1. Introduction The tunneling of packets between the correspondent node and the mobile node via the home agent is known as bidirectional tunneling. Bidirectional tunneling ensures that the mobile node is always reachable when it is away from home, even if the correspondent node is not Mobile IPv6-capable. The sending of packets directly between a mobile node and a Mobile IPv6-capable correspondent node is known as route optimization. [1] There may be usage scenarios whereby a correspondent node may wish to maintain the binding information for other Mobile IPv6 nodes without first exchanging data packets or requiring a mobile node to send binding updates to the correspondent node. This draft documents a proposal whereby a correspondent node may query a home agent for binding information about another mobile node or that a correspondent node may solicit binding information from the MN directly. Again, with such solicitation there is no requirement that a session is in progress or will ever happen. The distant node simply may wish to have the binding information of the respective MN or wishes to have this information prior to beginning a session. In particular this draft seeks to document a couple of usage cases. It is assumed throughout this draft that the requesting correspondent node is also a Mobile IPv6 supported node that is requesting binding information from its respective Home Agent about another Mobile IPv6 node that is also being serviced by the same Home Agent. 2. Terminology See [2] for mobility terminology used in this document. 3. Usage Cases Mobile IPv6 [1] defines a process during which a mobile node sends a Binding Update to its home agent or a correspondent node, causing a binding for the mobile node to be registered. Usage scenarios exist whereby a correspondent node may wish to request the mobile node's binding from its home agent. Mobile aware applications or services may need to know if another mobile node is connected or active. For example, the absence of a binding association for a homeless mobile node may mean that the node is not active or connected. Perhaps the mobile node is in nomadic mode and is currently inactive. A correspondent node can make a request to the home agent for the binding information. Applications may then use the binding cache to obtain information about on-line or Jaksa, et al. Expires December 27, 2006 [Page 3] Internet-Draft Requesting MN binding info June 2006 active status for the respective mobile node. Examples may include end-to-end gaming applications that may need to know if nodes within some predefined communication group are active (i.e., on-line). Here the Home agent is providing information to a node about the current reachability status of another node. Location based service support for mobile nodes is another usage case. For example, a server may wish to periodically track the movement and/or location of mobile nodes that are subscribing to its services even though there is not an active on-going session. The correspondent node providing the services may periodically check the location of the mobile node by requesting its binding information from the home agent. Services may then retrieve the binding cache and push location-based information to the mobile node. Other usage examples deal with multi-homed MN (MONAMI6 supported MNs) [3] [4] [5] . Some of those are enumerated in section 4 below. One example is that CN may wish to beware of flow state bindings (that are being discussed in MONAMI6) prior to initiating communication. This will allow the flows to happen that are preferred by the MN when the CN is the entity that is initiating communications. 4. Mobility Message Solicitation Request option This section defines a mobility message solicitation option that may be used by a node to request through a solicit type message a Binding Update or mobility binding type information such as the type of flow information that is being discussed in MONAMI6. Since the MONAMI6 work is still in progress, the actual format or additional extensions may be modified or added to this draft at some later point in time. 4.1. Background on Binding Refresh Request (BRR) Message Mobile IPv6 [1] defines the Binding Refresh Request (BRR) message requests a mobile node to update its already existing mobility binding. As is stated in [1] the BRR message is sent by correspondent nodes according to the rules in the base specification. When a mobile node receives a packet containing a Binding Refresh Request message it processes the message according to the rules in the base specification (see Section 11.7.4) of [1]. 4.2. Binding Solicitation Request (BSR) Message Deployment of Mobile IPv6 will require that the distant peer node (correspondent node) to know information about the Mobile IPv6 supported node prior to initiating communications. This becomes even more important when the Mobile IPv6 node is multi-homed (or MONAMI6 Jaksa, et al. Expires December 27, 2006 [Page 4] Internet-Draft Requesting MN binding info June 2006 supported). Even if the Mobile Node is not multi-homed a CN may wish to simply know the bindings of a peer. This information may be initially solicited by the CN. Mobility aware applications may also make use of this information in many different ways. Such information may include but is not limited to such things as 1. MN is on-line or off-line; 2. if the MN is at home or not at home; 3. if the MN is multi-homed or not. 4. if the MN is behind a NAT or not 5. MN is multi-homed and if so multi-homed information as well as other yet to be specified MONAMI6 specific information (i.e., flows, etc). The BSR message will have similar message format as the BRR [1] , e.g., +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Additional Mobility Options to be determined in later revisions of this document. Such additional options must be defined to obtain the specific kinds of data (such as enumerated in the above list) that a CN may wish to solicit. Once MONAMI6 flow bindings are specified such mobility options will be defined so that a CN may solicit these bindings either for a MN via a direct solicitation or through a request to the respective HA. 5. Security Considerations It is assumed throughout this draft that the requesting correspondent node is also a Mobile IPv6 supported node that is requesting binding information from its respective Home Agent about another Mobile IPv6 node that is also being serviced by the same Home Agent. As such there is already a security association between the nodes requesting binding information and the home agent. Instead of sending a binding Jaksa, et al. Expires December 27, 2006 [Page 5] Internet-Draft Requesting MN binding info June 2006 update to the home agent, a request for another mobile nodes binding information is being made. What needs to be fretted out is a way to keep private home agent binding cache entries for mobile nodes that don't want to disclose this information. 6. References 6.1. Normative references [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. 6.2. Informative References [3] Montavont, N., Wakikawa, R., and T. Ernst, "Analysis of Multihoming in Mobile IPv6", Work In Progress draft-ietf-monami6-mipv6-analysis-00.txt, February 2006. [4] Huitema, C. and R. Draves, "Host-Centric IPv6 Multihoming", Work In Progress draft-huitema-multi6-hosts-00.txt, July 2001. [5] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484 Year 2003, February 2003. Jaksa, et al. Expires December 27, 2006 [Page 6] Internet-Draft Requesting MN binding info June 2006 Authors' Addresses Robert Jaksa Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: rjaksa@futurewei.com Carl Williams Huawei USA Consultant, Palo Alto, CA 94306 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org Bechet Sarikaya Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: bsarikaya@huawei.com Spencer Dawkins Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: sdawkins@huawei.com Jaksa, et al. Expires December 27, 2006 [Page 7] Internet-Draft Requesting MN binding info June 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. Jaksa, et al. Expires December 27, 2006 [Page 8]