MIP6
MEXT (MIP6) Working Group                           R. Wakikawa (Editor)
Internet-Draft                                           Keio University                                                Toyota ITC
Intended status: Standards Track                       November 19, 2007
Expires: May 22,                           July 14, 2008
Expires: January 15, 2009

                    Home Agent Reliability Protocol
                  draft-ietf-mip6-hareliability-03.txt
                  draft-ietf-mip6-hareliability-04.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 May 22, 2008. January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

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

Table of Contents

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

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

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

   4.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . . .  8

   5.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Home Agent Network Configuration . . . . . . . . . . . . . 10
     5.2.  8
     4.1.  Home Agent Virtual Switch  . . . . . . . . . . . . . . . . 11
     5.3.  8
     4.2.  Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12
     5.4.  Active  9
     4.3.  Home Agent Management  . . . . . . . . . . . . . . . 13

   6. . . . 10

   5.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1. 11
     5.1.  New Mobility Header Messages . . . . . . . . . . . . . . . 15
       6.1.1. 11
       5.1.1.  State Synchronization Message  . . . . . . . . . . . . 15
       6.1.2. 11
       5.1.2.  Home Agent Control Message . . . . . . . . . . . . . . 17
       6.1.3. 13
       5.1.3.  Home Agent Hello Message . . . . . . . . . . . . . . . 19
       6.1.4. 15
       5.1.4.  Home Agent Switch Message  . . . . . . . . . . . . . . 21
     6.2. 16
     5.2.  New Mobility Options . . . . . . . . . . . . . . . . . . . 22
       6.2.1. 17
       5.2.1.  IP address Option  . . . . . . . . . . . . . . . . . . 22
       6.2.2. 17
       5.2.2.  Binding Cache Information Option . . . . . . . . . . . 22
       6.2.3. 17
       5.2.3.  AAA Information Option . . . . . . . . . . . . . . . . 24

   7. 18

   6.  Home Agent Operation . . Configuration . . . . . . . . . . . . . . . . . . . 25
     7.1.  Home Agent Address 20
     6.1.  Network Configuration  . . . . . . . . . . . . . 25
     7.2.  Consideration of Routing and Neighbor Discovery
           Protocol . . . . . . 20
     6.2.  Address Configuration for Virtual Switch . . . . . . . . . 21
     6.3.  Address Configuration for Hard Switch  . . . . . . . . . . 25
     7.3. 21

   7.  Home Agent List Management Common Operation  . . . . . . . . . . . . . . . . 26
     7.4.  Detecting . 22
     7.1.  Home Agent Failure List Management . . . . . . . . . . . . . . . 27
     7.5. . 22
     7.2.  Detecting Home Agent Switch Over . . . Failure . . . . . . . . . . . . . . . 28
     7.6. 22
     7.3.  Processing Hello Messages  . . . . . . . . . . . . . . . . 29
       7.6.1. 23
       7.3.1.  Requesting Hello Message . . . . . . . . . . . . . . . 29
       7.6.2. 24
       7.3.2.  Sending Hello Message  . . . . . . . . . . . . . . . . 30
       7.6.3. 24
       7.3.3.  Receiving Hello Message  . . . . . . . . . . . . . . . 30
     7.7. 25
     7.4.  Processing State Synchronization Messages  . . . . . . . . 31
       7.7.1.  Soliciting 26
       7.4.1.  Requesting State of a Particular Mobile Node or
               Subset of Mobile Nodes . Node(s)  . . . . . . . . . . . . . . . 31
       7.7.2. 26
       7.4.2.  Synchronizing State of Mobile Nodes  .  . . . . . . . . 32
       7.7.3.  Explicit Acknowledgement of the State
               Synchronization Reply message  . . . . . . . . . . 27
       7.4.3.  Reliable Transmission by Explicit Acknowledgement  . . 34
     7.8. 28
     7.5.  Processing Home Agent Control Messages . . . . . . . . . . 34
       7.8.1. 29
       7.5.1.  Standby Home Agent becomes an Active Home Agent  . . . 34
       7.8.2. 29
       7.5.2.  Active Home Agent becomes in-active  . . . . . . . . . 35
       7.8.3.  Notification of Home Agent Switch Completion 30
     7.6.  Interworking with VRRP . . . . . 36
     7.9.  Sending Home Agent Switch Messages . . . . . . . . . . . . 36
     7.10. Interworking with VRRP . 31
     7.7.  Retransmissions and Rate Limiting  . . . . . . . . . . . . 32

   8.  Home Agent Virtual Switch  . . . . . 37
     7.11. Retransmissions and Rate Limiting . . . . . . . . . . . . 38

   8. . 34
     8.1.  Consideration of Routing and Neighbor Discovery
           Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34
     8.2.  Home Agent Recovery  . . . . . . . . . . . . . . . . . . . 34

   9.  Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35
     9.1.  Home Agent Recovery  . . . . . . . . . . . . . . . . . . . 35
     9.2.  Sending Home Agent Switch Messages . . . . . . . . . . . . 35
     9.3.  Notification of Home Agent Switch Completion . . . . . . . 36
     9.4.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 40
     8.1. 36
       9.4.1.  Home Agent Addresses Discovery . . . . . . . . . . . . . . 40
     8.2. 36
       9.4.2.  IKE/IPsec pre-establishment to Home Agents . . . . . . . . 40
     8.3. 37
       9.4.3.  Receiving Home Agent Switch message  . . . . . . . . . . . 41

   9. 37

   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 42

   10. 39

   11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 44

   11. 41

   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 45

   12. Contributors . . . 42

   13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 47

   13. 43

   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47

   14. 43

   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
     14.1. 44
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 48
     14.2. 44
     15.2. Informative References . . . . . . . . . . . . . . . . . . 48 44

   Appendix A.  Change Log From Previous Versions . . . . . . . . . . 50 46

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 46
   Intellectual Property and Copyright Statements . . . . . . . . . . 51 47

1.  Introduction

   In Mobile IPv6 [RFC-3775] and NEMO Basic Support[RFC-3963], mobile
   nodes may use Support [RFC-3963], if a bi-directional tunnel with their home agents for all
   traffic with correspondent nodes.  A
   home agent on the home link
   maintains a binding cache entry for each mobile node and uses loses the binding cache entry state, due to route any traffic meant for the mobile node failure or some
   other reason, it results in a loss of service for the mobile network.  If the mobile node nodes.
   It 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 is beneficial to provide high availability beneficial to provide high availability and redundancy for a
   home agent so that mobile nodes can avail of uninterrupted service
   even when one home agent crashes or loses state.

2.  Terminology  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are Home Agent
   Reliability protocol is designed to be interpreted as described in [RFC-2119].

   In this document, synchronize the term mobile node refers to both a mobile node
   [RFC-3775] Mobile IPv6
   states between active and a standby home agents as VRRP[RFC-3768] or
   HSRP [RFC-2281].  A home agent maintains not only binding cache but
   also IPsec and IKE related states per mobile router [RFC-3963].

   Some node.  Mobile IPv6
   mandates IPsec encryption for signaling of the mobility related terms used in this document are defined
   in [RFC-3775] home binding registration
   (BU and [RFC-3753].  In addition or BA) and return routability (HoTI and HoT) as described in replacement
   [RFC-3776].  However, IPsec states synchronization is out of scope in
   this document.  The scope of
   these, the following terms are defined or redefined:

   Active Home Agent

      A home agent that Reliability protocol is currently serving
   limited to the mobile nodes.

   Standby management of Mobile IPv6 related states.  Thus, we
   define two different approaches such as Home Agent

      A home agent which will serve Virtual Switch and
   Home Agent Hard Switch depending on the capability of IPsec state
   synchronization.  In both cases, a mobile nodes when the active node maintains only one
   home agent fails.

   Failed Home Agent

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

   Redundant binding at any given time.

   Home Agent Set

      A group of active and standby home agent(s).  The Group Identifier
      is used to identify a redundant home agent set. Virtual Switch

      The Group ID is
      exchanged by Hello messages.

   Binding Synchronization

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

      This preference value Virtual Switch operation can be used only if IPsec
      state synchronization mechanism is defined for Duplicate available (outside of Home
      Agent Address
      Discovery (DHAAD) in RFC3775.  This protocol uses this preference
      value for home agent selection when an Reliability Protocol).  The IPsec state per mobile node MUST
      be shared between the active home agent has
      failed.  However, an operator can also define an independent value
      used only for the and standby home agent reliability protocol if agents in
      the operator
      wants to have different preference values for DHAAD background.  The active and the standby home
      agent reliability protocol.  A home agent SHOULD NOT use agents are
      addressed by the same
      preference value as other home agents for this protocol.

3.  Problem Statement and Requirements

   In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a
   binding with agent address, although only one home agent.  Thus the active
      home agent represents is accessible with the
   possibility of a single point of failure for Mobile IPv6.  A home agent may be responsible for multiple address.  Each mobile nodes on
      node negotiates just one Security Association with the active home link.
   The
      agent.  In case there is a failure of the active home agent, the
      standby home agent may then result in takes over without the loss of
   connectivity for numerous mobile nodes located throughout the
   Internet.  To overcome this problem, Mobile IPv6 allows deployment node being aware
      of
   multiple home agents on the home link so that upon change in the failure of a
   home agent, a mobile node can re-establish its connection through a
   new home agent.  However,

   Home Agent Hard Switch

      In the base Mobile IPv6 specification does Home Agent Hard Switch, IPsec/IKE states synchronization is
      not
   address home agent failover and dynamic transfer of service from one required.  The home agent to another.  This transfer of service from the failed agents are addressed by different IP
      addresses.  When an active home agent to fails, a new working home agent requires coordination or pre-
   configuration among the home agents regarding security associations,
   transfer of mobile node bindings, and other service information for
   reliable Mobile IPv6 service in will
      receive a deployment scenario.

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

   Reliable Home agent service

      Multiple home agents are available for notification (Home Agent Switch message [RFC-5142]) from
      a standby home prefix agent, and one of
      them actively serves send a Binding Update to the mobile nodes.  A standby
      home agent takes
      over when the active home agent becomes unavailable.  The transfer
      of agent.  In order for the MN-HA association should be transparent mobile node to applications and
      should not take longer than receive the Home
      Agent Switch message securely from the care-of-addresses update procedure
      described in Mobile IPv6 [RFC-3775].

   Availability of a redundant home agent set

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

   State Synchronization

      The information for mobile nodes must be able needs to be synchronized
      between establish an IPsec SA with both the active home agent
      and the standby home agents.  This
      includes agents beforehand.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

   In this document, the Binding Cache, AAA information, other Mobile IPv6 term mobile node refers to both a mobile node
   [RFC-3775] and
      NEMO a mobile router [RFC-3963].

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

   Active Home Agent Reliability
      protocol exchanges only running states of

      A home agent that is currently serving the mobile nodes.
      Therefore, we do not have any specific operation for synchronizing

   Standby Home Agent

      A home agent which will serve the configuration information.  For instance, mobile nodes when Mobile IPv6 is
      operated with Authentication protocol, the synchronizing the
      configurations of the Authentication protocol is out of scope in
      this document.  Operators MAY correctly configure in multiple home
      agents.

   Consideration of IPsec/IKE transfer

      An active
      home agent maintains several IPsec and IKE states for
      mobile nodes.  These states are synchronized within the redundant fails.

   Failed Home Agent

      A home agent set.  The details are described in Section 9.

   Secured Message Exchanges

      The messages used between the home agents that is not available due to transfer binding
      cache information MAY be authenticated and encrypted.

   Failure Detection hardware or software
      failure, system maintenance, etc.

   Redundant home agents must actively check for possible failure Home Agent Set

      A group of
      an active and standby home agent.  If a home agent supports an existing
      failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC-
      2281], it can re-use that mechanism agent(s).  The Group Identifier
      is used to detect the identify a redundant home agent
      failure.  On set.

   Virtual Home Agent Address

      A home agent address shared among home agents in a redundant home
      agent set and used only in the other hand, periodic Hello messages are
      introduced to detect Home Agent Virtual Switch case.
      The address is only acitivated on an active home agent's service availability agent.

   Home Agent Preference

      This preference value is originally defined for Dynamic Home Agent
      Address Discovery (DHAAD) in RFC3775.  This protocol re-uses this document.

   Failure Notification

      If necessary, a mobile node is notified about the
      preference value for home agent selection when an active home
      agent failure by has failed.  However, an operator can also define an
      independent value used only for the standby home agent.

