MEXT Working Group                                  R. Wakikawa (Editor)
Internet-Draft                                                Toyota ITC
Intended status: Standards Track                           July 13, 2009 12, 2010
Expires: January 14, 2010 13, 2011

                 Home Agent Reliability Protocol
                  draft-ietf-mip6-hareliability-05.txt (HARP)
                  draft-ietf-mip6-hareliability-06.txt

Abstract

   The home agent can be a single point of failure when Mobile IPv6 and
   its compatible protocols are operated in a system.  It is critical to
   provide home agent reliability in the event of a home agent crashing
   or becoming unavailable.  This would allow another home agent to take
   over and continue providing service to the mobile nodes.  This
   document describes the problem scope briefly and provides mechanisms
   of home agent failure detection, home agent state transfer, and home
   agent switching for home agent redundancy and reliability.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 14, 2010. 13, 2011.

Copyright Notice

   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   The home agent can be a single point of failure when Mobile IPv6 is
   operated in a system.  It is critical to provide home agent
   reliability  Code Components extracted from this document must
   include Simplified BSD License text as described in the event Section 4.e of a home agent crashing or becoming
   unavailable.  This would allow another home agent to take over and
   continue providing service to the mobile nodes.  This document
   describes
   the problem scope briefly and provides a mechanism of home
   agent failure detection, home agent state transfer, and home agent
   switching for home agent redundancy Trust Legal Provisions and reliability. are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  4
     1.2.  Problem Statement and Requirements . . . . . . . . . . . . . .  6

   4.

   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  7

   3.  Home Agent Virtual Switch Configuration . . . . . . . . . . . . . . . .  8
     4.2.  Home Agent Hard Switch . . . 11
     3.1.  Network Configuration  . . . . . . . . . . . . . . .  9
     4.3. . . . 11
     3.2.  Home Agent Management Address Configuration . . . . . . . . . . . . . 12

   4.  Home Agent Operations  . . . . . 10

   5.  Messages . . . . . . . . . . . . . . . 12
     4.1.  Home Agent List Management . . . . . . . . . . . . 11
     5.1.  New Mobility Header Messages . . . . 12
     4.2.  Detecting Home Agent Failure . . . . . . . . . . . 11
       5.1.1.  State Synchronization Message  . . . . . . . . . 14
     4.3.  Processing the HARP Messages . . . 11
       5.1.2.  Home Agent Control Message . . . . . . . . . . . . 14
       4.3.1.  IP field and Security Descriptions of HARP message . . 13
       5.1.3. 14
       4.3.2.  Processing Home Agent Hello Message (HA-HELLO) . . . . . . . . 16
       4.3.3.  Processing Home Agent Switch Over (SWO-REQ/REP)  . . . 17
       4.3.4.  Processing Home Agent Switch Back (SWB-REQ/REP)  . . . 18
     4.4.  State Synchronization  . 15
       5.1.4.  Home Agent Rekey Message . . . . . . . . . . . . . . . 17
     5.2.  New Mobility Options . . 19
       4.4.1.  Binding Cache Information Management . . . . . . . . . 20
       4.4.2.  IP field and Security Descriptions of SS message . . . 20
       4.4.3.  Requesting State of Mobile Nodes (SS-REQ)  . . . . . 17
       5.2.1.  IP address Option . 20
       4.4.4.  Sending State Information (SS-REP) . . . . . . . . . . 21
       4.4.5.  Synchronizing State (SS-REP and SS-ACK)  . . . . . . . 18
       5.2.2.  Binding Cache Information Option 22
     4.5.  Switching the Active Home Agent  . . . . . . . . . . . 18
       5.2.3.  AAA Information Option . . 23
     4.6.  Consideration of Routing and Neighbor Discovery
           Protocol (VHARP) . . . . . . . . . . . . . . 19

   6.  Home Agent Configuration . . . . . . . 24
     4.7.  Interworking with VRRP . . . . . . . . . . . . 20
     6.1.  Network Configuration . . . . . . 25
     4.8.  Retransmissions and Rate Limiting  . . . . . . . . . . . . 20
     6.2.  Address Configuration for Virtual Switch 26

   5.  Mobile Node Operation  . . . . . . . . . 21
     6.3.  Address Configuration for Hard Switch . . . . . . . . . . 21

   7. . 26
     5.1.  Home Agent Common Operation Addresses Discovery . . . . . . . . . . . . . . 26
     5.2.  IPsec/IKE Establishment to Home Agents . . . 22
     7.1.  Home Agent List Management . . . . . . . 27
     5.3.  Synchronizing State: K-bit treatment . . . . . . . . . . . 22
     7.2.  Detecting 28
     5.4.  Receiving Home Agent Failure Switch message  . . . . . . . . . . . 28

   6.  Messages Format  . . . . 22
     7.3.  Processing Hello Messages . . . . . . . . . . . . . . . . 23
       7.3.1.  Requesting Hello Message . . . 29
     6.1.  New Mobility Header Messages . . . . . . . . . . . . . 24
       7.3.2.  Sending Hello . . 29
       6.1.1.  HARP Message Format  . . . . . . . . . . . . . . . . 24
       7.3.3.  Receiving Hello . 29
       6.1.2.  State Synchronization Message Format . . . . . . . . . 32
       6.1.3.  Home Agent Rekey Message . . . . . . 25

     7.4.  Processing State Synchronization Messages . . . . . . . . 26
       7.4.1.  Requesting State of a Particular Mobile Node(s) . 34
     6.2.  New Mobility Options . . 26
       7.4.2.  Synchronizing State . . . . . . . . . . . . . . . . . 27
       7.4.3.  Reliable Transmission by Explicit Acknowledgement 35
       6.2.1.  Binding Cache Information Option . . 28
     7.5.  Processing Home Agent Control Messages . . . . . . . . . 35
       6.2.2.  State Synchronization Status Option  . 29
       7.5.1.  Standby Home Agent becomes an Active Home Agent . . . 29
       7.5.2.  Active Home Agent becomes inactive . . . . . 36
       6.2.3.  AAA Information Option . . . . . 30
     7.6.  Interworking with VRRP . . . . . . . . . . . 38

   7.  Security Considerations  . . . . . . . 31
     7.7.  Retransmissions and Rate Limiting . . . . . . . . . . . . 32 38

   8.  Home Agent Virtual Switch  . . . . . . . . . . . . . . . . . . 34
     8.1.  Consideration of Routing and Neighbor Discovery  Protocol Constants . . . . . . . . . . . . . . . . . . . . . . . . . 34
     8.2.  Home Agent Recovery  . . . . . . . . . . . . . . . . . . . 34 39

   9.  Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35
     9.1.  Home Agent Recovery  . . . . . . . . . . . . . . . . . . . 35
     9.2.  Sending Home Agent Switch Messages . . . . . . . . . . . . 35
     9.3.  Sending Home Agent Rekey Messages  . . . . . . . . . . . . 36
     9.4.  Notification of Home Agent Switch Completion . . . . . . . 36
     9.5.  Mobile Node Operation  . . . . . . . . . . . . . . . . .  IANA Considerations  . 36
       9.5.1.  Home Agent Addresses Discovery . . . . . . . . . . . . 36
       9.5.2.  IKE/IPsec pre-establishment to Home Agents . . . . . . 37
       9.5.3.  Synchronizing State: K-bit treatment . . 39

   10. Additional Authors . . . . . . . 37
       9.5.4.  Receiving Home Agent Switch message . . . . . . . . . 38
       9.5.5.  Receiving Home Agent Rekey message . . . . . . 39

   11. Acknowledgements . . . . 38

   10. Security Considerations . . . . . . . . . . . . . . . . . . . 40

   11. Protocol Constants . . . . . . .

   12. References . . . . . . . . . . . . . . . 42

   12. IANA Considerations . . . . . . . . . . . 40
     12.1. Normative References . . . . . . . . . . 43

   13. Additional Authors . . . . . . . . . 41
     12.2. Informative References . . . . . . . . . . . . . 44

   14. Acknowledgements . . . . . 41

   Author's Address . . . . . . . . . . . . . . . . . . 44

   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 45
     15.2. Informative References . . . . . . . . . . . . . . . . . . 45

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 43

1.  Introduction

   In Mobile IPv6 [RFC-3775] and its compatible protocols like NEMO
   Basic Support [RFC-3963], [RFC-3963] and Dual Stack Mobile IPv6 [RFC-5555], if a
   home agent loses the binding cache state, due to failure or some
   other reason, it results in a loss of service for the mobile nodes.
   It is beneficial to provide high availability and redundancy for a
   home agent so that mobile nodes can avail of uninterrupted service
   even when one home agent crashes or loses state.  The Home Agent
   Reliability protocol (HARP) is designed to synchronize the Mobile IPv6
   states between active and manage standby home agents as VRRP[RFC-3768] or
   HSRP [RFC-2281].  A
   and switch a home agent maintains not only binding cache but
   also IPsec and IKE related states per mobile node.  Mobile IPv6
   mandates IPsec encryption for signaling in case of the active home binding registration
   (BU and BA) and return routability (HoTI agent failure.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and HoT) "OPTIONAL" in this
   document are to be interpreted as described in
   [RFC-3776].  However, IPsec states synchronization is out of scope [RFC-2119].

   In this document, the term mobile node refers to both a mobile node
   [RFC-3775] and a mobile router [RFC-3963].

   Mobility related terms used in this document.  The scope document are defined in [RFC-
   3775] and [RFC-3753].  In addition or in replacement of these, the
   following terms are defined or redefined:

   Home Agent Reliability protocol is
   limited Protocol (HARP)

      Providing reliability by using multiple home agents with
      individual home agent addresses.  It requires binding re-
      registration to the management of Mobile IPv6 related states.  Thus, we
   define two different approaches such as Home Agent Virtual Switch and
   Home Agent Hard Switch depending on the capability of IPsec state
   synchronization.  In both cases, a mobile node maintains only one new home binding at any given time.

   Home Agent Virtual Switch

      The Home Agent agent.

   Virtual Switch operation can be used only if IPsec
      state synchronization mechanism is available (outside of Home Agent Reliability Protocol).  The IPsec state per mobile node MUST
      be shared between the active home agent and standby Protocol (VHARP)

      Providing reliability by using multiple home agents in
      the background.  The active and the standby home agents are
      addressed by the same home agent address, although only the active
      home agent is accessible with the single
      virtual home agent address.  Each mobile
      node negotiates just one Security Association with the active home
      agent.  In case there is a failure of the active home agent,  It can virtually switch to the
      standby new
      home agent takes over without binding re-registration to the mobile node being aware
      of the change in the new home agent.

   Active Home Agent Hard Switch

      In

      A home agent that is currently serving the mobile nodes.

   Standby Home Agent Hard Switch, IPsec/IKE states synchronization is
      not required.  The home agents are addressed by different IP
      addresses.  When an active

      A home agent fails, a mobile node which will
      receive a notification (Home Agent Switch message [RFC-5142]) from
      a standby home agent, and send a Binding Update to the standby
      home agent.  In order for serve the mobile node to receive nodes when the active
      home agent fails.

   Failed Home Agent Switch message securely from the standby

      A home agent, the
      mobile node needs agent that is not available due to establish hardware or software
      failure, system maintenance, etc.

   Redundant Home Agent Set

      A group of an IPsec SA with both the active and the standby home agents beforehand.

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].

   In this document, the term mobile node refers to both a mobile node
   [RFC-3775] and a mobile router [RFC-3963].

   Mobility related terms used in this document are defined in [RFC-
   3775] and [RFC-3753].  In addition or in replacement of these, the
   following terms are defined or redefined:

   Active Home Agent

      A home agent that is currently serving the mobile nodes.

   Standby Home Agent

      A home agent which will serve the mobile nodes when the active
      home agent fails.

   Failed Home Agent

      A home agent that is not available due to hardware or software
      failure, system maintenance, etc.

   Redundant Home Agent Set

      A group of active and standby home agent(s). agent(s).  The Group
      Identifier is used to identify a redundant home agent set.
      Operators need to configure a value per redundant home agent set.

   Virtual Home Agent Address

      A home agent address shared among home agents in a redundant home
      agent set and used only set.  It is similar to virtual router address specified in the Home Agent Virtual Switch case.
      VRRP [RFC-3768] [RFC-5798].  The address is only activated on an
      active home agent.

   Home Agent Preference

      This preference value is originally defined for Dynamic Home Agent
      Address Discovery (DHAAD) in RFC3775.  This protocol re-uses this
      preference value for home agent selection when an active home
      agent has failed.  However, an operator can also define an
      independent value used only for the home agent reliability
      protocol if the operator wants to have different preference values
      for DHAAD and the home agent reliability protocol.  A home agent
      SHOULD NOT use the same preference value of other home agents.

3.

   New Messages

         Home Agent Reliability Protocol (HARP) message defined in
         Section 6.1.1:

            SwitchOver Request (SWO-REQ)

            SwitchOver Reply (SWO-REP)

            SwitchBack Request (SWB-REQ)

            SwitchBack Reply (SWB-REP)

            Switch Complete (SW-COMP)

            Home Agent HELLO (HA-HELLO)

         State Synchronization (SS) message defined in Section 6.1.2:

            State Synchronization Request (SS-REQ)

            State Synchronization Reply (SS-REP)

            State Synchronization Reply-Ack (SS-ACK)

