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

Versions: 00 01 02

Mobile IP Working Group                                  Jahanzeb Faizan
Internet-Draft                                          Hesham El-Rewini
Expires: October, 2004                     Southern Methodist University
                                                         Mohammad Khalil
                                                         Nortel Networks
                                                             April, 2004


                Virtual Home Agent Reliability Protocol (VHAR)
                       draft-jfaizan-mipv6-vhar-02.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.

   This Internet-Draft will expire on October, 2004.

Copyright Notice

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

Abstract

   Current specifications of Mobile IPv6 does not provide Home Agent
   Reliability in the home link. The aim of this draft is to introduce
   Virtual Home Agent Reliability Protocol as the solution. In this
   protocol multiple Home Agents coexist on the same home link and share
   the same Global IP address. Only one of them is active at a time and
   serves the Mobile Node. The Home Agent failure and failover
   mechanisms are completely transparent to the Mobile Node which is
   required for minimal service interruption time. This protocol does
   not introduce any new Mobile IPv6 message over the air interface and
   thus helps reducing the overall overhead.



Faizan.                  Expires October, 2004                  [Page 1]


Internet-Draft               VHAR Protocol                   April, 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.   Terminology . . . .. . . . . . . . . . . . . . . . . . . . . . 3

   3.   Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5

   4.   Virtual Home Agent Reliability Protocol Overview . . . . . . . 5
        4.1  VHAR Deployment Scenario . . . . . . . . . . . . . . . . .5
        4.2  VHAR State Diagram. . . . . . . . . . . . . . . . . . . . 6
        4.3  Mobile Node Registration . . . . . . . . . . . . . . . . .8
        4.4  VHAR Failure Detection and Recovery . . . . . . . . . . . 9
             4.4.1 Active Home Agent Failure . . . . . . . . . . . . .10
             4.4.2 Backup Home Agent Failure . . . . . . . . . . . . .12

   5.   Security Issues in VHAR. . . . . . . . . . . . . . . . . . . .14
        5.1  IPsec SAs Synchronization among Home Agents. . . . . . . 14
        5.2  Correct Ordering of Binding Updates . . . . . . . . . . .14

   6.   New ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 15
        6.2  Modified Router Advertisement Message. . . . . . . . . . 15
        6.3  MN Release Request Message . . . . . . . . . . . . . . . 16
        6.4  MN Release Reply Message . . . . . . . . . . . . . . . . 17
        6.5  MN Context Update Request Message . . . . . . . . . . . .18
        6.6  MN Context Update Reply Message . . . . . . . . . . . . .19
        6.7  SP Synch Message . . . . . . . . . . . . . . . . . . . . 20
        6.8  SP Reply Message . . . . . . . . . . . . . . . . . . . . 21
        6.9  SeqNo Synch Message . . . . . . . . . . . . . . . . . . .22

   7.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23

   8.   Security Considerations . . . . . . . . . . . . . . . . . . . 23

        References . . . . . . . . . . . . . . . . . . . . . . . . . .23

        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .24

        Intellectual Property and Copyright Statements . . . . . . . .24

        Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .25










Faizan.                  Expires October, 2004                  [Page 2]


Internet-Draft               VHAR Protocol                   April, 2004


1. Introduction

   Mobile IPv6 [1] is designed to allow a Mobile Node(MN) to change its
   point of IP subnet attachment in the Internet at the network or IP
   layer. MN is always identified by it Home Address regardless of its
   current location. Its mobility is not limited by conventional IP
   network boundaries. In Mobile IPv6 system the Home Agent(HA) remains
   at conventional IPv6 subnet called the home link and when the MN is
   at the home link packets sent to it are routed through conventional
   IPv6 [3] routing mechanisms. When the MN is not at home link it
   registers its remote point of attachment address called Care-of
   Address with the HA. This allows HA to forward packets, addressed to
   the MN at its home link, to its current location.

   In Mobile IPv6 system, as currently specified, a single HA services
   multiple MNs. Mobile IPv6 also allows deployment of multiple HAs on
   the same link so that if the serving HA fails then any other HA
   on the link can provide service to the MN.

   In Mobile IPv6, MN registers and establishes a connection with only
   one HA. The MN is reliant on this HA for its connectivity. Thus the
   HA represents the possibility of a single point of failure for Mobile
   IPv6. A HA may be responsible for multiple MNs on the home link. The
   failure of a single HA may then result in the loss of connectivity
   for numerous MNs located throughout the Internet. Thus the HA and MN
   taken together have a shared fate. A MN cannot afford the loss of its
   HA. To overcome this problem Mobile IPv6 allows deployment of
   multiple HAs on the home link so that upon the failure of serving HA,
   another HA can take over the functions of failed HA and thus provide
   continuous service to the MN(s) registered with failed HA. This
   transfer of service from the failed HA to a new working HA is
   problematic and the current specification of Mobile IPv6 does not
   provide solution to these problems. In [7] these problems were
   discussed and guidelines for the possible solutions were proposed.

   The goal of this draft is to propose "Virtual Home Agent Reliability"
   protocol which provides HA Reliability in the Mobile IPv6 networks.


