One document matched: draft-ietf-mip6-hareliability-00.txt
MIP6 Working Group R. Wakikawa (Editor)
Internet-Draft Keio University
Expires: December 21, 2006 June 19, 2006
Home Agent Reliability Protocol
draft-ietf-mip6-hareliability-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The home agent can be a single point of failure when Mobile IPv6 is
used in a system. It is critical to provide home agent reliability
in the event of a home agent crashing or becoming unavailable. This
would allow another home agent to take over and continue providing
service to the mobile nodes. This document describes the problem
scope briefly and provides a mechanism for achieving home agent
reliability. Note that this document is not completed yet. DT is
still discussing some items.
Wakikawa (Editor) Expires December 21, 2006 [Page 1]
Internet-Draft Home Agent Reliability June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
4. Goals for the Solution . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 10
5.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 11
5.3. Failure Detection and Home Agent Management . . . . . . . 13
6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 16
6.1.1. Home Agent Hello Request Message . . . . . . . . . . . 16
6.1.2. Home Agent Hello Message . . . . . . . . . . . . . . . 17
6.1.3. State Synchronization Request Message . . . . . . . . 20
6.1.4. State Synchronization Message . . . . . . . . . . . . 21
6.1.5. Home Agent SwitchOver Request Message . . . . . . . . 22
6.1.6. Home Agent SwitchOver Reply Message . . . . . . . . . 23
6.1.7. Home Agent SwitchBack Request Message . . . . . . . . 23
6.1.8. Home Agent SwitchBack Reply Message . . . . . . . . . 24
6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 25
6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 25
6.2.2. Binding Cache Information Option . . . . . . . . . . . 25
6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 27
6.2.4. Vendor Specific Information Option . . . . . . . . . . 27
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 29
7.1. Home Agent Configuration . . . . . . . . . . . . . . . . . 29
7.2. Hello messages Manipulation . . . . . . . . . . . . . . . 30
7.2.1. Sending Hello Request . . . . . . . . . . . . . . . . 31
7.2.2. Receiving Hello Request . . . . . . . . . . . . . . . 31
7.2.3. Sending Hello . . . . . . . . . . . . . . . . . . . . 31
7.2.4. Receiving Hello . . . . . . . . . . . . . . . . . . . 32
7.3. Failure Detection . . . . . . . . . . . . . . . . . . . . 32
7.4. Active Home Agent Change . . . . . . . . . . . . . . . . . 33
7.5. Processing State Synchronization Messages . . . . . . . . 34
7.5.1. Sending State Synchronization Request . . . . . . . . 34
7.5.2. Receiving State Synchronization Request . . . . . . . 34
7.5.3. Sending State Synchronization . . . . . . . . . . . . 34
7.5.4. Receiving State Synchronization . . . . . . . . . . . 35
7.6. Processing Home Agent SwitchOver Messages . . . . . . . . 35
7.6.1. Sending Home Agent SwitchOver Request . . . . . . . . 35
7.6.2. Sending Home Agent SwitchOver Reply . . . . . . . . . 36
Wakikawa (Editor) Expires December 21, 2006 [Page 2]
Internet-Draft Home Agent Reliability June 2006
7.6.3. Receiving Home Agent SwitchOver Reply . . . . . . . . 36
7.7. Processing Home Agent SwitchBack Messages . . . . . . . . 36
7.7.1. Sending Home Agent SwitchBack Request . . . . . . . . 36
7.7.2. Sending Home Agent SwitchBack Reply . . . . . . . . . 37
7.7.3. Receiving Home Agent SwitchBack Reply . . . . . . . . 37
7.8. Sending Home Agent Switch Message . . . . . . . . . . . . 37
8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 38
8.1. Standby Home Agent Addresses Discovery . . . . . . . . . . 38
8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 38
8.3. Receiving Home Agent Switch message . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47
Wakikawa (Editor) Expires December 21, 2006 [Page 3]
Internet-Draft Home Agent Reliability June 2006
1. Introduction
In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a
bi-directional tunnel with their Home Agents for all traffic with the
correspondent nodes. A home agent on the home link maintains a
binding cache entry for each mobile node and uses the binding cache
entry to route any traffic meant for the mobile node or the mobile
network. If the mobile node is not on the home link and does not
have a binding cache entry at the home agent, it is neither reachable
at its home address nor able to setup new sessions with its home
address. If a home agent loses the binding cache state, due to
failure or some other reason, it results in loss of service for the
mobile nodes.
It would be very beneficial to provide high availability and
redundancy for a home agent so that the mobile nodes can avail of
uninterrupted service even when one home agent crashes or loses
state.
Wakikawa (Editor) Expires December 21, 2006 [Page 4]
Internet-Draft Home Agent Reliability June 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3].
In this document, the term mobile node refers to both a mobile node
[1] and a mobile router [2].
Some of the mobility related terms used in this document are defined
in [1] and [7]. In addition or in replacement of these, the
following terms are defined or redefined:
Active Home Agent
A home agent that is currently serving the mobile nodes
Standby Home Agent
A home agent which will serve the mobile nodes when the active
home agent fails.
Failed Home Agent
A home agent that is not available due to hardware or software
failure, system maintenance, etc.
Redundant Home Agent Set
A pair of an Active Home Agent and Standby Home Agent(s). The
Group Identifier is introduced to identify a Redundant Home Agent
set. The Group ID is exchanged by Hello messages.
Binding Synchronization
Synchronization of binding cache entries within the redundant home
agent set
Home Agent Preference
This preference value is defined for DHAAD in RFC3775. This
protocol uses this preference value for home agent selection when
an active home agent is failed. However, an operator can also
define an independent value only for home agent reliability
protocol if the operator wants to have different preference value
for DHAAD and home agent reliability protocol. A Home Agent
SHOULD NOT use the same preference value of other Home Agents for
this protocol.
Wakikawa (Editor) Expires December 21, 2006 [Page 5]
Internet-Draft Home Agent Reliability June 2006
Home Agent Hard Switch
The Home Agent Hard Switch is used when IPsec states cannot be
synchronized between an active and a Standby Home Agent. In this
case each home agent negotiates independent IPsec SAs with a
mobile node. The mobile node will be notified to change its home
agent to one of Standby Home Agent.
Home Agent Virtual Switch
In this case IPsec states are synchronized within the redundant
home agent set. A given mobile node has only one IPsec SA and one
mobility binding. Upon failure of the Active Home Agent, the
Standby Home Agent begins to serve the mobile nodes without having
to notify the mobile nodes about the failure event in the network.
Wakikawa (Editor) Expires December 21, 2006 [Page 6]
Internet-Draft Home Agent Reliability June 2006
3. Problem Statement
In Mobile IPv6 base specification, a mobile node registers and
establishes a connection with only one Home Agent. Thus the Home
Agent represents the possibility of a single point of failure for
Mobile IPv6. A Home Agent may be responsible for multiple mobile
nodes on the home link. The failure of the Home Agent may then
result in the loss of connectivity for numerous mobile nodes located
throughout the Internet. To overcome this problem, Mobile IPv6
allows deployment of multiple Home Agents on the home link so that
upon the failure of serving Home Agent, mobile node can re-establish
its connection through the new Home Agent. However, base Mobile IPv6
specification does not address the Home Agent failover and dynamic
transfer of service from one Home agent to another. This transfer of
service from the Failed Home Agent to a new working Home Agent
requires co-ordination or pre-configuration among the Home agents
regarding security association, transfer of mobile-node related
binding and other service information for the reliable Mobile IPv6
service in a deployment scenario.
Wakikawa (Editor) Expires December 21, 2006 [Page 7]
Internet-Draft Home Agent Reliability June 2006
4. Goals for the Solution
For the home agent reliability solution, we define the following
requirements.
Reliable Home agent service
Multiple home agents are available for a home prefix and one of
them is actively serves the mobile nodes. A standby home agent
takes over when the Active Home Agent becomes unavailable. The
transfer of the MN-HA association should be transparent to the
application and should not take longer than care-of-addresses
update procedure described in the Mobile IPv6 [1].
Availability of a redundant home agent set
Availability of an Active Home Agent address and a standby Home
Agent address at the bootstrapping period to Mobile Node is
assumed.
State Synchronization
The information for mobile nodes must be synchronized between an
Active Home Agent and Standby Home Agents. The information is
Binding Cache, IPsec/IKE states, AAA information, vendor specific
information.
Consideration of IPsec/IKE transfer
An Active Home Agent maintains several IPsec and IKE states for
mobile nodes. These states are synchronized within the redundant
Home Agent set. The details are described in Section 9.
Secured Message Exchanges
The messages used between the home agents to transfer binding
cache information MAY be authenticated and encrypted.
Failure Detection
Redundant home agents must actively check for possible failure of
an Active Home Agent. Periodic hello messages should be used to
detect Active Home Agent's service availability
Failure Notification
Wakikawa (Editor) Expires December 21, 2006 [Page 8]
Internet-Draft Home Agent Reliability June 2006
If necessary a mobile node is notified about the active home agent
failure by the Standby Home Agent in Home Agent Hard Switch mode
of operation
Wakikawa (Editor) Expires December 21, 2006 [Page 9]
Internet-Draft Home Agent Reliability June 2006
5. Protocol Overview
This specification provides two modes for home agent local
reliability.
o Home Agent Virtual Switch: In this mode the active and the
redundant home agents are all accessible through the same IP
address. IPsec/IKE states must be synchronized between the active
and a redundant home agent(s). The mechanism used to synchronize
IPsec state is currently considered out of scope for this document
and not described here. In this mode, a mobile node always
establishes IPsec SAs only with the Active Home Agent. The IPsec
state will be shared within the redundant home agent set in
background. In case there is a failure the Standby Home Agent
takes over without the mobile node being aware of the change in
the home agent.
o Home Agent Hard Switch: In this mode the home agents are addressed
by different IP addresses and the mobile node is aware of the
change in the home agent. This mode is also useful when the IPsec
state cannot be synchronized. In this mode, a standby home agent
must solicit mobile nodes to re-establish IPsec/IKE for Mobile
IPv6 signaling. This IPsec re-establishment is triggered when a
mobile node changes its home agent after receiving a home agent
switch message from a standby home agent. In order to exchange
this message securely between a Standby Home Agent and a mobile
node, a mobile node need to establish IPsec SA with both an Active
Home Agent and redundant home agents beforehand. With this
multiple IPsec SAs, a mobile node will receive a notification from
the Standby Home Agent and start to use the Standby Home Agent
when the Active Home Agent failed.
All new messages defined in this document are defined as Mobility
Header messages so that the HA reliability protocol can be extended
later, if needed, to provide home link redundancy. (i.e. Protocol is
not tight with the link boundary)
5.1. Home Agent Virtual Switch
In the case of the virtual home agent switch, a mobile node remains
agnostic about the change in the serving home agent. The home agents
have replicated all session state including the IPsec/IKE/ESP sates.
The ESP sequence numbers, which is used to prevent replay attack, may
not be synchronized momentarily. However, this should not pose any
problem as both ends of the IPsec ESP tunnel should use sequence
numbers that are greater than the last known sequence numbers to
either ends. The Standby Home Agent should add a random number (+n)
over and above the anti-replay window to ensure that the packet
Wakikawa (Editor) Expires December 21, 2006 [Page 10]
Internet-Draft Home Agent Reliability June 2006
received by the mobile node passes ESP replay check.
The operations of the Home Agent Virtual Switch are shown in
Figure 1. After binding registration is done (2, 3), the Active Home
Agent pushes all the states of mobile nodes by a state
synchronization message in a periodic interval (4). The Active Home
Agent synchronizes the IPsec state information with the Standby Home
Agent(s), too. This state synchronization should be done
periodically in order to match the ESP sequence number and anti-
replay window among home agents. The Standby Home Agent(s) is not
active unless it takes over from a Failed Home Agent.
When the Active Home Agent's failure is detected (5), the Standby
Home Agent activates the IP address of the failed home agent on it
and takes over from the Failed Home Agent. All the home agents in
the redundant home agent set share a virtual address and the routing
will ensure only the Active Home Agent will be reachable using that
virtual address. The Standby Home Agent can serve all the mobile
nodes for which the states are synchronized, without any further
message exchange because it has all the necessary information which
it obtained from the failed home agent.
MN HA1(active) HA2(Standby)
| | .
|<--------->| . 1. IPsec/IKE
| | .
|---------->| . 2. Binding Update
|<----------| . 3. Binding Acknowledgement
| | .
| |<--------->. 4. State exchanges (Binding cache/IPsec)
| | .
| X . HA1 FAILURE
| X .
| X<----------. 5. Failure Detection
| X |
| X | 6. HA2 takes over the HA1
| X |
| X | RECOVERY COMPLETE
Figure 1: Overview of Home Agent Virtual Switch
5.2. Home Agent Hard Switch
The Home Agent Hard Switch is shown in Figure 2. This mode is not
transparent to mobile node when there is a home agent failure and
another home agent takes over.
Wakikawa (Editor) Expires December 21, 2006 [Page 11]
Internet-Draft Home Agent Reliability June 2006
MN HA1(active) HA2(Standby)
| | |
|<--------->| | 1. IKE exchange (w/HoA assignment)
| | |
|---------->| | 2. Binding Update
|<----------| | 3. Binding Acknowledgement
| | |
|<--------------------->| 4. IKE exchange (wo/HoA assignment)
| | |
| |<--------->| 5. State Exchanges
| | |
| X | HA1 FAILURE
| X |
| X<----------| 6. Failure Detection
| X |
|<----------------------| 7. Sending home agent
| X | Switch message
| X |
|<--------------------->| 8. Binding Registration (optional)
| X |
| X | RECOVERY COMPLETE
Figure 2: Overview of Home Agent Hard Switch
In this mode, a mobile node establish IPsec SA with multiple home
agents beforehand. When an Active Home Agent fails, the other
Standby Home Agent could use pre-existing IPsec SA to notify the
Mobile Node about the failure. After the notification, the mobile
node will use the Standby Home Agent as its home agent.
In order to discover the home agent address, two different mechanisms
are defined in the bootstrapping solution in split scenario. One is
DNS lookup by home agent Name, the other is DNS lookup by Service
Name. The mobile node sends a DNS SRV request and acquires IP
addresses and preferences of a redundant home agent set. In
integrated scenario, DHCPv6 is used to provide home agent provision
to Mobile Node.
The mobile node establishes IPsec/IKE state with the other acquired
home agents beforehand (1 and 4), however it registers only with the
Active Home Agent (2 and 3). The Active Home Agent synchronizes
required states of mobile nodes such as Binding Cache information and
AAA information, etc. with other standby home agents periodically
(5).
When the Standby Home Agent detects the failure of the active home
agent (6), it sends a home agent switch message to all the mobile
Wakikawa (Editor) Expires December 21, 2006 [Page 12]
Internet-Draft Home Agent Reliability June 2006
nodes that were registered to the Failed Home Agent (7). The home
agent switch message must be encrypted by pre-established IPsec SA.
After the switch message, the mobile node MAY send a binding update
and registers it with the new Active Home Agent in order to update
MIP6 tunnel's end points (8). However, this binding registration can
be skipped since the Standby Home Agent synchronizes the binding
cache information with the Active Home Agent periodically. The
mobile node only changes its home agent address to the new Active
Home Agent.
5.3. Failure Detection and Home Agent Management
HA1(active) HA2 HA3 .. HAn
| | | |
|<------>| | | 1. Hello exchange
|<------------->| |
|<-------------------->|
| | | |
(Failed) | | | A FAILURE OCCURS
X | | |
X | | | 3. Standby HAs detects
X | | | failure.
X | | |
X (active) | | 4. HA2 becomes Active HA
X | | |
| | | | HA1 RECOVER NOW
(standby) | | |
|------->| | | 5. HA1 sends SwitchOver Request
|<-------| | | 6. HA2 sends SwitchOver Reply
| | | |
(active) (standby) | | 7. HA1 returns to active HA
| | | |
| | | | HA1 BECOMES ACTIVE AGAIN
Figure 3: Home Agent Management
Figure 3 illustrates the mechanism by which a Standby Home Agent
takes over from a failed home agent. This operation is common for
both the hard and the virtual switch modes. The home agent whose
preference is the highest among the Standby Home Agents takes over
immediately after it detects failure of the Active Home Agent. The
preference value can be same as the home agent preference value of
RFC3775, while the operator can define an independent value only for
home agent reliability protocol.
The Home Agents in the redundant Home Agent set exchange periodic
Wakikawa (Editor) Expires December 21, 2006 [Page 13]
Internet-Draft Home Agent Reliability June 2006
Hello messages to convey their information to the peers (1). The
Hello messages can either be unicast or multicast. In order to
explicitly query the state information of its peer(s), any Home Agent
can send a Hello request to its peer(s) in the redundant Home Agent
set. The Hello message exchange is the basis of failure detection
and automatic switchover in this scheme (3 and 4).
When HA1 recovers in Figure 3, it needs to remain in the standby
state. This prevents it to automatically take over from the
currently active Home Agent. HA1 sends a SwitchOver Request to the
currently active Home Agent (i.e. HA2) only if the system
administrator issues a manual command, if the monitored server fails,
if the routing peer/link fails. The currently Active Home Agent can
be known through the exchange of Hello messages. HA1 may need to
send Hello Request message to all the Standby Home Agents, when it
recovered from the failure. When HA2 receives the Home Agent
SwitchOver Request from HA1 it changes its state to standby and sends
back the SwitchOver Reply message to HA1. HA1 returns to active home
agent status immediately after receiving the SwitchOver reply.
HA1(active) HA2 HA3 .. HAn
| | | |
|------->| | | 1. HA1 sends SwitchBack Request
|<-------| | | 2. HA2 sends SwitchBack Reply
| | | |
(standby) (active) | | HA2 BECOMES ACTIVE HA
| | | |
SYSTEM MAINTENANCE, ETC.
| | | |
|------->| | | 3. HA1 sends SwitchOver Request
|<-------| | | 4. HA2 sends SwitchOver Reply
| | | |
(active) (standby) | | 5. HA1 returns to active HA
| | | | HA1 BECOMES ACTIVE AGAIN
Figure 4: Manual Home Agent Change
In some scenarios the Active Home Agent may need to stop serving the
mobile nodes for system maintenance. This specification provides
manual home agent change by using Home Agent SwitchBack Request and
Reply messages. As shown in Figure 4, the Active Home Agent (HA1)
sends Home Agent SwitchBack Request to an Standby Home Agent. As
soon as HA2 receives the message, it becomes the Active Home Agent.
HA2 also acknowledges with the Home Agent SwitchBack reply to HA1.
HA1 becomes standby when it receives the SwitchBack reply. After the
downtime, HA1 sends a Home Agent SwitchOver Request to HA2 in order
Wakikawa (Editor) Expires December 21, 2006 [Page 14]
Internet-Draft Home Agent Reliability June 2006
to return to become an Active Home Agent again. This operation is
same as Figure 3
Wakikawa (Editor) Expires December 21, 2006 [Page 15]
Internet-Draft Home Agent Reliability June 2006
6. Messages
This document defines following new messages:
o New Mobility Header Messages
* Home Agent Hello Request Message
* Home Agent Hello Message
* State Synchronization Request Message
* State Synchronization Message
* Home Agent SwitchOver Request Message
* Home Agent SwitchOver Reply Message
* Home Agent SwitchBack Request Message
* Home Agent SwitchBack Reply Message
o New Mobility Options
* Binding Cache Information Option
* AAA Information Option
* Vendor Specific Information Option
We may add more mobility options in the future document. The DT is
currently discussing the needs and the formats of IPsec/IKE state
information Option and BGP/OSPF modifier option for state
synchronization message.
Home Agent Switch message is defined in [8]. This message is also
used in operation of Home Agent Hard Switch.
6.1. New Mobility Header Messages
6.1.1. Home Agent Hello Request Message
The message is unicasted to a home agent to solicit a Hello message
from a home agent. The receiver of this Hello Request message MUST
return a Hello message to the originator of this request message. A
Home Agent Hello message SHOULD be authenticated and encrypted by
IPsec ESP.
Wakikawa (Editor) Expires December 21, 2006 [Page 16]
Internet-Draft Home Agent Reliability June 2006
The Hello Request message has the MH Type value TBD. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Home Agent Hello Request Message
Sequence #
16-bit unsigned integer. The Sequence number of the Hello message
can be used to verify whether this Hello message is the latest one
or not.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of [1].
The receiver MUST ignore and skip any options which it does not
understand. There MAY be additional information, associated with
this HELLO Request message that need not be present in all HELLO
Request messages sent. Mobility options allow future extensions
to the format of the HELLO Request message to be defined.
If no options are present in this message, no padding is necessary
and the Header Len field will be set to 1.
6.1.2. Home Agent Hello Message
The message is either unicasted or multicasted to carry Home Agent
information among the Redundant home agent set. This Hello message
is used by any home agents to detect the failure of a redundant peer
in the redundant Home Agent set. This message can be sent either
periodically or in reply to Hello Request message. A home agent
Wakikawa (Editor) Expires December 21, 2006 [Page 17]
Internet-Draft Home Agent Reliability June 2006
Hello message SHOULD be authenticated and encrypted by IPsec ESP when
it is unicasted. If a Hello message is multicasted, IPsec ESP cannot
be applied. Hence if multicast is used, the redundant Home Agent set
should be in a secure network.
The Standby Home Agents and the Active Home Agent must exchange the
home agent information. Although Mobile IPv6 uses a router
advertisement to exchange home agent information periodically, the
Hello message can be replaced with the router advertisement.
If the Standby Home Agent misses this Hello message from it's peer
Active Home Agent for a configured number of times, it SHOULD assume
that the Active Home Agent has failed. If the active home agent does
not periodically send the Hello message, each standby home agent
needs to solicit it by sending a Hello Request message.
The Hello message has the MH Type value TBD. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | Group ID |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Home Agent Hello Message
Sequence #
16-bit unsigned integer. The Sequence number of the Hello message
can be used to verify whether this Hello message is the latest one
or not.
Wakikawa (Editor) Expires December 21, 2006 [Page 18]
Internet-Draft Home Agent Reliability June 2006
Home Agent Preference
16-bit unsigned integer. The preference for the home agent
sending this hello. This preference is same as the home agent
preference value of home agent information option defined in
Mobile IPv6. However, if operators want to use the different
preference value for this operation, it can use different value
from the preference defined in RFC3775
Home Agent Lifetime
16-bit unsigned integer. The lifetime for the home agent sending
this Hello. This lifetime is same as the home agent Lifetime
value of home agent information option defined in Mobile IPv6.
Hello Interval
16-bit unsigned integer. The interval for the home agent sending
this Hello.
Group Identifier
8-bit unsigned integer. This value is used to identify a
particular redundant home agent set.
A flag
If this flag is set, the sender of this Hello message is an Active
Home Agent. Otherwise, the sender is Standby Home Agent
Reserved
7-bit unsigned integer. It must be initialized to zero by the
sender and must be ignored by the receiver.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [1]. The receiver
MUST ignore and skip any options which it does not understand.
The following options are valid in a Hello:
* IP Address Option (Sub-type: Home Agent Address): A Home Agent
Address and its Prefix Length are stored in an IP address
option. If there are multiple home network prefixes serving by
Wakikawa (Editor) Expires December 21, 2006 [Page 19]
Internet-Draft Home Agent Reliability June 2006
a home agent, multiple IP address options should be used in a
Hello message.
If no options are present in this message, 0 octets of padding are
necessary and the Header Len field will be set to 2.
6.1.3. State Synchronization Request Message
This message is used to request state corresponding to a particular
mobile node. It is a unicast message and MUST be authenticated. The
State Synchronization Request message is used to solicit the active
state corresponding to a particular Mobile Node. The format of the
message is as follows:
The State Synchronization Request has the MH Type value TBD. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: State Synchronization Request Message
Identifier
The 16-bit identifier to aid in matching state synchronization
message. The identifier should never be set to 0. It should
always be more than 1.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [1]. The receiver
MUST ignore and skip any options which it does not understand.
Wakikawa (Editor) Expires December 21, 2006 [Page 20]
Internet-Draft Home Agent Reliability June 2006
The following options are valid in a State Synchronization Request
message. One of the following options is mandatory in State
Synchronization Request message. :
* IP Address Option (Sub-type: Home Address)[9]. If a Home
Agents wants the Binding Cache information for a particular
Mobile Node, it includes an IPv6 Address Option (Sub-type: Home
Address).
* Mobile Network Prefix Option: If a home agent wants to know the
forwarding state setting up for a particular Mobile Network
Prefix, it includes a Mobile Network Prefix Option defined in
[2].
If no options are present in this message, no padding is necessary
and the Header Len field will be set to 1.
6.1.4. State Synchronization Message
The State Synchronization message is used between the home agents in
the Home Agent redundant set to exchange binding cache information,
IPsec state and any other information related to providing mobility
service to the mobile nodes. It is an unicast message. The state
synchronization can be sent by an active home agent either
periodically or in response to a state synchronization Request
message.
The State Synchronization message has the MH Type value TBD. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: State Synchronization Message
Wakikawa (Editor) Expires December 21, 2006 [Page 21]
Internet-Draft Home Agent Reliability June 2006
Identifier
The 16-bit identifier to aid in matching state synchronization
reply message. The identifier should never be set to 0. It
should always be more than 1.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [1]. The receiver
MUST ignore and skip any options which it does not understand.
The following options are valid in a State Synchronization
message. One of the following options is mandate in State
Synchronization message. :
* Binding Cache Information Option.
* AAA Information Option.
* Vendor Specific Information Option.
This message requires at least one of mobility options. Therefore,
there is no default length for this message.
6.1.5. Home Agent SwitchOver Request Message
This message is unicasted by a Standby Home Agent that desires to
become the Active Home Agent for all the Mobile IPv6 sessions. The
receiver of the message MUST transit to inactive state as soon as the
message is received and validated.
The Home Agent SwitchOver Request message has the MH Type value TBD.
The message MUST be authenticated and encrypted by IPsec ESP.When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Home Agent SwitchOver Request Message
Wakikawa (Editor) Expires December 21, 2006 [Page 22]
Internet-Draft Home Agent Reliability June 2006
No padding is necessary and the Header Len field will be set to 1.
6.1.6. Home Agent SwitchOver Reply Message
This message is used to acknowledge the receipt of the corresponding
Home Agent SwitchOver Request message. The reply message should
contain status_code field to convey the result of processing the
received Home Agent SwitchOver Request message.
The Home Agent SwitchOver message has the MH Type value TBD. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Home Agent SwitchOver Reply Message
Status
16-bit Status value. Values of Status field greater than or equal
to 128 indicate that the Home Agent SwitchOver Request was
rejected by the receiving node. The following Status values are
currently defined:
0: success
128: The receiver of the Home Agent SwitchOver Request message
is not the Active Home Agent
129: failed, Admin Prohibited.
No padding is necessary and the Header Len field will be set to 1.
6.1.7. Home Agent SwitchBack Request Message
This message is unicasted by an Active Home Agent that desires to
become the inactive Home Agent for all the Mobile IPv6 sessions. The
receiver of this message SHOULD transit to active state as soon as
the message is received and validated.
The Home Agent SwitchBack Request message has the MH Type value TBD.
The message MUST be authenticated and encrypted by IPsec ESP. When
Wakikawa (Editor) Expires December 21, 2006 [Page 23]
Internet-Draft Home Agent Reliability June 2006
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Home Agent SwitchBack Request Message
No padding is necessary and the Header Len field will be set to 1.
6.1.8. Home Agent SwitchBack Reply Message
This message is used to acknowledge the receipt of the corresponding
Home Agent SwitchBack Request message. The message should contain
status_code field to convey the result of processing Home Agent
SwitchBack Request message.
The Home Agent SwitchBack Reply message has the MH Type value TBD.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Home Agent SwitchBack Reply Message
Status
16-bit Status value. Values of Status field greater than or equal
to 128 indicate that the Home Agent SwitchBack Request was
rejected by the receiving node. The following Status values are
currently defined:
0: success
Wakikawa (Editor) Expires December 21, 2006 [Page 24]
Internet-Draft Home Agent Reliability June 2006
128: The receiver of Home Agent SwitchBack Request is already
the Active Home Agent
129: failed, Admin Prohibited.
No padding is necessary and the Header Len field will be set to 1.
6.2. New Mobility Options
6.2.1. IP address Option
This option is already defined at FMIP specification[9]. This
document introduces new Sub-Type value for home agent address and
Home Address.
Option-Code
* 4: Home Agent Address
* 5: Home Address
6.2.2. Binding Cache Information Option
The binding cache information option has an alignment requirement of
8n+2. Its format is as follows:
Wakikawa (Editor) Expires December 21, 2006 [Page 25]
Internet-Draft Home Agent Reliability June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Mobile Network Prefix Option .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Binding Cache Information Option
The binding cache information option is valid in a state
synchronization message.
The fields of Home Address, Care-of Address, Flags, Sequence Number,
and Lifetime are copied from the registered binding of a particular
Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to
zero.
If the R-flag is set to indicate this binding cache entry is for a
Mobile Router, then this option will be immediately followed by one
or more Mobile Network Prefix options.
Wakikawa (Editor) Expires December 21, 2006 [Page 26]
Internet-Draft Home Agent Reliability June 2006
6.2.3. AAA Information Option
The AAA option is used to carry the AAA state of the Mobile Node's
MIP6 sessions. The AAA state information can be conveyed in RADIUS
or Diameter AVP formats including the user and session info. This
information option is valid in a state synchronization message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. AAA AVPs .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Vendor Specific Inforamtion Option
Type
8-bit Type value. The value is TBD.
Length
8-bit length value.
AAA AVPs
Series of TLV encoded AAA AVPs (including vendor specific AVPs)
carrying AAA related information for each MIP6 and IPsec/IKE
sessions.
Reserved
16-bit field reserved for future use. The value SHOULD be
initialized to zero by the sender, and MUST be ignored by the
receiver.
6.2.4. Vendor Specific Information Option
The Vendor Specific information option is used to carry the vendor
specific information of a home agent. The Vendor Specific
information option is valid in a state synchronization message.
Wakikawa (Editor) Expires December 21, 2006 [Page 27]
Internet-Draft Home Agent Reliability June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Vendor Specific Information .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Vendor Specific Inforamtion Option
Type
8-bit Type value. The value is TBD.
Length
8-bit length value.
Vendor Code
16-bit vendor code can be defined by each vendor.
Reserved
16-bit field reserved for future use. The value SHOULD be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Wakikawa (Editor) Expires December 21, 2006 [Page 28]
Internet-Draft Home Agent Reliability June 2006
7. Home Agent Operation
7.1. Home Agent Configuration
There are two approaches to place Standby Home Agents. The first
configuration is that a Standby Home Agent is located at the same
link (i.e. home link) of home agents. Another one is that the
Standby Home Agent is located at the different link from the home
link. The differences are whether home agent and Standby Home Agents
share the link or not.
HA1 HA2 HA3 HA4 .... HAn
| | | | |
--------+------+------+------+--------+---------
Home Link
Figure 16: Local Recovery Configuration
Figure 16 depicts the configuration where home agents serving the
same home network are located on the same link. For example, HA3 and
HA4 are Standby Home Agents of HA1 and HA2. This is what Mobile IPv6
defines for home agent configuration.
HA1 HA2 HA3 HA4
| | | |
--------+------+-----+ R +-----+------+-------
Home Link Router Recovery Link
Figure 17: Global Recovery Configuration
Figure 17 illustrates when standby home agents are located on
different link (named recovery link in the figure). For example, HA3
and HA4 are standby home agents of HA1 and HA2. In this case, HA3
and HA4 cannot receive the packets meant for the home network till
the route on the Router is changed. The advantage of this
configuration is that Standby Home Agents can recover the failure of
the home link. If the home link becomes unreachable, the local
recovery is useless. However, this configuration can achieve the
home agent recovery even if the entire home link fails. In this
configuration, the routing must be also updated to direct the packets
meant for the home link to the recovery link.
Each Standby Home Agent obtains its individual IP address from the
link. This IP address is used for home agent reliability protocol to
Wakikawa (Editor) Expires December 21, 2006 [Page 29]
Internet-Draft Home Agent Reliability June 2006
exchange information with the associated home agent. The link
between home agents should be secured.
When Home Agent Virtual Switch is used, the home agent's IP address
which is known by the mobile node can be shared with Standby Home
Agents. When a home agent fails, the standby home agent takes the IP
address out of the failed home agent. Then the Standby Home Agent
can uses the IP address for further home agent operations as being an
Active Home Agent. The Standby Home Agent should not activate the IP
address until the Active Home Agent is dead and the reachability to
the IP address is lost. Otherwise, address duplication will occurs.
This operation is normally done using route selector such as BGP and
OSPF modifier. As an example we can use the AS_Path prepend
operation for BGP and Metric field in the OSPF for route selection.
The Ha reliability DT may define a new mobility option to carry
respective BGP/OSPF modifier information.
Alternatively, in Home Agent Hard Switch case, The home agent address
may be different, but the home addresses and the home link prefix are
the same. In this case, all the reachability of mobile nodes will be
lost during the recovery procedure, since the IP address of Failed
Home Agent is no longer active and all the packets meant for the IP
address will be discarded. The Standby Home Agent must notify mobile
nodes to change the associating home agent. Thus, the mobile node
will detect the home agent changes by knowing the new IP address of
the standby home agent. The home agent has to use the same technique
as in virtual switch mode to advertise the routes into the routing
infrastructure.
7.2. Hello messages Manipulation
Mobile IPv6 [1] defines a mechanism for maintaining a home agent list
when there are multiple home agents present on a link. It is based
on each home agent sending a router advertisement periodically on the
home link with a Home Address Information option [1]. However, this
mechanism is governed by how a router sends a router advertisement as
defined in [4]. There are restrictions on how often a router
advertisement can be sent and on how they are processed by routers
that receive them. Moreover, the router advertisements are not sent
frequently enough to rely on the absence of the router advertisement
to detect a home agent failure. Moreover, when home agents are
placed at different links, Router Solicitation and Advertisement
messages [4] can not be used due to link-local limitation.
In this document, new Mobility Header messages are defined in
Section 6.1.1 and Section 6.1.2 to notify similar information of
Router Advertisement among home agents over the home link.
Wakikawa (Editor) Expires December 21, 2006 [Page 30]
Internet-Draft Home Agent Reliability June 2006
7.2.1. Sending Hello Request
A home agent can solicit a Hello message by sending a Hello Request
message. The Hello Request message is unicasted to an Active Home
Agent or a Standby Home Agent. This message should be encrypted and
authenticated by IPsec ESP mode. An originator of the Hello Request
message must specify the random sequence value. The sequence value
is used to match the Hello message which is sent from the receiver of
the Hello Request message.
7.2.2. Receiving Hello Request
When a home agent receives a hello Request message, it SHOULD verify
correct IPsec protection. If the message is not protected, it SHOULD
be silently discarded. However, if the Hello messages can be sent on
a dedicated link between the home agents and in such a case, IPsec
protection is not required.
If the sender home agent is not in the same redundant home agent set,
the message MUST be silently ignored, too.
The sequence field should be copied to the Hello message which will
be sent in reply to the hello Request message. This sequence number
is used as a transaction ID for the Hello message exchange.
7.2.3. Sending Hello
A home agent Hello message MUST be constructed with same information
of a Router Advertisement message described in section 7 of [1]. The
Hello messages can be unicasted or multicasted. A new multicast
address will be assigned by the IANA. All the home agents on the
home link should join this multicast address. When the Hello
messages are used for maintaining the home agents list, the home
agent SHOULD NOT use the home agent Information option in the router
advertisements to manage the home agents list.
The Hello message MUST be sent when a home agent is requested by a
hello Request message. The Hello message can be also periodically
sent. In addition, the home agent SHOULD send a home agent Hello
message to home agents of the redundant home agent set when it boots
up and its local information such as preference, lifetime, and
registration status, etc. change. The interval between two Hello
messages is configurable on the home agents. When a new home agent
boots up, it SHOULD wait a particular time to listen home agent Hello
messages of all configured Home Agents. Alternatively, it can
solicit Hello message by sending a Hello Request message.
If a home agent is the Active Home Agent, it MUST set A flag in Hello
Wakikawa (Editor) Expires December 21, 2006 [Page 31]
Internet-Draft Home Agent Reliability June 2006
Messages.
7.2.4. Receiving Hello
The receiver of a Home Agent Hello message MUST verify the source
address field of the IPv6 header. If a Home Agent Hello message is
received from unknown home agent, the message MUST be silently
dropped. If the source address is not in the list of known home
agents, the message MUST be silently dropped. In addition to this
source address check, Group ID is introduced in this document. This
Group ID is used to identify a particular redundant home agent set.
If the Group ID field is specified in a Hello message, the receiver
MUST process only the Hello which group ID is matched. This Group ID
is verified when the Hello message is multicasted. The Hello message
MUST NOT be sent to a home agent whose Group ID is different from the
sender. If the Group ID is set to zero, the receiver MUST ignore
this field.
Any Home Agent Hello message satisfying all of these tests MUST be
processed to update its home agent list. The Home Agents list can be
ordered based on the home agent preference value. If the home agent
lifetime field in the Hello message is set to 0, the receiver removes
the sender home agent that from the home agents list.
7.3. Failure Detection
When a home agent meets an error and cannot fulfill home agent
functionality, the Standby Home Agent must detect the failure and
should act as the Active Home Agent. The failure detection is
important feature of Home Agent local reliability.
The most common way to detect failure is using periodic message
exchange such as Hello of routing protocols. This mechanism is often
used to detect failure on many protocols. In the real scenario, when
a home agent crashed, it can happened that only home agent
functionality is down and network reachability to home agent is
alive. In this case, ICMP type of message such as ping can not be
used to detect the home agent failure. Therefore, we define a new
Hello message to detect the home agent failure.
The Active and the Standby Home Agents exchange periodic Hello
messages to monitor one another's status. Hello request message may
be used by any Home Agent to explicitly request state information
from any other Home Agent in the redundant Home Agent set. If a Home
Agent Hello message is not received from a Home Agent peer within a
configurable amount of time, then that home agent peer is considered
to have failed.
Wakikawa (Editor) Expires December 21, 2006 [Page 32]
Internet-Draft Home Agent Reliability June 2006
Example Failure Events:
Loss of Communication with the Active Peer Home Agent
The redundant Home Agent set should have knowledge of each others
state. In order to achieve that, we define Hello message
exchanges. In the event that the Home Agent that is currently
inactive does not receive any Hello message from its peer which is
currently active for a configurable duration, the Home Agent may
decide to become active.
Monitored Server Failure by the Active Home Agent
There may be number of critical servers in the network that are
essential for the ongoing Mobile IPv6 session at the Home Agent.
One such server may be the AAA server which is receiving the
accounting information for the session. The operator may have a
policy in place that requires the Home Agent to initiate
SwitchOver procedure upon detecting that the link to such a server
has failed.
Routing Peer/Link Failure
In some cases, the operator may like the Home Agent to detect a
next hop routing peer failure. If the next hop routing peer
fails, the operator may want the Home Agent to initiate SwitchOver
if the failure is fatal in nature or due to some other routing
policies.
7.4. Active Home Agent Change
There are two cases when a Standby Home Agent takes over an Active
Home Agent. The first case is when a Standby Home Agent detects
failure of the Active Home Agent described in Section 7.3. The
Standby Home Agent immediately becomes an Active Home Agent. The
second case is when a home agent receives a Home Agent SwitchOver
Request message described in Section 7.6.
Upon detecting failure of an Active Home Agent, the Standby Home
Agent becomes Active. If there are more than one Standby Home Agent
or when there are two Home Agents in the redundant Home Agent set,
but both of them boots up at the same time, two values are used to
break any tie. The Home Agent with lowest BGP/OSPF modifier value
becomes Active. If the BGP/OSPF modifiers are the same, then the
home agent preference values (configured by the system administrator)
is used to break the tie.
When the Standby Home Agent becomes active, it MUST start to
Wakikawa (Editor) Expires December 21, 2006 [Page 33]
Internet-Draft Home Agent Reliability June 2006
advertise the home agent address and the home prefix of the home
addresses serviced by the redundant home agent set into the routing
infrastructure. This is operated by using route selector such as BGP
and OSPF modifier. In addition, if necessary, the new active home
agent must overwrite the neighbor entries of the mobile nodes in
order to intercept packets of the mobile nodes.
7.5. Processing State Synchronization Messages
It is necessary for Standby Home Agent to synchronize the state
information of each mobile node stored in the active home agent. In
Home Agent Virtual Switch mode, the synchronized state information is
used by a Standby Home Agent when it takes over the Failed Home
Agent. In Home Agent Hard Switch mode, the Standby Home Agent starts
the trigger to all the mobile nodes registering to the Failed Home
Agent when the home agent failure is detected. This state
synchronization must be securely operated.
7.5.1. Sending State Synchronization Request
When a Standby Home Agent wants state for a particular Mobile Node
such as Binding Cache, AAA, etc, it can solicit State Synchronization
message by sending State Synchronization Request. This is optional
operation of a standby home agent. The Standby Home Agent MUST set a
random value to the Identifier field in the state synchronization
Request message and MUST include either a Home Address mobility
option or a Mobile Network Prefix mobility option. The Standby Home
Agent can store multiple home address mobility options or mobile
network prefix mobility options to request state information for
multiple mobile nodes by a single state synchronization Request
message.
7.5.2. Receiving State Synchronization Request
If the received state synchronization Request message is not
protected by IPsec ESP, the message must be silently discarded. If
the sender home agent is not belong to the same redundant home agent
set, the message must be silently ignored. Moreover, if a receiver
is not the Active Home Agent for the requested home address or mobile
network prefix, it MUST silently discard the message. Otherwise, the
receiver MUST reply with a State Synchronization message including
state information for the requested mobile node(s).
7.5.3. Sending State Synchronization
A state synchronization message can be sent either:
Wakikawa (Editor) Expires December 21, 2006 [Page 34]
Internet-Draft Home Agent Reliability June 2006
o when an Active Home Agent receives a state synchronization Request
message
o when an Active Home Agent creates/updates binding cache for a
particular Mobile Node.
o in a periodic interval to update the state info for all sessions
that changed since last update.
If an Active Home Agent sends the state synchronization message
whenever the local state information such as binding cache changed,
the size of the state synchronization message are large. The Active
Home Agent should update the state information with an interval which
is configured by system administrator.
The binding cache of the requested Mobile Node are stored in the
state synchronization message. The Active Home Agent MUST copy the
binding cache of the requested Mobile Node to each fields of a
binding cache information option. If the state synchronization
message is sent in response to the state synchronization Request
message, the Active Home Agent MUST copy the Identifier field of the
state synchronization Request message to the same filed in the state
synchronization message. Otherwise, it MUST set zero to the
Identifier field.
The Active Home Agent can store state of multiple mobile nodes in a
state synchronization message
7.5.4. Receiving State Synchronization
A state synchronization message MUST be authenticated and encrypted
by IPsec ESP mode. If not, the message MUST be ignored. When a Home
Agent receives a state synchronization message, it MUST verify the
Source address field of the IPv6 header. If the source address do
not belong to any home agents of the redundant home agent set, the
message MUST be silently discarded. The receiver home agent SHOULD
record the state and the Active Home Agent address into its Binding
Cache.
7.6. Processing Home Agent SwitchOver Messages
7.6.1. Sending Home Agent SwitchOver Request
When a Standby Home Agent decides to become an active home agent, it
MAY send a home agent SwitchOver Request message to an Active Home
Agent. The reason for the Standby Home Agent to send this message is
administrative intervention. The Standby Home Agent sends with a
mobility header which type is set to the home agent SwitchOver
Wakikawa (Editor) Expires December 21, 2006 [Page 35]
Internet-Draft Home Agent Reliability June 2006
Request type. This message must be encrypted and authenticated by
IPsec ESP. The Active Home Agent MUST NOT generate this message.
7.6.2. Sending Home Agent SwitchOver Reply
A home agent SwitchOver reply is sent in reply to a home agent
SwitchOver Request message. When a home agent receives a home agent
SwitchOver Request message, it first verifies the message. If the
request message is not protected by IPsec, it MUST be silently
discarded. In addition, if the sender home agent is not belong to
the same redundant home agent set, the message MUST be silently
discarded.
If a receiver home agent is not an Active Home Agent, it replies a
home agent SwitchOver reply which status field set to 128.
Otherwise, the receiver home agent MUST become a Standby Home Agent
and replies a home agent SwitchOver reply which status field set to
zero.
7.6.3. Receiving Home Agent SwitchOver Reply
If a home agent receives a home agent SwitchOver reply, the message
MUST be protected by IPsec. Otherwise, the message MUST be silently
discarded. If a receiver home agent did not send a home agent
SwitchOver Request beforehand, the message MUST be silently
discarded.
If the status field of the SwitchOver reply message indicates zero,
the receiver Standby Home Agent immediately becomes an Active Home
Agent. If the status value is greater than 128, an error is
occurred. Thus, the receiver cannot be an active home agent.
7.7. Processing Home Agent SwitchBack Messages
7.7.1. Sending Home Agent SwitchBack Request
When an Active Home Agent decides to become an in-active home agent
(i.e. Standby Home Agent), it MAY send a home agent SwitchBack
Request message to a Standby Home Agent. The reason for the Active
Home Agent to send this message is administrative intervention, and
events like Monitored Server Failure by the Active Home Agent or
Routing Peer/Link Failure. The Active Home Agent sends it with a
mobility header which type is set to the home agent SwitchBack
Request type. This message must be encrypted and authenticated by
IPsec ESP. A Standby Home Agent MUST NOT generate this message.
Wakikawa (Editor) Expires December 21, 2006 [Page 36]
Internet-Draft Home Agent Reliability June 2006
7.7.2. Sending Home Agent SwitchBack Reply
A home agent SwitchBack reply is sent in reply to a home agent
SwitchBack Request message. When a home agent receives a home agent
SwitchBack Request message, it first verifies the message. If the
request message is not protected by IPsec, it MUST be silently
discarded. In addition, if the sender home agent is not belong to
the same redundant home agent set, the message MUST be silently
discarded. If the sender home agent of SwitchBack Request message is
not an Active Home Agent, the message MUST be silently discarded.
If a receiver home agent of SwitchBack Request message is already an
Active Home Agent, it replies home agent SwitchBack reply which
status field set to 128. Otherwise, the receiver home agent MUST
become an Active Home Agent and replies a home agent SwitchBack reply
which status field set to zero.
7.7.3. Receiving Home Agent SwitchBack Reply
If a home agent receives a home agent SwitchBack reply, the message
MUST be protected by IPsec. Otherwise, the message MUST be silently
discarded. If a receiver home agent did not send a home agent
SwitchBack Request message beforehand, the message MUST be silently
discarded, too.
If the status field of the SwitchBack reply message indicates zero,
the receiver home agent immediately becomes an in-Active Home Agent.
If the status value is greater than 128, some error is occurred.
Thus, the receiver cannot be an in-active home agent and MUST
continue to be an Active Home Agent.
7.8. Sending Home Agent Switch Message
If an Active Home Agent fails, another Standby Home Agent on the home
link can take over the Failed Home Agent in the Home Agent Hard
Switch mode. This operation is valid only for the Home Agent Hard
Switch mode. The Standby Home Agent MUST send a home agent Switch
message defined in [8] to all the mobile nodes that were being served
by the Failed Home Agent. The message must be encrypted with pre-
established SA. The standby home agent should include its own IP
address in the home agent switch message.
Note that a Home Agent Switch message is sent to each mobile node
served by the home agent. If there are a large number of mobile
nodes, sending Home Agent Switch messages will cause a lot of
signaling overhead on the network.
Wakikawa (Editor) Expires December 21, 2006 [Page 37]
Internet-Draft Home Agent Reliability June 2006
8. Mobile Node Operation
Operations described in this section are valid only for the home
agent hard switch mode. When the Home Agent Virtual Switch is used,
all the operations can be skipped.
8.1. Standby Home Agent Addresses Discovery
To provide home agent reliability, one possible solution is that the
Mobile Node authenticate itself to two home agents and creates IPsec
SA with two home agents in bootstrapping. When one home agent fails
the other home agent could use pre-existing SA to notify the Mobile
Node about the failure.
In the Home Agent Hard Switch mode, multiple home agent addresses are
valid in the home network. In order to discover the home agent
address, two different mechanisms are defined in the bootstrapping
solution in split scenario [10]. One is DNS lookup by home agent
Name, the other is DNS lookup by Service Name. Also in integrated
scenario [11], DHCPv6 is used to provide home agent provision to
Mobile Node.
In the split scenario, Mobile Node can use DNS lookup by Service Name
to discover the home agents, as defined in [10]. For example, If
home agent reliability is required by the Mobile Node, DNS lookup by
Service Name method is recommended for Mobile to discovery multiple
home agents addresses. Therefore Mobile Node will query the DNS SRV
records with service name of mip6 and protocol name of ipv6. the DNS
SRV records includes multiple home agents addresses and different
preference value and weight. The mobile node SHOULD choose two home
agents from the Home Agents list according to there preference value.
Then the Mobile Node should authenticate itself to both home agents
via IKEv2 exchange.
In the integrated scenario, Mobile Node can use DHCPv6 to get home
agents provision from MSP or ASP, as already defined in [11]. The
only requirement is that the DHCPv6 response must include multiple
home agent information in order to support home agent reliability.
8.2. IKE/IPsec pre-establishment to Home Agents
After Mobile Node get multiple Home Agent addresses, it need to
trigger multiple IKE exchange with multiple home agents selected from
the Home Agent list. Since both IKEv1 and IKEv2 can be used to
bootstrap Mobile IPv6, this solution does not introduce any new
operations to co-operate with IKEv1 or IKEv2. It should initiate IKE
for home agents as soon as home registration is completed.
Wakikawa (Editor) Expires December 21, 2006 [Page 38]
Internet-Draft Home Agent Reliability June 2006
The Mobile Node MUST follow standard IKEv2 exchange in bootstrapping
solution of split scenario [10], or IKEv1 bootstrap solution [12]. if
needed by Mobile Node, Home Address configuration maybe included for
the first IKE exchange. After its Home Address is assigned or
approved by the first home agent, Mobile Node SHOULD register itself
to the second home agent by IKE using the same Home Address.
Therefore, no HoA configuration should be used in the second IKEv2
procedure. Note that the Mobile Node sends Binding Update Message to
the first home agent.
8.3. Receiving Home Agent Switch message
A mobile node must follow the operation specified in [8] when it
receives home agent switch message.
When the mobile node receives a Home Agent Switch message, and if the
message contains the IP address of standby home agent, it picks the
Standby Home Agent in the request message as the Active Home Agent
and sends a Binding Update message to it. The mobile node have
already pre-established SA with the home agent and use the SA to send
Binding Update. However, in this specification, the binding cache
information is already synchronized among the redundant home agent
set, the mobile node can skip this binding re-registration to the new
active home agent. In this case, the mobile node only updates the
Home Agent address of all the binding update list, MIP6 tunnel end
points, etc.
Wakikawa (Editor) Expires December 21, 2006 [Page 39]
Internet-Draft Home Agent Reliability June 2006
9. Security Considerations
Mobile IPv6 depends on IPsec and IKE for binding home registration
described in [5]. A mobile node must encrypt a binding update sent
to a home agent. In addition, the mobile node exchanges HoTI and HoT
messages through a home agent by using IPsec tunnel mode. Therefore,
before a home agent failure, these IPsec states (below is example)
should be synchronized among home agents of a redundant home agent
set.
mobile node may encrypt particular data traffic sent to the Internet.
o Security Policy Database (SPD) and Selector Information
o Security Association (SA) for Binding Registration (SA1 and SA2)
o SA for HoTI/HoT Exchange (SA3 and SA4)
o SA for Mobile Prefix Discovery (SA5 and SA6)
o SA for data packets if any (SA7 and SA8)
The Home Agent reliability scheme for Mobile IPv6 involves IPsec
tunnel SwitchOver upon Home Agent failure. There are various ways
this can be achieved e.g. setting up of multiple IPsec security
associations between the Mobile Node and the Home Agent sets.
Another way could be, the Home Agents periodically check pointing
IPsec session state including the per packet sequence numbers for the
Mobile Node. We can call these two possible Home Agent redundancy
modes as follows:
1. Home Agent Hard Switch. In this mode, the Mobile Node and the
redundant Home Agent set negotiates independent IPsec SAs.
2. Home Agent Virtual Switch. In this mode, the Mobile Node
negotiates just one SA for both the redundant Home Agent set.
In both the cases, the mobile node maintains only one binding cache
at any given time. In the Home Agent Hard Switch case, the mobile
node needs to switch binding from active to Standby Home Agent upon
failover. IPsec redundancy need synchronize both SPD, Selector and
SAD information from one home agent to another home agent.
Since Mobile IPv6 operation requires ESP in transport mode between
the Mobile Node and the Home Agent, we will talk about the ESP field
synchronization issues between the Mobile Node and the redundant set
of Home Agents. Most of fields should be synchronized based on
RFC4301[6]. The ESP header has the following fields:
Wakikawa (Editor) Expires December 21, 2006 [Page 40]
Internet-Draft Home Agent Reliability June 2006
SPI
This field identifies the SAD at the receiver.
Home Agent Hard Switch Mode
the Mobile Node and the redundant Home Agent set negotiates
separate/independent IPsec SAs. Therefore, the SPI value will
vary depending on which Home Agent the Mobile Node selects to
send/receive data packets.
Home Agent Virtual Switch Mode
The Mobile Node negotiates only one IPsec SA. Hence, the SPI
value will remain unchanged upon Home Agent SwitchOver.
Sequence Number
This field is used for "anti-replay" feature of ESP. The
transmitter must include this monotonically increasing number.
The receiver may process the sequence number based on local
policy.
Home Agent Hard Switch Mode
The Mobile Node and the redundant Home Agent set will have
independent set of sequence numbers. Therefore, the Mobile
Node and the Home Agent needs to choose the most appropriate
sequence number to be used. Synchronization of the sequence
number field between the Home Agents is not mandatory in this
mode of operation.
Home Agent Virtual Swtich Mode
The Mobile Node and the redundant Home Agent set will have the
same set of sequence numbers for transmit and receive. Hence,
synchronization of the sequence number field is mandatory in
this mode of operation.
For MIP6 signaling i.e. BU/BA, HoTi/HoT etc. the SA1, SA2, SA3,
SA4 could be synchronized between the Home Agents as these
messages are not sent continuously. Moreover for the BU Case, if
the Mobile Node is in the middle of sending a BU to the Home Agent
(Active Home Agent) for binding refresh, and the Home Agent is
crashing at that moment. The Mobile Node will not get any
response from the Home Agent. The Mobile Node will retry. After
the Standby Home Agent becomes active, it will receive BU from the
Mobile Node with a sequence number that is +n from its last known
Wakikawa (Editor) Expires December 21, 2006 [Page 41]
Internet-Draft Home Agent Reliability June 2006
sequence number for SA1. For the BA case (SA2), the Standby Home
Agent SHOULD add a random number to the last known sequence number
over and above the replay window to ensure that the packet passes
replay check at the Mobile Node. The same applies to HoTi and HoT
messages with SA3 and SA4. Note that this windowing of the
sequence numbers for MIP6 signaling is only needed to cover the
corner cases when BU/HoTi is in air and the Active Home Agent
fails.
The technique explained above should work fine for user data
packets if ESP is used to encrypt user data traffic as well. The
actual switchover time and the routing infrastructure convergence
time is the only latency that the user may perceive.
Initialization Vector
Since each time, IV will be delivered between Mobile Node and Home
Agent, so this field is not necessarily synchronized between home
agents.
Others
Other fields should be synchronized based on RFC4301[6]
In Home Agent Hard Switch mode, the Standby Home Agent needs to send
a home agent switch message in secure way ( i.e. required IPsec
encryption to the trigger). The mobile node pre-establishes IPsec SA
with the Standby Home Agent, as well as an active home agent. The
Standby Home Agent can send a trigger to the mobile node with the
pre-established IPsec SA.
Wakikawa (Editor) Expires December 21, 2006 [Page 42]
Internet-Draft Home Agent Reliability June 2006
10. Contributors
This document is a result of discussions in the Mobile IPv6 Home
Agent Reliability Design Team. The members of the design team are
listed below:
Samita Chakrabarti
samita.chakrabarti@sun.com
Kuntal Chowdhury
kchowdhury@starentnetworks.com
Hui Deng
hdeng@hitachi.cn
Vijay Devarapalli
vijay.devarapalli@azairenet.com
Sri Gundavelli
gundave@cisco.com
Brian Haley
brian.haley@hp.com
Behcet Sarikaya
bsarikaya@huawei.com
Ryuji Wakikawa
ryuji@sfc.wide.ad.jp
11. Acknowledgements
This document includes a lot of text from [13] and [14]. Therefore
the authors of these two documents are acknowledged. We would also
like to thank the authors of the home agent reliability problem
statement [15] for describing the problem succinctly and Alice Qin
for her work on the hello protocol.
Wakikawa (Editor) Expires December 21, 2006 [Page 43]
Internet-Draft Home Agent Reliability June 2006
12. References
12.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[6] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
12.2. Informative References
[7] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[8] Haley, B., "Mobility Header Home Agent Switch Message",
draft-ietf-mip6-ha-switch-01 (work in progress), June 2006.
[9] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[10] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-02 (work in progress),
March 2006.
[11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
progress), October 2005.
[12] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6
Bootstrapping with IKEv1",
draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress),
March 2006.
Wakikawa (Editor) Expires December 21, 2006 [Page 44]
Internet-Draft Home Agent Reliability June 2006
[13] Wakikawa, R., "Inter Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress),
March 2006.
[14] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-01 (work in progress),
March 2006.
[15] Faizan, J., "Problem Statement: Home Agent Reliability",
draft-jfaizan-mipv6-ha-reliability-01 (work in progress),
February 2004.
Wakikawa (Editor) Expires December 21, 2006 [Page 45]
Internet-Draft Home Agent Reliability June 2006
Author's Address
Ryuji Wakikawa
Keio University
Department of Environmental Information, Keio University
5322 Endo, Fujisawa, Kanagawa 252-8520
Japan
Email: ryuji@sfc.wide.ad.jp
Wakikawa (Editor) Expires December 21, 2006 [Page 46]
Internet-Draft Home Agent Reliability June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wakikawa (Editor) Expires December 21, 2006 [Page 47]
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:18 |