MIP6 Working Group                                  R. Wakikawa (Editor)
Internet-Draft                                           Keio University
Expires: December 21, 2006                                 June 19, 2006


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

Status of this Memo

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

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

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

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

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

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

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 for achieving home agent
   reliability.  Note that this document is not completed yet.  DT is
   still discussing some items.




Wakikawa (Editor)       Expires December 21, 2006               [Page 1]


Internet-Draft           Home Agent Reliability                June 2006


Table of Contents

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

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

   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  7

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

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

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

   7.  Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 29
     7.1.  Home Agent Configuration . . . . . . . . . . . . . . . . . 29
     7.2.  Hello messages Manipulation  . . . . . . . . . . . . . . . 30
       7.2.1.  Sending Hello Request  . . . . . . . . . . . . . . . . 31
       7.2.2.  Receiving Hello Request  . . . . . . . . . . . . . . . 31
       7.2.3.  Sending Hello  . . . . . . . . . . . . . . . . . . . . 31
       7.2.4.  Receiving Hello  . . . . . . . . . . . . . . . . . . . 32
     7.3.  Failure Detection  . . . . . . . . . . . . . . . . . . . . 32
     7.4.  Active Home Agent Change . . . . . . . . . . . . . . . . . 33
     7.5.  Processing State Synchronization Messages  . . . . . . . . 34
       7.5.1.  Sending State Synchronization Request  . . . . . . . . 34
       7.5.2.  Receiving State Synchronization Request  . . . . . . . 34
       7.5.3.  Sending State Synchronization  . . . . . . . . . . . . 34
       7.5.4.  Receiving State Synchronization  . . . . . . . . . . . 35
     7.6.  Processing Home Agent SwitchOver Messages  . . . . . . . . 35
       7.6.1.  Sending Home Agent SwitchOver Request  . . . . . . . . 35
       7.6.2.  Sending Home Agent SwitchOver Reply  . . . . . . . . . 36



Wakikawa (Editor)       Expires December 21, 2006               [Page 2]


Internet-Draft           Home Agent Reliability                June 2006


       7.6.3.  Receiving Home Agent SwitchOver Reply  . . . . . . . . 36
     7.7.  Processing Home Agent SwitchBack Messages  . . . . . . . . 36
       7.7.1.  Sending Home Agent SwitchBack Request  . . . . . . . . 36
       7.7.2.  Sending Home Agent SwitchBack Reply  . . . . . . . . . 37
       7.7.3.  Receiving Home Agent SwitchBack Reply  . . . . . . . . 37
     7.8.  Sending Home Agent Switch Message  . . . . . . . . . . . . 37

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

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

   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43

   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 44
     12.2. Informative References . . . . . . . . . . . . . . . . . . 44

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



























Wakikawa (Editor)       Expires December 21, 2006               [Page 3]


Internet-Draft           Home Agent Reliability                June 2006


1.  Introduction

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

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

































Wakikawa (Editor)       Expires December 21, 2006               [Page 4]


Internet-Draft           Home Agent Reliability                June 2006


2.  Terminology

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

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

   Some of the mobility related terms used in this document are defined
   in [1] and [7].  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 pair of an Active Home Agent and Standby Home Agent(s).  The
      Group Identifier is introduced 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 DHAAD in RFC3775.  This
      protocol uses this preference value for home agent selection when
      an active home agent is failed.  However, an operator can also
      define an independent value only for home agent reliability
      protocol if the operator wants to have different preference value
      for DHAAD and home agent reliability protocol.  A Home Agent
      SHOULD NOT use the same preference value of other Home Agents for
      this protocol.



Wakikawa (Editor)       Expires December 21, 2006               [Page 5]


Internet-Draft           Home Agent Reliability                June 2006


   Home Agent Hard Switch

      The Home Agent Hard Switch is used when IPsec states cannot be
      synchronized between an active and a Standby Home Agent.  In this
      case each home agent negotiates independent IPsec SAs with a
      mobile node.  The mobile node will be notified to change its home
      agent to one of Standby Home Agent.

   Home Agent Virtual Switch

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




































Wakikawa (Editor)       Expires December 21, 2006               [Page 6]


Internet-Draft           Home Agent Reliability                June 2006


3.  Problem Statement

   In Mobile IPv6 base specification, a mobile node registers and
   establishes a connection 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 serving Home Agent, mobile node can re-establish
   its connection through the new Home Agent.  However, base Mobile IPv6
   specification does not address the 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 co-ordination or pre-configuration among the Home agents
   regarding security association, transfer of mobile-node related
   binding and other service information for the reliable Mobile IPv6
   service in a deployment scenario.
































Wakikawa (Editor)       Expires December 21, 2006               [Page 7]


Internet-Draft           Home Agent Reliability                June 2006


4.  Goals for the Solution

   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 is 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 the
      application and should not take longer than care-of-addresses
      update procedure described in the Mobile IPv6 [1].

   Availability of a redundant home agent set

      Availability of an Active Home Agent address and a standby Home
      Agent address at the bootstrapping period to Mobile Node is
      assumed.

   State Synchronization

      The information for mobile nodes must be synchronized between an
      Active Home Agent and Standby Home Agents.  The information is
      Binding Cache, IPsec/IKE states, AAA information, vendor specific
      information.

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

   Failure Notification






Wakikawa (Editor)       Expires December 21, 2006               [Page 8]


Internet-Draft           Home Agent Reliability                June 2006


      If necessary a mobile node is notified about the active home agent
      failure by the Standby Home Agent in Home Agent Hard Switch mode
      of operation
















































Wakikawa (Editor)       Expires December 21, 2006               [Page 9]


Internet-Draft           Home Agent Reliability                June 2006


