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

Versions: 00 01 02 03 04 05 06 07 08 09

MIP6 Working Group                                  R. Wakikawa (Editor)
Internet-Draft                                           Keio University
Intended status: Standards Track                       November 19, 2007
Expires: May 22, 2008


                    Home Agent Reliability Protocol
                  draft-ietf-mip6-hareliability-03.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.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Wakikawa (Editor)         Expires May 22, 2008                  [Page 1]


Internet-Draft               HA Reliability                November 2007


Abstract

   The home agent can be a single point of failure when Mobile IPv6 is
   used in a system.  It is critical to provide home agent reliability
   in the event of a home agent crashing or becoming unavailable.  This
   would allow another home agent to take over and continue providing
   service to the mobile nodes.  This document describes the problem
   scope briefly and provides a mechanism of home agent failure
   detection, home agent state transfer, and home agent switching for
   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.  Home Agent Virtual Switch  . . . . . . . . . . . . . . . . 11
     5.3.  Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12
     5.4.  Active Home Agent Management . . . . . . . . . . . . . . . 13

   6.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  New Mobility Header Messages . . . . . . . . . . . . . . . 15
       6.1.1.  State Synchronization Message  . . . . . . . . . . . . 15
       6.1.2.  Home Agent Control Message . . . . . . . . . . . . . . 17
       6.1.3.  Home Agent Hello Message . . . . . . . . . . . . . . . 19
       6.1.4.  Home Agent Switch Message  . . . . . . . . . . . . . . 21
     6.2.  New Mobility Options . . . . . . . . . . . . . . . . . . . 22
       6.2.1.  IP address Option  . . . . . . . . . . . . . . . . . . 22
       6.2.2.  Binding Cache Information Option . . . . . . . . . . . 22
       6.2.3.  AAA Information Option . . . . . . . . . . . . . . . . 24

   7.  Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 25
     7.1.  Home Agent Address Configuration . . . . . . . . . . . . . 25
     7.2.  Consideration of Routing and Neighbor Discovery
           Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 25
     7.3.  Home Agent List Management . . . . . . . . . . . . . . . . 26
     7.4.  Detecting Home Agent Failure . . . . . . . . . . . . . . . 27
     7.5.  Home Agent Switch Over . . . . . . . . . . . . . . . . . . 28
     7.6.  Processing Hello Messages  . . . . . . . . . . . . . . . . 29
       7.6.1.  Requesting Hello Message . . . . . . . . . . . . . . . 29



Wakikawa (Editor)         Expires May 22, 2008                  [Page 2]


Internet-Draft               HA Reliability                November 2007


       7.6.2.  Sending Hello Message  . . . . . . . . . . . . . . . . 30
       7.6.3.  Receiving Hello Message  . . . . . . . . . . . . . . . 30
     7.7.  Processing State Synchronization Messages  . . . . . . . . 31
       7.7.1.  Soliciting State of a Particular Mobile Node or
               Subset of Mobile Nodes . . . . . . . . . . . . . . . . 31
       7.7.2.  Synchronizing State of Mobile Nodes  . . . . . . . . . 32
       7.7.3.  Explicit Acknowledgement of the State
               Synchronization Reply message  . . . . . . . . . . . . 34
     7.8.  Processing Home Agent Control Messages . . . . . . . . . . 34
       7.8.1.  Standby Home Agent becomes an Active Home Agent  . . . 34
       7.8.2.  Active Home Agent becomes in-active  . . . . . . . . . 35
       7.8.3.  Notification of Home Agent Switch Completion . . . . . 36
     7.9.  Sending Home Agent Switch Messages . . . . . . . . . . . . 36
     7.10. Interworking with VRRP . . . . . . . . . . . . . . . . . . 37
     7.11. Retransmissions and Rate Limiting  . . . . . . . . . . . . 38

   8.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 40
     8.1.  Home Agent Addresses Discovery . . . . . . . . . . . . . . 40
     8.2.  IKE/IPsec pre-establishment to Home Agents . . . . . . . . 40
     8.3.  Receiving Home Agent Switch message  . . . . . . . . . . . 41

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 42

   10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 44

   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 45

   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47

   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47

   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
     14.2. Informative References . . . . . . . . . . . . . . . . . . 48

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

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












Wakikawa (Editor)         Expires May 22, 2008                  [Page 3]


Internet-Draft               HA Reliability                November 2007


1.  Introduction

   In Mobile IPv6 [RFC-3775] and NEMO Basic Support[RFC-3963], mobile
   nodes may use 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 the
   binding cache entry to route any traffic meant for the mobile node or
   the mobile network.  If the mobile node is not on the home link and
   does not have a binding cache entry at the home agent, it is neither
   reachable at its home address nor able to setup new sessions with its
   home address.  If a home agent loses the binding cache state, due to
   failure or some other reason, it results in a loss of service for the
   mobile nodes.

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


































Wakikawa (Editor)         Expires May 22, 2008                  [Page 4]


Internet-Draft               HA Reliability                November 2007


2.  Terminology

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

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

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

   Active Home Agent

      A home agent that is currently serving the mobile nodes.

   Standby Home Agent

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

   Failed Home Agent

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

   Redundant Home Agent Set

      A group of active and standby home agent(s).  The Group Identifier
      is used to identify a redundant home agent set.  The Group ID is
      exchanged by Hello messages.

   Binding Synchronization

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

   Home Agent Preference

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



Wakikawa (Editor)         Expires May 22, 2008                  [Page 5]