2 Terminology

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

   Following terms are not re-defined. They are included for the
   convenience of the readers.




Faizan.                  Expires October, 2004                  [Page 3]


Internet-Draft               VHAR Protocol                   April, 2004


   Mobile IPv6
           Mobile IP for IPv6 [1]

   Mobile Node (MN)
           A node that can change its point of attachment from one link
           to another, while still being reachable via its home address.

   IP
           Internet Protocol Version 6 (IPv6).[3]

   Home Address
           A unicast routable address assigned to a MN, used as the
           permanent address of the MN. This address is within the MN's
           home link. Standard IP routing mechanisms will deliver
           packets destined for a MN's home address to its home
           link. MNs can have multiple home addresses, for instance when
           there are multiple home prefixes on the home link.

   Home Link
           The link on which a MN's home subnet prefix is defined.

   Home Agent (HA)
           A router on a MN's home link with which the MN has registered
           its current Care-of address. While the MN is away from home,
           the HA intercepts packets on the home link destined to the
           MN's home address, encapsulates them, and tunnels them to the
           MN's registered Care-of address.

   Care-of Address
           A unicast routable address associated with a MN while
           visiting a foreign link; the subnet prefix of this IP address
           is a foreign subnet prefix. Among the multiple
           Care-of addresses that a MN may have at any given time (e.g.,
           with different subnet prefixes), the one registered with the
           MN's HA for a given home address is called its "primary"
           Care-of address.

   IPsec Security Association
           An IPsec security association is a cooperative relationship
           formed by the sharing of cryptographic keying material and
           associated context. Security associations are simplex. That
           is, two security associations are needed to protect
           bidirectional traffic between two nodes, one for each
           direction.

   Home Registration
           A registration between the MN and its HA, authorized by the
           use of IPsec.



Faizan.                  Expires October, 2004                  [Page 4]


Internet-Draft               VHAR Protocol                   April, 2004


3. Related Work

   HAHA [4] protocol provides HA Reliability for Mobile IPv6. In this
   protocol multiple HAs are provided over different links and MN has to
   register its binding in them. MN selects one of the HAs as its
   primary HA. Primary HA or any other HA can tunnel packets from
   Correspondant Node to MN. On failure of the primary HA the MN can
   switch its service to any other HA on any link. In this protocol the
   MN has burden to detect the failure of its primary HA and then
   recover from this failure. Since HAs are located at different
   physical links to provide service in case of home link failure the MN
   has burden of doing multiple Home Registrations. Also the failure of
   the primary HA is not transparent to the MN and it is delayed by a
   considerable amount of time which results in service interruption and
   message overhead. MN also has to re-establish IPsec Security
   Associations (SAs) with all the HAs.


4. Virtual Home Agent Reliability Protocol Overview

   Virtual HA Reliability Protocol (VHAR) provides HA reliability in the
   Mobile IPv6 by introducing some modifications in the operation of
   HAs. Except some modifications, the Mobile IPv6 operation remains
   unchanged. VHAR uses multiple HAs on the same home link. All the HAs
   have different link-local IP addresses but exactly same Global IP
   address, referred as Global Home Agent address (modification in
   Mobile IPv6). Unlike Mobile IPv6, MN is only aware of the Global Home
   Agent address and uses this address as the destination IP address for
   the packets destined to its home network. Also the HA send packets to
   the MN using the Global Home Agent address as the source IP address.
   In short all the communication between the MN and HA is based on the
   Global Home Agent address. This provide seamless HA failure and
   failover and helps keeping the message overhead and service
   interruption time minimized. On the home link all the HAs communicate
   with each other using link-local IP addresses according to normal
   Mobile IPv6 operation.

4.1 VHAR Deployment Scenario

   We will consider a basic deployment scenario where six HAs (HA_1..6)
   coexist on the same home link to provide continuous service to the
   MN. Currently HA_1 is Active HA and responsible for all the Mobile
   IPv6 HA functions.








Faizan.                  Expires October, 2004                  [Page 5]


Internet-Draft               VHAR Protocol                   April, 2004


            Foreign Network                       Home Link
           ...................            ..............................
           .                 .            .                            .
           .      +----+     .            .  +-------+      +-------+  .
           .      |MN  |     .<==========>.  | HA_1  |      | HA_4  |  .
           .      |    |     .            .  +-------+      +-------+  .
           .      +----+     .            .                            .
           .                 .            .  +-------+      +-------+  .
           ...................            .  | HA_2  |      | HA_5  |  .
                                          .  +-------+      +-------+  .
                                          .                            .
                                          .  +-------+      +-------+  .
                                          .  | HA_3  |      | HA_6  |  .
                                          .  +-------+      +-------+  .
                                          ..............................

                 Figure 1: VHAR Basic Deployment Scenario