1.2.  Problem Statement and Requirements

   In Mobile IPv6 [RFC-3775], [RFC-3775, RFC-4877], a mobile node registers and
   establishes a binding with only one home agent.  Thus the  The home agent
   represents the possibility of a single point of failure for Mobile
   IPv6.  A home agent is responsible for multiple mobile nodes on its
   home link.  The failure of the home agent may then result in the loss
   of connectivity for numerous mobile nodes located throughout the
   Internet.  To overcome this problem, Mobile IPv6 allows deployment of
   multiple home agents on the home link so that upon the failure of a
   home agent, a mobile node can re-establish its connection through a
   new home agent.  However, the base Mobile IPv6 specification does not
   address home agent failover fail-over and dynamic transfer of service from one
   home agent to another.  This transfer of service from the failed home
   agent to a new active home agent requires coordination or pre-configuration pre-
   configuration among the home agents regarding security associations,
   transfer of mobile node bindings, and other service information for
   reliable Mobile IPv6 service in a deployment scenario.

   For the home agent reliability solution, we define the following
   requirements:

   Reliable Home agent service

      Multiple home agents are available for a home prefix and one of
      them actively serves the mobile nodes.  A standby home agent takes
      over when the active home agent becomes unavailable.  The transfer
      of the MN-HA association should be transparent to applications and
      should not take longer than the care-of-addresses update procedure
      described in Mobile IPv6 [RFC-3775].

   Availability of a redundant home agent set

      Availability of an active home agent address and a standby home
      agent address at the bootstrapping period for the mobile node is
      assumed.

   State Synchronization

      The information for mobile nodes must be able to be synchronized
      between an active home agent and standby home agents.  This
      includes the Binding Cache, AAA information, other Mobile IPv6 and
      NEMO related information.  Note that the Home Agent Reliability
      protocol exchanges only running states of mobile nodes.
      Therefore, we do not have any specific operation for synchronizing
      the configuration information.  For instance, when Mobile IPv6 is
      operated with Authentication protocol, synchronizing the
      configurations of the Authentication protocol is out of scope in
      this document.  Operators MAY correctly set the configuration
      information in multiple home agents.

   Consideration of IPsec/IKE transfer

      An active home agent maintains several IPsec and IKE states for
      mobile nodes.  These states are synchronized within the redundant
      home agent set.  The details are described in Section 10. 7.

   Secured Message Exchanges

      The messages used between the home agents to transfer binding
      cache information MAY be authenticated and encrypted.

   Failure Detection

      Redundant home agents must actively check for possible failure of
      an active home agent.  If a home agent supports an existing
      failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC-
      2281], it can re-use that mechanism to detect the home agent
      failure.  On the other hand, periodic Hello messages are
      introduced to detect active home agent's service availability in
      this document.

   Failure Notification

      If necessary, a mobile node is notified about the active home
      agent failure by the standby home agent.

4.

2.  Protocol Overview

4.1.  Home Agent Virtual Switch

   A mobile node remains unaware about the change in the active

   HARP assumes multiple home agents placement on a same home link or
   different links and groups them into a redundant home agent since the set.  One
   of home agents have replicated all session state
   including IPsec/IKE states.  IPsec/IKE state transfer is out selected as an active home agent and receives a
   binding update from mobile nodes.  According to [RFC-3775, RFC-4877],
   an active home agent maintains not only binding cache but also IPsec/
   IKEv2 states per mobile node, because Mobile IP adapts IPsec as its
   security mechanism for signaling.

   If the active home agent fails, all these information per mobile node
   is vanished.  As a result, all mobile nodes served by the failed home
   agent will be disconnected.  In HARP, other home agents , named
   standby home agent, exchange the required information with the active
   home agent in case of scope failure of this document. the active home agent.  HARP can let
   standby home agent take over the failed home agent with such
   information of the serving mobile nodes.

     MN      HA1(active)    HA2(Standby)          HA1         HA2
      |           |<-HA1-addr |<-HA2-addr
      |           |           |
      |        (active)    (standby)
      |           |           .
      |<--------->|           |
      |           |<--------->| 1. IKE exchange (with HoA assignment)
      |---------->|           . Hello exchanges
      |<--------->|           | 2. Binding Update
      |<----------|           . 3. Binding Acknowledgment
      |           |           . Registration to HA1
      |           |<--------->. 4.           |<--------->| 3. State exchanges (binding cache/IPsec)
      |           |           .           |
      |           X           .           |  HA1 FAILURE
      |           X           .           |           X<----------. 5. Failure Detection
      |           X           | 4. Failure Detection
      |<----------------------| 5. Sending Home Agent Switch message
      |<--------------------->| 6. Binding Registration to HA2 takes over the HA1
      |           X           |       (active) RECOVERY COMPLETE
      |           X           |    RECOVERY COMPLETE

       Figure 1: Overview of Home Agent Virtual Switch

   The operations of the Home Agent Virtual Switch mode are shown in Reliability Protocol (HARP)

   Figure 1.  A mobile node first attempts 1 shows an example of the IKE exchange for Security
   Association (SA) setup HARP operations.  HA1 and HA2 belong
   to the same redundant home agent set and are assigned with an
   individual IP address assignment (1).  After
   binding registration is done (2, 3), (HA1 and HA2-addr) at the active home link.  Each home
   agent pushes all
   the states of its can be seen as an individual home agent by mobile nodes with a state synchronization message
   (4).  The standby nodes.  All
   the home agent(s) is not active unless it takes over
   from agents periodically send a failed hello message (named HA-HELLO) to
   exchange the home Agent.

   When agent information and also monitor the active home
   agent's failure is detected (5), status (1).  The mobile node registers its binding only with
   the standby active home agent activates the virtual (2).  The active home agent address on its interface
   and takes over for synchronizes the failed
   serving mobile node information (i.e. home agent.  All address) with the other
   standby home agents in periodically (3).

   HARP introduces the
   redundant new HA-HELLO message for failure detection, but
   it should use any types of information to detect that failure.  After
   detecting failure of the active home agent set share (4), a virtual standby home agent address and
   whose preference value is the
   routing will ensure only highest takes over the active home agent will be reachable
   using that virtual failed home agent address.  The
   agent.  For doing so, the standby home agent can
   serve sends a Home Agent
   Switch message to all the mobile nodes for which that were registered at the states are synchronized,
   without any further
   failed home agent (5).  The standby Home Agent set its own address in
   the Home Agent Address field in the Home Agent Switch message exchange, because so that
   it has all will receive the
   necessary information which it obtained binding update from the failed home agent.

4.2. mobile node as an
   acknowledgment of the sent Home Agent Hard Switch message.  The overview of home agent
   switch-over is complete when it receives binding updates from all the
   mobile nodes (6).  For protecting the Home Agent Hard Switch is shown in Figure 2.
   This mode is not transparent to Switch, the mobile
   node when should have IPsec Security Associations (SA) with the active standby
   home agent failure occurs.

     MN      HA1(active)    HA2(Standby)
      |           |           |
      |<--------->|           | 1. IKE exchange (with HoA assignment)
      |---------->|           | 2. Binding Update
      |<----------| before any failover.  The mobile node may pre-establish
   multiple IPsec SAs with all the home agents.

   Although the active home agent manages IPsec/IKEv2 states per mobile
   node, HARP does not offer any recovery mechanism of these states by
   itself.  IPsec/IKE states synchronization is out of scope in this
   document.  However, some Virtual Private Network (VPN) products have
   proprietary IPsec/IKEv2 state synchronization among multiple boxes.
   If IPsec/IKEv2 states can be recovered from the active home agent to
   standby one, HARP can be operated slightly in different manner named
   Virtual-HARP (VHARP).  Unlike HARP, the standby home agents are an
   exact copy of the active home agent.  It is similar to the virtual
   router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281].  Note
   that HARP is mandatory and VHARP is optional in this document.  VHARP
   is shown in Figure 2.

     MN          HA1         HA2
      | 3. Binding Acknowledgment
      |<--------------------->| 4. IKE exchange (without HoA assignment)           |<-HA-addr  :<-HA-addr'
      |           |           :
      |        (active)    (standby)
      |<--------->|           : 1. Binding Registration to HA1
      |           |<--------->. 5.           |<--------->: 2. State exchanges (binding cache)
      |
      |           |           :
      |           X           |           :  HA1 FAILURE
      |           X           :
      |
      |           X<----------| 6.           X           : 3. Failure Detection
      |<----------------------| 7. Sending Home Agent
      |           X           |          Switch message
      |<--------------------->| 8. Binding Registration 4. HA2 takes over the HA1
      |           X           |       (active) RECOVERY COMPLETE
      |           X           |    RECOVERY COMPLETE

   Figure 2: Overview of Virtual Home Agent Hard Switch

   The mobile node establishes IPsec/IKE state with all Reliability Protocol (VHARP)

   All the home agents (HA1 and HA2) in the redundant home agent set beforehand (1 and 4), however it
   registers its binding only with the active
   share a virtual home agent (2 address (HA-addr) and 3).
   When an the routing will
   ensure only the active home agent fails, a standby will be reachable using that
   virtual home agent uses address.  After a pre-
   existing IPsec SA to notify the mobile node about node's binding
   registration (1), the failure by
   securely sending a Home Agent Switch message.  In order to discover
   home agent addresses, two different mechanisms are defined, as
   described in Section 9.5.1.  The active home agent synchronizes pushes all the
   required states of the its
   mobile nodes, such as Binding Cache and AAA
   information, with nodes to the other standby home agents periodically (5).  The (2).  In VHARP, all the
   states of a mobile node MUST NOT request a home address(es) assignment through
   the IKE exchange need to be synchronized.  The example
   information such as Binding Cache and Authentication, Authorization,
   and Accounting (AAA) information, etc.

   After detecting the standby active home agent when it establishes an SA
   with it (4).

   When has failed (3), the standby
   home agent detects whose preference value is the failure of highest takes over the active
   failed home agent.  The standby home agent (6), it sends a Home Agent Switch message activates the virtual home
   agent address on its interface attached to the home link.  The
   virtual home agent address's activation can be operated by VRRP.
   Since all the necessary states of mobile nodes that were registered with have already been
   transferred to this standby home agent, the failed standby home agent (7).  The Home
   Agent Switch message must be encrypted by a pre-established IPsec SA.
   After can
   immediately start acting as the switch message, active home agent (4).  Unlike HARP,
   the mobile node MUST send a is not required to re-register its binding update to a new
   active home agent.  The mobile node may use the IKEv2 resumption
   mechanism [RFC-5723] to resume IPsec SA with the new active home agent
   agent.

   This document offers a new management mechanism of an active and
   standby home agents by using a new Mobility Header (MH) message named
   a HARP message as shown in order to update Figure 3.  This mechanism can be used in
   both HARP and VHARP.  Each home agent exchanges own home agent
   information with the Mobile IPv6
   tunnel endpoints (8).

4.3. other home agents in its redundancy home agent
   set by a Home Agent Management HELLO message (HA-HELLO) (1).  The HA-HELLO
   message can also be used to monitor the availability of the active
   home agent.

       HA1(active)  HA2    HA3 .. HAn
           |        |      |      |
           |<------>|<---->|<---->| 1. HELLO exchange
           |------->|      |      | 1. 2. HA1 sends SwitchBack Request SWB-REQ
           |<-------|      |      | 2. 3. HA2 sends SwitchBack Reply
           |        |      |      |
           |<-------| SWB-REP
           |------->|      |      | 3. 4. HA2 sends SwitchCompl (optional) SW-COMP
       (standby) (active)  |      | HA2 BECOMES ACTIVE HA
           |        |      |      |
              SYSTEM MAINTENANCE, ETC.
           |        |      |      |
           |------->|      |      | 4. 5. HA1 sends SwitchOver Request SWO-REQ
           |<-------|      |      | 5. 6. HA2 sends SwitchOver Reply
           |        |      |      | SWO-REP
           |------->|      |      | 6. 7. HA1 sends SwitchCompl SW-COMP (optional)
       (active) (standby)  |      | 7. 8. HA1 returns to active HA
           |        |      |      | HA1 BECOMES ACTIVE AGAIN

                      Figure 3: Manual Home Agent Change Management

   In some scenarios the active home agent may need to stop serving
   mobile nodes for system maintenance.  This specification provides for
   a manual home agent switch by using SwitchBack Request and Reply
   messages. management.  As shown in Figure 3, the active
   home agent (HA1) sends a SwitchBack Request message (SWB-REQ) to a
   standby home agent (HA2).  As soon as
   HA2 receives the message, it becomes the active home agent. (HA2) (2).  HA2 will acknowledge the message by
   sending a SwitchBack Reply message (SWB-REP) to HA1. HA1 becomes a standby (3).  In the HARP
   operation, it takes certain time to complete home agent fail-over by
   mobile nodes' re-registration to the new home agent.  During this
   fail-over operations, HA1 may continue serving the mobile nodes until
   the switch over is completed.  When HA2 completes the switch-over, it
   SHOULD send a SW-COMP to HA1 (4).  As soon as HA2 sends the SW-COMP,
   it becomes the active home agent.  HA1 becomes standby when it
   receives the SwitchBack
   Reply. SW-COMP.

   After the downtime, down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2
   in order to become the active home agent again.

   The SwitchCompl message is used only in the Home Agent Hard Switch.
   As shown in Section 9, again (5).  HA2 acknowledge
   it takes certain time by sending a SwitchOver Reply (SWO-REP) to complete the HA1 (6).  HA1 now
   starts home agent switch.  Thus, fail-over operation.  After the completion of fail-
   over, HA1 sends a SW-COMP to HA2 (7).  Then, HA1 returns to the old
   active home agent continues serving the
   received packets and HA2 fall back to a standby home agent (8).

3.  Home Agent Configuration

3.1.  Network Configuration

   HARP supports two different configurations for standby home agents.
   Standby home agents can be placed on the mobile nodes during the switch process.  As
   soon as the new same home agent completes link or on a
   different link.  Figure 4 depicts the recovery, it sends
   SwitchCompl message to configuration where home agents
   serving the previous active same home agent.  SwitchCompl
   is an optional operation network are located on the same link as defined
   in this specification.

5.  Messages

5.1.  New Mobility Header Messages

5.1.1.  State Synchronization Message

   This message is used to exchange state corresponding to a particular
   mobile node(s).  It MUST be unicasted and MUST be authenticated by
   IPsec ESP.  This message has the MH Type value TBD.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |     Type      |A|   Reserved [RFC-3775].

                 HA1    HA2    HA3    HA4 .... HAn
                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |         Identifier      |      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          --------+------+------+------+--------+---------
                             Home Link

                  Figure 4: State Synchronization Message

   Type

      8-bit unsigned integer.  It can be assigned one Local Recovery Configuration

   Figure 5 illustrates when standby home agents are located on a
   different link (illustrated as Recovery Link in Figure 5).  Most
   large operators have a very stringent requirement on network
   availability even in the worst type of disaster or outage.  This
   configuration can achieve home agent recovery even if the following
      values:

         0: Request entire home
   link fails.  This message is called State Synchronization Request (SS-REQ) geographic redundancy and used to solicit the active state corresponding to a
         particular mobile node.

         1: Reply

         The message is called State Synchronization Reply (SS-REP) and
         is used between the well-known
   configuration for Telecommunications operators.  In Figure 5, home
   agents (HA1-HA4) are placed in the redundant home agent set
         to exchange binding cache information geographically separated regions
   (region-1 and any other information
         related to providing mobility service -2).  If region-1 suffers a down time due to any
   reason, all the sessions will be seamlessly taken over by the mobile nodes
         either periodically or
   in response to a SS-REQ.

         2: Reply-Ack

         The message is called State Synchronization Reply-Ack (SS-ACK) region-2.  Note that HA3 and HA4 cannot receive packets meant for
   the home network until the route on the Routers is used changed.  The
   routing must be also updated to acknowledge direct the SS-REP. packets meant for the home
   link to the recovery link.

           ---------IGP------>|<---BGP--->|<-----IGP---------

                HA1    HA2                     HA3    HA4
                 |      |                       |      |
         --------+------+-----+ R---R---R +-----+------+-------
               Home Link          Routers     Recovery Link
              (region-1)                       (region-2)

                  Figure 5: Global Recovery Configuration