Internet-Draft               HA Reliability                November 2007


3.  Problem Statement and Requirements

   In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a
   binding with only one home agent.  Thus the home agent represents the
   possibility of a single point of failure for Mobile IPv6.  A home
   agent may be responsible for multiple mobile nodes on the home link.
   The failure of the home agent may then result in the loss of
   connectivity for numerous mobile nodes located throughout the
   Internet.  To overcome this problem, Mobile IPv6 allows deployment of
   multiple home agents on the home link so that upon the failure of a
   home agent, a mobile node can re-establish its connection through a
   new home agent.  However, the base Mobile IPv6 specification does not
   address home agent failover and dynamic transfer of service from one
   home agent to another.  This transfer of service from the failed home
   agent to 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 a deployment scenario.

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

   Reliable Home agent service

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

   Availability of a redundant home agent set

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

   State Synchronization

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



Wakikawa (Editor)         Expires May 22, 2008                  [Page 6]


Internet-Draft               HA Reliability                November 2007


      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
      home agent set.  The details are described in Section 9.

   Secured Message Exchanges

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

   Failure Detection

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

   Failure Notification

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























Wakikawa (Editor)         Expires May 22, 2008                  [Page 7]


Internet-Draft               HA Reliability                November 2007


4.  Protocol Design

   Mobile IPv6 depends on IPsec and IKE for home binding registration as
   described in [RFC-3776].  A mobile node must encrypt a Binding Update
   sent to a home agent.  In addition, the mobile node exchanges HoTI
   and HoT messages through the home agent by using IPsec tunnel mode.
   Therefore, before home agent failure, these IPsec states should be
   synchronized among home agents of a redundant home agent set.  A
   mobile node may also encrypt particular data traffic sent to nodes in
   the Internet.  IPsec information required by 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
   multiple IPsec security associations between the mobile node and the
   home agent sets.  Another is to have the home agents periodically
   check-point IPsec session state, including the per packet sequence
   numbers, for the mobile node.  Thus, we define two possible home
   agent redundancy modes as follows:

   Home Agent Virtual Switch

      Each mobile node negotiates just one SA with an active home agent
      in a redundant home agent set.  The IPsec state will be shared
      within the redundant home agent set in the background.  The active
      and the redundant home agents are addressed by the same home agent
      address, although only the active home agent is accessible by the
      home agent address all of the time.  IPsec/IKE states must be
      synchronized between the active and standby home agents.  The
      mechanism used to synchronize IPsec state is considered out of
      scope for this document.  In case there is a failure of the active
      home agent, the standby home agent takes over without the mobile
      node being aware of the change in the home agent.

      In a redundant home agent set, a single home agent address is used
      by the active home agent.  Thus, all the mobile nodes served by a
      redundant home agent set MUST associate with the same home agent
      (the active home agent) all the time.




Wakikawa (Editor)         Expires May 22, 2008                  [Page 8]


Internet-Draft               HA Reliability                November 2007


   Home Agent Hard Switch

      The home agents are addressed by different IP addresses and the
      mobile node is aware of the change of home agent.  A Mobile node
      and all home agents in a redundant home agent set negotiate
      independent IPsec SAs.  This mode is especially useful when the
      IPsec/IKE states cannot be synchronized.  However, the home agent
      change is not transparent to the mobile node.  When an active home
      agent fails, a mobile node will receive a notification (a Home
      Agent Switch message [ID-HASWITCH]) from a standby home agent, and
      send a Binding Update to the standby home agent.  In order to
      exchange the Home Agent Switch message securely between the
      standby home agent and a mobile node, the mobile node needs to
      establish an IPsec SA with both the active and the standby home
      agents 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 the home agents is its
      active home agent.  For example, when two home agents serve a home
      network, half of the mobile nodes might register with one home
      agent and the rest of mobile nodes with another home agent.  When
      one of the home agents fails, a standby home agent, whose
      preference value is next highest than the failed home agent, can
      trigger a home agent switch by sending a Home Agent Switch message
      to the mobile nodes that were registered with the failed home
      agent.

   In both the cases, the mobile node maintains only one home binding at
   any given time.  In the Home Agent Hard Switch mode, the mobile node
   needs to switch its binding from the active to standby home agent
   upon failover.  The bindings are synchronized among home agents in
   the redundant home agent set in the background when the Home Agent
   Virtual Switch mode is used.

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

   Finally, the reasons why we defined a new Hello message instead of
   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.







Wakikawa (Editor)         Expires May 22, 2008                  [Page 9]


Internet-Draft               HA Reliability                November 2007


5.  Protocol Overview

5.1.  Home Agent Network Configuration

   The Home Agent Reliability protocol supports two different
   configurations for standby home agents.  Standby home agents can be
   placed on the same home link as the active home agent, or on a
   different link.  The Global Recovery described below is not included
   in this document, although the Home Agent Reliability protocol can
   support this with slight modifications to home agent operations.


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


                  Figure 1: Local Recovery Configuration

   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.  This is the same as what Mobile
   IPv6 defines for home agent configuration.



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

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



                  Figure 2: Global Recovery Configuration

   Figure 2 illustrates when standby home agents are located on a
   different link (named the recovery link in Figure 2).  HA3 and HA4
   are standby home agents of HA1 and HA2.  In this case, HA3 and HA4
   cannot receive packets meant for the home network until the route on
   the Routers is changed.  The advantage of this configuration is that
   standby home agents can recover from a failure of the home link.
   This configuration can achieve home agent recovery even if the entire
   home link fails.  In this configuration, the routing must be also
   updated to direct the packets meant for the home link to the recovery
   link.



