MIP6/NEMO Working Group V. Devarapalli Internet-Draft Nokia Expires: September 6, 2006 R. Wakikawa WIDE P. Thubert Cisco March 5, 2006 Local HA to HA protocol draft-devarapalli-mip6-nemo-local-haha-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 September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the use of an Inter Home Agents protocol (HAHA) to achieve Home Agent reliability and load balancing. The protocol allows Home Agents serving the same home link to share the binding cache contents, and switch a mobile node from one home agent to another. It also allows a mobile node to utilize multiple Home Devarapalli, et al. Expires September 6, 2006 [Page 1] Internet-Draft Local HA to HA protocol March 2006 Agents simultaneously. A mobile node picks one Home Agent as its primary Home Agent and registers with it. The primary Home Agent synchronizes the binding cache information with other Home Agents. Any of Home Agents can intercept a packet meant for the mobile node and tunnel the packet directly to its current Care-of address. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Home Agent List Management . . . . . . . . . . . . . . . . 4 3.2. Home Agent Failure Detection . . . . . . . . . . . . . . . 5 3.3. Binding Synchronization . . . . . . . . . . . . . . . . . 5 3.4. Home Agent Switching . . . . . . . . . . . . . . . . . . . 6 4. Interworking with VRRP for IPv6 . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Devarapalli, et al. Expires September 6, 2006 [Page 2] Internet-Draft Local HA to HA protocol March 2006 1. Introduction Mobile nodes [3] and mobile routers [5] may use a bi-directional tunnel with their Home Agents for all traffic with the correspondent nodes. Note that in this document, the term mobile node refers to both a mobile node and a mobile router. A Home Agent on the home link maintains a binding cache entry for each mobile node and uses the binding cache entry to route any traffic meant for the mobile node or the mobile network. If the mobile node does not have a binding cache entry at the Home Agent, it is neither reachable at its home address nor able to setup new sessions with its home address. If a Home Agent loses the binding cache state, due to failure or some other reason, it results in loss of service for the mobile nodes. It would be very beneficial to provide high availability and redundancy for a Home Agent so that the mobile nodes can avail of uninterrupted service even when one Home Agent crashes or loses state. Mobile IPv6 defines a rudimentary load balancing mechanism based on the Dynamic Home Agent Address discovery mechanism (DHAAD). Each Home Agent advertises a preference value on the home link. The home agents are ordered based on the preference values in a DHAAD reply. A mobile node typically picks the Home Agent that appears first on the list of Home Agents in the DHAAD reply. A Home Agent can dynamically alter its position on the list by changing its preference value. But the DHAAD mechanism is useful only when the mobile node tries to discover a Home Agent when it does not have one configured. It cannot be used dynamically to switch a mobile node to another Home Agent. Moreover, DHAAD is only initiated by the mobile node. Also the mechanism is too slow for the mobile node to recover when its Home Agent fails. In this document we present a mechanism, based on the HAHA protocol, for switching a mobile node to another Home Agent at any time and thus achieve load balancing. The switch to another Home Agent can be initiated by the mobile node or a Home Agent on the home link. We also discuss how the local HAHA protocol can be used with VRRPv6 [7] to achieve redundancy. 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 [1]. Devarapalli, et al. Expires September 6, 2006 [Page 3] Internet-Draft Local HA to HA protocol March 2006 For the HAHA protocol related terminology, please see [4] 3. Protocol Operation The following sections describe the local HAHA protocol. 3.1. Home Agent List Management RFC 3775 defines a mechanism for maintaining a home agent list when there are multiple home agents present on a link. It is based on each Home Agent sending a router advertisement periodically on the home link with a Home Address Information option [3]. However, this mechanism is governed by how a router sends a router advertisement as defined in [8]. There are restrictions on how often a router advertisement can be sent and on how they are processed by routers that receive them. Moreover, the router advertisements are not sent frequently enough to rely on the absence of the router advertisement to detect a Home Agent failure. We show in Section 3.2, how the Hello messages can be used to detect Home Agent failure. In this document, we present another mechanism based on the Home Agent Hello message defined in [4]. The Hello message includes the home agent preference, lifetime and the prefix the Home Agent serves. Each Home Agent MUST periodically send a Home Agent Hello message. The Home Agent SHOULD also send a Home Agent Hello message when its local information such as preference, lifetime, and registration status, etc. changes. The interval between two Hello messages is configurable on the Home Agents. The Hello messages should be sent a new link-local scope multicast address (to be assigned by the IANA). All the Home Agents on the home link should join this multicast address. When a Home Agent receives and processes a Hello message, it adds the Home Agent to its list of known Home Agents on the home link. The Home Agents list is ordered based on the home agent preference value. If the home agent lifetime field in the Hello message is set to 0, the Home Agent removes the Home Agent that sent the Hello message from the Home Agents list. This mechanism should be used only when all the Home Agents on a particular link support sending and receiving these Hello messages. When the Hello messages are used for maintaining the Home Agents list, the Home Agent MUST NOT use the Home Agent Information option in the router advertisements to manage the Home Agents list. Devarapalli, et al. Expires September 6, 2006 [Page 4] Internet-Draft Local HA to HA protocol March 2006 3.2. Home Agent Failure Detection Failure detection is based on Hello messages [4]. Each Home Agent is expected to send the Hello message periodically. This interval is indicated by the Hello interval field in the Hello message. If a Hello message is not received from a Home Agent within a multiple of the interval value, then the Home Agent is considered to have failed. A Home Agent that is designated as a backup for the failed Home Agent takes over and sends a Home Agent Switch Request (Section 3.4) message to all the mobile nodes that were being served by the failed Home Agent to switch to it. VRRP for IPv6 can also be used for detecting a Home Agent failure. The operation of local HAHA with VRRP is explained in Section 4. 3.3. Binding Synchronization Binding cache entries are synchronized between all the Home Agents on the home link. The Home Agent that had actually processed the Binding Update from the mobile node is considered the primary Home Agent for a particular mobile node. Each Home Agent sends a Binding Information Update message, gratuitously, whenever it creates or updates a binding cache entry for a mobile node. The Binding Information Update message is sent unicast to all the Home Agents in the home agents list. A Home Agent can send information on multiple binding cache entries in a Binding Information Update message by including multiple Binding Cache Entry Information options. The Binding Cache Entry Information option is defined in [4]. If the Binding Cache entry is for a mobile router, the mobile network prefix information is also sent in the option. When a Home Agent receives a Binding Information Update message, it stores the binding cache entry information locally and marks the entries as having received from a particular Home Agent. If the Binding Information Update message was unicast to the Home Agent, it sends a unicast Binding Information Acknowledgement message in response to the Home Agent that sent the Binding Information Update message. A Home Agent can also query another Home Agent for the binding cache information for a particular mobile node by sending a Binding Information Request Message [4]. If a Home Agents wants the Binding Cache Information for a particular mobile node it includes a Home Address mobility option, defined in [4], to carry the home address of the mobile node. If a Home Agent wants to know the forwarding state setting up for a particular Mobile Network Prefix, it includes the Mobile Network Prefix Option, defined in [2]. When a Home Agent receives a Binding Information Request message, it responds with a Devarapalli, et al. Expires September 6, 2006 [Page 5] Internet-Draft Local HA to HA protocol March 2006 Binding Information Update message for the corresponding binding cache entry. 3.4. Home Agent Switching If a Home Agent is no longer able to provide service to a particular mobile node, due to excessive load or due to an administrative reason, it can tell the mobile node to use another Home Agent on the home link by sending a Home Agent Switch Request message. This message is defined in [4]. The Home Agent MAY include the IP address of another Home Agent in the Home Agent Switch Request message. The request message MUST only be sent to mobile nodes that are not on the home link. When the mobile node receives a Home Agent Switch Request message, and if the request message contains the IP address of another Home Agent, it picks the Home Agent in the request message as the primary Home Agent and sends a Binding Update message to it. If the Home Agent Switch Request message does not contain another Home Agent address, the mobile node should perform DHAAD and obtain the current list of Home Agents. If the mobile node already has a list of Home Agents from performing DHAAD earlier, it MAY pick a Home Agent from the list and send a Binding Update message to it. If a Home Agent fails, another Home Agent on the home link can act as a backup for the failed Home Agent. The backup Home Agent sends a Home Agent Switch Request message to all the mobile nodes that were being served by the failed Home Agent. The backup Home Agent should include its IP address in the request message. The primary Home Agent switching is completed when the mobile node sends a Binding Update and creates a binding at the new Home Agent. The Home Agent that the mobile node was previously using, deletes the binding cache entry, when it receives a Binding Information Update message that contains the binding cache information for the mobile node, from the new Home Agent 4. Interworking with VRRP for IPv6 VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. Devarapalli, et al. Expires September 6, 2006 [Page 6] Internet-Draft Local HA to HA protocol March 2006 VRRP, however, cannot be used for binding cache synchronization. It can replace the failure detection mechanism described in Section 3.2. Therefore, when VRRP is available, the Home Agent Hello messages should not be used. The Home Agents should still perform binding cache synchronization as described in Section 3.3 and support the Home Agent switch mechanism as described in Section 3.4. A protocol similar to VRRP was developed for HA reliability. It is described in [9]. But this protocol cannot be used if the Home Agents are distributed geographically [6]. 5. Security Considerations When the Home Agents exchange binding cache information, they MUST use IPsec ESP to encrypt the messages. Other nodes on the home link MUST NOT be able to observe the contents of the Binding Information Update messages. The Home Agents can be connected through a dedicated subnet, separate from the home link, for exchanging information. In this case, Home Agents MAY skip confidentiality protection for the binding synchronization messages. However, no other host should be allowed to connect to this dedicated subnet. The Home Agent switching mechanism described in Section 3.4 can result in disrupting the service for the mobile node for a brief while. Therefore, the Home Agent Switch Request message MUST be protected by IPsec ESP in transport mode. If there is no existing security association, the Home Agent must negotiate an IPsec SA, as defined in [5], to protect the request message. The Home Agent Hello messages cannot be protected since they are sent to a multicast address. The Hello messages do not contain any information that requires confidentiality protection. A malicious user on the home link could send fake Hello messages and populate the Home Agents list on the Home Agents. But this mechanism is no worse than the current router advertisements based Home Agents list maintenance. The authors believe that the home link will have restricted access, which will prevent such malicious users from connecting to the home link. 6. IANA Considerations The Home Agent Hello messages are sent to an IPv6 link-local scope multicast address. This needs to be assigned by the IANA. The address should be of the following form: FF02:0:0:0:0:0:XXXX:XXXX Devarapalli, et al. Expires September 6, 2006 [Page 7] Internet-Draft Local HA to HA protocol March 2006 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Wakikawa, R., "Inter Home Agents Protocol Specification", draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress), October 2004. 7.2. Informative References [5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [6] Thubert, P., "Global HA to HA protocol", draft-thubert-nemo-global-haha-01 (work in progress), October 2005. [7] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", draft-ietf-vrrp-ipv6-spec-07 (work in progress), October 2004. [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [9] El-Rewini, H., Khalil, M., and J. Faizan, "Virtual Home Agent Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-02 (work in progress), April 2004. Devarapalli, et al. Expires September 6, 2006 [Page 8] Internet-Draft Local HA to HA protocol March 2006 Authors' Addresses Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: dvijay@gmail.com Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan Email: ryuji@sfc.wide.ad.jp Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 France Email: pthubert@cisco.com Devarapalli, et al. Expires September 6, 2006 [Page 9] Internet-Draft Local HA to HA protocol March 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. Devarapalli, et al. Expires September 6, 2006 [Page 10]