4.  Protocol Design

   Mobile IPv6 depends on IPsec and IKE agent reliability
      protocol if the operator wants to have different preference values
      for DHAAD and the home binding registration as
   described in [RFC-3776]. agent reliability protocol.  A mobile node must encrypt a Binding Update
   sent to a home agent.  In addition, agent
      SHOULD NOT use the same preference value of other home agents.

3.  Problem Statement and Requirements

   In Mobile IPv6 [RFC-3775], a mobile node exchanges HoTI registers and HoT messages through the establishes a
   binding with only one home agent by using IPsec tunnel mode.
   Therefore, before agent.  Thus the home agent failure, these IPsec states should be
   synchronized among home agents represents the
   possibility of a redundant single point of failure for Mobile IPv6.  A home
   agent set.  A is responsible for multiple mobile node may also encrypt particular data traffic sent to nodes on its home link.  The
   failure of the home agent may then result in the loss of connectivity
   for numerous mobile nodes located throughout the Internet.  IPsec information required by  To
   overcome this problem, Mobile IPv6 is listed
   below.

   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 and SA8)

   There are various ways this can be achieved.  One is to setup allows deployment of multiple IPsec security associations between home
   agents on the home link so that upon the failure of a home agent, a
   mobile node and can re-establish its connection through a new home agent.
   However, the base Mobile IPv6 specification does not address home
   agent sets.  Another is to have the failover and dynamic transfer of service from one home agents periodically
   check-point IPsec session state, including the per packet sequence
   numbers, for agent to
   another.  This transfer of service from the mobile node.  Thus, we define two possible failed home agent redundancy modes as follows:

   Home Agent Virtual Switch

      Each mobile node negotiates just one SA with an to a
   new active home agent requires coordination or pre-configuration
   among the home agents regarding security associations, transfer of
   mobile node bindings, and other service information for reliable
   Mobile IPv6 service in a redundant home agent set.  The IPsec state will be shared
      within deployment scenario.

   For the redundant home agent set in the background.  The active
      and reliability solution, we define the redundant following
   requirements:

   Reliable Home agent service

      Multiple home agents are addressed by the same available for a home agent
      address, although only prefix and one of
      them actively serves the active mobile nodes.  A standby home agent is accessible by takes
      over when the active home agent address all becomes unavailable.  The transfer
      of the time.  IPsec/IKE states must MN-HA association should be
      synchronized between the active and standby home agents.  The
      mechanism used transparent to synchronize IPsec state is considered out applications and
      should not take longer than the care-of-addresses update procedure
      described in Mobile IPv6 [RFC-3775].

   Availability of
      scope for this document.  In case there is a failure of the active
      home agent, the standby redundant home agent takes over without the mobile
      node being aware set

      Availability of the change in the home agent.

      In a redundant an active home agent set, address and a single standby home
      agent address is used
      by at the active home agent.  Thus, all bootstrapping period for the mobile node is
      assumed.

   State Synchronization

      The information for mobile nodes served by a
      redundant home agent set MUST associate with the same must be able to be synchronized
      between an active home agent
      (the active and standby home agent) all agents.  This
      includes the time.

   Home Agent Hard Switch

      The home agents are addressed by different IP addresses Binding Cache, AAA information, other Mobile IPv6 and
      NEMO related information.  Note that the Home Agent Reliability
      protocol exchanges only running states of mobile node nodes.
      Therefore, we do not have any specific operation for synchronizing
      the configuration information.  For instance, when Mobile IPv6 is aware
      operated with Authentication protocol, the synchronizing the
      configurations of the change Authentication protocol is out of home agent.  A Mobile node
      and all home agents scope in a redundant
      this document.  Operators MAY correctly configure in multiple home
      agents.

   Consideration of IPsec/IKE transfer

      An active home agent set negotiate
      independent maintains several IPsec SAs.  This mode is especially useful when the
      IPsec/IKE states cannot be synchronized.  However, and IKE states for
      mobile nodes.  These states are synchronized within the redundant
      home agent
      change is not transparent to set.  The details are described in Section 10.

   Secured Message Exchanges

      The messages used between the mobile node.  When 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 fails, a mobile node will receive a notification (a Home
      Agent Switch message [ID-HASWITCH]) from agent.  If a standby home agent, and
      send a Binding Update agent supports an existing
      failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC-
      2281], it can re-use that mechanism to detect the standby home agent.  In order to
      exchange the Home Agent Switch message securely between agent
      failure.  On the
      standby other hand, periodic Hello messages are
      introduced to detect active home agent and agent's service availability in
      this document.

   Failure Notification

      If necessary, a mobile node, the mobile node needs to
      establish an IPsec SA with both is notified about the active and home
      agent failure by the standby home
      agents agent.

4.  Protocol Overview

4.1.  Home Agent Virtual Switch

   A mobile node remains unaware about the change in the redundant home agent set beforehand.

      Since each home agent has a different address, an active home
   agent can be defined for each mobile node.  When a mobile node
      boots, it will discover home agents and create IPsec SAs with
      them.  It will then decide which one of since the home agents have replicated all session state
   including IPsec/IKE/ESP states.  IPsec/IKE/ESP state transfer is its
      active home agent.  For example, when two home agents serve a home
      network, half out
   of scope of this document.

     MN      HA1(active)    HA2(Standby)
      |           |           .
      |<--------->|           | 1. IKE exchange (with HoA assignment)
      |---------->|           . 2. Binding Update
      |<----------|           . 3. Binding Acknowledgment
      |           |           .
      |           |<--------->. 4. State exchanges (binding cache/IPsec)
      |           |           .
      |           X           .  HA1 FAILURE
      |           X           .
      |           X<----------. 5. Failure Detection
      |           X           | 6. HA2 takes over the mobile nodes might register with one home
      agent and the rest HA1
      |           X           |
      |           X           |    RECOVERY COMPLETE

              Figure 1: Overview of mobile nodes with another home agent.  When
      one Home Agent Virtual Switch

   The operations of the Home Agent Virtual Switch mode are shown in
   Figure 1.  A mobile node first attempts the IKE exchange for Security
   Association (SA) setup and home agents fails, a standby home agent, whose
      preference value address assignment (1).  After
   binding registration is next highest than done (2, 3), the failed home agent, can
      trigger a active home agent switch by sending a Home Agent Switch message
      to pushes all
   the states of its mobile nodes that were registered with the a state synchronization message
   (4).  The standby home agent(s) is not active unless it takes over
   from a failed home
      agent.

   In both the cases, Agent.

   When the mobile node maintains only one active home binding at
   any given time.  In agent's failure is detected (5), the Home Agent Hard Switch mode, standby
   home agent activates the mobile node
   needs to switch virtual home agent address on its binding from interface
   and takes over for the active to standby failed home agent
   upon failover.  The bindings are synchronized among agent.  All the home agents in the
   redundant home agent set in share a virtual home agent address and the background when
   routing will ensure only the Home Agent
   Virtual Switch mode is used.

   All new messages defined in this document are defined as Mobility
   Header messages so that the Home Agent Reliability protocol can be
   extended to provide active home link redundancy.

   Finally, the reasons why we defined a new Hello message instead of agent will be reachable
   using VRRP is described in Section 7.3 and Section 7.4.  We also give
   instructions on how operators can run both VRRP and the Home Agent
   Reliability protocol at the same time in Section 7.10.

5.  Protocol Overview

5.1.  Home Agent Network Configuration that virtual home agent address.  The Home Agent Reliability protocol supports two different
   configurations for standby home agents.  Standby home agents agent can be
   placed on
   serve all the same home link as mobile nodes for which the active states are synchronized,
   without any further message exchange, because it has all the
   necessary information which it obtained from the failed home agent, or on a
   different link. agent.

4.2.  Home Agent Hard Switch

   The Global Recovery described below is not included
   in this document, although overview of the Home Agent Reliability protocol can
   support this with slight modifications to home agent operations.

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

                  Figure 1: Local Recovery Configuration Hard Switch is shown in Figure 1 depicts the configuration where home agents serving the same
   home network are located on the same link.  For example, HA2, HA3 and
   HA4 are standby home agents of HA1. 2.
   This mode is not transparent to the same as what Mobile
   IPv6 defines for mobile node when the active home
   agent configuration.

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

                HA1    HA2                     HA3    HA4 failure occurs.

     MN      HA1(active)    HA2(Standby)
      |           |           |
      |<--------->|           |
         --------+------+-----+ R---R---R +-----+------+-------
               Home Link          Routers     Recovery Link 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
      |<--------------------->| 8. Binding Registration
      |           X           |
      |           X           |    RECOVERY COMPLETE

               Figure 2: Global Recovery Configuration

   Figure 2 illustrates when standby Overview of Home Agent Hard Switch

   The mobile node establishes IPsec/IKE state with all the home agents are located on a
   different link (named the recovery link
   in Figure 2).  HA3 and HA4
   are standby the redundant home agents of HA1 and HA2.  In this case, HA3 agent set beforehand (1 and HA4
   cannot receive packets meant for 4), however it
   registers its binding only with the active home network until agent (2 and 3).
   When an active home agent fails, a standby home agent uses a pre-
   existing IPsec SA to notify the route on mobile node about the Routers is changed. failure by
   securely sending a Home Agent Switch message.  In order to discover
   home agent addresses, two different mechanisms are defined, as
   described in Section 9.4.1.  The advantage active home agent synchronizes the
   required states of this configuration is that the mobile nodes, such as Binding Cache and AAA
   information, with other standby home agents can recover from periodically (5).  The
   mobile node MUST NOT request a failure of the home link.
   This configuration can achieve home agent recovery even if address(es) assignment through
   the entire
   home link fails.  In this configuration, the routing must be also
   updated to direct the packets meant for IKE exchange to the standby home link to agent when it establishes an SA
   with it (4).

   When the recovery
   link.

   This geographic redundancy is not a requirement by most SDOs
   (Standards Development Organization), but is required by operators.
   Most large operators have a very stringent requirement on network
   availability even in standby home agent detects the worst type failure 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 the active home
   agent (6), it sends a downtime due Home Agent Switch message to any reason, all the sessions will
   be seamlessly taken over by the mobile
   nodes in region-2.  This is called
   geographic redundancy.  This is a well-known configuration for
   Telecommunications operators.

5.2. that were registered with the failed home agent (7).  The Home
   Agent Virtual Switch

   A message must be encrypted by a pre-established IPsec SA.
   After the switch message, the mobile node remains unaware about the change in MUST send a binding update
   to the new active home agent since the home agents have replicated all session state
   including in order to update the IPsec/IKE/ESP states.  The IPsec/IKE/ESP state transfer
   is out of scope of this document.

     MN Mobile IPv6
   tunnel end points (8).

