Mobile IP Working Group Jahanzeb Faizan
Internet-Draft Hesham El-Rewini
Expires: August, 2004 Southern Methodist University
Mohammad Khalil
Nortel Networks
February, 2004
Virtual Home Agent Reliability Protocol (VHAR)
draft-jfaizan-mipv6-vhar-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.
This Internet-Draft will expire on August, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Current specifications of Mobile IPv6 does not provide Home Agent
Reliability and Load Balancing 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 August, 2004 [Page 1]
Internet-Draft VHAR Protocol February, 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 . . . . . . . . . . . . . . . . .7
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. New ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Modified Router Advertisement Message. . . . . . . . . . 14
5.3 MN Release Request Message . . . . . . . . . . . . . . . 15
5.4 MN Release Reply Message . . . . . . . . . . . . . . . . 15
5.5 MN Context Update Request Message . . . . . . . . . . . .17
5.6 MN Context Update Reply Message . . . . . . . . . . . . .18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . .19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .20
Intellectual Property and Copyright Statements . . . . . . . .21
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .22
Faizan. Expires August, 2004 [Page 2]
Internet-Draft VHAR Protocol February, 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[5] 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 [12] 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 provide HA Reliability and Load Balancing 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 August, 2004 [Page 3]
Internet-Draft VHAR Protocol February, 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).[5]
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 August, 2004 [Page 4]
Internet-Draft VHAR Protocol February, 2004
3. Related Work
HAHA [7] protocol provides HA Reliability and Load Balancing 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 itself 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
establish IPsec Security Associations with all its HAs. Load
Balancing among HAs has been proposed in [13] but it does not provide
Reliability solution.
4. Virtual Home Agent Reliability Protocol Overview
Virtual HA Reliability Protocol (VHAR) works along with Mobile IPv6
at the network layer and provide HA Reliability and Load Balancing.
It uses multiple HAs on the same home link. All the HAs have exact
same Global IP address (referred as Home Agent Address) and only one
of them is active on the home link at a particular instance of time,
similar to the technique used in VRRPv6 [8].
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 MN.
Currently HA_1 is active and responsible for all the Mobile IPv6 HA
functions as defined in [1].
Faizan. Expires August, 2004 [Page 5]
Internet-Draft VHAR Protocol February, 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
Each HA on the home link could be in one of the following states.
Active HA
Active HA is the one which is responsible for all the HA tasks
as defined in Mobile IPv6 [1]. There could be only single Active
HA on the link at a particular instance of time. It will send
Router Advertisements on the link by setting 'A' bit along with
the 'H' bit.
Backup HA
Backup HA is the one which is not performing any HA task except
storing the mobility bindings in the Binding Cache. There should
be atleast two Backup HAs always maintained on the home link.
Each backup HA will send Router Advertisements on the link by
setting 'B' bit along with the 'H' bit.
Inactive HA
Inactive HA is the one which is 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 home link are Inactive
HAs. They send Router Advertisements on the link by setting only
the 'H' bit.
Faizan. Expires August, 2004 [Page 6]
Internet-Draft VHAR Protocol February, 2004
+-------------+
| |
| 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, one of the two Backup HAs will become
Active HA.
Transition 4
When any Backup HA receives MN Context Update Request Message
from the Active HA, it will remain as Backup HA.
4.3 Mobile Node Registration
When MN wants to register its Care-of Address, it sends Binding
Update(BU) using the Home Address as the destination address. This BU
will be intercepted by the Active HA_1(in our scenario) which MAY
perform Duplicate Address Detection[9] (DaD) to know if this 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"
Faizan. Expires August, 2004 [Page 7]
Internet-Draft VHAR Protocol February, 2004
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
then select two HAs, HA_4 and HA_5 on the home 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 August, 2004 [Page 8]
Internet-Draft VHAR Protocol February, 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 home link. VHAR
protocol 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.
As defined in Mobile IPv6 each HA sends unsolicited multicast Router
Advertisement messages periodically on the link. 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). Thus each HA on the link knows about the Active HA,
Backup HAs and Inactive HAs on the home link.
Faizan. Expires August, 2004 [Page 9]
Internet-Draft VHAR Protocol February, 2004
When any HA on the link fails all other HAs will not receive Router
Advertisement messages from it and upon timeout they will send
unicast Router Solicitation messages [10] 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 to it 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 August, 2004 [Page 10]
Internet-Draft VHAR Protocol February, 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 August, 2004 [Page 11]
Internet-Draft VHAR Protocol February, 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 also 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 August, 2004 [Page 12]
Internet-Draft VHAR Protocol February, 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 August, 2004 [Page 13]
Internet-Draft VHAR Protocol February, 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. New ICMP Messages
5.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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 this 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 this link.
Faizan. Expires August, 2004 [Page 14]
Internet-Draft VHAR Protocol February, 2004
Reserved (Reser)
Reduced from a 5-bit field to a 3-bit field to account for
the addition of the above bits.
5.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)
Code
0
Checksum
The ICMP checksum [11].
Identifier
An identifier to aid in matching MN Release Reply message to
this MN Release Request message.
Faizan. Expires August, 2004 [Page 15]
Internet-Draft VHAR Protocol February, 2004
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.
5.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
Checksum
The ICMP checksum [11].
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.
Faizan. Expires August, 2004 [Page 16]
Internet-Draft VHAR Protocol February, 2004
5.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 [11].
Identifier
An identifier to aid in matching MN Context Update Reply
message to this 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.
Data
Data field includes the binding information for a single or
multiple MNs. It has the following format.
Faizan. Expires August, 2004 [Page 17]
Internet-Draft VHAR Protocol February, 2004
Home Address(64 bits), Care-of Address(64-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
5.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 [11].
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.
Faizan. Expires August, 2004 [Page 18]
Internet-Draft VHAR Protocol February, 2004
6. 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
7. Security Considerations
Security Considerations are not discussed in 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] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in
progress), June 2003.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Wakikawa, R., Devarapalli, V. and P.Thubert, "Inter Home Agents
Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-00.txt (work in
progress), October 2003.
[8] Hinden, R., "Virtual Router Redundancy Protocol",
draft-ietf-vrrp-spec-v2-09.txt.(work in progress), August 2003.
Faizan. Expires August, 2004 [Page 19]
Internet-Draft VHAR Protocol February, 2004
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[10] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[11] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[12] 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.
[13] Deng, H., Zhang, R., Huang, X. and K.Zhang, "Load Balance for
Distributed Home Agents in Mobile IPv6", draft-deng-mip6-ha-
loadbalance-00.txt (work in progress), November 2003.
[14] Faizan, J., El-Rewini, H. and M.Khalil, "Virtual Home Agent
Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-00.txt
(work in progress), November 2003.
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
Faizan. Expires August, 2004 [Page 20]
Internet-Draft VHAR Protocol February, 2004
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
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.
Faizan. Expires August, 2004 [Page 21]
Internet-Draft VHAR Protocol February, 2004
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 August, 2004 [Page 22]