MIP6 Working Group                                  R. Wakikawa (Editor)
Internet-Draft                                           Keio University
Intended status: Standards Track                           March 5, 2007
Expires: December 21, 2006                                 June 19, 2006 September 6, 2007

                    Home Agent Reliability Protocol
                  draft-ietf-mip6-hareliability-00.txt
                  draft-ietf-mip6-hareliability-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 21, 2006. September 6, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   The home agent can be a single point of failure when Mobile IPv6 is
   used 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 a mechanism of home agent failure
   detection, home agent state transfer, and home agent switching for achieving
   home agent redundancy and reliability.  Note that this document is not completed yet.  DT is
   still discussing some items.

Table of Contents

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

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

   3.  Problem Statement and Requirements . . . . . . . . . . . . . .  6

   4.  Protocol Design  . . . . . . . .  7

   4.  Goals for the Solution . . . . . . . . . . . . . . . . . . . .  8

   5.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Home Agent Virtual Switch  . . . Network Configuration . . . . . . . . . . . . . 10
     5.2.  Home Agent Hard Virtual Switch  . . . . . . . . . . . . . . . . . . 11
     5.3.  Failure Detection and  Home Agent Management  . Hard Switch . . . . . . 13

   6.  Messages . . . . . . . . . . . . 12
     5.4.  Active Home Agent Management . . . . . . . . . . . . . . . 16
     6.1.  New Mobility Header 13

   6.  Messages . . . . . . . . . . . . . . . 16
       6.1.1.  Home Agent Hello Request Message . . . . . . . . . . . 16
       6.1.2.  Home Agent Hello Message . 14
     6.1.  New Mobility Header Messages . . . . . . . . . . . . . . . 17
       6.1.3. 14
       6.1.1.  State Synchronization Request Message  . . . . . . . . 20
       6.1.4.  State Synchronization Message  . . . . . . 14
       6.1.2.  Home Agent Control Message . . . . . . 21
       6.1.5.  Home Agent SwitchOver Request Message . . . . . . . . 22
       6.1.6. 16
       6.1.3.  Home Agent SwitchOver Reply Hello Message . . . . . . . . . 23
       6.1.7.  Home Agent SwitchBack Request Message  . . . . . . . . 23
       6.1.8. 18
       6.1.4.  Home Agent SwitchBack Reply Switch Message  . . . . . . . . . 24 . . . . . 20
     6.2.  New Mobility Options . . . . . . . . . . . . . . . . . . . 25 20
       6.2.1.  IP address Option  . . . . . . . . . . . . . . . . . . 25 20
       6.2.2.  Binding Cache Information Option . . . . . . . . . . . 25 21
       6.2.3.  AAA Information Option . . . . . . . . . . . . . . . . 27
       6.2.4.  Vendor Specific Information Option 22

   7.  Home Agent Operation . . . . . . . . . . 27

   7.  Home Agent Operation . . . . . . . . . . . 23
     7.1.  Home Agent Address Configuration . . . . . . . . . . 29
     7.1.  Home Agent Configuration . . . 23
     7.2.  Consideration of Routing and Neighbor Discovery
           Protocol . . . . . . . . . . . . . . 29
     7.2.  Hello messages Manipulation . . . . . . . . . . . 23
     7.3.  Home Agent List Management . . . . 30
       7.2.1.  Sending Hello Request . . . . . . . . . . . . 24
     7.4.  Detecting Home Agent Failure . . . . 31
       7.2.2.  Receiving Hello Request . . . . . . . . . . . 25
     7.5.  Home Agent Switch Over . . . . 31
       7.2.3.  Sending Hello . . . . . . . . . . . . . . 26
     7.6.  Processing Hello Messages  . . . . . . 31
       7.2.4.  Receiving Hello . . . . . . . . . . 27
       7.6.1.  Requesting Hello Message . . . . . . . . . 32
     7.3.  Failure Detection . . . . . . 27
       7.6.2.  Sending Hello Message  . . . . . . . . . . . . . . 32
     7.4.  Active Home Agent Change . . 27
       7.6.3.  Receiving Hello Message  . . . . . . . . . . . . . . . 33
     7.5. 28
     7.7.  Processing State Synchronization Messages  . . . . . . . . 34
       7.5.1.  Sending 28
       7.7.1.  Soliciting State Synchronization Request of a Particular Mobile Node or
               Subset of Mobile Nodes . . . . . . . . 34
       7.5.2.  Receiving State Synchronization Request  . . . . . . . 34
       7.5.3.  Sending State Synchronization  . . . . . . . . . . . . 34
       7.5.4.  Receiving 29
       7.7.2.  Synchronizing State Synchronization  . . of Mobile Nodes  . . . . . . . . . 35
     7.6. 30
     7.8.  Processing Home Agent SwitchOver Control Messages . . . . . . . . 35
       7.6.1.  Sending Home Agent SwitchOver Request  . . . . . . . . 35
       7.6.2.  Sending 31
       7.8.1.  Standby Home Agent becomes an Active Home Agent SwitchOver Reply  . . . . . .  . . . 36
       7.6.3.  Receiving 31
       7.8.2.  Active Home Agent SwitchOver Reply becomes in-active  . . . . . . . . 36
     7.7.  Processing . 32
     7.9.  Sending Home Agent SwitchBack Switch Messages . . . . . . . . 36
       7.7.1.  Sending Home Agent SwitchBack Request  . . . . . . . 32
     7.10. Interworking with VRRP . 36
       7.7.2.  Sending Home Agent SwitchBack Reply . . . . . . . . . 37
       7.7.3.  Receiving Home Agent SwitchBack Reply . . . . . . . . 37
     7.8.  Sending Home Agent Switch Message 33
     7.11. Retransmissions and Rate Limiting  . . . . . . . . . . . . 37 35

   8.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 38 36
     8.1.  Standby  Home Agent Addresses Discovery . . . . . . . . . . 38 . . . . 36
     8.2.  IKE/IPsec pre-establishment to Home Agents . . . . . . . . 38 36
     8.3.  Receiving Home Agent Switch message  . . . . . . . . . . . 39 37

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40 38

   10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40

   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43

   11. 41

   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43

   12. 41

   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     12.1. 42
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
     12.2. 42
     13.2. Informative References . . . . . . . . . . . . . . . . . . 42

   Appendix A.  Change Log From Previous Versions . . . . . . . . . . 44

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 47 45

1.  Introduction

   In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a
   bi-directional tunnel with their Home Agents home agents for all traffic with the
   correspondent nodes.  A home agent on the home link maintains a
   binding cache entry for each mobile node and uses the binding cache
   entry to route any traffic meant for the mobile node or the mobile
   network.  If the mobile node is not on the home link and does not
   have a binding cache entry at the home agent, it is neither reachable
   at its home address nor able to setup new sessions with its home
   address.  If a home agent loses the binding cache state, due to
   failure or some other reason, it results in a loss of service for the
   mobile nodes.

   It would be very is beneficial to provide high availability and redundancy for a
   home agent so that the mobile nodes can avail of uninterrupted service
   even when one home agent crashes or loses state.

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

   In this document, the term mobile node refers to both a mobile node
   [1] and a mobile router [2].

   Some of the mobility related terms used in this document are defined
   in [1] and [7]. [10].  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 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 pair group of an Active Home Agent active and Standby Home Agent(s). standby home agent(s).  The Group Identifier
      is introduced used to identify a Redundant Home Agent redundant home agent set.  The Group ID is
      exchanged by Hello messages.

   Binding Synchronization

      Synchronization of binding cache entries within the redundant home
      agent set set.

   Home Agent Preference

      This preference value is defined for DHAAD Duplicate Home Agent Address
      Discovery (DHAAD) in RFC3775.  This protocol uses this preference
      value for home agent selection when an active home agent is 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 value values for DHAAD and the home
      agent reliability protocol.  A Home Agent home agent SHOULD NOT use the same
      preference value of as other Home Agents home agents for this protocol.

   Home Agent Hard Switch

      The Home Agent Hard Switch is used when IPsec states cannot be
      synchronized between an active

3.  Problem Statement and a Standby Home Agent.  In this
      case each home agent negotiates independent IPsec SAs with a
      mobile node.  The mobile node will be notified to change its home
      agent to one of Standby Home Agent.

   Home Agent Virtual Switch

      In this case IPsec states are synchronized within the redundant
      home agent set.  A given mobile node has only one IPsec SA and one
      mobility binding.  Upon failure of the Active Home Agent, the
      Standby Home Agent begins to serve the mobile nodes without having
      to notify the mobile nodes about the failure event in the network.

3.  Problem Statement

   In Mobile IPv6 base specification, Requirements

   In Mobile IPv6 [1], a mobile node registers and establishes a connection binding
   with only one Home Agent. home agent.  Thus the Home
   Agent home agent represents the
   possibility of a single point of failure for Mobile IPv6.  A Home Agent home
   agent may be responsible for multiple mobile nodes on the home link.
   The failure of the Home Agent 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 home agents on the home link so that upon the failure of serving Home Agent, a
   home agent, a mobile node can re-establish its connection through the a
   new Home Agent. home agent.  However, the base Mobile IPv6 specification does not
   address the Home Agent home agent failover and dynamic transfer of service from one Home
   home agent to another.  This transfer of service from the Failed Home Agent failed home
   agent to a new working Home Agent home agent requires co-ordination coordination or pre-configuration pre-
   configuration among the Home home agents regarding security association, associations,
   transfer of mobile-node related
   binding mobile node bindings, and other service information for the
   reliable Mobile IPv6 service in a deployment scenario.

4.  Goals for the Solution

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

   Reliable Home agent service

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

   Availability of a redundant home agent set

      Availability of an Active Home Agent active home agent address and a standby Home
      Agent home
      agent address at the bootstrapping period to Mobile Node for the mobile node is
      assumed.

   State Synchronization

      The information for mobile nodes must be able to be synchronized
      between an
      Active Home Agent active home agent and Standby Home Agents.  The information is standby home agents.  This
      includes the Binding Cache, IPsec/IKE states, AAA information, vendor specific other Mobile IPv6 and
      NEMO related information.

   Consideration of IPsec/IKE transfer
      An Active Home Agent active home agent maintains several IPsec and IKE states for
      mobile nodes.  These states are synchronized within the redundant
      Home Agent
      home agent set.  The details are described in Section 9.

   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.  Periodic hello messages should be used to
      detect Active Home Agent's service availability

   Failure Notification active home agent.  If necessary a mobile node is notified about the active home agent supports an existing
      failure by detection mechanism such as VRRP[4] or HSRP[5], it can re-
      use that mechanism to detect the Standby Home Agent in Home Agent Hard Switch mode
      of operation

5.  Protocol Overview

   This specification provides two modes for home agent local
   reliability.

   o  Home Agent Virtual Switch: In this mode the active and failure.  On the
      redundant home agents other
      hand, periodic Hello messages are all accessible through the same IP
      address.  IPsec/IKE states must be synchronized between the introduced to detect active
      and a redundant home agent(s).  The mechanism used to synchronize
      IPsec state is currently considered out of scope for this document
      and not described here.  In
      agent's service availability in this mode, document.

   Failure Notification

      If necessary, a mobile node always
      establishes IPsec SAs only with the Active Home Agent.  The IPsec
      state will be shared within is notified about the redundant active home
      agent set in
      background.  In case there is a failure by the Standby Home Agent
      takes over without the standby home agent.