5.  Protocol Overview

   This specification provides two modes for home agent local
   reliability.

   o  Home Agent Virtual Switch: In this mode the active and the
      redundant home agents are all accessible through the same IP
      address.  IPsec/IKE states must be synchronized between the active
      and a redundant home agent(s).  The mechanism used to synchronize
      IPsec state is currently considered out of scope for this document
      and not described here.  In this mode, a mobile node always
      establishes IPsec SAs only with the Active Home Agent.  The IPsec
      state will be shared within the redundant home agent set in
      background.  In case there is a failure the Standby Home Agent
      takes over without the mobile node being aware of the change in
      the home agent.

   o  Home Agent Hard Switch: In this mode the home agents are addressed
      by different IP addresses and the mobile node is aware of the
      change in the home agent.  This mode is also useful when the IPsec
      state cannot be synchronized.  In this mode, a standby home agent
      must solicit mobile nodes to re-establish IPsec/IKE for Mobile
      IPv6 signaling.  This IPsec re-establishment is triggered when a
      mobile node changes its home agent after receiving a home agent
      switch message from a standby home agent.  In order to exchange
      this message securely between a Standby Home Agent and a mobile
      node, a mobile node need to establish IPsec SA with both an Active
      Home Agent and redundant home agents beforehand.  With this
      multiple IPsec SAs, a mobile node will receive a notification from
      the Standby Home Agent and start to use the Standby Home Agent
      when the Active Home Agent failed.

   All new messages defined in this document are defined as Mobility
   Header messages so that the HA reliability protocol can be extended
   later, if needed, to provide home link redundancy. (i.e.  Protocol is
   not tight with the link boundary)

5.1.  Home Agent Virtual Switch

   In the case of the virtual home agent switch, a mobile node remains
   agnostic about the change in the serving home agent.  The home agents
   have replicated all session state including the IPsec/IKE/ESP sates.
   The ESP sequence numbers, which is used to prevent replay attack, may
   not be synchronized momentarily.  However, this should not pose any
   problem as both ends of the IPsec ESP tunnel should use sequence
   numbers that are greater than the last known sequence numbers to
   either ends.  The Standby Home Agent should add a random number (+n)
   over and above the anti-replay window to ensure that the packet



Wakikawa (Editor)       Expires December 21, 2006              [Page 10]


Internet-Draft           Home Agent Reliability                June 2006


   received by the mobile node passes ESP replay check.

   The operations of the Home Agent Virtual Switch are shown in
   Figure 1.  After binding registration is done (2, 3), the Active Home
   Agent pushes all the states of mobile nodes by a state
   synchronization message in a periodic interval (4).  The Active Home
   Agent synchronizes the IPsec state information with the Standby Home
   Agent(s), too.  This state synchronization should be done
   periodically in order to match the ESP sequence number and anti-
   replay window among home agents.  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 from the Failed Home Agent.  All the home agents in
   the redundant home agent set share a virtual address and the routing
   will ensure only the Active Home Agent will be reachable using that
   virtual 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.


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


   Figure 1: Overview of Home Agent Virtual Switch

5.2.  Home Agent Hard Switch

   The Home Agent Hard Switch is shown in Figure 2.  This mode is not
   transparent to mobile node when there is a home agent failure and
   another home agent takes over.



Wakikawa (Editor)       Expires December 21, 2006              [Page 11]


Internet-Draft           Home Agent Reliability                June 2006


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


   Figure 2: Overview of Home Agent Hard Switch

   In this mode, a mobile node establish IPsec SA with multiple home
   agents beforehand.  When an Active Home Agent fails, the other
   Standby Home Agent could use pre-existing IPsec SA to notify the
   Mobile Node about the failure.  After the notification, the mobile
   node will use the Standby Home Agent as its home agent.

   In order to discover the home agent address, two different mechanisms
   are defined in the bootstrapping solution in split scenario.  One is
   DNS lookup by home agent Name, the other is DNS lookup by Service
   Name.  The mobile node sends a DNS SRV request and acquires IP
   addresses and preferences of a redundant home agent set.  In
   integrated scenario, DHCPv6 is used to provide home agent provision
   to Mobile Node.

   The mobile node establishes IPsec/IKE state with the other acquired
   home agents beforehand (1 and 4), however it registers only with the
   Active Home Agent (2 and 3).  The Active Home Agent synchronizes
   required states of mobile nodes such as Binding Cache information and
   AAA information, etc. with other standby home agents periodically
   (5).

   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



Wakikawa (Editor)       Expires December 21, 2006              [Page 12]


Internet-Draft           Home Agent Reliability                June 2006


   nodes that were registered to the Failed Home Agent (7).  The home
   agent switch message must be encrypted by pre-established IPsec SA.
   After the switch message, the mobile node MAY send a binding update
   and registers it with the new Active Home Agent in order to update
   MIP6 tunnel's end points (8).  However, this binding registration can
   be skipped since the Standby Home Agent synchronizes the binding
   cache information with the Active Home Agent periodically.  The
   mobile node only changes its home agent address to the new Active
   Home Agent.

5.3.  Failure Detection and Home Agent Management


       HA1(active)  HA2    HA3 .. HAn
           |        |      |      |
           |<------>|      |      | 1. Hello exchange
           |<------------->|      |
           |<-------------------->|
           |        |      |      |
        (Failed)    |      |      | A FAILURE OCCURS
           X        |      |      |
           X        |      |      | 3. Standby HAs detects
           X        |      |      |    failure.
           X        |      |      |
           X     (active)  |      | 4. HA2 becomes Active HA
           X        |      |      |
           |        |      |      | HA1 RECOVER NOW
       (standby)    |      |      |
           |------->|      |      | 5. HA1 sends SwitchOver Request
           |<-------|      |      | 6. HA2 sends SwitchOver Reply
           |        |      |      |
       (active) (standby)  |      | 7. HA1 returns to active HA
           |        |      |      |
           |        |      |      | HA1 BECOMES ACTIVE AGAIN


   Figure 3: Home Agent Management

   Figure 3 illustrates the mechanism by which a Standby Home Agent
   takes over from a failed home agent.  This operation is common for
   both the hard and the virtual switch modes.  The home agent whose
   preference is the highest among the Standby Home Agents takes over
   immediately after it detects failure of the Active Home Agent.  The
   preference value can be same as the home agent preference value of
   RFC3775, while the operator can define an independent value only for
   home agent reliability protocol.

   The Home Agents in the redundant Home Agent set exchange periodic