Wakikawa (Editor)         Expires May 22, 2008                 [Page 10]


Internet-Draft               HA Reliability                November 2007


   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 the worst type of disaster or outage.  For
   example, critical nodes in region-1 are backed up by nodes in
   region-2.  These two regions are geographically separated.  If
   region-1 suffers a downtime due to any reason, all the sessions will
   be seamlessly taken over by the nodes in region-2.  This is called
   geographic redundancy.  This is a well-known configuration for
   Telecommunications operators.

5.2.  Home Agent Virtual Switch

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


     MN      HA1(active)    HA2(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 HA1
      |           X           |
      |           X           |    RECOVERY COMPLETE


              Figure 3: Overview of Home Agent Virtual Switch

   The operations of the Home Agent Virtual Switch mode are shown in
   Figure 3.  The mobile node first attempts the IKE exchange for
   Security Association (SA) setup and home address assignment (1).
   After binding registration is done (2, 3), the active home agent
   pushes all the states of its mobile nodes with a state
   synchronization message (4).  The standby home agent(s) is not active
   unless it takes over from a failed home Agent.

   When the active home agent's failure is detected (5), the standby
   home agent activates the IP address of the failed home agent on it
   and takes over for the failed home agent.  All the home agents in the



Wakikawa (Editor)         Expires May 22, 2008                 [Page 11]


Internet-Draft               HA Reliability                November 2007


   redundant home agent set share a virtual home agent address and the
   routing will ensure only the active home agent will be reachable
   using that virtual home agent address.  The standby home agent can
   serve all the mobile nodes for which the states are synchronized,
   without any further message exchange, because it has all the
   necessary information which it obtained from the failed home agent.

5.3.  Home Agent Hard Switch

   The overview of the Home Agent Hard Switch is shown in Figure 4.
   This mode is not transparent to the mobile node when the active home
   agent failure occurs.


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


               Figure 4: Overview of Home Agent Hard Switch

   The mobile node establishes IPsec/IKE state with all the home agents
   in the redundant home agent set beforehand (1 and 4), however it
   registers its binding only with the active home agent (2 and 3).
   When an active home agent fails, a standby home agent uses a pre-
   existing IPsec SA to notify the mobile node about the failure by
   securely sending a Home Agent Switch message.  In order to discover
   home agent addresses, two different mechanisms are defined, as
   described in Section 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 periodically (5).  The
   mobile node MUST NOT request a home address(es) assignment through
   the IKE exchange to the standby home agent when it establishes an SA
   with it (4).



Wakikawa (Editor)         Expires May 22, 2008                 [Page 12]


Internet-Draft               HA Reliability                November 2007


   When the standby home agent detects the failure of the active home
   agent (6), it sends a Home Agent Switch message to all the mobile
   nodes that were registered with the failed home agent (7).  The Home
   Agent Switch message must be encrypted by a pre-established IPsec SA.
   After the switch message, the mobile node MUST send a binding update
   to the new active home agent in order 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



Wakikawa (Editor)         Expires May 22, 2008                 [Page 13]


Internet-Draft               HA Reliability                November 2007


   optional operation in this specification.


















































Wakikawa (Editor)         Expires May 22, 2008                 [Page 14]


Internet-Draft               HA Reliability                November 2007


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



Wakikawa (Editor)         Expires May 22, 2008                 [Page 15]


Internet-Draft               HA Reliability                November 2007


         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.




Wakikawa (Editor)         Expires May 22, 2008                 [Page 16]


Internet-Draft               HA Reliability                November 2007


      *  Mobile Network Prefix Option.  If a home agent wants to know
         the forwarding state setup for a particular Mobile Network
         Prefix, it includes a Mobile Network Prefix Option as defined
         in [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].

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

      *  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.  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 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      |   Status      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 7: Home Agent Control Message






Wakikawa (Editor)         Expires May 22, 2008                 [Page 17]


Internet-Draft               HA Reliability                November 2007


   Type

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

         0: SwitchOver Request

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

         1: SwitchOver Reply

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

         2: SwitchBack Request

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

         3: SwitchBack Reply

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

         4: Switch Complete

         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 or SwitchBack Request message.  This field is only valid
      in SwitchOver Reply and SwitchBack Reply messages.  The following
      Status values are defined:






Wakikawa (Editor)         Expires May 22, 2008                 [Page 18]


Internet-Draft               HA Reliability                November 2007


         0: Success

         128: Reason unspecified

         129: Administratively prohibited

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

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

         132: Not in same redundant home agent set

   Mobility Options

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

   This messages can be replaced by other protocols as described in
   Section 7.10.  If this message is used, it MUST be either unicasted
   or multicasted to carry home agent information among the redundant
   home agent set.  The Hello message is defined for two purpose: 1) an
   alive check and 2) home agent information exchange.  A home agent
   Hello message SHOULD be authenticated and encrypted by IPsec ESP when
   it is unicasted.  If a Hello message is multicasted, IPsec ESP cannot
   be applied.  In this case the 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 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:










Wakikawa (Editor)         Expires May 22, 2008                 [Page 19]


Internet-Draft               HA Reliability                November 2007


        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: Home Agent Hello Message

   Sequence #

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

   Home Agent Preference

      16-bit unsigned integer.  The preference for the home agent
      sending this Hello 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 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.







Wakikawa (Editor)         Expires May 22, 2008                 [Page 20]


