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

Versions: 00 01

MIP6/NEMO Working Group                                   Ryuji Wakikawa
INTERNET DRAFT                                      Keio University/WIDE
Category:  Standards Track                             Vijay Devarapalli
16 Feb 2004                                                        Nokia
                                                          Pascal Thubert
                                                           Cisco Systems

                    Inter Home Agents Protocol (HAHA)
                  draft-wakikawa-mip6-nemo-haha-01.txt


   Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


   Abstract

   This document describes an inter Home Agents (HAHA) protocol to
   provide multiple Home Agents support for both Mobile IPv6 and the
   Nemo Basic Support protocol.  The HAHA protocol provides Home Agent
   redundancy and load-balancing for both protocols.  The HAHA protocol
   allows multiple Home Agents to be placed at different links.  It also
   allows a Mobile Node to utilize multiple Home Agents simultaneously.
   The protocol consists of 3 mechanisms, Home Agent List management,
   Binding Synchronization, and Home Agent Switching.  A Mobile Node
   picks one Home Agent as its primary Home Agent and registers with it.
   The primary Home Agent synchronizes the binding cache information
   with other Home Agents.  Any of Home Agents can intercept a packet
   meant for the Mobile Node and tunnel the packet directly to its
   current Care-of address.  Alternatively, the Home Agent can tunnel
   the packet to the primary Home Agent.


Wakikawa, et al.               Expires 16 Aug 2004              [Page 1]


Internet Draft                 HAHA protocol                 16 Feb 2004


                                  Contents


Status of This Memo                                                    1

Abstract                                                               1

 1. Introduction                                                       4

 2. Terminology                                                        6

 3. Overview of Inter Home Agents Protocol                             7

 4. Message Formats                                                   10
     4.1. New Mobility Header Messages  . . . . . . . . . . . . . .   10
           4.1.1. Home Agent HELLO Message  . . . . . . . . . . . .   10
           4.1.2. Binding Information Request Message . . . . . . .   11
           4.1.3. Binding Information Update Message  . . . . . . .   13
           4.1.4. Binding Information Acknowledgment Message  . . .   13
           4.1.5. Home Agent Switch Request Message . . . . . . . .   14
     4.2. New Mobility Options  . . . . . . . . . . . . . . . . . .   15
           4.2.1. Home Address  . . . . . . . . . . . . . . . . . .   15
           4.2.2. Mobile Network Prefix Option  . . . . . . . . . .   15
           4.2.3. Binding Cache Entry Information Option  . . . . .   16

 5. Home Agent Lists Management                                       17

 6. Home Agent Failure Detection                                      18

 7. Binding Synchronization among Home Agents                         19
     7.1. Requesting Binding  . . . . . . . . . . . . . . . . . . .   19
     7.2. Notifying Binding . . . . . . . . . . . . . . . . . . . .   19

 8. Primary Home Agent Switching                                      21
     8.1. Home Agent initiated Switching  . . . . . . . . . . . . .   21
     8.2. Mobile Node initiated Switching . . . . . . . . . . . . .   21

 9. Scenarios                                                         23
     9.1. Single Home Agent Activation  . . . . . . . . . . . . . .   23
     9.2. Multiple Home Agent Activation  . . . . . . . . . . . . .   24

10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol  27

11. IANA Considerations                                               29

12. Security Considerations                                           30

 A. Changes from -00                                                  32


Wakikawa, et al.               Expires 16 Aug 2004              [Page 2]


Internet Draft                 HAHA protocol                 16 Feb 2004


 B. Distributed Home Network                                          33

Addresses                                                             38


Wakikawa, et al.               Expires 16 Aug 2004              [Page 3]


Internet Draft                 HAHA protocol                 16 Feb 2004


   1. Introduction

   In Mobile IPv6 [2], a Mobile Host could be tunneling and receiving
   all its traffic through a bi-directional tunnel with its Home Agent,
   unless it uses Route Optimization with its Correspondent Nodes.  In
   Nemo Basic Support protocol [7], the default mode of operation is
   to tunnel all traffic meant for the Mobile Network through the Home
   Agent serving the Mobile Router.  Consequently, Home Agents could
   become a considerable bottleneck in the performance of Mobile IPv6
   and Nemo protocols.  This becomes more significant when the Home
   Agent serves thousands of Mobile Hosts and Mobile Routers.  Sometimes
   the Mobile Network could be closer to the Correspondent Node than
   the Home Agent.  If the Mobile Router could pick another Home Agent
   closer to its current location, the tunneling overhead on every
   packet could be reduced to a much shorter path in the Internet.

   This draft specifies the inter Home Agents protocol (HAHA protocol)
   to provide reliability, redundancy and load balancing of Home Agents.
   Problem statements of Home Agent Reliability is summarized in  [1].

   For the HAHA protocol, the definition of Home Agent is extended to
   place multiple Home Agents at different links.  Multiple Home Agents
   could be located on different links and still serve the same home
   prefix.  Mobile IPv6 uses a IPv6 Neighbor Discovery based mechanism
   for maintaining the list of Home Agents serving the same prefix, at
   each Home Agent.  If the Home Agents are not present on the same
   physical link, Neighbor Discovery based mechanisms don't work.  The
   HAHA protocol defines a mechanism for Home Agents List management
   using new MH messages for Home Agents located on different links.
   Network configurations such as Home Network Prefix Assignments and
   route distributions among Home Agents are described in [8].  In
   appendix B, a distributed home network scenarios are described.

   The HAHA protocol makes it possible to have two new scenarios which
   would not have possible with Mobile IPv6 and the Nemo Basic Support
   Protocol.  These scenarios are Single Home Agent Activation and
   Multiple Home Agent Activation and are explained in the following
   paragraphs.

   In the scenario of Single Home Agent Activation, a Mobile Node always
   selects the best Home Agent to register its binding depending on
   Mobile Node's current location or Home Agent status.  The Mobile
   Node's binding is always maintained by the single Home Agent.  For
   example, when a Mobile Node registers its binding to the nearest Home
   Agent, the path between the Mobile Node and the Home Agent can be the
   shortest possible path.  This is particularly useful for a Mobile
   Node which moves over geographically wide areas such as a Mobile
   Router on an airplane.


Wakikawa, et al.               Expires 16 Aug 2004              [Page 4]