Wakikawa (Editor)       Expires December 21, 2006              [Page 13]


Internet-Draft           Home Agent Reliability                June 2006


   Hello messages to convey their information to the peers (1).  The
   Hello messages can either be unicast or multicast.  In order to
   explicitly query the state information of its peer(s), any Home Agent
   can send a Hello request to its peer(s) in the redundant Home Agent
   set.  The Hello message exchange is the basis of failure detection
   and automatic switchover in this scheme (3 and 4).

   When HA1 recovers in Figure 3, it needs to remain in the standby
   state.  This prevents it to automatically take over from the
   currently active Home Agent.  HA1 sends a SwitchOver Request to the
   currently active Home Agent (i.e.  HA2) only if the system
   administrator issues a manual command, if the monitored server fails,
   if the routing peer/link fails.  The currently Active Home Agent can
   be known through the exchange of Hello messages.  HA1 may need to
   send Hello Request message to all the Standby Home Agents, when it
   recovered from the failure.  When HA2 receives the Home Agent
   SwitchOver Request from HA1 it changes its state to standby and sends
   back the SwitchOver Reply message to HA1.  HA1 returns to active home
   agent status immediately after receiving the SwitchOver reply.


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


   Figure 4: Manual Home Agent Change

   In some scenarios the Active Home Agent may need to stop serving the
   mobile nodes for system maintenance.  This specification provides
   manual home agent change by using Home Agent SwitchBack Request and
   Reply messages.  As shown in Figure 4, the Active Home Agent (HA1)
   sends Home Agent SwitchBack Request to an Standby Home Agent.  As
   soon as HA2 receives the message, it becomes the Active Home Agent.
   HA2 also acknowledges with the Home Agent SwitchBack reply to HA1.
   HA1 becomes standby when it receives the SwitchBack reply.  After the
   downtime, HA1 sends a Home Agent SwitchOver Request to HA2 in order



Wakikawa (Editor)       Expires December 21, 2006              [Page 14]


Internet-Draft           Home Agent Reliability                June 2006


   to return to become an Active Home Agent again.  This operation is
   same as Figure 3

















































Wakikawa (Editor)       Expires December 21, 2006              [Page 15]


Internet-Draft           Home Agent Reliability                June 2006


6.  Messages

   This document defines following new messages:

   o  New Mobility Header Messages

      *  Home Agent Hello Request Message

      *  Home Agent Hello Message

      *  State Synchronization Request Message

      *  State Synchronization Message

      *  Home Agent SwitchOver Request Message

      *  Home Agent SwitchOver Reply Message

      *  Home Agent SwitchBack Request Message

      *  Home Agent SwitchBack Reply Message

   o  New Mobility Options

      *  Binding Cache Information Option

      *  AAA Information Option

      *  Vendor Specific Information Option

   We may add more mobility options in the future document.  The DT is
   currently discussing the needs and the formats of IPsec/IKE state
   information Option and BGP/OSPF modifier option for state
   synchronization message.

   Home Agent Switch message is defined in [8].  This message is also
   used in operation of Home Agent Hard Switch.

6.1.  New Mobility Header Messages

6.1.1.  Home Agent Hello Request Message

   The message is unicasted to a home agent to solicit a Hello message
   from a home agent.  The receiver of this Hello Request message MUST
   return a Hello message to the originator of this request message.  A
   Home Agent Hello message SHOULD be authenticated and encrypted by
   IPsec ESP.




Wakikawa (Editor)       Expires December 21, 2006              [Page 16]


Internet-Draft           Home Agent Reliability                June 2006


   The Hello Request message has the MH Type value TBD.  When this value
   is indicated in the MH Type field, the format of the Message Data
   field in the Mobility Header is as follows:


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


   Figure 5: Home Agent Hello Request 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.

   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 Section 6.2 of [1].
      The receiver MUST ignore and skip any options which it does not
      understand.  There MAY be additional information, associated with
      this HELLO Request message that need not be present in all HELLO
      Request messages sent.  Mobility options allow future extensions
      to the format of the HELLO Request message to be defined.

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

6.1.2.  Home Agent Hello Message

   The message is either unicasted or multicasted to carry Home Agent
   information among the Redundant home agent set.  This Hello message
   is used by any home agents to detect the failure of a redundant peer
   in the redundant Home Agent set.  This message can be sent either
   periodically or in reply to Hello Request message.  A home agent



Wakikawa (Editor)       Expires December 21, 2006              [Page 17]


Internet-Draft           Home Agent Reliability                June 2006


   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.  Hence if multicast is used, the redundant Home Agent set
   should be in a secure network.

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

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

   The Hello message has the MH Type value TBD.  When this value is
   indicated in the MH Type field, the format of the Message Data field
   in the Mobility Header is as follows:


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


   Figure 6: Home Agent Hello Message

   Sequence #

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






Wakikawa (Editor)       Expires December 21, 2006              [Page 18]


Internet-Draft           Home Agent Reliability                June 2006


   Home Agent Preference

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

   Home Agent Lifetime

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

   Hello Interval

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

   Group Identifier

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

   A flag

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

   Reserved

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

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in [1].  The receiver
      MUST ignore and skip any options which it does not understand.

      The following options are valid in a Hello:

      *  IP Address Option (Sub-type: Home Agent Address): A Home Agent
         Address and its Prefix Length are stored in an IP address
         option.  If there are multiple home network prefixes serving by



Wakikawa (Editor)       Expires December 21, 2006              [Page 19]


Internet-Draft           Home Agent Reliability                June 2006


         a home agent, multiple IP address options should be used in a
         Hello message.

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

6.1.3.  State Synchronization Request Message

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

   The State Synchronization Request has the MH Type value TBD.  When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:


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


   Figure 7: State Synchronization Request Message

   Identifier

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

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in [1].  The receiver
      MUST ignore and skip any options which it does not understand.




Wakikawa (Editor)       Expires December 21, 2006              [Page 20]