Internet-Draft               HA Reliability                November 2007


   Group Identifier

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

   A flag

      If this flag is set, the sender of this Hello message is an active
      home agent.  Otherwise, the sender is a standby home agent.

   R flag

      If this flag is set, the receiver of this Hello message must send
      back a 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.  Home Agent Switch Message

   This message is defined in Section 8.3.  The Home Agent Reliability
   protocol extends this message for the Home Agent Hard Switch.















Wakikawa (Editor)         Expires May 22, 2008                 [Page 21]


Internet-Draft               HA Reliability                November 2007


       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: Home Agent Switch Message

   IPsec Re-key (I)

      The IPsec rekey (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.  New Mobility Options

6.2.1.  IP address Option

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

   Option-Code

      *  4: Home Address

6.2.2.  Binding Cache Information Option

   The binding cache information option has an alignment requirement of
   8n+2.  Its format is as follows:





Wakikawa (Editor)         Expires May 22, 2008                 [Page 22]


Internet-Draft               HA Reliability                November 2007


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







Wakikawa (Editor)         Expires May 22, 2008                 [Page 23]


Internet-Draft               HA Reliability                November 2007


6.2.3.  AAA Information Option

   The AAA option is used to carry the AAA state of the mobile node's
   Mobile IPv6 sessions.  The AAA state information can be conveyed in
   RADIUS or Diameter AVP formats including the user and session info.
   This information option is only valid in a State Synchronization
   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: 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.














Wakikawa (Editor)         Expires May 22, 2008                 [Page 24]


Internet-Draft               HA Reliability                November 2007


7.  Home Agent Operation

7.1.  Home Agent Address Configuration

   Each standby home agent obtains its individual IPv6 address from its
   attached link.  This IPv6 address is used by the home agent
   reliability protocol to exchange information with the associated home
   agents.  The 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 standby home agents.  When a home agent fails, the standby home
   agent activates the IPv6 address of the failed home agent and becomes
   the active home agent.  The standby home agent should not activate
   the IPv6 address until it knows the active home agent is no longer
   reachable at the address, otherwise address duplication will occur.
   To guarantee transparency of the home agent virtual switch to mobile
   nodes located on the home link, the neighbor cache of the home agent
   IP address MUST be carefully operated.  See Section 7.2 in detail.

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

7.2.  Consideration of Routing and Neighbor Discovery Protocol

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

   When a standby home agent becomes active in the Home Agent Virtual
   Switch mode, it MUST start to advertise the home agent address and
   the home prefix of the home addresses serviced by the redundant home
   agent set into the routing infrastructure.  This operation is
   normally done using a route selector such as BGP or an OSPF modifier.
   For example, we can use the AS_Path prepend operation for BGP, and
   the Metric field in OSPF for route selection.

   For instance, home agents should run OSPF with the appropriate cost
   so that the active home agent whose preference is highest can receive



Wakikawa (Editor)         Expires May 22, 2008                 [Page 25]


Internet-Draft               HA Reliability                November 2007


   the packets from the other routers on the home link.  When the active
   home agent is down, OSPF detects the failure and can dynamically
   switch the route to the standby home Agent based on the OSPF cost
   value.  If this cost conflicts with the home agent preference value
   due to misconfiguration, the routers on the home link may not route
   packets to the desired standby home agent.  Therefore, the home agent
   MAY dynamically change the OSPF cost based on the 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 the home link.

   When an active home agent activates a home agent address, it SHOULD
   use a virtual MAC address as introduced in [RFC-3768].  When the
   active home agent is changed, the neighbor cache of the active home
   agent is not necessarily updated on mobile nodes located on the home
   link.  Otherwise, the new home agent MUST update the neighbor cache
   entry for the home agent address on all the mobile nodes located on
   the home link.  In addition, Mobile IPv6 uses proxy NDP to intercept
   packets meant for mobile nodes which are away from the home link.
   However, it is unnecessary for the new active home agent to overwrite
   the existing proxy neighbor entries of the mobile nodes.

7.3.  Home Agent List Management

   In Mobile IPv6 [RFC-3775], each home agent periodically sends router
   advertisements with a 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 the Home Agent Reliability Protocol
   is used, Hello messages are used to update the home agent list.
   There are several reasons to use Hello message instead of Router
   Advertisement on the Home Agent Reliability protocol:

   1.  Router Advertisements are sent among home agents and also to
       mobile nodes.  When the Home Agent Virtual Switch mode is used,
       standby home agents MUST NOT generate unsolicited Router
       Advertisements.  The standby home agents MUST be transparent to
       all mobile nodes.  Hello messages are exchanged only with other
       home agents.

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

   3.  The Home Agent Reliability protocol is required to exchange
       additional information such as Group ID and Active/Standby Status



Wakikawa (Editor)         Expires May 22, 2008                 [Page 26]


Internet-Draft               HA Reliability                November 2007


       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 in the Hello
   messages.  However, mobile nodes located on the home link require
   this information for home agent discovery.  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.  Router Advertisements are used to carry the home
   agent information for mobile nodes, and Hello message are used to
   carry information for Home Agent Reliability operation.  If an
   operator decides not to use the Hello messages, Router Advertisements
   MUST be used to update the home agent list.

   Since Hello messages carry all the necessary information filled-in
   from the home agent list, the management 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
   in detail.

7.4.  Detecting Home Agent Failure

   The active and standby home agents can monitor each other's status in
   multiple ways.  One method is to reuse other failure detection
   mechanisms such as VRRP[RFC-3768] and HSRP [RFC-2281] described in
   Section 7.10.  This document also defines its own method by using
   periodic exchanges of Hello messages to monitor status.  The reasons
   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 used in
       this scenario since their scope is link-local.  Thus, Hello
       messages are necessary to exchange home agent information among
       home agents in a globally redundant home agent set.

   2.  If Router Advertisements and VRRP are used for periodic messages,
       they may not detect the case where the system is running but the
       Mobile IPv6 stack is not operational.  Mobile IPv6 may be
       implemented as a userland daemon, so if Hello messages are used,
       the failure of a home agent can be easily detected, assuming
       Hello message functionality is implemented in the same home agent
       daemon.

   3.  Hello messages can be frequently exchanged to detect failure,
       while there is a restriction on how often Router Advertisements
       can be sent, and on how they are processed by routers that



Wakikawa (Editor)         Expires May 22, 2008                 [Page 27]


Internet-Draft               HA Reliability                November 2007


       receive them.  Router Advertisements are also not sent frequently
       enough to rely on their absence to detect a home agent failure.

   A Hello request message (R-flag set) may be used by any home agent to
   request state information from any other home agent in the redundant
   home agent set.  If a Hello message is not received from a home agent
   peer within a configurable amount of time, then that home agent peer
   is considered to have failed.  The detail of the Hello message is
   described in Section 7.6.  Failure events used in the Home Agent
   Reliability protocol are listed below.

   Loss of Communication with the Active Peer Home Agent

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

   Monitored Server Failure by the Active Home Agent

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

   Routing Peer/Link Failure

      In some cases, an operator may require the home agent to detect a
      next-hop routing peer failure.  If the next-hop routing peer
      fails, the operator may want the home agent to initiate a switch-
      over procedure if the failure is fatal in nature, or due to some
      other routing policies.

7.5.  Home Agent Switch Over

   After detecting the active home agent has failed, the standby home
   agent whose preference value is the highest MUST take over for the
   failed home agent.  Alternately, if Home Agent Control messages are
   used, a standby home agent who will be the new active home agent is
   determined during the Home Agent Control message exchanges.

   In the Home Agent Virtual Switch mode, the standby home agent MUST
   activate the virtual home agent address.  If a virtual MAC address as
   introduced in [RFC-3768] is used, the standby home agent MUST start
   using the virtual MAC address as well.  Since all the necessary state



Wakikawa (Editor)         Expires May 22, 2008                 [Page 28]


Internet-Draft               HA Reliability                November 2007


   has already been transferred to this standby home agent before the
   active home agent failed, it can immediately start acting as the
   active home agent.

   In the Home Agent Hard Switch mode, the standby home agent MUST send
   a Home Agent Switch message to all the mobile nodes that were
   registered at the failed home agent as described in Section 7.9,
   using the pre-established IPsec SA.  The standby Home Agent MUST set
   its own address in the Home Agent Address field in the Home Agent
   Switch message so that it will receive the binding update from the
   mobile node as an acknowledgement of the sent Home Agent Switch
   message.  The home agent switch-over is complete when it receives
   binding updates from all the mobile nodes.  It is important to remark
   that sending Home Agent Switch messages to all the mobile nodes at
   once may bring non-negligible overhead to the home agent.

   This overhead cannot be avoided if 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 the administrative operation (maintenance, etc), the previous
   active home agent may continue serving the mobile nodes until the
   switch over is 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 Home Agent Hard Switch.  Therefore, the
   new active home agent can notify the completion 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, the
   previous active home agent can be shutdown or detached from the
   network safely.

7.6.  Processing Hello Messages

   Hello messages can be unicasted or multicasted.  A new multicast
   address will be assigned by the IANA.  When all home agents in a
   redundant home agent set are configured on a same home link, they
   MUST join a new multicast address (TBA) and multicast Hello.  On the
   other hand, if a home link is separated as described in Figure 2,
   each home agent MUST unicast Hello messages.

7.6.1.  Requesting Hello Message

   A home agent can solicit a Hello message from a particular home agent
   in the same redundant home agent set by unicasting a Hello message
   with the R-flag set.  The sender MUST fill the fields of the Hello
   message with its home agent information.  A home agent can solicit a
   Hello message from all the home agents in the multicast group by
   multicasting a Hello message with the R-flag set.  This Hello request
   message SHOULD be generated when:



Wakikawa (Editor)         Expires May 22, 2008                 [Page 29]


Internet-Draft               HA Reliability                November 2007


   o  A new home agent needs to collect information of the other home
      agents in the same redundant home agent set.  In this case it
      SHOULD multicast a Hello message in which the R-flag is set.

   o  A home agent entry in 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 the specified hello
      interval.

7.6.2.  Sending Hello Message

   The Hello message 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 the home agents of the 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 the R-flag set in parallel with
   sending its own Hello message.

   Whenever a home agent generates Hello message, it MUST increment in
   the Sequence Number by 1.  The Sequence Number SHOULD be initialized
   to zero for the first Hello message.  To accomplish sequence number
   rollover, if the sequence number has already been assigned to be the
   largest possible number representable as a 16-bit unsigned integer,
   then when it is incremented it will then have a value of zero (0).
   It MUST also specify its own Group ID in the Group ID field of the
   Hello message.  If a home agent is the active home agent, it MUST set
   the A-flag in it's Hello Messages.  In the Home Agent Hard Switch
   mode, the source address of Hello messages MUST be the configured
   home agent address.  In the Home Agent Virtual Switch mode, the
   individual IPv6 addresses 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 the message is not protected, it SHOULD be
   silently discarded.  However, if the Hello messages is sent on a
   dedicated link between the home agents, IPsec protection is not
   required.  If a Hello message is sent from an IPv6 address whose
   scope is not global, the message MUST be silently discarded.

   If the sending home agent is not in the same redundant home agent
   set, the message MUST be silently ignored.  This can be done by
   comparing the Group ID field of the received Hello message with its



Wakikawa (Editor)         Expires May 22, 2008                 [Page 30]


Internet-Draft               HA Reliability                November 2007


   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 in the Hello message is equal to or less than the Sequence
   Number value stored in the home agent list entry, the Hello message
   MUST be discarded.

   Any Hello message satisfying all of these tests MUST be processed to
   update the redundant home agent list.  The receiver copies home agent
   information in the Hello message to the corresponding redundant home
   agent list entry.  The home agent address of the sender is retrieved
   from the Source Address field of the IPv6 header of the Hello
   message.  If the home agent lifetime field in the Hello message is
   set to 0, the receiver removes the sender from the redundant home
   agents list.

   If the R-flag is set in the received Hello message, the receiver MUST
   reply with a Hello message 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 of each mobile node registered with the active home
   agent.  In the Home Agent Virtual Switch mode, the synchronized state
   information is used by a standby home agent when it takes over for
   the failed home agent.  In the Home Agent Hard Switch mode, the
   standby home agent starts the switch-over of all the mobile nodes
   registered to the failed home agent when the home agent failure is
   detected.  Thus, the Binding Cache entry MUST be modified to keep the
   active home agent address of each mobile node.

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

   When a standby home agent wants state information for a particular
   mobile node or a subset of mobile nodes, such as Binding Cache, AAA,
   etc., it MAY solicit this state by sending a State Synchronization
   message constructed as follows:

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

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

   o  It MUST include either a IP address mobility option which subtype
      is set to home address indicating the mobile node, or a Mobile
      Network Prefix mobility option indicating the mobile router.  The
      standby home agent can send multiple home address and mobile



Wakikawa (Editor)         Expires May 22, 2008                 [Page 31]


Internet-Draft               HA Reliability                November 2007


      network prefix mobility options to request state information for
      multiple mobile nodes in a single State Synchronization request
      message.

   o  It MUST set the unspecified address (0::0) in the Home Address
      mobility option if it solicits all the active mobile nodes' and
      mobile routers' state at once.

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

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

   o  The sending home agent MUST belong to the same redundant home
      agent set

   o  The receiver MUST be 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 MUST be silently ignored.

   Otherwise, the receiver 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  When an active home agent receives a state synchronization message
      in which the Type field is set to 0 (Request).

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

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

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




Wakikawa (Editor)         Expires May 22, 2008                 [Page 32]


Internet-Draft               HA Reliability                November 2007


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

   If 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 is stored
   in 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, the active home agent MUST copy the Identifier field of the
   State Synchronization request message to the Identifier field in the
   State Synchronization reply message.  Otherwise, it MUST set the
   Identifier field to 0.

   When the active home agent stores the state of multiple mobile nodes
   in a state synchronization message, a Binding Cache Information
   option is used as a separator.  For each mobile node, a Binding Cache
   Information option is placed first, followed by any other options.
   When the next Binding Cache Information option is reached in the
   State Synchronization message, it indicates the information of a
   different mobile node.

   If the unspecified address is found in the Home Address mobility
   option carried with the State Synchronization request message, the
   active home agent MUST return all the active mobile nodes' and mobile
   routers' states by the State Synchronization reply message.  The IP
   fragmentation can be occurred depending on the total size of all the
   states.

   A State Synchronization message MUST be authenticated and encrypted
   by IPsec ESP mode, otherwise the message MUST be ignored.  When a
   home agent receives a State Synchronization message, it MUST verify
   the Source address field of the IPv6 header.  If the source address
   does not belong to any home agent in the redundant home agent set,
   the message MUST be silently discarded.  After successfully verifying
   the message, 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).