Internet Draft                 HAHA protocol                 16 Feb 2004


   In the scenario of Multiple Home Agent Activation, a Mobile Nodes
   registers its binding to multiple Home Agents at the same time.
   The Mobile Node sends a binding update to its primary home agent.
   After the home registration, the primary Home Agent exchanges the
   binding information with the other Home Agents.  The Mobile Node's
   binding is maintained by multiple Home Agent.  Thereafter, the Mobile
   Node can use any of these Home Agents which have the binding.  The
   Mobile Node can accept packets which are tunneled by any of the Home
   Agents.  Alternatively, a Home Agent who intercepts packets can
   tunnel packets to the primary Home Agent.  In this case, the Mobile
   Node receives packets through the primary Home Agent.  If many Home
   Agents are scattered on the Internet, the Home Agent nearest to the
   correspondent node intercepts packets meant for the Mobile Node or
   the Mobile Network and tunnels them to the Mobile Node.  The route
   path between the correspondent node and the Home Agent can be kept
   short.


Wakikawa, et al.               Expires 16 Aug 2004              [Page 5]


Internet Draft                 HAHA protocol                 16 Feb 2004


   2. Terminology

   There is a separate Nemo terminology document [3], which defines the
   terms related to Network Mobility used in the document.

   The keywords ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
   NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and
   ``OPTIONAL'' in this document are to be interpreted as described in
   RFC 2119.

      Home Agent

              A Home Agent is originally defined in [2].  Traditional
              Home Agents, if they all serve the same home prefix are
              configured on a single link.  This document extends the
              definition of Home Agents such that the Home Agents need
              not be on the same link.  There could be multiple Home
              Agents attached to different links serving the same home
              prefix.

      Primary Home Agent

              A Home Agent who receives Binding Update from a Mobile
              Router.  The Mobile Router is always associated with a
              primary Home Agent to register its binding.

      Mobile Node, Mobile Host, and Mobile Router

              In this document,three terms are used to express mobile
              entities as defined at  [10].  A Mobile Host is an end
              host capable of Mobile IPv6.  A Mobile Router is a router
              of a mobile network supporting the Basic NEMO protocol.  A
              Mobile Node is entity moving on the Internet.  A Mobile
              Node implies either a Mobile Host, Mobile Router, or both.


Wakikawa, et al.               Expires 16 Aug 2004              [Page 6]


Internet Draft                 HAHA protocol                 16 Feb 2004


   3. Overview of Inter Home Agents Protocol

   The HAHA protocol addresses the issues of home agent reliability
   described in [1].  The HAHA protocol prevents Home Agent failure and
   Home Link failure from Mobile IPv6.  It provides mechanism of failure
   detection and its recovery by binding synchronization.


     Local HAs Distribtuion     Global Home Distribution

                                 Home Link1
                                ----+----
       +--------+                   |
       |Internet|               +--------+   |
       +--------+               |Internet|---+ Home Link2
           |                    +--------+   |
     --+---+---+--Home Link         |
       |   |   |                ----+------
      HA  HA  HA                Home Link3


               The Combination

               Home Link1
               HA  HA  HA
               |   |   |
               +---+---+
                   |        +- HA
              +--------+    |
              |Internet|----+- HA  Home Link2
              +--------+    |
                   |        +- HA
              +----+----+
              |    |    | Home Link3
              HA   HA   HA

   Local Home Agent distribution is the configuration when multiple
   home agents are placed locally in same routing domain.  Multiple
   home agents are configured at the same home link for a particular
   mobile nodes.  When one of home agents goes down, another home agent
   takes over the inactive home agent and serves same mobile nodes
   continuously.  It is possible to balance load locally among home
   agents.  Local multiplexing is effective for load balancing and home
   agent redundancy.

   Global Home Agent distribution is used to avoid home link failure.
   Multiple home agents are placed globally despite routing domains.
   Multiple home agents serving a same home network are distributed


Wakikawa, et al.               Expires 16 Aug 2004              [Page 7]


Internet Draft                 HAHA protocol                 16 Feb 2004


   to different routing domains.  Therefore, the routes for the home
   network are advertised from multiple routing domains.  Each mobile
   node can pick the best home agent among distributed home agents
   according to network environments and topological position.

   When multiple Home Agents are configured at different links, each
   Home Agent is expected to know the other Home Agents beforehand and
   establishes Security Association with them for a secure path towards
   the other Home Agents.

   Each Home Agent maintains a list of all other Home Agents that serve
   the same Home Network.  The Mobile IPv6 mechanism of using router
   advertisements for maintaining the Home Agent list cannot be used
   if the Home Agents are placed on geographically different links,
   because router advertisements can not be sent over link-local scope.
   Therefore, each Home Agents periodically unicasts a Home Agent HELLO
   message instead of Router Advertisement to the other Home Agents
   configured at different links.  Whenever a Home Agent receives a Home
   Agent HELLO message, it updates its Home Agent List according to the
   information in the received HELLO message.  The Home Agent manages
   the Home Agent List as same as the Mobile IPv6 specification.  If
   the lifetime of an entry is expired in the Home Agent List, the Home
   Agent should delete the the entry from the Home Agent List and MAY
   assume the Home Agent which entry is deleted becomes unreachable
   (i.e.  system down).

   Synchronizing Binding of a particular Mobile Node allow to activate
   multiple Home Agents simultaneously.  When a primary Home Agent
   receives a Binding Update and creates a Binding, it notifies the
   Binding to the other Home Agents by unicasting Binding Information
   Update messages.  Home Agents receiving the Binding Information
   Update message records Binding information and the address of the
   primary Home Agent into their Binding Cache.  Home Agents MUST
   return Binding Information Acknowledgment messages with appropriate
   status code to the sender Home Agent.  A Home Agent sends a Binding
   Information Request message to solicit a Binding Information Update
   message to the primary Home Agent if needed.

   When a Home Agent wants a Mobile Node to change the primary Home
   Agent, it sends a Home Agent Switch Request message to trigger
   the Dynamic Home Agent Address Discovery to a Mobile Node.  After
   receiving an ICMP Home Agent Address Discovery Request, the Home
   Agent should reply an ICMP Home Agent Address Discovery Reply with
   addresses of appropriate Home Agent addresses.  If the Home Agent
   has already had the desired new primary Home Agent, it contains
   the address of the new Home Agent in the Home Agent Switch Request
   message.  The Mobile Node switches its primary Home Agent to the new
   Home Agent.  When the Mobile Node changes the primary Home Agent
   proactively, it selects a new Home Agent from its home agent list.


Wakikawa, et al.               Expires 16 Aug 2004              [Page 8]