Internet-Draft           Home Agent Reliability                June 2006


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

      *  IP Address Option (Sub-type: Home Address)[9].  If a Home
         Agents wants the Binding Cache information for a particular
         Mobile Node, it includes an IPv6 Address Option (Sub-type: Home
         Address).

      *  Mobile Network Prefix Option: If a home agent wants to know the
         forwarding state setting up for a particular Mobile Network
         Prefix, it includes a Mobile Network Prefix Option defined in
         [2].

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

6.1.4.  State Synchronization Message

   The State Synchronization message is used between the home agents in
   the Home Agent redundant set to exchange binding cache information,
   IPsec state and any other information related to providing mobility
   service to the mobile nodes.  It is an unicast message.  The state
   synchronization can be sent by an active home agent either
   periodically or in response to a state synchronization Request
   message.

   The State Synchronization message has the MH Type value TBD.  When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:


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


   Figure 8: State Synchronization Message





Wakikawa (Editor)       Expires December 21, 2006              [Page 21]


Internet-Draft           Home Agent Reliability                June 2006


   Identifier

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

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in [1].  The receiver
      MUST ignore and skip any options which it does not understand.

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

      *  Binding Cache Information Option.

      *  AAA Information Option.

      *  Vendor Specific Information Option.

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

6.1.5.  Home Agent SwitchOver Request Message

   This message is unicasted by a Standby Home Agent that desires to
   become the Active Home Agent for all the Mobile IPv6 sessions.  The
   receiver of the message MUST transit to inactive state as soon as the
   message is received and validated.

   The Home Agent SwitchOver Request message has the MH Type value TBD.
   The message MUST be authenticated and encrypted by IPsec ESP.When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Reserved             |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 9: Home Agent SwitchOver Request Message



Wakikawa (Editor)       Expires December 21, 2006              [Page 22]


Internet-Draft           Home Agent Reliability                June 2006


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

6.1.6.  Home Agent SwitchOver Reply Message

   This message is used to acknowledge the receipt of the corresponding
   Home Agent SwitchOver Request message.  The reply message should
   contain status_code field to convey the result of processing the
   received Home Agent SwitchOver Request message.

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


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Status               |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 10: Home Agent SwitchOver Reply Message

   Status

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

         0: success

         128: The receiver of the Home Agent SwitchOver Request message
         is not the Active Home Agent

         129: failed, Admin Prohibited.

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

6.1.7.  Home Agent SwitchBack Request Message

   This message is unicasted by an Active Home Agent that desires to
   become the inactive Home Agent for all the Mobile IPv6 sessions.  The
   receiver of this message SHOULD transit to active state as soon as
   the message is received and validated.

   The Home Agent SwitchBack Request message has the MH Type value TBD.
   The message MUST be authenticated and encrypted by IPsec ESP.  When



Wakikawa (Editor)       Expires December 21, 2006              [Page 23]


Internet-Draft           Home Agent Reliability                June 2006


   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Reserved             |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 11: Home Agent SwitchBack Request Message

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

6.1.8.  Home Agent SwitchBack Reply Message

   This message is used to acknowledge the receipt of the corresponding
   Home Agent SwitchBack Request message.  The message should contain
   status_code field to convey the result of processing Home Agent
   SwitchBack Request message.

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


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Status               |
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 12: Home Agent SwitchBack Reply Message

   Status

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

         0: success







Wakikawa (Editor)       Expires December 21, 2006              [Page 24]


Internet-Draft           Home Agent Reliability                June 2006


         128: The receiver of Home Agent SwitchBack Request is already
         the Active Home Agent

         129: failed, Admin Prohibited.

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

6.2.  New Mobility Options

6.2.1.  IP address Option

   This option is already defined at FMIP specification[9].  This
   document introduces new Sub-Type value for home agent address and
   Home Address.

   Option-Code

      *  4: Home Agent Address

      *  5: Home Address

6.2.2.  Binding Cache Information Option

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


























Wakikawa (Editor)       Expires December 21, 2006              [Page 25]


Internet-Draft           Home Agent Reliability                June 2006


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


   Figure 13: Binding Cache Information Option

   The binding cache information option is 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. 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 December 21, 2006              [Page 26]


Internet-Draft           Home Agent Reliability                June 2006


6.2.3.  AAA Information Option

   The AAA option is used to carry the AAA state of the Mobile Node's
   MIP6 sessions.  The AAA state information can be conveyed in RADIUS
   or Diameter AVP formats including the user and session info.  This
   information option is valid in a state synchronization message.


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


   Figure 14: Vendor Specific Inforamtion Option

   Type

      8-bit Type value.  The value is TBD.

   Length

      8-bit length value.

   AAA AVPs

      Series of TLV encoded AAA AVPs (including vendor specific AVPs)
      carrying AAA related information for each MIP6 and IPsec/IKE
      sessions.

   Reserved

      16-bit field reserved for future use.  The value SHOULD be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

6.2.4.  Vendor Specific Information Option

   The Vendor Specific information option is used to carry the vendor
   specific information of a home agent.  The Vendor Specific
   information option is valid in a state synchronization message.



Wakikawa (Editor)       Expires December 21, 2006              [Page 27]


Internet-Draft           Home Agent Reliability                June 2006


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  | Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Vendor Code          |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                 Vendor Specific Information                   .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 15: Vendor Specific Inforamtion Option

   Type

      8-bit Type value.  The value is TBD.

   Length

      8-bit length value.

   Vendor Code

      16-bit vendor code can be defined by each vendor.

   Reserved

      16-bit field reserved for future use.  The value SHOULD be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

















Wakikawa (Editor)       Expires December 21, 2006              [Page 28]


Internet-Draft           Home Agent Reliability                June 2006


7.  Home Agent Operation

7.1.  Home Agent Configuration

   There are two approaches to place Standby Home Agents.  The first
   configuration is that a Standby Home Agent is located at the same
   link (i.e. home link) of home agents.  Another one is that the
   Standby Home Agent is located at the different link from the home
   link.  The differences are whether home agent and Standby Home Agents
   share the link or not.


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


   Figure 16: Local Recovery Configuration

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


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


   Figure 17: Global Recovery Configuration

   Figure 17 illustrates when standby home agents are located on
   different link (named recovery link in the figure).  For example, HA3
   and HA4 are standby home agents of HA1 and HA2.  In this case, HA3
   and HA4 cannot receive the packets meant for the home network till
   the route on the Router is changed.  The advantage of this
   configuration is that Standby Home Agents can recover the failure of
   the home link.  If the home link becomes unreachable, the local
   recovery is useless.  However, this configuration can achieve the
   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.

   Each Standby Home Agent obtains its individual IP address from the
   link.  This IP address is used for home agent reliability protocol to