3.2.  Home Agent Address Configuration

   In HARP, each home agent obtains its individual IPv6 address from its
   serving home prefix.  In VHARP, all the home agents use a virtual
   home agent address generated from the home prefix.

   In addition, each home agent running VHARP need to obtain its
   individual IPv6 address from its attached link.  This message is
         optional and IPv6 address is specially
   used when only for the links VHARP operations between home agents are not reliable.

   Ack flag

      This flag and is valid only not
   revealed to mobile nodes for SS-REP.  If binding registration.

   All the sender requires
      explicit acknowledgment by SS-ACK, it home agents MUST set this flag.

   Reserved join the ALL_HA_MULTICAST_ADDR.  In VHARP,
   each home agent join the multicast group with its individual IPv6
   address, but not with virtual home agent address.  This field is unused.  It MUST multicast
   address can be initialized used to zero by exchange the
      sender and MUST be ignored by HA-HELLO message among the receiver.

   Identifier

      A 16-bit identifier to aid in matching state synchronization
      message.  The identifier should never be set to 0.  It should
      always be more than 1.

   Mobility Options

      Variable-length field of such length that home
   agents.  On the complete Mobility
      Header other hand, if a home recovery link is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in separately
   defined, each home agent always unicasts the HARP messages to home
   agents configured at a geographically separated link.

4.  Home Agent Operations

4.1.  Home Agent List Management

   In Mobile IPv6, each home agent periodically sends router
   advertisements with the Home Address Information option [RFC-3775].  The
      receiver MUST ignore and skip any options which it does not
      understand.  This
   HARP introduces a HARP HA-HELLO message requires at least one mobility option,
      therefore, there is no default length for this message.

      One to replace the router
   advertisement.  There are several reasons to use HA-HELLO message
   instead of the following options is mandatory in SS-REQ message.
      Multiple same options Router Advertisement such as:

   o  A HA-HELLO message can be stored in sent beyond the same SS-REQ message,
      (ex. two IP address options for two mobile nodes):

      *  IP Address Option (Sub-type: Home Address) defined in [RFC-
         5268].  If link, while a router
      advertisement cannot be sent beyond the link.  In case of
      geographic redundancy, router advertisements cannot be sent to the
      recovery link unless the home agent wants link and the Binding Cache recovery link are
      virtually connected by L2TP, etc.

   o  A HA-HELLO message is defined to manage additional information for
         a particular mobile node, it includes
      such as Group ID and Active/Standby Status of the mobile node's home
         address agents in an IPv6 Address Option.  If a home agent wants to
         solicit all the active mobile nodes' states, it can include
      the
         unspecified address (::) in an IPv6 address option.

      *  Mobile Network Prefix Option.  If a home agent wants to know
         the forwarding state setup for a particular Mobile Network
         Prefix, it includes list.

   o  A HA-HELLO message is exchange only between home agents, while a Mobile Network Prefix Option as defined
         in [RFC-3963].

      *  The Mobile Node Identifier option defined in [RFC4283].  If
      router advertisement is also processed by mobile nodes attached to
      a home agent wants link.  A HA-HELLO does not introduce any burden to the Binding Cache information for a particular
      mobile node, nodes even if it can include is frequently sent on the mobile node's identifier (ex.
         Network Access Identifier (NAI) [RFC4282]) in this option.

      *  Vendor Specific Mobility Option.  If home link.

   When a HA-HELLO is used to exchange the home agent wants vendor
         specific information, it can solicit with this option as
         defined in [RFC-5094].

      One of each
   home agent SHOULD NOT process the following options is mandatory in SS-REP:

      *  Binding Cache Information Option

      *  AAA Information Option

      *  Vendor Specific Mobility Option

5.1.2. Home Agent Control Message

   This message Information option
   carried by a Router Advertisement.  A router advertisement is used only
   processed by mobile nodes.  Operators may define different
   configuration values to control the status parameters of a the home agent to either
   active or standby. information
   for a HA-HELLO and a Router Advertisement.

   This message MUST be unicasted between document requires additional information to the home
   agents and MUST be authenticated and encrypted by IPsec ESP. agent list
   defined in [RFC-3775].  The
   Home Agent Control additional information is learned through
   HA-HELLO message has exchange.

   o  Group ID of a redundant home agent set.  It is learned through the MH Type
      Group ID field of the HA-HELLO.

   o  HA-HELLO Interval.  This value TBD.  If no options
   are present in this message, no padding is necessary locally configured at every home
      agent by operators and is learned through the Header
   Len Hello Interval field will be set to 1.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |     Type      |   Status      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5: Home Agent Control Message

   Type

      8-bit unsigned integer.  It can be assigned one
      of the following
      values:

         0: SwitchOver Request (SO-REQ)

         It is unicasted by a standby HA-HELLO.

   o  An individual home agent that desires to become
         the active home agent.  The receiver of the message MUST
         transition to standby state as soon as address used in the message VHARP operation.
      This information is received
         and validated successfully.

         1: SwitchOver Reply (SO-REP)

         It only required when VHARP is used in addition
      to acknowledge the receipt of the corresponding SO-
         REQ.

         2: SwitchBack Request (SB-REQ)

         It is unicasted by an active virtual home agent that desires to become
         a standby home agent.  The receiver of this message SHOULD
         transition to active state as soon as the message is received
         and validated successfully.

         3: SwitchBack Reply (SB-REP) address.  It is used to acknowledge learned through the receipt
      Source Address of the corresponding SB-
         REQ.

         4: Switch Complete (SW-COMP) HA-HELLO message.

   o  VHARP capability.  This message information is used to indicate learned through the completion V flag
      of switch over,
         (i.e. sending home agent switch messages and receiving binding
         update messages from all the served mobile nodes).

   Status

      8-bit unsigned integer indicating HA-HELLO message.

   o  Current mode (HARP or VHARP).  This information is learned through
      the disposition M flag of a SO-REQ or
      SB-REQ. the HA-HELLO message.

   o  Active status.  This field information is only valid in SO-REP and SB-REP.  The
      following Status values are defined:

         0: Success

         128: Reason unspecified

         129: Administratively prohibited

         130: Not active home agent (The receiver of SO-REQ is not learned through the
         active home agent)
         131: Not standby home agent (The receiver A flag of SB-REQ is already
      the HA-HELLO message.

4.2.  Detecting Home Agent Failure

   An active and standby home agent)

         132: Not agents can monitor each other in same redundant home agent set

   Mobility Options

      No options are several
   ways.  One method is to reuse other failure detection mechanisms
   defined in this specification

5.1.3.  Home Agent Hello Message

   The Home Agent Hello (HA-HELLO) message MUST be either unicasted or
   multicasted to carry home agent information among VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281].  However,
   VRRP and HSRP are not sufficient since they cannot detect the redundant home
   agent set.  The HA-Hello message case
   where the system is running but the Mobile IPv6 stack is not
   operational.  Failure events used in HARP/VHARP are listed below.

   Loss of HA-HELLO

      HARP/VHARP is defined for two purpose: 1) an
   alive check extension to Mobile IPv6 and 2) can monitor
      availability of Mobile IPv6 stack on each home agent information exchange.  A HA-HELLO
   SHOULD be authenticated and encrypted by IPsec ESP when it is
   unicasted.  If
      periodically sending a HA-Hello message is multicasted, IPsec ESP cannot HA-HELLO as a heart-beat.  This HA-HELLO
      can also be
   applied. exchanged frequently enough to detect the failure
      promptly without any additional overhead to mobile nodes attached
      to the home link.  In this case the redundant event that a standby home agent set should be located
   in does not
      receive any HA-HELLOs from its peer for a secure network.  Alternatively, all configurable duration,
      the standby home agents MUST have a
   secure channel with each other. agent assumes that home agent's failure.  The HA-Hello has
      detail of the MH Type value
   TBD.  If no options are present Hello message is described in this message, 0 octets of padding
   are necessary and Section 4.3.2.

   Monitored Server Failure by the Header Len field will be set to 2.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Home Agent Preference    |      Home Agent Lifetime      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Hello Interval         |   Group ID    |A|R|  Reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: Active Home Agent Hello Message

   Sequence #
      16-bit unsigned integer.  The Sequence

      There may be number of critical servers such as an AAA server in
      the HA-Hello
      message network that are essential for the ongoing Mobile IPv6
      sessions at the home agent.  Operators can be used to verify whether this Hello message have a policy in place
      that the active home agent is treated as a failed home agent upon
      detecting that the
      latest one or not.

   Home Agent Preference

      16-bit unsigned integer.  The preference for link to such servers has failed.

   Routing Peer/Link Failure

      Operators may require the home agent
      sending to detect its next-hop
      routing peer failure.  If the HA-Hello message.  This preference next-hop routing failure is fatal in
      nature, or due to some other routing policies, the same active home
      agent is treated as a failed home gent and the
      Home Agent Preference value of recovering
      operation should be started.

4.3.  Processing the Home Agent Information option
      as defined HARP Messages

4.3.1.  IP field and Security Descriptions of HARP message

   The HARP message format is defined in [RFC-3775].  However, operators MAY use Section 6.1.1.  If a different
      preference value for this operation.

   Home Agent Lifetime

      16-bit unsigned integer.  The lifetime for the home agent sending
      the HA-Hello message.  This lifetime HARP
   message is unicasted, the same as the Home Agent
      Lifetime value destination address is one of the Home Agent Information option as defined in
      [RFC-3775].

   Hello Interval

      16-bit unsigned integer.  The interval for
   the home agent sending
      this Hello message.

   Group Identifier

      8-bit unsigned integer.  This value is used to identify a
      particular redundant home agent set.

   A flag

      Active same Redundant Home Agent flag. set.  If this flag is set, the sender of this
      HA-Hello message it is an active home agent.

   R flag HA-HELLO requesting flag.  If this flag is set, the receiver of
      this HA-Hello message must send back a HA-Hello message to (by
   setting the
      sender.

   Reserved

      This type field is unused.  It to 4), it can be multicasted.  The destination
   address MUST be initialized set to zero by the
      sender and ALL_HA_MULTICAST_ADDR.  The source address
   MUST be ignored by the receiver.

   Mobility Options

      No valid options are defined in this specification.

5.1.4.  Home Agent Rekey Message

   This message is used set to indicate that the mobile node SHOULD start an
   IPsec re-key with the sender's home agent specified address.  Note that, in VHARP,
   the Home Agent
   Addresses field.  This message is used when a failed virtual home agent
   recovers and needs address SHOULD NOT be set to re-establish IPsec SA/IKE state with source and
   destination address.  The IP address of the interface the packet is
   being sent from SHOULD be used.

   If a mobile
   node.  This HARP message MUST is unicasted, it SHOULD be unicasted to a mobile node authenticated by the active
   home agent IPsec
   AH and MUST MAY be authenticated and encrypted by IPsec ESP.  The
   Home Agent Rekey  If a HA-HELLO message has the MH Type value TBD. is
   multicasted, multicast extensions to IPsec [RFC-5374] SHOULD be
   applied.  If no options all the home agents are present placed in this a secure transport
   network to exchange a HARP message, no padding is necessary authentication and encryption MAY
   be omitted.  Which security verification is used depends on
   operational policy.  If security verification is failed for a
   receiving HA-HELLO, the Header
   Len field will HA-HELLO MUST be discarded.

   The following operations MUST be performed when transmitting a HARP
   message.

   o  The incremented latest Sequence Number MUST be set to 2.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      .                      Home Agent Addresses                     .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                        Mobility options                       .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7: Home Agent Rekey Message

   Reserved the Sequence
      Number field.  The reserved field Sequence Number SHOULD be initialized to zero
      for the first Hello message.  To accomplish sequence number
      rollover, if the sequence number has already been assigned to be
      the largest possible number representable as a 16-bit unsigned
      integer, then when it is 16 bits

   Home Agent Address incremented it will then have a value of
      zero (0).

   o  The receiver sender's Group ID MUST be set to the Group ID field.

   o  The V-flag MUST be set if the sender is capable of this message VHARP.

   o  The M-flag MUST rekey be unset if the security asscoation sender is operated with the specified home agent.

5.2.  New Mobility Options
5.2.1.  IP address Option

   This option is already defined in the Fast Handovers for Mobile IPv6
   (FMIP) specification [RFC-5268].  This document introduces new Sub-
   Type values for home agent address and Home Address.

   Option-Code

      *  4: Home Address

5.2.2.  Binding Cache Information Option

   The binding cache information option has an alignment requirement of
   8n+2.  The Binding Cache Information option is only valid in a State
   Synchronization message.  Its format is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  | Length = 40   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Flags                |       Sequence Number         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Lifetime             |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                        Home Address                           |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                        Care-of Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                Mobile Network Prefix Option                   .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 8: Binding Cache Information Option

   The fields of Home Address, Care-of Address, Flags, Sequence Number,
   and Lifetime are copied from the registered binding of a particular
   mobile node or mobile router.  The 16-bit Reserved field MUST be set
   to zero.  If the R-flag is set to indicate this binding cache entry
   is for a mobile router, then this option will be immediately followed
   by one or more Mobile Network Prefix options.

5.2.3.  AAA Information Option

   This option is used to carry the AAA state of the mobile node's
   Mobile IPv6 sessions.  The AAA state information can be carried in
   RADIUS or Diameter AVP formats including the user and session info.
   This information option is only valid in a State Synchronization
   message.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |   Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                        AAA AVPs                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 9: Vendor Specific Information Option

   Type

      8-bit Type value.  The value is TBD.

   Length

      8-bit length value.

   AAA AVPs

      Series of TLV encoded AAA AVPs (including vendor specific AVPs)
      carrying AAA-related information for each Mobile IPv6 and IPsec/
      IKE session.

6.  Home Agent Configuration