Internet Draft                 HAHA protocol                 16 Feb 2004


   After determination of the new Home Agent, it simply registers its
   binding to the new Home Agent.  The Mobile Node should de-register
   its binding from the old Home Agent before the home registration to
   the new Home Agent.

   The scenarios for the HAHA protocol are described in Section 9.  In
   the Single Home Agent Activation scenario, only a primary Home Agent
   manages a binding for a Mobile Node and takes responsibility for
   tunneling packets from and to a Mobile Node.  The Mobile Node can
   switch its primary Home Agent to a Home Agent located in different
   link by the HAHA protocol.

   In the Multiple Home Agents Activation scenario, a primary Home Agent
   shares the registered binding for a Mobile Node with all other Home
   Agents.  Each Home Agent intercepts packets and take responsibility
   for delivering intercepted packets to either the Mobile Node or
   the primary Home Agent.  The Mobile Node accepts tunneled packets
   directly from the Home Agent.  Otherwise, when the primary Home Agent
   receives tunneled packets from other Home Agents, it delivers packets
   to the Mobile Node.  The Mobile Node always tunnels outgoing packets
   to the primary Home Agent.  The Mobile Node can switch its primary
   Home Agent to a Home Agent located in different link by the HAHA
   protocol.


Wakikawa, et al.               Expires 16 Aug 2004              [Page 9]


Internet Draft                 HAHA protocol                 16 Feb 2004


   4. Message Formats

   4.1. New Mobility Header Messages

   The Mobility Header format is defined in section 6 of [2].  This
   document defines five new mobility messages.


   4.1.1. Home Agent HELLO Message

   The Home Agent HELLO message is pulsed to other Home Agents in order
   to inform activeness of the sender home agent.  The format of the
   Home Agent HELLO message 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           |    Reserved   |  Prefix length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                                                               |
       |                      Home Agent Address                       |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      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.  This value does not need to be recorded in
         Home Agent List.

      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.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 10]


Internet Draft                 HAHA protocol                 16 Feb 2004


      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.

      Reserved

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

      Prefix Length

         8-bit unsigned integer.  The prefix length of the home prefix
         that HA is serving.  The home prefix is retrieved from the
         Prefix Length field and following Home Agent Address field.

      Home Agent Address

         A 16 byte field contains an IPv6 global address of the home
         agent sending this hello.

   This message MUST include the Mobile Network Prefix Option defined in
   section 4.2.2 that is served by the Home Agent if available.

   Home Agent HELLO message MUST be authenticated and encrypted by IPsec
   ESP.


   4.1.2. Binding Information Request Message

   The Binding Information Request Message is used to request Binding
   Cache Information corresponding to a particular Mobile Node.  It is


Wakikawa, et al.              Expires 16 Aug 2004              [Page 11]


Internet Draft                 HAHA protocol                 16 Feb 2004


   sent only between Home Agents.  The format of the Binding Information
   Request message 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                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Identifier

         The 16-bit identifier to aid in matching Home Agent Information
         Update message.  The identifier should never be set to 0.  It
         should always be more than 1.

   This message MUST include either the Home Address mobility option
   defined in section 4.2.1 or the Mobile Network Prefix Option
   defined in section 4.2.2.  If a Home Agents want the Binding Cache
   Information for a particular Mobile Node it includes a Home Address
   mobility option.  If a Home Agent wants to know the forwarding state
   setting up for a particular Mobile Network Prefix, it includes the
   Mobile Network Prefix Option.

   This message is optional if Home Agents send out unsolicited Binding
   Information Update messages.

   Binding Information Request message MUST be authenticated and
   encrypted by IPsec ESP.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 12]


Internet Draft                 HAHA protocol                 16 Feb 2004


   4.1.3. Binding Information Update Message

   The Binding Information Update message is used by the Home Agents
   to exchange Binding Cache Information.  The message format is as
   follows:

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

      Identifier

         The 16-bit identifier to aid in matching Home Agent Information
         Request and Home Agent Information Acknowledge message.  The
         identifier should never be set to 0.  It should always be
         more than 1.  The identifier should be set random number for
         unsolicited Binding Information Update messages.  Otherwise,
         the identifier should be set to the identifier in a Binding
         Information Request message if this is a solicited Binding
         Information Update message.

   This message MUST include Binding Cache Entry Information option.

   Binding Information Update message MUST be authenticated and
   encrypted by IPsec ESP.


   4.1.4. Binding Information Acknowledgment Message

   The Binding Information Acknowledgment message is used by the Home
   Agents to confirm recipient of a Binding Information Update message.
   The message format is as follows:

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


Wakikawa, et al.              Expires 16 Aug 2004              [Page 13]


Internet Draft                 HAHA protocol                 16 Feb 2004


      Identifier

         The 16-bit identifier should be copied from the identifier
         field of the received Home Agent Information Update message.

      Status

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

            0       Binding is successfully synchronized

      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.

   Binding Information Acknowledgment message MUST be authenticated and
   encrypted by IPsec ESP.


   4.1.5. Home Agent Switch Request Message

   This message is sent by a Home Agent to a Mobile Node to trigger
   Dynamic Home Agent Discovery.  The message format is as follows:

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

      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, et al.              Expires 16 Aug 2004              [Page 14]


Internet Draft                 HAHA protocol                 16 Feb 2004


      Home Agent Address

         A 16 byte field contains the new primary Home Agent Address.
         The Home Agent address MUST be recorded in the Home Agent list
         of the Mobile Router.  If this field does not contain the
         valid global IPv6 address or the unknown Home Agent address,
         the Mobile Router sends dynamic Home Agent address discovery
         request message.  Otherwise, the Mobile Router switches to this
         Home Agent immediately as its primary Home Agent.

   Home Agent Switch Request message MUST be authenticated and encrypted
   by the use of IPsec ESP mode.


   4.2. New Mobility Options

   4.2.1. Home Address

   The Home Address option has an alignment requirement of 8n+6.  Its
   format is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = 0x8  | Option Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                        Home Address                           |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This option is used when the Home Agent needs to figure out the
   Binding Cache information for a particular Mobile Node or Mobile
   Router.  not useful when each Home Agent sends an unsolicited binding
   cache information for each BU it receives.


   4.2.2. Mobile Network Prefix Option

   This option is already defined in the Nemo basic support [7].  This
   option is included in the Binding Information Request message only if
   a Home Agent is requesting information regarding a particular Mobile
   Network Prefix.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 15]