4.  Protocol Design

   Mobile IPv6 depends on IPsec and IKE for home binding registration as
   described in [6].  A mobile node being aware of the change in
      the must encrypt a Binding Update sent
   to a home agent.

   o  Home Agent Hard Switch:  In this mode the home agents are addressed
      by different IP addresses and addition, the mobile node is aware of the
      change in exchanges HoTI and HoT
   messages through the home agent.  This mode is also useful when the agent by using IPsec
      state cannot tunnel mode.
   Therefore, before home agent failure, these IPsec states should be synchronized.  In this mode,
   synchronized among home agents of a standby redundant home agent
      must solicit set.  A
   mobile nodes node may also encrypt particular data traffic sent to re-establish IPsec/IKE for nodes in
   the Internet.  IPsec information required by Mobile IPv6 signaling.  This IPsec re-establishment is triggered when a
      mobile node changes its home agent after receiving a home agent
      switch message from a standby home agent.  In order to exchange
      this message securely between a Standby Home Agent listed
   below.

   o  Security Policy Database (SPD) and a mobile
      node, a mobile node need to establish IPsec Selector Information

   o  Security Association (SA) for Binding Registration (SA1 and SA2)

   o  SA with both an Active
      Home Agent for HoTI/HoT Exchange (SA3 and redundant home agents beforehand.  With SA4)

   o  SA for Mobile Prefix Discovery (SA5 and SA6)

   o  SA for data packets if any (SA7 and SA8)

   There are various ways this can be achieved.  One is to setup
   multiple IPsec SAs, a security associations between the mobile node will receive a notification from
      the Standby Home Agent and start the
   home agent sets.  Another is to use have the Standby Home Agent
      when home agents periodically
   check-point IPsec session state, including the Active Home Agent failed.

   All new messages defined in this document are defined as Mobility
   Header messages so that per packet sequence
   numbers, for the HA reliability protocol can be extended
   later, if needed, to provide mobile node.  Thus, we define two possible home link redundancy. (i.e.  Protocol is
   not tight with the link boundary)

5.1.
   agent redundancy modes as follows:

   Home Agent Virtual Switch

   In the case of the virtual

      Each mobile node negotiates just one SA with an active home agent switch,
      in a mobile node remains
   agnostic about redundant home agent set.  The IPsec state will be shared
      within the change redundant home agent set in the serving home agent. background.  The active
      and the redundant home agents
   have replicated all session state including the IPsec/IKE/ESP sates.
   The ESP sequence numbers, which is used to prevent replay attack, may
   not be synchronized momentarily.  However, this should not pose any
   problem as both ends of the IPsec ESP tunnel should use sequence
   numbers that are greater than the last known sequence numbers to
   either ends.  The Standby Home Agent should add a random number (+n)
   over and above the anti-replay window to ensure that the packet
   received addressed by the mobile node passes ESP replay check.

   The operations of the Home Agent Virtual Switch are shown in
   Figure 1.  After binding registration same home agent
      address, although only tje active home agent is done (2, 3), accessible by the Active Home
   Agent pushes
      home agent address all the states of mobile nodes by a state
   synchronization message in a periodic interval (4).  The Active Home
   Agent synchronizes the IPsec state information with the Standby Home
   Agent(s), too.  This state synchronization should time.  IPsec/IKE states must be done
   periodically in order to match
      synchronized between the ESP sequence number active and anti-
   replay window among standby home agents.  The Standby Home Agent(s)
      mechanism used to synchronize IPsec state is considered out of
      scope for this document.  In case there is not
   active unless it takes over from a Failed Home Agent.

   When the Active Home Agent's failure is detected (5), the Standby
   Home Agent activates the IP address of the failed active
      home agent, the standby home agent on it
   and takes over from without the Failed Home Agent.  All mobile
      node being aware of the home agents change in the home agent.

      In a redundant home agent set share set, a virtual single home agent address and is used
      by the routing
   will ensure only the Active Home Agent will be reachable using that
   virtual address.  The Standby Home Agent can serve all active home agent.  Thus, all the mobile nodes for which the states are synchronized, without any further
   message exchange because it has all the necessary information which
   it obtained from served by a
      redundant home agent set MUST associate with the failed same home agent.

     MN      HA1(active)    HA2(Standby)
      |           |           .
      |<--------->|           . 1. IPsec/IKE
      |           |           .
      |---------->|           . 2. Binding Update
      |<----------|           . 3. Binding Acknowledgement
      |           |           .
      |           |<--------->. 4. State exchanges (Binding cache/IPsec)
      |           |           .
      |           X           .  HA1 FAILURE
      |           X           .
      |           X<----------. 5. Failure Detection
      |           X           |
      |           X           | 6. HA2 takes over agent
      (the active home agent) all the HA1
      |           X           |
      |           X           |    RECOVERY COMPLETE

   Figure 1: Overview of Home Agent Virtual Switch

5.2. time.

   Home Agent Hard Switch

      The Home Agent Hard Switch home agents are addressed by different IP addresses and the
      mobile node is shown aware of the change of home agent.  A Mobile node
      and all home agents in Figure 2. a redundant home agent set negotiate
      independent IPsec SAs.  This mode is especially useful when the
      IPsec/IKE states cannot be synchronized.  However, the home agent
      change is not transparent to the mobile node.  When an active home
      agent fails, a mobile node when there is will receive a notification (a Home
      Agent Switch message [11]) from a standby home agent failure agent, and
   another home agent takes over.

     MN      HA1(active)    HA2(Standby)
      |           |           |
      |<--------->|           | 1. IKE exchange (w/HoA assignment)
      |           |           |
      |---------->|           | 2. send a
      Binding Update
      |<----------|           | 3. Binding Acknowledgement
      |           |           |
      |<--------------------->| 4. IKE to the standby home agent.  In order to exchange (wo/HoA assignment)
      |           |           |
      |           |<--------->| 5. State Exchanges
      |           |           |
      |           X           |  HA1 FAILURE
      |           X           |
      |           X<----------| 6. Failure Detection
      |           X           |
      |<----------------------| 7. Sending home agent
      |           X           |    Switch message
      |           X           |
      |<--------------------->| 8. Binding Registration (optional)
      |           X           |
      |           X           |    RECOVERY COMPLETE

   Figure 2: Overview of
      the Home Agent Hard Switch

   In this mode, message securely between the standby home
      agent and a mobile node, the mobile node needs to establish an
      IPsec SA with multiple both the active and the standby home agents in the
      redundant home agent set beforehand.  When

      Since each home agent has a different address, an Active Home Agent fails, the other
   Standby Home Agent could use pre-existing IPsec SA to notify the
   Mobile Node about the failure.  After the notification, the active home
      agent can be defined for each mobile node.  When a mobile node
      boots, it will use discover home agents and create IPsec SAs with
      them.  It will then decide which one of the Standby Home Agent as home agents is its
      active home agent.

   In order to discover the home agent address,  For example, when two different mechanisms
   are defined in home agents serve a home
      network, half of the bootstrapping solution in split scenario.  One is
   DNS lookup by mobile nodes might register with one home
      agent Name, and the other is DNS lookup by Service
   Name.  The rest of mobile node sends a DNS SRV request and acquires IP
   addresses and preferences nodes with another home agent.  When
      one of the home agents fails, a redundant standby home agent set.  In
   integrated scenario, DHCPv6 agent, whose
      preference value is used to provide next highest than the failed home agent, can
      trigger a home agent provision switch by sending a Home Agent Switch message
      to Mobile Node.

   The the mobile node establishes IPsec/IKE state nodes that were registered with the other acquired failed home agents beforehand (1 and 4), however it registers only with
      agent.

   In both the cases, the
   Active Home Agent (2 and 3).  The Active Home Agent synchronizes
   required states of mobile nodes such as Binding Cache information and
   AAA information, etc. with other standby node maintains only one home agents periodically
   (5).

   When binding at
   any given time.  In the Standby Home Agent detects Hard Switch mode, the failure of mobile node
   needs to switch its binding from the active to standby home agent (6), it sends a
   upon failover.  The bindings are synchronized among home agents in
   the redundant home agent switch message to all set in the mobile
   nodes background when the Home Agent
   Virtual Switch mode is used.

   All new messages defined in this document are defined as Mobility
   Header messages so that were registered to the Failed Home Agent (7).  The home
   agent switch message must Reliability protocol can be encrypted by pre-established IPsec SA.
   After the switch message,
   extended to provide home link redundancy.

   Finally, the mobile node MAY send reasons why we defined a binding update
   and registers it with the new Active Home Agent Hello message instead of
   using VRRP is described in order to update
   MIP6 tunnel's end points (8).  However, this binding registration Section 7.3 and Section 7.4.  We also give
   instructions on how operators can
   be skipped since run both VRRP and the Standby Home Agent synchronizes the binding
   cache information with
   Reliability protocol at the Active same time in Section 7.10.

5.  Protocol Overview

5.1.  Home Agent periodically. Network Configuration

   The
   mobile node only changes its home agent address to the new Active
   Home Agent.

5.3.  Failure Detection and Home Agent Management

       HA1(active)  HA2    HA3 .. HAn
           |        |      |      |
           |<------>|      |      | 1. Hello exchange
           |<------------->|      |
           |<-------------------->|
           |        |      |      |
        (Failed)    |      |      | A FAILURE OCCURS
           X        |      |      |
           X        |      |      | 3. Reliability protocol supports two different
   configurations for standby home agents.  Standby HAs detects
           X        |      |      |    failure.
           X        |      |      |
           X     (active)  |      | 4. HA2 becomes Active HA
           X        |      |      |
           |        |      |      | HA1 RECOVER NOW
       (standby)    |      |      |
           |------->|      |      | 5. home agents can be
   placed on the same home link as the active home agent, or on a
   different link.  The Global Recovery described below is not included
   in this document, although the Home Agent Reliability protocol can
   support this with slight modifications to home agent operations.

                 HA1 sends SwitchOver Request
           |<-------|      |      | 6.    HA2 sends SwitchOver Reply
           |        |      |      |
       (active) (standby)  |      | 7. HA1 returns to active HA
           |        |      |    HA3    HA4 .... HAn
                  |      |      |      |        | HA1 BECOMES ACTIVE AGAIN

   Figure 3:
          --------+------+------+------+--------+---------
                             Home Agent Management Link

                  Figure 3 illustrates 1: Local Recovery Configuration

   Figure 1 depicts the mechanism by which a Standby Home Agent
   takes over from a failed configuration where home agent.  This operation is common for
   both the hard and agents serving the virtual switch modes.  The same
   home agent whose
   preference is the highest among the Standby Home Agents takes over
   immediately after it detects failure of network are located on the Active Home Agent.  The
   preference value can be same as the link.  For example, HA2, HA3 and
   HA4 are standby home agent preference value agents of
   RFC3775, while HA1.  This is the operator can define an independent value only same as what Mobile
   IPv6 defines for home agent reliability protocol.

   The Home Agents in the redundant Home Agent set exchange periodic
   Hello messages to convey their information to the peers (1).  The
   Hello messages can either be unicast or multicast.  In order to
   explicitly query the state information of its peer(s), any configuration.

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

                HA1    HA2                     HA3    HA4
                 |      |                       |      |
         --------+------+-----+ R---R---R +-----+------+-------
               Home Agent
   can send Link          Routers     Recovery Link

                  Figure 2: Global Recovery Configuration

   Figure 2 illustrates when standby home agents are located on a Hello request to its peer(s) in the redundant Home Agent
   set.  The Hello message exchange is
   different link (named the basis recovery link in Figure 2).  HA3 and HA4
   are standby home agents of failure detection HA1 and automatic switchover in HA2.  In this scheme (3 case, HA3 and 4).

   When HA1 recovers in Figure 3, it needs to remain in HA4
   cannot receive packets meant for the home network until the route on
   the Routers is changed.  The advantage of this configuration is that
   standby
   state.  This prevents it to automatically take over home agents can recover from the
   currently active Home Agent.  HA1 sends a SwitchOver Request to the
   currently active Home Agent (i.e.  HA2) only if failure of the system
   administrator issues a manual command, home link.
   This configuration can achieve home agent recovery even if the monitored server fails,
   if entire
   home link fails.  In this configuration, the routing peer/link fails.  The currently Active Home Agent can must be known through the exchange of Hello messages.  HA1 may need to
   send Hello Request message also
   updated to all the Standby Home Agents, when it
   recovered from the failure.  When HA2 receives direct the Home Agent
   SwitchOver Request from HA1 it changes its state to standby and sends
   back packets meant for the SwitchOver Reply message to HA1.  HA1 returns to active home
   agent status immediately after receiving link to the SwitchOver reply. recovery
   link.

   This geographic redundancy is not a requirement by any SDO (Standards
   Development Organization), but is required by operators.  Most large
   operators have a very stringent requirement on network availability
   even in the worst type of disaster or outage.  For example, critical
   nodes in region-1 are backed up by nodes 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.