Wakikawa (Editor)       Expires December 21, 2006              [Page 29]


Internet-Draft           Home Agent Reliability                June 2006


   exchange information with the associated home agent.  The link
   between home agents should be secured.

   When Home Agent Virtual Switch is used, the home agent's IP address
   which is known by the mobile node can be shared with Standby Home
   Agents.  When a home agent fails, the standby home agent takes the IP
   address out of the failed home agent.  Then the Standby Home Agent
   can uses the IP address for further home agent operations as being an
   Active Home Agent.  The Standby Home Agent should not activate the IP
   address until the Active Home Agent is dead and the reachability to
   the IP address is lost.  Otherwise, address duplication will occurs.
   This operation is normally done using route selector such as BGP and
   OSPF modifier.  As an example we can use the AS_Path prepend
   operation for BGP and Metric field in the OSPF for route selection.
   The Ha reliability DT may define a new mobility option to carry
   respective BGP/OSPF modifier information.

   Alternatively, in Home Agent Hard Switch case, The home agent address
   may be different, but the home addresses and the home link prefix are
   the same.  In this case, all the reachability of mobile nodes will be
   lost during the recovery procedure, since the IP address of Failed
   Home Agent is no longer active and all the packets meant for the IP
   address will be discarded.  The Standby Home Agent must notify mobile
   nodes to change the associating home agent.  Thus, the mobile node
   will detect the home agent changes by knowing the new IP address of
   the standby home agent.  The home agent has to use the same technique
   as in virtual switch mode to advertise the routes into the routing
   infrastructure.

7.2.  Hello messages Manipulation

   Mobile IPv6 [1] defines a mechanism for maintaining a home agent list
   when there are multiple home agents present on a link.  It is based
   on each home agent sending a router advertisement periodically on the
   home link with a Home Address Information option [1].  However, this
   mechanism is governed by how a router sends a router advertisement as
   defined in [4].  There are restrictions on how often a router
   advertisement can be sent and on how they are processed by routers
   that receive them.  Moreover, the router advertisements are not sent
   frequently enough to rely on the absence of the router advertisement
   to detect a home agent failure.  Moreover, when home agents are
   placed at different links, Router Solicitation and Advertisement
   messages [4] can not be used due to link-local limitation.

   In this document, new Mobility Header messages are defined in
   Section 6.1.1 and Section 6.1.2 to notify similar information of
   Router Advertisement among home agents over the home link.




Wakikawa (Editor)       Expires December 21, 2006              [Page 30]


Internet-Draft           Home Agent Reliability                June 2006


7.2.1.  Sending Hello Request

   A home agent can solicit a Hello message by sending a Hello Request
   message.  The Hello Request message is unicasted to an Active Home
   Agent or a Standby Home Agent.  This message should be encrypted and
   authenticated by IPsec ESP mode.  An originator of the Hello Request
   message must specify the random sequence value.  The sequence value
   is used to match the Hello message which is sent from the receiver of
   the Hello Request message.

7.2.2.  Receiving Hello Request

   When a home agent receives a hello Request message, it SHOULD verify
   correct IPsec protection.  If the message is not protected, it SHOULD
   be silently discarded.  However, if the Hello messages can be sent on
   a dedicated link between the home agents and in such a case, IPsec
   protection is not required.

   If the sender home agent is not in the same redundant home agent set,
   the message MUST be silently ignored, too.

   The sequence field should be copied to the Hello message which will
   be sent in reply to the hello Request message.  This sequence number
   is used as a transaction ID for the Hello message exchange.

7.2.3.  Sending Hello

   A home agent Hello message MUST be constructed with same information
   of a Router Advertisement message described in section 7 of [1].  The
   Hello messages can be unicasted or multicasted.  A new multicast
   address will be assigned by the IANA.  All the home agents on the
   home link should join this multicast address.  When the Hello
   messages are used for maintaining the home agents list, the home
   agent SHOULD NOT use the home agent Information option in the router
   advertisements to manage the home agents list.

   The Hello message MUST be sent when a home agent is requested by a
   hello Request message.  The Hello message can be also periodically
   sent.  In addition, the home agent SHOULD send a home agent Hello
   message to home agents of the redundant home agent set when it boots
   up and its local information such as preference, lifetime, and
   registration status, etc. change.  The interval between two Hello
   messages is configurable on the home agents.  When a new home agent
   boots up, it SHOULD wait a particular time to listen home agent Hello
   messages of all configured Home Agents.  Alternatively, it can
   solicit Hello message by sending a Hello Request message.

   If a home agent is the Active Home Agent, it MUST set A flag in Hello



Wakikawa (Editor)       Expires December 21, 2006              [Page 31]


Internet-Draft           Home Agent Reliability                June 2006


   Messages.

7.2.4.  Receiving Hello

   The receiver of a Home Agent Hello message MUST verify the source
   address field of the IPv6 header.  If a Home Agent Hello message is
   received from unknown home agent, the message MUST be silently
   dropped.  If the source address is not in the list of known home
   agents, the message MUST be silently dropped.  In addition to this
   source address check, Group ID is introduced in this document.  This
   Group ID is used to identify a particular redundant home agent set.
   If the Group ID field is specified in a Hello message, the receiver
   MUST process only the Hello which group ID is matched.  This Group ID
   is verified when the Hello message is multicasted.  The Hello message
   MUST NOT be sent to a home agent whose Group ID is different from the
   sender.  If the Group ID is set to zero, the receiver MUST ignore
   this field.

   Any Home Agent Hello message satisfying all of these tests MUST be
   processed to update its home agent list.  The Home Agents list can be
   ordered based on the home agent preference value.  If the home agent
   lifetime field in the Hello message is set to 0, the receiver removes
   the sender home agent that from the home agents list.