4.3.  Home Agent Management

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

                    Figure 3: Overview of Manual Home Agent Virtual Switch

   The operations of Change

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

   When becomes the active home agent's failure is detected (5), agent.  HA2 will
   acknowledge the message by sending a SwitchBack Reply message to HA1.
   HA1 becomes a standby home agent activates the IP address of the failed home agent on when it
   and takes over for receives the failed home agent.  All SwitchBack
   Reply.  After the home agents downtime, HA1 sends a SwitchOver Request to HA2 in
   order to become the
   redundant home agent set share a virtual active home agent address and the
   routing will ensure again.

   The SwitchCompl message is used only in the Home Agent Hard Switch.
   As shown in Section 9, it takes certain time to complete the active home agent will be reachable
   using that virtual home
   agent address.  The standby switch.  Thus, the old active home agent can
   serve all continues serving the
   received packets for the mobile nodes for which during the states are synchronized,
   without any further message exchange, because it has all switch process.  As
   soon as the
   necessary information which new home agent completes the recovery, it obtained from sends
   SwitchCompl message to the failed previous active home agent.

5.3.  Home Agent Hard Switch

   The overview of the Home Agent Hard Switch  SwitchCompl
   is shown an optional operation in Figure 4. this specification.

5.  Messages

5.1.  New Mobility Header Messages

5.1.1.  State Synchronization Message

   This mode message is not transparent used to the exchange state corresponding to a particular
   mobile node when node(s).  It MUST be unicasted and MUST be authenticated by
   IPsec ESP.  This message has the active home
   agent failure occurs.

     MN      HA1(active)    HA2(Standby)
      |           |           |
      |<--------->|           | 1. IKE exchange (with HoA assignment)
      |---------->| MH Type value TBD.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       | 2. Binding Update
      |<----------|     Type      |A|   Reserved  | 3. Binding Acknowledgment
      |<--------------------->| 4. IKE exchange (without HoA assignment)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identifier            |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |           |<--------->. 5.
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: State exchanges (binding cache)
      |           |           |
      |           X           |  HA1 FAILURE
      |           X           |
      |           X<----------| 6. Failure Detection
      |<----------------------| 7. Sending Home Agent
      |           X           |          Switch message
      |<--------------------->| 8. Binding Registration
      |           X           |
      |           X           |    RECOVERY COMPLETE

               Figure 4: Overview Synchronization Message

   Type

      8-bit unsigned integer.  It can be assigned one of Home Agent Hard Switch

   The mobile node establishes IPsec/IKE the following
      values:

         0: Request

         This message is called State Synchronization Request (SS-REQ)
         and used to solicit the active state with all corresponding to a
         particular mobile node.

         1: Reply

         The message is called State Synchronization Reply (SS-REP) and
         is used between the home agents in the redundant home agent set beforehand (1 and 4), however it
   registers its
         to exchange binding only with the active home agent (2 cache information and 3).
   When an active home agent fails, a standby home agent uses a pre-
   existing IPsec SA any other information
         related to notify the mobile node about the failure by
   securely sending a Home Agent Switch message.  In order providing mobility service 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 AAA
   information, with other standby home agents nodes
         either periodically (5).  The
   mobile node MUST NOT request or in response to a home address(es) assignment through
   the IKE exchange SS-REQ.

         2: Reply-Ack

         The message is called State Synchronization Reply-Ack (SS-ACK)
         and is used to acknowledge to the standby home agent SS-REP.  This message is
         optional and is specially used when it establishes an SA
   with it (4).

   When the standby links between home agent detects
         agents are not reliable.

   Ack flag

      This flag is valid only for SS-REP.  If the failure of the active home
   agent (6), sender requires
      explicit acknowledgment by SS-ACK, it sends a Home Agent Switch message MUST set this flag.

   Reserved

      This field is unused.  It MUST be initialized to all zero by the mobile
   nodes
      sender and MUST be ignored by the receiver.

   Identifier

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

   Mobility Options

      Variable-length field of such length that were registered with the failed home agent (7). complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The Home
   Agent Switch encoding
      and format of defined options are described in [RFC-3775].  The
      receiver MUST ignore and skip any options which it does not
      understand.  This message must requires at least one mobility option,
      therefore, there is no default length for this message.

      One of the following options is mandatory in SS-REQ message.
      Multiple same options can be encrypted by a pre-established IPsec SA.
   After stored in the switch same SS-REQ message,
      (ex. two IP address options for two mobile nodes):

      *  IP Address Option (Sub-type: Home Address) defined in [RFC-
         5268].  If a home agent wants the Binding Cache information for
         a particular mobile node, it includes the mobile node MUST send node's home
         address in an IPv6 Address Option.  If a binding update home agent want to
         solicit all the new active mobile nodes' states, it can include the
         unspecified address (0::0) in an IPv6 address option.

      *  Mobile Network Prefix Option.  If a home agent in order wants to update the Mobile IPv6
   tunnel end points (8).

5.4.  Active Home Agent Management

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

                    Figure 5: Manual Home Agent Change

   In some scenarios the active home agent may need to stop serving
   mobile nodes for system maintenance.  This specification provides for
   a manual home agent switch by using SwitchBack Request and Reply
   messages.  As shown in Figure 5, the active home agent (HA1) sends a
   SwitchBack Request message to a standby home agent (HA2).  As soon as
   HA2 receives the message, it becomes the active home agent.  HA2 will
   acknowledge the message by sending a SwitchBack Reply message to HA1.
   HA1 becomes a standby home agent when it receives the SwitchBack
   Reply.  After the downtime, HA1 sends a SwitchOver Request to HA2 in
   order to become the active home agent again.

   The SwitchCompl message is used only in the Home Agent Hard Switch.
   As shown in Section 5.3, it takes certain time to complete the home
   agent switch.  Thus, the old active home agent continue serving the
   received packets for the mobile nodes during the switch process.  As
   soon as the new home agent takes over all the mobile nodes, it sends
   SwitchCompl message to the previous active home agent.  This is
   optional operation in this specification.

6.  Messages

6.1.  New Mobility Header Messages

6.1.1.  State Synchronization Message

   This message is used to exchange state corresponding to a particular
   mobile node(s).  It MUST be unicasted and MUST be authenticated by
   IPsec ESP.  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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |     Type      |A|   Reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identifier            |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

         2: Reply-Ack (optional)

         The message is called State Synchronization Reply-Ack and is
         used to acknowledge to the State Synchronization Reply message.
         This message is optional and is used when the link between two
         home agents is not reliable.

   Ack flag

      This flag is valid only for State Synchronization Reply message.
      If the sender requires explicit acknowledgment (i.e.  State
      Synchronization Reply-Ack), it MUST set this flag.

   Reserved

      This field is unused.  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
      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 [RFC-3775].  The
      receiver MUST ignore and skip any options which it does not
      understand.

      One of the following options is mandatory in State Synchronization
      Request message.  Multiple same options can be stored in the same
      request message, (ex. two IP address options for two mobile
      nodes):

      *  IP Address Option (Sub-type: Home Address) defined in [RFC-
         4068].  If a home agent wants the Binding Cache information for
         a particular mobile node, it includes the mobile node's home
         address in an IPv6 Address Option.  If a home agent want to
         solicit all the active mobile nodes' states, it can include the
         unspecified address (0::0) in an IPv6 address option.

      *  Mobile Network Prefix Option.  If a home agent wants to know know
         the forwarding state setup for a particular Mobile Network
         Prefix, it includes a Mobile Network Prefix Option as defined
         in [RFC-3963].

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

      One of the following options is mandatory in State Synchronization
      Reply. : SS-REP:

      *  Binding Cache Information Option

      *  AAA Information Option

      *  Vendor Specific Mobility Option

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

6.1.2.

5.1.2.  Home Agent Control Message

   This message is used to control the status of a home agent to either
   active or standby.  This message MUST be unicasted between home
   agents and MUST be authenticated and encrypted by IPsec ESP.  The
   Home Agent Control message has the MH Type value TBD.  When  If no options
   are present in this
   value message, no padding is indicated in the MH Type field, the format of the Message
   Data field in necessary and the Mobility Header is as follows:
   Len field will be set to 1.

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

                   Figure 7: 5: Home Agent Control Message

   Type

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

         0: SwitchOver Request

         This message is called SwitchOver Request. (SO-REQ)

         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. (SO-REP)

         It is used to acknowledge the receipt of the corresponding SwitchOver
         Request. SO-
         REQ.

         2: SwitchBack Request

         This message is called SwitchBack Request. (SB-REQ)

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

         3: SwitchBack Reply

         This message is called SwitchBack Reply. (SB-REP)

         It is used to acknowledge the receipt of the corresponding SwitchBack
         Request. SB-
         REQ.

         4: Switch Complete (SW-COMP)

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

   Status

      8-bit unsigned integer indicating the disposition of a Switchover
      Request SO-REQ or SwitchBack Request message.
      SB-REQ.  This field is only valid in SwitchOver Reply SO-REP and SwitchBack Reply messages. SB-REP.  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 SO-REQ is not the
         active home agent)

         131: Not standby home agent (The receiver of the SwitchBack
         Request SB-REQ 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 [RFC-3775].  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.3.

5.1.3.  Home Agent Hello Message

   This messages can be replaced by other protocols as described in
   Section 7.10.  If this

   The Home Agent Hello (HA-HELLO) message is used, it MUST be either unicasted or
   multicasted to carry home agent information among the redundant home
   agent set.  The Hello HA-Hello message is defined for two purpose: 1) an
   alive check and 2) home agent information exchange.  A home agent
   Hello message HA-HELLO
   SHOULD be authenticated and encrypted by IPsec ESP when it is
   unicasted.  If a Hello HA-Hello message is multicasted, IPsec ESP cannot be
   applied.  In this case the redundant home agent set should be located
   in a secure network.  Alternatively, all the home agents MUST have a
   secure channel with each other.  The Hello message HA-Hello has the MH Type value
   TBD.  When this value is indicated  If no options are present in the MH Type field,
   the format this message, 0 octets of padding
   are necessary and the Message Data field in the Mobility Header is as
   follows: Len field will be set to 2.

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

                    Figure 8: 6: Home Agent Hello Message

   Sequence #

      16-bit unsigned integer.  The Sequence number of the Hello HA-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 the HA-Hello message.  This preference is the same as the
      Home Agent Preference value of the Home Agent Information option
      as defined in [RFC-3775].  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
      the HA-Hello message.  This lifetime is the same as the Home Agent
      Lifetime value of the Home Agent Information option as defined in
      [RFC-3775].

   Hello Interval

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

   Group Identifier

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

   A flag

      Active Home Agent flag.  If this flag is set, the sender of this Hello
      HA-Hello message is an active home agent.  Otherwise, the sender is a standby home agent.

   R flag

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

   Reserved

      This field is unused.  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 [RFC-3775].  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 are
      necessary and the Header Len field will be set to 2.

6.1.4.

5.1.4.  Home Agent Switch Message

   This message is defined in Section 8.3. 9.4.3.  The Home Agent Reliability
   protocol extends this message for the Home Agent 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   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      .                      Home Agent Addresses                     .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                        Mobility options                       .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9: 7: Home Agent Switch Message

   IPsec Re-key (I)

      The IPsec rekey re-key (I) bit is set to indicate that the mobile node
      SHOULD start an IPsec re-key with the home agent specified in the
      Home Agent Addresses field.  This flag is used when a failed home
      agent recovers and needs to re-establish IPsec SA/IKE state with a
      mobile node.  When this flag is set, the mobile node does not
      switch the home agent, but only re-key the SA.

   Reserved

      The reserve field is reduced from 8 to 7 bits

6.2.

5.2.  New Mobility Options

6.2.1.

5.2.1.  IP address Option

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

   Option-Code

      *  4: Home Address

6.2.2.

5.2.2.  Binding Cache Information Option

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

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

                Figure 10: 8: Binding Cache Information Option

   The Binding Cache Information option is only valid in a 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 or 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.