4.2 VHAR State Diagram

   Unlike Mobile IPv6, each HA on the link could be in one of the
   following states.

Active HA

        Active HA is the one which is responsible for all the Mobile
        IPv6 HA tasks. It owns the Global Home Agent address. There
        could be only one Active HA on the link at a particular instance
        of time. When any HA becomes Active HA it multicasts Neighbor
        Advertisement message on the link with the Target address equal
        to Global Home Agent address and Target link layer address equal
        to its own link-local IP address. This way the Active HA inform
        all the nodes on the link that the Global Home Agent address is
        owned by it. As the result packets received by any node with the
        destination IP address equal to that of Global Home Agent
        address will be forwarded to the Active HA. The Active HA will
        send Router Advertisements on the link by setting 'A' bit along
        with the 'H' bit.

Backup HA

        There are atleast two HAs always exist on the link serving as
        the backup for the mobility bindings. They are known as Backup
        HAs. They don't perform any HA operation and serves as the IPv6
        router. Upon the Active HA failure one of the available Backup
        HAs will become Active HA. Each Backup HA will send Router
        Advertisements on the link by setting 'B' bit along with the 'H'
        bit.



Faizan.                  Expires October, 2004                  [Page 6]


Internet-Draft               VHAR Protocol                   April, 2004


Inactive HA

        Inactive HA is the one which is working as IPv6 router and not
        performing any HA task. Initially all HAs are Inactive HAs.
        Later on except the Active HA and Backup HAs all other HAs on
        the link are Inactive HAs. An Inactive HA can be changed to
        Backup HA by the Active HA. They send Router Advertisements on
        the link by setting the 'H' bit.


                            +-------------+
                            |             |
                            | Inactive HA |
                            |             |
                            +-------------+
                             |           |
                            1|           |2
                             |           |        ------
                             v           v       |      |
                    +-----------+      +-----------+    |4
                    |           |      |           |    |
                    | Active HA |<-----| Backup HA |<---
                    |           |   3  |           |
                    +-----------+      +-----------+

                 Figure 2: VHAR State Diagram


Transition 1

        Initially all HAs are Inactive HAs. When the network is launched
        one of the HAs becomes Active HA.

Transition 2

        When any Inactive HA receives MN Context Update Request Message
        from the Active HA it will become Backup HA.

Transition 3

        When the Active HA fails, a Backup HA will become Active HA.

Transition 4

        When any Backup HA receives MN Context Update Request Message
        from the Active HA it will update its Binding Cache.





Faizan.                  Expires October, 2004                  [Page 7]


Internet-Draft               VHAR Protocol                   April, 2004


4.3 Mobile Node Registration

   When MN wants to register its Care-of Address, it sends Binding
   Update (BU) using the Global Home Agent address as the destination
   address. Any node intercepting this BU will check its neighbor cache
   [5] and forward it to the Active HA_1 (in our scenario) which MAY
   perform Duplicate Address Detection [5] (DaD) to know if the sending
   MN is already registered with any other HA on the home link. If it is
   registered then the Active HA_1 will send "MN Release Request"
   message to the HA which is holding the binding. In response, "MN
   Release Reply" message will be send to the Active HA_1 which will
   complete the registration according to normal Mobile IPv6 operation.
   Active HA_1 will then select two HAs, HA_4 and HA_5 on the link and
   send "MN Context Update Request"(MCUR) messages to them. In response
   these HAs will become Backup HAs and send "MN Context Update Reply"
   (MCURe) messages to the Active HA_1. If the Backup HAs already exist
   then the Active HA_1 will send MCUR messages to them directly. Upon
   receiving the replies Active HA_1 will send Binding Acknowledgement
   (BA) message to the MN.as shown in figure 3 and figure 4..


         Foreign Network                         Home Link
      ...................            .................................
      .                 .            .                               .
      .      +----+     .     BU     .  +--------+ MCUR   +--------+ .
      .      |    |================> .  | Active |------->| Backup | .
      .      | MN |     .            .  |  HA_1  |------  |  HA_4  | .
      .      |    |<====================+--------+ MCUR | +--------+ .
      .      +----+     .     BA     .                  |            .
      .                 .            .  +--------+      | +--------+ .
      ...................            .  |  HA_2  |      | | Backup | .
                                     .  |        |      ->|  HA_5  | .
                                     .  +--------+        +--------+ .
                                     .                               .
                                     .  +--------+        +--------+ .
                                     .  |  HA_3  |        |  HA_6  | .
                                     .  |        |        |        | .
                                     .  +--------+        +--------+ .
                                     .................................

                  Figure 3: VHAR Mobile Node Registration