Wakikawa (Editor)         Expires May 22, 2008                 [Page 33]


Internet-Draft               HA Reliability                November 2007


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 the link between home agents is stable and reliable.
   However, operators may need more explicit notification to confirm the
   message exchanges between home agents.  This specification provides
   an optional acknowledgment for the State Synchronization Reply
   message.

   If an active home agent requires an acknowledgment of a State
   Synchronization Reply message, it MUST set the Ack flag in the
   message.  If a standby home agent receives a State Synchronization
   Reply message with the Ack flag set, it MUST send back a State
   Synchronization Reply-Ack message as an acknowledgment.

   The standby home agent MUST copy the Identifier received in the State
   Synchronization Reply message into the Reply-Ack and set the type
   field to 2 (Reply-Ack).

7.8.  Processing Home Agent Control Messages

7.8.1.  Standby Home Agent becomes an Active Home Agent

   When a standby home agent decides to become an active home agent, the
   standby home agent sends a SwitchOver Request message (a Home Agent
   Control message in which the Type field is set to 0) to the active
   home agent.  This message MUST be unicasted to the active home agent
   and MUST be encrypted and authenticated by IPsec ESP.  The active
   home Agent MUST NOT generate this message.

   When an active home agent receives a SwitchOver Request, it first
   verifies the received Home Agent Control message.  If the request
   message is not protected by IPsec, it MUST be silently discarded.  If
   the home agent is not an active home agent, it MUST send a SwitchOver
   Reply message (a Home Agent Control message in which the Type field
   is set to 1) with the Status field set to 130 (Not active home
   agent).  If the receiver 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 the Status field set to 129
   (Administratively prohibited).  In addition, if the sending home
   agent does not belong to the same redundant home agent set, a
   SwitchOver Reply message MUST be sent to the sender with the Status
   field set 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 field set to 0 (Success).