5.2.3.  AAA Information Option

   The AAA

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

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

               Figure 11: 9: 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 Mobile IPv6 and IPsec/
      IKE session.

7.  Home Agent Operation

7.1.

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

6.1.  Network Configuration

   The link between home agents should be 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 Reliability protocol supports two different
   configurations for standby home agents.  When a home agent fails, the standby home
   agent activates the IPv6 address of the failed home agent and becomes
   the active home agent.  The standby home agent should not activate
   the IPv6 address until it knows the active home agent is no longer
   reachable at the address, otherwise address duplication will occur.
   To guarantee transparency of the home agent virtual switch to mobile
   nodes located on the home link, the neighbor cache of the  Standby home agent
   IP address MUST agents can be carefully operated.  See Section 7.2 in detail.

   When
   placed on the Home Agent Hard Switch mode is used, each same home agent
   configures itself with link or on a different IPv6 address from the same home
   prefix.  This IPv6 address can be used for the link.

                 HA1    HA2    HA3    HA4 .... HAn
                  |      |      |      |        |
          --------+------+------+------+--------+---------
                             Home Agent Reliability
   protocol if Link

                  Figure 10: Local Recovery Configuration

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

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

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

                 Figure 2, the router
   must carefully route packets to the 11: Global Recovery Configuration

   Figure 11 illustrates when standby home agents are located on a
   different link (illustrated as described Recovery Link in Section 7.2.  Once Figure 11).  Most
   large operators have a mobile node registers its binding with very stringent requirement on network
   availability even in the
   active home agent, it may solicit an IPsec/IKE exchange with standby
   home agents. worst type of disaster or outage.  For
   example, HAs in region-1 are backed up by HAs in region-2.  These packets must be routed two
   regions are geographically separated.  If region-1 suffers a downtime
   due to any reason, all the recovery link.
   This can sessions will be achieved seamlessly taken over 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 nodes in region-2.  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. called geographic redundancy.  This operation
   is
   normally done using a route selector such as BGP or an OSPF modifier.
   For example, we well-known configuration for Telecommunications operators.  It
   can use achieve home agent recovery even if the AS_Path prepend operation for BGP, entire home link fails.
   In Figure 11, HA3 and
   the Metric field in OSPF for route selection.

   For instance, HA4 are standby home agents should run OSPF with the appropriate cost
   so that the active home agent whose preference is highest can of HA1 and HA2.  In
   this case, HA3 and HA4 cannot receive
   the packets from the other routers on meant for the home link.  When
   network until the active
   home agent route on the Routers is down, OSPF detects changed.  The routing must
   be also updated to direct the failure and can dynamically
   switch packets meant for the route home link to the
   recovery link.

6.2.  Address Configuration for Virtual Switch

   Each standby home Agent based on the OSPF cost
   value.  If this cost conflicts with agent obtains its individual IPv6 address from its
   attached link.  This IPv6 address is used by the home agent preference value
   due
   reliability protocol to misconfiguration, the routers on exchange information with the associated home
   agents.  The link may not route
   packets to between home agents should be secured.

   The virtual home agent's IPv6 address which is known by the mobile
   node is shared with the desired standby home agent.  Therefore, the agents.  When a home agent
   MAY dynamically change the OSPF cost based on
   fails, the standby home agent
   preference value.  Most of router vendors have a private MIB to set
   the cost via SNMP, though this is a vendor-specific function.  The
   operator can consider other existing approaches to update routes on
   the routers at activates the IPv6 address of the
   failed home link.

   When an agent and becomes the active home agent activates a agent.  The standby
   home agent address, it SHOULD
   use a virtual MAC should not activate the IPv6 address as introduced in [RFC-3768].  When until it knows the
   active home agent is changed, no longer reachable at the neighbor cache address, otherwise
   address duplication will occur.  To guarantee transparency of the active
   home agent is not necessarily updated on virtual switch to mobile nodes located on the home
   link.  Otherwise, link,
   the neighbor cache of the new home agent IP address MUST update the neighbor cache
   entry be carefully
   operated.  See Section 8.1 in detail.

6.3.  Address Configuration for Hard Switch

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

   Each home agent configures itself with a different IPv6 address on all from
   the mobile nodes same home prefix.  This IPv6 address can be used for the Home
   Agent Reliability protocol if the standby home agents are located on at
   the same link of the active home link. agent (Figure 10).  In addition, Mobile IPv6 uses proxy NDP to intercept case of
   Figure 11, the router must carefully route packets meant for to the standby
   home agents as described in Section 8.1.  Once a mobile nodes which are away from node
   registers its binding with the active home link.
   However, agent, it is unnecessary may solicit an
   IPsec/IKE exchange with standby home agents.  These packets must be
   routed to the recovery link.  This can be achieved by installing host
   routes for the new active standby home agent to overwrite agents on the existing proxy neighbor entries recovery link of the mobile nodes.

7.3.
   router.

7.  Home Agent Common Operation

7.1.  Home Agent List Management

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

   1.  Router Advertisements are sent among home agents and also to
       mobile nodes.  When  In the Home Agent Virtual Switch mode is used, mode, if the standby home agents MUST NOT generate
       send unsolicited Router
       Advertisements.  The Advertisements to the home link, the
       mobile nodes attached to the home link are aware of the presence
       of standby home agents.  However, the standby home agents MUST must be transparent to
       all mobile nodes.  Hello
       hidden until the active home agent fails.  HA-Hello messages are
       exchanged only with other between home agents.

   2.  Router Solicitation and Advertisement messages [RFC-2461] cannot
       be used due to link-local limitations.  However, as  As shown in Section 5.1, 6.1, standby home agents are not always
       configured on at the same link.  In this case, Router Advertisements
       cannot be used in this case. sent to the recovery link unless the home link and the
       recovery link are connected (ex.  L2TP).  HA-HELLO can be sent
       beyond the link.

   3.  The Home Agent Reliability protocol is required defines to exchange manage additional
       information such as Group ID and Active/Standby Status of the
       home agents.

   When Hello messages are used, the Home Agent Information Option [RFC-
   3775] MAY NOT be used in Router Advertisements on the home link,
   because all necessary information will be present agents in the Hello
   messages.  However, mobile nodes located on the home link require
   this information for home agent discovery. list.

   In addition, if operators
   want to use different parameters such as Preference value for home
   agents and mobile nodes, they can utilize both Router Advertisements
   and Hello messages. Mobile IPv6, Router Advertisements Advertisement are used to carry the home agent
   information for to both mobile nodes, nodes on the home link and Hello message are used to
   carry information for the home
   agents.  On the other hand, in the Home Agent Reliability operation.  If an
   operator decides not protocol,
   HA-Hello is to use exchange the information among the home agents and the Hello messages,
   Router Advertisements
   MUST be Advertisement is used to update notify the information to the mobile
   nodes.  The home agent list.

   Since Hello messages carry all agents SHOULD NOT process the necessary information filled-in
   from Home Agent Information
   option carried by Router Advertisement if HA-HELLO is available.
   Operators can define different values to the parameters of the home
   agent list, the information for HA-HELLO and Router Advertisement.  The
   management operation of the home agent list is
   unchanged.  If a standby home agent removes an active home agent from
   the list because its lifetime has become zero, it can start recovery
   according to this document.  Section 7.4 describes failure detection unchanged and defined
   in detail.

7.4. [RFC-3775].

7.2.  Detecting Home Agent Failure

   The active and standby home agents can monitor each other's status other in
   multiple several
   ways.  One method is to reuse other failure detection mechanisms such as
   defined in VRRP[RFC-3768] and HSRP [RFC-2281] described in (see Section 7.10. 7.6).
   However, VRRP and HSRP cannot detect the case where the system is
   running but the Mobile IPv6 stack is not operational.  In the Home
   Agent Reliability protocol, a new message called HA-HELLO is
   periodically exchanged in the redundant home agent set as a heart-
   beat.  If HA-HELLO is implemented as a part of Mobile IPv6 stack, it
   can detect the home agent failure (Mobile IPv6 stack failure).  This document
   HA-HELLO can also defines its own method by using
   periodic exchanges of Hello messages be exchanged frequently enough to monitor status.  The reasons detect the
   failure promptly and does not introduce any processing overhead to specify Hello messages are:

   1.  Hello messages can be sent off-link for global recovery is
       required by an operator.  Router Advertisements cannot be
   the mobile node attached to the home link.

   Failure events used in
       this scenario since their scope the Home Agent Reliability protocol are listed
   below.

   Loss of HA-HELLO

      In the event that a standby home agent does not receive any HA-
      HELLO from its peer which is link-local.  Thus, Hello
       messages are necessary to exchange currently the active home agent information among for a
      configurable duration, the standby home agent assumes the active
      home agent's failure.  Any home agents can also request the home
      agent information of the other home agent in a globally the same redundant
      home agent set by sending HA-HELLO with R-flag set.

   2.  If Router Advertisements and VRRP are used for periodic messages,
       they may HA-HELLO
      is not detect the case where replied from the system target home agent within a configurable
      amount of time, that home agent peer is running but considered to have failed.
      The detail of the
       Mobile IPv6 stack Hello message is not operational.  Mobile IPv6 described in Section 7.3.

   Monitored Server Failure by the Active Home Agent

      There may be
       implemented number of critical servers such as a userland daemon, so if Hello messages AAA server in the
      network that are used, essential for the failure of ongoing Mobile IPv6 sessions at
      the home agent.  Operators can have a policy in place that the
      active home agent can be easily detected, assuming
       Hello message functionality is implemented in treated as a failed home agent upon detecting
      that the link to such servers has failed.

   Routing Peer/Link Failure

      Operators may require the same home agent
       daemon.

   3.  Hello messages can be frequently exchanged to detect failure,
       while there its next-hop
      routing peer failure.  If the next-hop routing failure is fatal in
      nature, or due to some other routing policies, the active home
      agent is treated as a restriction on how often Router Advertisements
       can be sent, failed home gent and on how they are processed the recovering
      operation should be started.

7.3.  Processing Hello Messages

   HA-HELLO MUST be either unicasted or multicasted.  A new multicast
   address (all_homeagent_multicast_address) will be assigned by routers that
       receive them.  Router Advertisements the
   IANA.  When all the home agents in a redundant home agent set are also not sent frequently
       enough to rely
   configured on their absence to detect a same home link, they MUST join the
   all_homeagent_multicast_address.  On the other hand, if a home
   recovery link is separately defined as described in Figure 11, each
   home agent failure.

   A SHOULD unicast HA-HELLO.

7.3.1.  Requesting Hello request message (R-flag set) may be used by any Message

   A home agent can solicit HA-HELLO to
   request state information from any other a particular home agent in the
   same redundant home agent set by unicasting HA-HELLO with the R-flag
   set.  If a Hello message is not received from a  The sender MUST fill the fields of the HA-HELLO with its home
   agent
   peer within information.  If a configurable amount of time, then that home agent peer
   is considered needs to have failed.  The detail of request HA-HELLO to all
   the Hello message is
   described in Section 7.6.  Failure events used in home agents, it sends the Home Agent
   Reliability protocol are listed below.

   Loss of Communication HA-HELLO with R-flag set to the Active Peer Home Agent

      In the event that a standby
   all_homeagent_multicast_address.  Requesting HA-HELLO SHOULD be
   operated when:

   1.  A new home agent does not receive any Hello
      message from its peer which is currently needs to collect the active information of all the
       other home agent for
      a configurable duration, agents in the standby same redundant home agent may decide set.  The HA-
       HELLO with R-flag set is multicasted to
      become the active
       all_homeagent_multicast_address.

   2.  A home agent.

   Monitored Server Failure by the Active Home Agent

      There may be number of critical servers agent entry in the network that are
      essential for the ongoing Mobile IPv6 sessions at redundant home agent list is about to
       be removed due to home agent lifetime expiration.  The HA-HELLO
       with R-flag set is unicasted to the home agent.
      One such server may be agent whose lifetime is
       soon expired.

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