Faizan.                  Expires October, 2004                  [Page 8]


Internet-Draft               VHAR Protocol                   April, 2004


       ......................................
  MN   . HA_1  HA_2  HA_3  HA_4  HA_5  HA_6 . 0. HA_1 is Active HA.
  |    .  |     |     |     |     |     |   .
  |===>.  |     |     |     |     |     |   . 1. MN sent BU.
  |    .  |     |     |     |     |     |   .
  |    .  |<--------------------------->|   . 2. DaD by Active HA_1.
  |    .  |     |     |     |     |     |   .    HA_3 has binding.
  |    .  |     |     |     |     |     |   .
  |    .  |---------->|     |     |     |   . 3. Active HA_1 sent to
  |    .  |     |     |     |     |     |   .    HA_3 MN Release
  |    .  |     |     |     |     |     |   .    Request.
  |    .  |     |     |     |     |     |   .
  |    .  |<----------|     |     |     |   . 4. HA_3 sent to Active
  |    .  |     |     |     |     |     |   .    HA_1 MN Release Reply.
  |    .  |     |     |     |     |     |   .
  |    .  |---------------->|     |     |   . 5. Active HA_1 sent to
  |    .  |---------------------->|     |   .    HA_4 and HA_5 MCURs.
  |    .  |     |     |     |     |     |   .
  |    .  |<----------------|     |     |   . 6. HA_4 and HA_5 replied
  |    .  |<----------------------|     |   .    to Active HA_1 and
  |    .  |     |     |     |     |     |   .    became Backup HAs.
  |    .  |     |     |     |     |     |   .
  |<======|     |     |     |     |     |   . 7. Active HA_1 sent BA to
  |    .  |     |     |     |     |     |   .    the MN.
       ......................................

             Figure 4: VHAR Mobile Node Registration Signal Flow

   The above mentioned signal flow indicates that there is only single
   Home Registration done by the MN on the home link and still MN's
   binding information is stored on three HAs.

4.4 VHAR Failure Detection and Recovery

   According to Mobile IPv6 specifications each HA maintains Home Agent
   List(HAL) to keep track of all the HAs on the link. VHAR modifies
   this HAL by adding a new field called "Status". This Status field
   represents the state of the HA which could be Active, Backup or
   Inactive. Unsolicited multicast Router Advertisement messages are
   sent periodically on the link according to Mobile IPv6. They help
   HAs to maintain their HALs. VHAR modifies the Router Advertisement
   message by including two flag bits called the 'A' bit (Active HA) and
   the 'B' bit (Backup HA). Also currently specified 'H' bit indicates
   Inactive HA. Thus each HA on the link knows about the Active HA,
   Backup HAs and Inactive HAs on the home link.

   When any HA on the link fails all other HAs will not receive Router
   Advertisement messages from it and upon timeout they will send



Faizan.                  Expires October, 2004                  [Page 9]


Internet-Draft               VHAR Protocol                   April, 2004


   unicast Router Solicitation messages [5] to it in order to confirm
   its failure and if they don't receive Router Advertisement message
   from it still, they will delete its entry from their HALs.

4.4.1 Active Home Agent Failure

   If the failed HA is Active HA then one of the two Backup HAs will
   become Active HA and it will start sending Router Advertisements with
   the 'A' bit set along with the 'H' bit. It will make, among the
   Inactive HAs, a Backup HA by sending MCUR message and receiving MCURe
   message in response.

   Figure 5 shows the failure of Active HA_1 which results in changing
   the status of Backup HA_4 into Active HA_4. The Active HA_4 will then
   send MCUR message to the Inactive HA_2 in order to make it as Backup
   HA_2 as shown in figure 6


       Foreign Network                         Home Link
      ...................            .................................
      .                 .            .    \     /                    .
      .      +----+     .            .  +--\---/-+        +--------+ .
      .      |    |     .            .  | Active |        | Backup | .
      .      | MN |     .            .  |  HA_1  |        |  HA_4  | .
      .      |    |     .            .  +----/\--+        +--------+ .
      .      +----+     .            .      /  \                     .
      .                 .            .  +--------+        +--------+ .
      ...................            .  |  HA_2  |        | Backup | .
                                     .  |        |        |  HA_5  | .
                                     .  +--------+        +--------+ .
                                     .                               .
                                     .  +--------+        +--------+ .
                                     .  |  HA_3  |        |  HA_6  | .
                                     .  |        |        |        | .
                                     .  +--------+        +--------+ .
                                     .................................

                   Figure 5: Failure of the Active HA_1













Faizan.                  Expires October, 2004                 [Page 10]


