draft-ietf-mip6-hareliability-00.txt   draft-ietf-mip6-hareliability-01.txt 
MIP6 Working Group R. Wakikawa (Editor) MIP6 Working Group R. Wakikawa (Editor)
Internet-Draft Keio University Internet-Draft Keio University
Expires: December 21, 2006 June 19, 2006 Intended status: Standards Track March 5, 2007
Expires: September 6, 2007
Home Agent Reliability Protocol Home Agent Reliability Protocol
draft-ietf-mip6-hareliability-00.txt draft-ietf-mip6-hareliability-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The home agent can be a single point of failure when Mobile IPv6 is 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 used in a system. It is critical to provide home agent reliability
in the event of a home agent crashing or becoming unavailable. This in the event of a home agent crashing or becoming unavailable. This
would allow another home agent to take over and continue providing would allow another home agent to take over and continue providing
service to the mobile nodes. This document describes the problem service to the mobile nodes. This document describes the problem
scope briefly and provides a mechanism for achieving home agent scope briefly and provides a mechanism of home agent failure
reliability. Note that this document is not completed yet. DT is detection, home agent state transfer, and home agent switching for
still discussing some items. home agent redundancy and reliability.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6
4. Goals for the Solution . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 10 5.1. Home Agent Network Configuration . . . . . . . . . . . . . 10
5.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 11 5.2. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 11
5.3. Failure Detection and Home Agent Management . . . . . . . 13 5.3. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12
5.4. Active Home Agent Management . . . . . . . . . . . . . . . 13
6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 16 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 14
6.1.1. Home Agent Hello Request Message . . . . . . . . . . . 16 6.1.1. State Synchronization Message . . . . . . . . . . . . 14
6.1.2. Home Agent Hello Message . . . . . . . . . . . . . . . 17 6.1.2. Home Agent Control Message . . . . . . . . . . . . . . 16
6.1.3. State Synchronization Request Message . . . . . . . . 20 6.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 18
6.1.4. State Synchronization Message . . . . . . . . . . . . 21 6.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 20
6.1.5. Home Agent SwitchOver Request Message . . . . . . . . 22 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 20
6.1.6. Home Agent SwitchOver Reply Message . . . . . . . . . 23 6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 20
6.1.7. Home Agent SwitchBack Request Message . . . . . . . . 23 6.2.2. Binding Cache Information Option . . . . . . . . . . . 21
6.1.8. Home Agent SwitchBack Reply Message . . . . . . . . . 24 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 22
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. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 23
7.1. Home Agent Configuration . . . . . . . . . . . . . . . . . 29 7.1. Home Agent Address Configuration . . . . . . . . . . . . . 23
7.2. Hello messages Manipulation . . . . . . . . . . . . . . . 30 7.2. Consideration of Routing and Neighbor Discovery
7.2.1. Sending Hello Request . . . . . . . . . . . . . . . . 31 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2.2. Receiving Hello Request . . . . . . . . . . . . . . . 31 7.3. Home Agent List Management . . . . . . . . . . . . . . . . 24
7.2.3. Sending Hello . . . . . . . . . . . . . . . . . . . . 31 7.4. Detecting Home Agent Failure . . . . . . . . . . . . . . . 25
7.2.4. Receiving Hello . . . . . . . . . . . . . . . . . . . 32 7.5. Home Agent Switch Over . . . . . . . . . . . . . . . . . . 26
7.3. Failure Detection . . . . . . . . . . . . . . . . . . . . 32 7.6. Processing Hello Messages . . . . . . . . . . . . . . . . 27
7.4. Active Home Agent Change . . . . . . . . . . . . . . . . . 33 7.6.1. Requesting Hello Message . . . . . . . . . . . . . . . 27
7.5. Processing State Synchronization Messages . . . . . . . . 34 7.6.2. Sending Hello Message . . . . . . . . . . . . . . . . 27
7.5.1. Sending State Synchronization Request . . . . . . . . 34 7.6.3. Receiving Hello Message . . . . . . . . . . . . . . . 28
7.5.2. Receiving State Synchronization Request . . . . . . . 34 7.7. Processing State Synchronization Messages . . . . . . . . 28
7.5.3. Sending State Synchronization . . . . . . . . . . . . 34 7.7.1. Soliciting State of a Particular Mobile Node or
7.5.4. Receiving State Synchronization . . . . . . . . . . . 35 Subset of Mobile Nodes . . . . . . . . . . . . . . . . 29
7.6. Processing Home Agent SwitchOver Messages . . . . . . . . 35 7.7.2. Synchronizing State of Mobile Nodes . . . . . . . . . 30
7.6.1. Sending Home Agent SwitchOver Request . . . . . . . . 35 7.8. Processing Home Agent Control Messages . . . . . . . . . . 31
7.6.2. Sending Home Agent SwitchOver Reply . . . . . . . . . 36 7.8.1. Standby Home Agent becomes an Active Home Agent . . . 31
7.6.3. Receiving Home Agent SwitchOver Reply . . . . . . . . 36 7.8.2. Active Home Agent becomes in-active . . . . . . . . . 32
7.7. Processing Home Agent SwitchBack Messages . . . . . . . . 36 7.9. Sending Home Agent Switch Messages . . . . . . . . . . . . 32
7.7.1. Sending Home Agent SwitchBack Request . . . . . . . . 36 7.10. Interworking with VRRP . . . . . . . . . . . . . . . . . . 33
7.7.2. Sending Home Agent SwitchBack Reply . . . . . . . . . 37 7.11. Retransmissions and Rate Limiting . . . . . . . . . . . . 35
7.7.3. Receiving Home Agent SwitchBack Reply . . . . . . . . 37
7.8. Sending Home Agent Switch Message . . . . . . . . . . . . 37
8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 38 8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 36
8.1. Standby Home Agent Addresses Discovery . . . . . . . . . . 38 8.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 36
8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 38 8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 36
8.3. Receiving Home Agent Switch message . . . . . . . . . . . 39 8.3. Receiving Home Agent Switch message . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 47 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Change Log From Previous Versions . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Introduction 1. Introduction
In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a 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 bi-directional tunnel with their home agents for all traffic with
correspondent nodes. A home agent on the home link maintains a correspondent nodes. A home agent on the home link maintains a
binding cache entry for each mobile node and uses the binding cache 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 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 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 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 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 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 failure or some other reason, it results in a loss of service for the
mobile nodes. mobile nodes.
It would be very beneficial to provide high availability and It is beneficial to provide high availability and redundancy for a
redundancy for a home agent so that the mobile nodes can avail of home agent so that mobile nodes can avail of uninterrupted service
uninterrupted service even when one home agent crashes or loses even when one home agent crashes or loses state.
state.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3]. document are to be interpreted as described in [3].
In this document, the term mobile node refers to both a mobile node In this document, the term mobile node refers to both a mobile node
[1] and a mobile router [2]. [1] and a mobile router [2].
Some of the mobility related terms used in this document are defined Some of the mobility related terms used in this document are defined
in [1] and [7]. In addition or in replacement of these, the in [1] and [10]. In addition or in replacement of these, the
following terms are defined or redefined: following terms are defined or redefined:
Active Home Agent Active Home Agent
A home agent that is currently serving the mobile nodes A home agent that is currently serving the mobile nodes.
Standby Home Agent Standby Home Agent
A home agent which will serve the mobile nodes when the active A home agent which will serve the mobile nodes when the active
home agent fails. home agent fails.
Failed Home Agent Failed Home Agent
A home agent that is not available due to hardware or software A home agent that is not available due to hardware or software
failure, system maintenance, etc. failure, system maintenance, etc.
Redundant Home Agent Set Redundant Home Agent Set
A pair of an Active Home Agent and Standby Home Agent(s). The A group of active and standby home agent(s). The Group Identifier
Group Identifier is introduced to identify a Redundant Home Agent is used to identify a redundant home agent set. The Group ID is
set. The Group ID is exchanged by Hello messages. exchanged by Hello messages.
Binding Synchronization Binding Synchronization
Synchronization of binding cache entries within the redundant home Synchronization of binding cache entries within the redundant home
agent set agent set.
Home Agent Preference Home Agent Preference
This preference value is defined for DHAAD in RFC3775. This This preference value is defined for Duplicate Home Agent Address
protocol uses this preference value for home agent selection when Discovery (DHAAD) in RFC3775. This protocol uses this preference
an active home agent is failed. However, an operator can also value for home agent selection when an active home agent has
define an independent value only for home agent reliability failed. However, an operator can also define an independent value
protocol if the operator wants to have different preference value used only for the home agent reliability protocol if the operator
for DHAAD and home agent reliability protocol. A Home Agent wants to have different preference values for DHAAD and the home
SHOULD NOT use the same preference value of other Home Agents for agent reliability protocol. A home agent SHOULD NOT use the same
this protocol. preference value as other home agents for this protocol.
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.
3. Problem Statement
In Mobile IPv6 base specification, a mobile node registers and 3. Problem Statement and Requirements
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.
4. Goals for the Solution In Mobile IPv6 [1], a mobile node registers and establishes a binding
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 a
home agent, a mobile node can re-establish its connection through a
new home agent. However, the base Mobile IPv6 specification does not
address 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 coordination or pre-
configuration among the home agents regarding security associations,
transfer of mobile node bindings, and other service information for
reliable Mobile IPv6 service in a deployment scenario.
For the home agent reliability solution, we define the following For the home agent reliability solution, we define the following
requirements. requirements:
Reliable Home agent service Reliable Home agent service
Multiple home agents are available for a home prefix and one of Multiple home agents are available for a home prefix and one of
them is actively serves the mobile nodes. A standby home agent them actively serves the mobile nodes. A standby home agent takes
takes over when the Active Home Agent becomes unavailable. The over when the active home agent becomes unavailable. The transfer
transfer of the MN-HA association should be transparent to the of the MN-HA association should be transparent to applications and
application and should not take longer than care-of-addresses should not take longer than the care-of-addresses update procedure
update procedure described in the Mobile IPv6 [1]. described in Mobile IPv6 [1].
Availability of a redundant home agent set Availability of a redundant home agent set
Availability of an Active Home Agent address and a standby Home Availability of an active home agent address and a standby home
Agent address at the bootstrapping period to Mobile Node is agent address at the bootstrapping period for the mobile node is
assumed. assumed.
State Synchronization State Synchronization
The information for mobile nodes must be synchronized between an The information for mobile nodes must be able to be synchronized
Active Home Agent and Standby Home Agents. The information is between an active home agent and standby home agents. This
Binding Cache, IPsec/IKE states, AAA information, vendor specific includes the Binding Cache, AAA information, other Mobile IPv6 and
information. NEMO related information.
Consideration of IPsec/IKE transfer Consideration of IPsec/IKE transfer
An active home agent maintains several IPsec and IKE states for
An Active Home Agent maintains several IPsec and IKE states for
mobile nodes. These states are synchronized within the redundant mobile nodes. These states are synchronized within the redundant
Home Agent set. The details are described in Section 9. home agent set. The details are described in Section 9.
Secured Message Exchanges Secured Message Exchanges
The messages used between the home agents to transfer binding The messages used between the home agents to transfer binding
cache information MAY be authenticated and encrypted. cache information MAY be authenticated and encrypted.
Failure Detection Failure Detection
Redundant home agents must actively check for possible failure of Redundant home agents must actively check for possible failure of
an Active Home Agent. Periodic hello messages should be used to an active home agent. If a home agent supports an existing
detect Active Home Agent's service availability failure detection mechanism such as VRRP[4] or HSRP[5], it can re-
use that mechanism to detect the home agent failure. On the other
hand, periodic Hello messages are introduced to detect active home
agent's service availability in this document.
Failure Notification Failure Notification
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
5. Protocol Overview If necessary, a mobile node is notified about the active home
agent failure by the standby home agent.
This specification provides two modes for home agent local 4. Protocol Design
reliability.
o Home Agent Virtual Switch: In this mode the active and the Mobile IPv6 depends on IPsec and IKE for home binding registration as
redundant home agents are all accessible through the same IP described in [6]. A mobile node must encrypt a Binding Update sent
address. IPsec/IKE states must be synchronized between the active to a home agent. In addition, the mobile node exchanges HoTI and HoT
and a redundant home agent(s). The mechanism used to synchronize messages through the home agent by using IPsec tunnel mode.
IPsec state is currently considered out of scope for this document Therefore, before home agent failure, these IPsec states should be
and not described here. In this mode, a mobile node always synchronized among home agents of a redundant home agent set. A
establishes IPsec SAs only with the Active Home Agent. The IPsec mobile node may also encrypt particular data traffic sent to nodes in
state will be shared within the redundant home agent set in the Internet. IPsec information required by Mobile IPv6 is listed
background. In case there is a failure the Standby Home Agent below.
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 o Security Policy Database (SPD) and Selector Information
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 o Security Association (SA) for Binding Registration (SA1 and SA2)
state cannot be synchronized. In this mode, a standby home agent
must solicit mobile nodes to re-establish IPsec/IKE for Mobile o SA for HoTI/HoT Exchange (SA3 and SA4)
IPv6 signaling. This IPsec re-establishment is triggered when a
mobile node changes its home agent after receiving a home agent o SA for Mobile Prefix Discovery (SA5 and SA6)
switch message from a standby home agent. In order to exchange
this message securely between a Standby Home Agent and a mobile o SA for data packets if any (SA7 and SA8)
node, a mobile node need to establish IPsec SA with both an Active
Home Agent and redundant home agents beforehand. With this There are various ways this can be achieved. One is to setup
multiple IPsec SAs, a mobile node will receive a notification from multiple IPsec security associations between the mobile node and the
the Standby Home Agent and start to use the Standby Home Agent home agent sets. Another is to have the home agents periodically
when the Active Home Agent failed. check-point IPsec session state, including the per packet sequence
numbers, for the mobile node. Thus, we define two possible home
agent redundancy modes as follows:
Home Agent Virtual Switch
Each mobile node negotiates just one SA with an active home agent
in a redundant home agent set. The IPsec state will be shared
within the redundant home agent set in the background. The active
and the redundant home agents are addressed by the same home agent
address, although only tje active home agent is accessible by the
home agent address all of the time. IPsec/IKE states must be
synchronized between the active and standby home agents. The
mechanism used to synchronize IPsec state is considered out of
scope for this document. In case there is a failure of the active
home agent, the standby home agent takes over without the mobile
node being aware of the change in the home agent.
In a redundant home agent set, a single home agent address is used
by the active home agent. Thus, all the mobile nodes served by a
redundant home agent set MUST associate with the same home agent
(the active home agent) all the time.
Home Agent Hard Switch
The home agents are addressed by different IP addresses and the
mobile node is aware of the change of home agent. A Mobile node
and all home agents in a redundant home agent set negotiate
independent IPsec SAs. This mode is especially useful when the
IPsec/IKE states cannot be synchronized. However, the home agent
change is not transparent to the mobile node. When an active home
agent fails, a mobile node will receive a notification (a Home
Agent Switch message [11]) from a standby home agent, and send a
Binding Update to the standby home agent. In order to exchange
the Home Agent Switch message securely between the standby home
agent and a mobile node, the mobile node needs to establish an
IPsec SA with both the active and the standby home agents in the
redundant home agent set beforehand.
Since each home agent has a different address, an active home
agent can be defined for each mobile node. When a mobile node
boots, it will discover home agents and create IPsec SAs with
them. It will then decide which one of the home agents is its
active home agent. For example, when two home agents serve a home
network, half of the mobile nodes might register with one home
agent and the rest of mobile nodes with another home agent. When
one of the home agents fails, a standby home agent, whose
preference value is next highest than the failed home agent, can
trigger a home agent switch by sending a Home Agent Switch message
to the mobile nodes that were registered with the failed home
agent.
In both the cases, the mobile node maintains only one home binding at
any given time. In the Home Agent Hard Switch mode, the mobile node
needs to switch its binding from the active to standby home agent
upon failover. The bindings are synchronized among home agents in
the redundant home agent set in the background when the Home Agent
Virtual Switch mode is used.
All new messages defined in this document are defined as Mobility All new messages defined in this document are defined as Mobility
Header messages so that the HA reliability protocol can be extended Header messages so that the Home Agent Reliability protocol can be
later, if needed, to provide home link redundancy. (i.e. Protocol is extended to provide home link redundancy.
not tight with the link boundary)
5.1. Home Agent Virtual Switch Finally, the reasons why we defined a new Hello message instead of
using VRRP is described in Section 7.3 and Section 7.4. We also give
instructions on how operators can run both VRRP and the Home Agent
Reliability protocol at the same time in Section 7.10.
In the case of the virtual home agent switch, a mobile node remains 5. Protocol Overview
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
received by the mobile node passes ESP replay check.
The operations of the Home Agent Virtual Switch are shown in 5.1. Home Agent Network Configuration
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 The Home Agent Reliability protocol supports two different
Home Agent activates the IP address of the failed home agent on it configurations for standby home agents. Standby home agents can be
and takes over from the Failed Home Agent. All the home agents in placed on the same home link as the active home agent, or on a
the redundant home agent set share a virtual address and the routing different link. The Global Recovery described below is not included
will ensure only the Active Home Agent will be reachable using that in this document, although the Home Agent Reliability protocol can
virtual address. The Standby Home Agent can serve all the mobile support this with slight modifications to home agent operations.
nodes for which the states are synchronized, without any further
message exchange because it has all the necessary information which HA1 HA2 HA3 HA4 .... HAn
it obtained from the failed home agent. | | | | |
--------+------+------+------+--------+---------
Home Link
Figure 1: Local Recovery Configuration
Figure 1 depicts the configuration where home agents serving the same
home network are located on the same link. For example, HA2, HA3 and
HA4 are standby home agents of HA1. This is the same as what Mobile
IPv6 defines for home agent configuration.
---------IGP------>|<---BGP--->|<-----IGP---------
HA1 HA2 HA3 HA4
| | | |
--------+------+-----+ R---R---R +-----+------+-------
Home Link Routers Recovery Link
Figure 2: Global Recovery Configuration
Figure 2 illustrates when standby home agents are located on a
different link (named the recovery link in Figure 2). HA3 and HA4
are standby home agents of HA1 and HA2. In this case, HA3 and HA4
cannot receive packets meant for the home network until the route on
the Routers is changed. The advantage of this configuration is that
standby home agents can recover from a failure of the home link.
This configuration can achieve 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.
This geographic redundancy is not a requirement by any SDO (Standards
Development Organization), but is required by operators. Most large
operators have a very stringent requirement on network availability
even in the worst type of disaster or outage. For example, critical
nodes in region-1 are backed up by nodes in region-2. These two
regions are geographically separated. If region-1 suffers a downtime
due to any reason, all the sessions will be seamlessly taken over by
the nodes in region-2. This is called geographic redundancy. This
is a well-known configuration for Telecommunications operators.
5.2. Home Agent Virtual Switch
A mobile node remains unaware about the change in the active home
agent since the home agents have replicated all session state
including the IPsec/IKE/ESP states. The IPsec/IKE/ESP state transfer
is out of scope of this document.
MN HA1(active) HA2(Standby) MN HA1(active) HA2(Standby)
| | . | | .
|<--------->| . 1. IPsec/IKE |<--------->| | 1. IKE exchange (with HoA assignment)
| | .
|---------->| . 2. Binding Update |---------->| . 2. Binding Update
|<----------| . 3. Binding Acknowledgement |<----------| . 3. Binding Acknowledgment
| | . | | .
| |<--------->. 4. State exchanges (Binding cache/IPsec) | |<--------->. 4. State exchanges (binding cache/IPsec)
| | . | | .
| X . HA1 FAILURE | X . HA1 FAILURE
| X . | X .
| X<----------. 5. Failure Detection | X<----------. 5. Failure Detection
| X |
| X | 6. HA2 takes over the HA1 | X | 6. HA2 takes over the HA1
| X | | X |
| X | RECOVERY COMPLETE | X | RECOVERY COMPLETE
Figure 1: Overview of Home Agent Virtual Switch Figure 3: Overview of Home Agent Virtual Switch
5.2. Home Agent Hard Switch The operations of the Home Agent Virtual Switch mode are shown in
Figure 3. The mobile node first attempts the IKE exchange for
Security Association (SA) setup and home address assignment (1).
After binding registration is done (2, 3), the active home agent
pushes all the states of its mobile nodes with a state
synchronization message (4). The standby home agent(s) is not active
unless it takes over from a failed home Agent.
The Home Agent Hard Switch is shown in Figure 2. This mode is not When the active home agent's failure is detected (5), the standby
transparent to mobile node when there is a home agent failure and home agent activates the IP address of the failed home agent on it
another home agent takes over. and takes over for the failed home agent. All the home agents in the
redundant home agent set share a virtual home agent address and the
routing will ensure only the active home agent will be reachable
using that virtual home agent 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.
5.3. Home Agent Hard Switch
The overview of the Home Agent Hard Switch is shown in Figure 4.
This mode is not transparent to the mobile node when the active home
agent failure occurs.
MN HA1(active) HA2(Standby) MN HA1(active) HA2(Standby)
| | | | | |
|<--------->| | 1. IKE exchange (w/HoA assignment) |<--------->| | 1. IKE exchange (with HoA assignment)
| | |
|---------->| | 2. Binding Update |---------->| | 2. Binding Update
|<----------| | 3. Binding Acknowledgement |<----------| | 3. Binding Acknowledgment
| | | |<--------------------->| 4. IKE exchange (without HoA assignment)
|<--------------------->| 4. IKE exchange (wo/HoA assignment)
| | | | | |
| |<--------->| 5. State Exchanges | |<--------->. 5. State exchanges (binding cache)
| | | | | |
| X | HA1 FAILURE | X | HA1 FAILURE
| X | | X |
| X<----------| 6. Failure Detection | X<----------| 6. Failure Detection
| X | |<----------------------| 7. Sending Home Agent
|<----------------------| 7. Sending home agent
| X | Switch message | X | Switch message
| X | |<--------------------->| 8. Binding Registration
|<--------------------->| 8. Binding Registration (optional)
| X | | X |
| X | RECOVERY COMPLETE | X | RECOVERY COMPLETE
Figure 2: Overview of Home Agent Hard Switch Figure 4: 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
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 The mobile node establishes IPsec/IKE state with all the home agents
takes over from a failed home agent. This operation is common for in the redundant home agent set beforehand (1 and 4), however it
both the hard and the virtual switch modes. The home agent whose registers its binding only with the active home agent (2 and 3).
preference is the highest among the Standby Home Agents takes over When an active home agent fails, a standby home agent uses a pre-
immediately after it detects failure of the Active Home Agent. The existing IPsec SA to notify the mobile node about the failure by
preference value can be same as the home agent preference value of securely sending a Home Agent Switch message. In order to discover
RFC3775, while the operator can define an independent value only for home agent addresses, two different mechanisms are defined, as
home agent reliability protocol. described in Section 8.1. The active home agent synchronizes the
required states of the mobile nodes, such as Binding Cache and AAA
information, with other standby home agents periodically (5). The
mobile node MUST NOT request a home address(es) assignment through
the IKE exchange to the standby home agent when it establishes an SA
with it (4).
The Home Agents in the redundant Home Agent set exchange periodic When the standby home agent detects the failure of the active home
Hello messages to convey their information to the peers (1). The agent (6), it sends a Home Agent Switch message to all the mobile
Hello messages can either be unicast or multicast. In order to nodes that were registered with the failed home agent (7). The Home
explicitly query the state information of its peer(s), any Home Agent Agent Switch message must be encrypted by a pre-established IPsec SA.
can send a Hello request to its peer(s) in the redundant Home Agent After the switch message, the mobile node MUST send a binding update
set. The Hello message exchange is the basis of failure detection to the new active home agent in order to update the Mobile IPv6
and automatic switchover in this scheme (3 and 4). tunnel end points (8).
When HA1 recovers in Figure 3, it needs to remain in the standby 5.4. Active Home Agent Management
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 HA1(active) HA2 HA3 .. HAn
| | | | | | | |
|------->| | | 1. HA1 sends SwitchBack Request |------->| | | 1. HA1 sends SwitchBack Request
|<-------| | | 2. HA2 sends SwitchBack Reply |<-------| | | 2. HA2 sends SwitchBack Reply
| | | | | | | |
(standby) (active) | | HA2 BECOMES ACTIVE HA (standby) (active) | | HA2 BECOMES ACTIVE HA
| | | | | | | |
SYSTEM MAINTENANCE, ETC. SYSTEM MAINTENANCE, ETC.
| | | | | | | |
|------->| | | 3. HA1 sends SwitchOver Request |------->| | | 3. HA1 sends SwitchOver Request
|<-------| | | 4. HA2 sends SwitchOver Reply |<-------| | | 4. HA2 sends SwitchOver Reply
| | | | | | | |
(active) (standby) | | 5. HA1 returns to active HA (active) (standby) | | 5. HA1 returns to active HA
| | | | HA1 BECOMES ACTIVE AGAIN | | | | HA1 BECOMES ACTIVE AGAIN
Figure 4: Manual Home Agent Change Figure 5: Manual Home Agent Change
In some scenarios the Active Home Agent may need to stop serving the In some scenarios the active home agent may need to stop serving
mobile nodes for system maintenance. This specification provides mobile nodes for system maintenance. This specification provides for
manual home agent change by using Home Agent SwitchBack Request and a manual home agent switch by using SwitchBack Request and Reply
Reply messages. As shown in Figure 4, the Active Home Agent (HA1) messages. As shown in Figure 5, the active home agent (HA1) sends a
sends Home Agent SwitchBack Request to an Standby Home Agent. As SwitchBack Request message to a standby home agent (HA2). As soon as
soon as HA2 receives the message, it becomes the Active Home Agent. HA2 receives the message, it becomes the active home agent. HA2 will
HA2 also acknowledges with the Home Agent SwitchBack reply to HA1. acknowledge the message by sending a SwitchBack Reply message to HA1.
HA1 becomes standby when it receives the SwitchBack reply. After the HA1 becomes a standby home agent when it receives the SwitchBack
downtime, HA1 sends a Home Agent SwitchOver Request to HA2 in order Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in
to return to become an Active Home Agent again. This operation is order to become the active home agent again.
same as Figure 3
6. Messages 6. Messages
This document defines following new messages: 6.1. New Mobility Header Messages
o New Mobility Header Messages 6.1.1. State Synchronization Message
* Home Agent Hello Request Message This message is used to exchange state corresponding to a particular
mobile node. It MUST be unicasted and MUST be authenticated by IPsec
ESP. 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:
* Home Agent Hello 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* State Synchronization Request Message Figure 6: State Synchronization Message
* State Synchronization Message Type
* Home Agent SwitchOver Request Message 8-bit unsigned integer. It can be assigned one of the following
values:
* Home Agent SwitchOver Reply Message 0: Request
* Home Agent SwitchBack Request Message This message is called State Synchronization Request and used
to request state corresponding to a particular mobile node.
The State Synchronization Request is used to solicit the active
state corresponding to a particular mobile node.
* Home Agent SwitchBack Reply Message 1: Reply
o New Mobility Options The message is called State Synchronization Reply and is used
between the home agents in the redundant home agent set to
exchange binding cache information and any other information
related to providing mobility service to the mobile nodes. The
State Synchronization Reply can be sent by an active home agent
either periodically or in response to a State Synchronization
Request.
* Binding Cache Information Option Reserved
* AAA Information Option 8-bit unsigned integer. It must be initialized to zero by the
sender and must be ignored by the receiver.
* Vendor Specific Information Option Identifier
We may add more mobility options in the future document. The DT is A 16-bit identifier to aid in matching state synchronization
currently discussing the needs and the formats of IPsec/IKE state messages. The identifier should never be set to 0. It should
information Option and BGP/OSPF modifier option for state always be more than 1.
synchronization message.
Home Agent Switch message is defined in [8]. This message is also Mobility Options
used in operation of Home Agent Hard Switch.
6.1. New Mobility Header Messages 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.
6.1.1. Home Agent Hello Request Message One of the following options is mandatory in State Synchronization
Request message. :
The message is unicasted to a home agent to solicit a Hello message * IP Address Option (Sub-type: Home Address)[12]. If a home
from a home agent. The receiver of this Hello Request message MUST agent wants the Binding Cache information for a particular
return a Hello message to the originator of this request message. A mobile node, it includes an IPv6 Address Option.
Home Agent Hello message SHOULD be authenticated and encrypted by
IPsec ESP.
The Hello Request message has the MH Type value TBD. When this value * Mobile Network Prefix Option. If a home agent wants to know
is indicated in the MH Type field, the format of the Message Data the forwarding state setup for a particular Mobile Network
field in the Mobility Header is as follows: Prefix, it includes a Mobile Network Prefix Option as defined
in [2].
* Vendor Specific Mobility Option. If a home agent wants vendor
specific information, it can solicit with this option as
defined in [7].
One of the following options is mandatory in State Synchronization
Reply. :
* Binding Cache Information Option
* AAA Information Option
* Vendor Specific Mobility Option
This message requires at least one mobility option, therefore, there
is no default length for this message.
6.1.2. Home Agent Control Message
This message is used to control the status of a home agent to either
active or standby. This message MUST be unicasted between home
agents and MUST be authenticated and encrypted by IPsec ESP. The
Home Agent Control 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
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 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 # | | Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . . .
. Mobility Options . . Mobility Options .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Home Agent Hello Request Message Figure 7: Home Agent Control Message
Sequence # Type
16-bit unsigned integer. The Sequence number of the Hello message 8-bit unsigned integer. It can be assigned one of the following
can be used to verify whether this Hello message is the latest one values:
or not.
0: SwitchOver Request
This message is called SwitchOver Request. It is unicasted by
a standby home agent that desires to become the active home
agent. The receiver of the message MUST transition to standby
state as soon as the message is received and validated
successfully.
1: SwitchOver Reply
This message is called SwitchOver Reply. It is used to
acknowledge the receipt of the corresponding SwitchOver
Request.
2: SwitchBack Request
This message is called SwitchBack Request. It is unicasted by
an active home agent that desires to become the a standby home
agent. The receiver of this message SHOULD transition to
active state as soon as the message is received and validated
successfully.
3: SwitchBack Reply
This message is called SwitchBack Reply. It is used to
acknowledge the receipt of the corresponding SwitchBack
Request.
Status
8-bit unsigned integer indicating the disposition of a Switchover
Request or SwitchBack Request message. This field is only valid
in SwitchOver Reply and SwitchBack Reply messages. The following
Status values are defined:
0: Success
128: Reason unspecified
129: Administratively prohibited
130: Not active home agent (The receiver of the SwitchOver
Request message is not the active home agent)
131: Not standby home agent (The receiver of the SwitchBack
Request is already the active home agent)
132: Not in same redundant home agent set
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of [1]. and format of defined options are described in [1]. The receiver
The receiver MUST ignore and skip any options which it does not MUST ignore and skip any options which it does not understand. No
understand. There MAY be additional information, associated with options are defined in this specification
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 If no options are present in this message, no padding is necessary
and the Header Len field will be set to 1. and the Header Len field will be set to 1.
6.1.2. Home Agent Hello Message 6.1.3. Home Agent Hello Message
The message is either unicasted or multicasted to carry Home Agent This messages can be replaced by other protocols as described in
information among the Redundant home agent set. This Hello message Section 7.10. If this message is used, it MUST be either unicasted
is used by any home agents to detect the failure of a redundant peer or multicasted to carry home agent information among the redundant
in the redundant Home Agent set. This message can be sent either home agent set. The Hello message is defined for two purpose: 1) an
periodically or in reply to Hello Request message. A home agent alive check and 2) home agent information exchange. A home agent
Hello message SHOULD be authenticated and encrypted by IPsec ESP when Hello message SHOULD be authenticated and encrypted by IPsec ESP when
it is unicasted. If a Hello message is multicasted, IPsec ESP cannot it is unicasted. If a Hello message is multicasted, IPsec ESP cannot
be applied. Hence if multicast is used, the redundant Home Agent set be applied. In this case the redundant home agent set should be
should be in a secure network. located in a secure network. Alternatively, all the home agents MUST
have a secure channel with each other. The Hello message has the MH
The Standby Home Agents and the Active Home Agent must exchange the Type value TBD. When this value is indicated in the MH Type field,
home agent information. Although Mobile IPv6 uses a router the format of the Message Data field in the Mobility Header is as
advertisement to exchange home agent information periodically, the follows:
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
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 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 # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime | | Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | Group ID |A| Reserved | | Hello Interval | Group ID |A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility Options . . Mobility Options .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Home Agent Hello Message Figure 8: Home Agent Hello Message
Sequence # Sequence #
16-bit unsigned integer. The Sequence number of the Hello message 16-bit unsigned integer. The Sequence number of the Hello message
can be used to verify whether this Hello message is the latest one can be used to verify whether this Hello message is the latest one
or not. or not.
Home Agent Preference Home Agent Preference
16-bit unsigned integer. The preference for the home agent 16-bit unsigned integer. The preference for the home agent
sending this hello. This preference is same as the home agent sending this Hello message. This preference is the same as the
preference value of home agent information option defined in Home Agent Preference value of the Home Agent Information option
Mobile IPv6. However, if operators want to use the different as defined in [1]. However, operators MAY use a different
preference value for this operation, it can use different value preference value for this operation.
from the preference defined in RFC3775
Home Agent Lifetime Home Agent Lifetime
16-bit unsigned integer. The lifetime for the home agent sending 16-bit unsigned integer. The lifetime for the home agent sending
this Hello. This lifetime is same as the home agent Lifetime this Hello message. This lifetime is the same as the Home Agent
value of home agent information option defined in Mobile IPv6. Lifetime value of the Home Agent Information option as defined in
[1].
Hello Interval Hello Interval
16-bit unsigned integer. The interval for the home agent sending 16-bit unsigned integer. The interval for the home agent sending
this Hello. this Hello message.
Group Identifier Group Identifier
8-bit unsigned integer. This value is used to identify a 8-bit unsigned integer. This value is used to identify a
particular redundant home agent set. particular redundant home agent set.
A flag A flag
If this flag is set, the sender of this Hello message is an Active If this flag is set, the sender of this Hello message is an active
Home Agent. Otherwise, the sender is Standby Home Agent home agent. Otherwise, the sender is standby home agent
R flag
If this flag is set, the receiver of this Hello message must send
back a Hello message to the sender.
Reserved Reserved
7-bit unsigned integer. It must be initialized to zero by the 6-bit unsigned integer. It must be initialized to zero by the
sender and must be ignored by the receiver. sender and must be ignored by the receiver.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [1]. The receiver and format of defined options are described in [1]. The receiver
MUST ignore and skip any options which it does not understand. MUST ignore and skip any options which it does not understand. No
valid options are defined in this specification.
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
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 If no options are present in this message, 0 octets of padding are
necessary and the Header Len field will be set to 2. necessary and the Header Len field will be set to 2.
6.1.3. State Synchronization Request Message 6.1.4. Home Agent Switch 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 message is defined in Section 8.3. The Home Agent Reliability
this value is indicated in the MH Type field, the format of the protocol extends this message for the Home Agent Hard Switch.
Message Data field in the Mobility Header is as follows:
0 1 2 3 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 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 | |# of Addresses |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . + +
. Mobility Options . . Home Agent Addresses .
. . + +
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 . . Mobility options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: State Synchronization Message Figure 9: Home Agent Switch Message
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
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
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 IPsec Re-key (I)
to 128 indicate that the Home Agent SwitchBack Request was
rejected by the receiving node. The following Status values are
currently defined:
0: success The IPsec rekey (I) bit is set to indicate that the mobile node
128: The receiver of Home Agent SwitchBack Request is already SHOULD start an IPsec re-key with the home agent specified in the
the Active Home Agent Home Agent Addresses field. This flag is used when a failed home
agent recovers and needs to re-establish IPsec SA/IKE state with a
mobile node.
129: failed, Admin Prohibited. Reserved
No padding is necessary and the Header Len field will be set to 1. The reserve field is reduced from 8 to 7 bits
6.2. New Mobility Options 6.2. New Mobility Options
6.2.1. IP address Option 6.2.1. IP address Option
This option is already defined at FMIP specification[9]. This This option is already defined in the Fast Handovers for Mobile IPv6
document introduces new Sub-Type value for home agent address and (FMIP) specification [12]. This document introduces new Sub-Type
Home Address. values for home agent address and Home Address.
Option-Code Option-Code
* 4: Home Agent Address * 4: Home Agent Address
* 5: Home Address * 5: Home Address
6.2.2. Binding Cache Information Option 6.2.2. Binding Cache Information Option
The binding cache information option has an alignment requirement of The binding cache information option has an alignment requirement of
8n+2. Its format is as follows: 8n+2. Its format is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 37 skipping to change at page 21, line 43
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. Mobile Network Prefix Option . . Mobile Network Prefix Option .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Binding Cache Information Option Figure 10: Binding Cache Information Option
The binding cache information option is valid in a state The Binding Cache Information option is only valid in a State
synchronization message. Synchronization message.
The fields of Home Address, Care-of Address, Flags, Sequence Number, The fields of Home Address, Care-of Address, Flags, Sequence Number,
and Lifetime are copied from the registered binding of a particular and Lifetime are copied from the registered binding of a particular
Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to mobile node or mobile router. The 8-bit Reserved field MUST be set
zero. 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
If the R-flag is set to indicate this binding cache entry is for a by one or more Mobile Network Prefix options.
Mobile Router, then this option will be immediately followed by one
or more Mobile Network Prefix options.
6.2.3. AAA Information Option 6.2.3. AAA Information Option
The AAA option is used to carry the AAA state of the Mobile Node's 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 Mobile IPv6 sessions. The AAA state information can be conveyed in
or Diameter AVP formats including the user and session info. This RADIUS or Diameter AVP formats including the user and session info.
information option is valid in a state synchronization message. This information option is only valid in a State Synchronization
message.
0 1 2 3 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 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 | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. AAA AVPs . . AAA AVPs .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Vendor Specific Inforamtion Option Figure 11: Vendor Specific Inforamtion Option
Type Type
8-bit Type value. The value is TBD. 8-bit Type value. The value is TBD.
Length Length
8-bit length value. 8-bit length value.
AAA AVPs AAA AVPs
Series of TLV encoded AAA AVPs (including vendor specific AVPs) Series of TLV encoded AAA AVPs (including vendor specific AVPs)
carrying AAA related information for each MIP6 and IPsec/IKE carrying AAA-related information for each Mobile IPv6 and IPsec/
sessions. IKE session.
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 7. Home Agent Operation
The Vendor Specific information option is used to carry the vendor 7.1. Home Agent Address Configuration
specific information of a home agent. The Vendor Specific
information option is valid in a state synchronization message.
0 1 2 3 Each standby home agent obtains its individual IPv6 address from its
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 attached link. This IPv6 address is used by the home agent
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reliability protocol to exchange information with the associated home
| Type = TBD | Length | agents. The link between home agents should be secured.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Vendor Specific Information .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Vendor Specific Inforamtion Option When the Home Agent Virtual Switch mode is used, the virtual home
agent IPv6 address which is known by the mobile node is shared with
the standby home agents. When a home agent fails, the standby home
agent activates the IPv6 address of the failed home agent and becomes
the active home agent. The standby home agent should not activate
the IPv6 address until it knows the active home agent is no longer
reachable at the address, otherwise address duplication will occur.
To guarantee transparency of the home agent virtual switch to mobile
nodes located on the home link, the neighbor cache of the home agent
IP address MUST be carefully operated. See Section 7.2 in detail.
Type When the Home Agent Hard Switch mode is used, each home agent
configures itself with a different IPv6 address from the same home
prefix. This IPv6 address can be used for the Home Agent Reliability
protocol if the standby home agents are located at the same link of
the active home agent (Figure 1). In case of Figure 2, the router
must carefully route packets to the standby home agents as described
in Section 7.2. Once a mobile node registers its binding with the
active home agent, it may solicit an IPsec/IKE exchange with standby
home agents. These packets must be routed to the recovery link.
This can be achieved by installing host routes for the standby home
agents on the recovery link of the router.
8-bit Type value. The value is TBD. 7.2. Consideration of Routing and Neighbor Discovery Protocol
Length This section gives a brief explanation of how a home agent interacts
with routing and Neighbor Discovery Protocol (NDP) when the Home
Agent Virtual Switch mode is used.
8-bit length value. When a standby home agent becomes active in the Home Agent Virtual
Switch mode, it MUST start to 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 operation is
normally done using a route selector such as BGP or an OSPF modifier.
For example, we can use the AS_Path prepend operation for BGP, and
the Metric field in OSPF for route selection.
Vendor Code For instance, home agents should run OSPF with the appropriate cost
so that the active home agent whose preference is highest can receive
the packets from the other routers on the home link. When the active
home agent is down, OSPF detects the failure and can dynamically
switch the route to the standby home Agent based on the OSPF cost
value. If this cost conflicts with the home agent preference value
due to misconfiguration, the routers on the home link may not route
packets to the desired standby home agent. Therefore, the home agent
MAY dynamically change the OSPF cost based on the home agent
preference value. Most of router vendors have a private MIB to set
the cost via SNMP, though this is a vendor-specific function. The
operator can consider other existing approaches to update routes on
the routers at the home link.
16-bit vendor code can be defined by each vendor. When an active home agent activates a home agent address, it SHOULD
use a virtual MAC address as introduced in [4]. When the active home
agent is changed, the neighbor cache of the active home agent is not
necessarily updated on mobile nodes located on the home link.
Otherwise, the new home agent MUST update the neighbor cache entry
for the home agent address on all the mobile nodes located on the
home link. In addition, Mobile IPv6 uses proxy NDP to intercept
packets meant for mobile nodes which are away from the home link.
However, it is unnecessary for the new active home agent to overwrite
the existing proxy neighbor entries of the mobile nodes.
Reserved 7.3. Home Agent List Management
16-bit field reserved for future use. The value SHOULD be In Mobile IPv6 [1], each home agent periodically sends router
initialized to zero by the sender, and MUST be ignored by the advertisements with a Home Address Information option [1] for
receiver. exchanging home agent information when there are multiple home agents
present on a link. This information is managed in a home agent list
introduced in [1]. When the Home Agent Reliability Protocol is used,
Hello messages are used to update the home agent list. There are
several reasons to use Hello message instead of Router Advertisement
on the Home Agent Reliability protocol:
7. Home Agent Operation 1. Router Advertisements are sent among home agents and also to
mobile nodes. When the Home Agent Virtual Switch is used,
standby home agents MUST NOT generate unsolicited Router
Advertisements. The standby home agents MUST be transparent to
all mobile nodes. Hello messages are exchanged only with other
home agents.
7.1. Home Agent Configuration 2. Router Solicitation and Advertisement messages [8] cannot be used
due to link-local limitations. However, as shown in Section 5.1,
standby home agents are not always configured on the same link.
Router Advertisements cannot be used in this case.
There are two approaches to place Standby Home Agents. The first 3. The Home Agent Reliability protocol is required to exchange
configuration is that a Standby Home Agent is located at the same additional information such as Group ID and Active/Standby Status
link (i.e. home link) of home agents. Another one is that the of the home agents.
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 When Hello messages are used, the Home Agent Information Option [1]
| | | | | MAY NOT be used in Router Advertisements on the home link, because
--------+------+------+------+--------+--------- all necessary information will be present in the Hello messages.
Home Link However, mobile nodes located on the home link require this
information for home agent discovery. In addition, if operators want
to use different parameters such as Preference value for home agents
and mobile nodes, they can utilize both Router Advertisements and
Hello messages. Router Advertisements are used to carry the home
agent information for mobile nodes, and Hello message are used to
carry information for Home Agent Reliability operation. If an
operator decides not to use the Hello messages, Router Advertisements
MUST be used to update the home agent list.
Figure 16: Local Recovery Configuration Since Hello messages carry all the necessary information filled-in
from the home agent list, the management of the home agent list is
unchanged. If a standby home agent removes an active home agent from
the list because it's lifetime has become zero, it can start recovery
according to this document. < xref target="subsec:failuredetection"/>
describes failure detection in detail.
Figure 16 depicts the configuration where home agents serving the 7.4. Detecting Home Agent Failure
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 The active and standby home agents can monitor each other's status in
| | | | multiple ways. One method is to reuse other failure detection
--------+------+-----+ R +-----+------+------- mechanisms such as VRRP[4] and HSRP[5] described in Section 7.10.
Home Link Router Recovery Link This document also defines its own method by using periodic exchanges
of Hello messages to monitor status. The reasons to specify Hello
messages are:
Figure 17: Global Recovery Configuration 1. Hello messages can be sent off-link for global recovery is
required by an operator. Router Advertisements cannot be used in
this scenario since their scope is link-local. Thus, Hello
messages are necessary to exchange home agent information among
home agents in a globally redundant home agent set.
Figure 17 illustrates when standby home agents are located on 2. If Router Advertisements and VRRP are used for periodic messages,
different link (named recovery link in the figure). For example, HA3 they may not detect the case where the system is running but the
and HA4 are standby home agents of HA1 and HA2. In this case, HA3 Mobile IPv6 stack is not operational. Mobile IPv6 may be
and HA4 cannot receive the packets meant for the home network till implemented as a userland daemon, so if Hello messages are used,
the route on the Router is changed. The advantage of this the failure of a home agent can be easily detected, assuming
configuration is that Standby Home Agents can recover the failure of Hello message functionality is implemented in the same home agent
the home link. If the home link becomes unreachable, the local daemon.
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 3. Hello messages can be frequently exchanged to detect failure,
link. This IP address is used for home agent reliability protocol to while there is a restriction on how often Router Advertisements
exchange information with the associated home agent. The link can be sent, and on how they are processed by routers that
between home agents should be secured. receive them. Router Advertisements are also not sent frequently
enough to rely on their absence to detect a home agent failure.
When Home Agent Virtual Switch is used, the home agent's IP address A Hello request message (R-flag set) may be used by any home agent to
which is known by the mobile node can be shared with Standby Home request state information from any other home agent in the redundant
Agents. When a home agent fails, the standby home agent takes the IP home agent set. If a Hello message is not received from a home agent
address out of the failed home agent. Then the Standby Home Agent peer within a configurable amount of time, then that home agent peer
can uses the IP address for further home agent operations as being an is considered to have failed. The detail of the Hello message is
Active Home Agent. The Standby Home Agent should not activate the IP described in Section 7.6. Failure events used in the Home Agent
address until the Active Home Agent is dead and the reachability to Reliability protocol are listed below.
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 Loss of Communication with the Active Peer Home Agent
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 In the event that a standby home agent does not receive any Hello
message from its peer which is currently the active home agent for
a configurable duration, the standby home agent may decide to
become the active home agent.
Mobile IPv6 [1] defines a mechanism for maintaining a home agent list Monitored Server Failure by the Active Home Agent
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 There may be number of critical servers in the network that are
Section 6.1.1 and Section 6.1.2 to notify similar information of essential for the ongoing Mobile IPv6 sessions at the home agent.
Router Advertisement among home agents over the home link. 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 a switch-
over procedure upon detecting that the link to such a server has
failed.
7.2.1. Sending Hello Request Routing Peer/Link Failure
A home agent can solicit a Hello message by sending a Hello Request In some cases, an operator may require the home agent to detect a
message. The Hello Request message is unicasted to an Active Home next-hop routing peer failure. If the next-hop routing peer
Agent or a Standby Home Agent. This message should be encrypted and fails, the operator may want the home agent to initiate a switch-
authenticated by IPsec ESP mode. An originator of the Hello Request over procedure if the failure is fatal in nature, or due to some
message must specify the random sequence value. The sequence value other routing policies.
is used to match the Hello message which is sent from the receiver of
the Hello Request message.
7.2.2. Receiving Hello Request 7.5. Home Agent Switch Over
When a home agent receives a hello Request message, it SHOULD verify After detecting the active home agent has failed, a standby home
correct IPsec protection. If the message is not protected, it SHOULD agent whose preference value is the highest MUST take over for the
be silently discarded. However, if the Hello messages can be sent on failed home agent.
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, In the Home Agent Virtual Switch mode, the standby home agent MUST
the message MUST be silently ignored, too. activate the virtual home agent address. If a virtual MAC address as
introduced in [4] is used, the standby home agent MUST start using
the virtual MAC address as well. Since all the necessary state has
already been transferred to this standby home agent before the active
home agent failed, it can immediately start acting as the active home
agent.
The sequence field should be copied to the Hello message which will In the Home Agent Hard Switch mode, the standby home agent MUST send
be sent in reply to the hello Request message. This sequence number a Home Agent Switch message to all the mobile nodes that were
is used as a transaction ID for the Hello message exchange. registered at the failed home agent as described in Section 7.9,
using the pre-established IPsec SA. The home agent switch-over is
complete when it receives binding updates from all the mobile nodes.
7.2.3. Sending Hello 7.6. Processing Hello Messages
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 Hello messages can be unicasted or multicasted. A new multicast
address will be assigned by the IANA. All the home agents on the address will be assigned by the IANA. When all home agents in a
home link should join this multicast address. When the Hello redundant home agent set are configured on a same home link, they
messages are used for maintaining the home agents list, the home MUST join a new multicast address (TBA) and multicast Hello. On the
agent SHOULD NOT use the home agent Information option in the router other hand, if a home link is separated as described in Figure 2,
advertisements to manage the home agents list. each home agent MUST unicast Hello messages.
The Hello message MUST be sent when a home agent is requested by a 7.6.1. Requesting Hello Message
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 A home agent can solicit a Hello message from a particular home agent
Messages. in the same redundant home agent set by unicasting or multicasting a
Hello message with the R-flag set. The sender MUST fill the fields
of the Hello message with it's home agent information. When a Hello
message is unicasted, only the destination of the Hello message will
answer it. On the other hand, if a Hello message is multicasted, all
the home agents in the multicast group will reply to the Hello
message. This Hello request message SHOULD be generated when:
7.2.4. Receiving Hello o A new home agent needs to collect information of the other home
agents in the same redundant home agent set. In this case it
SHOULD multicast a Hello message in which the R-flag is set.
The receiver of a Home Agent Hello message MUST verify the source o A home agent entry in the redundant home agent list is about to be
address field of the IPv6 header. If a Home Agent Hello message is removed due to home agent lifetime expiration.
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 o A Hello message has not been received during the specified hello
processed to update its home agent list. The Home Agents list can be interval.
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 7.6.2. Sending Hello Message
When a home agent meets an error and cannot fulfill home agent The Hello message MUST be sent when a home agent receives a Hello
functionality, the Standby Home Agent must detect the failure and message with the R-flag set, indicating a request is required,
should act as the Active Home Agent. The failure detection is otherwise Hello messages are periodically sent according to the pre-
important feature of Home Agent local reliability. configured Hello interval. In addition, a home agent SHOULD send a
Hello message to the home agents of the redundant home agent set when
it boots up and its local information, such as home agent preference,
home agent lifetime, and registration status, etc., change. When a
new home agent boots up, it SHOULD solicit Hello messages by
multicasting a Hello message with the R-flag set in parallel with
sending own Hello message.
The most common way to detect failure is using periodic message Whenever a home agent generates Hello message, it MUST increment in
exchange such as Hello of routing protocols. This mechanism is often the Sequence Number by 1. It MUST also specify its own Group ID in
used to detect failure on many protocols. In the real scenario, when the Group ID field of the Hello message. If a home agent is the
a home agent crashed, it can happened that only home agent active home agent, it MUST set the A-flag in it's Hello Messages. In
functionality is down and network reachability to home agent is the Home Agent Hard Switch mode, the source address of Hello messages
alive. In this case, ICMP type of message such as ping can not be MUST be the configured home agent address. In the Home Agent Virtual
used to detect the home agent failure. Therefore, we define a new Switch mode, the individual IPv6 addresses of each home agent MUST be
Hello message to detect the home agent failure. used.
The Active and the Standby Home Agents exchange periodic Hello 7.6.3. Receiving Hello Message
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.
Example Failure Events: When a home agent receives a Hello message, it SHOULD verify IPsec
ESP protection. If the message is not protected, it SHOULD be
silently discarded. However, if the Hello messages is sent on a
dedicated link between the home agents, IPsec protection is not
required. If a Hello message is sent from an IPv6 address whose
scope is not global, the message MUST be silently discarded.
Loss of Communication with the Active Peer Home Agent If the sending home agent is not in the same redundant home agent
set, the message MUST be silently ignored. This can be done by
comparing the Group ID field of the received Hello message with the
own Group ID value. Hello messages MUST NOT be sent to a home agent
whose Group ID is different from the sender. If the Sequence Number
value in the Hello message is equal to or less than the Sequence
Number value stored in the home agent list entry, the Hello message
MUST be discarded.
The redundant Home Agent set should have knowledge of each others Any Hello message satisfying all of these tests MUST be processed to
state. In order to achieve that, we define Hello message update the redundant home agent list. The receiver copies home agent
exchanges. In the event that the Home Agent that is currently information in the Hello message to the corresponding redundant home
inactive does not receive any Hello message from its peer which is agent list entry. The home agent address of the sender is retrieved
currently active for a configurable duration, the Home Agent may from the Source Address field of the IPv6 header of the Hello
decide to become active. message. If the home agent lifetime field in the Hello message is
set to 0, the receiver removes the sender from the redundant home
agents list.
Monitored Server Failure by the Active Home Agent If the R-flag is set in the received Hello message, the receiver MUST
reply with a Hello message to the originator as described in
Section 7.6.2.
There may be number of critical servers in the network that are 7.7. Processing State Synchronization Messages
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 It is necessary for standby home agents to synchronize the state
information of each mobile node registered with the active home
agent. In the Home Agent Virtual Switch mode, the synchronized state
information is used by a standby home agent when it takes over for
the failed home agent. In the Home Agent Hard Switch mode, the
standby home agent starts the switch-over of all the mobile nodes
registered to the failed home agent when the home agent failure is
detected. Thus, the Binding Cache entry MUST be modified to keep the
active home agent address of each mobile node.
In some cases, the operator may like the Home Agent to detect a 7.7.1. Soliciting State of a Particular Mobile Node or Subset of Mobile
next hop routing peer failure. If the next hop routing peer Nodes
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 When a standby home agent wants state information for a particular
mobile node or a subset of mobile nodes, such as Binding Cache, AAA,
etc., it MAY solicit this state by sending a State Synchronization
message constructed as follows:
There are two cases when a Standby Home Agent takes over an Active o It MUST set the Type field to 0 (Request).
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 o It MUST set a random value in the Identifier field.
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 o It MUST include either a Home Address mobility option indicating
advertise the home agent address and the home prefix of the home the mobile node, or a Mobile Network Prefix mobility option
addresses serviced by the redundant home agent set into the routing indicating the mobile router. The standby home agent can send
infrastructure. This is operated by using route selector such as BGP multiple home address and mobile network prefix mobility options
and OSPF modifier. In addition, if necessary, the new active home to request state information for multiple mobile nodes in a single
agent must overwrite the neighbor entries of the mobile nodes in State Synchronization request message.
order to intercept packets of the mobile nodes.
7.5. Processing State Synchronization Messages When a home agent receives the State Synchronization message with the
Type field set to 0 (Request), it MUST verify the message as follows:
It is necessary for Standby Home Agent to synchronize the state o The state synchronization message MUST be protected by IPsec ESP.
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 o The sending home agent MUST belong to the same redundant home
agent set
When a Standby Home Agent wants state for a particular Mobile Node o The receiver MUST be the active home agent for the requested home
such as Binding Cache, AAA, etc, it can solicit State Synchronization address or mobile network prefix.
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 Any packet carrying a State Synchronization message which fails to
satisfy all of these tests MUST be silently ignored.
If the received state synchronization Request message is not Otherwise, the receiver MUST reply with a State Synchronization
protected by IPsec ESP, the message must be silently discarded. If message including state information for the requested mobile node(s)
the sender home agent is not belong to the same redundant home agent and/or mobile network prefix(es) as described in Section
set, the message must be silently ignored. Moreover, if a receiver Section 7.7.2.
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 7.7.2. Synchronizing State of Mobile Nodes
A state synchronization message can be sent either: A state synchronization message can be sent either:
o when an Active Home Agent receives a state synchronization Request o When an active home agent receives a state synchronization message
message in which the Type field is set to 0 (Request).
o when an Active Home Agent creates/updates binding cache for a o When an active home agent creates a binding cache entry for a
particular Mobile Node. particular mobile node.
o in a periodic interval to update the state info for all sessions o When an active home agent deletes a binding cache entry for a
that changed since last update. particular mobile node.
If an Active Home Agent sends the state synchronization message o When an active home agent updates a binding cache entry for a
whenever the local state information such as binding cache changed, particular mobile node, only when operating in the Home Agent
the size of the state synchronization message are large. The Active Virtual Switch mode. In the Home Agent Hard Switch mode, standby
Home Agent should update the state information with an interval which home agents only use this binding cache information to send a Home
is configured by system administrator. Agent Switch message, so only need a home address of all the
mobile nodes registered to the active home agent of the same
redundant home agent set.
The binding cache of the requested Mobile Node are stored in the o In a periodic interval to update the state information for all
state synchronization message. The Active Home Agent MUST copy the sessions that changed since the last update.
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 If an active home agent sends a State Synchronization message
state synchronization message whenever the local state information changes, such as a binding cache
change, the number of the State Synchronization messages sent can be
quite large.
7.5.4. Receiving State Synchronization The binding cache information of the requested mobile nodes is stored
in the State Synchronization message. The active home agent MUST
copy the binding cache information of the requested mobile nodes into
Binding Cache Information options. If the State Synchronization
message is sent in response to a State Synchronization request
message, the active home agent MUST copy the Identifier field of the
State Synchronization request message to the Identifier field in the
State Synchronization reply message. Otherwise, it MUST set the
Identifier field to 0.
A state synchronization message MUST be authenticated and encrypted When the active home agent stores the state of multiple mobile nodes
by IPsec ESP mode. If not, the message MUST be ignored. When a Home in a state synchronization message, a Binding Cache Information
Agent receives a state synchronization message, it MUST verify the option is used as a separator. For each mobile node, a Binding Cache
Source address field of the IPv6 header. If the source address do Information option is placed first, followed by any other options.
not belong to any home agents of the redundant home agent set, the When the next Binding Cache Information option is reached in the
message MUST be silently discarded. The receiver home agent SHOULD State Synchronization message, it indicates the information of a
record the state and the Active Home Agent address into its Binding different mobile node.
Cache.
7.6. Processing Home Agent SwitchOver Messages A State Synchronization message MUST be authenticated and encrypted
by IPsec ESP mode, otherwise 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
does not belong to any home agent in the redundant home agent set,
the message MUST be silently discarded. After successfully verifying
the message, the receiving home agent MUST update its binding cache
and all other necessary information such as AAA and vendor specific
information in the particular database. In the Home Agent Hard
Switch mode, the receiver MUST also record the IPv6 address of the
sender (the active home agent).
7.6.1. Sending Home Agent SwitchOver Request 7.8. Processing Home Agent Control Messages
When a Standby Home Agent decides to become an active home agent, it 7.8.1. Standby Home Agent becomes an Active Home Agent
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
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 When a standby home agent decides to become an active home agent, the
standby home agent sends a SwitchOver Request message (a Home Agent
Control message in which the Type field is set to 0) to the active
home agent. This message MUST be unicasted to the active home agent
and MUST be encrypted and authenticated by IPsec ESP. The active
home Agent MUST NOT generate this message.
A home agent SwitchOver reply is sent in reply to a home agent When an active home agent receives a SwitchOver Request, it first
SwitchOver Request message. When a home agent receives a home agent verifies the received Home Agent Control message. If the request
SwitchOver Request message, it first verifies the message. If the message is not protected by IPsec, it MUST be silently discarded. If
request message is not protected by IPsec, it MUST be silently the home agent is not an active home agent, it MUST send a SwitchOver
discarded. In addition, if the sender home agent is not belong to Reply message (a Home Agent Control message in which the Type field
the same redundant home agent set, the message MUST be silently is set to 1) with the Status field set to 130 (Not active home
discarded. agent). If the receiver is an active home agent and does not want
this standby home agent to become the active home agent, it MUST
reply a SwitchOver reply with the Status field set to 129
(Administratively prohibited). In addition, if the sending home
agent does not belong to the same redundant home agent set, a
SwitchOver Reply message MUST be sent to the sender with the Status
field set to 132 (Not in same redundant home agent set). Otherwise,
the active home agent MUST become a standby home agent and reply with
a SwitchOver Reply message with the Status field set to 0 (Success).
If a receiver home agent is not an Active Home Agent, it replies a If a home agent receives a SwitchOver Reply message, it MUST be
home agent SwitchOver reply which status field set to 128. protected by IPsec ESP. Otherwise, the message MUST be silently
Otherwise, the receiver home agent MUST become a Standby Home Agent discarded. If the receiving home agent did not send a SwitchOver
and replies a home agent SwitchOver reply which status field set to Request message, the message MUST be silently ignored. If the Status
zero. field of the SwitchOver Reply message is 0 (Success), the receiving
standby home agent immediately becomes an active home agent. If the
value in the Status field is greater than 128 an error has occurred.
In this case, the receiver MUST NOT become an active home agent.
7.6.3. Receiving Home Agent SwitchOver Reply 7.8.2. Active Home Agent becomes in-active
If a home agent receives a home agent SwitchOver reply, the message When an active home agent decides to become an in-active home agent,
MUST be protected by IPsec. Otherwise, the message MUST be silently it sends a SwitchBack Request message (i.e. a Home Agent Control
discarded. If a receiver home agent did not send a home agent message with Type field set to 3) to a standby home agent. The
SwitchOver Request beforehand, the message MUST be silently reason for the active home agent to send this message can be
discarded. administrative intervention, and events like Monitored Server Failure
by the active home agent or Routing Peer/Link Failure. This message
MUST be unicasted to one of the standby home agents and MUST be
encrypted and authenticated by IPsec ESP. A standby home agent MUST
NOT generate this message.
If the status field of the SwitchOver reply message indicates zero, A SwitchBack Reply is sent in reply to a SwitchBack Request message.
the receiver Standby Home Agent immediately becomes an Active Home When a home agent receives a SwitchBack Request message, it first
Agent. If the status value is greater than 128, an error is verifies the message. If the SwitchBack Request message is not
occurred. Thus, the receiver cannot be an active home agent. protected by IPsec ESP, it MUST be silently discarded. If the
sending home agent of the SwitchBack Request message is not an active
home agent, the receiver MUST reply with a SwitchBack Reply (a Home
Agent Control message in which the Type field is set to 4) in which
the Status field is set to 130 (Not active home agent). If the
sending home agent does not belong to the same redundant home agent
set, a SwitchBack Reply message MUST be sent in which the Status
field set to 132 (Not in same redundant home agent set). Otherwise,
the receiving home agent MUST send a SwitchBack Reply message in
which the Status field is set to 0 (Success). After sending the
SwitchBack reply, it MUST NOT become an active home agent
immediately. This is because the active home agent is still active
until it receives the SwitchBack Reply message acknowledging the
SwitchBack Request. The standby home agent SHOULD change to active
at least after LINK_TRAVERSAL_TIME.
7.7. Processing Home Agent SwitchBack Messages If a home agent receives a SwitchBack Reply message, it MUST be
protected by IPsec ESP, otherwise the message MUST be silently
discarded. If the receiving home agent did not send a SwitchBack
Request message beforehand, the message MUST be silently discarded.
If the Status field of the SwitchBack Reply message is 0 (Success),
the receiving home agent immediately becomes an in-active home agent.
If the value in the Status field is greater than 128, an error has
occurred. In this case, the receiver cannot become an in-active home
agent and MUST continue to be an active home agent.
7.7.1. Sending Home Agent SwitchBack Request 7.9. Sending Home Agent Switch Messages
When an Active Home Agent decides to become an in-active home agent This operation is valid only for the Home Agent Hard Switch mode.
(i.e. Standby Home Agent), it MAY send a home agent SwitchBack The standby home agent MUST send a Home Agent Switch message as
Request message to a Standby Home Agent. The reason for the Active defined in [11] to all the mobile nodes that were being served by the
Home Agent to send this message is administrative intervention, and failed home agent. Since the active home agent address is recorded
events like Monitored Server Failure by the Active Home Agent or in each synchronized binding cache, the standby home agent knows
Routing Peer/Link Failure. The Active Home Agent sends it with a which mobile nodes were served by the failed home agent. The Home
mobility header which type is set to the home agent SwitchBack Agent Switch message must be encrypted with a pre-established SA.
Request type. This message must be encrypted and authenticated by The standby home agent should include its own IPv6 address in the
IPsec ESP. A Standby Home Agent MUST NOT generate this message. Home Agent Switch message. Note that a Home Agent Switch message is
sent to each mobile node served by the home agent. If there is a
large number of mobile nodes, sending Home Agent Switch messages will
cause a lot of signaling overhead on the network.
7.7.2. Sending Home Agent SwitchBack Reply When a failed home agent recovers, it MUST re-establish an IPsec SA
with each mobile node served by its redundant home agent set.
Otherwise, it cannot be either a standby or active home agent for the
mobile nodes. Therefore, it sends a Home Agent Switch message with
the I-flag set to all the mobile nodes serving by other home agents
in the same redundant home agent set, and includes its own home agent
address in the Home Agent Addresses field.
A home agent SwitchBack reply is sent in reply to a home agent 7.10. Interworking with VRRP
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 VRRP and HSRP specify an election protocol that dynamically assigns
Active Home Agent, it replies home agent SwitchBack reply which responsibility for a virtual router to one of the VRRP routers on a
status field set to 128. Otherwise, the receiver home agent MUST LAN. This operation is similar to the Home Agent Virtual Switch
become an Active Home Agent and replies a home agent SwitchBack reply operation. For example, the VRRP router controlling the IP
which status field set to zero. address(es) associated with a virtual router is called the Master,
and forwards packets sent to these IP addresses. The election
process provides dynamic fail over in the forwarding responsibility
should the Master become unavailable. Although VRRP is used to
guarantee home agent address reachability, it cannot be used for
state synchronization and explicit switching of Master and Backup.
Thus, the Home Agent Reliability protocol cannot be replaced by VRRP.
This section explains how VRRP can interwork with the Home Agent
Reliability protocol.
7.7.3. Receiving Home Agent SwitchBack Reply When VRRP is available, VRRP can replace the Hello message described
in Section 6.1.3. However, some of information is missed by using
VRRP. After receiving a VRRP message, each home agent SHOULD process
the message and store the information as if it receives Home Agent
Hello messages Section 7.6.3. The Home Agents SHOULD still perform
binding cache synchronization as described in Section 7.7 and SHOULD
support the Home Agent Switch message as described in Section 7.9.
If a home agent receives a home agent SwitchBack reply, the message In addition to this, VRRP is useful only if all home agents are
MUST be protected by IPsec. Otherwise, the message MUST be silently located on the same link. If the home agents are topologically
discarded. If a receiver home agent did not send a home agent separated, the Home Agent Reliability protocol MUST be used.
SwitchBack Request message beforehand, the message MUST be silently
discarded, too.
If the status field of the SwitchBack reply message indicates zero, 0 1 2 3
the receiver home agent immediately becomes an in-Active Home Agent. 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
If the status value is greater than 128, some error is occurred. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thus, the receiver cannot be an in-active home agent and MUST |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr|
continue to be an Active Home Agent. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(rsvd) | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Address(es) |
+ +
+ +
+ +
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.8. Sending Home Agent Switch Message Figure 12: VRRP Packet Format
If an Active Home Agent fails, another Standby Home Agent on the home The message format of VRRP is described in Figure 12. Each field is
link can take over the Failed Home Agent in the Home Agent Hard mapped as follows:
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 Virtual Rtr ID
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.
8. Mobile Node Operation Group ID is stored in the Virtual Rtr ID field.
Operations described in this section are valid only for the home Priority
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 Home Agent Preference is stored in the Priority field. Note that
VRRP only has 8 bits for the Priority field. Therefore, values
larger than 255 MUST NOT be assigned to the preference value.
To provide home agent reliability, one possible solution is that the Count IPv6 IPv6 Addr
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 This field MUST be always be 1.
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 Advert Int
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 This field MUST be mapped to the Hello Interval field of the Home
agents provision from MSP or ASP, as already defined in [11]. The Agent Hello message, though it only has 12 bytes.
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 IPv6 address
After Mobile Node get multiple Home Agent addresses, it need to A home agent address is stored in this field.
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.
The Mobile Node MUST follow standard IKEv2 exchange in bootstrapping Home Agent Lifetime, Sequence Number and Flags field are missing in
solution of split scenario [10], or IKEv1 bootstrap solution [12]. if the VRRP packet format. Therefore, operators SHOULD use the same
needed by Mobile Node, Home Address configuration maybe included for statically configured value for Home Agent Lifetime. Each home agent
the first IKE exchange. After its Home Address is assigned or does not check freshness of received VRRP message because of no
approved by the first home agent, Mobile Node SHOULD register itself sequence number. If VRRP is used, a home agent cannot determine the
to the second home agent by IKE using the same Home Address. active home agent from the VRRP message due to lack of A flag, and
Therefore, no HoA configuration should be used in the second IKEv2 cannot request a VRRP advertisement to other home agents.
procedure. Note that the Mobile Node sends Binding Update Message to
the first home agent.
8.3. Receiving Home Agent Switch message 7.11. Retransmissions and Rate Limiting
A mobile node must follow the operation specified in [8] when it Standby and active home agents are responsible for retransmissions
receives home agent switch message. and rate limiting of a State Synchronization Request, Switchover
Request, SwitchBack Request messages for which they expect a
response. The home agent MUST determine a value for the initial
transmission timer:
When the mobile node receives a Home Agent Switch message, and if the o If the home agent sends a State Synchronization Request message,
message contains the IP address of standby home agent, it picks the it SHOULD use an initial retransmission interval of
Standby Home Agent in the request message as the Active Home Agent INITIAL_STATE_SYNC_REQ_TIMER.
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.
9. Security Considerations o If a standby home agent sends a Switchover Request message, it
SHOULD use an initial retransmission interval of
INITIAL_SWICHOVER_REQ_TIMER.
Mobile IPv6 depends on IPsec and IKE for binding home registration o If an active home agent sends a SwitchBack Request message, it
described in [5]. A mobile node must encrypt a binding update sent SHOULD use an initial retransmission interval of
to a home agent. In addition, the mobile node exchanges HoTI and HoT INITIAL_SWICHBACK_REQ_TIMER .
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. If the sending home agent fails to receive a valid matching response
within the selected initial retransmission interval, it SHOULD
retransmit the message until a response is received. All of the
above constants are specified in Section 10.
o Security Policy Database (SPD) and Selector Information The retransmission MUST use an exponential backoff process as
described in [1] until either the home agent receives a response, or
the timeout period reaches the value MAC_HARELIABILITY_TIMEOUT
(16sec). The home agent SHOULD use a separate back-off process for
different message types and different destinations. The rate
limiting of Mobility Header messages is the same as one in [1]. A
home agent MUST NOT send Mobility Header Messages to a particular
home agent more than MAX_UPDATE_RATE (3) times a second, which is
specified in [1].
o Security Association (SA) for Binding Registration (SA1 and SA2) 8. Mobile Node Operation
o SA for HoTI/HoT Exchange (SA3 and SA4) Operations described in this section are valid only for the Home
Agent Hard Switch mode. When the Home Agent Virtual Switch is used,
all these operations can be skipped.
o SA for Mobile Prefix Discovery (SA5 and SA6) 8.1. Home Agent Addresses Discovery
o SA for data packets if any (SA7 and SA8) To provide home agent reliability with the Home Agent Hard Switch
mode, a mobile node authenticates itself to two or more home agents
and creates IPsec SAs with them during bootstrapping. When one home
agent fails, another home agent can use the pre-existing SA to notify
the mobile node about the failure.
The Home Agent reliability scheme for Mobile IPv6 involves IPsec Multiple home agent addresses are available in a home network. In
tunnel SwitchOver upon Home Agent failure. There are various ways order to discover these home agent addresses, two different
this can be achieved e.g. setting up of multiple IPsec security mechanisms are defined in the bootstrapping solution in the split
associations between the Mobile Node and the Home Agent sets. scenario [13]. One is DNS lookup by home agent Name, the other is
Another way could be, the Home Agents periodically check pointing DNS lookup by Service Name. DHCPv6 can also be used in the
IPsec session state including the per packet sequence numbers for the integrated scenario [14] to provide home agent provisioning to mobile
Mobile Node. We can call these two possible Home Agent redundancy nodes.
modes as follows:
1. Home Agent Hard Switch. In this mode, the Mobile Node and the In the split scenario, a mobile node can use DNS lookup by Service
redundant Home Agent set negotiates independent IPsec SAs. Name to discover the home agents, as defined in [13]. For example,
if home agent reliability is required by a mobile node, DNS lookup by
Service Name method is recommended for the mobile node to discover
multiple home agents addresses. Therefore, mobile nodes will query
the DNS SRV records with a service name of mip6 and protocol name of
ipv6. The DNS SRV records includes multiple home agent addresses and
different preference values and weights. The mobile node SHOULD
choose two or more home agents from the home agents list according to
their preference value. Then the mobile node should authenticate
itself to these home agents via an IKEv2 exchange.
2. Home Agent Virtual Switch. In this mode, the Mobile Node In the integrated scenario, a mobile node can use DHCPv6 to get home
negotiates just one SA for both the redundant Home Agent set. agent provisioning from an MSP or ASP, as already defined in [14].
The only requirement is that the DHCPv6 response must include
multiple home agents' information in order to support home agent
reliability.
In both the cases, the mobile node maintains only one binding cache 8.2. IKE/IPsec pre-establishment to Home Agents
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 After a mobile node gets multiple home agent addresses, it needs to
the Mobile Node and the Home Agent, we will talk about the ESP field trigger multiple IKE exchanges with theh multiple home agents
synchronization issues between the Mobile Node and the redundant set selected from the home agent list. Since both IKEv1 and IKEv2 can be
of Home Agents. Most of fields should be synchronized based on used to bootstrap Mobile IPv6, this solution does not introduce any
RFC4301[6]. The ESP header has the following fields: new operations to co-operate with IKEv1 or IKEv2. It should initiate
IKE for home agents as soon as home registration is complete.
SPI The mobile node MUST follow the standard IKEv2 exchange in the
bootstrapping solution of the split scenario [13], or the IKEv1
bootstrapping solution [15]. Home Address configuration maybe also
be included, if necessary, for the first IKE exchange. After its
Home Address is assigned or approved by the first home agent, mobile
node SHOULD register itself with the second home agent with IKE using
the same Home Address. Therefore, no home address configuration
should be used in the second IKEv2 procedure. Note that the mobile
node only sends a Binding Update message to the first home agent.
This field identifies the SAD at the receiver. 8.3. Receiving Home Agent Switch message
Home Agent Hard Switch Mode A mobile node must follow the operation specified in [11] when it
receives a Home Agent Switch message.
the Mobile Node and the redundant Home Agent set negotiates If the I-flag is set in the received Home Agent Switch message, the
separate/independent IPsec SAs. Therefore, the SPI value will mobile node MUST re-key the SA with the home agent addresses stored
vary depending on which Home Agent the Mobile Node selects to in the Home Agent Addresses field. The mobile node MUST NOT change
send/receive data packets. its active home agent when the I-flag is set. If the home agent
address is not known from the bootstrapping described in Section 8.1,
the mobile node MUST NOT start an IKE session with the unknown home
agent. Instead, it SHOULD re-start home agent discovery again to
update its home agent address information.
Home Agent Virtual Switch Mode When the mobile node receives a Home Agent Switch message without
I-flag set, and if the message contains the IPv6 address of a standby
home agent, it SHOULD pick the standby home agent in the switch
message as the active home agent and send a Binding Update message to
it. The mobile node already has a pre-established SA with the home
agent and should use that SA to send the Binding Update.
The Mobile Node negotiates only one IPsec SA. Hence, the SPI 9. Security Considerations
value will remain unchanged upon Home Agent SwitchOver.
Since Mobile IPv6 operation requires ESP in transport mode between
the mobile node and the home agent, we will discuss the ESP field
synchronization issues between the mobile node and the redundant set
of home agents. This synchronization is required only for Home Agent
Virtual Switch mode. Most of fields should be synchronized based on
RFC4301 [9]. The ESP header has the following fields:
SPI
This field identifies the SAD at the receiver.
The mobile node negotiates only one IPsec SA. Hence, the SPI
value will remain unchanged upon home agent failover.
Sequence Number Sequence Number
This field is used for "anti-replay" feature of ESP. The This field is used for "anti-replay" feature of ESP. The
transmitter must include this monotonically increasing number. transmitter must include this monotonically increasing number.
The receiver may process the sequence number based on local The receiver may process the sequence number based on local
policy. policy.
Home Agent Hard Switch Mode The mobile node and the redundant home agent set will have the
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, same set of sequence numbers for transmit and receive. Hence,
synchronization of the sequence number field is mandatory in synchronization of the sequence number field is mandatory in this
this mode of operation. mode of operation.
For MIP6 signaling i.e. BU/BA, HoTi/HoT etc. the SA1, SA2, SA3, As described in Section 4, the SA1, SA2, SA3, SA4 could be
SA4 could be synchronized between the Home Agents as these synchronized between the home agents as these messages are not
messages are not sent continuously. Moreover for the BU Case, if sent continuously. Moreover for the Binding Update case, if the
the Mobile Node is in the middle of sending a BU to the Home Agent mobile node is in the middle of sending a Binding Update to an
(Active Home Agent) for binding refresh, and the Home Agent is active home agent for a binding refresh, and the active home agent
crashing at that moment. The Mobile Node will not get any is not available at that moment, the mobile node will not get any
response from the Home Agent. The Mobile Node will retry. After response from the active home agent. After a standby home agent
the Standby Home Agent becomes active, it will receive BU from the becomes active, the mobile node will retry and it will receive the
Mobile Node with a sequence number that is +n from its last known Binding Update from the mobile node with a sequence number that is
sequence number for SA1. For the BA case (SA2), the Standby Home +n from its last known sequence number for SA1. For the Binding
Agent SHOULD add a random number to the last known sequence number Acknowledgement case (SA2), the standby home agent SHOULD add a
over and above the replay window to ensure that the packet passes random number to the last known sequence number over and above the
replay check at the Mobile Node. The same applies to HoTi and HoT replay window to ensure that the packet passes the replay check at
messages with SA3 and SA4. Note that this windowing of the the mobile node. The same applies to HoTi and HoT messages with
sequence numbers for MIP6 signaling is only needed to cover the SA3 and SA4. Note that this windowing of the sequence numbers for
corner cases when BU/HoTi is in air and the Active Home Agent Mobile IPv6 signaling is only needed to cover the corner cases
when Binding Update or HoTi is in-flight and the active home agent
fails. fails.
The technique explained above should work fine for user data The technique explained above should work for user data packets if
packets if ESP is used to encrypt user data traffic as well. The ESP is used to encrypt user data traffic as well. The actual
actual switchover time and the routing infrastructure convergence switchover time and the routing infrastructure convergence time is
time is the only latency that the user may perceive. the only latency that the user may perceive.
Initialization Vector Initialization Vector
Since each time, IV will be delivered between Mobile Node and Home Since the Initialization Vector will be delivered in each exchange
Agent, so this field is not necessarily synchronized between home between a mobile node and home agent, this field is not
agents. necessarily synchronized between home agents.
Others Others
Other fields should be synchronized based on RFC4301[6] Other fields should be synchronized based on RFC4301[9]
In Home Agent Hard Switch mode, the Standby Home Agent needs to send In the Home Agent Hard Switch mode, the standby home agent needs to
a home agent switch message in secure way ( i.e. required IPsec send a Home Agent Switch message using IPsec encryption. Since the
encryption to the trigger). The mobile node pre-establishes IPsec SA mobile node has pre-established an IPsec SA with both the active and
with the Standby Home Agent, as well as an active home agent. The standby home agents, the standby home agent can send the message to
Standby Home Agent can send a trigger to the mobile node with the the mobile node with the pre-established IPsec SA.
pre-established IPsec SA.
10. Contributors 10. Protocol Constants
INITIAL_STATE_SYNC_REQ_TIMER: 3sec
INITIAL_SWICHOVER_REQ_TIMER: 1sec
INITIAL_SWICHBACK_REQ_TIMER 1sec
LINK_TRAVERSAL_TIME 150msec
11. Contributors
This document is a result of discussions in the Mobile IPv6 Home This document is a result of discussions in the Mobile IPv6 Home
Agent Reliability Design Team. The members of the design team are Agent Reliability Design Team. The members of the design team that
listed below: are listed below are authors that have contributed to this document:
Samita Chakrabarti Samita Chakrabarti
samita.chakrabarti@sun.com samita.chakrabarti@azairenet.com
Kuntal Chowdhury Kuntal Chowdhury
kchowdhury@starentnetworks.com kchowdhury@starentnetworks.com
Hui Deng Hui Deng
hdeng@hitachi.cn hdeng@hitachi.cn
Vijay Devarapalli Vijay Devarapalli
vijay.devarapalli@azairenet.com vijay.devarapalli@azairenet.com
Sri Gundavelli Sri Gundavelli
gundave@cisco.com sgundave@cisco.com
Brian Haley Brian Haley
brian.haley@hp.com brian.haley@hp.com
Behcet Sarikaya Behcet Sarikaya
bsarikaya@huawei.com bsarikaya@huawei.com
Ryuji Wakikawa Ryuji Wakikawa
ryuji@sfc.wide.ad.jp ryuji@sfc.wide.ad.jp
11. Acknowledgements 12. Acknowledgements
This document includes a lot of text from [13] and [14]. Therefore This document includes a lot of text from [16] and [17]. Therefore
the authors of these two documents are acknowledged. We would also the authors of these two documents are acknowledged. We would also
like to thank the authors of the home agent reliability problem like to thank the authors of the home agent reliability problem
statement [15] for describing the problem succinctly and Alice Qin statement [18] for describing the problem succinctly and Alice Qin
for her work on the hello protocol. for her work on the hello protocol.
12. References 13. References
12.1. Normative References 13.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [4] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
for IP Version 6 (IPv6)", RFC 2461, December 1998. RFC 3768, April 2004.
[5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [5] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC 2281, March 1998.
[6] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[6] Kent, S. and K. Seo, "Security Architecture for the Internet [7] Devarapalli, V., "Mobile IPv6 Vendor Specific Option",
draft-ietf-mip6-vsm-00 (work in progress), December 2006.
[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
12.2. Informative References 13.2. Informative References
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", [10] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[8] Haley, B., "Mobility Header Home Agent Switch Message", [11] Haley, B., "Mobility Header Home Agent Switch Message",
draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. draft-ietf-mip6-ha-switch-01 (work in progress), June 2006.
[9] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, [12] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005. July 2005.
[10] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-02 (work in progress), draft-ietf-mip6-bootstrapping-split-02 (work in progress),
March 2006. March 2006.
[11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for [14] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario", the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
progress), October 2005. progress), October 2005.
[12] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 [15] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6
Bootstrapping with IKEv1", Bootstrapping with IKEv1",
draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress),
March 2006. March 2006.
[13] Wakikawa, R., "Inter Home Agents Protocol Specification", [16] Wakikawa, R., "Inter Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress),
March 2006. March 2006.
[14] Devarapalli, V., "Local HA to HA protocol", [17] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), draft-devarapalli-mip6-nemo-local-haha-01 (work in progress),
March 2006. March 2006.
[15] Faizan, J., "Problem Statement: Home Agent Reliability", [18] Faizan, J., "Problem Statement: Home Agent Reliability",
draft-jfaizan-mipv6-ha-reliability-01 (work in progress), draft-jfaizan-mipv6-ha-reliability-01 (work in progress),
February 2004. February 2004.
Appendix A. Change Log From Previous Versions
Changes from draft-ietf-mip6-hareliability-00
o Combining State Synchronization Request message and State
Synchronization message
o Combining home agent SwitchOver Request & Reply and SwitchBack
Request & Reply messages.
o Many Editorial Changes
Author's Address Author's Address
Ryuji Wakikawa Ryuji Wakikawa
Keio University Keio University
Department of Environmental Information, Keio University Department of Environmental Information, Keio University
5322 Endo, Fujisawa, Kanagawa 252-8520 5322 Endo, Fujisawa, Kanagawa 252-8520
Japan Japan
Email: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 47, line 29 skipping to change at page 45, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 273 change blocks. 
1202 lines changed or deleted 1220 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/