Wakikawa (Editor)         Expires May 22, 2008                 [Page 34]


Internet-Draft               HA Reliability                November 2007


   The SwitchOver Reply message MUST be protected by IPsec ESP.
   Otherwise, the message MUST be silently discarded.  If the receiving
   home agent did not send a SwitchOver Request message (i.e. unexpected
   SwitchOver Reply), the message MUST be silently ignored.  If the
   Status 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 home agent decides to become an in-active home agent,
   it sends a SwitchBack Request message (i.e. a Home Agent Control
   message with Type field set to 3) to a standby home agent.  The
   reason for the active home agent to send this message can be
   administrative intervention, and events like Monitored Server Failure
   by the active home agent or Routing Peer/Link Failure.  This message
   MUST be unicasted to one of the standby home agents and MUST be
   encrypted and authenticated by IPsec ESP.  A standby home agent MUST
   NOT generate this message.

   A SwitchBack Reply is sent in reply to a SwitchBack Request message.
   When a home agent receives a SwitchBack Request message, it first
   verifies the message.  If the SwitchBack Request message is not
   protected by IPsec ESP, it MUST be silently discarded.  If the
   sending home agent of the SwitchBack Request message is not an active
   home agent, the receiver MUST reply with a SwitchBack Reply (a Home
   Agent Control message in which the Type field is set to 4) in which
   the Status field is set to 130 (Not active home agent).  If the
   sending home agent does not belong to the same redundant home agent
   set, a SwitchBack Reply message MUST be sent in which the Status
   field set to 132 (Not in same redundant home agent set).  Otherwise,
   the receiving home agent MUST send a SwitchBack Reply message in
   which the Status field is set to 0 (Success).  After sending the
   SwitchBack reply, it MUST NOT become an active home agent
   immediately.  This is because the active home agent is still active
   until it receives the SwitchBack Reply message acknowledging the
   SwitchBack Request.  The standby home agent SHOULD change to active
   at least after LINK_TRAVERSAL_TIME.

   If a home agent receives a SwitchBack Reply message, it MUST be
   protected by IPsec ESP, otherwise the message MUST be silently
   discarded.  If the receiving home agent did not send a SwitchBack
   Request message beforehand, the message MUST be silently discarded.
   If the Status field of the SwitchBack Reply message is 0 (Success),
   the receiving home agent immediately becomes an in-active home agent
   and the standby home agent becomes active home agent as described in