Internet Draft                 HAHA protocol                 16 Feb 2004


   4.2.3. Binding Cache Entry Information Option

   The Binding Cache Entry Information option has an alignment
   requirement of 8n+2.  Its format is as follows:

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

   Binding Cache Entry Information option is valid in the Binding
   Information Update.

   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.

   The field ``Number of MNPs'' tells the receiving Home Agent which
   Mobile Network Prefixes are owned by a Mobile Router.  The receiving
   Home Agent can then setup forwarding for each Mobile Network Prefix.
   for Mobile IPv6, the ``Number of MNPs'' field is set to 0.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 16]


Internet Draft                 HAHA protocol                 16 Feb 2004


   5. Home Agent Lists Management

   Mobile IPv6 uses Router Advertisement messages to manage Home Agent
   lists on each Home Agents.  When Home Agents are placed at different
   links, Router Solicitation and Advertisement messages can not be used
   due to link-local limitation.  Therefore, a new MH message is defined
   to notify similar information of Router Advertisement among Home
   Agents over the home link.

   A Home Agent MUST know other Home Agents which configured in
   different links beforehand.  This is manually configured on each
   Home Agent.  This mechanism MUST be used only between Home Agents on
   different links serving the same home prefix.  It SHOULD not be used
   between Home Agents on the same link.

   A Home Agent MUST periodically send a Home Agent HELLO message.  The
   Home Agent SHOULD also send a Home Agent HELLO message when its local
   information such as preference, lifetime, and registration status,
   etc.  changes.

   A Home Agent HELLO message MUST be constructed with same information
   of a Router Advertisement message described in section 7 of [2] and
   MUST be sent by a unicast to the destination (other Home Agents).

   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.  Otherwise, the
   receiver processes the Home Agent HELLO message to update its Home
   Agent list.  The Sequence field should be checked to ensure the
   freshness of the received HELLO message.

   Any Home Agent HELLO message satisfying all of these tests MUST be
   processed to update its Home Agent list.  The receiver Home Agent
   copy each field of the Home Agent HELLO message to its local Home
   Agent List.  If the Lifetime field is set to zero, the receiver MUST
   delete the sender Home Agent from the Home Agent List.

   When a new Home Agent boots up, it SHOULD wait particular time to
   listen Home Agent HELLO messages of all configured Home Agents.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 17]


Internet Draft                 HAHA protocol                 16 Feb 2004


   6. Home Agent Failure Detection

   Each Home Agent detects Home Agent failure by monitoring lifetime of
   each Home Agent List entry.

   When an entry is deleted because of lack of either Router
   Advertisements or Home Agent HELLO messages, the Home Agent is
   treated as invalid.

   When Home Agent Lifetime is notified with zero by Router
   Advertisements or Home Agent HELLO messages, the receiver MUST mark
   the sender Home Agent as invalid, too.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 18]


Internet Draft                 HAHA protocol                 16 Feb 2004


   7. Binding Synchronization among Home Agents

   A binding for a particular Mobile Node is shared among Home Agents.
   Therefore, each Home Agents can always know the binding for a
   particular Mobile Node and the primary Home Agent which is currently
   serving the Mobile Node.  This makes it possible for Mobile Nodes to
   utilize multiple Home Agents simultaneously.

   Binding synchronization messages can be sent with either unicast
   or multicast routing.  If unicast routing is used, full mesh
   flooding is required.  Full mesh flooding incurs high overhead for
   synchronizing information among multiple entities.  But there are
   existing mechanisms like CARP and BGP reflector mechanism to reduce
   the overhead.  Therefore this document does not discuss any optimized
   synchronization schemes.  This document assumes full mesh flooding,
   however, it can be replaced by any other mechanism which achieves
   full mesh flooding.


   7.1. Requesting Binding

   When a Home Agent wants a binding for a particular Mobile Node, it
   can solicit Binding Information Update message.  The Home Agent sends
   a Binding Information Request message to the primary Home Agent of
   the Mobile Node.  The Home Agent MUST set a random value to the
   Identifier field in the Binding Information Request message and MUST
   include either a Home Address mobility option or a Mobile Network
   Prefix mobility option.


   7.2. Notifying Binding

   The primary Home Agent sends Binding Information Update messages when
   it is solicited by Binding Information Request message or when it
   creates or updates binding for a particular Mobile Node.

   When the primary Home Agent receives a Binding Information Request
   message, it MUST verifies the Source address field of the IPv6
   header.  If the source address is not among the known Home Agents,
   the message MUST be silently discarded.

   If a Home Agent who receives a Binding Information Request message
   is not the primary Home Agent for the requested Mobile Node, it
   MUST ignore the message.  Otherwise, it SHOULD reply to the Binding
   Information Request message.

   The binding information of the requested Mobile Node are stored in
   the Binding Information Update message.  The primary Home Agent
   MUST copy the binding information of the requested Mobile Node to


Wakikawa, et al.              Expires 16 Aug 2004              [Page 19]


Internet Draft                 HAHA protocol                 16 Feb 2004


   each fields of a Binding Cache Entry Information option.  If the
   Binding Information Update message is sent in response to the Binding
   Information Request message, the primary Home Agent MUST copy the
   Identifier field of the Request message to the same filed in the
   Update message.  Otherwise, it MUST set zero to the Identifier field.

   When a Home Agent receives a Binding Information Update message, it
   MUST verify the Source address field of the IPv6 header.  If the
   source address is not among the known Home Agents, the message MUST
   be silently discarded.  If the Binding Information Update message
   is sent from the primary Home Agent, the Home Agent SHOULD record
   the binding information and the primary Home Agent address into its
   Binding Cache.  After registering the binding, the Home Agent MUST
   return a Binding Information Acknowledgement message to the sender
   Home Agent of the Binding Information Update message.

   If the sender Home Agent of the Binding Information Update message
   does not receive a Binding Information Acknowledgement message, it
   MUST retry to send a Binding Information Update message.

   Both a Binding Information Update message, a Binding Information
   Request message and a Binding Infromation Acknowledgement message
   MUST be authenticated and encrypted by IPsec ESP. If a message does
   not have IPsec ESP header, the message MUST be ignored.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 20]


