[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/