Internet-Draft               VHAR Protocol                   April, 2004


       Foreign Network                         Home Link
      ...................            .................................
      .      +----+     .            .                    +--------+ .
      .      |    |     .            .                    | Active | .
      .      | MN |     .            .                ----|  HA_4  | .
      .      |    |     .            .           MCUR|    +--------+ .
      .      +----+     .            .               |               .
      .                 .            .  +--------+   |    +--------+ .
      ...................            .  | Backup |   |    | Backup | .
                                     .  |  HA_2  |<--     |  HA_5  | .
                                     .  +--------+        +--------+ .
                                     .                               .
                                     .  +--------+        +--------+ .
                                     .  |  HA_3  |        |  HA_6  | .
                                     .  |        |        |        | .
                                     .  +--------+        +--------+ .
                                     .................................

          Figure 6: Recovery from the failure of the Active HA_1

       ......................................
  MN   . HA_1  HA_2  HA_3  HA_4  HA_5  HA_6 .
  |    .  |     |     |     |     |     |   . 0. HA_1 is Active,
  |    .  |     |     |     |     |     |   .    HA_4 and HA_5 are
  |    .  |     |     |     |     |     |   .    Backup HAs.
  |    .  |     |     |     |     |     |   .
  |    .  |<--------------------------->|   . 1. All the HAs
  |    .  |     |     |     |     |     |   .    multicast Router
  |    .  |     |     |     |     |     |   .    Advertisements.
  |    .  |     |     |     |     |     |   .
  |    .  |--X->|     |     |     |     |   . 2. Active HA_1 failed.
  |    .  |     |     |     |     |     |   .
  |    .  |<----|-----|-----|-----|-----|   . 3. All other HAs unicast
  |    .  |     |     |     |     |     |   .    Router Solicitations
  |    .  |     |     |     |     |     |   .    to HA_1.
  |    .  |     |     |     |     |     |   .
  |    .  |     |<----------|     |     |   . 4. Backup HA_4 became
  |    .  |     |     |     |     |     |   .    Active HA_4 and ask
  |    .  |     |     |     |     |     |   .    Inactive HA_2 to
  |    .  |     |     |     |     |     |   .    become Backup by
  |    .  |     |     |     |     |     |   .    sending MCUR
  |    .  |     |     |     |     |     |   .
  |    .  |     |---------->|     |     |   . 5. HA_2 replied to the
  |    .  |     |     |     |     |     |   .    Active HA_4 and became
  |    .  |     |     |     |     |     |   .    Backup HA_2.
       ......................................

   Figure 7: VHAR Active HA Failure Detection and Recovery Signal Flow



Faizan.                  Expires October, 2004                 [Page 11]


Internet-Draft               VHAR Protocol                   April, 2004


4.4.2 Backup Home Agent Failure

   VHAR require atleast two Backup HAs always maintained on the home
   link. It is unlikely that the both Backup HAs fail at the same time.
   There could be more than two Backup HAs but it depends on the
   application requirement.

   If the failed HA is Backup HA then the Active HA will make an
   Inactive HA as another Backup HA by sending MCUR message to it and
   receiving MCURe message in response. This newly added Backup HA will
   then start sending Router Advertisements by setting the 'B' bit along
   with the 'H' bit.

   Figure 8 shows the failure of Backup HA_5 as the result of which
   Active HA_4 sends MCUR message to Inactive HA_6 in order to make it
   as Backup HA_6 as shown in figure 9


       Foreign Network                         Home Link
      ...................            .................................
      .                 .            .                               .
      .      +----+     .            .                    +--------+ .
      .      |    |     .            .                    | Active | .
      .      | MN |     .            .                    |  HA_4  | .
      .      |    |     .            .                    +--------+ .
      .      +----+     .            .                   \       /   .
      .                 .            .  +--------+        +\----/--+ .
      ...................            .  | Backup |        | Backup | .
                                     .  |  HA_2  |        |  HA_5  | .
                                     .  +--------+        +--/--\--+ .
                                     .                      /    \   .
                                     .  +--------+        +--------+ .
                                     .  |  HA_3  |        |  HA_6  | .
                                     .  |        |        |        | .
                                     .  +--------+        +--------+ .
                                     .................................

                   Figure 8: Failure of the Backup HA_5













Faizan.                  Expires October, 2004                 [Page 12]