Internet Draft                 HAHA protocol                 16 Feb 2004


   8. Primary Home Agent Switching

   A Mobile Node always associates with the best Home Agent from Home
   Agents configured for the Mobile Node.  The Mobile Node initiates
   dynamic Home Agent discovery to get the most appropriate Home Agents.
   The Mobile Node can ensure the best Home Agent by issuing a Dynamic
   Home Agent Address Discovery Request message at each visiting foreign
   links.  Alternatively, Home Agent can send Home Agent Switch Request
   message as a trigger of a Dynamic Home Agent Address Discovery
   Request message to the Mobile Node.

   The Home Agent initiated switching is useful for load-sharing of each
   Home Agents.  A Home Agent can control the load average by moving
   some of Mobile Nodes to other Home Agents compulsory.

   The Mobile Node initiated switching guarantees a Mobile Node to
   register its binding to the best Home Agent all the time.  For
   example, the best Home Agent is the nearest one.


   8.1. Home Agent initiated Switching

   A Mobile Node can change its primary Home Agent when it is requested
   by a Home Agent.  When a Mobile Node receives a Home Agent Switch
   Request, it checks the Home Address field in the request.  If the
   address in the Home Address field is global scope address and is
   already recorded in the Home Agent list of the Mobile Node, the
   Mobile Node MUST immediately switch to the requested Home Agent by
   the Home Agent Switch Request.

   On the other hand, if the requested address in the Home Agent Switch
   Request message is either unknown or empty, the Mobile Node MUST send
   a Dynamic Home Agent Discovery Request message to the Mobile IPv6
   Home-Agents anycast address.  After receiving a Dynamic Home Agent
   Discovery Reply, the Mobile Node selects the most appropriate home
   agent and changes its primary Home Agent to the selected Home Agent.

   The primary Home Agent switching is completed when the Mobile Node
   registers its binding to the new Home Agent.


   8.2. Mobile Node initiated Switching

   When a Mobile Node decides to change its primary Home Agent, it
   selects the new Home Agent from its Home Agent list.  The Mobile Node
   can start Dynamic Home Agent Address Discovery mechanism to update
   Home Agents information such as a preference value of each Home
   Agents.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 21]


Internet Draft                 HAHA protocol                 16 Feb 2004


   After selection of a new Home Agent, it registers its binding to the
   new Home Agent.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 22]


Internet Draft                 HAHA protocol                 16 Feb 2004


   9. Scenarios

   This section describes assumed scenarios of the HAHA protocol.
   Network configurations such as Home Prefix assignments and route
   managements are described in [8].

   Two scenario are introduced such as the Single Home Agent Activation
   and the Multiple Home Agents Activation.  Both can be applied to both
   Mobile IPv6 and the Nemo basic support protocol.

   In each figures descrbied below, the operation of Binding Information
   Acknowledgement message is omitted.  The binding notification is
   assumed to be success all the time in this Section.


   9.1. Single Home Agent Activation


    MN     PHA      HA2     HA3     CN
     |       |       |       |       |
     |------>|       |       |       | 1. Home Registration
     |       |       |       |       |
     |======>|---------------------->| 2. Sending Packet to CN
     |       |       |       |       |    via Primary HA"(PHA)
     |<======|<----------------------| 3. Sending Packet to MN
     |       |       |       |       |    via PHA
     |<------|(HA1)  |       |       | 4. Trigger primary HA switching
     |       |       |       |       |
     |-------------->|(PHA)  |       | 5. Sending Binding Update
     |       |       |       |       |
     |       |<------|------>|       | 6. Soliciting the binding
     |       |       |       |       |    to other HAs. (no reply)
     |<--------------|       |       | 7. Sending Binding Acknowledgement
     |       |       |       |       |
     |==============>|-------------->| 8. Sending Packet to CN
     |       |       |       |       |
     |<==============|<--------------| 9. Sending Packet to CN
     |       |       |       |       |


                 Figure 1: Local Home Agent Distribution


   All packets meant for a Mobile Node are routed to the primary Home
   Agent and are intercepted by the primary Home Agent as well as both
   Mobile IPv6 and Nemo basic support.  Then, the primary Home Agent
   tunnels packets to the Mobile Node according to either the registered
   binding cache or the forwarding states established by a Binding
   Update (Seq2 and Seq3).


Wakikawa, et al.              Expires 16 Aug 2004              [Page 23]


Internet Draft                 HAHA protocol                 16 Feb 2004


   When the Mobile Node switches its primary Home Agent, it sends a
   Binding Update to the new primary Home Agent (Seq5).  The new primary
   Home Agent receiving the Binding Update verifies whether the other
   Home Agents still hold the binding for the Mobile Node.  It sends
   Binding Information Request messages to all the other Home Agents
   (Seq6).  If it receives any Binding Information Update message in
   response to the Binding Information Request messages, it sends a
   Binding Acknowledge to the Mobile Node with the status value set to
   144 (another Home Agent is still active).  Otherwise, the Home Agent
   accepts the Binding Update and becomes the primary Home Agent for the
   Mobile Node (Seq7).

   If the Mobile Node receives the Binding Acknowledge with a negative
   status code, it de-registers its binding from the old primary Home
   Agent and retries to send a Binding Update to the new primary Home
   Agent.  Before trying home registration to the new Home Agent, the
   Mobile Node should de-register its binding from the current primary
   Home Agent.

   When the Mobile Node receives a Home Agent Switch Request from the
   current primary Home Agent, it MUST switch its primary Home Agent
   to the new Home Agent specified in the Home Agent Switch Request.
   The Mobile Node can also switch the primary Home Agent proactively
   without the Home Agent Switch Request.


   9.2. Multiple Home Agent Activation

   Each Home Agent synchronizes a binding for a particular Mobile Node
   by the HAHA protocol.  If all the Home Agents who have the binding
   for the Mobile Node can setup forwarding for the Home Address and the
   mobile network prefixes owned by the Mobile Node if any, it tunnels
   intercepted packets directly to the Mobile Node (Fig 3).  On the
   other hand, if the Home Agent does not enable forwarding for the
   Home Address and the mobile network prefixes, it tunnels intercepted
   packets to the primary Home Agent (Fig 2) first.  Then the primary
   Home Agent re-tunnels packets to the Mobile Node.  It is a matter of
   operations whether forwarding setting is enable on all the Home Agent
   or not.

   In the figure 2, a Mobile Node first registers its binding to the
   primary Home Agent (Seq1).  Once the primary Home Agent creates
   a binding for the Home Address of the Mobile Node and sets up
   forwarding for the Mobile Network Prefixes, it sends Binding
   Information Update messages to other Home Agents to synchronize the
   binding information (Seq2 and Seq3).  When a Home Agent receives the
   Binding Information Update message, it records the binding and the
   primary Home Agent address (which can be retrieved from the source


Wakikawa, et al.              Expires 16 Aug 2004              [Page 24]


Internet Draft                 HAHA protocol                 16 Feb 2004


    MN      PHA     HA2     CN1     HA3     CN2
     |       |       |       |       |       |
     |------>|       |       |       |       | 1. Home Registration
     |       |       |       |       |       |
     |       |------>|       |       |       | 2. Sending binding to HA2
     |       |       |       |       |       |
     |       |---------------------->|       | 3. Sending binding to HA3
     |       |       |       |       |       |
     |======>|-------------->|       |       | 4. Sending Packet to CN1
     |       |       |       |       |       |    via PHA
     |<======|<------|<------|       |       | 5. Sending Packet to MN
     |       |       |       |       |       |    via HA2 and PHA
     |======>|------------------------------>| 6. Sending Packet to CN2
     |       |       |       |       |       |    via PHA
     |<======|<----------------------|<------| 7. Sending Packet to MN
     |       |       |       |       |       |    via HA3 and PHA
     |-------------->|(PHA)  |       |       | 8. Home Registration
     |       |       |       |       |       |
     |  (HA1)|<------|-------------->|       | 9. Sending binding to
     |       |       |       |       |       |    HA1 and HA3
     |==============>|---------------------->| 10. Sending Packet to CN2
     |       |       |       |       |       |    via PHA
     |<==============|<--------------|<------| 11. Sending Packet to MN
     |       |       |       |       |       |    via HA3 and PHA


    Figure 2: Multiple Home Agents with single bi-directional tunnel


   address of the Binding Information Update messages) in the binding
   cache entry.

   After the completion of the binding synchronization, all Home
   Agents start to distribute the network routes for the Mobile Network
   Prefixes to the Internet in the basic NEMO case.  Therefore, when the
   Mobile Network Node communicates with a Correspondent Node, outgoing
   packets from the Mobile Network are tunneled to the closer primary
   Home Agent (Seq4) and incoming packets to the Mobile Network are
   intercepted by the Home Agent which is close to the Correspondent
   Node (Seq5).  Then, the intercepted packets are forwarded/tunneled to
   the primary Home Agent.  The primary Home Agent delivers the packets
   to the Mobile Router through the bi-directional tunnel (Seq5).  In
   Mobile IPv6, the operation is same except for lack of Mobile Network
   Prefixes.

   If the Mobile Node decides to switch its primary Home Agent due to
   its movement, it sends a Binding Update to the new primary home
   agent.  Then, the new primary Home Agent starts to synchronize the