7.3.  Failure Detection

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

   The most common way to detect failure is using periodic message
   exchange such as Hello of routing protocols.  This mechanism is often
   used to detect failure on many protocols.  In the real scenario, when
   a home agent crashed, it can happened that only home agent
   functionality is down and network reachability to home agent is
   alive.  In this case, ICMP type of message such as ping can not be
   used to detect the home agent failure.  Therefore, we define a new
   Hello message to detect the home agent failure.

   The Active and the Standby Home Agents exchange periodic Hello
   messages to monitor one another's status.  Hello request message may
   be used by any Home Agent to explicitly request state information
   from any other Home Agent in the redundant Home Agent set.  If a Home
   Agent 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.




Wakikawa (Editor)       Expires December 21, 2006              [Page 32]


Internet-Draft           Home Agent Reliability                June 2006


   Example Failure Events:

   Loss of Communication with the Active Peer Home Agent

      The redundant Home Agent set should have knowledge of each others
      state.  In order to achieve that, we define Hello message
      exchanges.  In the event that the Home Agent that is currently
      inactive does not receive any Hello message from its peer which is
      currently active for a configurable duration, the Home Agent may
      decide to become active.

   Monitored Server Failure by the Active Home Agent

      There may be number of critical servers in the network that are
      essential for the ongoing Mobile IPv6 session 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
      SwitchOver procedure upon detecting that the link to such a server
      has failed.

   Routing Peer/Link Failure

      In some cases, the operator may like 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 SwitchOver
      if the failure is fatal in nature or due to some other routing
      policies.

7.4.  Active Home Agent Change

   There are two cases when a Standby Home Agent takes over an Active
   Home Agent.  The first case is when a Standby Home Agent detects
   failure of the Active Home Agent described in Section 7.3.  The
   Standby Home Agent immediately becomes an Active Home Agent.  The
   second case is when a home agent receives a Home Agent SwitchOver
   Request message described in Section 7.6.

   Upon detecting failure of an Active Home Agent, the Standby Home
   Agent becomes Active.  If there are more than one Standby Home Agent
   or when there are two Home Agents in the redundant Home Agent set,
   but both of them boots up at the same time, two values are used to
   break any tie.  The Home Agent with lowest BGP/OSPF modifier value
   becomes Active.  If the BGP/OSPF modifiers are the same, then the
   home agent preference values (configured by the system administrator)
   is used to break the tie.

   When the Standby Home Agent becomes active, it MUST start to



Wakikawa (Editor)       Expires December 21, 2006              [Page 33]


Internet-Draft           Home Agent Reliability                June 2006


   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 is operated by using route selector such as BGP
   and OSPF modifier.  In addition, if necessary, the new active home
   agent must overwrite the neighbor entries of the mobile nodes in
   order to intercept packets of the mobile nodes.

7.5.  Processing State Synchronization Messages

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

7.5.1.  Sending State Synchronization Request

   When a Standby Home Agent wants state for a particular Mobile Node
   such as Binding Cache, AAA, etc, it can solicit State Synchronization
   message by sending State Synchronization Request.  This is optional
   operation of a standby home agent.  The Standby Home Agent MUST set a
   random value to the Identifier field in the state synchronization
   Request message and MUST include either a Home Address mobility
   option or a Mobile Network Prefix mobility option.  The Standby Home
   Agent can store multiple home address mobility options or mobile
   network prefix mobility options to request state information for
   multiple mobile nodes by a single state synchronization Request
   message.

7.5.2.  Receiving State Synchronization Request

   If the received state synchronization Request message is not
   protected by IPsec ESP, the message must be silently discarded.  If
   the sender home agent is not belong to the same redundant home agent
   set, the message must be silently ignored.  Moreover, if a receiver
   is not the Active Home Agent for the requested home address or mobile
   network prefix, it MUST silently discard the message.  Otherwise, the
   receiver MUST reply with a State Synchronization message including
   state information for the requested mobile node(s).

7.5.3.  Sending State Synchronization

   A state synchronization message can be sent either:





Wakikawa (Editor)       Expires December 21, 2006              [Page 34]


Internet-Draft           Home Agent Reliability                June 2006


   o  when an Active Home Agent receives a state synchronization Request
      message

   o  when an Active Home Agent creates/updates binding cache for a
      particular Mobile Node.

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

   If an Active Home Agent sends the state synchronization message
   whenever the local state information such as binding cache changed,
   the size of the state synchronization message are large.  The Active
   Home Agent should update the state information with an interval which
   is configured by system administrator.

   The binding cache of the requested Mobile Node are stored in the
   state synchronization message.  The Active Home Agent MUST copy the
   binding cache of the requested Mobile Node to each fields of a
   binding cache information option.  If the state synchronization
   message is sent in response to the state synchronization Request
   message, the Active Home Agent MUST copy the Identifier field of the
   state synchronization Request message to the same filed in the state
   synchronization message.  Otherwise, it MUST set zero to the
   Identifier field.

   The Active Home Agent can store state of multiple mobile nodes in a
   state synchronization message

7.5.4.  Receiving State Synchronization

   A state synchronization message MUST be authenticated and encrypted
   by IPsec ESP mode.  If not, 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 do
   not belong to any home agents of the redundant home agent set, the
   message MUST be silently discarded.  The receiver home agent SHOULD
   record the state and the Active Home Agent address into its Binding
   Cache.

7.6.  Processing Home Agent SwitchOver Messages

7.6.1.  Sending Home Agent SwitchOver Request

   When a Standby Home Agent decides to become an active home agent, it
   MAY send a home agent SwitchOver Request message to an Active Home
   Agent.  The reason for the Standby Home Agent to send this message is
   administrative intervention.  The Standby Home Agent sends with a
   mobility header which type is set to the home agent SwitchOver



Wakikawa (Editor)       Expires December 21, 2006              [Page 35]


Internet-Draft           Home Agent Reliability                June 2006


   Request type.  This message must be encrypted and authenticated by
   IPsec ESP.  The Active Home Agent MUST NOT generate this message.

