Mobile IP Working Group Jahanzeb Faizan
Internet-Draft Hesham El-Rewini
Expires: June, 2004 Southern Methodist University
Mohammad Khalil
Nortel Networks
December, 2003
Virtual Home Agent Reliability Protocol (VHAR)
draft-jfaizan-mipv6-vhar-00.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 June, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Current specification of Mobile-IPv6 [1] does not provide Home Agent
Reliability and Load Balancing in the Home Network [12]. The aim of
this draft is to introduce Virtual Home Agent Reliability Protocol as
the solution. In this protocol multiple Home Agents and Recovery Home
Agents coexist on the same subnet and share the same 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 June, 2004 [Page 1]
Internet-Draft VHAR Protocol December, 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . .. . . . . . . . . . . . . . . . . . . . . . 3
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Virtual Home Agent Reliability Protocol Overview . . . . . . . 5
4.1 Mobile Node Registration . . . . . . . . . . . . . . . . .6
4.2 VHAR Failure Detection and Recovery . . . . . . . . . . . 7
4.3 VHAR Load Balancing . . . . . . . . . . . . . . . . . . . 8
5. New ICMP Messages . . . . . . . . . . . . . . . . . . . . . . .9
5.1 VHAR Solicitation Message . . . . . . . . . . . . . . . . 9
5.2 VHAR Advertisement Message . . . . . . . . . . . . . . . .9
5.3 MN Release Request Message . . . . . . . . . . . . . . . 11
5.4 MN Release Reply Message . . . . . . . . . . . . . . . . 12
5.5 MN Context Update Request Message . . . . . . . . . . . .13
5.6 MN Context Update Reply Message . . . . . . . . . . . . .14
5.7 MN Context Migration Request Message . . . . . . . . . . 15
5.8 MN Context Migration Reply Message . . . . . . . . . . . 16
5.9 Change HA Request Message . . . . . . . . . . . . . . . .17
5.10 Change HA 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 June, 2004 [Page 2]
Internet-Draft VHAR Protocol December, 2003
1. Introduction
Mobile-IPv6 [1] is designed to allow a Mobile Node to change its
point of IP subnet attachment in the Internet at the network or IP
layer. The Mobile Node is always identified by it Home Address
regardless of its current network location. Its mobility is not
limited by conventional IP network boundaries. The Mobile-IPv6 system
consists of Mobile Node and Home Agent. Home Agent remains at
conventional IPv6 subnet called the Home Subnet and when the Mobile
Node is at the Home Subnet then the packets sent to it are routed
through conventional IPv6 [5] routing mechanism. When the Mobile Node
is not at Home Subnet it registers its remote point of attachment
address called Care of Address with the Home Agent. This allows Home
Agent to forward packets, addressed to the Mobile Node at its Home
Network, to its current location.
In Mobile-IPv6, Mobile Node registers and establish a connection
with only one Home Agent which provides continuous service to it. The
Mobile Node is reliant on this Home Agent for its connectivity. Thus
the Home Agent represents the possibility of a single point of
failure for Mobile-IPv6 network. A Home Agent may be responsible for
multiple Mobile Nodes on the Home Subnet. The failure of a single
Home Agent may then result in the loss of connectivity for numerous
Mobile Nodes located throughout the Internet. Thus the Home Agent and
Mobile Node taken together have a shared fate. A Mobile Node cannot
afford the loss of its Home Agent. To overcome this problem
Mobile-IPv6 allows deployment of multiple Home Agents on the Home
Subnet so that upon the failure of serving Home Agent, another Home
Agent can take over the functions of failed Home Agent and thus
provide continuous service to the Mobile Node(s) registered with
failed Home Agent. This transfer of service from the failed Home
Agent to a new working Home Agent 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 Home Agent 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].
Faizan. Expires June, 2004 [Page 3]
Internet-Draft VHAR Protocol December, 2003
Mobile-IPv6
Mobile IP for IPv6 [1]
Mobile Node
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 Mobile Node, used as
the permanent address of the Mobile Node. This address is
within the Mobile Node's Home Subnet. Conventional IPv6
routing mechanisms will deliver packets destined for a Mobile
Node's Home Address to its Home Subnet.
Home Network
A network, possibly virtual, having a network prefix matching
that of a Mobile Node's Home Address.
Home Agent
A router on a Mobile Node's Home Network which tunnels
datagrams for delivery to the Mobile Node when it is away
from home, and maintains current location information for the
Mobile Node.
Care of Address
A unicast routable address associated with a Mobile Node
while visiting a foreign network.
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.
Registration
The process during which a Mobile Node sends a Binding Update
to its Home Agent causing a binding for the Mobile Node to be
registered.
Faizan. Expires June, 2004 [Page 4]
Internet-Draft VHAR Protocol December, 2003
3. Related Work
HAHA [7] protocol provides Home Agent Reliability and Load Balancing
for Mobile-IPv6. In this protocol multiple Home Agents are provided
over different links and Mobile Node has to register its binding in
them. Mobile Node selects one of the Home Agents as its primary Home
Agent. Primary Home Agent or any other Home Agent can tunnel packets
from Correspondant Node to Mobile Node. On failure of the primary
Home Agent Mobile Node can switch its service to any other Home Agent
on any link. This protocol extends the fundamental specification of
the Home Agent by allowing it to exists outside its Home Network
which does not improve overall performance rather increases
operational complexity and message overhead. Also the failure of the
primary Home Agent is not transparent to the Mobile Node which
results in service interruption. HAHA does not encounter the problems
of delayed failure detection and IPsec Security Association with the
new Home Agent as discussed in [12]. Also Load Balancing among Home
Agents has been proposed in [13] but it does not provide Reliability
solution.
4. Virtual Home Agent Reliability Protocol Overview
Virtual Home Agent Reliability Protocol (VHAR) provide Home Agent
Reliability and Load Balancing in Mobile-IPv6 network. VHAR allows
multiple Home Agents on the same subnet. Some of these Home Agents
are referred as "Recovery Home Agents". They provide recovery
functionalities beside usual Home Agent functions. All the Home
Agents including Recovery Home Agents have exact same IP address
(referred as Home Agent Address) and only one of them is active on
the subnet at a particular instance of time, similar to the technique
used in VRRPv6 [8].
We will consider a basic deployment scenario where three Home Agents
(HA_1..3) and Recovery Home Agents(RHA_1..3) coexist on the same
subnet to provide continuous service to Mobile Node (MN). Currently
HA_1 is active and responsible for all the Mobile-IPv6 Home Agent
functions as defined in [1].
Faizan. Expires June, 2004 [Page 5]
Internet-Draft VHAR Protocol December, 2003
Foreign Network Home Subnet
................... ..............................
. . . .
. +----+ . . +-------+ +-------+ .
. |MN | .<==========>. | HA_1 | | RHA_1 | .
. | | . . +-------+ +-------+ .
. +----+ . . .
. . . +-------+ +-------+ .
................... . | HA_2 | | RHA_2 | .
. +-------+ +-------+ .
. .
. +-------+ +-------+ .
. | HA_3 | | RHA_3 | .
. +-------+ +-------+ .
..............................
Figure 1: VHAR Basic Deployment Scenario
4.1 Mobile Node Registration
When MN wants to register its Care of Address, it sends BU using Home
Address as the destination address. This BU will be intercepted by
the active HA which MAY perform Duplicate Address Detection[9] (DaD)
to know if this MN is already registered with any other HA or RHA on
the subnet. If it is registered then first active HA will send
"MN Release Request" message to the HA or RHA which is holding the
binding. In response, "MN Release Reply" message will be send to the
active HA which will then select a RHA as its backup and sends
"MN Context Update Request" message to it. In response to this
selected RHA will send "Mobile Node Context Update Reply" message to
the active HA. Upon receiving this it will send the BA message to MN.
Faizan. Expires June, 2004 [Page 6]
Internet-Draft VHAR Protocol December, 2003
......................................
MN . HA_1 HA_2 HA_3 RHA_1 RHA_2 RHA_3 .
| . | | | | | | .
|===>. | | | | | | . 1. Home Registration
| . | | | | | | .
| . |<--------------------------->| . 2. DaD by active HA_1.
| . | | | | | | . HA_3 has binding.
| . | | | | | | .
| . |---------->| | | | . 3. HA_1 sent to HA_3
| | | | | | | . MN Release Request.
| . | | | | | | .
| . |<----------| | | | . 4. HA_3 sent to HA_1
| . | | | | | | . MN Release Reply.
| . | | | | | | .
| . |---------------->| | | . 5. HA_1 sent to RHA_1
| . | | | | | | . MN Context Update
| . | | | | | | . Request.
| . | | | | | | .
| . |<----------------| | | . 6. RHA_1 sent to HA_1
| . | | | | | | . MN Context Update
| . | | | | | | . Reply.
| . | | | | | | .
|<======| | | | | | . 7. HA_1 sent BA to MN.
| . | | | | | | .
......................................
Figure 2: VHAR Mobile Node Registration Signal Flow
4.2 VHAR Failure Detection and Recovery
Each HA and RHA maintains a "Status List" to keep track of all the
working HAs and RHAs on the subnet. They send unsolicited multicast
"VHAR Advertisement" messages periodically on the subnet. Any new
HA or RHA added on the subnet starts sending and receiving the VHAR
Advertisements as it boots up. These VHAR Advertisements allow
maintaining the Status List.
When any HA or RHA fails on the subnet all other HAs and RHAs on the
subnet will not receive VHAR Advertisements from it and upon timeout
they will silently delete the entry for it from the Status List. But
when the active HA fails they will send unicast "VHAR Solicitation"
messages to it in order to confirm its failure and if they don't
receive any VHAR Advertisement message from it they will delete its
entry from the Status List. Now the RHA selected by the failed HA
will serve as the active HA. It will also select its RHA in the same
manner as the failed active HA selected its RHA. It could also select
another HA as the active HA if it is over loaded by sending
Faizan. Expires June, 2004 [Page 7]
Internet-Draft VHAR Protocol December, 2003
"MN Context Migration Request" message to it and receiving
"MN Context Migration Reply" message in response. This will also
provide Load Balancing among the RHAs and HAs.
The failure detection and recovery mechanisms discussed above is
completely transparent to the MN which is required to keep the
service interruption time minimal.
......................................
MN . HA_1 HA_2 HA_3 RHA_1 RHA_2 RHA_3 .
| . | | | | | | .
| . | | | | | | .
| . |<--------------------------->| . 1. All the HAs and RHAs
| . | | | | | | . multicast VHAR
| . | | | | | | . Advertisements.
| . | | | | | | .
| . |--X->| | | | | . 2. Active HA_1 failed.
| . | | | | | | .
| . |<----|-----|-----|-----|-----| . 3. All other HAs and RHAs
| . | | | | | | . unicast VHAR
| . | | | | | | . Solicitations to HA_1.
| . | | | | | | .
| . | |<----------| | | . 4. RHA_1 ask HA_2 to
| . | | | | | | . become active by
| . | | | | | | . sending MN Context
| . | | | | | | . Migration Request.
| . | | | | | | .
| . | |---------->| | | . 5. HA_2 sent MN Context
| . | | | | | | . Migration Reply to
| . | | | | | | . RHA_1 and became
| . | | | | | | . active.
| . | | | | | | .
......................................
Figure 3: VHAR Failure Detection and Recovery Signal Flow
4.3 VHAR Load Balancing
If the active HA is over loaded it could make another HA as active by
sending "Change Active HA Request" message to it which could respond
by sending "Change Active HA Reply" message. That's how Load
Balancing is achieved among different HAs.
Faizan. Expires June, 2004 [Page 8]
Internet-Draft VHAR Protocol December, 2003
......................................
MN . HA_1 HA_2 HA_3 RHA_1 RHA_2 RHA_3 .
| . | | | | | | .
| . |---->| | | | | . 1. Active HA_1 wants to
| . | | | | | | . make HA_2 active. It
| . | | | | | | . sent Change Active HA
| . | | | | | | . Request to HA_2.
| . | | | | | | .
| . |<----| | | | | . 2. HA_2 became active. It
| . | | | | | | . sent Change Active HA
| . | | | | | | . Reply to HA_1.
| . | | | | | | .
......................................
Figure 4: VHAR Load Balancing Signal Flow
5. New ICMP Messages
5.1 VHAR Solicitation Message
The VHAR Solicitation message is used to confirm the failure of the
active HA or the RHA selected by it. Source and Destination address
fields of the IPv6 header MUST be set to sender's and receiver's
link-local unicast 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
The fields of a VHAR Solicitation message are same as the Router
Solicitation message [10] except for the Type field which is 160
(To Be Assigned by IANA).
5.2 VHAR Advertisement Message
The VHAR Advertisement messages are sent among HAs and RHAs to
maintain their Status Lists. The Source and Destination address
fields of the IPv6 header MUST be set to sender's link-local unicast
address and multicast address respectively.
Faizan. Expires June, 2004 [Page 9]
Internet-Draft VHAR Protocol December, 2003
VHAR modifies the format of the Router Advertisement message defined
in Mobile-IPv6 [1] by the addition of three flag bits to indicate the
status of sender sending the Advertisement message. Also the Type
and Reserved fields are changed. VHAR 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|R|S|Res| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over the Router
Advertisement message defined in Mobile-IPv6 [1]
Type
161 (To be Assigned by IANA)
Active HA bit(A)
The Active HA bit (A) is set to indicate that the sender of
this message is also functioning as active HA on this link.
RHA bit (R)
The RHA bit (R) is set to indicate that the sender of this
message is also functioning as RHA on this link.
Selected RHA bit (S)
The Selected RHA bit (S) is set to indicate that the sender
of this message is also functioning as the selected RHA for
the active HA on this link.
Reserved (Res)
Reduced from a 5-bit field to a 2-bit field to account for
the addition of the above bits.
Faizan. Expires June, 2004 [Page 10]
Internet-Draft VHAR Protocol December, 2003
5.3 MN Release Request Message
The MN Release Request message is sent by the active HA to the HA or
RHA, 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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
162 (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 June, 2004 [Page 11]
Internet-Draft VHAR Protocol December, 2003
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.
Care of Address
Specified by the BU from MN in the Source Address field of
the IPv6 header.
5.4 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
163 (To Be Assigned by IANA)
Code
0
Checksum
The ICMP checksum [11].
Identifier
The identifier from the invoking MN Release Request message.
Faizan. Expires June, 2004 [Page 12]
Internet-Draft VHAR Protocol December, 2003
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.5 MN Context Update Request Message
The MN Context Update Request message is sent by the active HA to the
selected RHA. The purpose of this message is to request RHA to store
the binding of MN. 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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
164 (To Be Assigned by IANA)
Code
0
Checksum
The ICMP checksum [11].
Faizan. Expires June, 2004 [Page 13]
Internet-Draft VHAR Protocol December, 2003
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.
Home Address
The Home Address that was contained in the Home Address
destination option of BU.
Care of Address
Specified by the BU from MN in the Source Address field of
the IPv6 header.
5.6 MN Context Update Reply Message
The MN Context Update Reply message is sent by the selected RHA 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
active HA and selected RHA 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
165 (To Be Assigned by IANA)
Code
0
Checksum
The ICMP checksum [11].
Faizan. Expires June, 2004 [Page 14]
Internet-Draft VHAR Protocol December, 2003
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.
5.7 MN Context Migration Request Message
The MN Context Migration Request message is sent by the selected
RHA of the failed active HA to another HA. The purpose of this
message is to assign a new active HA after the active HA failure.
Source and Destination address fields of the IPv6 header MUST be set
to the unicast link-local addresses of the selected RHA and the new
active HA.
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
166 (To Be Assigned by IANA)
Faizan. Expires June, 2004 [Page 15]
Internet-Draft VHAR Protocol December, 2003
Code
0
Checksum
The ICMP checksum [11].
Identifier
An identifier to aid in matching MN Context Migration Reply
message to this MN Context Migration 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.
Care of Address
Specified by the BU from MN in the Source Address field of
the IPv6 header.
5.8 MN Context Migration Reply Message
The MN Context Migration Reply message is sent by the new HA to the
selected RHA of the failed active HA. The purpose of this message is
to acknowledge the request of selected RHA for the sender to serve as
active HA. Source and Destination address fields of the IPv6 header
MUST be set to the unicast link-local addresses of the new active
HA and the selected RHA 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Faizan. Expires June, 2004 [Page 16]
Internet-Draft VHAR Protocol December, 2003
Type
167 (To Be Assigned by IANA)
Code
0
Checksum
The ICMP checksum [11].
Identifier
The identifier from the invoking MN Context Migration Request
message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.9 Change HA Request Message
The Change HA Request message is sent by the active HA to an another
HA. The purpose of this message is to request the HA to become active
for the subnet. It is used to share the load among HAs. Source and
Destination address fields of the IPv6 header MUST be set to the
unicast link-local addresses of the current active HA and new active
HA.
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
168 (To Be Assigned by IANA)
Code
0
Faizan. Expires June, 2004 [Page 17]
Internet-Draft VHAR Protocol December, 2003
Checksum
The ICMP checksum [11].
Identifier
An identifier to aid in matching Change HA Reply message to
this Change HA Request message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.10 Change HA Reply Message
The Change HA Reply message is sent by the new active HA to the
previously active HA. The purpose of this message is to acknowledge
the request for becoming active HA for the subnet. Source and
Destination address fields of the IPv6 header MUST be set to the
unicast link-local addresses of the new active HA and the previously
active HA respectively.
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
169 (To Be Assigned by IANA)
Code
0
Checksum
The ICMP checksum [11].
Identifier
The identifier from the invoking Change HA Request message.
Faizan. Expires June, 2004 [Page 18]
Internet-Draft VHAR Protocol December, 2003
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
6. IANA Considerations
This document defines ten new ICMP messages
- VHAR Solicitation Message
- VHAR Advertisement Message
- MN Release Request Message
- MN Release Reply Message
- MN Context Update Request Message
- MN Context Update Reply Message
- MN Context Migration Request Message
- MN Context Migration Reply Message
- Change HA Request Message
- Change HA 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
Faizan. Expires June, 2004 [Page 19]
Internet-Draft VHAR Protocol December, 2003
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.
[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-00.txt
(work in progress), November 2003.
[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.
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
Faizan. Expires June, 2004 [Page 20]
Internet-Draft VHAR Protocol December, 2003
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
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
Faizan. Expires June, 2004 [Page 21]
Internet-Draft VHAR Protocol December, 2003
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 June, 2004 [Page 22]