Internet-Draft               VHAR Protocol                   April, 2004


       Foreign Network                         Home Link
      ...................            .................................
      .                 .            .                               .
      .      +----+     .            .                    +--------+ .
      .      |    |     .            .                    | Active | .
      .      | MN |     .            .                    |  HA_4  | .
      .      |    |     .            .                    +--------+ .
      .      +----+     .            .                         |     .
      .                 .            .  +--------+             |     .
      ...................            .  | Backup |        MCUR |     .
                                     .  |  HA_2  |             |     .
                                     .  +--------+             |     .
                                     .                         V     .
                                     .  +--------+        +--------+ .
                                     .  |  HA_3  |        | Backup | .
                                     .  |        |        |  HA_6  | .
                                     .  +--------+        +--------+ .
                                     .................................

        Figure 9: Recovery from the failure of the Backup HA_5


       ......................................
  MN   . HA_1  HA_2  HA_3  HA_4  HA_5  HA_6 .
  |    .  |     |     |     |     |     |   . 0. HA_4 is Active,
  |    .  |     |     |     |     |     |   .    HA_2 and HA_5 are
  |    .  |     |     |     |     |     |   .    Backup HAs.
  |    .  |     |     |     |     |     |   .
  |    .  |<--------------------------->|   . 1. All the HAs
  |    .  |     |     |     |     |     |   .    multicast Router
  |    .  |     |     |     |     |     |   .    Advertisements.
  |    .  |     |     |     |     |     |   .
  |    .  |     |     |     |<--X-|--X->|   . 2. Backup HA_5 failed.
  |    .  |     |     |     |     |     |   .
  |    .  |-----|-----|-----|---->|<----|   . 3. All other HAs unicast
  |    .  |     |     |     |     |     |   .    Router Solicitations
  |    .  |     |     |     |     |     |   .    to HA_5.
  |    .  |     |     |     |     |     |   .
  |    .  |     |     |     |---------->|   . 4. Active HA_4 sent
  |    .  |     |     |     |     |     |   .    MCUR to Inactive HA_6
  |    .  |     |     |     |     |     |   .    to make it Backup HA_6.
  |    .  |     |     |     |     |     |   .
  |    .  |     |     |     |<----------|   . 5. HA_6 sent MCURe to
  |    .  |     |     |     |     |     |   .    Active HA_4 and became
  |    .  |     |     |     |     |     |   .    Backup HA_6.
       ......................................

  Figure 10: VHAR Backup HA Failure Detection and Recovery Signal Flow



Faizan.                  Expires October, 2004                 [Page 13]


Internet-Draft               VHAR Protocol                   April, 2004


   The Signal flows shown above indicate that the failure detection and
   recovery mechanism are completely transparent to the MN which is
   required to keep the service interruption time minimal. Moreover
   there is no operational burden on the MN. All the messages are
   exchanged on the home link only. This also helps reducing the message
   overhead on the air interface.


5. Security Issues in VHAR

5.1 IPsec SAs Synchronization among Home Agents

   As discussed in the HA reliability problem statement draft [7],
   re-establishment of IPsec SAs between the MN and the new HA after the
   failure of MN's serving HA is problematic. To encounter this problem,
   VHAR does not involve MN in this re-establishment of IPsec SAs at
   all. This is possible by synchronizing the existing IPsec SAs with
   the Backup HAs on the link.

   VHAR requires that initially IPsec SAs are always established
   dynamically or manually configured in the Active HA which will
   synchronize with the Backup HAs. Active HA will send SP Synch message
   to the Backup HAs when a new IPsec SA gets established dynamically or
   manually configured or any parameter, except Sequence Number Counter
   and Anti-reply Window, gets updated or a new Backup HA is assigned by
   it as shown in figure 11. The SP Synch message is acknowledged with
   SP Reply message. When the Sequence Number and Anti-Reply Window
   parameters are changed in the SA Database (SAD) then the Active HA
   will send SeqNo Synch message two times to the Backup HAs. This
   message is not acknowledged. This is done to minimize the traffic
   flow.
   .
5.2 Correct Ordering of Binding Updates

   During the Home Registration process, the Active HA send MCUR
   messages to the Backup HAs which contain complete mobility binding
   information including the sequence number. This helps keeping the
   sequence number information of binding updates protected in case of
   Active HA failure and solves the correct ordering problem.












Faizan.                  Expires October, 2004                 [Page 14]


Internet-Draft               VHAR Protocol                   April, 2004


         Foreign Network                         Home Link
      ...................            .................................
      .                 .            .                               .
      .      +----+     .            .  +--------+ SP Synch +--------+ .
      .      |    |     .            .  | Active |--------->| Backup | .
      .      | MN |     .            .  |  HA_1  |-------   |  HA_4  | .
      .      |    |     .            .  +--------+      |   +--------+ .
      .      +----+     .            .          SP Synch|              .
      .                 .            .  +--------+      |   +--------+ .
      ...................            .  |  HA_2  |      |   | Backup | .
                                     .  |        |      ->  |  HA_5  | .
                                     .  +--------+          +--------+ .
                                     .                                 .
                                     .  +--------+          +--------+ .
                                     .  |  HA_3  |          |  HA_6  | .
                                     .  |        |          |        | .
                                     .  +--------+          +--------+ .
                                     ...................................

                  Figure 11: VHAR IPsec SA Synchronization