Wakikawa, et al.              Expires 16 Aug 2004              [Page 25]


Internet Draft                 HAHA protocol                 16 Feb 2004


   binding information with other Home Agents (Seq9).  All Home Agent
   updates the binding and the primary Home Agent address according to
   the received Binding Information Update message.


    MN      HA1    HA2     CN1     HA3     CN2
     |       |       |       |       |       |
     |------>|       |       |       |       | 1. Home Registration
     |       |       |       |       |       |
     |       |------>|       |       |       | 2. Sending the binding
     |       |       |       |       |       |    to HA2
     |       |---------------------->|       | 3. Sending the binding
     |       |       |       |       |       |    to HA3
     |======>|-------------->|       |       | 4. Sending Packet to CN1
     |       |       |       |       |       |    via HA1
     |<==============|<------|       |       | 5. Replying to MN
     |       |       |       |       |       |    via HA2
     |======>|------------------------------>| 6. Sending Packet to CN2
     |       |       |       |       |       |    via HA1
     |<==============================|<------| 7. Replying to MN
     |       |       |       |       |       |    via HA3


              Figure 3: Multiple Home Agents with multiple
                         bi-directional tunnels


   In the figure 3, a Mobile Node first sends a Binding Update to its
   primary Home Agent (Seq1).  The primary Home Agent also notifies the
   binding information to other Home Agents by using Binding Information
   Update messages (Seq2 and Seq3).  When a Home Agent receives the
   Binding Information Update message, it records the binding and the
   primary home agent address as a binding cache entry for the Mobile
   Node and sets up forwarding for mobile network prefixes if any.

   After creating the binding cache entry and setting up forwarding,
   each Home Agent starts to distribute network routes for the mobile
   network prefixes to the Internet.  When the Mobile Network Node
   communicates with a Correspondent Node, outgoing packets from
   the mobile network are tunneled to the primary Home Agent (Seq4).
   Incoming packets to the mobile network are intercepted by the Home
   Agent which is close to the Correspondent Node (Seq5).  Then, the
   intercepted packets are tunneled directly to the current Care-of
   Address according to binding and forwarding (Seq5).

   The procedure of primary Home Agent switching is same as the
   procedure described in Fig 2.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 26]


Internet Draft                 HAHA protocol                 16 Feb 2004


   10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol

   The HAHA protocol modifies the below items of Mobile IPv6 [2] and the
   Nemo Basic Support protocol [7].

    -  The new status values for the Binding Acknowledgment.


       When a Mobile Node receives this status for its home
       registration, it MUST de-register its binding from the old
       primary Home Agent and SHOULD re-try home registration.  A Home
       Agent SHOULD use this status value only in the Single Home
       Agent Activation scenario.  The primary Home Agent can not be
       duplicated in the scenario and can only have a binding for a
       particular Mobile Node all the time.

       Status

          144     Another primary Home Agent is still active.

    -  Binding Cache Registration
       The conceptual fields of each Binding Cache entry are defined
       in [2].  The HAHA protocol introduces an additional field to
       record the primary Home Agent address for a Mobile Node.

       When a Home Agent receives a Binding Information Update message,
       it creates or updates the binding cache entry.  The Home Agent
       MUST record the primary Home Agent address in the binding cache
       entry.  The address can be derived from the Source address field
       of IPv6 header in the Binding Information Update message.

       When a primary Home Agent receives a Binding Update from a Mobile
       Node, it MUST records its own address as the primary Home Agent
       address in the binding cache entry.

    -  Tunneling packets to Mobile Node Home Agents
       Home Agents who registers a binding by the HAHA protocol can
       tunnel packets meant for the Mobile Node or Mobile Network to
       the current Care-of Address as well as the primary Home Agent.
       The Mobile Node can accept the tunneled packets.  The Mobile
       Node MUST know all the Home Agents who has its binding in the
       home agent list so as to verify the Source address of outer IPv6
       header.

    -  Tunneling packets to primary Home Agent from Home Agents
       When one of Home Agents who has a binding intercepts packets
       meant for a particular Mobile Node, the Home Agent can tunnel
       packets to the primary Home Agent recorded in the binding cache.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 27]


