MIP6 R. Jaksa Internet-Draft C. Williams Intended status: Informational B. Sarikaya Expires: September 6, 2007 S. Dawkins Huawei USA March 5, 2007 A mechanism defined for requesting a mobile nodes binding information draft-jaksa-mn-busolict-03.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 September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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. Such a solicitation may be used for peer-to- peer applications and services. A new Mobile IPv6 Group management system is also defined in this revision. Jaksa, et al. Expires September 6, 2007 [Page 1] Internet-Draft Requesting MN binding info March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage Cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Mobility Message Solicitation Request option . . . . . . . . . 5 4.1. Background on Binding Refresh Request (BRR) Message . . . 5 4.2. Binding Solicitation Request (BSR) Message . . . . . . . . 6 5. Specification of solicitation of binding updates for nodes within some predefined group . . . . . . . . . . . . . . . . . 7 6. Mobility Aware Applications . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative references . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Jaksa, et al. Expires September 6, 2007 [Page 2] Internet-Draft Requesting MN binding info March 2007 1. Introduction The world of mobile communications is changing rapidly. Not only new technologies evolve, but new communication paradigms and new ways of combining the existing solutions is created. These developments will increasingly affect the users as they will use new services through some new device using some new communication technology. In the following document we propose new changes and a new model for mapping Mobile IPv6 model to current modes of Internet communications. Without taking into consideration the services and application trends, there exist a danger of creating a protocol that is isolated from the types of services it will enable and help. In this regard new services that are molded on top of Mobile IPv6 will have specific requirements from the mobility management layer. Up to this point MObile IPv6 work has been defined without regard to the type of new services that are now possible. Mobile Internet Protocol version 6 (IPv6) allows an IPv6 node to be mobile-to arbitrarily change its location on the IPv6 Internet-and still maintain existing connections. This is done by installing a Mobile IPv6 Home Agent (HA) which maintains information about all mobile node bindings in a binding cache. Also, mobile nodes maintain information about correspondent nodes in a binding update list. Mobility applications may require to be aware of Mobile IPv6 state information that is registered with the HA. Currently, this information is often only provided to the Mobile IPv6 node when communication is initiated; and then it is often only with that specific node. A Mobile IPv6 enabled application may need to know the presence of a specific group of Mobile IPv6 nodes so that "sharing" with this group may be possible. What is needed are methods and systems for Mobile IPv6 nodes and their respective enabled client applications to automatically discover and retrieve state information of any other Mobile IPv6 node in some specified group. For example, these methods should also contain security and authentication methods so that only those mobile Ipv6 nodes within a group are shared with other nodes in that same group. We raise the idea of a new concept of a new Mobile IPv6 extension of a BU Solicitation method which may be used for peer-to-peer communication in a mobile environment. This approach is based on the concept of that the Home Agent represents a trusted entity that constantly monitors the mobile nodes that it services and collects this information for the use of different applications. The peer-to-peer applications reside on the mobile nodes. The mobile nodes may then solicit binding information of members of some predefined abstract group that is layered above the mobility layer. The tunneling of packets between the correspondent node and the mobile node via the home agent is known as bidirectional tunneling. Jaksa, et al. Expires September 6, 2007 [Page 3] Internet-Draft Requesting MN binding info March 2007 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. Finally the draft specifies a new model that provides for Mobile IPv6 group management that will require additional signaling at the mobility management layer. This involves the specification of a binding solicitation message and a binding solicitation response message. 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 Jaksa, et al. Expires September 6, 2007 [Page 4] Internet-Draft Requesting MN binding info March 2007 request to the home agent for the binding information. Applications may then use the binding cache to obtain information about on-line or 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 is 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. New services are not only a reason for the development of new communications paradigms but they may also be consequences of the development. As IPv6 mobility advances evolve it will enable new service scenarios and new business models. Positioning and personalization is seen as examples of the current trends. Also, peer-to-peer applications is the future the content of a service will depend increasingly on the terminal being mobile as well as the preferences of the user (i.e., MONAMI6 based applications). 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 Jaksa, et al. Expires September 6, 2007 [Page 5] Internet-Draft Requesting MN binding info March 2007 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 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 Jaksa, et al. Expires September 6, 2007 [Page 6] Internet-Draft Requesting MN binding info March 2007 request to the respective HA. 5. Specification of solicitation of binding updates for nodes within some predefined group The BU Solicitation approach may be used for peer-to-peer communication in a mobile environment. This approach is based on the concept of that the Home Agent represents a trusted entity that constantly monitors the mobile nodes that it services and collects this information for the use of different applications. The peer-to- peer applications reside on the mobile nodes. The mobile nodes may then solicit binding information of members of some predefined abstract group that is layered above the mobility layer. A mapping may be defined between the mobility management layer and the group management system. In such a model the creation of binding cache entries for nodes happens during group formation rather than when an active session is initiated or ongoing. If at the group management layer there exist a security relationship between the nodes in the group, no return routability signaling is required. In this case an optimized security model at the mobility management layer results. In the case that the group is open and no pre-defined security among group members exists, then normal Mobile IPv6 signaling is used (i.e., RTT, etc) when the initial binding solicitation message is made. +-------------------------------+ | Group management | |For Peer-to-Peer Applications | | | | | |-------------------------------| | IPv6 | | | | Mobile IPv6 Subsystem | +-------------------------------+ Figure 2: Mobile IPv6 and Group management Model The Mobile IPv6 Group management model the use of a solicitation message to obtain binding update information for nodes in some pre- defined group that a node may at anytime initiate communication with will be required. A binding solicitation response message will Jaksa, et al. Expires September 6, 2007 [Page 7] Internet-Draft Requesting MN binding info March 2007 provide the request information to the querying node. An interface between the mobility management layer will enable nodes to determine if another node is a member of its group and if so the type of group. Peers may form a secure channel of communication regardless of the location of where the node moves to. Security methods such as IPsec or other security mechanisms maybe used to secure this communication channels. In this scenario mobile host to mobile host VPN service is created. The use of peer-to-peer approach will become more popular. Currently peer-to-peer approach is limited by the mobile ipv6 signaling but this will change when this approach is applied into mobile IPv6 based networks. Peer-to-peer communication is seen as one of the most promising communication paradigms of the future as it allows resource sharing in a flexible manner. It allows truly dynamic networking and offers possibilities for the service scenarios of the future. Mobile IPv6 may define new extensions to enable better peer-to-peer services that may be based on this protocol and provide optimizations for such services. With the success of P2P for file sharing applications, it is the hope that these benefits can be brought into new mobility management schemes to improve their scalability, robustness, availability, and performance. This concept here in would enhance Mobile IPv6 mobility management system for mobile aware applications as well as for use in peer-to-peer applications. 6. Mobility Aware Applications Mobile IPv6 (MIPv6) retains connectivity through a single, well-known Home Address of the Mobile Node when it changes its attachments to different subnets. The key benefit of Mobile IPv6 is that even though the mobile node changes locations and addresses, the existing connections through which the mobile node is communicating are maintained. To accomplish this, connections to mobile nodes are made with a specific address that is always assigned to the mobile node, and through which the mobile node is always reachable. Mobile IPv6 provides Transport layer connection survivability when a node moves from one link to another by performing address maintenance for mobile nodes at the Internet layer. Thus applications need not be restarted and need not need to be mobile aware. Optionally, there may be need for applications to be aware of the information within the mobility management binding cache for Mobile IPv6. In this case the application may want to know about binding state of other nodes without actually starting or maintaining connectivity with those respective nodes. The binding query message Jaksa, et al. Expires September 6, 2007 [Page 8] Internet-Draft Requesting MN binding info March 2007 in this draft allows for information to be obtain in other binding caches of MNs of interest. The diagram below shows how mobility aware applications may query its own binding cache for information of other MNs. +-------------------------------+ | | | Mobility Aware Applications | | | | | |-------------------------------| | Transport | | | | | +-------------------------------+ | | | | | Mobile IPv6 Binding Cache | | | +-------------------------------+ Figure 3: Mobile IPv6 and Group management Model 7. 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 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. 8. References Jaksa, et al. Expires September 6, 2007 [Page 9] Internet-Draft Requesting MN binding info March 2007 8.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. 8.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. 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 Jaksa, et al. Expires September 6, 2007 [Page 10] Internet-Draft Requesting MN binding info March 2007 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 September 6, 2007 [Page 11] Internet-Draft Requesting MN binding info March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jaksa, et al. Expires September 6, 2007 [Page 12]