7.6.2.  Sending Home Agent SwitchOver Reply

   A home agent SwitchOver reply is sent in reply to a home agent
   SwitchOver Request message.  When a home agent receives a home agent
   SwitchOver Request message, it first verifies the message.  If the
   request message is not protected by IPsec, it MUST be silently
   discarded.  In addition, if the sender home agent is not belong to
   the same redundant home agent set, the message MUST be silently
   discarded.

   If a receiver home agent is not an Active Home Agent, it replies a
   home agent SwitchOver reply which status field set to 128.
   Otherwise, the receiver home agent MUST become a Standby Home Agent
   and replies a home agent SwitchOver reply which status field set to
   zero.

7.6.3.  Receiving Home Agent SwitchOver Reply

   If a home agent receives a home agent SwitchOver reply, the message
   MUST be protected by IPsec.  Otherwise, the message MUST be silently
   discarded.  If a receiver home agent did not send a home agent
   SwitchOver Request beforehand, the message MUST be silently
   discarded.

   If the status field of the SwitchOver reply message indicates zero,
   the receiver Standby Home Agent immediately becomes an Active Home
   Agent.  If the status value is greater than 128, an error is
   occurred.  Thus, the receiver cannot be an active home agent.

7.7.  Processing Home Agent SwitchBack Messages

7.7.1.  Sending Home Agent SwitchBack Request

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






Wakikawa (Editor)       Expires December 21, 2006              [Page 36]


Internet-Draft           Home Agent Reliability                June 2006


7.7.2.  Sending Home Agent SwitchBack Reply

   A home agent SwitchBack reply is sent in reply to a home agent
   SwitchBack Request message.  When a home agent receives a home agent
   SwitchBack Request message, it first verifies the message.  If the
   request message is not protected by IPsec, it MUST be silently
   discarded.  In addition, if the sender home agent is not belong to
   the same redundant home agent set, the message MUST be silently
   discarded.  If the sender home agent of SwitchBack Request message is
   not an Active Home Agent, the message MUST be silently discarded.

   If a receiver home agent of SwitchBack Request message is already an
   Active Home Agent, it replies home agent SwitchBack reply which
   status field set to 128.  Otherwise, the receiver home agent MUST
   become an Active Home Agent and replies a home agent SwitchBack reply
   which status field set to zero.

7.7.3.  Receiving Home Agent SwitchBack Reply

   If a home agent receives a home agent SwitchBack reply, the message
   MUST be protected by IPsec.  Otherwise, the message MUST be silently
   discarded.  If a receiver home agent did not send a home agent
   SwitchBack Request message beforehand, the message MUST be silently
   discarded, too.

   If the status field of the SwitchBack reply message indicates zero,
   the receiver home agent immediately becomes an in-Active Home Agent.
   If the status value is greater than 128, some error is occurred.
   Thus, the receiver cannot be an in-active home agent and MUST
   continue to be an Active Home Agent.

7.8.  Sending Home Agent Switch Message

   If an Active Home Agent fails, another Standby Home Agent on the home
   link can take over the Failed Home Agent in the Home Agent Hard
   Switch mode.  This operation is valid only for the Home Agent Hard
   Switch mode.  The Standby Home Agent MUST send a home agent Switch
   message defined in [8] to all the mobile nodes that were being served
   by the Failed Home Agent.  The message must be encrypted with pre-
   established SA.  The standby home agent should include its own IP
   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 are a large number of mobile
   nodes, sending Home Agent Switch messages will cause a lot of
   signaling overhead on the network.





Wakikawa (Editor)       Expires December 21, 2006              [Page 37]


Internet-Draft           Home Agent Reliability                June 2006


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 the operations can be skipped.

8.1.  Standby Home Agent Addresses Discovery

   To provide home agent reliability, one possible solution is that the
   Mobile Node authenticate itself to two home agents and creates IPsec
   SA with two home agents in bootstrapping.  When one home agent fails
   the other home agent could use pre-existing SA to notify the Mobile
   Node about the failure.

   In the Home Agent Hard Switch mode, multiple home agent addresses are
   valid in the home network.  In order to discover the home agent
   address, two different mechanisms are defined in the bootstrapping
   solution in split scenario [10].  One is DNS lookup by home agent
   Name, the other is DNS lookup by Service Name.  Also in integrated
   scenario [11], DHCPv6 is used to provide home agent provision to
   Mobile Node.

   In the split scenario, Mobile Node can use DNS lookup by Service Name
   to discover the home agents, as defined in [10].  For example, If
   home agent reliability is required by the Mobile Node, DNS lookup by
   Service Name method is recommended for Mobile to discovery multiple
   home agents addresses.  Therefore Mobile Node will query the DNS SRV
   records with service name of mip6 and protocol name of ipv6. the DNS
   SRV records includes multiple home agents addresses and different
   preference value and weight.  The mobile node SHOULD choose two home
   agents from the Home Agents list according to there preference value.
   Then the Mobile Node should authenticate itself to both home agents
   via IKEv2 exchange.

   In the integrated scenario, Mobile Node can use DHCPv6 to get home
   agents provision from MSP or ASP, as already defined in [11].  The
   only requirement is that the DHCPv6 response must include multiple
   home agent information in order to support home agent reliability.

8.2.  IKE/IPsec pre-establishment to Home Agents

   After Mobile Node get multiple Home Agent addresses, it need to
   trigger multiple IKE exchange with multiple home agents selected from
   the Home Agent list.  Since both IKEv1 and IKEv2 can be used to
   bootstrap Mobile IPv6, this solution does not introduce any new
   operations to co-operate with IKEv1 or IKEv2.  It should initiate IKE
   for home agents as soon as home registration is completed.




Wakikawa (Editor)       Expires December 21, 2006              [Page 38]


Internet-Draft           Home Agent Reliability                June 2006


   The Mobile Node MUST follow standard IKEv2 exchange in bootstrapping
   solution of split scenario [10], or IKEv1 bootstrap solution [12]. if
   needed by Mobile Node, Home Address configuration maybe included for
   the first IKE exchange.  After its Home Address is assigned or
   approved by the first home agent, Mobile Node SHOULD register itself
   to the second home agent by IKE using the same Home Address.
   Therefore, no HoA configuration should be used in the second IKEv2
   procedure.  Note that the Mobile Node sends Binding Update Message to
   the first home agent.