5.2.  Home Agent Virtual Switch

   A mobile node remains unaware about the change in the active home
   agent since the home agents have replicated all session state
   including the IPsec/IKE/ESP states.  The IPsec/IKE/ESP state transfer
   is out of scope of this document.

     MN      HA1(active)  HA2    HA3 .. HAn
           |        |      |    HA2(Standby)
      |
           |------->|           |           .
      |<--------->|           | 1. HA1 sends SwitchBack Request
           |<-------|      |      | IKE exchange (with HoA assignment)
      |---------->|           . 2. HA2 sends SwitchBack Reply
           |        |      |      |
       (standby) (active)  |      | HA2 BECOMES ACTIVE HA
           |        |      |      |
              SYSTEM MAINTENANCE, ETC. Binding Update
      |<----------|           . 3. Binding Acknowledgment
      |           |           .
      |           |<--------->. 4. State exchanges (binding cache/IPsec)
      |
           |------->|           |           .
      | 3.           X           .  HA1 sends SwitchOver Request
           |<-------|      |      | 4. HA2 sends SwitchOver Reply
           |        | FAILURE
      |           X           .
      |
       (active) (standby)           X<----------. 5. Failure Detection
      |           X           | 5. 6. HA2 takes over the HA1 returns to active HA
      |           X           |
      |           X           | HA1 BECOMES ACTIVE AGAIN    RECOVERY COMPLETE

              Figure 4: Manual 3: Overview of Home Agent Change

   In some scenarios Virtual Switch

   The operations of the Active Home Agent may need to stop serving the Virtual Switch mode are shown in
   Figure 3.  The mobile nodes node first attempts the IKE exchange for system maintenance.  This specification provides
   manual
   Security Association (SA) setup and home address assignment (1).
   After binding registration is done (2, 3), the active home agent change by using Home Agent SwitchBack Request and
   Reply messages.  As shown in Figure 4,
   pushes all the Active Home Agent (HA1)
   sends Home Agent SwitchBack Request to an Standby Home states of its mobile nodes with a state
   synchronization message (4).  The standby home agent(s) is not active
   unless it takes over from a failed home Agent.  As
   soon as HA2 receives

   When the message, active home agent's failure is detected (5), the standby
   home agent activates the IP address of the failed home agent on it becomes
   and takes over for the Active Home Agent.
   HA2 also acknowledges with failed home agent.  All the Home Agent SwitchBack reply to HA1.
   HA1 becomes home agents in the
   redundant home agent set share a virtual home agent address and the
   routing will ensure only the active home agent will be reachable
   using that virtual home agent address.  The standby when home agent can
   serve all the mobile nodes for which the states are synchronized,
   without any further message exchange, because it receives has all the SwitchBack reply.  After
   necessary information which it obtained from the
   downtime, HA1 sends a failed home agent.

5.3.  Home Agent SwitchOver Request to HA2 in order
   to return to become an Active Hard Switch

   The overview of the Home Agent again.  This operation Hard Switch is
   same as shown in Figure 3

6.  Messages 4.
   This document defines following new messages:

   o  New Mobility Header Messages

      *  Home Agent Hello Request Message

      *  Home Agent Hello Message

      *  State Synchronization Request Message

      *  State Synchronization Message

      *  Home Agent SwitchOver Request Message

      *  Home Agent SwitchOver Reply Message

      *  Home Agent SwitchBack Request Message

      *  Home Agent SwitchBack Reply Message

   o  New Mobility Options

      *  Binding Cache Information Option

      *  AAA Information Option

      *  Vendor Specific Information Option

   We may add more mobility options in the future document.  The DT mode is
   currently discussing not transparent to the needs and mobile node when the formats of IPsec/IKE state
   information Option and BGP/OSPF modifier option for state
   synchronization message. active home
   agent failure occurs.

     MN      HA1(active)    HA2(Standby)
      |           |           |
      |<--------->|           | 1. IKE exchange (with HoA assignment)
      |---------->|           | 2. Binding Update
      |<----------|           | 3. Binding Acknowledgment
      |<--------------------->| 4. IKE exchange (without HoA assignment)
      |           |           |
      |           |<--------->. 5. State exchanges (binding cache)
      |           |           |
      |           X           |  HA1 FAILURE
      |           X           |
      |           X<----------| 6. Failure Detection
      |<----------------------| 7. Sending Home Agent
      |           X           |          Switch message is defined in [8].  This message is also
   used in operation
      |<--------------------->| 8. Binding Registration
      |           X           |
      |           X           |    RECOVERY COMPLETE

               Figure 4: Overview of Home Agent Hard Switch.

6.1.  New Mobility Header Messages

6.1.1.  Home Agent Hello Request Message Switch

   The message is unicasted to a mobile node establishes IPsec/IKE state with all the home agents
   in the redundant home agent to solicit a Hello message
   from set beforehand (1 and 4), however it
   registers its binding only with the active home agent (2 and 3).
   When an active home agent fails, a standby home agent.  The receiver of this Hello Request message MUST
   return agent uses a Hello message pre-
   existing IPsec SA to notify the originator of this request message.  A mobile node about the failure by
   securely sending a Home Agent Hello message SHOULD be authenticated Switch message.  In order to discover
   home agent addresses, two different mechanisms are defined, as
   described in Section 8.1.  The active home agent synchronizes the
   required states of the mobile nodes, such as Binding Cache and encrypted by
   IPsec ESP. AAA
   information, with other standby home agents periodically (5).  The Hello Request message has
   mobile node MUST NOT request a home address(es) assignment through
   the MH Type value TBD. IKE exchange to the standby home agent when it establishes an SA
   with it (4).

   When this value
   is indicated in the MH Type field, standby home agent detects the format failure of the Message Data
   field in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5: active home
   agent (6), it sends a Home Agent Hello Request Message

   Sequence #

      16-bit unsigned integer.  The Sequence number of the Hello Switch message
      can be used to verify whether this Hello message is all the latest one
      or not.

   Mobility Options

      Variable-length field of such length mobile
   nodes that were registered with the complete Mobility
      Header 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 Section 6.2 of [1]. failed home agent (7).  The receiver MUST ignore and skip any options which it does not
      understand.  There MAY be additional information, associated with
      this HELLO Request Home
   Agent Switch message that need not must be present in all HELLO
      Request messages sent.  Mobility options allow future extensions
      to encrypted by a pre-established IPsec SA.
   After the format of switch message, the HELLO Request message mobile node MUST send a binding update
   to be defined.

   If no options are present in this message, no padding is necessary
   and the Header Len field will be set new active home agent in order to 1.

6.1.2. update the Mobile IPv6
   tunnel end points (8).

5.4.  Active Home Agent Hello Message

   The message is either unicasted or multicasted Management

       HA1(active)  HA2    HA3 .. HAn
           |        |      |      |
           |------->|      |      | 1. HA1 sends SwitchBack Request
           |<-------|      |      | 2. HA2 sends SwitchBack Reply
           |        |      |      |
       (standby) (active)  |      | HA2 BECOMES ACTIVE HA
           |        |      |      |
              SYSTEM MAINTENANCE, ETC.
           |        |      |      |
           |------->|      |      | 3. HA1 sends SwitchOver Request
           |<-------|      |      | 4. HA2 sends SwitchOver Reply
           |        |      |      |
       (active) (standby)  |      | 5. HA1 returns to carry active HA
           |        |      |      | HA1 BECOMES ACTIVE AGAIN

                    Figure 5: Manual Home Agent
   information among Change

   In some scenarios the Redundant active home agent set.  This Hello message
   is used by any home agents may need to detect the failure of a redundant peer
   in the redundant Home Agent set. stop serving
   mobile nodes for system maintenance.  This message can be sent either
   periodically or in reply to Hello Request message.  A specification provides for
   a manual home agent
   Hello message SHOULD be authenticated and encrypted switch by IPsec ESP when
   it is unicasted.  If a Hello message is multicasted, IPsec ESP cannot
   be applied.  Hence if multicast is used, the redundant Home Agent set
   should be in a secure network.

   The Standby Home Agents and the Active Home Agent must exchange the
   home agent information.  Although Mobile IPv6 uses a router
   advertisement to exchange home agent information periodically, the
   Hello message can be replaced with the router advertisement.

   If the Standby Home Agent misses this Hello message from it's peer
   Active Home Agent for a configured number of times, it SHOULD assume
   that the Active Home Agent has failed.  If the active home agent does
   not periodically send the Hello message, each standby home agent
   needs to solicit it by sending a Hello Request message.

   The Hello message has the MH Type value TBD.  When this value is
   indicated in the MH Type field, the format of the Message Data field
   in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Home Agent Preference    |      Home Agent Lifetime      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Hello Interval           |   Group ID    |A| Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: Home Agent Hello Message

   Sequence #

      16-bit unsigned integer.  The Sequence number of the Hello message
      can be used to verify whether this Hello message is the latest one
      or not.

   Home Agent Preference

      16-bit unsigned integer.  The preference for the home agent
      sending this hello.  This preference is same as the home agent
      preference value of home agent information option defined in
      Mobile IPv6.  However, if operators want to use the different
      preference value for this operation, it can use different value
      from the preference defined in RFC3775

   Home Agent Lifetime

      16-bit unsigned integer.  The lifetime for the home agent sending
      this Hello.  This lifetime is same as the home agent Lifetime
      value of home agent information option defined in Mobile IPv6.

   Hello Interval

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

   Group Identifier

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

   A flag

      If this flag is set, the sender of this Hello message is an Active
      Home Agent.  Otherwise, the sender is Standby Home Agent

   Reserved

      7-bit unsigned integer.  It must be initialized to zero by the
      sender and must be ignored by the receiver.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header 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 [1].  The receiver
      MUST ignore and skip any options which it does not understand.

      The following options are valid in a Hello:

      *  IP Address Option (Sub-type: Home Agent Address): A Home Agent
         Address and its Prefix Length are stored in an IP address
         option.  If there are multiple home network prefixes serving by
         a home agent, multiple IP address options should be used in a
         Hello message.

      If no options are present in this message, 0 octets of padding are
      necessary and the Header Len field will be set to 2.

6.1.3.  State Synchronization Request Message

   This message is used to request state corresponding to a particular
   mobile node.  It is a unicast message and MUST be authenticated.  The
   State Synchronization Request message is used to solicit the active
   state corresponding to a particular Mobile Node.  The format of the
   message is as follows:

   The State Synchronization Request has the MH Type value TBD.  When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Identifier           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 7: State Synchronization using SwitchBack Request Message

   Identifier

      The 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 the complete Mobility
      Header 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 [1].  The receiver
      MUST ignore and skip any options which it does not understand.

      The following options are valid in a State Synchronization Request
      message.  One of the following options is mandatory in State
      Synchronization Request message. :

      *  IP Address Option (Sub-type: Home Address)[9].  If a Home
         Agents wants Reply
   messages.  As shown in Figure 5, the Binding Cache information for active home agent (HA1) sends a particular
         Mobile Node, it includes an IPv6 Address Option (Sub-type: Home
         Address).

      *  Mobile Network Prefix Option: If
   SwitchBack Request message to a standby home agent wants to know (HA2).  As soon as
   HA2 receives the
         forwarding state setting up for message, it becomes the active home agent.  HA2 will
   acknowledge the message by sending a particular Mobile Network
         Prefix, SwitchBack Reply message to HA1.
   HA1 becomes a standby home agent when it includes receives the SwitchBack
   Reply.  After the downtime, HA1 sends a Mobile Network Prefix Option defined in
         [2].

   If no options are present SwitchOver Request to HA2 in this message, no padding is necessary
   and
   order to become the active home agent again.

6.  Messages

6.1.  New Mobility Header Len field will be set to 1.

6.1.4. Messages