7.3.2.  Sending Hello Message

   Each home agent periodically sends HA-HELLO for the session. home agent's
   failure detection.  The operator may have interval time is configured at each home
   agent.  Each home agent MUST also send a
      policy HA-HELLO in place that requires the following case:

   1.  when a home agent to initiate receives a switch-
      over procedure upon detecting that HA-HELLO with the link to such R-flag set

   2.  When a server has
      failed.

   Routing Peer/Link Failure

      In some cases, an operator may require the home agent to detect detects its local information such as home
       agent preference, home agent lifetime, and registration status
       change.

   3.  When a
      next-hop routing peer failure.  If the next-hop routing peer
      fails, the operator may want the new home agent to initiate boots up, it SHOULD solicit Hello messages
       by multicasting a switch-
      over procedure if Hello message with the failure is fatal R-flag set in nature, or due to some
      other routing policies.

7.5.  Home Agent Switch Over

   After detecting parallel
       with sending its own Hello message.

   When a home agent sends HA-HELLO, the active following rule MUST be applied.

   o  Whenever a home agent generates HA-HELLO, it MUST increment in the
      Sequence Number.  The Sequence Number SHOULD be initialized to
      zero for the first Hello message.  To accomplish sequence number
      rollover, if the sequence number has failed, already been assigned to be
      the standby largest possible number representable as a 16-bit unsigned
      integer, then when it is incremented it will then have a value of
      zero (0).

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

   o  If a home agent whose preference value is the highest active home agent, it MUST take over for set the A-flag
      in HA-HELLO.

   o  In the
   failed home agent.  Alternately, if Home Agent Control messages are
   used, a standby home agent who will Hard Switch mode, the source IPv6 address of HA-
      HELLO MUST be the new active home agent is
   determined during the Home Agent Control message exchanges. address.

   o  In the Home Agent Virtual Switch mode, the standby home agent local
      address MUST
   activate the virtual be used.

7.3.3.  Receiving Hello Message

   When a home agent address.  If a virtual MAC address receives HA-HELLO, it SHOULD verify the HA-HELLO as
   introduced in [RFC-3768]
   follows:

   o  If the HA-HELLO is used, not protected by IPsec ESP, it SHOULD be
      discarded.  Note that, only if the HA-HELLO is sent on a dedicated
      link between the standby home agent agents, IPsec protection might not be always
      required.  This depends on the operational policy.

   o  If HA-HELLO is sent from non global IPv6 address, it MUST start
   using be
      discarded.

   o  If the virtual MAC source IPv6 address as well.  Since all the necessary state
   has already been transferred of HA-HELLO is not belong to this standby one of the
      home agent before agents in the
   active redundant home agent failed, it can immediately start acting as set, the
   active HA-HELLO MUST be
      ignored.

   o  If the Group ID field of the received HA-HELLO and the receiver's
      Group ID is different, HA-HELLO MUST be discarded.  HA-HELLO MUST
      NOT be sent to home agent.

   In agents whose Group ID is different from the Home Agent Hard Switch mode,
      sender.

   o  If the standby Sequence Number value in the HA-HELLO is equal to or less
      than the last received Sequence Number value stored in the home
      agent list entry, the HA-HELLO MUST be discarded.

   o  HA-HELLO satisfying all of above tests MUST be processed by
      receiver.  The receiver copies home agent MUST send
   a Home Agent Switch message information in HA-HELLO
      to all the mobile nodes that were
   registered at the failed corresponding home agent as described in Section 7.9,
   using the pre-established IPsec SA. list entry.  The standby Home Agent MUST set
   its own home agent
      address in of the Home Agent sender is retrieved from the Source Address field in the Home Agent
   Switch message so that it will receive the binding update from
      of the
   mobile node as an acknowledgement IPv6 header of the sent Home Agent Switch
   message.  The HA-HELLO.

   o  If the home agent switch-over is complete when it receives
   binding updates from all lifetime field in the mobile nodes.  It HA-HELLO is important to remark
   that sending Home Agent Switch messages set to all 0, the mobile nodes at
   once may bring non-negligible overhead to
      receiver removes the home agent.

   This overhead cannot be avoided if sender from the active home agent suddenly
   stop serving mobile node because of unexpected reasons (crash,
   network trouble, etc).  However, if this switch over is operated
   under agents list.

   o  If the administrative operation (maintenance, etc), R-flag is set in the previous
   active home agent may continue serving received HA-HELLO, the mobile nodes until receiver MUST
      send a new HA-HELLO to the
   switch over originator as described in
      Section 7.3.2.

7.4.  Processing State Synchronization Messages

   It is completed.  Until necessary for standby home agents to synchronize the state
   information of each mobile node sends a binding
   update to registered with the new active home agent, it still sends the packet to the
   previous home agent in
   agent.  In the Home Agent Hard Switch.  Therefore, Switch mode, it is not necessary for
   the
   new active home agents to synchronize the complete binding cache
   information.  The standby home agent can notify needs the completion mapping information of switch-over to
   the
   previous active home agent by using Home Agent Control message as
   described in Section 7.8.3.  As soon as this message is received, and the
   previous active home agent can be shutdown or detached from mobile node.  The information is used
   to send the
   network safely.

7.6.  Processing Hello Messages

   Hello Home Agent Switch messages can be unicasted or multicasted.  A new multicast
   address will be assigned to all the mobile node served
   by the IANA.  When all failed home agents in agent.

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

   When a
   redundant home agent set are configured on needs the state information for a same home link, they
   MUST join particular mobile
   node or a new multicast address (TBA) and multicast Hello.  On the
   other hand, if subset of mobile nodes, it sends a home link is separated SS-REQ message
   constructed as described in Figure 2,
   each home agent follows:

   o  It MUST unicast Hello messages.

7.6.1.  Requesting Hello Message

   A home agent can solicit a Hello message from a particular home agent
   in set the same redundant home agent Type field to 0 (Request).

   o  It MUST set by unicasting a Hello message
   with random value in the R-flag set.  The sender Identifier field that does not
      coincide with any other currently pending Requests.

   o  It MUST fill the fields of include an IP address mobility option(s) which subtype is
      set to the Hello
   message with its home agent information.  A home agent can solicit address if the target is mobile node(s).

   o  It MUST include a
   Hello message from Mobile Network Prefix mobility option(s) for
      mobile router(s).

   o  It MUST set the unspecified address (0::0) in the Home Address
      mobility option if it solicits the state of all the home agents in mobile nodes
      and mobile routers registering at the multicast group by
   multicasting a Hello message with receiver of SS-REQ
      (i.e.destination of SS-REQ).

   o  In the R-flag set.  This Hello request
   message SHOULD Home Agent Virtual Switch, the sender of the SS-REQ MUST be generated when:

   o  A new
      a home agent needs to collect information local address of one of the other home agents in the same
      redundant home agent set.

   o  In this case it
      SHOULD multicast a Hello message in which the R-flag is set.

   o  A home agent entry in Home Agent Hard Switch, the redundant home agent list is about to be
      removed due to home agent lifetime expiration.

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

7.6.2.  Sending Hello Message

   The Hello message SS-REQ MUST be sent when a home agent receives a Hello
   message with the R-flag set, indicating a request is required,
   otherwise Hello messages are periodically sent according to the pre-
   configured Hello interval.  In addition, a
      home agent SHOULD send a
   Hello message to address of one of the home agents of in the same redundant
      home agent set when
   it boots up and its local information, such as home agent preference,
   home agent lifetime, and registration status, etc., change.  When a
   new home agent boots up, it SHOULD solicit Hello messages by
   multicasting a Hello message with set.

   o  The destination of the R-flag set in parallel with
   sending its own Hello message.

   Whenever a home agent generates Hello message, it SS-REQ MUST increment in
   the Sequence Number by 1.  The Sequence Number SHOULD be initialized
   to zero the active home agent for
      the first Hello message.  To accomplish sequence number
   rollover, if requesting home address or mobile network prefix.  The standby
      home agent MUST NOT reply the sequence number has already been assigned SS-RREP to be the
   largest possible number representable as sender.

   When a 16-bit unsigned integer,
   then when home agent receives the SS-REQ, it MUST verify if SS-REQ is incremented it will then have a value
   constructed with the above rules.  If SS-REQ satisfy all the above
   tests, the receiver of zero (0).
   It the SS-REQ MUST also specify its own Group ID in reply SS-REP including the Group ID field
   state information of the
   Hello message.  If requested mobile node(s) and/or mobile
   network prefix(es) as described in Section Section 7.4.2.

7.4.2.  Synchronizing State

   State synchronization messages SHOULD be sent when:

   1.  The active home agent receives SS-REQ.

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

   3.  The active home agent is the deletes a binding cache entry for a
       particular mobile node.

   The active home agent, it MUST set agent MAY additionally send state synchronization
   message in following cases:

   1.  The active home agent update the A-flag state information for all
       sessions that changed since the last update in it's Hello Messages.  In a periodic
       interval

   2.  Only for the Home Agent Hard Virtual Switch mode, the source address of Hello messages MUST be the configured active home
       agent address. updates a binding cache entry for a particular mobile node
       whenever the binding cache entry is updated.  In the Home Agent Virtual
       Hard Switch mode, standby home agents only need the
   individual IPv6 addresses mapping
       information of each 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 address of the message is not protected, it SHOULD be
   silently discarded.  However, if mobile node/router and the Hello messages is sent on a
   dedicated link between
       home agent address of the active home agent to which the home agents, IPsec protection mobile
       node/router is not
   required. currently registering.  This mapping is used to
       send a Home Agent Switch message.

   If an active home agent sends a Hello State Synchronization message is
   whenever the local state information changes, such as a binding cache
   change, the number of the State Synchronization messages sent from an IPv6 address whose
   scope can be
   quite large.

   All the state information of the requested mobile nodes is not global, stored in
   the message MUST SS-REP.  Following rules must be silently discarded.

   If applied when the sending active home agent
   constructs SS-REP.

   o  If the SS-REP is not sent in response to the same redundant SS-REQ, the active home
      agent
   set, the message MUST be silently ignored.  This can be done by
   comparing copy the Group ID Identifier field of the received Hello State Synchronization
      request message with its
   own Group ID value.  Hello messages MUST NOT be sent to a home agent
   whose Group ID is different from the sender.  If the Sequence Number
   value Identifier field in the Hello message is equal to or less than SS-REP.  Otherwise,
      it MUST set the Sequence
   Number value stored in Identifier field to 0.

   o  When the active home agent list entry, stores the Hello message
   MUST be discarded.

   Any Hello message satisfying all state of these tests MUST be processed to
   update multiple mobile
      nodes in a SS-REP, a Binding Cache Information option is used as a
      separator.  For each mobile node, a Binding Cache Information
      option is placed first, followed by any other options such as AAA
      option.  When the redundant home agent list.  The receiver copies home agent
   information next Binding Cache Information option is reached
      in the Hello message to State Synchronization message, it indicates the corresponding redundant home
   agent list entry.  The home agent address information
      of a different mobile node.

   o  If the sender unspecified address is retrieved
   from found in the Source Home Address field of the IPv6 header of mobility
      option carried with the Hello
   message.  If SS-REQ, the active home agent lifetime field in MUST return
      the Hello message is
   set to 0, state of all the receiver removes active mobile nodes and mobile routers by the sender from
      SS-REP.  The IP fragmentation can be occurred depending on the redundant
      total size of all the states.

   o  A SS-REP MUST be authenticated and encrypted by IPsec ESP.

   o  The destination and source home agents list.

   If MUST belong to the R-flag is set in same
      redundant home agent set.

   o  In the received Hello message, Home Agent Hard Switch, the receiver IPv6 source address MUST
   reply with a Hello message be set
      to the originator as described in
   Section 7.6.2.