Internet Draft                 HAHA protocol                 16 Feb 2004


       The primary Home Agent tunnels packets to the current Care-of
       Address of the Mobile Node.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 28]


Internet Draft                 HAHA protocol                 16 Feb 2004


   11. IANA Considerations

   This document defines three new Mobility Header messages

    -  Home Agent HELLO Message

    -  Binding Information Request Message

    -  Binding Information Update Message

    -  Binding Information Acknowledgment Message

    -  Home Agent Switch Request Message

   This document defines two new Mobility Options.

    -  Home Address

    -  Binding Cache Entry Information


Wakikawa, et al.              Expires 16 Aug 2004              [Page 29]


Internet Draft                 HAHA protocol                 16 Feb 2004


   12. Security Considerations

   Multiple Home Agents advertise routes for either same Home Prefix and
   possibly Mobile Network Prefix in the HAHA protocol, these routes
   MUST be correctly advertised.  System Administrators MUST prevent
   malicious (blackhole) routes for these prefixes.

   A Home Agent MUST know the other Home Agent serving a same Mobile
   Node and MUST establish a secure association with each Home Agent.
   All signaling messages between the Mobile Node and the Home Agent
   MUST be authenticated and encrypted by IPsec ESP [5].

   The Mobile Node MUST verify that packets are tunneled through the
   known Home Agent.  In Multiple Home Agent Activation scenario, the
   Mobile Node may receives packets tunneled by multiple Home Agents.
   The Mobile Node MUST know all Home Agents who has its binding by the
   HAHA protocol in its Home Agent List by using Home Agent Address
   Discovery.  It is necessary for a Mobile Node to know all other Home
   Agents in order to protect attacks launched by malicious Home Agents.

   Please refer to the Mobile IPv6 specification [2] and the Nemo Basic
   Support protocol specification [7] for security considerations.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 30]


Internet Draft                 HAHA protocol                 16 Feb 2004


   References

   [1] J. Faizan, H. El-Rewini, M. Khalil, Problem Statement:  Home
       Agent Reliability (work in progress). Internet Draft, IETF.
       draft-jfaizan-mipv6-ha-reliability-01.txt Februry 2004.

   [2] D. Johnson, C. Perkins and J. Arkko. Mobility Support
       in IPv6 (work in progress). Internet Draft, IETF.
       draft-ietf-mobileip-ipv6-22.txt. May 2003.

   [3] T. Ernst and H. Lach. Network Mobility Support Terminology (work
       in progress). Internet Draft, IETF. draft-ietf-nemo-terminology
       -00.txt May 2003.

   [4] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to
       Protect Mobile IPv6 Signaling between Mobile Nodes and
       Home Agents (work in progress). Internet Draft, IETF.
       draft-ietf-mobileip-mipv6-ha-ipsec-05.txt May 2003

   [5] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP).
       RFC 2402, IETF. November 1998.

   [6] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
       Specification. RFC 2473, IETF. December 1998.

   [7] V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert.
       Nemo Basic Support Protocol (work in progress). Internet Draft,
       IETF. draft-ietf-nemo-basic-support-01.txt September 2003

   [8] P. Thubert and R. Wakikawa and V. Devarapalli. Examples of
       basic Nemo usage (work in progress). Internet Draft, IETF.
       draft-ietf-nemo-basic-usage-00.txt October 14 2003.

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

   [10] J. Manner and M. Kojo. Mobility Related Terminology.
       draft-ietf-seamoby-mobility-terminology-05.txt November 2003


Wakikawa, et al.              Expires 16 Aug 2004              [Page 31]


Internet Draft                 HAHA protocol                 16 Feb 2004


   A. Changes from -00

    -  Obsolete two ICMP messages (Home Agent Solicitation and
       Advertisement Message)

    -  Add a new MH message called Home Agent HELLO message

    -  Change the name of Binding Information Reply Message to Binding
       Information Update Message

    -  Add a new MH message called Binding Information Acknowledgment
       Message

    -  Add a section for a detailed example in Appendix B


Wakikawa, et al.              Expires 16 Aug 2004              [Page 32]


Internet Draft                 HAHA protocol                 16 Feb 2004


   B. Distributed Home Network

   This section describes a detailed example how multiple Home Agents
   are configured in different routing domains.  The HAHA protocol does
   not completely cover all operations for this example at this time.
   Readers are expected to read  [8] before reading this section.

   In distributed home network, a global Home is advertised by several
   sites that are geographically distributed and meshed using tunnels
   in a VPN fashion.  Mobile Nodes locate the closest site using
   DHAAD against the global Home Network and bind there.  Some form of
   inter-site synchronization (e.g.  a routing protocol), which Mobile
   IPv6 and Nemo Basic Support do not provide, must take place in order
   to allow packets to be routed between the incoming site to the Mobile
   Node.  The HAHA (Home Agent to Home Agent) protocol is being designed
   for that purpose.

   In one model, each site is responsible for a subnet of Home.  When a
   Mobile Node roams far from its natural (default) site, it registers
   to a Home Agent on a remote site, that takes the registration and
   notifies at least the natural site of the foreign registration.

   There are at least 3 approaches in order to locate the Home Agent
   that has a registration for a given Mobile Node, Router or Mobile
   Network:

    -  reactive
       This method is also referred to as 'on-demand'.  In case
       of a binding cache miss, a Home Agent floods a Binding
       Information Request message to all the other Home Agents with
       the (destination of the packet) home address that is sought
       for.  Every Home Agent that has a registration for that home
       address or for a Mobile Network that encompasses that home
       address responds.  This approach is traditionally used in fast
       changing configurations, for instance if Mobile Nodes register
       and de-register very often.

    -  proactive
       An information is pushed to all Home Agents with the Home
       Address and the Mobile Network Prefixes each time by Binding
       Information Update message This approach is preferred for stable
       configurations, for instance if Mobile IP is used as a tool to
       simplify the configuration and reconfiguration of mostly stable
       networks.

    -  predictive
       Ranges of Home Addresses and prefixes are assigned to the Home
       Agents, following a rule that is commonly computed by all Home
       Agents.  Dynamic Home Agent Address Discovery (DHAAD) returns


Wakikawa, et al.              Expires 16 Aug 2004              [Page 33]