Wakikawa (Editor)         Expires May 22, 2008                 [Page 35]


Internet-Draft               HA Reliability                November 2007


   Section 7.5.  If the value in the Status field is greater than 128,
   an error has occurred.  In this case, the receiver cannot become an
   in-active home agent and MUST continue to be an active home agent.

7.8.3.  Notification of Home Agent Switch Completion

   If the new active home agent completes the switch-over as described
   in Section 7.5, it SHOULD send a Home Agent Control message with the
   type field set to 4 (Switch Complete) to the previous active home
   agent in the Home Agent Hard Switch case.  Until the previous home
   agent receives this message, it SHOULD continue serving any mobile
   nodes that are registered with it.  Once the previous home agent
   receives a Switch Complete message, it can stop offering home agent
   services.

7.9.  Sending Home Agent Switch Messages

   This operation is valid only for the Home Agent Hard Switch mode.
   The standby home agent MUST send a Home Agent Switch message as
   defined in [ID-HASWITCH] to all the mobile nodes that were being
   served by the failed home agent.  Since the active home agent address
   is recorded in each synchronized binding cache, the standby home
   agent knows which mobile nodes were served by the failed home agent.
   The Home Agent Switch message must be encrypted with a pre-
   established SA.  The standby home agent MUST include only its own
   IPv6 address in the Home Agent Switch message.  Note that a Home
   Agent Switch message is sent to each mobile node served by the home
   agent.  If there is a large number of mobile nodes, sending Home
   Agent Switch messages will cause a lot of signaling overhead on the
   network.  The previous active home agent MAY serve mobile nodes while
   the new active home agent completes the sending home agent switch and
   receiving binding update from all the mobile nodes.  This is the case
   when the previous home agent will be halt due to administrative
   reason.

   When a failed home agent recovers, it MUST re-establish an IPsec SA
   with each mobile node served by its redundant home agent set.
   Otherwise, it cannot be either a standby or active home agent for the
   mobile nodes.  Therefore, as soon as the active home agent detects
   the recovery of the failed home agent, it sends a 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 set, and includes the
   recovered home agent address in the Home Agent Addresses field.  The
   mobile node will re-key the SA, but it will not change the home agent
   by this home agent switch message which I-flag is on.






Wakikawa (Editor)         Expires May 22, 2008                 [Page 36]


Internet-Draft               HA Reliability                November 2007