6.1.1.  State Synchronization Message

   The State Synchronization

   This message is used between the home agents in
   the Home Agent redundant set to exchange binding cache information,
   IPsec state and any other information related to providing mobility
   service corresponding to the a particular
   mobile nodes. node.  It is an unicast message.  The state
   synchronization can MUST be sent unicasted and MUST be authenticated by an active home agent either
   periodically or in response to a state synchronization Request
   message. IPsec
   ESP.  The State Synchronization message has the MH Type value TBD.
   When this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Identifier     Type      |    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identifier            |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: 6: State Synchronization Message

   Type

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

         0: Request

         This message is called State Synchronization Request and used
         to request state corresponding to a particular mobile node.
         The State Synchronization Request is used to solicit the active
         state corresponding to a particular mobile node.

         1: Reply

         The message is called State Synchronization Message
   Identifier Reply and is used
         between the home agents in the redundant home agent set to
         exchange binding cache information and any other information
         related to providing mobility service to the mobile nodes.  The
         State Synchronization Reply can be sent by an active home agent
         either periodically or in response to a State Synchronization
         Request.

   Reserved

      8-bit unsigned integer.  It must be initialized to zero by the
      sender and must be ignored by the receiver.

   Identifier

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

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header 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 [1].  The receiver
      MUST ignore and skip any options which it does not understand.

      The

      One of the following options are valid is mandatory in a State Synchronization
      Request message. :

      *  IP Address Option (Sub-type: Home Address)[12].  If a home
         agent wants the Binding Cache information for a particular
         mobile node, it includes 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 a Mobile Network Prefix Option as defined
         in [2].

      *  Vendor Specific Mobility Option.  If a home agent wants vendor
         specific information, it can solicit with this option as
         defined in [7].

      One of the following options is mandate mandatory in State Synchronization message.
      Reply. :

      *  Binding Cache Information Option. Option

      *  AAA Information Option. Option

      *  Vendor Specific Information Option. Mobility Option

   This message requires at least one of mobility options.  Therefore, option, therefore, there
   is no default length for this message.

6.1.5.

6.1.2.  Home Agent SwitchOver Request Control Message

   This message is unicasted by a Standby Home Agent that desires used to
   become the Active Home Agent for all control the Mobile IPv6 sessions.  The
   receiver status of the message MUST transit a home agent to inactive state as soon as the either
   active or standby.  This message is received MUST be unicasted between home
   agents and validated.

   The Home Agent SwitchOver Request message has the MH Type value TBD.
   The message MUST be authenticated and encrypted by IPsec ESP.When ESP.  The
   Home Agent Control message has the MH Type value TBD.  When this
   value is indicated in the MH Type field, the format of the Message
   Data field in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Reserved     Type      |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Status      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9: 7: Home Agent Control Message

   Type

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

         0: SwitchOver Request Message

         This message is called SwitchOver Request.  It is unicasted by
         a standby home agent that desires to become the active home
         agent.  The receiver of the message MUST transition to standby
         state as soon as the message is received and validated
         successfully.

         1: SwitchOver Reply

         This message is called SwitchOver Reply.  It is used to
         acknowledge the receipt of the corresponding SwitchOver
         Request.

         2: SwitchBack Request

         This message is called SwitchBack Request.  It is unicasted by
         an active home agent that desires to become the 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

         This message is called SwitchBack Reply.  It is used to
         acknowledge the receipt of the corresponding SwitchBack
         Request.

   Status

      8-bit unsigned integer indicating the disposition of a Switchover
      Request or SwitchBack Request message.  This field is only valid
      in SwitchOver Reply and SwitchBack Reply messages.  The following
      Status values are defined:

         0: Success

         128: Reason unspecified

         129: Administratively prohibited

         130: Not active home agent (The receiver of the SwitchOver
         Request message is not the active home agent)

         131: Not standby home agent (The receiver of the SwitchBack
         Request is already the active home agent)

         132: Not in same redundant home agent set

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header 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 [1].  The receiver
      MUST ignore and skip any options which it does not understand.  No
      options are defined in this specification

   If no options are present in this message, no padding is necessary
   and the Header Len field will be set to 1.

6.1.6.

6.1.3.  Home Agent SwitchOver Reply Hello Message

   This messages can be replaced by other protocols as described in
   Section 7.10.  If this message is used used, it MUST be either unicasted
   or multicasted to acknowledge the receipt of carry home agent information among the corresponding
   Home Agent SwitchOver Request message. redundant
   home agent set.  The reply Hello message should
   contain status_code field to convey is defined for two purpose: 1) an
   alive check and 2) home agent information exchange.  A home agent
   Hello message SHOULD be authenticated and encrypted by IPsec ESP when
   it is unicasted.  If a Hello message is multicasted, IPsec ESP cannot
   be applied.  In this case the result of processing redundant home agent set should be
   located in a secure network.  Alternatively, all the
   received Home Agent SwitchOver Request message. home agents MUST
   have a secure channel with each other.  The Home Agent SwitchOver Hello message has the MH
   Type value TBD.  When this value is indicated in the MH Type field,
   the format of the Message Data field in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Status          Sequence #           |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Home Agent Preference    |      Home Agent Lifetime      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Hello Interval         |   Group ID    |A|R|  Reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 10: 8: Home Agent SwitchOver Reply Hello Message

   Status

   Sequence #

      16-bit Status value.  Values of Status field greater than or equal
      to 128 indicate that the Home Agent SwitchOver Request was
      rejected by the receiving node.  The following Status values are
      currently defined:

         0: success

         128: unsigned integer.  The receiver Sequence number of the Hello message
      can be used to verify whether this Hello message is the latest one
      or not.

   Home Agent SwitchOver Request message Preference

      16-bit unsigned integer.  The preference for the home agent
      sending this Hello message.  This preference is not the Active same as the
      Home Agent

         129: failed, Admin Prohibited.

   No padding is necessary and Preference value of the Header Len field will be set to 1.

6.1.7. Home Agent SwitchBack Request Message Information option
      as defined in [1].  However, operators MAY use a different
      preference value for this operation.

   Home Agent Lifetime

      16-bit unsigned integer.  The lifetime for the home agent sending
      this Hello message.  This message lifetime is unicasted by an Active the same as the Home Agent that desires to
   become
      Lifetime value of the inactive Home Agent Information option as defined in
      [1].

   Hello Interval

      16-bit unsigned integer.  The interval for all the Mobile IPv6 sessions.  The
   receiver 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

      If this flag is set, the sender of this Hello message SHOULD transit to is an active state as soon as
      home agent.  Otherwise, the message sender is received and validated.

   The Home Agent SwitchBack Request message has standby home agent

   R flag

      If this flag is set, the MH Type value TBD.
   The receiver of this Hello message MUST must send
      back a Hello message to the sender.

   Reserved

      6-bit unsigned integer.  It must be authenticated initialized to zero by the
      sender and encrypted must be ignored by IPsec ESP.  When
   this value is indicated in the MH Type field, receiver.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of the
   Message Data field defined options are described in the Mobility Header 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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Reserved             |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 11: Home Agent SwitchBack Request Message [1].  The receiver
      MUST ignore and skip any options which it does not understand.  No
      valid options are defined in this specification.

      If no options are present in this message, 0 octets of padding is are
      necessary and the Header Len field will be set to 1.

6.1.8. 2.

6.1.4.  Home Agent SwitchBack Reply Switch Message

   This message is used to acknowledge the receipt of the corresponding defined in Section 8.3.  The Home Agent SwitchBack Request message.  The Reliability
   protocol extends this message should contain
   status_code field to convey for the result of processing Home Agent
   SwitchBack Request message.

   The Home Agent SwitchBack Reply message has the MH Type value TBD.
   When this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows: Hard Switch.

       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |# of Addresses |I|  Reserved   |          Status
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                               |
      +                                                               +
      .                      Home Agent Addresses                     .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                        Mobility options                       .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 12: 9: Home Agent SwitchBack Reply Switch Message

   Status

      16-bit Status value.  Values of Status field greater than or equal

   IPsec Re-key (I)

      The IPsec rekey (I) bit is set to 128 indicate that the Home Agent SwitchBack Request was
      rejected by mobile node
      SHOULD start an IPsec re-key with the receiving node.  The following Status values are
      currently defined:

         0: success
         128: The receiver of Home Agent SwitchBack Request is already home agent specified in the Active
      Home Agent

         129: failed, Admin Prohibited.

   No padding Addresses field.  This flag is necessary used when a failed home
      agent recovers and the Header Len needs to re-establish IPsec SA/IKE state with a
      mobile node.

   Reserved

      The reserve field will be set is reduced from 8 to 1. 7 bits

6.2.  New Mobility Options

6.2.1.  IP address Option

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

   Option-Code

      *  4: Home Agent Address
      *  5: Home Address

6.2.2.  Binding Cache Information Option

   The binding cache information option has an alignment requirement of
   8n+2.  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 13: 10: Binding Cache Information Option

   The binding cache information Binding Cache Information option is only valid in a state
   synchronization State
   Synchronization message.

   The fields of Home Address, Care-of Address, Flags, Sequence Number,
   and Lifetime are copied from the registered binding of a particular
   Mobile Node
   mobile node or Mobile Router. mobile router.  The 8-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.

6.2.3.  AAA Information Option

   The AAA option is used to carry the AAA state of the Mobile Node's
   MIP6 sessions.  The AAA state information can be conveyed in RADIUS
   or Diameter AVP formats including the user and session info.  This
   information option is 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 14: Vendor Specific Inforamtion 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 MIP6 and IPsec/IKE
      sessions.

   Reserved

      16-bit field reserved for future use.  The value SHOULD be
      initialized to zero by
   to zero.  If the sender, and MUST R-flag is set to indicate this binding cache entry
   is for a mobile router, then this option will be ignored immediately followed
   by the
      receiver.

6.2.4.  Vendor Specific one or more Mobile Network Prefix options.

6.2.3.  AAA Information Option

   The Vendor Specific information AAA option is used to carry the vendor
   specific information AAA state of a home agent. the mobile node's
   Mobile IPv6 sessions.  The Vendor Specific AAA state information can be conveyed in
   RADIUS or Diameter AVP formats including the user and session info.
   This information option is only valid in a state synchronization 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      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Vendor Code          |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                 Vendor Specific Information                        AAA AVPs                               .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 15: 11: Vendor Specific Inforamtion Option

   Type

      8-bit Type value.  The value is TBD.

   Length

      8-bit length value.

   Vendor Code

      16-bit

   AAA AVPs

      Series of TLV encoded AAA AVPs (including vendor code can be defined by each vendor.

   Reserved

      16-bit field reserved specific AVPs)
      carrying AAA-related information for future use. each Mobile IPv6 and IPsec/
      IKE session.

7.  Home Agent Operation

7.1.  Home Agent Address Configuration

   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 value SHOULD link between home agents should be
      initialized secured.

   When the Home Agent Virtual Switch mode is used, the virtual home
   agent 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 zero by mobile
   nodes located on the sender, and home link, the neighbor cache of the home agent
   IP address MUST be ignored by carefully operated.  See Section 7.2 in detail.

   When the
      receiver.

7.  Home Agent Operation

7.1. Home Agent Configuration

   There are two approaches to place Standby Home Agents.  The first
   configuration Hard Switch mode is that used, each home agent
   configures itself with a Standby different IPv6 address from the same home
   prefix.  This IPv6 address can be used for the Home Agent is Reliability
   protocol if the standby home agents are located at the same link (i.e. of
   the active home link) agent (Figure 1).  In case of Figure 2, the router
   must carefully route packets to the standby home agents as described
   in Section 7.2.  Once a mobile node registers its binding with the
   active home agent, it may solicit an IPsec/IKE exchange with standby
   home agents.  Another one  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.2.  Consideration of Routing and Neighbor Discovery Protocol

   This section gives a brief explanation of how a home agent interacts
   with routing and Neighbor Discovery Protocol (NDP) when the Home
   Agent Virtual Switch mode is used.

   When a standby home agent becomes active in the Home Agent Virtual
   Switch mode, it MUST 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 Metric field in OSPF for route selection.

   For instance, home agents should run OSPF with the appropriate cost
   so that the
   Standby Home Agent active home agent whose preference is located at highest can receive
   the different link packets from the other routers on the home link.  The differences are whether  When the active
   home agent and Standby Home Agents
   share is down, OSPF detects the link or not.

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

   Figure 16: Local Recovery Configuration

   Figure 16 depicts failure and can dynamically
   switch the configuration where home agents serving route to the
   same standby home network are located Agent based on the same link.  For example, HA3 and
   HA4 are Standby Home Agents of HA1 and HA2.  This is what Mobile IPv6
   defines for OSPF cost
   value.  If this cost conflicts with the home agent configuration.

                 HA1    HA2             HA3    HA4
                  |      |               |      |
          --------+------+-----+ R +-----+------+-------
                  Home Link    Router   Recovery Link

   Figure 17: Global Recovery Configuration

   Figure 17 illustrates when standby home agents are located preference value
   due to misconfiguration, the routers on
   different link (named recovery the home link in may not route
   packets to the figure).  For example, HA3
   and HA4 are desired standby home agents of HA1 and HA2.  In this case, HA3
   and HA4 cannot receive the packets meant for agent.  Therefore, the home network till agent
   MAY dynamically change the route OSPF cost based on the Router is changed.  The advantage home agent
   preference value.  Most of router vendors have a private MIB to set
   the cost via SNMP, though this
   configuration is that Standby Home Agents a vendor-specific function.  The
   operator can recover consider other existing approaches to update routes on
   the failure routers at the home link.

   When an active home agent activates a home agent address, it SHOULD
   use a virtual MAC address as introduced in [4].  When the active home
   agent is changed, the neighbor cache of the active home agent is not
   necessarily updated on mobile nodes located on the home link.  If
   Otherwise, the new home link becomes unreachable, agent MUST update the local
   recovery is useless.  However, this configuration can achieve neighbor cache entry
   for the home agent recovery even if address on all the mobile nodes located on the entire
   home link fails. link.  In this
   configuration, the routing must be also updated addition, Mobile IPv6 uses proxy NDP to direct the intercept
   packets meant for mobile nodes which are away from the home link.
   However, it is unnecessary for the new active home link agent to overwrite
   the recovery link.

   Each Standby existing proxy neighbor entries of the mobile nodes.