6.1.  Network Configuration

   The Home Agent Reliability protocol supports two different
   configurations for standby home agents.  Standby home agents can be
   placed on the same home link or on a different link.

                 HA1    HA2    HA3    HA4 .... HAn
                  |      |      |      |        |
          --------+------+------+------+--------+---------
                             Home Link

                  Figure 10: Local Recovery Configuration

   Figure 10 depicts the configuration where home agents serving the
   same home network are located on the same link.  For example, HA2,
   HA3 and HA4 are standby home agents of HA1.  This is the same as what
   Mobile IPv6 defines for home agent configuration.

           ---------IGP------>|<---BGP--->|<-----IGP---------

                HA1    HA2                     HA3    HA4
                 |      |                       |      |
         --------+------+-----+ R---R---R +-----+------+-------
               Home Link          Routers     Recovery Link
              (region-1)                       (region-2)

                 Figure 11: Global Recovery Configuration

   Figure 11 illustrates when standby home agents are located on a
   different link (illustrated as Recovery Link in Figure 11).  Most
   large operators have a very stringent requirement on network
   availability even in the worst type of disaster or outage.  For
   example, HAs in region-1 are backed up by HAs in region-2.  These two
   regions are geographically separated.  If region-1 suffers a downtime
   due to any reason, all the sessions will be seamlessly taken over by
   the nodes in region-2.  This is called geographic redundancy.  This
   is a well-known configuration for Telecommunications operators.  It
   can achieve home agent recovery even if the entire home link fails.
   In Figure 11, HA3 and HA4 are standby home agents of HA1 and HA2.  In
   this case, HA3 and HA4 cannot receive packets meant for the home
   network until the route on the Routers is changed.  The routing must
   be also updated to direct the packets meant for the home link to the
   recovery link.

6.2.  Address Configuration for Virtual Switch

   Each standby home agent obtains its individual IPv6 address from its
   attached link.  This IPv6 address is used by the home agent
   reliability protocol to exchange information with the associated home
   agents.  The link between home agents should be secured.

   The virtual home agent's IPv6 address which is known by the mobile
   node is shared with the standby home agents.  When a home agent
   fails, the standby home agent activates the IPv6 address of the
   failed home agent and becomes the active home agent.  The standby
   home agent should not activate the IPv6 address until it knows the
   active home agent is no longer reachable at the address, otherwise
   address duplication will occur.  To guarantee transparency of the
   home agent virtual switch to mobile nodes located on the home link,
   the neighbor cache of the home agent IP address MUST be carefully
   operated.  See Section 8.1 in detail.

6.3.  Address Configuration for Hard Switch

   Each standby home agent obtains its individual IPv6 address from its
   attached link.  This IPv6 address is used by the home agent
   reliability protocol to exchange information with the associated home
   agents.  The link between home agents should be secured.

   Each home agent configures itself with a different IPv6 address from
   the same home prefix.  This IPv6 address can be used for the Home
   Agent Reliability protocol if the standby home agents are located at
   the same link of the active home agent (Figure 10).  In case of
   Figure 11, the router must carefully route packets to the standby
   home agents as described in Section 8.1.  Once a mobile node
   registers its binding with the active home agent, it may solicit an
   IPsec/IKE exchange with standby home agents.  These packets must be
   routed to the recovery link.  This can be achieved by installing host
   routes for the standby home agents on the recovery link of the
   router.

7.  Home Agent Common Operation

7.1.  Home Agent List Management

   In Mobile IPv6 [RFC-3775], each home agent periodically sends router
   advertisements with the Home Address Information option [RFC-3775]
   when there are multiple home agents present on a link.  This
   information is managed in a home agent list.  For the Home Agent
   Reliability Protocol, HA-HELLO messages are used to manage the home
   agent list.  There are several reasons to use HA-HELLO message
   instead of Router Advertisement such as:

   1.  In the Home Agent Virtual Switch mode, if the standby home agents
       send unsolicited Router Advertisements to the home link, the
       mobile nodes attached to the home link are aware of the presence
       of standby home agents.  However, the standby home agents must be
       hidden until the active home agent fails.  HA-Hello messages are
       exchanged only between home agents.

   2.  As shown in Section 6.1, standby home agents are not always
       configured at the same link.  In this case, Router Advertisements
       cannot be sent to the recovery link unless the home link and the
       recovery link are connected (ex.  L2TP).  HA-HELLO can be sent
       beyond the link.

   3.  The Home Agent Reliability protocol is defined to manage
       additional information such as Group ID and Active/Standby Status
       of the home agents in the home agent list.

   In Mobile IPv6, Router Advertisement are to carry the home agent
   information to both mobile nodes on the home link and the home
   agents.  On the other hand, in the Home Agent Reliability protocol,
   HA-Hello is to exchange the information among the home agents and the
   Router Advertisement is used to notify the information to the mobile
   nodes on the home link.  The home agents SHOULD NOT process the Home
   Agent Information option carried by Router Advertisement if HA-HELLO
   is available.  Operators can define different values to the
   parameters of the home agent information for HA-HELLO and Router
   Advertisement.  The management operation of the home agent list is
   unchanged and defined in [RFC-3775].

7.2.  Detecting Home Agent Failure

   The active and standby home agents can monitor each other in several
   ways.  One method is to reuse other failure detection mechanisms
   defined in VRRP[RFC-3768] and HSRP [RFC-2281] (see Section 7.6).
   However, VRRP and HSRP cannot detect the case where the system is
   running but the Mobile IPv6 stack is not operational.  In the Home
   Agent Reliability protocol, a new message called HA-HELLO is
   periodically exchanged in the redundant home agent set as a heart-
   beat.  If HA-HELLO is implemented as a part of Mobile IPv6 stack, it
   can detect the home agent failure (Mobile IPv6 stack failure).  This
   HA-HELLO can also be exchanged frequently enough to detect the
   failure promptly and does not introduce any processing overhead to
   the mobile node attached to the home link.

   Failure events used in the Home Agent Reliability protocol are listed
   below.

   Loss of HA-HELLO

      In the event that a standby home agent does not receive any HA-
      HELLO from its peer which is currently the active home agent for a
      configurable duration, the standby home agent assumes the active
      home agent's failure.  Any home agents can also request the home
      agent information of the other home agent in the same redundant
      home agent set by sending HA-HELLO with R-flag set.  If HA-HELLO
      is not replied from the target home agent within a configurable
      amount of time, that home agent peer is considered to have failed.
      The detail of the Hello message is described in Section 7.3.

   Monitored Server Failure by the Active Home Agent

      There may be number of critical servers such as AAA server in the
      network that are essential for the ongoing Mobile IPv6 sessions at
      the home agent.  Operators can have a policy in place that the
      active home agent is treated as a failed home agent upon detecting
      that the link to such servers has failed.

   Routing Peer/Link Failure

      Operators may require the home agent to detect its next-hop
      routing peer failure.  If the next-hop routing failure is fatal in
      nature, or due to some other routing policies, the active home
      agent is treated as a failed home gent and the recovering
      operation should be started.

7.3.  Processing Hello Messages

   HA-HELLO MUST be either unicasted or multicasted.  A new multicast
   address (all_homeagent_multicast_address) will be assigned by the
   IANA.  When all the home agents in a redundant home agent set are
   configured on a same home link, they MUST join the
   all_homeagent_multicast_address.  On the other hand, if a home
   recovery link is separately defined as described in Figure 11, each
   home agent SHOULD unicast HA-HELLO.

7.3.1.  Requesting Hello Message

   A home agent can solicit HA-HELLO to a particular home agent in the
   same redundant home agent set by unicasting HA-HELLO with the R-flag
   set.  The sender MUST fill the fields of the HA-HELLO with its home
   agent information.  If a home agent needs to request HA-HELLO to all
   the home agents, it sends the HA-HELLO with R-flag set to the
   all_homeagent_multicast_address.  Requesting HA-HELLO SHOULD be
   operated when:

   1.  A new home agent needs to collect the information of all the
       other home agents in the same redundant home agent set.  The HA-
       HELLO with R-flag set is multicasted to
       all_homeagent_multicast_address.

   2.  A home agent entry in the redundant home agent list is about to
       be removed due to home agent lifetime expiration.  The HA-HELLO
       with R-flag set is unicasted to the home agent whose lifetime is
       soon expired.

   3.  HA-HELLO has not been received during the specified hello
       interval.  The HA-HELLO with R-flag set is unicasted to the
       target home agent.

7.3.2.  Sending Hello Message

   Each home agent periodically sends HA-HELLO for the home agent's
   failure detection.  The interval time is configured at each home
   agent.  Each home agent MUST also send a HA-HELLO in following case:

   1.  when a home agent receives a HA-HELLO with the R-flag set

   2.  When a home agent detects its local information such as home
       agent preference, home agent lifetime, and registration status
       change.

   3.  When a new home agent boots up, it SHOULD solicit Hello messages
       by multicasting a Hello message with the R-flag HARP.

   o  The M-flag MUST be set in parallel if the sender is operated with sending its own Hello message.

   When a VHARP.

   o  The A-flag MUST be set if the sender is the active home agent sends HA-HELLO, agent.

   Performed the following rule functions when a HARP message is received.

   o  MUST be applied. verify the Group ID of the HARP message is equal to the
      receiver's Group ID.

   o  Whenever a  MUST verify the sender of the HARP message belongs to the
      receiver's same redundant home agent generates HA-HELLO, it set

   o  MUST verify that the M flag is equal to the receiver's operating
      mode.

   o  MUST increment verify the Sequence Number.  The Number value in the HARP is larger than
      the last received Sequence Number SHOULD be initialized to
      zero for value.  When the first Hello message.  To accomplish sequence number
      rollover, if
      rollover is occurred, the sequence number has already been assigned to be
      the largest possible number representable as a 16-bit unsigned
      integer, then when it is incremented it will then have a value of
      zero (0).

   o  It MUST also specify its own Group ID in HA-HELLO.

   o  If a home agent the HA-HELLO is
      zero.

   If any one of the active home agent, it MUST set above checks fails, the A-flag
      in HA-HELLO.

   o  In receiver SHOULD discard the
   HARP message.

4.3.2.  Processing Home Agent Hard Switch mode, the source IPv6 address of HA-
      HELLO MUST be the Hello (HA-HELLO)

4.3.2.1.  Sending HA-Hello Message

   Each home agent address. MUST send a HA-HELLO in following case:

   o  In the Home Agent Virtual Switch mode, the  UNSOLICITED: Each home agent local
      address MUST be used.

7.3.3.  Receiving Hello Message SHOULD periodically send a HA-HELLO.
      The interval time is configured locally at each home agent.

   o  UNSOLICITED: When a home agent receives HA-HELLO, detects its local information
      change, it SHOULD verify the HA-HELLO as
   follows: should immediately send a HA-HELLO.

   o  If the  SOLICITED: when a home agent receives a HA-HELLO with the R-flag
      set.  When the R-flag is not protected by IPsec ESP, it SHOULD set, the HA-HELLO can be
      discarded.  Note that, only if requested to the
      destination home agent.

   A home agent can solicit a HA-HELLO is sent on to a dedicated
      link between particular home agent(s) in
   the same redundant home agents, IPsec protection might not be always
      required.  This depends on agent set by unicasting or multicasting a HA-
   HELLO with the operational policy.

   o  If R-flag set.  Soliciting HA-HELLO is sent from non global IPv6 address, it MUST be
      discarded. operated when:

   o  If  A new home agent boots up.  The new home agent SHOULD solicit HA-
      Hello messages by multicasting a HA-Hello message with the source IPv6 address of R-flag
      set.

   o  A HA-HELLO does has not belong been received after the specified hello
      interval.  The HA-HELLO MAY be solicited to one of the home agents agent.

   o  A home agent entry in the redundant home agent set, the HA-HELLO MUST
      be ignored.

   o  If the Group ID field of the received HA-HELLO and the receiver's
      Group ID set is different, HA-HELLO MUST about to be discarded.
      removed due to home agent lifetime expiration.  The HA-HELLO MUST
      NOT
      SHOULD be unicasted solicited to the home agents agent whose Group ID lifetime is different from soon
      expired.

   In addition to Section 4.3.1, the sender. following operations MUST be
   performed when transmitting a HA-HELLO.

   o  If the Sequence Number value in  The Type field MUST be set to 4.

   o  The R-flag MUST be set if the sender solicits a HA-HELLO is equal to or less
      than the last received Sequence Number value stored in the
      other home agent(s).

   o  The appropriate home agent list entry, the HA-HELLO configuration values MUST be discarded.  When copied to
      the
      sequence number rollover is occurred, Home Agent Preference, the sequence number value in Home Agent Lifetime, and Hello
      Interval fields.

4.3.2.2.  Receiving Hello Message

   The receiver MUST perform the verification to the HA-HELLO SHOULD be zero.

   o  HA-HELLO satisfying all of above tests MUST be processed by
      receiver.  The described
   in Section 4.3.1.  After the verification, the receiver copies home agent information the
   value stored in the HA-HELLO message to the corresponding home agent
   list entry.  The home agent
      address of the sender is retrieved from the Source Address field
      of the IPv6 header of the HA-HELLO.

   o entry according to Section 4.1.

   If the home agent lifetime field in the HA-HELLO is set to 0, the
   receiver removes MUST remove the sender home agent from the home agents list.

   o

   If the R-flag is set in the received HA-HELLO, the receiver MUST send
   a new HA-HELLO to the originator as described in Section 7.3.2.

7.4. 4.3.2.1.

4.3.3.  Processing State Synchronization Messages

   It is necessary for Home Agent Switch Over (SWO-REQ/REP)

   When a standby home agents agent decides to synchronize become an active home agent, the state
   information of each mobile node registered
   standby home agent sends a SwitchOver Request (SWO-REQ) to the
   current active home agent with the following operations.

   o  MUST be unicasted only to the current active home agent

   o  MUST be sent from a standby home agent.  In the Home  The active home Agent Hard Switch mode,
      MUST NOT generate this message.

   When an active home agent receives a SWO-REQ, it MUST operate the
   following verification and operations in addition to Section 4.3.1:

   o  If the receiver of the SWO-REQ is not necessary for an active home agent, it
      MUST send a SWO-REP with the Status field set to 130 (Not active
      home agent).

   o  If the sender home agent does not belong to the same redundant
      home agent set, a SWO-REP message MUST be sent to the sender with
      the Status field set to 132 (Not in same redundant home agent
      set).

   o  There is a case where the active home agents to synchronize the complete binding cache
   information.  The agent cannot be standby home
      agent.  The active home agent needs MUST reply a SWO-REP with the mapping information of Status
      field set to 129 (Administratively prohibited).

   o  Otherwise, the active home agent MUST become a standby home agent
      and reply with a SWO-REP message with the mobile node.  The information is used
   to send the Home Agent Switch messages Status field set to all the mobile node served
   by the failed home agent.