7.10.  Interworking with VRRP

   VRRP and HSRP specify an election protocol that dynamically assigns
   responsibility for a virtual router to one of the VRRP routers on a
   LAN.  This operation is similar to the Home Agent Virtual Switch
   operation.  For example, the VRRP router controlling the IP
   address(es) associated with a virtual router is called the Master,
   and forwards packets sent to these IP addresses.  The election
   process provides dynamic fail over in the forwarding responsibility
   should the Master become unavailable.  Although VRRP is used to
   guarantee home agent address reachability, it cannot be used for
   state synchronization and explicit switching of Master and Backup.
   Thus, the Home Agent Reliability protocol cannot be replaced by VRRP.
   This section explains how VRRP can interwork with the Home Agent
   Reliability protocol.

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

   In addition to this, VRRP is useful only if all home agents are
   located on the same link.  If the home agents are topologically
   separated, the Home Agent Reliability protocol MUST be used.


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




Wakikawa (Editor)         Expires May 22, 2008                 [Page 37]


Internet-Draft               HA Reliability                November 2007


                       Figure 12: VRRP Packet Format

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

   Virtual Rtr ID

      Group ID is stored in the Virtual Rtr ID field.

   Priority

      Home Agent Preference is stored in the Priority field.  Note that
      VRRP only has 8 bits for the Priority field.  Therefore, values
      larger than 255 MUST NOT be assigned to the preference value.

   Count IPv6 IPv6 Addr

      This field MUST be always be 1.

   Advert Int

      This field MUST be mapped to the Hello Interval field of the Home
      Agent Hello message, though it only has 12 bytes.

   IPv6 address

      A home agent address is stored in this field.

   Home Agent Lifetime, Sequence Number and Flags field are missing in
   the VRRP packet format.  Therefore, operators SHOULD use the same
   statically configured value for Home Agent Lifetime.  Each home agent
   does not check freshness of received VRRP message because of no
   sequence number.  If VRRP is used, a home agent cannot determine the
   active home agent from the VRRP message due to lack of A flag, and
   cannot request a VRRP advertisement to other home agents.

7.11.  Retransmissions and Rate Limiting

   Standby and active home agents are responsible for retransmissions
   and rate limiting of a State Synchronization Request, Switchover
   Request, SwitchBack Request messages for which they expect a
   response.  The home agent MUST determine a value for the initial
   transmission timer:

   o  If the home agent sends a State Synchronization Request message,
      it SHOULD use an initial retransmission interval of
      INITIAL_STATE_SYNC_REQ_TIMER.




Wakikawa (Editor)         Expires May 22, 2008                 [Page 38]


Internet-Draft               HA Reliability                November 2007


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

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

   If the sending home agent fails to receive a valid matching response
   within the selected initial retransmission interval, it SHOULD
   retransmit the message until a response is received.  All of the
   above constants are specified in Section 10.

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





























Wakikawa (Editor)         Expires May 22, 2008                 [Page 39]


Internet-Draft               HA Reliability                November 2007


8.  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.  Home Agent Addresses Discovery

   To provide home agent reliability with 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 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 a home network.  In
   order to discover these 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.  IKE/IPsec pre-establishment to Home Agents

   After a mobile node gets 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



Wakikawa (Editor)         Expires May 22, 2008                 [Page 40]


Internet-Draft               HA Reliability                November 2007


   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.  Receiving Home Agent Switch message

   A mobile node must follow the operation specified in [ID-HASWITCH]
   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,
   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 the standby home agent in the switch
   message as the active home agent and send a Binding Update message to
   it.  Note that the standby home agent address in the switch message
   MUST be equal to the sender of the Home Agent Switch message.  This
   is because the standby Home agent expects the Binding Update as an
   acknowledgement of the Home Agent Switch message.  The mobile node
   already has a pre-established SA with the home agent 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.













Wakikawa (Editor)         Expires May 22, 2008                 [Page 41]


Internet-Draft               HA Reliability                November 2007


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





Wakikawa (Editor)         Expires May 22, 2008                 [Page 42]


Internet-Draft               HA Reliability                November 2007


      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.































Wakikawa (Editor)         Expires May 22, 2008                 [Page 43]


Internet-Draft               HA Reliability                November 2007


10.  Protocol Constants

      INITIAL_STATE_SYNC_REQ_TIMER: 3sec

      INITIAL_SWICHOVER_REQ_TIMER: 1sec

      INITIAL_SWICHBACK_REQ_TIMER 1sec

      LINK_TRAVERSAL_TIME 150msec










































Wakikawa (Editor)         Expires May 22, 2008                 [Page 44]


Internet-Draft               HA Reliability                November 2007


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





Wakikawa (Editor)         Expires May 22, 2008                 [Page 45]


Internet-Draft               HA Reliability                November 2007


   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]











































Wakikawa (Editor)         Expires May 22, 2008                 [Page 46]


Internet-Draft               HA Reliability                November 2007


12.  Contributors

   This document is a result of discussions in the Mobile IPv6 Home
   Agent Reliability Design Team.  The members of the design team that
   are listed below 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.  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.




Wakikawa (Editor)         Expires May 22, 2008                 [Page 47]


Internet-Draft               HA Reliability                November 2007


14.  References


14.1.  Normative References

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

   [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] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
   July 2005.

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




Wakikawa (Editor)         Expires May 22, 2008                 [Page 48]


Internet-Draft               HA Reliability                November 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),
   June 2007.

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





































Wakikawa (Editor)         Expires May 22, 2008                 [Page 49]


Internet-Draft               HA Reliability                November 2007


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)

   o  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
   Japan

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/











Wakikawa (Editor)         Expires May 22, 2008                 [Page 50]


Internet-Draft               HA Reliability                November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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


Intellectual Property

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





Wakikawa (Editor)         Expires May 22, 2008                 [Page 51]


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