6. New ICMP Messages

6.1 Modified Router Advertisement Message

   The Router Advertisement messages as defined in Mobile IPv6 are sent
   among HAs to maintain their HALs. The Source and Destination address
   fields of the IPv6 header MUST be set to sender's link-local unicast
   address and multicast address respectively.

   VHAR modifies the format of the Router Advertisement message by the
   addition of two flag bits to indicate the status of sending HA. Also
   the Reserved field is changed. Router Advertisement 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cur Hop Limit |M|O|H|A|B|Reser|       Router Lifetime         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Reachable Time                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Retrans Timer                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-


Faizan.                  Expires October, 2004                 [Page 15]


Internet-Draft               VHAR Protocol                   April, 2004


   This format represents the following changes over the Router
   Advertisement message defined in Mobile IPv6 [1]

   Active HA bit (A)

           The Active HA bit (A) is set to indicate that the sender of
           this message is functioning as Active HA on the link.

   Backup HA bit (B)

           The Backup HA bit (B) is set to indicate that the sender of
           this message is functioning as Backup HA on the link.

   Reserved (Reser)

           Reduced from a 5-bit field to a 3-bit field to account for
           the addition of the above bits.

6.2 MN Release Request Message

   The MN Release Request message is sent by the Active HA to another HA
   at which MN is currently registered. The purpose of this message is
   to request de-registration of the MN's binding at its current HA. The
   Source and Destination address fields of the IPv6 header MUST be set
   to sender's and receiver's unicast link-local addresses.

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Home Address                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

           161 (To Be Assigned by IANA)






Faizan.                  Expires October, 2004                 [Page 16]


Internet-Draft               VHAR Protocol                   April, 2004


   Code

           0

   Checksum

           The ICMP checksum [6].

   Identifier

           An identifier to aid in matching MN Release Reply message to
           this MN Release Request message.

   Reserved

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

   Home Address

           The Home Address that was contained in the Home Address
           destination option of BU.

6.3 MN Release Reply Message

   The MN Release Reply message is sent by the current HA of the MN to
   the Active HA. The purpose of this message is to confirm the
   de-registration of the MN at its current HA. The Source and
   Destination address fields of the IPv6 header MUST be set to sender's
   and receiver's unicast link-local addresses.

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

           162 (To Be Assigned by IANA)

   Code

           0





Faizan.                  Expires October, 2004                 [Page 17]


Internet-Draft               VHAR Protocol                   April, 2004


   Checksum

           The ICMP checksum [6].

   Identifier

           The identifier from the invoking MN Release Request message.

   Reserved

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

6.4 MN Context Update Request Message

   The MN Context Update Request message is sent by the Active HA to a
   Backup HA or an Inactive HA. The purpose of this message is to
   request the Backup HA to store the binding of the MN. In case when
   the receiver is Inactive HA the purpose of this message is to make it
   Backup HA. Source and Destination address fields of the IPv6 header
   MUST be set to sender's and receiver's unicast link-local addresses.

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data..
   +-+-+-+-+


   Type

           163 (To Be Assigned by IANA)

   Code

           0

   Checksum

           The ICMP checksum [6].

   Identifier

           An identifier to aid in matching MN Context Update Reply
           message to this MN Context Update Request message.


Faizan.                  Expires October, 2004                 [Page 18]


Internet-Draft               VHAR Protocol                   April, 2004



   Reserved

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

   Data
           Data field includes the binding information for a single or
           multiple MNs. It has the following format.

           Home Address(128 bits), Care-of Address(128-bits),
           lifetime(16 bits), Flag(1 bit), Sequence Number(16 bits),
           Usage Information(16 bits).

           This constitutes complete Binding Cache entry for a single
           MN. Data field could be composed of multiple Binding Cache
           entries, each separated by a blank. It is terminated by a
           terminator

6.5 MN Context Update Reply Message

   The MN Context Update Reply message is sent by the Backup HA to the
   Active HA. The purpose of this message is to acknowledge the storage
   of MN's binding. Source and Destination address fields of the IPv6
   header MUST be set to the unicast link-local addresses of the
   Backup HA and Active HA respectively.

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

           164 (To Be Assigned by IANA)

   Code

           0

   Checksum

           The ICMP checksum [6].





Faizan.                  Expires October, 2004                 [Page 19]


Internet-Draft               VHAR Protocol                   April, 2004


   Identifier

           The identifier from the invoking MN Context Update Request
           message.

   Reserved

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

6.6 SP Synch Message

   The SP Synch message is sent to synchronize the IPsec SAs among the
   Active HA and Backup HAs. The Source and Destination address fields
   of the IPv6 header MUST be set to sender's and receiver's unicast
   link-local addresses.

    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      |     Code      |            Checksum           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |         Number of SAs         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data...
   +-----------+


   Type

           165 (To Be Assigned by IANA)

   Code

           0

   Checksum

           The ICMP checksum [6].

   Identifier

           An identifier to aid in matching SP Reply message to this SP
           Synch message.

   Number of SAs

           This field represents number of SAs in the Data field.