8.3.  Receiving Home Agent Switch message

   A mobile node must follow the operation specified in [8] when it
   receives home agent switch message.

   When the mobile node receives a Home Agent Switch message, and if the
   message contains the IP address of standby home agent, it picks the
   Standby Home Agent in the request message as the Active Home Agent
   and sends a Binding Update message to it.  The mobile node have
   already pre-established SA with the home agent and use the SA to send
   Binding Update.  However, in this specification, the binding cache
   information is already synchronized among the redundant home agent
   set, the mobile node can skip this binding re-registration to the new
   active home agent.  In this case, the mobile node only updates the
   Home Agent address of all the binding update list, MIP6 tunnel end
   points, etc.

























Wakikawa (Editor)       Expires December 21, 2006              [Page 39]


Internet-Draft           Home Agent Reliability                June 2006


9.  Security Considerations

   Mobile IPv6 depends on IPsec and IKE for binding home registration
   described in [5].  A mobile node must encrypt a binding update sent
   to a home agent.  In addition, the mobile node exchanges HoTI and HoT
   messages through a home agent by using IPsec tunnel mode.  Therefore,
   before a home agent failure, these IPsec states (below is example)
   should be synchronized among home agents of a redundant home agent
   set.

   mobile node may encrypt particular data traffic sent to the Internet.

   o  Security Policy Database (SPD) and Selector Information

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

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

   o  SA for Mobile Prefix Discovery (SA5 and SA6)

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

   The Home Agent reliability scheme for Mobile IPv6 involves IPsec
   tunnel SwitchOver upon Home Agent failure.  There are various ways
   this can be achieved e.g. setting up of multiple IPsec security
   associations between the Mobile Node and the Home Agent sets.
   Another way could be, the Home Agents periodically check pointing
   IPsec session state including the per packet sequence numbers for the
   Mobile Node.  We can call these two possible Home Agent redundancy
   modes as follows:

   1.  Home Agent Hard Switch.  In this mode, the Mobile Node and the
       redundant Home Agent set negotiates independent IPsec SAs.

   2.  Home Agent Virtual Switch.  In this mode, the Mobile Node
       negotiates just one SA for both the redundant Home Agent set.

   In both the cases, the mobile node maintains only one binding cache
   at any given time.  In the Home Agent Hard Switch case, the mobile
   node needs to switch binding from active to Standby Home Agent upon
   failover.  IPsec redundancy need synchronize both SPD, Selector and
   SAD information from one home agent to another home agent.

   Since Mobile IPv6 operation requires ESP in transport mode between
   the Mobile Node and the Home Agent, we will talk about the ESP field
   synchronization issues between the Mobile Node and the redundant set
   of Home Agents.  Most of fields should be synchronized based on
   RFC4301[6].  The ESP header has the following fields:



Wakikawa (Editor)       Expires December 21, 2006              [Page 40]


Internet-Draft           Home Agent Reliability                June 2006


   SPI

      This field identifies the SAD at the receiver.

      Home Agent Hard Switch Mode

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

      Home Agent Virtual Switch Mode

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

   Sequence Number

      This field is used for "anti-replay" feature of ESP.  The
      transmitter must include this monotonically increasing number.
      The receiver may process the sequence number based on local
      policy.

      Home Agent Hard Switch Mode

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

      Home Agent Virtual Swtich Mode

         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.

      For MIP6 signaling i.e.  BU/BA, HoTi/HoT etc. the SA1, SA2, SA3,
      SA4 could be synchronized between the Home Agents as these
      messages are not sent continuously.  Moreover for the BU Case, if
      the Mobile Node is in the middle of sending a BU to the Home Agent
      (Active Home Agent) for binding refresh, and the Home Agent is
      crashing at that moment.  The Mobile Node will not get any
      response from the Home Agent.  The Mobile Node will retry.  After
      the Standby Home Agent becomes active, it will receive BU from the
      Mobile Node with a sequence number that is +n from its last known



Wakikawa (Editor)       Expires December 21, 2006              [Page 41]


Internet-Draft           Home Agent Reliability                June 2006


      sequence number for SA1.  For the BA 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
      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 MIP6 signaling is only needed to cover the
      corner cases when BU/HoTi is in air and the Active Home Agent
      fails.

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

   Initialization Vector

      Since each time, IV will be delivered between Mobile Node and Home
      Agent, so this field is not necessarily synchronized between home
      agents.

   Others

      Other fields should be synchronized based on RFC4301[6]

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





















Wakikawa (Editor)       Expires December 21, 2006              [Page 42]


Internet-Draft           Home Agent Reliability                June 2006


10.  Contributors

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

   Samita Chakrabarti

      samita.chakrabarti@sun.com

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Hui Deng

      hdeng@hitachi.cn

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sri Gundavelli

      gundave@cisco.com

   Brian Haley

      brian.haley@hp.com

   Behcet Sarikaya

      bsarikaya@huawei.com

   Ryuji Wakikawa

      ryuji@sfc.wide.ad.jp


11.  Acknowledgements

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





Wakikawa (Editor)       Expires December 21, 2006              [Page 43]


Internet-Draft           Home Agent Reliability                June 2006


12.  References

12.1.  Normative References

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

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

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

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

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

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

12.2.  Informative References

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

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

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

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

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

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



Wakikawa (Editor)       Expires December 21, 2006              [Page 44]


Internet-Draft           Home Agent Reliability                June 2006


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

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

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








































Wakikawa (Editor)       Expires December 21, 2006              [Page 45]


Internet-Draft           Home Agent Reliability                June 2006


Author's Address

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

   Email: ryuji@sfc.wide.ad.jp










































Wakikawa (Editor)       Expires December 21, 2006              [Page 46]


Internet-Draft           Home Agent Reliability                June 2006


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Wakikawa (Editor)       Expires December 21, 2006              [Page 47]