7.3.  Home Agent obtains its individual IP address from the List Management

   In Mobile IPv6 [1], each home agent periodically sends router
   advertisements with a Home Address Information option [1] for
   exchanging home agent information when there are multiple home agents
   present on a link.  This IP address information is managed in a home agent list
   introduced in [1].  When the Home Agent Reliability Protocol is used,
   Hello messages are used for to update the home agent reliability protocol list.  There are
   several reasons to
   exchange information with use Hello message instead of Router Advertisement
   on the associated Home Agent Reliability protocol:

   1.  Router Advertisements are sent among home agent. agents and also to
       mobile nodes.  When the Home Agent Virtual Switch is used,
       standby home agents MUST NOT generate unsolicited Router
       Advertisements.  The link
   between standby home agents should MUST be secured.

   When transparent to
       all mobile nodes.  Hello messages are exchanged only with other
       home agents.

   2.  Router Solicitation and Advertisement messages [8] cannot be used
       due to link-local limitations.  However, as shown in Section 5.1,
       standby home agents are not always configured on the same link.
       Router Advertisements cannot be used in this case.

   3.  The Home Agent Virtual Switch Reliability protocol is used, required to exchange
       additional information such as Group ID and Active/Standby Status
       of the home agent's IP address
   which is known by agents.

   When Hello messages are used, the mobile node can be shared with Standby Home
   Agents.  When a home agent fails, Agent Information Option [1]
   MAY NOT be used in Router Advertisements on the standby home agent takes link, because
   all necessary information will be present in the IP
   address out of Hello messages.
   However, mobile nodes located on the failed home agent.  Then the Standby Home Agent
   can uses the IP address link require this
   information for further home agent operations as being an
   Active Home Agent.  The Standby Home Agent should not activate the IP
   address until the Active Home Agent is dead and the reachability discovery.  In addition, if operators want
   to
   the IP address is lost.  Otherwise, address duplication will occurs.
   This operation is normally done using route selector use different parameters such as BGP Preference value for home agents
   and
   OSPF modifier.  As an example we mobile nodes, they can use the AS_Path prepend
   operation for BGP utilize both Router Advertisements and Metric field in the OSPF for route selection.
   The Ha reliability DT may define a new mobility option
   Hello messages.  Router Advertisements are used to carry
   respective BGP/OSPF modifier information.

   Alternatively, in Home Agent Hard Switch case, The home agent address
   may be different, but the home addresses
   agent information for mobile nodes, and the home link prefix Hello message are
   the same.  In this case, all the reachability of mobile nodes will be
   lost during the recovery procedure, since the IP address of Failed used to
   carry information for Home Agent is no longer active and all the packets meant for Reliability operation.  If an
   operator decides not to use the IP
   address will Hello messages, Router Advertisements
   MUST be discarded.  The Standby Home Agent must notify mobile
   nodes used to change update the associating home agent.  Thus, agent list.

   Since Hello messages carry all the mobile node
   will detect necessary information filled-in
   from the home agent changes by knowing list, the new IP address management of the home agent list is
   unchanged.  If a standby home agent.  The agent removes an active home agent from
   the list because it's lifetime has become zero, it can start recovery
   according to use the same technique this document. < xref target="subsec:failuredetection"/>
   describes failure detection in detail.

7.4.  Detecting Home Agent Failure

   The active and standby home agents can monitor each other's status in
   multiple ways.  One method is to reuse other failure detection
   mechanisms such as VRRP[4] and HSRP[5] described in virtual switch mode Section 7.10.
   This document also defines its own method by using periodic exchanges
   of Hello messages to advertise the routes into the routing
   infrastructure.

7.2. monitor status.  The reasons to specify Hello
   messages Manipulation

   Mobile IPv6 [1] defines a mechanism are:

   1.  Hello messages can be sent off-link for maintaining a global recovery is
       required by an operator.  Router Advertisements cannot be used in
       this scenario since their scope is link-local.  Thus, Hello
       messages are necessary to exchange home agent list
   when there are multiple information among
       home agents present on in a link.  It is based
   on each globally redundant home agent sending set.

   2.  If Router Advertisements and VRRP are used for periodic messages,
       they may not detect the case where the system is running but the
       Mobile IPv6 stack is not operational.  Mobile IPv6 may be
       implemented as a router advertisement periodically on userland daemon, so if Hello messages are used,
       the
   home link with failure of a Home Address Information option [1].  However, this
   mechanism home agent can be easily detected, assuming
       Hello message functionality is implemented in the same home agent
       daemon.

   3.  Hello messages can be frequently exchanged to detect failure,
       while there is governed by how a router sends a router advertisement as
   defined in [4].  There are restrictions restriction on how often a router
   advertisement Router Advertisements
       can be sent sent, and on how they are processed by routers that
       receive them.  Moreover, the router advertisements  Router Advertisements are also not sent frequently
       enough to rely on the their absence of the router advertisement to detect a home agent failure.  Moreover, when home agents are
   placed at different links, Router Solicitation and Advertisement
   messages [4] can not

   A Hello request message (R-flag set) may be used due by any home agent to link-local limitation.

   In this document, new Mobility Header messages are defined
   request state information from any other home agent in the redundant
   home agent set.  If a Hello message is not received from a home agent
   peer within a configurable amount of time, then that home agent peer
   is considered to have failed.  The detail of the Hello message is
   described in Section 6.1.1 and Section 6.1.2 7.6.  Failure events used in the Home Agent
   Reliability protocol are listed below.

   Loss of Communication with the Active Peer Home Agent

      In the event that a standby home agent does not receive any Hello
      message from its peer which is currently the active home agent for
      a configurable duration, the standby home agent may decide to notify similar information
      become the active home agent.

   Monitored Server Failure by the Active Home Agent

      There may be number of
   Router Advertisement among critical servers in the network that are
      essential for the ongoing Mobile IPv6 sessions at the home agents agent.
      One such server may be the AAA server which is receiving the
      accounting information for the session.  The operator may have a
      policy in place that requires the home agent to initiate a switch-
      over procedure upon detecting that the link to such a server has
      failed.

   Routing Peer/Link Failure

      In some cases, an operator may require the home link.

7.2.1.  Sending Hello Request

   A home agent can solicit to detect a Hello message by sending
      next-hop routing peer failure.  If the next-hop routing peer
      fails, the operator may want the home agent to initiate a Hello Request
   message.  The Hello Request message switch-
      over procedure if the failure is unicasted fatal in nature, or due to an Active some
      other routing policies.

7.5.  Home Agent or a Standby Home Agent.  This message should be encrypted and
   authenticated by IPsec ESP mode.  An originator of the Hello Request
   message must specify Switch Over

   After detecting the random sequence value.  The sequence active home agent has failed, a standby home
   agent whose preference value is used to match the Hello message which is sent from highest MUST take over for the receiver of
   failed home agent.

   In the Hello Request message.

7.2.2.  Receiving Hello Request

   When a Home Agent Virtual Switch mode, the standby home agent receives a hello Request message, it SHOULD verify
   correct IPsec protection.  If MUST
   activate the message virtual home agent address.  If a virtual MAC address as
   introduced in [4] is not protected, it SHOULD
   be silently discarded.  However, if used, the Hello messages can be sent on
   a dedicated link between standby home agent MUST start using
   the virtual MAC address as well.  Since all the necessary state has
   already been transferred to this standby home agents and in such a case, IPsec
   protection is not required.

   If agent before the sender active
   home agent is not in failed, it can immediately start acting as the active home
   agent.

   In the Home Agent Hard Switch mode, the same redundant standby home agent set,
   the message MUST be silently ignored, too.

   The sequence field should be copied to the Hello send
   a Home Agent Switch message which will
   be sent in reply to all the hello Request message.  This sequence number
   is used as a transaction ID for mobile nodes that were
   registered at the Hello message exchange.

7.2.3.  Sending Hello

   A failed home agent Hello message MUST be constructed with same information
   of a Router Advertisement message as described in section 7 of [1]. Section 7.9,
   using the pre-established IPsec SA.  The home agent switch-over is
   complete when it receives binding updates from all the mobile nodes.

7.6.  Processing Hello Messages

   Hello messages can be unicasted or multicasted.  A new multicast
   address will be assigned by the IANA.  All the home agents on the
   home link should join this multicast address.  When the Hello
   messages are used for maintaining the all home agents list, the home
   agent SHOULD NOT use the home agent Information option in the router
   advertisements to manage the home agents list.

   The Hello message MUST be sent when a home agent is requested by a
   hello Request message.  The Hello message can be also periodically
   sent.  In addition, the home agent SHOULD send a home agent Hello
   message to home agents of the
   redundant home agent set when it boots
   up and its local information such as preference, lifetime, and
   registration status, etc. change.  The interval between two Hello
   messages is configurable are configured on the a same home agents.  When link, they
   MUST join a new home agent
   boots up, it SHOULD wait multicast address (TBA) and multicast Hello.  On the
   other hand, if a particular time to listen home link is separated as described in Figure 2,
   each home agent MUST unicast Hello
   messages of all configured Home Agents.  Alternatively, it can
   solicit messages.

7.6.1.  Requesting Hello message by sending Message

   A home agent can solicit a Hello Request message.

   If message from a particular home agent is
   in the Active Home Agent, it MUST same redundant home agent set A flag in Hello
   Messages.

7.2.4.  Receiving Hello

   The receiver of by unicasting or multicasting a Home Agent
   Hello message with the R-flag set.  The sender MUST verify fill the source
   address field fields
   of the IPv6 header.  If a Home Agent Hello message is
   received from unknown with it's home agent, the agent information.  When a Hello
   message MUST be silently
   dropped.  If the source address is not in unicasted, only the list destination of known home
   agents, the Hello message MUST be silently dropped.  In addition to this
   source address check, Group ID is introduced in this document.  This
   Group ID is used to identify a particular redundant home agent set.
   If will
   answer it.  On the Group ID field is specified in other hand, if a Hello message, message is multicasted, all
   the receiver
   MUST process only home agents in the Hello which multicast group ID is matched.  This Group ID
   is verified when will reply to the Hello message is multicasted.  The
   message.  This Hello request message
   MUST NOT SHOULD be sent to a generated when:

   o  A new home agent whose Group ID is different from the
   sender.  If the Group ID is set needs to zero, collect information of the receiver MUST ignore other home
      agents in the same redundant home agent set.  In this field.

   Any Home Agent case it
      SHOULD multicast a Hello message satisfying all of these tests MUST be
   processed to update its in which the R-flag is set.

   o  A home agent entry in the redundant home agent list.  The Home Agents list can is about to be
   ordered based on the
      removed due to home agent preference value.  If lifetime expiration.

   o  A Hello message has not been received during the specified hello
      interval.