Faizan.                  Expires October, 2004                 [Page 20]


Internet-Draft               VHAR Protocol                   April, 2004


   Data

           Data field include single or multiple SAs. Each is of fixed
           length. Data field is terminated by a terminator. Each SA
           follows the following format.

           Direction = 1 bit - (Outgoing =1,Incoming =0)
           Protocol = 4 bits - (MH =1, ICMP =2 etc)
           Interface = 3 bits - (IPv6 tunnel to Home Agent_1 =1 etc)
           IPsec Protocol = 1 bit - (ESP =1, AH =0)
           IPsec Mode = 1 bit - (Tunnel =1, Transport =0)
           SPI = 32 bits
           Source IP Address = 128 bits
           Destination IP Address = 128 bits
           Sequence Number Counter = 64 bits
           Anti-reply Window = 64 bits.

6.7 SP Reply Message

   The SP Reply message is sent to acknowledge the SP Synch message. The
   Source and Destination address fields of the IPv6 header MUST be set
   to sender's and receiver's unicast link-local addresses.

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

           166 (To Be Assigned by IANA)

   Code

           0

   Checksum

           The ICMP checksum [6].

   Identifier

           The identifier from the invoking SP Synch message.




Faizan.                  Expires October, 2004                 [Page 21]


Internet-Draft               VHAR Protocol                   April, 2004

   Reserved

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

6.8 SeqNo Synch Message

   The SeqNo Synch message is sent to synchronize the IPsec SA's
   Sequence Number and Anti-reply Window information among the
   Active HA and Backup HAs. The Source and Destination address fields
   of the IPv6 header MUST be set to sender's and receiver's unicast
   link-local addresses.

    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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SPI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Sequence Number                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Anti-reply Window                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

           167 (To Be Assigned by IANA)

   Code

           0

   Checksum

           The ICMP checksum [6].

   SPI

           SPI is included for IPsec SA lookup in the SAD.

   Sequence Number

           Sequence Number of the IPsec SA.



Faizan.                  Expires October, 2004                 [Page 22]


Internet-Draft               VHAR Protocol                   April, 2004


   Anti-reply Window

           Anti-reply Window of the IPsec SA. In case of outgoing IPsec
           SA this field is set to zero.


7. IANA Considerations

   This document defines four new ICMP messages

   -  MN Release Request Message

   -  MN Release Reply Message

   -  MN Context Update Request Message

   -  MN Context Update Reply Message

   -  SP Synch Message

   -  SP Reply Message

   -  SeqNo Synch Message


8. Security Considerations

   Security Considerations are discussed in section 6 of this draft.


References

   [1]  Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
        IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), August
        2003.

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

   [3]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [4]  Wakikawa, R., Devarapalli, V. and P.Thubert, "Inter Home Agents
        Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-00.txt (work in
        progress), October 2003.

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



Faizan.                  Expires October, 2004                 [Page 23]


Internet-Draft               VHAR Protocol                   April, 2004


   [6]  Conta, A. and S. Deering, "Internet Control Message Protocol
        (ICMPv6) for the Internet Protocol Version 6 (IPv6)
        Specification", RFC 2463, December 1998.

   [7]  Faizan, J., El-Rewini, H. and M.Khalil, "Problem Statement:Home
        Agent Reliability", draft-jfaizan-mipv6-ha-reliability-01.txt
        (work in progress), February 2004.

   [8]  Faizan, J., El-Rewini, H. and M.Khalil, "Virtual Home Agent
        Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-01.txt
        (work in progress), February 2004.


Authors' Addresses

   Jahanzeb Faizan
   Southern Methodist University
   Computer Science and Engineering Department.
   6425 N Ownby Dr., SIC #300D
   Dallas, TX, 75205, USA

   Phone +1 214-768-3712, Fax +1 214-768-3085
   EMail: jfaizan@smu.edu


   Hesham El-Rewini
   Southern Methodist University
   Computer Science and Engineering Department.
   6425 N Ownby Dr., SIC #306C
   Dallas, TX, 75205, USA

   Phone +1 214-768-3278, Fax +1 214-768-3085
   EMail: rewini@engr.smu.edu


   Mohammad Khalil
   Nortel Networks
   Richardson, TX, USA

   Phone: +1 972-685-0564
   EMail: mkhalil@nortelnetworks


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in



Faizan.                  Expires October, 2004                 [Page 24]


Internet-Draft               VHAR Protocol                   April, 2004


   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary

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.


Acknowledgment

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




Faizan.                  Expires October, 2004                 [Page 25]

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