7.7.  Processing State Synchronization Messages

   It is necessary for standby home agents to synchronize the state
   information agent address of each mobile node registered with the active home
   agent. sender.

   o  In the Home Agent Virtual Switch mode, Switch, the synchronized state
   information is used by IPv6 source address MUST be
      set to the home agent local address of the sender.

   When a standby home agent when receives a SS-REP, it takes over for MUST verify whether the failed home agent.  In SS-
   REP is constructed with the Home Agent Hard Switch mode, above rules or not.  If the
   standby home agent starts SS-REP does
   not satisfy all the switch-over rules above, it is discarded.  Otherwise, the
   following operation must be taken.

   o  The receiver of SS-REP MUST update its binding cache and all other
      necessary information such as AAA and vendor specific information
      in the mobile nodes
   registered to the failed home agent when particular database.

   o  In the home agent failure is
   detected.  Thus, Home Agent Hard Switch mode, the Binding Cache entry receiver MUST be modified to keep record the
   active home agent
      IPv6 address of each mobile node.

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

   When a standby the sender as the active home agent wants state information for a particular
   mobile node or a subset of the mobile nodes, such as Binding Cache, AAA,
   etc., it MAY solicit this state
      node.

7.4.3.  Reliable Transmission by sending a State Synchronization
   message constructed as follows:

   o  It MUST set Explicit Acknowledgement

   Signaling messages of the Type field Home Agent Reliability protocol are not
   guaranteed reliable transmission due to 0 (Request).

   o  It MUST set a random value in the Identifier field that does Mobility Header use.
   This is not
      coincide with any other currently pending Requests.

   o  It MUST include either a IP address mobility option which subtype always critical, because the link between home agents is set
   carefully managed as stable and reliable.  However, operators may
   need more explicit notification to confirm the message exchanges
   between home address indicating agents.  This specification provides an optional
   acknowledgment to SS-REP messages.

   If an active home agent requires an acknowledgment of SS-REP, it set
   the mobile node, or a Mobile
      Network Prefix mobility option indicating Ack flag in the mobile router. SS-REP.  The
      standby home agent can receiver of such SS-REP will send multiple home address and mobile
      network prefix mobility options to request state information for
      multiple mobile nodes in
   back a single State Synchronization request
      message.

   o  It SS-ACK.  The receiver MUST set copy the unspecified address (0::0) Identifier value received
   in the Home Address
      mobility option if it solicits all SS-REP into SS-ACK in order to match the active mobile nodes' SS-REP and
      mobile routers' state at once. SS-ACK.

7.5.  Processing Home Agent Control Messages

7.5.1.  Standby Home Agent becomes an Active Home Agent

   When a standby home agent receives the State Synchronization message with the
   Type field set decides to 0 (Request), it MUST verify become an active home agent, the message as follows:

   o  The state synchronization message MUST be protected by IPsec ESP.

   o  The sending
   standby home agent MUST belong sends a SO-REQ to the same redundant active home
      agent set

   o  The receiver agent.  This
   message MUST be unicasted to the active home agent for the requested home
      address or mobile network prefix.

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

   Otherwise, the receiver
   encrypted and authenticated by IPsec ESP.  The active home Agent MUST reply with a State Synchronization
   message including state information for the requested mobile node(s)
   and/or mobile network prefix(es) as described in Section
   Section 7.7.2.

7.7.2.  Synchronizing State of Mobile Nodes

   A state synchronization message can be sent either:

   o
   NOT generate this message.

   When an active home agent receives a state synchronization message
      in which SO-REQ, it MUST operate the Type field is set to 0 (Request).

   o  When an active home agent creates a binding cache entry for a
      particular mobile node.
   following verification and operations:

   o  When an active home agent deletes a binding cache entry for a
      particular mobile node.  If the SO-REQ is not protected by IPsec, it MUST be discarded.

   o  When an active home agent updates a binding cache entry for a
      particular mobile node, only when operating in  If the Home Agent
      Virtual Switch mode.  In receiver of 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 SO-REQ is not an active home address of all agent, it MUST
      send a SO-REP with the
      mobile nodes registered Status field set to the 130 (Not active home
      agent).

   o  If the sender home agent of does not belong to the same redundant
      home agent set.

   o  In set, a periodic interval SO-REP message MUST be sent to update the state information for all
      sessions that changed since sender with
      the last update. Status field set to 132 (Not in same redundant home agent
      set).

   o  If the receiver is an active home agent sends a State Synchronization message
   whenever the local state information changes, such as a binding cache
   change, the number of the State Synchronization messages sent can be
   quite large.

   The binding cache information of the requested mobile nodes agent, there is stored
   in case where the State Synchronization message.  The
      active home agent MUST
   copy the binding cache information of the requested mobile nodes into
   Binding Cache Information options.  If the State Synchronization
   message is sent in response to a State Synchronization request
   message, cannot be standby home agent.  In such case, the
      active home agent MUST copy the Identifier field of the
   State Synchronization request message to the Identifier field in the
   State Synchronization can reply message.  Otherwise, it MUST set a SO-REP with the
   Identifier Status field set to 0.

   When
      129 (Administratively prohibited).

   o  Otherwise, the active home agent stores the state of multiple mobile nodes
   in a state synchronization message, a Binding Cache Information
   option is used as MUST become a separator.  For each mobile node, standby home agent
      and reply with a Binding Cache
   Information option is placed first, followed by any other options.
   When SO-REP message with the next Binding Cache Information option is reached in Status field set to 0
      (Success).

   The SO-REP MUST be also protected by IPsec ESP.  Otherwise, the
   State Synchronization message, it indicates
   message MUST be silently discarded.  If the information receiver of SO-REP did
   not send a
   different mobile node. SO-REQ message (i.e. unexpected SO-REP), the message MUST
   be ignored.  If the unspecified address Status field of the SwitchOver Reply message is found 0
   (Success), the receiving standby home agent immediately becomes an
   active home agent as described in Section 8.2.  If the Home Address mobility
   option carried with value in the State Synchronization request message,
   Status field is greater than 128 an error has occurred.  In this
   case, the receiver MUST NOT attempt to be an active home agent.

7.5.2.  Active Home Agent becomes in-active

   When an active home agent MUST return all decides to become a standby home agent, it
   sends a SB-REQ to one of standby home agent.  The reason for the
   active mobile nodes' home agent to send this message can be administrative
   intervention, and mobile
   routers' states events like Monitored Server Failure by the State Synchronization reply message.  The IP
   fragmentation can active
   home agent or Routing Peer/Link Failure.  This message MUST be occurred depending on the total size
   unicasted to one of all the
   states.

   A State Synchronization message standby home agents and MUST be authenticated and encrypted and
   authenticated by IPsec ESP mode, otherwise the message ESP.  A standby home agent MUST be ignored. NOT generate
   this message.

   When a home agent receives a State Synchronization SwitchBack Request message, it first
   verifies the message.

   o  If the SwitchBack Request message is not protected by IPsec ESP,
      it MUST verify be discarded.

   o  If the Source address field sender home agent of the IPv6 header. SB-REQ is not an active home
      agent, the receiver MUST reply a SB-REP with the Status field is
      set to 130 (Not active home agent).

   o  If the source address sending home agent does not belong to any home agent in the same redundant
      home agent set,
   the message a SB-REP MUST be silently discarded.  After successfully verifying sent in which the message, Status field
      set to 132 (Not in same redundant home agent set).

   o  Otherwise, the receiving home agent MUST update its binding cache
   and all other necessary information such as AAA and vendor specific
   information in the particular database.  In the Home Agent Hard
   Switch mode, the receiver MUST also record the IPv6 address of the
   sender (the active home agent).

7.7.3.  Explicit Acknowledgement of the State Synchronization Reply
        message

   The Home Agent Reliability protocol does not support any reliable
   transport mechanism for Mobility Header signaling, this specification
   assumes that send a SB-REP with the link between home agents
      Status field is stable and reliable.
   However, operators may need more explicit notification set to confirm 0 (Success).

   After sending the
   message exchanges between SwitchBack reply, it MUST NOT become an active home agents.
   agent immediately.  This specification provides
   an optional acknowledgment for is because the State Synchronization Reply
   message.

   If an active home agent requires an acknowledgment of a State
   Synchronization Reply message, is still
   active until it MUST set receives the Ack flag in SB-REP which is acknowledging the
   message. SB-
   REQ.  The standby home agent SHOULD change to active at least after
   LINK_TRAVERSAL_TIME.

   If a standby home agent receives a State Synchronization
   Reply message with the Ack flag set, SB-REP, it MUST be protected by IPsec ESP,
   otherwise the message MUST be silently discarded.  If the receiving
   home agent did not send back a State
   Synchronization Reply-Ack SB-REQ matched to the received SB-REP, the
   message as an acknowledgment. MUST be silently discarded.  If the Status field of the SB-
   REP is 0 (Success), the active home agent immediately becomes a
   standby home agent.  The standby sender home agent MUST copy the Identifier received of SB-REP becomes active
   home agent as described in Section 8.2.  If the State
   Synchronization Reply message into the Reply-Ack and set value in the type Status
   field to 2 (Reply-Ack).

7.8.  Processing Home Agent Control Messages

7.8.1.  Standby Home Agent becomes an Active Home Agent

   When is greater than 128, the receiver of SB-REP (active home agent)
   cannot become a standby home agent decides and MUST continue to become be an active
   home agent, agent.

7.6.  Interworking with VRRP

   VRRP and HSRP specify an election protocol that dynamically assigns
   responsibility for a virtual router to one of the
   standby home agent sends VRRP routers on a SwitchOver Request message (a
   LAN.  This operation is similar to the Home Agent
   Control message in which Virtual Switch
   operation.  For example, the Type field VRRP router controlling the IP
   address(es) associated with a virtual router is set to 0) to called the active
   home agent.  This message MUST be unicasted Master,
   and forwards packets sent to these IP addresses.  The election
   process provides dynamic fail over in the active forwarding responsibility
   should the Master become unavailable.  Although VRRP is used to
   guarantee home agent
   and MUST address reachability, it cannot be encrypted used for
   state synchronization and authenticated explicit switching of Master and Backup.
   Thus, the Home Agent Reliability protocol cannot be replaced by IPsec ESP.  The active
   home VRRP.
   This section explains how VRRP can interwork with the Home Agent MUST NOT generate this message.
   Reliability protocol.

   When an active VRRP is available, VRRP can replace the Hello message described
   in Section 5.1.3.  However, some of information is missed by using
   VRRP.  After receiving a VRRP message, each home agent receives a SwitchOver Request, it first
   verifies SHOULD process
   the received message and store the information as if it receives Home Agent Control message.  If
   Hello messages Section 7.3.3.  The Home Agents SHOULD still perform
   binding cache synchronization as described in Section 7.4 and SHOULD
   support the request Home Agent Switch message as described in Section 9.2.

   In addition to this, VRRP is not protected by IPsec, it MUST be silently discarded. useful only if all home agents are
   located on the same link.  If the home agent is not an active home agent, it MUST send a SwitchOver
   Reply message (a agents are topologically
   separated, the Home Agent Control 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 Rtr ID|   Priority    |Count IPv6 Addr|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |(rsvd) |       Adver Int       |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                       IPv6 Address(es)                        |
       +                                                               +
       +                                                               +
       +                                                               +
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 12: VRRP Packet Format

   The message format of VRRP is described in which the Type Figure 12.  Each field is set to 1) with the Status field set to 130 (Not active home
   agent).  If the receiver
   mapped as follows:

   Virtual Rtr ID

      Group ID is an active home agent and does not want
   this standby home agent to become the active home agent, it MUST
   reply a SwitchOver reply with stored in the Status field set to 129
   (Administratively prohibited).  In addition, if Virtual Rtr ID field.

   Priority

      Home Agent Preference is stored in the sending home
   agent does not belong to Priority field.  Note that
      VRRP only has 8 bits for the same redundant home agent set, a
   SwitchOver Reply message Priority field.  Therefore, values
      larger than 255 MUST NOT be sent to the sender with the Status
   field set assigned to 132 (Not in same redundant home agent set).  Otherwise,
   the active home agent MUST become a standby home agent and reply with
   a SwitchOver Reply message with the Status preference value.

   Count IPv6 IPv6 Addr

      This field set to 0 (Success).

   The SwitchOver Reply message MUST be protected by IPsec ESP.
   Otherwise, the message MUST always be silently discarded.  If the receiving
   home agent did not send a SwitchOver Request message (i.e. unexpected
   SwitchOver Reply), the message 1.

   Advert Int

      This field MUST be silently ignored.  If mapped to the
   Status Hello Interval field of the SwitchOver Reply message is 0 (Success), the
   receiving standby home agent immediately becomes an active home agent
   as described in Section 7.5.  If the value in the Status field is
   greater than 128 an error has occurred.  In this case, the receiver
   MUST NOT become an active home agent.