7.6.2.  Sending Hello Message

   The Hello message MUST be sent when a home agent
   lifetime field in the receives a Hello
   message with the R-flag set, indicating a request is set required,
   otherwise Hello messages are periodically sent according to 0, the receiver removes the sender pre-
   configured Hello interval.  In addition, a home agent that from SHOULD send a
   Hello message to the home agents list.

7.3.  Failure Detection

   When a home agent meets an error and cannot fulfill of the redundant home agent
   functionality, the Standby Home Agent must detect the failure set when
   it boots up and
   should act as the Active Home Agent.  The failure detection is
   important feature of Home Agent its local reliability.

   The most common way to detect failure is using periodic message
   exchange information, such as Hello of routing protocols.  This mechanism is often
   used to detect failure on many protocols.  In the real scenario, when
   a home agent crashed, it can happened that only preference,
   home agent
   functionality is down lifetime, and network reachability to home agent is
   alive.  In this case, ICMP type of message such as ping can not be
   used to detect the registration status, etc., change.  When a
   new home agent failure.  Therefore, we define boots up, it SHOULD solicit Hello messages by
   multicasting a new Hello message to detect with the R-flag set in parallel with
   sending own Hello message.

   Whenever a home agent failure.

   The Active and the Standby Home Agents exchange periodic Hello
   messages to monitor one another's status. generates Hello request message may
   be used message, it MUST increment in
   the Sequence Number by any Home Agent to explicitly request state information
   from any other Home Agent 1.  It MUST also specify its own Group ID in
   the redundant Home Agent set. Group ID field of the Hello message.  If a Home
   Agent Hello message home agent is not received from a the
   active home agent, it MUST set the A-flag in it's Hello Messages.  In
   the Home Agent peer within a
   configurable amount Hard Switch mode, the source address of time, then that Hello messages
   MUST be the configured home agent peer is considered
   to have failed.

   Example Failure Events:

   Loss of Communication with address.  In the Active Peer Home Agent

      The redundant Home Agent set should have knowledge Virtual
   Switch mode, the individual IPv6 addresses of each others
      state.  In order to achieve that, we define home agent MUST be
   used.

7.6.3.  Receiving Hello Message

   When a home agent receives a Hello message, it SHOULD verify IPsec
   ESP protection.  If the message
      exchanges.  In is not protected, it SHOULD be
   silently discarded.  However, if the event that Hello messages is sent on a
   dedicated link between the Home Agent that home agents, IPsec protection is currently
      inactive does not receive any
   required.  If a Hello message from its peer which is
      currently active for a configurable duration, the Home Agent may
      decide to become active.

   Monitored Server Failure by the Active Home Agent

      There may be number of critical servers in the network that are
      essential for the ongoing Mobile sent from an IPv6 session at address whose
   scope is not global, the Home Agent.
      One such server may message MUST be silently discarded.

   If the AAA server which sending home agent is receiving the
      accounting information for the session.  The operator may have a
      policy not in place that requires the Home Agent to initiate
      SwitchOver procedure upon detecting that same redundant home agent
   set, the link to such a server
      has failed.

   Routing Peer/Link Failure

      In some cases, message MUST be silently ignored.  This can be done by
   comparing the operator may like Group ID field of the received Hello message with the Home Agent
   own Group ID value.  Hello messages MUST NOT be sent to detect a
      next hop routing peer failure.  If the next hop routing peer
      fails, home agent
   whose Group ID is different from the operator may want sender.  If the Home Agent to initiate SwitchOver
      if Sequence Number
   value in the failure Hello message is fatal in nature or due equal to some other routing
      policies.

7.4.  Active Home Agent Change

   There are two cases when a Standby Home Agent takes over an Active
   Home Agent.  The first case is when a Standby Home Agent detects
   failure of or less than the Active Home Agent described Sequence
   Number value stored in Section 7.3.  The
   Standby Home Agent immediately becomes an Active Home Agent.  The
   second case is when a the home agent receives a Home Agent SwitchOver
   Request list entry, the Hello message described in Section 7.6.

   Upon detecting failure
   MUST be discarded.

   Any Hello message satisfying all of an Active Home Agent, these tests MUST be processed to
   update the Standby Home
   Agent becomes Active.  If there are more than one Standby Home Agent
   or when there are two Home Agents redundant home agent list.  The receiver copies home agent
   information in the Hello message to the corresponding redundant Home Agent set,
   but both home
   agent list entry.  The home agent address of them boots up at the same time, two values are used to
   break any tie.  The Home Agent with lowest BGP/OSPF modifier value
   becomes Active.  If sender is retrieved
   from the BGP/OSPF modifiers are Source Address field of the same, then IPv6 header of the Hello
   message.  If the home agent preference values (configured by the system administrator)
   is used to break the tie.

   When lifetime field in the Standby Home Agent becomes active, it MUST start Hello message is
   set to
   advertise the home agent address and 0, the home prefix of receiver removes the home
   addresses serviced by sender from the redundant home agent set into
   agents list.

   If the routing
   infrastructure.  This R-flag is operated by using route selector such as BGP
   and OSPF modifier.  In addition, if necessary, the new active home
   agent must overwrite set in the neighbor entries of received Hello message, the mobile nodes in
   order receiver MUST
   reply with a Hello message to intercept packets of the mobile nodes.

7.5. originator as described in
   Section 7.6.2.

7.7.  Processing State Synchronization Messages

   It is necessary for Standby Home Agent standby home agents to synchronize the state
   information of each mobile node stored in registered with the active home
   agent.  In the Home Agent Virtual Switch mode, the synchronized state
   information is used by a Standby Home Agent standby home agent when it takes over for
   the Failed Home
   Agent. failed home agent.  In the Home Agent Hard Switch mode, the Standby Home Agent
   standby home agent starts the trigger to switch-over of all the mobile nodes registering
   registered to the Failed Home
   Agent failed home agent when the home agent failure is
   detected.  This state
   synchronization must  Thus, the Binding Cache entry MUST be securely operated.

7.5.1.  Sending modified to keep the
   active home agent address of each mobile node.

7.7.1.  Soliciting State Synchronization Request of a Particular Mobile Node or Subset of Mobile
        Nodes

   When a Standby Home Agent standby home agent wants state information for a particular Mobile Node
   mobile node or a subset of mobile nodes, such as Binding Cache, AAA, etc,
   etc., it can MAY solicit State Synchronization
   message this state by sending a State Synchronization Request.  This is optional
   operation of a standby home agent.  The Standby Home Agent
   message constructed as follows:

   o  It MUST set the Type field to 0 (Request).

   o  It MUST set a random value to the Identifier field in the state synchronization
   Request message and Identifier field.

   o  It MUST include either a Home Address mobility option indicating
      the mobile node, or a Mobile Network Prefix mobility option. option
      indicating the mobile router.  The Standby Home
   Agent standby home agent can store send
      multiple home address mobility options or and mobile network prefix mobility options
      to request state information for multiple mobile nodes by in a single state synchronization Request
      State Synchronization request message.

7.5.2.  Receiving

   When a home agent receives the State Synchronization Request

   If message with the received
   Type field set to 0 (Request), it MUST verify the message as follows:

   o  The state synchronization Request message is not MUST be protected by IPsec ESP, the message must be silently discarded.  If
   the sender ESP.

   o  The sending home agent is not MUST belong to the same redundant home
      agent
   set, the message must be silently ignored.  Moreover, if a set

   o  The receiver
   is not MUST be the Active Home Agent active home agent for the requested home
      address or mobile network prefix, it prefix.

   Any packet carrying a State Synchronization message which fails to
   satisfy all of these tests MUST be silently discard the message. ignored.

   Otherwise, the receiver MUST reply with a State Synchronization
   message including state information for the requested mobile node(s).

7.5.3.  Sending node(s)
   and/or mobile network prefix(es) as described in Section
   Section 7.7.2.

7.7.2.  Synchronizing State Synchronization of Mobile Nodes

   A state synchronization message can be sent either:

   o  when  When an Active Home Agent active home agent receives a state synchronization Request message
      in which the Type field is set to 0 (Request).

   o  when  When an Active Home Agent creates/updates active home agent creates a binding cache entry for a
      particular Mobile Node. mobile node.

   o  When an active home agent deletes a binding cache entry for a
      particular mobile node.

   o  When an active home agent updates a binding cache entry for a
      particular mobile node, only when operating in the Home Agent
      Virtual Switch mode.  In the Home Agent Hard Switch mode, standby
      home agents only use this binding cache information to send a Home
      Agent Switch message, so only need a home address of all the
      mobile nodes registered to the active home agent of the same
      redundant home agent set.

   o  In a periodic interval to update the state info information for all
      sessions that changed since the last update.

   If an Active Home Agent active home agent sends the state synchronization a State Synchronization message
   whenever the local state information changes, such as a binding cache changed,
   change, the size number of the state synchronization message are large.  The Active
   Home Agent should update the state information with an interval which
   is configured by system administrator. State Synchronization messages sent can be
   quite large.

   The binding cache information of the requested Mobile Node are mobile nodes is stored
   in the
   state synchronization State Synchronization message.  The Active Home Agent active home agent MUST
   copy the binding cache information of the requested Mobile Node to each fields of a
   binding cache information option. mobile nodes into
   Binding Cache Information options.  If the state synchronization State Synchronization
   message is sent in response to the state synchronization Request a State Synchronization request
   message, the Active Home Agent active home agent MUST copy the Identifier field of the
   state synchronization Request
   State Synchronization request message to the same filed Identifier field in the state
   synchronization
   State Synchronization reply message.  Otherwise, it MUST set zero to the
   Identifier field.

   The Active Home Agent can store field to 0.

   When the active home agent stores the state of multiple mobile nodes
   in a state synchronization message

7.5.4.  Receiving message, 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.
   When the next Binding Cache Information option is reached in the
   State Synchronization message, it indicates the information of a
   different mobile node.

   A state synchronization State Synchronization message MUST be authenticated and encrypted
   by IPsec ESP mode.  If not, mode, otherwise the message MUST be ignored.  When a Home
   Agent
   home agent receives a state synchronization State Synchronization message, it MUST verify
   the Source address field of the IPv6 header.  If the source address do
   does not belong to any home agents of agent in the redundant home agent set,
   the message MUST be silently discarded.  The receiver  After successfully verifying
   the message, the receiving home agent SHOULD
   record the state MUST update its binding cache
   and all other necessary information such as AAA and vendor specific
   information in the particular database.  In the Active Home Agent Hard
   Switch mode, the receiver MUST also record the IPv6 address into its Binding
   Cache.

7.6. of the
   sender (the active home agent).

7.8.  Processing Home Agent SwitchOver Control Messages

7.6.1.  Sending

7.8.1.  Standby Home Agent SwitchOver Request

   When a Standby becomes an Active Home Agent

   When a standby home agent decides to become an active home agent, it
   MAY send a the
   standby home agent sends a SwitchOver Request message to an Active Home
   Agent.  The reason for the Standby Home Agent to send this message is
   administrative intervention.  The Standby message (a Home Agent sends with a
   mobility header
   Control message in which type the Type field is set to 0) to the active
   home agent SwitchOver
   Request type. agent.  This message must MUST be unicasted to the active home agent
   and MUST be encrypted and authenticated by IPsec ESP.  The Active Home active
   home Agent MUST NOT generate this message.

7.6.2.  Sending Home Agent SwitchOver Reply

   A home agent SwitchOver reply is sent in reply to a home agent
   SwitchOver Request message.

   When a an active home agent receives a home agent SwitchOver Request message, Request, it first
   verifies the received Home Agent Control message.  If the request
   message is not protected by IPsec, it MUST be silently discarded.  In addition, if  If
   the sender home agent is not belong an active home agent, it MUST send a SwitchOver
   Reply message (a Home Agent Control message in which the Type field
   is set to 1) with the same redundant Status field set to 130 (Not active home agent set, the message MUST be silently
   discarded.
   agent).  If a the receiver is an active home agent is and does not an Active Home Agent, want
   this standby home agent to become the active home agent, it replies MUST
   reply a SwitchOver reply with the Status field set to 129
   (Administratively prohibited).  In addition, if the sending home
   agent does not belong to the same redundant home agent set, a
   SwitchOver reply which status Reply message MUST be sent to the sender with the Status
   field set to 128. 132 (Not in same redundant home agent set).  Otherwise,
   the receiver active home agent MUST become a Standby Home Agent
   and replies a standby home agent SwitchOver and reply which status with
   a SwitchOver Reply message with the Status field set to
   zero.