7.4.1.  Requesting State of a Particular Mobile Node(s) 0
      (Success).

   When a standby home agent needs the state information for a particular mobile
   node or receives a subset of mobile nodes, SWO-REP, it sends a SS-REQ message
   constructed as follows:

   o  It MUST set operate the Type field
   following verification and operations in addition to 0 (Request). Section 4.3.1:

   o  It MUST set a random value in  If the Identifier field that does not
      coincide with any other currently pending Requests.

   o  It MUST include an IP address mobility option(s) which subtype receiver is
      set to the an active home address if agent, the target is mobile node(s).

   o  It SWO-REP MUST include a Mobile Network Prefix mobility option(s) for
      mobile router(s). be
      discarded.

   o  It MUST set  If the unspecified address (::) standby home agent receives an unexpected SWO-REP which is
      not in reply to its SWO-REQ, it MUST ignore the Home Address
      mobility option SWO-REP.

   o  Otherwise, if it solicits the state Status field of all the mobile nodes
      and mobile routers registering at SWO-REP is 0 (Success), the
      standby home agent (the receiver of SS-REQ
      (i.e.destination of SS-REQ). SWO-REP) immediately becomes
      an active home agent.

   o  If the value in the Status field is greater than 128 an error has
      occurred.  In this case, the receiver MUST NOT attempt to be an
      active home agent.

4.3.4.  Processing Home Agent Virtual Switch, the sender of the SS-REQ MUST be
      a Switch Back (SWB-REQ/REP)

   When an active home agent local address of decides to become a standby home agent, it
   sends a SWB-REQ to one of standby home agents.  The reason for the
   active home agents in agent to send this message can be administrative
   intervention, and events like Monitored Server Failure by the same
      redundant active
   home agent set. or Routing Peer/Link Failure.  The following operations
   MUST be performed when SWB-REQ is sent.

   o  In the Home Agent Hard Switch, the sender of the SS-REQ  MUST be a
      home agent address of unicasted only to one of the standby home agents in the same
      redundant home agent set. set

   o  The destination of the SS-REQ  MUST be the sent from an active home agent for
      the requesting home address or mobile network prefix. agent.  The standby home agent Agent
      MUST NOT reply the SS-RREP to the sender. generate this message.

   When a home agent receives the SS-REQ, a SWB-REQ message, it MUST verify if SS-REQ is
   constructed with verifies the above rules. message
   as follows.

   o  If SS-REQ satisfy all the above
   tests, the receiver of the SS-REQ MUST reply SS-REP including the
   state information of the requested mobile node(s) and/or mobile
   network prefix(es) as described in Section Section 7.4.2.

7.4.2.  Synchronizing State

   State synchronization messages SHOULD be sent when:

   1.  The active home agent receives SS-REQ.

   2.  The active sender home agent creates a binding cache entry for a
       particular mobile node.

   3.  The of the SWB-REQ is not an active home agent deletes a binding cache entry for
      agent, the receiver MUST reply a
       particular mobile node.

   The SWB-REP with the Status field is
      set to 130 (Not active home agent MAY additionally send state synchronization
   message in following cases:

   1.  The active agent).

   o  If the sending home agent update the state information for all
       sessions that changed since does not belong to the last update in same redundant
      home agent set, a periodic
       interval

   2.  Only for SWB-REP MUST be sent in which the Home Agent Virtual Switch mode, Status field
      set to 132 (Not in same redundant home agent set).

   o  Otherwise, the active receiving home agent updates a binding cache entry for MUST send a particular mobile node
       whenever SWB-REP with the binding cache entry
      Status field is updated.  In set to 0 (Success).

   o  After sending the Home Agent
       Hard Switch mode, standby home agents only need SWB-REP, the mapping
       information of a standby home address of the mobile node/router and the agent MUST NOT become
      an active home agent address of immediately.  This is because the active home
      agent to which the mobile
       node/router is currently registering.  This mapping still active until it receives the SWB-REP which is used
      acknowledging the SWB-REQ.  The standby home agent SHOULD change
      to
       send a Home Agent Switch message.

   If an active at least after LINK_TRAVERSAL_TIME.

   When a home agent sends receives a State Synchronization message
   whenever SWB-REP message, it verifies the local state information changes, such message
   as a binding cache
   change, follows.

   o  If the number of standby home agent receives an unexpected SWB-REP which is
      not in reply to own SWB-REQ, it SHOULD ignore the State Synchronization messages sent can be
   quite large.

   All SWO-REP.

   o  If the state information Status field of the requested mobile nodes SWB-REP is stored in
   the SS-REP.  Following rules must be applied when 0 (Success), the active home
      agent constructs SS-REP. immediately becomes a standby home agent.  The sender home
      agent of SWB-REP becomes an active home agent after certain time,
      LINK_TRAVERSAL_TIME.

   o  If the SS-REP is sent value in response to the SS-REQ, Status field is greater than 128, the active receiver
      of SWB-REP (active home agent) cannot become a standby home agent
      and MUST copy the Identifier field of the continue to be an active home agent.