7.8.2.  Active Home
      Agent becomes in-active

   When an active Hello message, though it only has 12 bytes.

   IPv6 address

      A home agent decides to become an in-active home agent,
   it sends a SwitchBack Request message (i.e. a address is stored in this field.

   Home Agent Control
   message with Type Lifetime, Sequence Number and Flags field set to 3) to a standby home agent.  The
   reason for are missing in
   the active VRRP packet format.  Therefore, operators SHOULD use the same
   statically configured value for Home Agent Lifetime.  Each home agent to send this
   does not check freshness of received VRRP message can be
   administrative intervention, and events like Monitored Server Failure
   by because of no
   sequence number.  If VRRP is used, a home agent cannot determine the
   active home agent or Routing Peer/Link Failure.  This from the VRRP message
   MUST be unicasted due to one lack of the standby A flag, and
   cannot request a VRRP advertisement to other home agents agents.

7.7.  Retransmissions and MUST be
   encrypted Rate Limiting

   Standby and authenticated by IPsec ESP.  A standby active home agent MUST
   NOT generate this message.

   A SwitchBack Reply is sent in reply to agents are responsible for retransmissions
   and rate limiting of a SwitchBack Request message.
   When SS-REQ, SO-REQ, SB-REQ messages for which they
   expect a response.  The home agent receives MUST determine a SwitchBack Request message, it first
   verifies the message.  If value for the SwitchBack Request message is not
   protected by IPsec ESP, it MUST be silently discarded.
   initial transmission timer:

   o  If the
   sending home agent of the SwitchBack Request message is not an active
   home agent, the receiver MUST reply with sends 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). SS-REQ message, it SHOULD use an initial
      retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.

   o  If the
   sending home agent does not belong to the same redundant home agent
   set, a SwitchBack Reply message MUST be sent in which the Status
   field set to 132 (Not in same redundant standby home agent set).  Otherwise,
   the receiving sends a SO-REQ message, it SHOULD use an
      initial retransmission interval of INITIAL_SWICHOVER_REQ_TIMER.

   o  If an active home agent MUST send sends a SwitchBack Reply message in
   which SB-REQ message, it SHOULD use an
      initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER .

   If the Status field is set to 0 (Success).  After sending home agent fails to receive a valid matching response
   within the
   SwitchBack reply, selected initial retransmission interval, it SHOULD
   retransmit the message until a response is received.  All of the
   above constants are specified in Section 11.

   The retransmission MUST NOT become use an active home agent
   immediately.  This is because exponential backoff process as
   described in [RFC-3775] until either the active home agent is still active
   until it receives a
   response, or the SwitchBack Reply message acknowledging timeout period reaches the
   SwitchBack Request. value
   MAC_HARELIABILITY_TIMEOUT (16sec).  The standby home agent SHOULD change to active
   at least after LINK_TRAVERSAL_TIME.

   If a home agent receives use a SwitchBack Reply message, it MUST be
   protected by IPsec ESP, otherwise the
   separate back-off process for different message MUST be silently
   discarded.  If types and different
   destinations.  The rate limiting of Mobility Header messages is the receiving
   same as one in [RFC-3775].  A home agent did not MUST NOT send Mobility
   Header Messages to a SwitchBack
   Request message beforehand, the message MUST be silently discarded.
   If the Status field particular home agent more than MAX_UPDATE_RATE
   (3) times a second, which is specified in [RFC-3775].

8.  Home Agent Virtual Switch

8.1.  Consideration 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 SwitchBack Reply message Home
   Agent Virtual Switch mode is 0 (Success),
   the receiving used.

   When a standby home agent immediately becomes an in-active active in the Home Agent Virtual
   Switch mode, it MUST start to advertise the home agent address and
   the standby home agent becomes active 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 described in
   Section 7.5.  If BGP or an OSPF modifier.
   For example, we can use the value in AS_Path prepend operation for BGP, and
   the Status Metric field is greater than 128,
   an error has occurred.  In this case, in OSPF for the receiver cannot become an
   in-active route selection.  When each home
   agent and MUST continue to participates in OSPF routing, each home agent should be an active
   configured with the appropriate metric matched to the home agent.

7.8.3.  Notification of Home Agent Switch Completion

   If agent
   preference value.  When the new active home agent completes fails, OSPF detects the switch-over as described
   in Section 7.5, it SHOULD send a Home Agent Control message with
   failure and can dynamically switch the
   type field set to 4 (Switch Complete) route to the previous active standby home
   agent in the Home
   Agent Hard Switch case.  Until based on the previous home
   agent receives OSPF cost value.  If this message, it SHOULD continue serving any mobile
   nodes that are registered cost conflicts with it.  Once the previous
   home agent
   receives a Switch Complete message, it can stop offering preference value due to configuration errors, the routers
   on the home agent
   services.

7.9.  Sending Home Agent Switch Messages

   This operation is valid only for link may not route packets to the Home Agent Hard Switch mode.
   The desired standby home
   agent.  In order to change the OSPF cost correctly and dynamically,
   The operator takes other existing approaches.  For example, most of
   router vendors have a private MIB to set the cost via SNMP, though
   this is a vendor-specific function.

   When an active home agent MUST send activates a Home Agent Switch message home agent address, it SHOULD
   use a virtual MAC address as
   defined introduced in [ID-HASWITCH] to all the mobile nodes that were being
   served by the failed home agent.  Since [RFC-3768].  When the
   active home agent address is recorded in each synchronized binding cache, changed, the standby neighbor cache of the active home
   agent knows which is not necessarily updated on mobile nodes were served by located on the failed home agent.
   The Home Agent Switch message must be encrypted with a pre-
   established SA.  The standby
   link.  Otherwise, the new home agent MUST include only its own
   IPv6 address in update the Home Agent Switch message.  Note that a Home
   Agent Switch message is sent to each mobile node served by neighbor cache
   entry for the home
   agent.  If there is a large number of agent address on all the mobile nodes, sending Home
   Agent Switch messages will cause a lot of signaling overhead nodes located on
   the
   network.  The previous active home agent MAY serve link.  In addition, Mobile IPv6 uses proxy NDP to intercept
   packets meant for mobile nodes while which are away from the home link.
   However, it is unnecessary for the new active home agent completes to overwrite
   the sending home agent switch and
   receiving binding update from all existing proxy neighbor entries of the mobile nodes.  This is

8.2.  Home Agent Recovery

   After detecting the case
   when active home agent has failed, the previous standby home
   agent will be halt due to administrative
   reason.

   When a whose preference value is the highest MUST take over the failed
   home agent.  The standby home agent recovers, it MUST re-establish an IPsec SA
   with each mobile node served by its redundant activate the virtual home
   agent set.
   Otherwise, it cannot be either address.  If a virtual MAC address as introduced in [RFC-3768]
   is used, the standby or active home agent for the
   mobile nodes.  Therefore, as soon MUST start using that virtual MAC
   address as well.  Since all the active necessary state has already been
   transferred to this standby home agent detects
   the recovery of before the failed active home agent, agent
   failed, it sends a can immediately start acting as the active home agent.

9.  Home Agent Hard Switch
   message with the I-flag set to all the mobile nodes serving by other
   home agents in

9.1.  Home Agent Recovery

   After detecting the same redundant active home agent set, and includes has failed, the
   recovered standby home
   agent address in the Home Agent Addresses field.  The
   mobile node will re-key whose preference value is the SA, but it will not change highest MUST take over the failed
   home agent
   by this agent.  The standby home agent switch message which I-flag is on.

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 MUST send a
   LAN.  This operation is similar to the Home Agent Virtual Switch
   operation.  For example, the VRRP router controlling the IP
   address(es) associated with a virtual router is called the Master,
   and forwards packets sent
   message to these IP addresses.  The election
   process provides dynamic fail over in all the forwarding responsibility
   should mobile nodes that were registered at the Master become unavailable.  Although VRRP is used to
   guarantee failed
   home agent address reachability, it cannot be used for
   state synchronization and explicit switching of Master and Backup.
   Thus, as described in Section 9.2, using the pre-established
   IPsec SA.  The standby Home Agent MUST set its own address in the
   Home Agent Reliability protocol cannot be replaced by VRRP.
   This section explains how VRRP can interwork with Address field in the Home Agent
   Reliability protocol.

   When VRRP is available, VRRP can replace the Hello Switch message described
   in Section 6.1.3.  However, some of information is missed by using
   VRRP.  After receiving a VRRP message, each home agent SHOULD process so that it
   will receive the message and store binding update from the information mobile node as if it receives an
   acknowledgment of the sent Home Agent
   Hello messages Section 7.6.3. Switch message.  The Home Agents SHOULD still perform home agent
   switch-over is complete when it receives binding cache synchronization as described in Section 7.7 and SHOULD
   support updates from all the
   mobile nodes.  It is important to remark that sending Home Agent
   Switch message as described in Section 7.9.

   In addition messages to this, VRRP is useful only if all home agents are
   located on the same link.  If mobile nodes at once may bring non-
   negligible overhead to the home agents are topologically
   separated, the Home Agent Reliability protocol MUST agent.

   This overhead cannot be used.

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

   The message format avoided if the active home agent suddenly
   stop serving mobile node because of VRRP is described in Figure 12.  Each field unexpected reasons (crash,
   network trouble, etc).  However, if this switch over is
   mapped as follows:

   Virtual Rtr ID

      Group ID operated
   under the administrative operation (maintenance, etc), the previous
   active home agent may continue serving the mobile nodes until the
   switch over is stored completed.  Until the mobile node sends a binding
   update to the new active home agent, it still sends the packet to the
   previous home agent in the Virtual Rtr ID field.

   Priority Home Agent Preference is stored in Hard Switch.  Therefore, the Priority field.  Note that
      VRRP only has 8 bits for
   new active home agent can notify the Priority field.  Therefore, values
      larger than 255 MUST NOT be assigned completion of switch-over to the preference value.

   Count IPv6 IPv6 Addr

      This field MUST
   previous active home agent by using Home Agent Control message as
   described in Section 9.3.  As soon as this message is received, the
   previous active home agent can be always shutdown or detached from the
   network safely.