Internet Draft                 HAHA protocol                 16 Feb 2004


       only the address of one Home Agent, the one that is pre-allocated
       for that Mobile Node.  When the wrong Home Agent intercepts
       packets, it can compute which is the right Home Agent and forward
       packets to it at L2 if they are directly connected, or via a HAHA
       tunnel which is established between Home Agents.  This is what we
       call 'Z' routing.


       CN  --------> closest HA       CN  ----------> closest HA
                  /                                      |
                 /                                       |
                /                                        |
               /                                         |
              /                                          |
   Assigned  /                                           |
      HA    v                                            V
           ----------> Mobile Node                   Mobile Node


   The Predictive Mode minimizes the control traffic, which may be
   required for a large configuration.  Some additional controls would
   be necessary for the HAHA protocol to allow the negotiation and the
   distribution of the shares of Home to be attributed to each Home
   Agent.

   One specific advantage of not relying on a Home Link for HAHA
   communication is that for a large configuration, the Home Agents can
   be organized hierarchically and distributed geographically, as a set
   of local clusters linked together to form a global Home Network.

   For instance, it is possible for a large ISP to partition the Home
   Network for a given worldwide service, and assign a partition to a
   cluster of Home Agents in each of the geographies.  In predictive
   mode, each Home Agent in the world would be able to compute the
   best suited Home Agent in its local cluster (call this a Acting


Wakikawa, et al.              Expires 16 Aug 2004              [Page 34]


Internet Draft                 HAHA protocol                 16 Feb 2004


   Home Agent) and the best suited Home Agent worldwide (call this the
   Assigned Home Agent) for each and any Home Address.


             HA                                     HA
             |                  ______              |
  --+-----+--+- . -+- . -+--    TUNNEL   --+-----+--+- . -+- .. -+--
    |     |        |     |      ______     |     |        |      |
   MR1   MR2      MRi   MRN               MR1   MR2      MRi    MRN
 ------  ------  ------ ------           ------  ------  ---- - ----
  /64        A:B:1:i::/64                 /64         A:B:n:i::/64


                    Distributed Home Network /48
 <------------------------------------------------------------------>

     extended HN             Aggregated HN              Virtual HN
 <----------------------><---------------------->...<--------------->

  Home    Mob       Mob    Mob    Mob       Mob       Mob       Mob
 <-----><----->...<-----><-----><----->...<----->...<----->...<----->


   Any Home Agent processing an anycast DHAAD can predict the Assigned
   Home Agent and local Acting Home Agents for a Home Address if that
   information is added to the DHAAD request.  In the case of Mobile
   Routers, the service must be arranged in such ways that, for a given
   registration, all the Mobile Networks are assigned to a same Home
   Agent.

   Possible flows:  In order to register, a Mobile Node uses DHAAD which
   returns one Home Agent in the closest cluster.  This can be a Acting
   Home Agent if the Mobile Node is roaming far from Home, but hopefully
   it is in general the Assigned Home Agent for that Mobile Node.  When
   this is a Acting Home Agent, it needs to register to the Assigned
   Home Agent as proxy binding.

   When a packet destined to a given Home Address arrives at a Home
   Agent from a Correspondent Node:

   If the Home Agent is Assigned Home Agent for that Home Address and it
   has a direct registration (it is primary), the Home Agent forwards
   the packet over its bi-directional tunnel established with the Mobile
   Node (the MNHA tunnel).  If it has a proxy registration (it is
   secondary), it forwards the packet to the primary Acting Home Agent -
   or directly to the Mobile Node if that is practical for tunnel setup
   and security reasons.  Else it drops the packet.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 35]


Internet Draft                 HAHA protocol                 16 Feb 2004


   Else If the Home Agent is Acting Home Agent for that Home Address and
   it has a direct registration (it is primary), the Home Agent forwards
   the packet over its MNHA tunnel.  If it has a proxy registration (it
   is secondary), it forwards the packet to the primary Acting Home
   Agent - or directly to the Mobile Node if that is practical for
   tunnel setup and security reasons.  Else, it forwards the packet to
   the Assigned Home Agent.


       CN  ----------> Acting HA
                     /   closest to CN
                    /
                   /
                  /
       Assigned  /
           HA   V
                 "
                  "
                   "
                    "
                     "
                      " Acting HA primary
        MN <----------- for that registration
                        (closest to MN)


       CN  ----------> closest HA
                     | to CN
                     |
                     |
                     |
                     |
                     v Acting HA, primary
       MN <---------  for that registration
                          (closest to MN)

   Else (if the Home Agent is the 'wrong Home Agent') the Home Agent
   tunnels the packet to the best suited of the local Home Agents, be it
   the Assigned Home Agent, or a local Acting Home Agent.

   In the worst case, the packet may bounce from the receiving
   Home Agent to the local Acting Home Agent, then to the Assigned
   Home Agent, and finally to the Acting Home Agent that has the
   registration.  It is up to the Assigned Home Agent to forward the
   proxy binding states to the Acting Home Agent on the receiving side
   in order to allow Acting Home Agent to Acting Home Agent 'Z' routing.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 36]


Internet Draft                 HAHA protocol                 16 Feb 2004


   If the Home Agents are distributed geographically, it is expected
   that, in general, the angles of the Z (the Home Agents) are close to
   the Mobile Node and Correspondent Node respectively, relatively to
   the distance between the Home Agents, which makes the cost of the
   bouncing acceptable in terms of distance and hops.

   When a packet from a registered Mobile Node arrives over the MNHA
   tunnel to a Home Agent (one that it is registered to), the Home Agent
   forwards the packet directly to the Correspondent Node.  That Home
   Agent is supposed to be close to the Mobile Node, making the MN-HA-CN
   triangle as flat as possible and limiting the cost of the dogleg.


Wakikawa, et al.              Expires 16 Aug 2004              [Page 37]


Internet Draft                 HAHA protocol                 16 Feb 2004


   Authors Addresses


        Ryuji Wakikawa
        Keio University and WIDE
        5322 Endo Fujisawa Kanagawa
        252-8520
        Japan
        Email:  ryuji@sfc.wide.ad.jp

        Vijay Devarapalli
        Nokia Research Center
        313 Fairchild Drive
        Mountain View, CA 94043
        USA
        Email:  vijay.devarapalli@nokia.com

        Pascal Thubert
        Cisco Systems Technology Center
        Village d'Entreprises Green Side
        400, Avenue Roumanille
        Biot - Sophia Antipolis 06410
        France
        Email:  pthubert@cisco.com


Wakikawa, et al.              Expires 16 Aug 2004              [Page 38]


Internet Draft                 HAHA protocol                 16 Feb 2004


   Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However,
   this document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet Society
   or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures
   for copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.


   Acknowledgement

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


Wakikawa, et al.              Expires 16 Aug 2004              [Page 39]


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