4.4.  State Synchronization

   A State Synchronization
      request (SS) message to the Identifier field format is defined in
   Section 6.1.2.  It can carry several state information about a mobile
   node by setting mobility options in the SS-REP.  Otherwise,
      it MUST set Mobility Options field.  The
   following list shows examples of the mobility options which can be
   specified in the state synchronization message.

   o  IPv6 Home Address (Binding Cache Option)

   o  Binding Cache Information (Binding Cache Option)

   o  NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC-
      3963])

   o  IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555])

   o  IPv4 Home Address (IPv4 Home Address Option [RFC-5555])

   o  Binding Identifier field to 0. (Binding Identifier Option [RFC-5648]

   o  AAA states (AAA Information Option)

   o  Miscellaneous states (Vendor Specific Mobility Option [RFC-5094])

   When the active a home agent stores need to send the state of multiple mobile nodes in
   a SS-REP, single state synchronization message (SS-REQ or SS-REP), a Binding
   Cache Information option is used as a separator.  For each mobile
   node, a Binding Cache Information option is placed first, followed by
   any other options such as AAA
      option.  When related to the mobile node if necessary.

   In HARP, since a mobile node will re-register to the next new active home
   agent after home agent fail-over, it is not necessary for the standby
   home agents to synchronize all the mobile nodes' state information.
   The standby home agent only need to collect the home address
   information of all the mobile nodes served by the active home agent.
   The information is used to send the Home Agent Switch messages to all
   the mobile node when the home agent failure is occurred.

   In VHARP, home agent fail-over is completed without mobile nodes'
   binding re-registration.  Therefore, standby home agents need to copy
   the complete state information of each mobile node registered with
   the active home agent.

4.4.1.  Binding Cache Information option Management

   In HARP, each standby home agent learns the partial binding cache
   information such as a pair of a home address and a mobile node's
   registering home agent address.  This information is reached stored somewhere
   in a standby home agent.

   In VHARP, a standby home agent ideally copies the State Synchronization message, it indicates the received binding
   cache information
      of a different and other mobile node.

   o  If node's information into the unspecified address
   appropriate database so that it can act as an active home agent as
   soon as it takes over the failed home agent.

4.4.2.  IP field and Security Descriptions of SS message

   A state synchronization message is found only unicasted.  The destination
   address MUST be one of home agents in the same Redundant Home Address mobility
      option carried with Agent
   set.  The source address MUST be set to the SS-REQ, sender's home agent
   address.  Note that, in VHARP, the active virtual home agent address MUST return
   NOT be set to the state source address.  IP address of all the active mobile nodes and mobile routers by interface the
      SS-REP.  The message may
   packet is being sent from SHOULD be fragemented depending on the total
      size needed to carry all states.

   o  A SS-REP MUST used.

   If a state synchronization message is unicasted, it SHOULD be
   authenticated by IPsec AH and MAY be encrypted by IPsec ESP.

   o  The destination and source  If all
   the home agents MUST belong are placed in a secure transport network to exchange
   the same
      redundant state synchronization message, authentication and encryption MAY
   be omitted.  If security verification is failed for a receiving state
   synchronization message, the message MUST be discarded.  Which
   security mechanism is used depend on the operational policy.

4.4.3.  Requesting State of Mobile Nodes (SS-REQ)

   When a home agent set. needs the state information for a particular mobile
   node or a subset of mobile nodes, it sends a SS-REQ message
   constructed as follows:

   o  In  MUST set the Home Agent Hard Switch, Type field to 0 (Request).

   o  MUST set a random value in the IPv6 source address Identifier field that does not
      coincide with any other currently pending Requests.

   o  MUST be include a Binding Cache Information option(s) which Home
      Address field is set to the target home agent address address.  Other fields of
      the sender. Binding Cache Information option can be omitted.

   o  In the Home Agent Virtual Switch, the IPv6 source address  MUST be set to the home agent local unspecified address (::) in the Home Address field of
      the sender.

   When a home agent receives a SS-REP, Binding Cache Information option, if it MUST verify whether the SS-
   REP is constructed with the above rules or not.  If solicits the SS-REP does
   not satisfy state of
      all the rules above, it is discarded.  Otherwise, mobile nodes registering at the
   following operation must be taken.

   o  The receiver destination home agent of SS-REP
      the SS-REQ message.

   o  MUST update its include multiple binding cache and all other
      necessary information such as AAA and vendor specific information options in a SS-
      REQ, if the particular database. sender requests multiple mobile nodes' information.
      The sender SHOULD NOT send multiple SS-REQs per mobile node.

   o  In the Home Agent Hard Switch mode, the receiver  MUST record the
      IPv6 address of the sender as send a SS-REQ to the active home agent of the target mobile
      node.

7.4.3.  Reliable Transmission by Explicit Acknowledgement

   Signaling messages of the Home Agent Reliability protocol are not
   guaranteed reliable transmission due to the Mobility Header use.
   This is not always critical, because the link between home agents is
   carefully managed as stable and reliable.  However, operators may
   need more explicit notification to confirm the message exchanges
   between home agents.  This specification provides an optional
   acknowledgment to SS-REP messages.

   If an active
      node(s).

   When a home agent requires an acknowledgment of SS-REP, receives a SS-REQ, it set MUST perform the verification
   described in Section 4.4.2 and following:

   o  If the receiver does not know the Ack flag binding cache for the target
      mobile node(s) specified in the SS-REP.  The receiver of such SS-REP will send
   back a SS-ACK.  The receiver received Binding Cache Information
      option(s), it MUST copy ignore the Identifier value received
   in SS-REQ and MUST NOT reply a SS-REQ.

   o  Otherwise, the receiver MUST reply a SS-REP into SS-ACK in order to match including all the
      state information of the target mobile node(s).

4.4.4.  Sending State Information (SS-REP)

   A SS-REP and SS-ACK.

7.5.  Processing Home Agent Control Messages

7.5.1.  Standby Home Agent becomes an Active Home Agent

   When a standby message(s) SHOULD be sent when:

   1.  The active home agent decides to become an receives a SS-REQ.

   2.  The active home agent, the
   standby home agent sends creates or deletes a SO-REQ to the binding cache entry
       for a particular mobile node.

   The active home agent.  This agent MAY additionally send a SS-REP message MUST be unicasted to the in
   following cases:

   1.  The active home agent and MUST be
   encrypted and authenticated by IPsec ESP.  The updates the state information for all
       sessions that changed since the last update in a periodic
       interval

   2.  Often in VHARP, the active home Agent MUST
   NOT generate this message.

   When agent MAY update a binding cache
       entry for a particular mobile node whenever the binding cache
       entry is updated.  If an active home agent receives sends a SO-REQ, it MUST operate SS-REP message
       whenever the
   following verification and operations:

   o  If local state information changes, such as a binding
       cache change, the SO-REQ is not protected by IPsec, it MUST number of the SS-REP messages can be discarded. quite
       large.

   Following rules must be applied when the active home agent constructs
   a SS-REP.

   o  If  MUST copy the Identifier field of the SS-REQ to the receiver same field of
      the SO-REQ SS-REP, if the SS-REP is not an active home agent, it MUST
      send a SO-REP with sent in response to the Status field SS-REQ.

   o  MUST set zero to 130 (Not active home
      agent).

   o  If the sender home agent does not belong to Identifier field if the same redundant
      home agent set, SS-REP is sent
      without solicitation (no SS-REQ).

   o  MUST include required mobility options in the SS-REP.

      *  In HARP, a SO-REP message partial Binding Cache Information Option (the Home
         Address Field only) MUST be sent to the sender with included in the Status field set to 132 (Not SS-REP.

      *  In VHARP, a full Binding Cache Information Option and other
         required options shown in same redundant home agent
      set). Section 6.1.2 MUST be included in the
         SS-REP.

   o  If  MUST include the state of all the receiver is an active home agent, there is case where mobile nodes registering
      in the active home agent cannot by the SS-REP when the unspecified
      address is found in the Home Address mobility option carried with
      the SS-REQ.  The message may be standby home agent.  In such case, fragmented depending on the
      active total
      size needed to carry all states.

4.4.5.  Synchronizing State (SS-REP and SS-ACK)

   When a home agent can reply receives a SO-REP with SS-REP, it MUST take the Status field set to
      129 (Administratively prohibited). following
   operations.

   o  Otherwise,  If no options are carried in the SS-REP, the active home agent MUST become a standby home agent
      ignore the SS-REP and reply with a SO-REP message MUST send SS-ACK with the Status field
      Synchronization Status option which status value is set to 0
      (Success).

   The SO-REP MUST be also protected by IPsec ESP.  Otherwise, the
   message MUST be silently discarded.  If the receiver of SO-REP did
   not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST
   be ignored. [131:
      No Mobility Option]

   o  If the Status field sender of the SwitchOver Reply message SS-REP is 0
   (Success), not in the receiving standby same global home agent immediately becomes an
   active set,
      the home agent as described in Section 8.2.  If MUST reject the value in SS-REP and MUST send SS-ACK with
      the Status field Synchronization Status option which status value is greater than 128 an error has occurred.  In this
   case, the receiver MUST NOT attempt set
      to be an active home agent.

7.5.2.  Active Home Agent becomes inactive

   When an active [130: Not in same global home agent decides to become a standby home agent, it
   sends a SB-REQ to one of standby home agent. set]

   o  The reason for the
   active receiver home agent to send this message can be administrative
   intervention, and events like Monitored Server Failure by MUST record the IPv6 address of the sender
      as the active home agent or Routing Peer/Link Failure.  This message MUST be
   unicasted to one of the standby mobile node in its local binding
      cache.

   o  The receiver home agents and agent MUST be encrypted update its binding cache and
   authenticated by IPsec ESP.  A standby all
      other necessary information in a particular database(s).

   o  The receiver home agent MUST NOT generate
   this message.

   When send a SS-ACK with state
      synchronization status mobility options if A flag is set.

   If an active home agent receives requires an acknowledgment of a SwitchBack Request message, SS-REP, it first
   verifies
   MUST set the message.

   o  If Ack flag in the SwitchBack Request message is not protected by IPsec ESP,
      it SS-REP.  The receiver of such SS-REP
   will send back a SS-ACK.  The receiver MUST be discarded.

   o  If copy the Identifier value
   received in the SS-REP into SS-ACK in order to match the SS-REP and
   SS-ACK.

4.5.  Switching the Active Home Agent

   In HARP, the sender standby home agent of the SB-REQ which is not an going to be active home
      agent, the receiver MUST reply send
   a SB-REP with the Status field is
      set Home Agent Switch message [RFC-5142] to 130 (Not active home agent).

   o  If all the sending home agent does not belong to mobile nodes that
   were being served by the same redundant failed home agent set, a SB-REP agent.  The following rules MUST
   be sent in which applied when transmitting a Home Agent Switch message.

   o  MUST use IPsec ESP to the Status field Home Agent Switch message.

   o  MUST set to 132 (Not in same redundant only that standby home agent set).

   o  Otherwise, address in the receiving home agent MUST send Home Agent
      Switch message

   If there are a SB-REP with large number of mobile nodes served by the
      Status field is set to 0 (Success).

   After failed home
   agent, the overhead sending Home Agent Switch messages is high.  This
   overhead cannot be avoided if the SwitchBack reply, it MUST NOT become an active home agent immediately.  This is suddenly stop
   serving mobile node because of unexpected reasons (crash, network
   trouble, etc).  However, if this switch over is operated under the
   administrative operation (maintenance, etc), the previous active home
   agent is still
   active may continue serving the mobile nodes until it receives the SB-REP which switch over is acknowledging
   completed.  Until the SB-
   REQ.  The standby home agent SHOULD change mobile node sends a binding update to the new
   active at least after
   LINK_TRAVERSAL_TIME.

   If a home agent receives a SB-REP, agent, it MUST be protected by IPsec ESP,
   otherwise the message MUST be silently discarded.  If still sends the receiving
   home agent did not send a SB-REQ matched packet to the received SB-REP, previous home
   agent.

   Therefore, the
   message MUST be silently discarded.  If new active home agent can notify the Status field completion of
   switch-over to the SB-
   REP is 0 (Success), the previous active home agent immediately becomes by using a
   standby home agent.  The sender home agent of SB-REP becomes SW-COMP
   message.  When the new active home agent as described in Section 8.2.  If the value in the Status
   field is greater than 128, completes the receiver of SB-REP (active home agent)
   cannot become switch-over,
   it SHOULD send a standby home agent and MUST continue SW-COMP to be an the previous active home agent.

7.6.  Interworking with VRRP

   VRRP and HSRP specify an election protocol that dynamically assigns
   responsibility for a virtual router to one of the VRRP routers on a
   LAN.  This operation is similar to the Home Agent Virtual Switch
   operation.  For example, the VRRP router controlling  Until
   the IP
   address(es) associated previous home agent receives this message, it SHOULD continue
   serving any mobile nodes that are registered 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 it.  Once the Master become unavailable.  Although VRRP is used to
   guarantee
   previous home agent address reachability, receives the SW-COMP message, it cannot can be used for
   state synchronization and explicit switching of Master and Backup.
   Thus, shutdown
   or detached from the Home Agent Reliability protocol cannot be replaced by VRRP.
   This section explains how VRRP can interwork with network safely.

   In VHARP, after detecting the Home Agent
   Reliability protocol.

   When VRRP is available, VRRP can replace active home agent has failed, the Hello message described
   in Section 5.1.3.  However, some of information
   standby home agent whose preference value is missed by using
   VRRP.  After receiving a VRRP message, each the highest MUST take
   over the failed home agent.  The standby home agent SHOULD process MUST activate the message and store
   virtual home agent address.  If a virtual MAC address as introduced
   in [RFC-3768, RFC-5798] is used, the information standby home agent MUST start
   using that virtual MAC address as if it receives Home Agent
   Hello messages Section 7.3.3.  The Home Agents SHOULD still perform
   binding cache synchronization well.  If VHARP run with VRRP and
   HSRP as described in Section 7.4 and SHOULD
   support 4.7, the Home Agent Switch message virtual home agent address can
   be treated as described a virtual router address in Section 9.2.

   In addition to this, VRRP is useful only if all and HSRP.  Therefore,
   VRRP and HSRP can automatically activate the virtual home agents are
   located agent
   address on the same link.  If standby home agent after their election mechanism.
   Since all the necessary state has already been transferred to this
   standby home agents are topologically
   separated, agent before the Home Agent Reliability protocol active home agent failed, it can
   immediately start acting as the active home agent.

   When the failed home agent recovers from failure and would return to
   the active home agent, it MUST be used.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Type  | Virtual Rtr ID|   Priority    |Count IPv6 Addr|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |(rsvd) |       Adver Int       |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                       IPv6 Address(es)                        |
       +                                                               +
       +                                                               +
       +                                                               +
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 12: VRRP Packet Format

   The message format of VRRP is described in Figure 12.  Each field re-establish IPsec SA with all the
   mobile nodes.  All the mobile nodes lost IPsec SA with the home agent
   when the failure is
   mapped occurred.  Otherwise, it cannot be either a
   standby or active home agent for the mobile nodes.  Therefore, as follows:

   Virtual Rtr ID

      Group ID is stored
   soon as the active home agent detects the recovery of the failed home
   agent, it sends a Home Agent Rekey message to all the mobile nodes
   served by other home agents in the Virtual Rtr ID same redundant home agent set, and
   includes the recovered home agent address in the Home Agent Addresses
   field.

   Priority  The detail of the Home Agent Preference Rekey message is stored described in
   Section 6.1.3.  The mobile node will re-key the Priority field.  Note that
      VRRP only has 8 bits for SA by using The IKEv2
   resumption mechanism [RFC-5723].  Alternatively, the Priority field.  Therefore, values
      larger than 255 MUST NOT be assigned to mobile node MAY
   start a new IKE session with the preference value.

   Count IPv6 IPv6 Addr

      This field MUST be always be 1.

   Advert Int recovered home agent.

4.6.  Consideration of Routing and Neighbor Discovery Protocol (VHARP)

   This field section gives a brief explanation of how a home agent interacts
   with routing and Neighbor Discovery Protocol (NDP) when is VHARP
   used.

   When a standby home agent becomes active in VHARP, it MUST be mapped start to
   advertise the home agent address and the home prefix of the home
   addresses serviced by the redundant home agent set into the routing
   infrastructure.  This operation is normally done using a route
   selector such as BGP or an OSPF modifier.  For example, we can use
   the AS_Path prepend operation for BGP, and the Hello Interval Metric field of in OSPF
   for the Home
      Agent Hello message, though it only has 12 bytes.

   IPv6 address

      A route selection.  When each home agent address is stored in this field.

   Home Agent Lifetime, Sequence Number and Flags field are missing participates in
   the VRRP packet format.  Therefore, operators SHOULD use the same
   statically configured value for Home Agent Lifetime.  Each OSPF
   routing, each home agent
   does not check freshness of received VRRP message because of no
   sequence number.  If VRRP is used, a should be configured with the appropriate
   metric matched to the home agent cannot determine preference value.  When the active
   home agent from fails, OSPF detects the VRRP message due to lack of A flag, failure and
   cannot request a VRRP advertisement can dynamically switch
   the route to other home agents.

7.7.  Retransmissions and Rate Limiting

   Standby and active the standby home agents are responsible for retransmissions
   and rate limiting of a SS-REQ, SO-REQ, SB-REQ messages for which they
   expect a response.  The Agent based on the OSPF cost value.  If
   this creates conflicts with the home agent MUST determine a preference value for due to
   configuration errors, the
   initial transmission timer:

   o  If routers on the home agent sends a SS-REQ message, it SHOULD use an initial
      retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.

   o  If a link may not route
   packets to the desired standby home agent sends a SO-REQ message, it SHOULD use an
      initial retransmission interval agent.  In order to change the
   OSPF cost correctly and dynamically, The operator takes other
   existing approaches.  For example, most of INITIAL_SWICHOVER_REQ_TIMER.

   o  If router vendors have a
   private MIB to set the cost via SNMP, though this is a vendor-
   specific function.

   When an active home agent sends a SB-REQ message, activates a home agent address, it SHOULD
   use an
      initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER .

   If a virtual MAC address as introduced in [RFC-3768, RFC-5798].
   When the sending active home agent fails to receive a valid matching response
   within is changed, the selected initial retransmission interval, it SHOULD
   retransmit neighbor cache of the message until a response
   active home agent is received.  All of not necessarily updated on mobile nodes located
   on the
   above constants are specified in Section 11.

   The retransmission MUST use an exponential backoff process as
   described in [RFC-3775] until either home link.  Otherwise, the new home agent receives a
   response, or MUST update the timeout period reaches
   neighbor cache entry for the value
   MAC_HARELIABILITY_TIMEOUT (16sec).  The home agent SHOULD use a
   separate back-off process address on all the mobile
   nodes located on the home link.  In addition, Mobile IPv6 uses proxy
   NDP to intercept packets meant for different message types mobile nodes which are away from
   the home link.  However, it is unnecessary for the new active home
   agent to overwrite the existing proxy neighbor entries of the mobile
   nodes.

4.7.  Interworking with VRRP

   VRRP and different
   destinations.  The rate limiting HSRP specify an election protocol that dynamically assigns
   responsibility for a virtual router to one of Mobility Header messages the VRRP routers on a
   LAN.  This operation is similar to the
   same as one VHARP.  For example, 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 [RFC-3775].  A home agent MUST NOT send Mobility
   Header Messages the
   forwarding responsibility should the Master become unavailable.
   Although VRRP is used to a particular guarantee home agent more than MAX_UPDATE_RATE
   (3) times a second, which is specified in [RFC-3775].

8.  Home Agent Virtual Switch

8.1.  Consideration address reachability,
   it cannot be used for state synchronization and explicit switching of Routing
   Master and Neighbor Discovery Protocol Backup.  Thus, the Home Agent Reliability protocol cannot
   be replaced by VRRP.  This section gives a brief explanation of explains how VRRP can interwork
   with HARP/VHARP.

   When VRRP is available, VRRP can replace the Hello message described
   in Section 6.1.1.  However, some of information is missed by using
   VRRP.  After receiving a VRRP message, each home agent interacts
   with routing SHOULD process
   the message and Neighbor Discovery Protocol (NDP) when store the information as if it receives Home Agent
   Hello messages Section 4.3.2.2.  The message format of VRRP can be
   found in Section 5.1 of [RFC-5798].  Each field is mapped as follows:

   o  Virtual Switch mode Rtr ID: Group ID is used.

   When a standby home agent becomes active stored in the Virtual Rtr ID field.

   o  Priority: Home Agent Virtual
   Switch mode, it Preference is stored in the Priority field.
      Note that VRRP only has 8 bits for the Priority field.  Therefore,
      values larger than 255 MUST start NOT be assigned to advertise the home agent address and preference
      value.

   o  Count IPv6 IPv6 Addr: This field MUST be always be 1.

   o  Max Advert Int: This field MUST be mapped to the home prefix Hello Interval
      field of the home addresses serviced by the redundant home
   agent set into the routing infrastructure.  This operation is
   normally done using a route selector such as BGP or an OSPF modifier.
   For example, we can use the AS_Path prepend operation for BGP, Home Agent Hello message, though it only has 12
      bytes.

   o  IPv6 address: A home agent address is stored in this field.

   Home Agent Lifetime, Sequence Number and
   the Metric Flags field are missed in OSPF for
   the route selection.  When each VRRP packet format.  Therefore, operators SHOULD use the same
   statically configured value for Home Agent Lifetime.  Each home agent participates in OSPF routing, each
   does not check freshness of received VRRP message because of no
   sequence number.

4.8.  Retransmissions and Rate Limiting

   Home agents are responsible for retransmissions and rate limiting of
   SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response.
   The home agent should be
   configured with MUST determine a value for the appropriate metric matched to initial transmission
   timer:

   o  If the home agent
   preference value.  When the active sends a SS-REQ message, it SHOULD use an initial
      retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.

   o  If a home agent fails, OSPF detects the
   failure and can dynamically switch the route to the standby home
   Agent based on the OSPF cost value. sends a SWO-REQ or SWB-REQ message, it SHOULD use
      an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER.

   If this creates conflicts with the sending home agent preference value due to configuration errors, the
   routers on the home link may not route packets fails to receive a valid matching response
   within the desired standby
   home agent.  In order to change selected initial retransmission interval, it SHOULD
   retransmit the OSPF cost correctly and
   dynamically, The operator takes other existing approaches.  For
   example, most of router vendors have message until a private MIB to set the cost
   via SNMP, though this response is a vendor-specific function.

   When received.  All of the
   above constants are specified in Section 8.

   The retransmission MUST use an active exponential backoff process as
   described in [RFC-3775] until either the home agent activates receives a
   response, or the timeout period reaches the value
   MAC_HARELIABILITY_TIMEOUT.  The home agent address, it SHOULD use a virtual MAC address separate
   back-off process for different message types and different
   destinations.  The rate limiting of Mobility Header messages is the
   same as introduced one in [RFC-3768].  When the
   active [RFC-3775].  A home agent MUST NOT send Mobility
   Header Messages to a particular home agent more than MAX_UPDATE_RATE
   (3) times a second, which is changed, specified in [RFC-3775].

5.  Mobile Node Operation

   This section describes the neighbor cache operations of a mobile node only when HARP
   is used.  Non of operations in this section is required in VHARP.

5.1.  Home Agent Addresses Discovery

   A mobile node authenticates itself to two or more home agents and
   creates IPsec SAs with them during bootstrapping.  When the active
   home agent is not necessarily updated on mobile nodes located on the fails, another home
   link.  Otherwise, agent can use the new pre-existing SA to
   notify the mobile node about the failure by sending a Home Agent
   Switch message.

   In order to discover multiple home agent MUST update addresses, two different
   mechanisms are defined in the neighbor cache
   entry for bootstrapping solution in the split
   scenario [RFC-5026].  One is DNS lookup by home agent address on all Name, the mobile nodes located on other
   is DNS lookup by Service Name.  DHCPv6 can also be used in the
   integrated scenario [ID-BOOTINT] to provide home link.  In addition, Mobile IPv6 uses proxy NDP agent provisioning
   to intercept
   packets meant for mobile nodes which are away from nodes.

   In the split scenario, a mobile node can use DNS lookup by Service
   Name to discover the home link.
   However, it agents, as defined in [RFC-5026].  For
   example, if home agent reliability is unnecessary required by a mobile node, DNS
   lookup by Service Name method is recommended for the new active home agent mobile node to overwrite
   the existing proxy neighbor entries of the
   discover multiple home agents addresses.  Therefore, mobile nodes.

8.2.  Home Agent Recovery

   After detecting nodes
   will query the active DNS SRV records with a service name of mip6 and
   protocol name of ipv6.  The DNS SRV records includes multiple home
   agent has failed, addresses and different preference values and weights.  The
   mobile node SHOULD choose two or more home agents from the standby home
   agent whose
   agents list according to their preference value is the highest MUST take over value.  Then the failed
   home agent.  The standby mobile
   node should authenticate itself to these home agent MUST activate agents via an IKEv2
   exchange.

   In the virtual integrated scenario, a mobile node can use DHCPv6 to get home
   agent address.  If a virtual MAC address provisioning from an MSP or ASP, as introduced already defined in [RFC-3768] [ID-
   BOOTINT].  The only requirement is used, the standby home agent MUST start using that virtual MAC
   address as well.  Since all the necessary state has already been
   transferred to this standby DHCPv6 response must
   include multiple home agent before the active agents' information in order to support home
   agent
   failed, it can immediately start acting as the active home agent.

9.  Home Agent Hard Switch

9.1. reliability.

5.2.  IPsec/IKE Establishment to Home Agent Recovery

   After detecting the active home agent has failed, the standby Agents

   In this document, a mobile node need to manage an IPsec SA with a
   home
   agent whose preference value is the highest MUST take over agent(s).  The following mechanism can be used to manage the failed
   IPsec SA(s) with a home agent.  The standby agent(s).

   o  IKEv1/v2 running per home agent MUST send a Home Agent Switch
   message (HARP) to all the mobile nodes that were registered at establish multiple IPsec
      SAs for home agents.

   o  The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA
      with the failed new home agent as described (VHARP)

   If IPsec/IKEv2 state synchronization mechanism is available in Section 9.2, using
   Virtual Private Network (VPN) products, none of above is required for
   the pre-established VHARP operation.  The IPsec SA. SAs per mobile node are seamlessly
   copied among multiple home agents.

   The standby Home Agent mobile node MUST set its own address in follow the
   Home Agent Address field standard IKEv2 exchange in the Home Agent Switch message so that it
   will receive
   bootstrapping solution of the binding update from split scenario [RFC-5026].  If multiple
   IKEv2 are run per home agent, the mobile node as an
   acknowledgement of MUST NOT attempt the sent Home Agent Switch message.  The
   home
   agent switch-over is complete when address assignment to standby home agents.

5.3.  Synchronizing State: K-bit treatment

   When a mobile node moves and the care-of address changes, it receives binding updates from
   all can use
   the mobile nodes.  It is important to remark that sending Home
   Agent Switch messages to all Key Management Mobility Capability (K) bit in the mobile nodes at once may bring non-
   negligible overhead Binding Update
   in order to update the home agent.

   This overhead cannot be avoided if peer endpoint of the key management protocol
   (ex.  IKE Security Association).

   If an active home agent suddenly
   stop serving mobile node because of unexpected reasons (crash,
   network trouble, etc).  However, if this switch over receives a Binding Update which K-bit is operated
   under set,
   it MUST proceed the administrative operation (maintenance, etc), Binding Update as [RFC-3775].  In addition, the previous
   active home agent may continue serving the mobile nodes until the
   switch over is completed.  Until MUST notify the mobile node sends a binding
   update care-of address change to the new active other
   standby home agent, agents.  For doing so, it still sends MUST send State
   Synchronization Reply message including Binding Cache Information
   option to all the packet other standby home agents.  The flags of the
   Binding Update (ex.  K-bit) MUST be copied to the
   previous flags field of the
   Binding Cache Information option.  After all, the standby home agent agents
   know the existence of K-bit set in the Home Agent Hard Switch.  Therefore, Flag field of the
   new Binding
   Cache Information option and update the peer endpoint of the key
   management protocol.

   If the K-bit is not set in the Binding Update, an active home agent can notify the completion of switch-over
   needs to rerun the
   previous key management protocol.  The active home agent by using Home Agent Control message as
   described in Section 9.4.  As soon as this
   MUST send State Synchronization Reply message is received, including Binding Cache
   Information option to all the
   previous active other standby home agent can be shutdown or detached from agents.  K-bit is
   unset in the
   network safely.

9.2.  Sending Home Agent Switch Messages flags field of the Binding Cache Information option.
   The receivers of the State Synchronization Reply message (i.e.
   standby home agent which is going to be active MUST send a agents) detect the care-of address change and rerun the
   key management protocol.

5.4.  Receiving Home Agent Switch message as defined in [RFC-5142] to all the

   A mobile nodes
   that were being served by node must follow the failed home agent. verification and operations specified
   in [RFC-5142] when it receives a Home Agent Switch message.

   The Home Agent Switch message must MUST be securely sent to the exchanged between a
   mobile node and a home agent by using IPsec ESP.  The

   When the mobile node receives a Home Agent Switch message, and if the
   message contains the IPv6 address of a standby home agent agent, it MUST include only
   select the standby home agent as its own active home agent and MUST send
   a new Binding Update message to it.

   The standby home agent address in the Home Agent Switch message.  If there are a large
   number of mobile nodes served by message MUST
   be equal to the failed home agent, sender of the overhead
   sending Home Agent Switch messages message.  If the IPv6
   address stored in the Home agent address field is high.  Until a different from the
   sender's source IPv6 address, the mobile node
   receives this MUST send a binding
   update to the sender and MUST NOT use the IPv6 address in the Home
   Agent Switch messages, message.

6.  Messages Format

6.1.  New Mobility Header Messages

6.1.1.  HARP Message Format

   The HARP message has the mobile node's
   communication type field to identify different roles.  The
   HARP message has the MH Type value TBD.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |     Type      |   Group ID    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Sequence #           |A|R|V|M|Rsvd   |   Status      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Home Agent Preference    |      Home Agent Lifetime      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Hello Interval         |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                                                               |
       .                        Mobility Options                       .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: Home Agent Hello Message

   Type

      8-bit unsigned integer.  It can be assigned one of the following
      values:

         0: SwitchOver Request (SWO-REQ)

         It is discontinued.  Therefore, until the unicasted by a standby home agent completes sending that desires to become
         the active home agent.  The receiver of the Home Agent Switch message MUST
         transition to all standby state as soon as the
   mobile nodes message is received
         and receives Binding Updates from all the mobile node,
   the failed home agent SHOULD serve mobile nodes if possible.  This validated successfully.

         1: SwitchOver Reply (SWO-REP)
         It is used to acknowledge the case when receipt of the active home agent corresponding SWO-
         REQ.

         2: SwitchBack Request (SWB-REQ)

         It is replaced unicasted by administrative
   operation with the Home Agent Control messages as described in
   Section 9.4.

9.3.  Sending Home Agent Rekey Messages

   When a failed home agent recovers, it MUST re-establish an IPsec SA
   with each mobile node served by its redundant active home agent set.
   Otherwise, it cannot be either that desires to become
         a standby or active home agent for the
   mobile nodes.  Therefore, agent.  The receiver of this message SHOULD
         transition to active state as soon as the active home agent detects message is received
         and validated successfully.

         3: SwitchBack Reply (SWB-REP)

         It is used to acknowledge the recovery receipt of the failed home agent, it sends a Home Agent Rekey corresponding SWB-
         REQ.

         4: Switch Complete (SW-COMP)

         This message is used to indicate the completion of switch over,
         (i.e. sending home agent switch messages and receiving binding
         update messages from all the mobile nodes served by other mobile nodes).

         4: Home Agent HELLO (HA-HELLO)

         It MUST be either unicasted or multicasted to carry home agents in agent
         information among the
   same redundant home agent set, set.  The HA-Hello
         message is defined for two purpose: 1) an alive check and includes the recovered 2)
         home agent information exchange.

   Group Identifier

      8-bit unsigned integer.  This value is used to identify a
      particular redundant home agent
   address in the Home Agent Addresses field. set.

   Sequence #

      16-bit unsigned integer.  The mobile node will re-
   key the SA.