7.6.3.  Receiving Home Agent SwitchOver Reply 0 (Success).

   If a home agent receives a home agent SwitchOver reply, the message Reply message, it MUST be
   protected by IPsec. IPsec ESP.  Otherwise, the message MUST be silently
   discarded.  If a receiver the receiving home agent did not send a home agent SwitchOver
   Request beforehand, message, the message MUST be silently
   discarded. ignored.  If the status Status
   field of the SwitchOver reply Reply message indicates zero, is 0 (Success), the receiver Standby Home Agent receiving
   standby home agent immediately becomes an Active Home
   Agent. active home agent.  If the status
   value in the Status field is greater than 128, 128 an error is has occurred.  Thus,
   In this case, the receiver cannot be MUST NOT become an active home agent.

7.7.  Processing Home Agent SwitchBack Messages

7.7.1.  Sending

7.8.2.  Active Home Agent SwitchBack Request becomes in-active

   When an Active Home Agent active home agent decides to become an in-active home agent
   (i.e.  Standby Home Agent), agent,
   it MAY send sends a home agent SwitchBack Request message to (i.e. a Standby Home Agent. Agent Control
   message with Type field set to 3) to a standby home agent.  The
   reason for the Active
   Home Agent active home agent to send this message is can be
   administrative intervention, and events like Monitored Server Failure
   by the Active Home Agent active home agent or Routing Peer/Link Failure.  The Active Home Agent sends it with a
   mobility header which type is set  This message
   MUST be unicasted to one of the standby home agent SwitchBack
   Request type.  This message must agents and MUST be
   encrypted and authenticated by IPsec ESP.  A Standby Home Agent standby home agent MUST
   NOT generate this message.

7.7.2.  Sending Home Agent SwitchBack Reply

   A home agent SwitchBack reply Reply is sent in reply to a home agent SwitchBack Request message.
   When a home agent receives a home agent SwitchBack Request message, it first
   verifies the message.  If the
   request SwitchBack Request message is not
   protected by IPsec, IPsec ESP, it MUST be silently discarded.  In addition, if  If the sender
   sending home agent of the SwitchBack Request message is not an active
   home agent, the receiver MUST reply with a SwitchBack Reply (a Home
   Agent Control message in which the Type field is set to 4) in which
   the Status field is set to 130 (Not active home agent).  If the
   sending home agent does not belong to the same redundant home agent
   set, the a SwitchBack Reply message MUST be silently
   discarded.  If sent in which the sender Status
   field set to 132 (Not in same redundant home agent of SwitchBack Request message is
   not an Active Home Agent, set).  Otherwise,
   the message MUST be silently discarded.

   If a receiver receiving home agent of MUST send a SwitchBack Request Reply message is already an
   Active Home Agent, it replies home agent SwitchBack reply in
   which
   status the Status field is set to 128.  Otherwise, 0 (Success).  After sending the receiver home agent
   SwitchBack reply, it MUST NOT become an Active Home Agent and replies a active home agent
   immediately.  This is because the active home agent SwitchBack reply
   which status field set to zero.

7.7.3.  Receiving Home Agent is still active
   until it receives the SwitchBack Reply message acknowledging the
   SwitchBack Request.  The standby home agent SHOULD change to active
   at least after LINK_TRAVERSAL_TIME.

   If a home agent receives a home agent SwitchBack reply, the message Reply message, it MUST be
   protected by IPsec.  Otherwise, IPsec ESP, otherwise the message MUST be silently
   discarded.  If a receiver the receiving home agent did not send a home agent SwitchBack
   Request message beforehand, the message MUST be silently
   discarded, too. discarded.
   If the status Status field of the SwitchBack reply Reply message indicates zero, is 0 (Success),
   the receiver receiving home agent immediately becomes an in-Active Home Agent. in-active home agent.
   If the status value in the Status field is greater than 128, some an error is has
   occurred.
   Thus,  In this case, the receiver cannot be become an in-active home
   agent and MUST continue to be an Active Home Agent.

7.8. active home agent.

7.9.  Sending Home Agent Switch Message

   If an Active Messages

   This operation is valid only for the Home Agent fails, another Standby Hard Switch mode.
   The standby home agent MUST send a Home Agent on Switch message as
   defined in [11] to all the mobile nodes that were being served by the
   failed home
   link can take over agent.  Since the Failed active home agent address is recorded
   in each synchronized binding cache, the standby home agent knows
   which mobile nodes were served by the failed home agent.  The Home
   Agent Switch message must be encrypted with a pre-established SA.
   The standby home agent should include its own IPv6 address in the
   Home Agent Hard Switch mode.  This operation message.  Note that a Home Agent Switch message is valid only
   sent to each mobile node served by the home agent.  If there is a
   large number of mobile nodes, sending Home Agent Switch messages will
   cause a lot of signaling overhead on the network.

   When a failed home agent recovers, it MUST re-establish an IPsec SA
   with each mobile node served by its redundant home agent set.
   Otherwise, it cannot be either a standby or active home agent for the
   mobile nodes.  Therefore, it sends a Home Agent Hard
   Switch mode.  The Standby Home Agent MUST send a home agent Switch message defined in [8] with
   the I-flag set to all the mobile nodes that were being served serving by other home agents
   in the Failed Home Agent.  The message must be encrypted with pre-
   established SA.  The standby same redundant home agent should include set, and includes its own IP home agent
   address in the home agent switch message.

   Note Home Agent Addresses field.

7.10.  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 message
   operation.  For example, the VRRP router controlling the IP
   address(es) associated with a virtual router is called the Master,
   and forwards packets sent to each mobile node
   served by these IP addresses.  The election
   process provides dynamic fail over in the forwarding responsibility
   should the Master become unavailable.  Although VRRP is used to
   guarantee home agent.  If there are a large number agent address reachability, it cannot be used for
   state synchronization and explicit switching of mobile
   nodes, sending Master and Backup.
   Thus, the Home Agent Switch messages will cause a lot Reliability protocol cannot be replaced by VRRP.
   This section explains how VRRP can interwork with the Home Agent
   Reliability protocol.

   When VRRP is available, VRRP can replace the Hello message described
   in Section 6.1.3.  However, some of
   signaling overhead information is missed by using
   VRRP.  After receiving a VRRP message, each home agent SHOULD process
   the message and store the information as if it receives Home Agent
   Hello messages Section 7.6.3.  The Home Agents SHOULD still perform
   binding cache synchronization as described in Section 7.7 and SHOULD
   support the Home Agent Switch message as described in Section 7.9.

   In addition to this, VRRP is useful only if all home agents are
   located on the network.

8.  Mobile Node Operation

   Operations described in this section are valid only for same link.  If the home
   agent hard switch mode.  When agents are topologically
   separated, the Home Agent Reliability protocol 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 Switch Rtr ID|   Priority    |Count IPv6 Addr|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |(rsvd) |       Adver Int       |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                       IPv6 Address(es)                        |
       +                                                               +
       +                                                               +
       +                                                               +
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 12: VRRP Packet Format

   The message format of VRRP is used,
   all described in Figure 12.  Each field is
   mapped as follows:

   Virtual Rtr ID

      Group ID is stored in the operations can be skipped.

8.1.  Standby Virtual Rtr ID field.

   Priority

      Home Agent Addresses Discovery

   To provide home agent reliability, one possible solution Preference is stored in the Priority field.  Note that
      VRRP only has 8 bits for the
   Mobile Node authenticate itself Priority field.  Therefore, values
      larger than 255 MUST NOT be assigned to two home agents and creates IPsec
   SA with two home agents in bootstrapping.  When one home agent fails the other home agent could use pre-existing SA preference value.

   Count IPv6 IPv6 Addr

      This field MUST be always be 1.

   Advert Int

      This field MUST be mapped to notify the Mobile
   Node about the failure.

   In Hello Interval field of the Home
      Agent Hard Switch mode, multiple home agent addresses are
   valid in the home network.  In order to discover the home agent
   address, two different mechanisms are defined in the bootstrapping
   solution in split scenario [10].  One is DNS lookup by Hello message, though it only has 12 bytes.

   IPv6 address

      A home agent
   Name, the other address is DNS lookup by Service Name.  Also stored in this field.

   Home Agent Lifetime, Sequence Number and Flags field are missing in integrated
   scenario [11], DHCPv6 is used to provide home agent provision to
   Mobile Node.

   In
   the split scenario, Mobile Node can VRRP packet format.  Therefore, operators SHOULD use DNS lookup by Service Name
   to discover the same
   statically configured value for Home Agent Lifetime.  Each home agents, as defined in [10].  For example, agent
   does not check freshness of received VRRP message because of no
   sequence number.  If VRRP is used, a home agent reliability is required by cannot determine the Mobile Node, DNS lookup by
   Service Name method is recommended for Mobile to discovery multiple
   active home agents addresses.  Therefore Mobile Node will query agent from the DNS SRV
   records with service name VRRP message due to lack of mip6 A flag, and protocol name of ipv6. the DNS
   SRV records includes multiple
   cannot request a VRRP advertisement to other home agents addresses agents.

7.11.  Retransmissions and different
   preference value Rate Limiting

   Standby and weight.  The mobile node SHOULD choose two active home agents from are responsible for retransmissions
   and rate limiting of a State Synchronization Request, Switchover
   Request, SwitchBack Request messages for which they expect a
   response.  The home agent MUST determine a value for the Home Agents list according to there preference value.
   Then initial
   transmission timer:

   o  If the Mobile Node should authenticate itself to both home agents
   via IKEv2 exchange.

   In the integrated scenario, Mobile Node can agent sends a State Synchronization Request message,
      it SHOULD use DHCPv6 to get an initial retransmission interval of
      INITIAL_STATE_SYNC_REQ_TIMER.

   o  If a standby home
   agents provision from MSP or ASP, as already defined in [11].  The
   only requirement is that the DHCPv6 response must include multiple agent sends a Switchover Request message, it
      SHOULD use an initial retransmission interval of
      INITIAL_SWICHOVER_REQ_TIMER.

   o  If an active home agent information in order to support sends a SwitchBack Request message, it
      SHOULD use an initial retransmission interval of
      INITIAL_SWICHBACK_REQ_TIMER .

   If the sending home agent reliability.

8.2.  IKE/IPsec pre-establishment to Home Agents

   After Mobile Node get multiple Home Agent addresses, it need fails to
   trigger multiple IKE exchange with multiple home agents receive a valid matching response
   within the selected from initial retransmission interval, it SHOULD
   retransmit 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.  It should initiate IKE
   for home agents as soon as home registration message until a response is completed. received.  All of the
   above constants are specified in Section 10.

   The Mobile Node retransmission MUST follow standard IKEv2 exchange use an exponential backoff process as
   described in bootstrapping
   solution of split scenario [10], or IKEv1 bootstrap solution [12]. if
   needed by Mobile Node, Home Address configuration maybe included for [1] until either the first IKE exchange.  After its Home Address is assigned home agent receives a response, or
   approved by
   the first home agent, Mobile Node SHOULD register itself
   to timeout period reaches the second value MAC_HARELIABILITY_TIMEOUT
   (16sec).  The home agent by IKE using SHOULD use a separate back-off process for
   different message types and different destinations.  The rate
   limiting of Mobility Header messages is the same Home Address.
   Therefore, no HoA configuration should be used as one in the second IKEv2
   procedure.  Note that the [1].  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
   specified in [1].

8.  Mobile Node sends Binding Update Message to Operation

   Operations described in this section are valid only for the Home
   Agent Hard Switch mode.  When the first Home Agent Virtual Switch is used,
   all these operations can be skipped.

8.1.  Home Agent Addresses Discovery

   To provide home agent.