9.2.  Sending Home Agent Switch Messages

   The standby home agent which is going to be 1.

   Advert Int

      This field active MUST be mapped send a Home
   Agent Switch message as defined in [RFC-5142] to all the Hello Interval field of mobile nodes
   that were being served by the failed home agent.  The Home Agent Hello message, though it
   Switch message must be securely sent to the mobile node by using
   IPsec ESP.  The standby home agent MUST include only has 12 bytes.

   IPv6 address

      A its own home
   agent address is stored in this field. the Home Agent Lifetime, Sequence Number and Flags field Switch message.  If there are missing in a large
   number of mobile nodes served by the VRRP packet format.  Therefore, operators SHOULD use failed home agent, the same
   statically configured value for overhead
   sending Home Agent Lifetime.  Each home agent
   does not check freshness of received VRRP message because of no
   sequence number.  If VRRP Switch messages is used, high.  Until a home agent cannot determine mobile node
   receives this Home Agent Switch messages, the
   active mobile node's
   communication is discontinued.  Therefore, until the standby home
   agent from completes sending the VRRP Home Agent Switch message due to lack of A flag, all the
   mobile nodes and
   cannot request a VRRP advertisement to other receives Binding Updates from all the mobile node,
   the failed home agents.

7.11.  Retransmissions and Rate Limiting

   Standby and agent SHOULD serve mobile nodes if possible.  This is
   the case when the active home agents are responsible for retransmissions
   and rate limiting of a State Synchronization Request, Switchover
   Request, SwitchBack Request agent is replaced by administrative
   operation with the Home Agent Control messages for which they expect as described in
   Section 9.3.

   When a
   response.  The failed home agent recovers, it MUST determine re-establish an IPsec SA
   with each mobile node served by its redundant home agent set.
   Otherwise, it cannot be either a value standby or active home agent for the initial
   transmission timer:

   o  If
   mobile nodes.  Therefore, as soon as the active home agent sends a State Synchronization Request message,
      it SHOULD use an initial retransmission interval detects
   the recovery of
      INITIAL_STATE_SYNC_REQ_TIMER.

   o  If a standby the failed home agent agent, it sends a Switchover Request message, it
      SHOULD use an initial retransmission interval of
      INITIAL_SWICHOVER_REQ_TIMER.

   o  If an active Home Agent Switch
   message with the I-flag set to all the mobile nodes serving by other
   home agents in the same redundant home agent sends a SwitchBack Request message, it
      SHOULD use an initial retransmission interval of
      INITIAL_SWICHBACK_REQ_TIMER .

   If set, and includes the sending
   recovered home agent fails to receive a valid matching response
   within address in the selected initial retransmission interval, Home Agent Addresses field.  The
   mobile node will re-key the SA, but it SHOULD
   retransmit will not change the home agent
   by this home agent switch message until a response which I-flag is received.  All set.

9.3.  Notification of Home Agent Switch Completion

   If the
   above constants are specified in Section 10.

   The retransmission MUST use an exponential backoff process new active home agent completes the switch-over as described
   in [RFC-3775] until either Section 8.2, it SHOULD send a SW-COMP to the previous active home
   agent receives a
   response, or in the timeout period reaches Home Agent Hard Switch case.  Until the value
   MAC_HARELIABILITY_TIMEOUT (16sec).  The previous home
   agent receives this message, it SHOULD use a
   separate back-off process for different message types and different
   destinations.  The rate limiting of Mobility Header messages is continue serving any mobile
   nodes that are registered with it.  Once the
   same as one in [RFC-3775].  A previous home agent MUST NOT send Mobility
   Header Messages to a particular
   receives the SW-COMP message, it can stop home agent more than MAX_UPDATE_RATE
   (3) times a second, which is specified in [RFC-3775].

8. services.

9.4.  Mobile Node Operation

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

8.1.

9.4.1.  Home Agent Addresses Discovery

   To provide home agent reliability with

   In the Home Agent Hard Switch mode, a mobile node authenticates
   itself to two or more home agents and creates IPsec SAs with them
   during bootstrapping.  When one the active home agent fails, another home
   agent can use the pre-existing SA to notify
   the mobile node about the failure.

   Multiple home agent addresses are available in to notify the mobile node about the
   failure by sending a home network. Home Agent Switch message.

   In order to discover these multiple home agent addresses, two different
   mechanisms are defined in the bootstrapping solution in the split
   scenario [RFC-5026].  One is DNS lookup by home agent Name, the other
   is DNS lookup by Service Name.  DHCPv6 can also be used in the
   integrated scenario [ID-BOOTINT] to provide home agent provisioning
   to mobile nodes.

   In the split scenario, a mobile node can use DNS lookup by Service
   Name to discover the home agents, as defined in [RFC-5026].  For
   example, if home agent reliability is required by a mobile node, DNS
   lookup by Service Name method is recommended for the mobile node to
   discover multiple home agents addresses.  Therefore, mobile nodes
   will query the DNS SRV records with a service name of mip6 and
   protocol name of ipv6.  The DNS SRV records includes multiple home
   agent addresses and different preference values and weights.  The
   mobile node SHOULD choose two or more home agents from the home
   agents list according to their preference value.  Then the mobile
   node should authenticate itself to these home agents via an IKEv2
   exchange.

   In the integrated scenario, a mobile node can use DHCPv6 to get home
   agent provisioning from an MSP or ASP, as already defined in [ID-
   BOOTINT].  The only requirement is that the DHCPv6 response must
   include multiple home agents' information in order to support home
   agent reliability.

8.2.

9.4.2.  IKE/IPsec pre-establishment to Home Agents

   After a mobile node gets obtains multiple home agent addresses, it needs
   to trigger multiple IKE exchanges with the multiple home agents
   selected from the home agent list.  Since both IKEv1 and IKEv2 can be
   used to bootstrap Mobile IPv6, this solution does not introduce any
   new operations to co-operate with IKEv1 or IKEv2.  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 the split scenario [RFC-5026].  Home
   Address configuration maybe also be included, if necessary, for the
   first IKE exchange.  After its Home Address is assigned or approved
   by the first home agent, mobile node SHOULD register itself with the
   second home agent with IKE using the same Home 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.

9.4.3.  Receiving Home Agent Switch message

   A mobile node must follow the operation specified in [ID-HASWITCH] [RFC-5142] when
   it receives a Home Agent Switch message.

   If the I-flag is set in the received Home Agent Switch message, the
   mobile node MUST re-key the SA with the home agent addresses stored
   in the Home Agent Addresses field.  The mobile node MUST NOT change
   its active home agent when the I-flag is set.  If the home agent
   address is not known from the bootstrapping described in
   Section 8.1, 9.4.1, the mobile node MUST NOT start an IKE session with the
   unknown home agent.  Instead, it SHOULD re-start home agent discovery
   again to update its home agent address information.

   When the mobile node receives a Home Agent Switch message without
   I-flag set, and if the message contains the IPv6 address of a standby
   home agent, it SHOULD pick MUST select the standby home agent in the switch
   message as the active home agent and send a new Binding Update
   message to it.  Note that the standby home agent address in the switch message Home
   Agent Switch MUST be equal to the sender of the Home Agent Switch
   message.  This
   is because the  The standby Home agent expects the Binding Update as an
   acknowledgement
   acknowledgment of the Home Agent Switch message.  The mobile node
   already has a pre-established SA with the standby home agent agents and
   should use that SA to send the Binding Update.  If the address stored
   in the Home agent address field is different from the sender, the
   mobile node MUST send a binding update to the sender.

9.

10.  Security Considerations

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

   SPI

      This field identifies the SAD at the receiver.

      The mobile node negotiates only one IPsec SA.  Hence, the SPI
      value will remain unchanged upon 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.

      The mobile node and the redundant 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.

      As described in Section 4, the

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

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

   Initialization Vector

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

   Others

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

   In the Home Agent Hard Switch mode, the standby home agent needs to
   send a Home Agent Switch message using IPsec encryption.  Since the
   mobile node has pre-established an IPsec SA with both the active and
   standby home agents, the standby home agent can send the message to
   the mobile node with the pre-established IPsec SA.

10.

11.  Protocol Constants

      INITIAL_STATE_SYNC_REQ_TIMER: 3sec

      INITIAL_SWICHOVER_REQ_TIMER: 1sec

      INITIAL_SWICHBACK_REQ_TIMER 1sec

      LINK_TRAVERSAL_TIME 150msec

11.

12.  IANA Considerations

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

      *  State Synchronization Message

      *  Home Agent Control Message

      *  Home Agent Hello Message

      *  Home Agent Switch Message

   o  The Type values for the State Synchronization Message

      *  0: Request

      *  1: Reply

      *  2: Reply-Ack

   o  The Type values for the Home Agent Control Message

      *  0: SwitchOver Request

      *  1: SwitchOver Reply

      *  2: SwitchBack Request

      *  3: SwitchBack Reply

   o  The Status values for the Home Agent Control Message

      *  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
   o  The values for following mobility options MUST be assigned by
      IANA.

      1.  Binding Cache Information Option

      2.  AAA Information Option

   o  New Option Code for the IP address option defined in [RFC-4068]

12.  Contributors [RFC-5268]

13.  Additional Authors

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

   Samita Chakrabarti

      samita.chakrabarti@azairenet.com

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Hui Deng

      denghui@chinamobile.com

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sri Gundavelli

      sgundave@cisco.com

   Brian Haley

      brian.haley@hp.com

   Behcet Sarikaya

      bsarikaya@huawei.com

   Ryuji Wakikawa

      ryuji@sfc.wide.ad.jp

13.

14.  Acknowledgements

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

14.

15.  References

14.1.

15.1.  Normative References

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

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

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

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

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

   [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
   scenario", RFC 5026, October 2007.

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

15.2.  Informative References

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

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

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

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

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

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

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

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

   [ID-VSM] Devarapalli, V., "Mobile IPv6 Vendor Specific Option",
   draft-ietf-mip6-vsm-03 (work in progress), October 2007.

14.2.  Informative References

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

   [ID-HASWITCH] Haley, B., "Mobility Header Home Agent Switch Message",
   draft-ietf-mip6-ha-switch-05 (work in progress), November 2007.

   [RFC-4068]

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

   [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
   scenario", Fast Handovers", RFC 5026, October 2007.

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

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

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

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

Appendix A.  Change Log From Previous Versions

   Changes from draft-ietf-mip6-hareliability-02

   o  comment (see mail at 2007 June 20) from Wesley Eddy, Verizon
      Federal Network Systems

   o  Support Mobile Node Identifier option (See Section 6.1.1) draft-ietf-mip6-hareliability-03

   o  Only Editorial Update and No Technical Change the usage of HA switch message: the standby HA MUST use its
      address in the Home Agent Address field in the HA switch message.
      Otherwise, the standby HA cannot receive the acknowledgement (i.e.
      BU) of the HA switch message.  (See Section 8.3)

   o  Defining a wildcard option for the State Sync Request message A
      new boot up HA can retrieve all the active mobile nodes' state at
      once. (see section 7.7.1)

   o  Defining a new type (Reply-ack) in State Sync Reply message (see
      section 7.7.3).  This is optional message.

   o  Defining a new type (SwitchCompletion) in HA Control message.  For
      the impact of HA switch in the HA hard switch scenario (see
      section 7.8.3).  This is optional.

   o  Adding IANA Consideration Section.  (See Section 11)

Author's Address

   Ryuji Wakikawa (Editor)
   Faculty of Environment and Information Studies, Keio University
   Keio University, 5322 Endo
   Fujisawa, Kanagawa  252-8520
   Toyota ITC
   6-6-20 Akasaka, Minato-ku
   Tokyo  107-0052
   Japan

   Phone: +81-466-49-1100 +81-3-5561-8276
   Fax:   +81-466-49-1395   +81-3-5561-8292
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/ ryuji@jp.toyota-itc.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

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

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

Intellectual Property

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

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

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

Acknowledgment

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