9.4.  Notification Sequence number of the HA-Hello
      message can be used to verify whether this Hello message is the
      latest one or not.

   (A)ctive flag

      Active Home Agent Switch Completion flag.  If this flag is set, the new sender of this
      HA-Hello message is an active home agent completes agent.

   (R)equest flag
      HA-HELLO requesting flag.  If this flag is set, the switch-over as described
   in Section 8.2, it SHOULD receiver of
      this HA-Hello message must send back a SW-COMP HA-Hello message to the previous active home
   agent in the Home Agent Hard Switch case.  Until the previous
      sender.

   (V)HARP capability flag

      VHARP capability Flag.  If a home agent receives this message, is capable of IPsec/IKE
      state synchronization, it SHOULD continue serving any mobile
   nodes that are registered with it.  Once the previous MUST set this flag.

   (M)ode flag

      A home agent
   receives MUST set this flag only when VHARP is used in the SW-COMP message, it can stop home agent services.

9.5.  Mobile Node Operation

9.5.1.  Home Agent Addresses Discovery

   In
      current operation.  If the Home Agent Hard Switch mode, a mobile node authenticates
   itself to two or more home agents and creates IPsec SAs with them
   during bootstrapping.  When flag is unset, the active home agent fails, another home agent can use the pre-existing SA currently
      operates HARP.  (HARP:0, VHARP:1)

   Reserved

      This field is unused.  It MUST be initialized to notify the mobile node about zero by the
   failure
      sender and MUST be ignored by sending a Home Agent Switch message.

   In order to discover multiple home agent addresses, two different
   mechanisms are defined in the bootstrapping solution in receiver.

   Status

      8-bit unsigned integer indicating the split
   scenario [RFC-5026].  One disposition of a SWO-REQ or
      SWB-REQ.  This field is DNS lookup by only valid in SWO-REP and SWB-REP.  The
      following Status values are defined:

         0: Success

         128: Reason unspecified

         129: Administratively prohibited

         130: Not active home agent Name, the other (The receiver of SWO-REQ is DNS lookup by Service Name.  DHCPv6 can also be used in not the
   integrated scenario [ID-BOOTINT] to provide
         active home agent)

         131: Not standby home agent provisioning
   to mobile nodes.

   In the split scenario, a mobile node can use DNS lookup by Service
   Name to discover (The receiver of SWB-REQ is already
         the active home agents, as defined agent)

         132: Not in [RFC-5026].  For
   example, if same redundant home agent reliability is required by a mobile node, DNS
   lookup by Service Name method is recommended set

   Home Agent Preference

      16-bit unsigned integer.  The preference for the mobile node to
   discover multiple home agents addresses.  Therefore, mobile nodes
   will query agent
      sending the DNS SRV records with a service name of mip6 and
   protocol name HA-Hello message.  This preference is the same as the
      Home Agent Preference value of ipv6.  The DNS SRV records includes multiple home
   agent addresses and the Home Agent Information option
      as defined in [RFC-3775].  However, operators MAY use a different
      preference values and weights. value for this operation.

   Home Agent Lifetime

      16-bit unsigned integer.  The
   mobile node SHOULD choose two or more home agents from lifetime for the home
   agents list according to their preference value.  Then agent sending
      the mobile
   node should authenticate itself to these home agents via an IKEv2
   exchange.

   In HA-Hello message.  This lifetime is the integrated scenario, a mobile node can use DHCPv6 to get home
   agent provisioning from an MSP or ASP, same as the Home Agent
      Lifetime value of the Home Agent Information option as already defined in [ID-
   BOOTINT].
      [RFC-3775].

   Hello Interval

      16-bit unsigned integer.  The only requirement is that interval for the DHCPv6 response must
   include multiple home agents' information agent sending
      this Hello message.

   Mobility Options

      No valid options are defined in order this specification.

6.1.2.  State Synchronization Message Format

   This message is used to support home
   agent reliability.

9.5.2.  IKE/IPsec pre-establishment exchange state corresponding to Home Agents

   After a particular
   mobile node obtains multiple home agent addresses, it needs
   to trigger multiple IKE exchanges with the multiple home agents
   selected from the home agent list.  Since both IKEv1 and IKEv2 can be
   used to bootstrap Mobile IPv6, this solution does not introduce any
   new operations to co-operate with IKEv1 or IKEv2. node(s).  It should initiate
   IKE for home agents as soon as home registration is complete.

   The mobile node MUST follow the standard IKEv2 exchange in be unicasted and MUST be authenticated by
   IPsec ESP.  This message has the
   bootstrapping solution MH Type value TBD.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |     Type      |A|   Reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identifier            |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: State Synchronization Message

   Type

      8-bit unsigned integer.  It can be assigned one of the split scenario [RFC-5026].  Home
   Address configuration maybe also be included, if necessary, for following
      values:

         0: State Synchronization Request (SS-REQ)
         It is used to solicit the
   first IKE exchange.  After its Home Address active state corresponding to a
         particular mobile node.

         1: State Synchronization Reply (SS-REP)

         It is assigned or approved
   by used between the first home agent, mobile node SHOULD register itself with agents in the
   second redundant home agent with IKE using the same Home Address.  Therefore,
   no home address configuration should be used in the second IKEv2
   procedure.  Note that
         set to exchange binding cache information and any other
         information related to providing mobility service to the mobile node only sends
         nodes either periodically or in response to a Binding Update SS-REQ.

         2: State Synchronization Reply-Ack (SS-ACK)

         This message to is optional and is specially used when the first links
         between home agent.