8.3.  Receiving agent reliability with the Home Agent Hard Switch message

   A
   mode, a mobile node must follow the operation specified in [8] when it
   receives authenticates itself to two or more home agent switch message. agents
   and creates IPsec SAs with them during bootstrapping.  When one home
   agent fails, another home agent can use the pre-existing SA to notify
   the mobile node receives about the failure.

   Multiple home agent addresses are available in a Home Agent Switch message, and if home network.  In
   order to discover these home agent addresses, two different
   mechanisms are defined in the
   message contains bootstrapping solution in the IP address of standby split
   scenario [13].  One is DNS lookup by home agent, it picks agent Name, the
   Standby Home Agent other is
   DNS lookup by Service Name.  DHCPv6 can also be used in the request message as
   integrated scenario [14] to provide home agent provisioning to mobile
   nodes.

   In the Active Home Agent
   and sends split scenario, a Binding Update message to it.  The mobile node have
   already pre-established SA with can use DNS lookup by Service
   Name to discover the home agents, as defined in [13].  For example,
   if home agent and use reliability is required by a mobile node, DNS lookup by
   Service Name method is recommended for the SA mobile node to send
   Binding Update.  However, in this specification, the binding cache
   information is already synchronized among discover
   multiple home agents addresses.  Therefore, mobile nodes will query
   the redundant DNS SRV records with a service name of mip6 and protocol name of
   ipv6.  The DNS SRV records includes multiple home agent
   set, the addresses and
   different preference values and weights.  The mobile node can skip this binding re-registration to the new
   active SHOULD
   choose two or more home agent.  In this case, the mobile node only updates the
   Home Agent address of all agents from the binding update list, MIP6 tunnel end
   points, etc.

9.  Security Considerations

   Mobile IPv6 depends on IPsec and IKE for binding home registration
   described in [5].  A agents list according to
   their preference value.  Then the mobile node must encrypt a binding update sent should authenticate
   itself to a these home agent. agents via an IKEv2 exchange.

   In addition, the integrated scenario, a mobile node exchanges HoTI and HoT
   messages through a home agent by using IPsec tunnel mode.  Therefore,
   before a can use DHCPv6 to get home
   agent failure, these IPsec states (below provisioning from an MSP or ASP, as already defined in [14].
   The only requirement is example)
   should be synchronized among that the DHCPv6 response must include
   multiple home agents of a redundant agents' information in order to support home agent
   set.
   reliability.

8.2.  IKE/IPsec pre-establishment to Home Agents

   After a mobile node may encrypt particular data traffic sent gets multiple home agent addresses, it needs to
   trigger multiple IKE exchanges with theh multiple home agents
   selected from the Internet.

   o  Security Policy Database (SPD) and Selector Information

   o  Security Association (SA) for Binding Registration (SA1 and SA2)

   o  SA for HoTI/HoT Exchange (SA3 and SA4)

   o  SA for Mobile Prefix Discovery (SA5 and SA6)

   o  SA for data packets if any (SA7 home agent list.  Since both IKEv1 and SA8)

   The Home Agent reliability scheme for IKEv2 can be
   used to bootstrap Mobile IPv6 involves IPsec
   tunnel SwitchOver upon Home Agent failure.  There are various ways IPv6, this can be achieved e.g. setting up solution does not introduce any
   new operations to co-operate with IKEv1 or IKEv2.  It should initiate
   IKE for home agents as soon as home registration is complete.

   The mobile node MUST follow the standard IKEv2 exchange in the
   bootstrapping solution of multiple IPsec security
   associations between the Mobile Node and split scenario [13], or the IKEv1
   bootstrapping solution [15].  Home Agent sets.
   Another way could be, Address configuration maybe also
   be included, if necessary, for the first IKE exchange.  After its
   Home Agents periodically check pointing
   IPsec session state including Address is assigned or approved by the per packet sequence numbers for first home agent, mobile
   node SHOULD register itself with the
   Mobile Node.  We can call these two possible second home agent with IKE using
   the same Home Agent redundancy
   modes as follows:

   1. Address.  Therefore, no home address configuration
   should be used in the second IKEv2 procedure.  Note that the mobile
   node only sends a Binding Update message to the first home agent.

8.3.  Receiving Home Agent Hard Switch.  In this mode, the Mobile Node and Switch message

   A mobile node must follow the
       redundant operation specified in [11] when it
   receives a Home Agent Switch message.

   If the I-flag is set negotiates independent IPsec SAs.

   2. in the received Home Agent Virtual Switch.  In this mode, Switch message, the
   mobile node MUST re-key the Mobile Node
       negotiates just one SA for both with the home agent addresses stored
   in the redundant Home Agent Addresses field.  The mobile node MUST NOT change
   its active home agent when the I-flag is set.

   In both  If the home agent
   address is not known from the bootstrapping described in Section 8.1,
   the mobile node MUST NOT start an IKE session with the cases, unknown home
   agent.  Instead, it SHOULD re-start home agent discovery again to
   update its home agent address information.

   When the mobile node maintains only one binding cache
   at any given time.  In the receives a Home Agent Hard Switch case, message without
   I-flag set, and if the message contains the IPv6 address of a standby
   home agent, it SHOULD pick the standby home agent in the mobile
   node needs to switch binding from
   message as the active to Standby Home Agent upon
   failover.  IPsec redundancy need synchronize both SPD, Selector and
   SAD information from one home agent and send a Binding Update message to another
   it.  The mobile node already has a pre-established SA with the home agent.
   agent and should use that SA to send the Binding Update.

9.  Security Considerations

   Since Mobile IPv6 operation requires ESP in transport mode between
   the Mobile Node mobile node and the Home Agent, home agent, we will talk about discuss the ESP field
   synchronization issues between the Mobile Node mobile node and the redundant set
   of home agents.  This synchronization is required only for Home Agents. Agent
   Virtual Switch mode.  Most of fields should be synchronized based on
   RFC4301[6].
   RFC4301 [9].  The ESP header has the following fields:

   SPI

      This field identifies the SAD at the receiver.

      Home Agent Hard Switch Mode

         the Mobile Node and the redundant Home Agent set negotiates
         separate/independent IPsec SAs.  Therefore, the SPI value will
         vary depending on which Home Agent the Mobile Node selects to
         send/receive data packets.

      Home Agent Virtual Switch Mode

      The Mobile Node mobile node negotiates only one IPsec SA.  Hence, the SPI
      value will remain unchanged upon Home Agent SwitchOver. home agent failover.

   Sequence Number

      This field 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.

      Home Agent Hard Switch Mode

         The Mobile Node and the redundant Home Agent set will have
         independent set of sequence numbers.  Therefore, the Mobile
         Node and the Home Agent needs to choose the most appropriate
         sequence number to be used.  Synchronization of the sequence
         number field between the Home Agents is not mandatory in this
         mode of operation.

      Home Agent Virtual Swtich Mode monotonically increasing number.
      The Mobile Node receiver may process the sequence number based on local
      policy.

      The mobile node and the redundant Home Agent home agent set will have the
      same set of sequence numbers for transmit and receive.  Hence,
      synchronization of the sequence number field is mandatory in this
      mode of operation.

      For MIP6 signaling i.e.  BU/BA, HoTi/HoT etc.

      As described in Section 4, the SA1, SA2, SA3, SA4 could be
      synchronized between the Home Agents home agents as these messages are not
      sent continuously.  Moreover for the BU Case, Binding Update case, if the Mobile Node
      mobile node is in the middle of sending a BU Binding Update to the Home Agent
      (Active Home Agent) an
      active home agent for a binding refresh, and the Home Agent active home agent
      is
      crashing not available at that moment.  The Mobile Node moment, the mobile node will not get any
      response from the Home Agent.  The Mobile Node will retry. active home agent.  After
      the Standby Home Agent a standby home agent
      becomes active, the mobile node will retry and it will receive BU the
      Binding Update from the
      Mobile Node mobile node with a sequence number that is
      +n from its last known sequence number for SA1.  For the BA Binding
      Acknowledgement case (SA2), the Standby Home
      Agent standby 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 Mobile Node. mobile node.  The same applies to HoTi and HoT messages with
      SA3 and SA4.  Note that this windowing of the sequence numbers for MIP6
      Mobile IPv6 signaling is only needed to cover the corner cases
      when BU/HoTi Binding Update or HoTi is in air in-flight and the Active Home Agent active home agent
      fails.

      The technique explained above should work fine for user data packets if
      ESP is used 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 each time, IV the Initialization Vector will be delivered in each exchange
      between Mobile Node a mobile node and Home
      Agent, so home agent, this field is not
      necessarily synchronized between home agents.

   Others

      Other fields should be synchronized based on RFC4301[6] RFC4301[9]

   In the Home Agent Hard Switch mode, the Standby Home Agent standby home agent needs to
   send a home agent switch Home Agent Switch message in secure way ( i.e. required using IPsec
   encryption to encryption.  Since the trigger).  The
   mobile node pre-establishes has pre-established an IPsec SA with both the Standby Home Agent, as well as an active and
   standby home agent.  The
   Standby Home Agent agents, the standby home agent can send a trigger the message to
   the mobile node with the pre-established IPsec SA.

10.  Protocol Constants

      INITIAL_STATE_SYNC_REQ_TIMER: 3sec

      INITIAL_SWICHOVER_REQ_TIMER: 1sec

      INITIAL_SWICHBACK_REQ_TIMER 1sec

      LINK_TRAVERSAL_TIME 150msec

11.  Contributors

   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: below are authors that have contributed to this document:

   Samita Chakrabarti

      samita.chakrabarti@sun.com

      samita.chakrabarti@azairenet.com

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Hui Deng

      hdeng@hitachi.cn

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sri Gundavelli

      gundave@cisco.com

      sgundave@cisco.com

   Brian Haley

      brian.haley@hp.com

   Behcet Sarikaya

      bsarikaya@huawei.com

   Ryuji Wakikawa

      ryuji@sfc.wide.ad.jp

11.

12.  Acknowledgements

   This document includes a lot of text from [13] [16] and [14]. [17].  Therefore
   the authors of these two documents are acknowledged.  We would also
   like to thank the authors of the home agent reliability problem
   statement [15] [18] for describing the problem succinctly and Alice Qin
   for her work on the hello protocol.

12.

13.  References

12.1.

13.1.  Normative References

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

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

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

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

   [5]   Li, T., Nordmark, E., Cole, B., Morton, P., and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", D. Li, "Cisco Hot Standby
         Router Protocol (HSRP)", RFC 2461, December 2281, March 1998.

   [5]

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

   [6]

   [7]   Devarapalli, V., "Mobile IPv6 Vendor Specific Option",
         draft-ietf-mip6-vsm-00 (work in progress), December 2006.

   [8]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [9]   Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

12.2.

13.2.  Informative References

   [7]

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

   [8]

   [11]  Haley, B., "Mobility Header Home Agent Switch Message",
         draft-ietf-mip6-ha-switch-01 (work in progress), June 2006.

   [9]

   [12]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
         July 2005.

   [10]

   [13]  Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
         draft-ietf-mip6-bootstrapping-split-02 (work in progress),
         March 2006.

   [11]

   [14]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
         the Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
         progress), October 2005.

   [12]

   [15]  Devarapalli, V. and M. Parthasarathy, "Mobile IPv6
         Bootstrapping with IKEv1",
         draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress),
         March 2006.

   [13]

   [16]  Wakikawa, R., "Inter Home Agents Protocol Specification",
         draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress),
         March 2006.

   [14]

   [17]  Devarapalli, V., "Local HA to HA protocol",
         draft-devarapalli-mip6-nemo-local-haha-01 (work in progress),
         March 2006.

   [15]

   [18]  Faizan, J., "Problem Statement: Home Agent Reliability",
         draft-jfaizan-mipv6-ha-reliability-01 (work in progress),
         February 2004.

Appendix A.  Change Log From Previous Versions

   Changes from draft-ietf-mip6-hareliability-00

   o  Combining State Synchronization Request message and State
      Synchronization message

   o  Combining home agent SwitchOver Request & Reply and SwitchBack
      Request & Reply messages.

   o  Many Editorial Changes

Author's Address

   Ryuji Wakikawa
   Keio University
   Department of Environmental Information, Keio University
   5322 Endo, Fujisawa, Kanagawa  252-8520
   Japan

   Email: ryuji@sfc.wide.ad.jp

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).