9.5.3.  Synchronizing State: K-bit treatment

   When a mobile node moves and agents are not reliable.

   (A)ck flag

      This flag is valid only for SS-REP.  If the care-of address changes, sender requires
      explicit acknowledgment by SS-ACK, it can use MUST set this flag.

   Reserved

      This field is unused.  It MUST be initialized to zero by the Key Management Mobility Capability (K) bit in
      sender and MUST be ignored by the Binding Update receiver.

   Identifier

      A 16-bit identifier to aid in order matching state synchronization
      message.  The identifier should never be set to update the peer endpoint 0.  It should
      always be more than 1.

   Mobility Options

      Variable-length field of such length that the key management protocol
   (ex.  IKE Security Association).

   If an active home agent receives a Binding Update which K-bit complete Mobility
      Header is set,
   it MUST proceed the Binding Update as an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in [RFC-3775].  In addition, the
   active home agent  The
      receiver MUST notify the care-of address change to the other
   standby home agents.  For doing so, ignore and skip any options which it MUST send State
   Synchronization Reply does not
      understand.  This message including requires at least one mobility option,
      therefore, there is no default length for this message.

      Binding Cache Information
   option to all the other standby home agents.  The flags of the
   Binding Update (ex.  K-bit) MUST Option is mandatory in SS-REQ message.
      Multiple options can be copied to the flags field of the
   Binding Cache Information option.  After all, stored in the standby same SS-REQ message.  A home agents
   know
      agent includes the existence of K-bit set mobile node's home address in the Flag field of the Binding Cache
      Information option and update the peer endpoint of the key
   management protocol. Option.  If the K-bit is not set in the Binding Update, an active a home agent
   needs wants to rerun solicit all the key management protocol.  The
      active home agent
   MUST send State Synchronization Reply message including mobile nodes' states, it can include the unspecified
      address (::) in an IPv6 address option.

      Binding Cache Information option to all the other standby home agents.  K-bit Option is
   unset mandatory in the flags field SS-REP.  SS-REP
      can carry any of the Binding Cache Information option. mobility options.  The receivers of the State Synchronization Reply message (i.e.
   standby home agents) detect the care-of address change and rerun the
   key management protocol.

9.5.4.  Receiving Home Agent Switch message

   A mobile node must follow the operation specified in [RFC-5142] when
   it receives a following options are just
      examples.

      *  AAA Information Option

      *  Vendor Specific Mobility Option [RFC-5094]

      *  Mobile Network Prefix Option [RFC-3963]

      *  IPv4 Care-of Address Option [RFC-5555]

      *  IPv4 Home Agent Switch message.

   When the mobile node receives a Address Option [RFC-5555]

      *  Binding Identifier Option [RFC-5648]

6.1.3.  Home Agent Switch message, and if the Rekey Message

   This message contains is used to indicate that the IPv6 address of a standby home agent, it MUST
   select mobile node SHOULD start an
   IPsec re-key with the standby home agent specified in the switch Home Agent
   Addresses field.  This message as the active is used when a failed home agent
   recovers and send needs to re-establish IPsec SA/IKE state with a new Binding Update mobile
   node.  This message MUST be unicasted to it.  Note that a mobile node by the standby active
   home agent address in the Home Agent Switch and MUST be equal
   to the sender of the Home Agent Switch message. authenticated and encrypted by IPsec ESP.  The standby Home
   agent expects the Binding Update as an acknowledgment of the
   Home Agent Switch message.  The mobile node already Rekey message has a pre-established
   SA with the standby home agents and should use that SA to send the
   Binding Update. MH Type value TBD.  If the address stored no options
   are present in the Home agent address
   field this message, no padding is different from the sender, necessary and the mobile node MUST send a
   binding update Header
   Len field will be set to the sender.

9.5.5.  Receiving 2.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      .                      Home Agent Addresses                     .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                        Mobility options                       .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 8: Home Agent Rekey Message

   Reserved

      The reserved field is 16 bits

   Home Agent Rekey Address

      The receiver of this message MUST rekey the security asscoation
      with the specified home agent.

   When a mobile node receives a Home Agent Rekey message, it MUST
   verify the message as following following.

   o  The message MUST be sent from the receiver's active home agent.
      Otherwise, the message MUST be discarded.

   o  The message MUST be protected by IPsec.  Otherwise, the message
      MUST be discarded.

   o  The message SHOULD contain one of standby home agent's address.
      If the home agent address is not known from the bootstrapping
      described in Section 9.5.1, Section 5.1, the mobile node MUST NOT start an IKE
      session with the unknown home agent.  Instead, it SHOULD re-start
      home agent discovery again to update its home agent address
      information.

   If all the above verfications are satisified, the mobile node MUST
   re-key the SA with the home agent addresses stored in the Home Agent
   Addresses field.

6.2.  New Mobility Options

6.2.1.  Binding Cache Information Option

   The binding cache information option is used to carry binding cache
   information of each mobile node.  It has two different lengths
   depending on the number of fields.  Two lengths can be set, 16 and
   40.  The alignment requirement is either 8n+6 or 8n+2.  The Binding
   Cache Information option is only valid in a State Synchronization
   message.  Its format is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                        Home Address                           |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       +                                                               +
       :                                                               :
       +                        Care-of Address                        +
       :                                                               :
       +                                                               +
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :          Flags                :       Sequence Number         :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :          Lifetime             :          Reserved             :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: Binding Cache Information Option

   The fields of Home Address is always mandated in a Binding Cache
   Information option.  The Care-of Address, Flags, Sequence Number, and
   Lifetime fields are presented only if these values are necessary (ex.
   VHARP).  The corresponding value in the mobile node MUST NOT start an IKE
      session with binding cache database of the unknown home agent.  Instead, it SHOULD re-start
   active home agent discovery again is copied to update its home agent address
      information.

   If all the above verfications are satisified, each field.  Note that the mobile node 16-bit
   Reserved field MUST
   re-key the SA with be set to zero.

6.2.2.  State Synchronization Status Option

   Figure 10 is a new mobility option of State Synchronization message.
   In the home agent addresses stored in global HAHA, SS-ACK is mandatory for receivers of SS-REP to
   notify the global binding registration status
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |   Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Status       |                  Reserved                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                        Home Agent
   Addresses field.

10.  Security Considerations

   Since Mobile IPv6 operation requires ESP Address                           |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 10: State Synchronization Status Option

   Type

      8-bit Type value.  The value is TBD.

   Length

      8-bit length value.

   Status

      8 bit Status value of global binding registration.

      *  0: Success

      *  128: Reason unspecified

      *  129: Malformed SS-REP

      *  130: Not in transport mode between
   the mobile node and the same global home agent, we will discuss the ESP field
   synchronization issues between the mobile node and the redundant agent set
   of home agents.  This synchronization is required only for

      *  131: No Mobility Option

   Reserved

      24 bit Reserved fields

   Home Agent
   Virtual Switch mode.  Most Address

      Corresponding home address of fields should be synchronized based on
   [RFC-4301].  The ESP header has the following fields:

   SPI status code.

6.2.3.  AAA Information Option

   This field identifies option is used to carry the SAD at AAA state of the receiver.

      The mobile node negotiates only one IPsec SA.  Hence, node's
   Mobile IPv6 sessions.  The AAA state information can be carried in
   RADIUS or Diameter AVP formats including the SPI
      value will remain unchanged upon home agent failover.

   Sequence Number user and session info.
   This field information option is used for "anti-replay" feature of ESP.  The
      transmitter must include this monotonically increasing number.
      The receiver may process the sequence number based on local
      policy. only valid in a State Synchronization
   message.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |   Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                        AAA AVPs                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 11: AAA Information Option

   Type

      8-bit Type value.  The mobile node and the redundant home agent set will have the
      same set value is TBD.

   Length

      8-bit length value.

   AAA AVPs

      Series of sequence numbers TLV encoded AAA AVPs (including vendor specific AVPs)
      carrying AAA-related information for transmit each Mobile IPv6 and receive.  Hence,
      synchronization of IPsec/
      IKE session.

7.  Security Considerations

   All the sequence number field is mandatory messages newly defined in this
      mode of operation.

      The SA1, SA2, SA3, SA4 could document SHOULD be synchronized between the home
      agents as these messages are not sent continuously.  Moreover for
      the Binding Update case, if the mobile node
   authenticated by IPsec AH and MAY be encrypted by IPsec ESP.  When a
   HA-HELLO message is in multicasted, the middle of
      sending a Binding Update multicast extensions to an active IPsec
   [RFC-5374] is used.  In some operational scenarios, home agent for a binding
      refresh, agents are
   located in deeply core network and the active securely managed.  If there is a
   secure transport network between home agents, some of security
   mechanism can be turned off depending on administrative policy.

   A home agent switch message is not available at that
      moment, the mobile node will not get any response from the active
      home agent.  After reused for signaling between a standby home
   agent becomes active, the mobile
      node will retry and it will receive the Binding Update from the a mobile node with a sequence number that in HARP.  It is +n from its last known
      sequence number for SA1.  For the Binding Acknowledgment case
      (SA2), the standby protected by IPsec ESP as
   defined in [RFC-5142].

   When an active home agent SHOULD add a random number to the
      last known sequence number over and above the replay window to
      ensure that the packet passes the replay check at the fails, mobile node.
      The same applies to HoTi and HoT messages with SA3 and SA4.  Note nodes using that this windowing of the sequence numbers for Mobile IPv6
      signaling is only needed to cover the corner cases when Binding
      Update or HoTi is in-flight and the active home agent fails.

      The technique explained above should work for user data packets if
      ESP is used
   need to encrypt user data traffic as well.  The actual
      switchover time and the routing infrastructure convergence time is
      the only latency that the user may perceive.

   Initialization Vector

      Since the Initialization Vector will be delivered in each exchange
      between a mobile node and home agent, this field is not
      necessarily synchronized between home agents.

   Others

      Other fields should be synchronized based on RFC4301 [RFC-4301]

   In the Home Agent Hard Switch mode, the standby change its home agent needs to
   send a Home Agent Switch message using IPsec encryption.  Since the one of standby home agents.  The
   mobile node has pre-established an need to update or establish the IPsec SA with both the active and
   standby home agents, the standby new
   home agent can send the message as described in Section 5.2.  Existing mechanisms
   [RFC5723] are applied to
   the mobile node with the pre-established IPsec SA.

11. this operation.

8.  Protocol Constants

      INITIAL_STATE_SYNC_REQ_TIMER: 3sec

      INITIAL_SWICHOVER_REQ_TIMER: 1sec

      INITIAL_SWICHBACK_REQ_TIMER

      INITIAL_SWICH_REQ_TIMER: 1sec

      LINK_TRAVERSAL_TIME 150msec

12.

      MAC_HARELIABILITY_TIMEOUT 16sec

      ALL_HA_MULTICAST_ADDR: TBD

9.  IANA Considerations

   o

   The values for following mobility header message Extension Types MUST be assigned by IANA.

      *  State Synchronization Message

      *  Home Agent Control Message

      * IANA:

   o  Home Agent Hello Reliability Protocol (HARP) Message

      *  Home Agent Rekey

   o  State Synchronization (SS) Message

   o  The values for following mobility options MUST be assigned by
      IANA.

      1.  Binding Cache Information Option

      2.

   o  AAA Information Option

   o  New Option Code  A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all
      home agents will be assigned by the IP address option defined in [RFC-5268]

13. IANA.

10.  Additional Authors

   This document is a result of discussions in the Mobile IPv6 Home
   Agent Reliability Design Team.  The members of the design team that
   are listed below are authors that have contributed to this document:

   Samita Chakrabarti

      samita.chakrabarti@azairenet.com

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Hui Deng

      denghui@chinamobile.com

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sri Gundavelli

      sgundave@cisco.com

   Brian Haley

      brian.haley@hp.com

   Behcet Sarikaya

      bsarikaya@huawei.com

   Ryuji Wakikawa

      ryuji@sfc.wide.ad.jp

14.

      ryuji.wakikawa@gmail.com

11.  Acknowledgements

   This document includes a lot of text from [ID-LOCALHAHA] and [ID-
   HAHA].  Therefore the authors of these two documents are
   acknowledged.  We would also like to thank the authors of the home
   agent reliability problem statement [ID-PS-HARELIABILITY] for
   describing the problem succinctly and Alice Qin for her work on the
   hello protocol.

15.

12.  References

15.1.
12.1.  Normative References

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
   IPv6", RFC 3775, June 2004.

   [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
   Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
   January 2005.

   [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
   Network Access Identifier", RFC 4282, December 2005.

   [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
   Chowdhury,

   [RFC-5026] Giaretta, G., "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", bootstrapping in split
   scenario", RFC 4283, November 2005. 5026, October 2007.

   [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC
   5094, October 2007.

   [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message",
   RFC-5142, November 2007.

   [RFC-5026] Giaretta, G.,

   [RFC-5374] B. Weis, G. GrossD.  Ignjatic, "Multicast Extensions to
   the Security Architecture for the Internet Protocol", RFC 5374,
   November 2008

   [RFC-5555] Soliman, H. et al, "Mobile IPv6 bootstrapping in split
   scenario", support for dual stack
   Hosts and Routers (DSMIPv6)", RFC-5555, June 2009.

   [RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
   and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5026, 5648,
   October 2007. 2009.

   [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via
   DHCPv6 for the Integrated Scenario",
   draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress),
   April 2008.

15.2.

12.2.  Informative References

   [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
   RFC 3768, April 2004.

   [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
   Standby Router Protocol (HSRP)", RFC 2281, March 1998.

   [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
   Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
   RFC 3776, June 2004.

   [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
   Internet Protocol", RFC 4301, December 2005.

   [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
   RFC 3753, June 2004.

   [RFC-5268] Koodli,

   [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
   RFC 3768, April 2004.

   [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Fast Handovers", Operation with
   IKEv2 and the Revised IPsec Architecture", RFC 5268, June
   2008. 4877, April 2007.

   [RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol
   Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010.

   [RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3
   for IPv4 and IPv6", RFC 5798 (soon?), December 2009.

   [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification",
   draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006.

   [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol",
   draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006.

   [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent
   Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired),
   February 2004.

Author's Address

   Ryuji Wakikawa
   TOYOTA InfoTechnology Center, U.S.A., Inc.
   465 Bernardo Avenue
   Mountain View, CA  94043
   USA

   Email: ryuji@us.toyota-itc.com