draft-ietf-mip6-hareliability-03.txt   draft-ietf-mip6-hareliability-04.txt 
MIP6 Working Group R. Wakikawa (Editor) MEXT (MIP6) Working Group R. Wakikawa (Editor)
Internet-Draft Keio University Internet-Draft Toyota ITC
Intended status: Standards Track November 19, 2007 Intended status: Standards Track July 14, 2008
Expires: May 22, 2008 Expires: January 15, 2009
Home Agent Reliability Protocol Home Agent Reliability Protocol
draft-ietf-mip6-hareliability-03.txt draft-ietf-mip6-hareliability-04.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 34 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 May 22, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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 operated in a system. It is critical to provide home agent
in the event of a home agent crashing or becoming unavailable. This reliability in the event of a home agent crashing or becoming
would allow another home agent to take over and continue providing unavailable. This would allow another home agent to take over and
service to the mobile nodes. This document describes the problem continue providing service to the mobile nodes. This document
scope briefly and provides a mechanism of home agent failure describes the problem scope briefly and provides a mechanism of home
detection, home agent state transfer, and home agent switching for agent failure detection, home agent state transfer, and home agent
home agent redundancy and reliability. switching for 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 and Requirements . . . . . . . . . . . . . . 6 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6
4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 8
4.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 9
4.3. Home Agent Management . . . . . . . . . . . . . . . . . . 10
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Home Agent Network Configuration . . . . . . . . . . . . . 10 5.1. New Mobility Header Messages . . . . . . . . . . . . . . . 11
5.2. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 11 5.1.1. State Synchronization Message . . . . . . . . . . . . 11
5.3. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12 5.1.2. Home Agent Control Message . . . . . . . . . . . . . . 13
5.4. Active Home Agent Management . . . . . . . . . . . . . . . 13 5.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 15
5.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 16
5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 17
5.2.1. IP address Option . . . . . . . . . . . . . . . . . . 17
5.2.2. Binding Cache Information Option . . . . . . . . . . . 17
5.2.3. AAA Information Option . . . . . . . . . . . . . . . . 18
6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 20
6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 15 6.1. Network Configuration . . . . . . . . . . . . . . . . . . 20
6.1.1. State Synchronization Message . . . . . . . . . . . . 15 6.2. Address Configuration for Virtual Switch . . . . . . . . . 21
6.1.2. Home Agent Control Message . . . . . . . . . . . . . . 17 6.3. Address Configuration for Hard Switch . . . . . . . . . . 21
6.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 19
6.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 21
6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 22
6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 22
6.2.2. Binding Cache Information Option . . . . . . . . . . . 22
6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 24
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 25 7. Home Agent Common Operation . . . . . . . . . . . . . . . . . 22
7.1. Home Agent Address Configuration . . . . . . . . . . . . . 25 7.1. Home Agent List Management . . . . . . . . . . . . . . . . 22
7.2. Consideration of Routing and Neighbor Discovery 7.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 22
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Processing Hello Messages . . . . . . . . . . . . . . . . 23
7.3. Home Agent List Management . . . . . . . . . . . . . . . . 26 7.3.1. Requesting Hello Message . . . . . . . . . . . . . . . 24
7.4. Detecting Home Agent Failure . . . . . . . . . . . . . . . 27 7.3.2. Sending Hello Message . . . . . . . . . . . . . . . . 24
7.5. Home Agent Switch Over . . . . . . . . . . . . . . . . . . 28 7.3.3. Receiving Hello Message . . . . . . . . . . . . . . . 25
7.6. Processing Hello Messages . . . . . . . . . . . . . . . . 29 7.4. Processing State Synchronization Messages . . . . . . . . 26
7.6.1. Requesting Hello Message . . . . . . . . . . . . . . . 29 7.4.1. Requesting State of a Particular Mobile Node(s) . . . 26
7.6.2. Sending Hello Message . . . . . . . . . . . . . . . . 30 7.4.2. Synchronizing State . . . . . . . . . . . . . . . . . 27
7.6.3. Receiving Hello Message . . . . . . . . . . . . . . . 30 7.4.3. Reliable Transmission by Explicit Acknowledgement . . 28
7.7. Processing State Synchronization Messages . . . . . . . . 31 7.5. Processing Home Agent Control Messages . . . . . . . . . . 29
7.7.1. Soliciting State of a Particular Mobile Node or 7.5.1. Standby Home Agent becomes an Active Home Agent . . . 29
Subset of Mobile Nodes . . . . . . . . . . . . . . . . 31 7.5.2. Active Home Agent becomes in-active . . . . . . . . . 30
7.7.2. Synchronizing State of Mobile Nodes . . . . . . . . . 32 7.6. Interworking with VRRP . . . . . . . . . . . . . . . . . . 31
7.7.3. Explicit Acknowledgement of the State 7.7. Retransmissions and Rate Limiting . . . . . . . . . . . . 32
Synchronization Reply message . . . . . . . . . . . . 34
7.8. Processing Home Agent Control Messages . . . . . . . . . . 34
7.8.1. Standby Home Agent becomes an Active Home Agent . . . 34
7.8.2. Active Home Agent becomes in-active . . . . . . . . . 35
7.8.3. Notification of Home Agent Switch Completion . . . . . 36
7.9. Sending Home Agent Switch Messages . . . . . . . . . . . . 36
7.10. Interworking with VRRP . . . . . . . . . . . . . . . . . . 37
7.11. Retransmissions and Rate Limiting . . . . . . . . . . . . 38
8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 40 8. Home Agent Virtual Switch . . . . . . . . . . . . . . . . . . 34
8.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 40 8.1. Consideration of Routing and Neighbor Discovery
8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 40 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.3. Receiving Home Agent Switch message . . . . . . . . . . . 41 8.2. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35
9.1. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 35
9.2. Sending Home Agent Switch Messages . . . . . . . . . . . . 35
9.3. Notification of Home Agent Switch Completion . . . . . . . 36
9.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 36
9.4.1. Home Agent Addresses Discovery . . . . . . . . . . . . 36
9.4.2. IKE/IPsec pre-establishment to Home Agents . . . . . . 37
9.4.3. Receiving Home Agent Switch message . . . . . . . . . 37
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 44 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 41
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 43
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. Change Log From Previous Versions . . . . . . . . . . 50 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
15.1. Normative References . . . . . . . . . . . . . . . . . . . 44
15.2. Informative References . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix A. Change Log From Previous Versions . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 51
1. Introduction Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47
In Mobile IPv6 [RFC-3775] and NEMO Basic Support[RFC-3963], mobile 1. Introduction
nodes may use a bi-directional tunnel with their home agents for all
traffic with correspondent nodes. A home agent on the home link
maintains a binding cache entry for each mobile node and uses the
binding cache entry to route any traffic meant for the mobile node or
the mobile network. If the mobile node is not on the home link and
does not have a binding cache entry at the home agent, it is neither
reachable at its home address nor able to setup new sessions with its
home address. If a home agent loses the binding cache state, due to
failure or some other reason, it results in a loss of service for the
mobile nodes.
In Mobile IPv6 [RFC-3775] and NEMO Basic Support [RFC-3963], if a
home agent loses the binding cache state, due to failure or some
other reason, it results in a loss of service for the mobile nodes.
It is beneficial to provide high availability and redundancy for a It is beneficial to provide high availability and redundancy for a
home agent so that mobile nodes can avail of uninterrupted service home agent so that mobile nodes can avail of uninterrupted service
even when one home agent crashes or loses state. even when one home agent crashes or loses state. The Home Agent
Reliability protocol is designed to synchronize the Mobile IPv6
states between active and standby home agents as VRRP[RFC-3768] or
HSRP [RFC-2281]. A home agent maintains not only binding cache but
also IPsec and IKE related states per mobile node. Mobile IPv6
mandates IPsec encryption for signaling of home binding registration
(BU and BA) and return routability (HoTI and HoT) as described in
[RFC-3776]. However, IPsec states synchronization is out of scope in
this document. The scope of Home Agent Reliability protocol is
limited to the management of Mobile IPv6 related states. Thus, we
define two different approaches such as Home Agent Virtual Switch and
Home Agent Hard Switch depending on the capability of IPsec state
synchronization. In both cases, a mobile node maintains only one
home binding at any given time.
Home Agent Virtual Switch
The Home Agent Virtual Switch operation can be used only if IPsec
state synchronization mechanism is available (outside of Home
Agent Reliability Protocol). The IPsec state per mobile node MUST
be shared between the active home agent and standby home agents in
the background. The active and the standby home agents are
addressed by the same home agent address, although only the active
home agent is accessible with the home agent address. Each mobile
node negotiates just one Security Association with the active home
agent. 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.
Home Agent Hard Switch
In the Home Agent Hard Switch, IPsec/IKE states synchronization is
not required. The home agents are addressed by different IP
addresses. When an active home agent fails, a mobile node will
receive a notification (Home Agent Switch message [RFC-5142]) from
a standby home agent, and send a Binding Update to the standby
home agent. In order for the mobile node to receive the Home
Agent Switch message securely from the standby home agent, the
mobile node needs to establish an IPsec SA with both the active
and the standby home agents beforehand.
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 [RFC-2119]. document are to be interpreted as described in [RFC-2119].
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
[RFC-3775] and a mobile router [RFC-3963]. [RFC-3775] and a mobile router [RFC-3963].
Some of the mobility related terms used in this document are defined Mobility related terms used in this document are defined in [RFC-
in [RFC-3775] and [RFC-3753]. In addition or in replacement of 3775] and [RFC-3753]. In addition or in replacement of these, the
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 group of active and standby home agent(s). The Group Identifier A group of active and standby home agent(s). The Group Identifier
is used to identify a redundant home agent set. The Group ID is is used to identify a redundant home agent set.
exchanged by Hello messages.
Binding Synchronization Virtual Home Agent Address
Synchronization of binding cache entries within the redundant home A home agent address shared among home agents in a redundant home
agent set. agent set and used only in the Home Agent Virtual Switch case.
The address is only acitivated on an active home agent.
Home Agent Preference Home Agent Preference
This preference value is defined for Duplicate Home Agent Address This preference value is originally defined for Dynamic Home Agent
Discovery (DHAAD) in RFC3775. This protocol uses this preference Address Discovery (DHAAD) in RFC3775. This protocol re-uses this
value for home agent selection when an active home agent has preference value for home agent selection when an active home
failed. However, an operator can also define an independent value agent has failed. However, an operator can also define an
used only for the home agent reliability protocol if the operator independent value used only for the home agent reliability
wants to have different preference values for DHAAD and the home protocol if the operator wants to have different preference values
agent reliability protocol. A home agent SHOULD NOT use the same for DHAAD and the home agent reliability protocol. A home agent
preference value as other home agents for this protocol. SHOULD NOT use the same preference value of other home agents.
3. Problem Statement and Requirements 3. Problem Statement and Requirements
In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a
binding with only one home agent. Thus the home agent represents the binding with only one home agent. Thus the home agent represents the
possibility of a single point of failure for Mobile IPv6. A home possibility of a single point of failure for Mobile IPv6. A home
agent may be responsible for multiple mobile nodes on the home link. agent is responsible for multiple mobile nodes on its home link. The
The failure of the home agent may then result in the loss of failure of the home agent may then result in the loss of connectivity
connectivity for numerous mobile nodes located throughout the for numerous mobile nodes located throughout the Internet. To
Internet. To overcome this problem, Mobile IPv6 allows deployment of overcome this problem, Mobile IPv6 allows deployment of multiple home
multiple home agents on the home link so that upon the failure of a agents on the home link so that upon the failure of a home agent, a
home agent, a mobile node can re-establish its connection through a mobile node can re-establish its connection through a new home agent.
new home agent. However, the base Mobile IPv6 specification does not However, the base Mobile IPv6 specification does not address home
address home agent failover and dynamic transfer of service from one agent failover and dynamic transfer of service from one home agent to
home agent to another. This transfer of service from the failed home another. This transfer of service from the failed home agent to a
agent to a new working home agent requires coordination or pre- new active home agent requires coordination or pre-configuration
configuration among the home agents regarding security associations, among the home agents regarding security associations, transfer of
transfer of mobile node bindings, and other service information for mobile node bindings, and other service information for reliable
reliable Mobile IPv6 service in a deployment scenario. 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 actively serves the mobile nodes. A standby home agent takes them actively serves the mobile nodes. A standby home agent takes
over when the active home agent becomes unavailable. The transfer over when the active home agent becomes unavailable. The transfer
of the MN-HA association should be transparent to applications and of the MN-HA association should be transparent to applications and
skipping to change at page 7, line 11 skipping to change at page 7, line 11
the configuration information. For instance, when Mobile IPv6 is the configuration information. For instance, when Mobile IPv6 is
operated with Authentication protocol, the synchronizing the operated with Authentication protocol, the synchronizing the
configurations of the Authentication protocol is out of scope in configurations of the Authentication protocol is out of scope in
this document. Operators MAY correctly configure in multiple home this document. Operators MAY correctly configure in multiple home
agents. agents.
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 10.
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. If a home agent supports an existing an active home agent. If a home agent supports an existing
skipping to change at page 8, line 5 skipping to change at page 8, line 5
2281], it can re-use that mechanism to detect the home agent 2281], it can re-use that mechanism to detect the home agent
failure. On the other hand, periodic Hello messages are failure. On the other hand, periodic Hello messages are
introduced to detect active home agent's service availability in introduced to detect active home agent's service availability in
this document. this document.
Failure Notification Failure Notification
If necessary, a mobile node is notified about the active home If necessary, a mobile node is notified about the active home
agent failure by the standby home agent. agent failure by the standby home agent.
4. Protocol Design 4. Protocol Overview
Mobile IPv6 depends on IPsec and IKE for home binding registration as
described in [RFC-3776]. A mobile node must encrypt a Binding Update
sent to a home agent. In addition, the mobile node exchanges HoTI
and HoT messages through the home agent by using IPsec tunnel mode.
Therefore, before home agent failure, these IPsec states should be
synchronized among home agents of a redundant home agent set. A
mobile node may also encrypt particular data traffic sent to nodes in
the Internet. IPsec information required by Mobile IPv6 is listed
below.
o Security Policy Database (SPD) and Selector Information
o Security Association (SA) for Binding Registration (SA1 and SA2)
o SA for HoTI/HoT Exchange (SA3 and SA4)
o SA for Mobile Prefix Discovery (SA5 and SA6)
o SA for data packets if any (SA7 and SA8)
There are various ways this can be achieved. One is to setup
multiple IPsec security associations between the mobile node and the
home agent sets. Another is to have the home agents periodically
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 the 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 [ID-HASWITCH]) 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
Header messages so that the Home Agent Reliability protocol can be
extended to provide home link redundancy.
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.
5. Protocol Overview
5.1. Home Agent Network Configuration
The Home Agent Reliability protocol supports two different
configurations for standby home agents. Standby home agents can be
placed on the same home link as the active home agent, or on a
different link. The Global Recovery described below is not included
in this document, although the Home Agent Reliability protocol can
support this with slight modifications to home agent operations.
HA1 HA2 HA3 HA4 .... HAn
| | | | |
--------+------+------+------+--------+---------
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 most SDOs
(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 4.1. Home Agent Virtual Switch
A mobile node remains unaware about the change in the active home A mobile node remains unaware about the change in the active home
agent since the home agents have replicated all session state agent since the home agents have replicated all session state
including the IPsec/IKE/ESP states. The IPsec/IKE/ESP state transfer including IPsec/IKE/ESP states. IPsec/IKE/ESP state transfer is out
is out of scope of this document. of scope of this document.
MN HA1(active) HA2(Standby) MN HA1(active) HA2(Standby)
| | . | | .
|<--------->| | 1. IKE exchange (with HoA assignment) |<--------->| | 1. IKE exchange (with HoA assignment)
|---------->| . 2. Binding Update |---------->| . 2. Binding Update
|<----------| . 3. Binding Acknowledgment |<----------| . 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 | 6. HA2 takes over the HA1 | X | 6. HA2 takes over the HA1
| X | | X |
| X | RECOVERY COMPLETE | X | RECOVERY COMPLETE
Figure 3: Overview of Home Agent Virtual Switch Figure 1: Overview of Home Agent Virtual Switch
The operations of the Home Agent Virtual Switch mode are shown in The operations of the Home Agent Virtual Switch mode are shown in
Figure 3. The mobile node first attempts the IKE exchange for Figure 1. A mobile node first attempts the IKE exchange for Security
Security Association (SA) setup and home address assignment (1). Association (SA) setup and home address assignment (1). After
After binding registration is done (2, 3), the active home agent binding registration is done (2, 3), the active home agent pushes all
pushes all the states of its mobile nodes with a state the states of its mobile nodes with a state synchronization message
synchronization message (4). The standby home agent(s) is not active (4). The standby home agent(s) is not active unless it takes over
unless it takes over from a failed home Agent. from a failed home Agent.
When the active home agent's failure is detected (5), the standby When the active home agent's failure is detected (5), the standby
home agent activates the IP address of the failed home agent on it home agent activates the virtual home agent address on its interface
and takes over for the failed home agent. All the home agents in the 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 redundant home agent set share a virtual home agent address and the
routing will ensure only the active home agent will be reachable routing will ensure only the active home agent will be reachable
using that virtual home agent address. The standby home agent can using that virtual home agent address. The standby home agent can
serve all the mobile nodes for which the states are synchronized, serve all the mobile nodes for which the states are synchronized,
without any further message exchange, because it has all the without any further message exchange, because it has all the
necessary information which it obtained from the failed home agent. necessary information which it obtained from the failed home agent.
5.3. Home Agent Hard Switch 4.2. Home Agent Hard Switch
The overview of the Home Agent Hard Switch is shown in Figure 4. The overview of the Home Agent Hard Switch is shown in Figure 2.
This mode is not transparent to the mobile node when the active home This mode is not transparent to the mobile node when the active home
agent failure occurs. agent failure occurs.
MN HA1(active) HA2(Standby) MN HA1(active) HA2(Standby)
| | | | | |
|<--------->| | 1. IKE exchange (with HoA assignment) |<--------->| | 1. IKE exchange (with HoA assignment)
|---------->| | 2. Binding Update |---------->| | 2. Binding Update
|<----------| | 3. Binding Acknowledgment |<----------| | 3. Binding Acknowledgment
|<--------------------->| 4. IKE exchange (without HoA assignment) |<--------------------->| 4. IKE exchange (without HoA assignment)
| | | | | |
skipping to change at page 12, line 35 skipping to change at page 9, line 29
| | | | | |
| X | HA1 FAILURE | X | HA1 FAILURE
| X | | X |
| X<----------| 6. Failure Detection | X<----------| 6. Failure Detection
|<----------------------| 7. Sending Home Agent |<----------------------| 7. Sending Home Agent
| X | Switch message | X | Switch message
|<--------------------->| 8. Binding Registration |<--------------------->| 8. Binding Registration
| X | | X |
| X | RECOVERY COMPLETE | X | RECOVERY COMPLETE
Figure 4: Overview of Home Agent Hard Switch Figure 2: Overview of Home Agent Hard Switch
The mobile node establishes IPsec/IKE state with all the home agents The mobile node establishes IPsec/IKE state with all the home agents
in the redundant home agent set beforehand (1 and 4), however it in the redundant home agent set beforehand (1 and 4), however it
registers its binding only with the active home agent (2 and 3). registers its binding only with the active home agent (2 and 3).
When an active home agent fails, a standby home agent uses a pre- When an active home agent fails, a standby home agent uses a pre-
existing IPsec SA to notify the mobile node about the failure by existing IPsec SA to notify the mobile node about the failure by
securely sending a Home Agent Switch message. In order to discover securely sending a Home Agent Switch message. In order to discover
home agent addresses, two different mechanisms are defined, as home agent addresses, two different mechanisms are defined, as
described in Section 8.1. The active home agent synchronizes the described in Section 9.4.1. The active home agent synchronizes the
required states of the mobile nodes, such as Binding Cache and AAA required states of the mobile nodes, such as Binding Cache and AAA
information, with other standby home agents periodically (5). The information, with other standby home agents periodically (5). The
mobile node MUST NOT request a home address(es) assignment through mobile node MUST NOT request a home address(es) assignment through
the IKE exchange to the standby home agent when it establishes an SA the IKE exchange to the standby home agent when it establishes an SA
with it (4). with it (4).
When the standby home agent detects the failure of the active home 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 agent (6), it sends a Home Agent Switch message to all the mobile
nodes that were registered with the failed home agent (7). The Home nodes that were registered with the failed home agent (7). The Home
Agent Switch message must be encrypted by a pre-established IPsec SA. Agent Switch message must be encrypted by a pre-established IPsec SA.
After the switch message, the mobile node MUST send a binding update After the switch message, the mobile node MUST send a binding update
to the new active home agent in order to update the Mobile IPv6 to the new active home agent in order to update the Mobile IPv6
tunnel end points (8). tunnel end points (8).
5.4. Active Home Agent Management 4.3. Home Agent Management
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
| | | | | | | |
|<-------| | | 3. HA2 sends SwitchCompl (optional) |<-------| | | 3. HA2 sends SwitchCompl (optional)
(standby) (active) | | HA2 BECOMES ACTIVE HA (standby) (active) | | HA2 BECOMES ACTIVE HA
| | | | | | | |
SYSTEM MAINTENANCE, ETC. SYSTEM MAINTENANCE, ETC.
| | | | | | | |
|------->| | | 4. HA1 sends SwitchOver Request |------->| | | 4. HA1 sends SwitchOver Request
|<-------| | | 5. HA2 sends SwitchOver Reply |<-------| | | 5. HA2 sends SwitchOver Reply
| | | | | | | |
|------->| | | 6. HA1 sends SwitchCompl (optional) |------->| | | 6. HA1 sends SwitchCompl (optional)
(active) (standby) | | 7. HA1 returns to active HA (active) (standby) | | 7. HA1 returns to active HA
| | | | HA1 BECOMES ACTIVE AGAIN | | | | HA1 BECOMES ACTIVE AGAIN
Figure 5: Manual Home Agent Change Figure 3: Manual Home Agent Change
In some scenarios the active home agent may need to stop serving In some scenarios the active home agent may need to stop serving
mobile nodes for system maintenance. This specification provides for mobile nodes for system maintenance. This specification provides for
a manual home agent switch by using SwitchBack Request and Reply a manual home agent switch by using SwitchBack Request and Reply
messages. As shown in Figure 5, the active home agent (HA1) sends a messages. As shown in Figure 3, the active home agent (HA1) sends a
SwitchBack Request message to a standby home agent (HA2). As soon as SwitchBack Request message to a standby home agent (HA2). As soon as
HA2 receives the message, it becomes the active home agent. HA2 will HA2 receives the message, it becomes the active home agent. HA2 will
acknowledge the message by sending a SwitchBack Reply message to HA1. acknowledge the message by sending a SwitchBack Reply message to HA1.
HA1 becomes a standby home agent when it receives the SwitchBack HA1 becomes a standby home agent when it receives the SwitchBack
Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in
order to become the active home agent again. order to become the active home agent again.
The SwitchCompl message is used only in the Home Agent Hard Switch. The SwitchCompl message is used only in the Home Agent Hard Switch.
As shown in Section 5.3, it takes certain time to complete the home As shown in Section 9, it takes certain time to complete the home
agent switch. Thus, the old active home agent continue serving the agent switch. Thus, the old active home agent continues serving the
received packets for the mobile nodes during the switch process. As received packets for the mobile nodes during the switch process. As
soon as the new home agent takes over all the mobile nodes, it sends soon as the new home agent completes the recovery, it sends
SwitchCompl message to the previous active home agent. This is SwitchCompl message to the previous active home agent. SwitchCompl
optional operation in this specification. is an optional operation in this specification.
6. Messages 5. Messages
6.1. New Mobility Header Messages 5.1. New Mobility Header Messages
6.1.1. State Synchronization Message 5.1.1. State Synchronization Message
This message is used to exchange state corresponding to a particular This message is used to exchange state corresponding to a particular
mobile node(s). It MUST be unicasted and MUST be authenticated by mobile node(s). It MUST be unicasted and MUST be authenticated by
IPsec ESP. The State Synchronization message has the MH Type value IPsec ESP. This message has the MH Type value TBD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A| Reserved | | Type |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | | Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Mobility Options . . Mobility Options .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: State Synchronization Message Figure 4: State Synchronization Message
Type Type
8-bit unsigned integer. It can be assigned one of the following 8-bit unsigned integer. It can be assigned one of the following
values: values:
0: Request 0: Request
This message is called State Synchronization Request and used This message is called State Synchronization Request (SS-REQ)
to request state corresponding to a particular mobile node. and used to solicit the active state corresponding to a
The State Synchronization Request is used to solicit the active particular mobile node.
state corresponding to a particular mobile node.
1: Reply 1: Reply
The message is called State Synchronization Reply and is used The message is called State Synchronization Reply (SS-REP) and
between the home agents in the redundant home agent set to is used between the home agents in the redundant home agent set
exchange binding cache information and any other information to exchange binding cache information and any other information
related to providing mobility service to the mobile nodes. The related to providing mobility service to the mobile nodes
State Synchronization Reply can be sent by an active home agent either periodically or in response to a SS-REQ.
either periodically or in response to a State Synchronization
Request.
2: Reply-Ack (optional) 2: Reply-Ack
The message is called State Synchronization Reply-Ack and is The message is called State Synchronization Reply-Ack (SS-ACK)
used to acknowledge to the State Synchronization Reply message. and is used to acknowledge to the SS-REP. This message is
This message is optional and is used when the link between two optional and is specially used when the links between home
home agents is not reliable. agents are not reliable.
Ack flag Ack flag
This flag is valid only for State Synchronization Reply message. This flag is valid only for SS-REP. If the sender requires
If the sender requires explicit acknowledgment (i.e. State explicit acknowledgment by SS-ACK, it MUST set this flag.
Synchronization Reply-Ack), it MUST set this flag.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Identifier Identifier
A 16-bit identifier to aid in matching state synchronization A 16-bit identifier to aid in matching state synchronization
message. The identifier should never be set to 0. It should message. The identifier should never be set to 0. It should
always be more than 1. always be more than 1.
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 [RFC-3775]. The and format of defined options are described in [RFC-3775]. The
receiver MUST ignore and skip any options which it does not receiver MUST ignore and skip any options which it does not
understand. understand. This message requires at least one mobility option,
therefore, there is no default length for this message.
One of the following options is mandatory in State Synchronization One of the following options is mandatory in SS-REQ message.
Request message. Multiple same options can be stored in the same Multiple same options can be stored in the same SS-REQ message,
request message, (ex. two IP address options for two mobile (ex. two IP address options for two mobile nodes):
nodes):
* IP Address Option (Sub-type: Home Address) defined in [RFC- * IP Address Option (Sub-type: Home Address) defined in [RFC-
4068]. If a home agent wants the Binding Cache information for 5268]. If a home agent wants the Binding Cache information for
a particular mobile node, it includes the mobile node's home a particular mobile node, it includes the mobile node's home
address in an IPv6 Address Option. If a home agent want to address in an IPv6 Address Option. If a home agent want to
solicit all the active mobile nodes' states, it can include the solicit all the active mobile nodes' states, it can include the
unspecified address (0::0) in an IPv6 address option. unspecified address (0::0) in an IPv6 address option.
* Mobile Network Prefix Option. If a home agent wants to know * Mobile Network Prefix Option. If a home agent wants to know
the forwarding state setup for a particular Mobile Network the forwarding state setup for a particular Mobile Network
Prefix, it includes a Mobile Network Prefix Option as defined Prefix, it includes a Mobile Network Prefix Option as defined
in [RFC-3963]. in [RFC-3963].
* Vendor Specific Mobility Option. If a home agent wants vendor * Vendor Specific Mobility Option. If a home agent wants vendor
specific information, it can solicit with this option as specific information, it can solicit with this option as
defined in [ID-VSM]. defined in [RFC-5094].
One of the following options is mandatory in State Synchronization One of the following options is mandatory in SS-REP:
Reply. :
* Binding Cache Information Option * Binding Cache Information Option
* AAA Information Option * AAA Information Option
* Vendor Specific Mobility Option * Vendor Specific Mobility Option
This message requires at least one mobility option, therefore, there 5.1.2. Home Agent Control Message
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 This message is used to control the status of a home agent to either
active or standby. This message MUST be unicasted between home active or standby. This message MUST be unicasted between home
agents and MUST be authenticated and encrypted by IPsec ESP. The agents and MUST be authenticated and encrypted by IPsec ESP. The
Home Agent Control message has the MH Type value TBD. When this Home Agent Control message has the MH Type value TBD. If no options
value is indicated in the MH Type field, the format of the Message are present in this message, no padding is necessary and the Header
Data field in the Mobility Header is as follows: Len field will be set to 1.
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 | Status | | Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Mobility Options . . Mobility Options .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Home Agent Control Message Figure 5: Home Agent Control Message
Type Type
8-bit unsigned integer. It can be assigned one of the following 8-bit unsigned integer. It can be assigned one of the following
values: values:
0: SwitchOver Request 0: SwitchOver Request (SO-REQ)
This message is called SwitchOver Request. It is unicasted by It is unicasted by a standby home agent that desires to become
a standby home agent that desires to become the active home the active home agent. The receiver of the message MUST
agent. The receiver of the message MUST transition to standby transition to standby state as soon as the message is received
state as soon as the message is received and validated and validated successfully.
successfully.
1: SwitchOver Reply 1: SwitchOver Reply (SO-REP)
This message is called SwitchOver Reply. It is used to It is used to acknowledge the receipt of the corresponding SO-
acknowledge the receipt of the corresponding SwitchOver REQ.
Request.
2: SwitchBack Request 2: SwitchBack Request (SB-REQ)
This message is called SwitchBack Request. It is unicasted by It is unicasted by an active home agent that desires to become
an active home agent that desires to become a standby home a standby home agent. The receiver of this message SHOULD
agent. The receiver of this message SHOULD transition to transition to active state as soon as the message is received
active state as soon as the message is received and validated and validated successfully.
successfully.
3: SwitchBack Reply 3: SwitchBack Reply (SB-REP)
This message is called SwitchBack Reply. It is used to It is used to acknowledge the receipt of the corresponding SB-
acknowledge the receipt of the corresponding SwitchBack REQ.
Request.
4: Switch Complete 4: Switch Complete (SW-COMP)
This message is used to indicate the completion of switch over, This message is used to indicate the completion of switch over,
(i.e. sending home agent switch messages and receiving binding (i.e. sending home agent switch messages and receiving binding
update messages from all the served mobile nodes). update messages from all the served mobile nodes).
Status Status
8-bit unsigned integer indicating the disposition of a Switchover 8-bit unsigned integer indicating the disposition of a SO-REQ or
Request or SwitchBack Request message. This field is only valid SB-REQ. This field is only valid in SO-REP and SB-REP. The
in SwitchOver Reply and SwitchBack Reply messages. The following following Status values are defined:
Status values are defined:
0: Success 0: Success
128: Reason unspecified 128: Reason unspecified
129: Administratively prohibited 129: Administratively prohibited
130: Not active home agent (The receiver of the SwitchOver 130: Not active home agent (The receiver of SO-REQ is not the
Request message is not the active home agent) active home agent)
131: Not standby home agent (The receiver of the SwitchBack 131: Not standby home agent (The receiver of SB-REQ is already
Request is already the active home agent) the active home agent)
132: Not in same redundant home agent set 132: Not in same redundant home agent set
Mobility Options Mobility Options
No options are defined in this specification
Variable-length field of such length that the complete Mobility 5.1.3. Home Agent Hello Message
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 [RFC-3775]. The
receiver MUST ignore and skip any options which it does not
understand. No options are defined in this specification
If no options are present in this message, no padding is necessary
and the Header Len field will be set to 1.
6.1.3. Home Agent Hello Message
This messages can be replaced by other protocols as described in The Home Agent Hello (HA-HELLO) message MUST be either unicasted or
Section 7.10. If this message is used, it MUST be either unicasted multicasted to carry home agent information among the redundant home
or multicasted to carry home agent information among the redundant agent set. The HA-Hello message is defined for two purpose: 1) an
home agent set. The Hello message is defined for two purpose: 1) an alive check and 2) home agent information exchange. A HA-HELLO
alive check and 2) home agent information exchange. A home agent SHOULD be authenticated and encrypted by IPsec ESP when it is
Hello message SHOULD be authenticated and encrypted by IPsec ESP when unicasted. If a HA-Hello message is multicasted, IPsec ESP cannot be
it is unicasted. If a Hello message is multicasted, IPsec ESP cannot applied. In this case the redundant home agent set should be located
be applied. In this case the redundant home agent set should be in a secure network. Alternatively, all the home agents MUST have a
located in a secure network. Alternatively, all the home agents MUST secure channel with each other. The HA-Hello has the MH Type value
have a secure channel with each other. The Hello message has the MH TBD. If no options are present in this message, 0 octets of padding
Type value TBD. When this value is indicated in the MH Type field, are necessary and the Header Len field will be set to 2.
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|R| Reserved | | Hello Interval | Group ID |A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility Options . . Mobility Options .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Home Agent Hello Message Figure 6: 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 HA-Hello
can be used to verify whether this Hello message is the latest one message can be used to verify whether this Hello message is the
or not. latest one 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 message. This preference is the same as the sending the HA-Hello message. This preference is the same as the
Home Agent Preference value of the Home Agent Information option Home Agent Preference value of the Home Agent Information option
as defined in [RFC-3775]. However, operators MAY use a different as defined in [RFC-3775]. However, operators MAY use a different
preference value for this operation. preference value for this operation.
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 message. This lifetime is the same as the Home Agent the HA-Hello message. This lifetime is the same as the Home Agent
Lifetime value of the Home Agent Information option as defined in Lifetime value of the Home Agent Information option as defined in
[RFC-3775]. [RFC-3775].
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 message. 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 Active Home Agent flag. If this flag is set, the sender of this
home agent. Otherwise, the sender is a standby home agent. HA-Hello message is an active home agent.
R flag R flag
If this flag is set, the receiver of this Hello message must send HA-HELLO requesting flag. If this flag is set, the receiver of
back a Hello message to the sender. this HA-Hello message must send back a HA-Hello message to the
sender.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. 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 No valid options are defined in this specification.
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 [RFC-3775]. The
receiver MUST ignore and skip any options which it does not
understand. No valid options are defined in this specification.
If no options are present in this message, 0 octets of padding are
necessary and the Header Len field will be set to 2.
6.1.4. Home Agent Switch Message 5.1.4. Home Agent Switch Message
This message is defined in Section 8.3. The Home Agent Reliability This message is defined in Section 9.4.3. The Home Agent Reliability
protocol extends this message for the Home Agent Hard Switch. protocol extends this message for the Home Agent Hard Switch.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of Addresses |I| Reserved | |# of Addresses |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. Home Agent Addresses . . Home Agent Addresses .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility options . . Mobility options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Home Agent Switch Message Figure 7: Home Agent Switch Message
IPsec Re-key (I) IPsec Re-key (I)
The IPsec rekey (I) bit is set to indicate that the mobile node The IPsec re-key (I) bit is set to indicate that the mobile node
SHOULD start an IPsec re-key with the home agent specified in the SHOULD start an IPsec re-key with the home agent specified in the
Home Agent Addresses field. This flag is used when a failed home 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 agent recovers and needs to re-establish IPsec SA/IKE state with a
mobile node. When this flag is set, the mobile node does not mobile node. When this flag is set, the mobile node does not
switch the home agent, but only re-key the SA. switch the home agent, but only re-key the SA.
Reserved Reserved
The reserve field is reduced from 8 to 7 bits The reserve field is reduced from 8 to 7 bits
6.2. New Mobility Options 5.2. New Mobility Options
6.2.1. IP address Option 5.2.1. IP address Option
This option is already defined in the Fast Handovers for Mobile IPv6 This option is already defined in the Fast Handovers for Mobile IPv6
(FMIP) specification [RFC-4068]. This document introduces new Sub- (FMIP) specification [RFC-5268]. This document introduces new Sub-
Type values for home agent address and Home Address. Type values for home agent address and Home Address.
Option-Code Option-Code
* 4: Home Address * 4: Home Address
6.2.2. Binding Cache Information Option 5.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. The Binding Cache Information option is only valid in a State
Synchronization message. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 40 | | Type = TBD | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number | | Flags | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved | | Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 37 skipping to change at page 18, line 37
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. Mobile Network Prefix Option . . Mobile Network Prefix Option .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Binding Cache Information Option Figure 8: Binding Cache Information Option
The Binding Cache Information option is only valid in a State
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. The 8-bit Reserved field MUST be set mobile node or mobile router. The 8-bit Reserved field MUST be set
to zero. If the R-flag is set to indicate this binding cache entry 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 is for a mobile router, then this option will be immediately followed
by one or more Mobile Network Prefix options. by one or more Mobile Network Prefix options.
6.2.3. AAA Information Option 5.2.3. AAA Information Option
The AAA option is used to carry the AAA state of the mobile node's This option is used to carry the AAA state of the mobile node's
Mobile IPv6 sessions. The AAA state information can be conveyed in Mobile IPv6 sessions. The AAA state information can be carried in
RADIUS or Diameter AVP formats including the user and session info. RADIUS or Diameter AVP formats including the user and session info.
This information option is only valid in a State Synchronization This information option is only valid in a State Synchronization
message. 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 11: Vendor Specific Inforamtion Option Figure 9: 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 Mobile IPv6 and IPsec/ carrying AAA-related information for each Mobile IPv6 and IPsec/
IKE session. IKE session.
7. Home Agent Operation 6. Home Agent Configuration
7.1. Home Agent Address Configuration 6.1. Network Configuration
The Home Agent Reliability protocol supports two different
configurations for standby home agents. Standby home agents can be
placed on the same home link or on a different link.
HA1 HA2 HA3 HA4 .... HAn
| | | | |
--------+------+------+------+--------+---------
Home Link
Figure 10: Local Recovery Configuration
Figure 10 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
(region-1) (region-2)
Figure 11: Global Recovery Configuration
Figure 11 illustrates when standby home agents are located on a
different link (illustrated as Recovery Link in Figure 11). Most
large operators have a very stringent requirement on network
availability even in the worst type of disaster or outage. For
example, HAs in region-1 are backed up by HAs 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. It
can achieve home agent recovery even if the entire home link fails.
In Figure 11, 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 routing must
be also updated to direct the packets meant for the home link to the
recovery link.
6.2. Address Configuration for Virtual Switch
Each standby home agent obtains its individual IPv6 address from its Each standby home agent obtains its individual IPv6 address from its
attached link. This IPv6 address is used by the home agent attached link. This IPv6 address is used by the home agent
reliability protocol to exchange information with the associated home reliability protocol to exchange information with the associated home
agents. The link between home agents should be secured. agents. The link between home agents should be secured.
When the Home Agent Virtual Switch mode is used, the virtual home The virtual home agent's IPv6 address which is known by the mobile
agent IPv6 address which is known by the mobile node is shared with node is shared with the standby home agents. When a home agent
the standby home agents. When a home agent fails, the standby home fails, the standby home agent activates the IPv6 address of the
agent activates the IPv6 address of the failed home agent and becomes failed home agent and becomes the active home agent. The standby
the active home agent. The standby home agent should not activate home agent should not activate the IPv6 address until it knows the
the IPv6 address until it knows the active home agent is no longer active home agent is no longer reachable at the address, otherwise
reachable at the address, otherwise address duplication will occur. address duplication will occur. To guarantee transparency of the
To guarantee transparency of the home agent virtual switch to mobile home agent virtual switch to mobile nodes located on the home link,
nodes located on the home link, the neighbor cache of the home agent the neighbor cache of the home agent IP address MUST be carefully
IP address MUST be carefully operated. See Section 7.2 in detail. operated. See Section 8.1 in detail.
When the Home Agent Hard Switch mode is used, each home agent 6.3. Address Configuration for Hard Switch
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.
7.2. Consideration of Routing and Neighbor Discovery Protocol Each standby home agent obtains its individual IPv6 address from its
attached link. This IPv6 address is used by the home agent
reliability protocol to exchange information with the associated home
agents. The link between home agents should be secured.
This section gives a brief explanation of how a home agent interacts Each home agent configures itself with a different IPv6 address from
with routing and Neighbor Discovery Protocol (NDP) when the Home the same home prefix. This IPv6 address can be used for the Home
Agent Virtual Switch mode is used. Agent Reliability protocol if the standby home agents are located at
the same link of the active home agent (Figure 10). In case of
Figure 11, the router must carefully route packets to the standby
home agents as described in Section 8.1. 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.
When a standby home agent becomes active in the Home Agent Virtual 7. Home Agent Common Operation
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.
For instance, home agents should run OSPF with the appropriate cost 7.1. Home Agent List Management
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.
When an active home agent activates a home agent address, it SHOULD In Mobile IPv6 [RFC-3775], each home agent periodically sends router
use a virtual MAC address as introduced in [RFC-3768]. When the advertisements with the Home Address Information option [RFC-3775]
active home agent is changed, the neighbor cache of the active home when there are multiple home agents present on a link. This
agent is not necessarily updated on mobile nodes located on the home information is managed in a home agent list. For the Home Agent
link. Otherwise, the new home agent MUST update the neighbor cache Reliability Protocol, HA-HELLO messages are used to manage the home
entry for the home agent address on all the mobile nodes located on agent list. There are several reasons to use HA-HELLO message
the home link. In addition, Mobile IPv6 uses proxy NDP to intercept instead of Router Advertisement such as:
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.
7.3. Home Agent List Management 1. In the Home Agent Virtual Switch mode, if the standby home agents
send unsolicited Router Advertisements to the home link, the
mobile nodes attached to the home link are aware of the presence
of standby home agents. However, the standby home agents must be
hidden until the active home agent fails. HA-Hello messages are
exchanged only between home agents.
In Mobile IPv6 [RFC-3775], each home agent periodically sends router 2. As shown in Section 6.1, standby home agents are not always
advertisements with a Home Address Information option [RFC-3775] for configured at the same link. In this case, Router Advertisements
exchanging home agent information when there are multiple home agents cannot be sent to the recovery link unless the home link and the
present on a link. This information is managed in a home agent list recovery link are connected (ex. L2TP). HA-HELLO can be sent
introduced in [RFC-3775]. When the Home Agent Reliability Protocol beyond the link.
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:
1. Router Advertisements are sent among home agents and also to 3. The Home Agent Reliability protocol defines to manage additional
mobile nodes. When the Home Agent Virtual Switch mode is used, information such as Group ID and Active/Standby Status of the
standby home agents MUST NOT generate unsolicited Router home agents in the home agent list.
Advertisements. The standby home agents MUST be transparent to
all mobile nodes. Hello messages are exchanged only with other
home agents.
2. Router Solicitation and Advertisement messages [RFC-2461] cannot In Mobile IPv6, Router Advertisement are to carry the home agent
be used due to link-local limitations. However, as shown in information to both mobile nodes on the home link and the home
Section 5.1, standby home agents are not always configured on the agents. On the other hand, in the Home Agent Reliability protocol,
same link. Router Advertisements cannot be used in this case. HA-Hello is to exchange the information among the home agents and the
Router Advertisement is used to notify the information to the mobile
nodes. The home agents SHOULD NOT process the Home Agent Information
option carried by Router Advertisement if HA-HELLO is available.
Operators can define different values to the parameters of the home
agent information for HA-HELLO and Router Advertisement. The
management operation of the home agent list is unchanged and defined
in [RFC-3775].
3. The Home Agent Reliability protocol is required to exchange 7.2. Detecting Home Agent Failure
additional information such as Group ID and Active/Standby Status
of the home agents.
When Hello messages are used, the Home Agent Information Option [RFC- The active and standby home agents can monitor each other in several
3775] MAY NOT be used in Router Advertisements on the home link, ways. One method is to reuse other failure detection mechanisms
because all necessary information will be present in the Hello defined in VRRP[RFC-3768] and HSRP [RFC-2281] (see Section 7.6).
messages. However, mobile nodes located on the home link require However, VRRP and HSRP cannot detect the case where the system is
this information for home agent discovery. In addition, if operators running but the Mobile IPv6 stack is not operational. In the Home
want to use different parameters such as Preference value for home Agent Reliability protocol, a new message called HA-HELLO is
agents and mobile nodes, they can utilize both Router Advertisements periodically exchanged in the redundant home agent set as a heart-
and Hello messages. Router Advertisements are used to carry the home beat. If HA-HELLO is implemented as a part of Mobile IPv6 stack, it
agent information for mobile nodes, and Hello message are used to can detect the home agent failure (Mobile IPv6 stack failure). This
carry information for Home Agent Reliability operation. If an HA-HELLO can also be exchanged frequently enough to detect the
operator decides not to use the Hello messages, Router Advertisements failure promptly and does not introduce any processing overhead to
MUST be used to update the home agent list. the mobile node attached to the home link.
Since Hello messages carry all the necessary information filled-in Failure events used in the Home Agent Reliability protocol are listed
from the home agent list, the management of the home agent list is below.
unchanged. If a standby home agent removes an active home agent from
the list because its lifetime has become zero, it can start recovery
according to this document. Section 7.4 describes failure detection
in detail.
7.4. Detecting Home Agent Failure Loss of HA-HELLO
The active and standby home agents can monitor each other's status in In the event that a standby home agent does not receive any HA-
multiple ways. One method is to reuse other failure detection HELLO from its peer which is currently the active home agent for a
mechanisms such as VRRP[RFC-3768] and HSRP [RFC-2281] described in configurable duration, the standby home agent assumes the active
Section 7.10. This document also defines its own method by using home agent's failure. Any home agents can also request the home
periodic exchanges of Hello messages to monitor status. The reasons agent information of the other home agent in the same redundant
to specify Hello messages are: home agent set by sending HA-HELLO with R-flag set. If HA-HELLO
is not replied from the target home agent within a configurable
amount of time, that home agent peer is considered to have failed.
The detail of the Hello message is described in Section 7.3.
1. Hello messages can be sent off-link for global recovery is Monitored Server Failure by the Active Home Agent
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.
2. If Router Advertisements and VRRP are used for periodic messages, There may be number of critical servers such as AAA server in the
they may not detect the case where the system is running but the network that are essential for the ongoing Mobile IPv6 sessions at
Mobile IPv6 stack is not operational. Mobile IPv6 may be the home agent. Operators can have a policy in place that the
implemented as a userland daemon, so if Hello messages are used, active home agent is treated as a failed home agent upon detecting
the failure of a home agent can be easily detected, assuming that the link to such servers has failed.
Hello message functionality is implemented in the same home agent
daemon.
3. Hello messages can be frequently exchanged to detect failure, Routing Peer/Link Failure
while there is a restriction on how often Router Advertisements
can be sent, and on how they are processed by routers that
receive them. Router Advertisements are also not sent frequently
enough to rely on their absence to detect a home agent failure.
A Hello request message (R-flag set) may be used by any home agent to Operators may require the home agent to detect its next-hop
request state information from any other home agent in the redundant routing peer failure. If the next-hop routing failure is fatal in
home agent set. If a Hello message is not received from a home agent nature, or due to some other routing policies, the active home
peer within a configurable amount of time, then that home agent peer agent is treated as a failed home gent and the recovering
is considered to have failed. The detail of the Hello message is operation should be started.
described in Section 7.6. Failure events used in the Home Agent
Reliability protocol are listed below.
Loss of Communication with the Active Peer Home Agent 7.3. Processing Hello Messages
In the event that a standby home agent does not receive any Hello HA-HELLO MUST be either unicasted or multicasted. A new multicast
message from its peer which is currently the active home agent for address (all_homeagent_multicast_address) will be assigned by the
a configurable duration, the standby home agent may decide to IANA. When all the home agents in a redundant home agent set are
become the active home agent. configured on a same home link, they MUST join the
all_homeagent_multicast_address. On the other hand, if a home
recovery link is separately defined as described in Figure 11, each
home agent SHOULD unicast HA-HELLO.
Monitored Server Failure by the Active Home Agent 7.3.1. Requesting Hello Message
There may be number of critical servers in the network that are A home agent can solicit HA-HELLO to a particular home agent in the
essential for the ongoing Mobile IPv6 sessions at the home agent. same redundant home agent set by unicasting HA-HELLO with the R-flag
One such server may be the AAA server which is receiving the set. The sender MUST fill the fields of the HA-HELLO with its home
accounting information for the session. The operator may have a agent information. If a home agent needs to request HA-HELLO to all
policy in place that requires the home agent to initiate a switch- the home agents, it sends the HA-HELLO with R-flag set to the
over procedure upon detecting that the link to such a server has all_homeagent_multicast_address. Requesting HA-HELLO SHOULD be
failed. operated when:
Routing Peer/Link Failure 1. A new home agent needs to collect the information of all the
other home agents in the same redundant home agent set. The HA-
HELLO with R-flag set is multicasted to
all_homeagent_multicast_address.
In some cases, an operator may require the home agent to detect a 2. A home agent entry in the redundant home agent list is about to
next-hop routing peer failure. If the next-hop routing peer be removed due to home agent lifetime expiration. The HA-HELLO
fails, the operator may want the home agent to initiate a switch- with R-flag set is unicasted to the home agent whose lifetime is
over procedure if the failure is fatal in nature, or due to some soon expired.
other routing policies.
7.5. Home Agent Switch Over 3. HA-HELLO has not been received during the specified hello
interval. The HA-HELLO with R-flag set is unicasted to the
target home agent.
After detecting the active home agent has failed, the standby home 7.3.2. Sending Hello Message
agent whose preference value is the highest MUST take over for the
failed home agent. Alternately, if Home Agent Control messages are
used, a standby home agent who will be the new active home agent is
determined during the Home Agent Control message exchanges.
In the Home Agent Virtual Switch mode, the standby home agent MUST Each home agent periodically sends HA-HELLO for the home agent's
activate the virtual home agent address. If a virtual MAC address as failure detection. The interval time is configured at each home
introduced in [RFC-3768] is used, the standby home agent MUST start agent. Each home agent MUST also send a HA-HELLO in following case:
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.
In the Home Agent Hard Switch mode, the standby home agent MUST send 1. when a home agent receives a HA-HELLO with the R-flag set
a Home Agent Switch message to all the mobile nodes that were
registered at the failed home agent as described in Section 7.9,
using the pre-established IPsec SA. The standby Home Agent MUST set
its own address in the Home Agent Address field in the Home Agent
Switch message so that it will receive the binding update from the
mobile node as an acknowledgement of the sent Home Agent Switch
message. The home agent switch-over is complete when it receives
binding updates from all the mobile nodes. It is important to remark
that sending Home Agent Switch messages to all the mobile nodes at
once may bring non-negligible overhead to the home agent.
This overhead cannot be avoided if the active home agent suddenly 2. When a home agent detects its local information such as home
stop serving mobile node because of unexpected reasons (crash, agent preference, home agent lifetime, and registration status
network trouble, etc). However, if this switch over is operated change.
under the administrative operation (maintenance, etc), the previous
active home agent may continue serving the mobile nodes until the
switch over is completed. Until the mobile node sends a binding
update to the new active home agent, it still sends the packet to the
previous home agent in the Home Agent Hard Switch. Therefore, the
new active home agent can notify the completion of switch-over to the
previous active home agent by using Home Agent Control message as
described in Section 7.8.3. As soon as this message is received, the
previous active home agent can be shutdown or detached from the
network safely.
7.6. Processing Hello Messages 3. 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 its own Hello message.
Hello messages can be unicasted or multicasted. A new multicast When a home agent sends HA-HELLO, the following rule MUST be applied.
address will be assigned by the IANA. When all home agents in a
redundant home agent set are configured on a same home link, they
MUST join a new multicast address (TBA) and multicast Hello. On the
other hand, if a home link is separated as described in Figure 2,
each home agent MUST unicast Hello messages.
7.6.1. Requesting Hello Message o Whenever a home agent generates HA-HELLO, it MUST increment in the
Sequence Number. The Sequence Number SHOULD be initialized to
zero for the first Hello message. To accomplish sequence number
rollover, if the sequence number has already been assigned to be
the largest possible number representable as a 16-bit unsigned
integer, then when it is incremented it will then have a value of
zero (0).
A home agent can solicit a Hello message from a particular home agent o It MUST also specify its own Group ID in HA-HELLO.
in the same redundant home agent set by unicasting a Hello message
with the R-flag set. The sender MUST fill the fields of the Hello
message with its home agent information. A home agent can solicit a
Hello message from all the home agents in the multicast group by
multicasting a Hello message with the R-flag set. This Hello request
message SHOULD be generated when:
o A new home agent needs to collect information of the other home o If a home agent is the active home agent, it MUST set the A-flag
agents in the same redundant home agent set. In this case it in HA-HELLO.
SHOULD multicast a Hello message in which the R-flag is set.
o A home agent entry in the redundant home agent list is about to be o In the Home Agent Hard Switch mode, the source IPv6 address of HA-
removed due to home agent lifetime expiration. HELLO MUST be the home agent address.
o A Hello message has not been received during the specified hello o In the Home Agent Virtual Switch mode, the home agent local
interval. address MUST be used.
7.6.2. Sending Hello Message 7.3.3. Receiving Hello Message
The Hello message MUST be sent when a home agent receives a Hello When a home agent receives HA-HELLO, it SHOULD verify the HA-HELLO as
message with the R-flag set, indicating a request is required, follows:
otherwise Hello messages are periodically sent according to the pre-
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 its own Hello message.
Whenever a home agent generates Hello message, it MUST increment in o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be
the Sequence Number by 1. The Sequence Number SHOULD be initialized discarded. Note that, only if the HA-HELLO is sent on a dedicated
to zero for the first Hello message. To accomplish sequence number link between the home agents, IPsec protection might not be always
rollover, if the sequence number has already been assigned to be the required. This depends on the operational policy.
largest possible number representable as a 16-bit unsigned integer,
then when it is incremented it will then have a value of zero (0).
It MUST also specify its own Group ID in the Group ID field of the
Hello message. If a home agent is the active home agent, it MUST set
the A-flag in it's Hello Messages. In the Home Agent Hard Switch
mode, the source address of Hello messages MUST be the configured
home agent address. In the Home Agent Virtual Switch mode, the
individual IPv6 addresses of each home agent MUST be used.
7.6.3. Receiving Hello Message o If HA-HELLO is sent from non global IPv6 address, it MUST be
discarded.
When a home agent receives a Hello message, it SHOULD verify IPsec o If the source IPv6 address of HA-HELLO is not belong to one of the
ESP protection. If the message is not protected, it SHOULD be home agents in the redundant home agent set, the HA-HELLO MUST be
silently discarded. However, if the Hello messages is sent on a ignored.
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.
If the sending home agent is not in the same redundant home agent o If the Group ID field of the received HA-HELLO and the receiver's
set, the message MUST be silently ignored. This can be done by Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST
comparing the Group ID field of the received Hello message with its NOT be sent to home agents whose Group ID is different from the
own Group ID value. Hello messages MUST NOT be sent to a home agent sender.
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.
Any Hello message satisfying all of these tests MUST be processed to o If the Sequence Number value in the HA-HELLO is equal to or less
update the redundant home agent list. The receiver copies home agent than the last received Sequence Number value stored in the home
information in the Hello message to the corresponding redundant home agent list entry, the HA-HELLO MUST be discarded.
agent list entry. The home agent address of the sender is retrieved
from the Source Address field of the IPv6 header of the Hello
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.
If the R-flag is set in the received Hello message, the receiver MUST o HA-HELLO satisfying all of above tests MUST be processed by
reply with a Hello message to the originator as described in receiver. The receiver copies home agent information in HA-HELLO
Section 7.6.2. to the corresponding home agent list entry. The home agent
address of the sender is retrieved from the Source Address field
of the IPv6 header of the HA-HELLO.
7.7. Processing State Synchronization Messages o If the home agent lifetime field in the HA-HELLO is set to 0, the
receiver removes the sender from the home agents list.
o If the R-flag is set in the received HA-HELLO, the receiver MUST
send a new HA-HELLO to the originator as described in
Section 7.3.2.
7.4. Processing State Synchronization Messages
It is necessary for standby home agents to synchronize the state It is necessary for standby home agents to synchronize the state
information of each mobile node registered with the active home information of each mobile node registered with the active home
agent. In the Home Agent Virtual Switch mode, the synchronized state agent. In the Home Agent Hard Switch mode, it is not necessary for
information is used by a standby home agent when it takes over for the home agents to synchronize the complete binding cache
the failed home agent. In the Home Agent Hard Switch mode, the information. The standby home agent needs the mapping information of
standby home agent starts the switch-over of all the mobile nodes the active home agent and the mobile node. The information is used
registered to the failed home agent when the home agent failure is to send the Home Agent Switch messages to all the mobile node served
detected. Thus, the Binding Cache entry MUST be modified to keep the by the failed home agent.
active home agent address of each mobile node.
7.7.1. Soliciting State of a Particular Mobile Node or Subset of Mobile 7.4.1. Requesting State of a Particular Mobile Node(s)
Nodes
When a standby home agent wants state information for a particular When a home agent needs the state information for a particular mobile
mobile node or a subset of mobile nodes, such as Binding Cache, AAA, node or a subset of mobile nodes, it sends a SS-REQ message
etc., it MAY solicit this state by sending a State Synchronization constructed as follows:
message constructed as follows:
o It MUST set the Type field to 0 (Request). o It MUST set the Type field to 0 (Request).
o It MUST set a random value in the Identifier field that does not o It MUST set a random value in the Identifier field that does not
coincide with any other currently pending Requests. coincide with any other currently pending Requests.
o It MUST include either a IP address mobility option which subtype o It MUST include an IP address mobility option(s) which subtype is
is set to home address indicating the mobile node, or a Mobile set to the home address if the target is mobile node(s).
Network Prefix mobility option indicating the mobile router. The
standby home agent can send multiple home address and mobile
network prefix mobility options to request state information for
multiple mobile nodes in a single State Synchronization request
message.
o It MUST set the unspecified address (0::0) in the Home Address
mobility option if it solicits all the active mobile nodes' and
mobile routers' state at once.
When a home agent receives the State Synchronization message with the o It MUST include a Mobile Network Prefix mobility option(s) for
Type field set to 0 (Request), it MUST verify the message as follows: mobile router(s).
o The state synchronization message MUST be protected by IPsec ESP. o It MUST set the unspecified address (0::0) in the Home Address
mobility option if it solicits the state of all the mobile nodes
and mobile routers registering at the receiver of SS-REQ
(i.e.destination of SS-REQ).
o The sending home agent MUST belong to the same redundant home o In the Home Agent Virtual Switch, the sender of the SS-REQ MUST be
agent set a home agent local address of one of the home agents in the same
redundant home agent set.
o The receiver MUST be the active home agent for the requested home o In the Home Agent Hard Switch, the sender of the SS-REQ MUST be a
address or mobile network prefix. home agent address of one of the home agents in the same redundant
home agent set.
Any packet carrying a State Synchronization message which fails to o The destination of the SS-REQ MUST be the active home agent for
satisfy all of these tests MUST be silently ignored. the requesting home address or mobile network prefix. The standby
home agent MUST NOT reply the SS-RREP to the sender.
Otherwise, the receiver MUST reply with a State Synchronization When a home agent receives the SS-REQ, it MUST verify if SS-REQ is
message including state information for the requested mobile node(s) constructed with the above rules. If SS-REQ satisfy all the above
and/or mobile network prefix(es) as described in Section tests, the receiver of the SS-REQ MUST reply SS-REP including the
Section 7.7.2. state information of the requested mobile node(s) and/or mobile
network prefix(es) as described in Section Section 7.4.2.
7.7.2. Synchronizing State of Mobile Nodes 7.4.2. Synchronizing State
A state synchronization message can be sent either: State synchronization messages SHOULD be sent when:
o When an active home agent receives a state synchronization message 1. The active home agent receives SS-REQ.
in which the Type field is set to 0 (Request).
o When an active home agent creates a binding cache entry for a 2. The active home agent creates a binding cache entry for a
particular mobile node. particular mobile node.
o When an active home agent deletes a binding cache entry for a 3. The active home agent deletes a binding cache entry for a
particular mobile node. particular mobile node.
o When an active home agent updates a binding cache entry for a The active home agent MAY additionally send state synchronization
particular mobile node, only when operating in the Home Agent message in following cases:
Virtual Switch mode. In the Home Agent Hard Switch mode, standby
home agents only use this binding cache information to send a Home
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.
o In a periodic interval to update the state information for all 1. The active home agent update the state information for all
sessions that changed since the last update. sessions that changed since the last update in a periodic
interval
2. Only for the Home Agent Virtual Switch mode, the active home
agent updates a binding cache entry for a particular mobile node
whenever the binding cache entry is updated. In the Home Agent
Hard Switch mode, standby home agents only need the mapping
information of a home address of the mobile node/router and the
home agent address of the active home agent to which the mobile
node/router is currently registering. This mapping is used to
send a Home Agent Switch message.
If an active home agent sends a State Synchronization message If an active home agent sends a State Synchronization message
whenever the local state information changes, such as a binding cache whenever the local state information changes, such as a binding cache
change, the number of the State Synchronization messages sent can be change, the number of the State Synchronization messages sent can be
quite large. quite large.
The binding cache information of the requested mobile nodes is stored All the state information of the requested mobile nodes is stored in
in the State Synchronization message. The active home agent MUST the SS-REP. Following rules must be applied when the active home
copy the binding cache information of the requested mobile nodes into constructs SS-REP.
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.
When the active home agent stores the state of multiple mobile nodes o If the SS-REP is sent in response to the SS-REQ, the active home
in a state synchronization message, a Binding Cache Information agent MUST copy the Identifier field of the State Synchronization
option is used as a separator. For each mobile node, a Binding Cache request message to the Identifier field in the SS-REP. Otherwise,
Information option is placed first, followed by any other options. it MUST set the Identifier field to 0.
When the next Binding Cache Information option is reached in the
State Synchronization message, it indicates the information of a
different mobile node.
If the unspecified address is found in the Home Address mobility o When the active home agent stores the state of multiple mobile
option carried with the State Synchronization request message, the nodes in a SS-REP, a Binding Cache Information option is used as a
active home agent MUST return all the active mobile nodes' and mobile separator. For each mobile node, a Binding Cache Information
routers' states by the State Synchronization reply message. The IP option is placed first, followed by any other options such as AAA
fragmentation can be occurred depending on the total size of all the option. When the next Binding Cache Information option is reached
states. in the State Synchronization message, it indicates the information
of a different mobile node.
A State Synchronization message MUST be authenticated and encrypted o If the unspecified address is found in the Home Address mobility
by IPsec ESP mode, otherwise the message MUST be ignored. When a option carried with the SS-REQ, the active home agent MUST return
home agent receives a State Synchronization message, it MUST verify the state of all the active mobile nodes and mobile routers by the
the Source address field of the IPv6 header. If the source address SS-REP. The IP fragmentation can be occurred depending on the
does not belong to any home agent in the redundant home agent set, total size of all the states.
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.7.3. Explicit Acknowledgement of the State Synchronization Reply o A SS-REP MUST be authenticated and encrypted by IPsec ESP.
message
The Home Agent Reliability protocol does not support any reliable o The destination and source home agents MUST belong to the same
transport mechanism for Mobility Header signaling, this specification redundant home agent set.
assumes that the link between home agents is stable and reliable.
However, operators may need more explicit notification to confirm the
message exchanges between home agents. This specification provides
an optional acknowledgment for the State Synchronization Reply
message.
If an active home agent requires an acknowledgment of a State o In the Home Agent Hard Switch, the IPv6 source address MUST be set
Synchronization Reply message, it MUST set the Ack flag in the to the home agent address of the sender.
message. If a standby home agent receives a State Synchronization
Reply message with the Ack flag set, it MUST send back a State
Synchronization Reply-Ack message as an acknowledgment.
The standby home agent MUST copy the Identifier received in the State o In the Home Agent Virtual Switch, the IPv6 source address MUST be
Synchronization Reply message into the Reply-Ack and set the type set to the home agent local address of the sender.
field to 2 (Reply-Ack).
7.8. Processing Home Agent Control Messages When a home agent receives a SS-REP, it MUST verify whether the SS-
REP is constructed with the above rules or not. If the SS-REP does
not satisfy all the rules above, it is discarded. Otherwise, the
following operation must be taken.
7.8.1. Standby Home Agent becomes an Active Home Agent o The receiver of SS-REP MUST update its binding cache and all other
necessary information such as AAA and vendor specific information
in the particular database.
When a standby home agent decides to become an active home agent, the o In the Home Agent Hard Switch mode, the receiver MUST record the
standby home agent sends a SwitchOver Request message (a Home Agent IPv6 address of the sender as the active home agent of the mobile
Control message in which the Type field is set to 0) to the active node.
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.
When an active home agent receives a SwitchOver Request, it first 7.4.3. Reliable Transmission by Explicit Acknowledgement
verifies the received Home Agent Control message. If the request
message is not protected by IPsec, it MUST be silently discarded. If
the home agent is not an active home agent, it MUST send a SwitchOver
Reply message (a Home Agent Control message in which the Type field
is set to 1) with the Status field set to 130 (Not active home
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).
The SwitchOver Reply message MUST be protected by IPsec ESP. Signaling messages of the Home Agent Reliability protocol are not
Otherwise, the message MUST be silently discarded. If the receiving guaranteed reliable transmission due to the Mobility Header use.
home agent did not send a SwitchOver Request message (i.e. unexpected This is not always critical, because the link between home agents is
SwitchOver Reply), the message MUST be silently ignored. If the carefully managed as stable and reliable. However, operators may
Status field of the SwitchOver Reply message is 0 (Success), the need more explicit notification to confirm the message exchanges
receiving standby home agent immediately becomes an active home agent between home agents. This specification provides an optional
as described in Section 7.5. If the value in the Status field is acknowledgment to SS-REP messages.
greater than 128 an error has occurred. In this case, the receiver
MUST NOT become an active home agent.
7.8.2. Active Home Agent becomes in-active If an active home agent requires an acknowledgment of SS-REP, it set
the Ack flag in the SS-REP. The receiver of such SS-REP will send
back a SS-ACK. The receiver MUST copy the Identifier value received
in the SS-REP into SS-ACK in order to match the SS-REP and SS-ACK.
When an active home agent decides to become an in-active home agent, 7.5. Processing Home Agent Control Messages
it sends a SwitchBack Request message (i.e. a Home Agent Control
message with Type field set to 3) to a standby home agent. The 7.5.1. Standby Home Agent becomes an Active Home Agent
reason for the active home agent to send this message can be
administrative intervention, and events like Monitored Server Failure When a standby home agent decides to become an active home agent, the
by the active home agent or Routing Peer/Link Failure. This message standby home agent sends a SO-REQ to the active home agent. This
MUST be unicasted to one of the standby home agents and MUST be message MUST be unicasted to the active home agent and MUST be
encrypted and authenticated by IPsec ESP. A standby home agent MUST encrypted and authenticated by IPsec ESP. The active home Agent MUST
NOT generate this message. NOT generate this message.
A SwitchBack Reply is sent in reply to a SwitchBack Request message. When an active home agent receives a SO-REQ, it MUST operate the
following verification and operations:
o If the SO-REQ is not protected by IPsec, it MUST be discarded.
o If the receiver of the SO-REQ is not an active home agent, it MUST
send a SO-REP with the Status field set to 130 (Not active home
agent).
o If the sender home agent does not belong to the same redundant
home agent set, a SO-REP message MUST be sent to the sender with
the Status field set to 132 (Not in same redundant home agent
set).
o If the receiver is an active home agent, there is case where the
active home agent cannot be standby home agent. In such case, the
active home agent can reply a SO-REP with the Status field set to
129 (Administratively prohibited).
o Otherwise, the active home agent MUST become a standby home agent
and reply with a SO-REP message with the Status field set to 0
(Success).
The SO-REP MUST be also protected by IPsec ESP. Otherwise, the
message MUST be silently discarded. If the receiver of SO-REP did
not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST
be ignored. If the Status field of the SwitchOver Reply message is 0
(Success), the receiving standby home agent immediately becomes an
active home agent as described in Section 8.2. If the value in the
Status field is greater than 128 an error has occurred. In this
case, the receiver MUST NOT attempt to be an active home agent.
7.5.2. Active Home Agent becomes in-active
When an active home agent decides to become a standby home agent, it
sends a SB-REQ to one of standby home agent. The reason for the
active home agent to send this message can be 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.
When a home agent receives a SwitchBack Request message, it first When a home agent receives a SwitchBack Request message, it first
verifies the message. If the SwitchBack Request message is not verifies the message.
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.
If a home agent receives a SwitchBack Reply message, it MUST be o If the SwitchBack Request message is not protected by IPsec ESP,
protected by IPsec ESP, otherwise the message MUST be silently it MUST be discarded.
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
and the standby home agent becomes active home agent as described in
Section 7.5. 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.8.3. Notification of Home Agent Switch Completion o If the sender home agent of the SB-REQ is not an active home
agent, the receiver MUST reply a SB-REP with the Status field is
set to 130 (Not active home agent).
If the new active home agent completes the switch-over as described o If the sending home agent does not belong to the same redundant
in Section 7.5, it SHOULD send a Home Agent Control message with the home agent set, a SB-REP MUST be sent in which the Status field
type field set to 4 (Switch Complete) to the previous active home set to 132 (Not in same redundant home agent set).
agent in the Home Agent Hard Switch case. Until the previous home
agent receives this message, it SHOULD continue serving any mobile
nodes that are registered with it. Once the previous home agent
receives a Switch Complete message, it can stop offering home agent
services.
7.9. Sending Home Agent Switch Messages o Otherwise, the receiving home agent MUST send a SB-REP with the
Status field is set to 0 (Success).
This operation is valid only for the Home Agent Hard Switch mode. After sending the SwitchBack reply, it MUST NOT become an active home
The standby home agent MUST send a Home Agent Switch message as agent immediately. This is because the active home agent is still
defined in [ID-HASWITCH] to all the mobile nodes that were being active until it receives the SB-REP which is acknowledging the SB-
served by the failed home agent. Since the active home agent address REQ. The standby home agent SHOULD change to active at least after
is recorded in each synchronized binding cache, the standby home LINK_TRAVERSAL_TIME.
agent knows which mobile nodes were served by the failed home agent.
The Home Agent Switch message must be encrypted with a pre-
established SA. The standby home agent MUST include only its own
IPv6 address in the Home Agent Switch message. Note that a Home
Agent Switch message is sent to each mobile node served by the home
agent. If there is a large number of mobile nodes, sending Home
Agent Switch messages will cause a lot of signaling overhead on the
network. The previous active home agent MAY serve mobile nodes while
the new active home agent completes the sending home agent switch and
receiving binding update from all the mobile nodes. This is the case
when the previous home agent will be halt due to administrative
reason.
When a failed home agent recovers, it MUST re-establish an IPsec SA If a home agent receives a SB-REP, it MUST be protected by IPsec ESP,
with each mobile node served by its redundant home agent set. otherwise the message MUST be silently discarded. If the receiving
Otherwise, it cannot be either a standby or active home agent for the home agent did not send a SB-REQ matched to the received SB-REP, the
mobile nodes. Therefore, as soon as the active home agent detects message MUST be silently discarded. If the Status field of the SB-
the recovery of the failed home agent, it sends a Home Agent Switch REP is 0 (Success), the active home agent immediately becomes a
message with the I-flag set to all the mobile nodes serving by other standby home agent. The sender home agent of SB-REP becomes active
home agents in the same redundant home agent set, and includes the home agent as described in Section 8.2. If the value in the Status
recovered home agent address in the Home Agent Addresses field. The field is greater than 128, the receiver of SB-REP (active home agent)
mobile node will re-key the SA, but it will not change the home agent cannot become a standby home agent and MUST continue to be an active
by this home agent switch message which I-flag is on. home agent.
7.10. Interworking with VRRP 7.6. Interworking with VRRP
VRRP and HSRP specify an election protocol that dynamically assigns VRRP and HSRP specify an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a responsibility for a virtual router to one of the VRRP routers on a
LAN. This operation is similar to the Home Agent Virtual Switch LAN. This operation is similar to the Home Agent Virtual Switch
operation. For example, the VRRP router controlling the IP operation. For example, the VRRP router controlling the IP
address(es) associated with a virtual router is called the Master, address(es) associated with a virtual router is called the Master,
and forwards packets sent to these IP addresses. The election and forwards packets sent to these IP addresses. The election
process provides dynamic fail over in the forwarding responsibility process provides dynamic fail over in the forwarding responsibility
should the Master become unavailable. Although VRRP is used to should the Master become unavailable. Although VRRP is used to
guarantee home agent address reachability, it cannot be used for guarantee home agent address reachability, it cannot be used for
state synchronization and explicit switching of Master and Backup. state synchronization and explicit switching of Master and Backup.
Thus, the Home Agent Reliability protocol cannot be replaced by VRRP. Thus, the Home Agent Reliability protocol cannot be replaced by VRRP.
This section explains how VRRP can interwork with the Home Agent This section explains how VRRP can interwork with the Home Agent
Reliability protocol. Reliability protocol.
When VRRP is available, VRRP can replace the Hello message described When VRRP is available, VRRP can replace the Hello message described
in Section 6.1.3. However, some of information is missed by using in Section 5.1.3. However, some of information is missed by using
VRRP. After receiving a VRRP message, each home agent SHOULD process VRRP. After receiving a VRRP message, each home agent SHOULD process
the message and store the information as if it receives Home Agent the message and store the information as if it receives Home Agent
Hello messages Section 7.6.3. The Home Agents SHOULD still perform Hello messages Section 7.3.3. The Home Agents SHOULD still perform
binding cache synchronization as described in Section 7.7 and SHOULD binding cache synchronization as described in Section 7.4 and SHOULD
support the Home Agent Switch message as described in Section 7.9. support the Home Agent Switch message as described in Section 9.2.
In addition to this, VRRP is useful only if all home agents are In addition to this, VRRP is useful only if all home agents are
located on the same link. If the home agents are topologically located on the same link. If the home agents are topologically
separated, the Home Agent Reliability protocol MUST be used. separated, the Home Agent Reliability protocol MUST be used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 40 skipping to change at page 32, line 40
A home agent address is stored in this field. A home agent address is stored in this field.
Home Agent Lifetime, Sequence Number and Flags field are missing in Home Agent Lifetime, Sequence Number and Flags field are missing in
the VRRP packet format. Therefore, operators SHOULD use the same the VRRP packet format. Therefore, operators SHOULD use the same
statically configured value for Home Agent Lifetime. Each home agent statically configured value for Home Agent Lifetime. Each home agent
does not check freshness of received VRRP message because of no does not check freshness of received VRRP message because of no
sequence number. If VRRP is used, a home agent cannot determine the sequence number. If VRRP is used, a home agent cannot determine the
active home agent from the VRRP message due to lack of A flag, and active home agent from the VRRP message due to lack of A flag, and
cannot request a VRRP advertisement to other home agents. cannot request a VRRP advertisement to other home agents.
7.11. Retransmissions and Rate Limiting 7.7. Retransmissions and Rate Limiting
Standby and active home agents are responsible for retransmissions Standby and active home agents are responsible for retransmissions
and rate limiting of a State Synchronization Request, Switchover and rate limiting of a SS-REQ, SO-REQ, SB-REQ messages for which they
Request, SwitchBack Request messages for which they expect a expect a response. The home agent MUST determine a value for the
response. The home agent MUST determine a value for the initial initial transmission timer:
transmission timer:
o If the home agent sends a State Synchronization Request message, o If the home agent sends a SS-REQ message, it SHOULD use an initial
it SHOULD use an initial retransmission interval of retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.
INITIAL_STATE_SYNC_REQ_TIMER.
o If a standby home agent sends a Switchover Request message, it o If a standby home agent sends a SO-REQ message, it SHOULD use an
SHOULD use an initial retransmission interval of initial retransmission interval of INITIAL_SWICHOVER_REQ_TIMER.
INITIAL_SWICHOVER_REQ_TIMER.
o If an active home agent sends a SwitchBack Request message, it o If an active home agent sends a SB-REQ message, it SHOULD use an
SHOULD use an initial retransmission interval of initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER .
INITIAL_SWICHBACK_REQ_TIMER .
If the sending home agent fails to receive a valid matching response If the sending home agent fails to receive a valid matching response
within the selected initial retransmission interval, it SHOULD within the selected initial retransmission interval, it SHOULD
retransmit the message until a response is received. All of the retransmit the message until a response is received. All of the
above constants are specified in Section 10. above constants are specified in Section 11.
The retransmission MUST use an exponential backoff process as The retransmission MUST use an exponential backoff process as
described in [RFC-3775] until either the home agent receives a described in [RFC-3775] until either the home agent receives a
response, or the timeout period reaches the value response, or the timeout period reaches the value
MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a
separate back-off process for different message types and different separate back-off process for different message types and different
destinations. The rate limiting of Mobility Header messages is the destinations. The rate limiting of Mobility Header messages is the
same as one in [RFC-3775]. A home agent MUST NOT send Mobility same as one in [RFC-3775]. A home agent MUST NOT send Mobility
Header Messages to a particular home agent more than MAX_UPDATE_RATE Header Messages to a particular home agent more than MAX_UPDATE_RATE
(3) times a second, which is specified in [RFC-3775]. (3) times a second, which is specified in [RFC-3775].
8. Mobile Node Operation 8. Home Agent Virtual Switch
Operations described in this section are valid only for the Home 8.1. Consideration of Routing and Neighbor Discovery Protocol
Agent Hard Switch mode. When the Home Agent Virtual Switch is used,
all these operations can be skipped.
8.1. Home Agent Addresses Discovery 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.
To provide home agent reliability with the Home Agent Hard Switch When a standby home agent becomes active in the Home Agent Virtual
mode, a mobile node authenticates itself to two or more home agents Switch mode, it MUST start to advertise the home agent address and
and creates IPsec SAs with them during bootstrapping. When one home the home prefix of the home addresses serviced by the redundant home
agent fails, another home agent can use the pre-existing SA to notify agent set into the routing infrastructure. This operation is
the mobile node about the failure. 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 the route selection. When each home
agent participates in OSPF routing, each home agent should be
configured with the appropriate metric matched to the home agent
preference value. When the active home agent fails, 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 configuration errors, the routers
on the home link may not route packets to the desired standby home
agent. In order to change the OSPF cost correctly and dynamically,
The operator takes other existing approaches. For example, most of
router vendors have a private MIB to set the cost via SNMP, though
this is a vendor-specific function.
Multiple home agent addresses are available in a home network. In When an active home agent activates a home agent address, it SHOULD
order to discover these home agent addresses, two different use a virtual MAC address as introduced in [RFC-3768]. 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.
8.2. Home Agent Recovery
After detecting the active home agent has failed, the standby home
agent whose preference value is the highest MUST take over the failed
home agent. The standby home agent MUST activate the virtual home
agent address. If a virtual MAC address as introduced in [RFC-3768]
is used, the standby home agent MUST start using that 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.
9. Home Agent Hard Switch
9.1. Home Agent Recovery
After detecting the active home agent has failed, the standby home
agent whose preference value is the highest MUST take over the failed
home agent. The standby home agent MUST send a Home Agent Switch
message to all the mobile nodes that were registered at the failed
home agent as described in Section 9.2, using the pre-established
IPsec SA. The standby Home Agent MUST set its own address in the
Home Agent Address field in the Home Agent Switch message so that it
will receive the binding update from the mobile node as an
acknowledgment of the sent Home Agent Switch message. The home agent
switch-over is complete when it receives binding updates from all the
mobile nodes. It is important to remark that sending Home Agent
Switch messages to all the mobile nodes at once may bring non-
negligible overhead to the home agent.
This overhead cannot be avoided if the active home agent suddenly
stop serving mobile node because of unexpected reasons (crash,
network trouble, etc). However, if this switch over is operated
under the administrative operation (maintenance, etc), the previous
active home agent may continue serving the mobile nodes until the
switch over is completed. Until the mobile node sends a binding
update to the new active home agent, it still sends the packet to the
previous home agent in the Home Agent Hard Switch. Therefore, the
new active home agent can notify the completion of switch-over to the
previous active home agent by using Home Agent Control message as
described in Section 9.3. As soon as this message is received, the
previous active home agent can be shutdown or detached from the
network safely.
9.2. Sending Home Agent Switch Messages
The standby home agent which is going to be active MUST send a Home
Agent Switch message as defined in [RFC-5142] to all the mobile nodes
that were being served by the failed home agent. The Home Agent
Switch message must be securely sent to the mobile node by using
IPsec ESP. The standby home agent MUST include only its own home
agent address in the Home Agent Switch message. If there are a large
number of mobile nodes served by the failed home agent, the overhead
sending Home Agent Switch messages is high. Until a mobile node
receives this Home Agent Switch messages, the mobile node's
communication is discontinued. Therefore, until the standby home
agent completes sending the Home Agent Switch message to all the
mobile nodes and receives Binding Updates from all the mobile node,
the failed home agent SHOULD serve mobile nodes if possible. This is
the case when the active home agent is replaced by administrative
operation with the Home Agent Control messages as described in
Section 9.3.
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, as soon as the active home agent detects
the recovery of the failed home agent, 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 the
recovered home agent address in the Home Agent Addresses field. The
mobile node will re-key the SA, but it will not change the home agent
by this home agent switch message which I-flag is set.
9.3. Notification of Home Agent Switch Completion
If the new active home agent completes the switch-over as described
in Section 8.2, it SHOULD send a SW-COMP to the previous active home
agent in the Home Agent Hard Switch case. Until the previous home
agent receives this message, it SHOULD continue serving any mobile
nodes that are registered with it. Once the previous home agent
receives the SW-COMP message, it can stop home agent services.
9.4. Mobile Node Operation
9.4.1. Home Agent Addresses Discovery
In 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 the active home agent fails, another home
agent can use the pre-existing SA to notify the mobile node about the
failure by sending a Home Agent Switch message.
In order to discover multiple home agent addresses, two different
mechanisms are defined in the bootstrapping solution in the split mechanisms are defined in the bootstrapping solution in the split
scenario [RFC-5026]. One is DNS lookup by home agent Name, the other scenario [RFC-5026]. One is DNS lookup by home agent Name, the other
is DNS lookup by Service Name. DHCPv6 can also be used in the is DNS lookup by Service Name. DHCPv6 can also be used in the
integrated scenario [ID-BOOTINT] to provide home agent provisioning integrated scenario [ID-BOOTINT] to provide home agent provisioning
to mobile nodes. to mobile nodes.
In the split scenario, a mobile node can use DNS lookup by Service In the split scenario, a mobile node can use DNS lookup by Service
Name to discover the home agents, as defined in [RFC-5026]. For Name to discover the home agents, as defined in [RFC-5026]. For
example, if home agent reliability is required by a mobile node, DNS example, if home agent reliability is required by a mobile node, DNS
lookup by Service Name method is recommended for the mobile node to lookup by Service Name method is recommended for the mobile node to
skipping to change at page 40, line 46 skipping to change at page 37, line 15
agents list according to their preference value. Then the mobile agents list according to their preference value. Then the mobile
node should authenticate itself to these home agents via an IKEv2 node should authenticate itself to these home agents via an IKEv2
exchange. exchange.
In the integrated scenario, a mobile node can use DHCPv6 to get home In the integrated scenario, a mobile node can use DHCPv6 to get home
agent provisioning from an MSP or ASP, as already defined in [ID- agent provisioning from an MSP or ASP, as already defined in [ID-
BOOTINT]. The only requirement is that the DHCPv6 response must BOOTINT]. The only requirement is that the DHCPv6 response must
include multiple home agents' information in order to support home include multiple home agents' information in order to support home
agent reliability. agent reliability.
8.2. IKE/IPsec pre-establishment to Home Agents 9.4.2. IKE/IPsec pre-establishment to Home Agents
After a mobile node gets multiple home agent addresses, it needs to After a mobile node obtains multiple home agent addresses, it needs
trigger multiple IKE exchanges with the multiple home agents selected to trigger multiple IKE exchanges with the multiple home agents
from the home agent list. Since both IKEv1 and IKEv2 can be used to selected from the home agent list. Since both IKEv1 and IKEv2 can be
bootstrap Mobile IPv6, this solution does not introduce any new used to bootstrap Mobile IPv6, this solution does not introduce any
operations to co-operate with IKEv1 or IKEv2. It should initiate IKE new operations to co-operate with IKEv1 or IKEv2. It should initiate
for home agents as soon as home registration is complete. IKE for home agents as soon as home registration is complete.
The mobile node MUST follow the standard IKEv2 exchange in the The mobile node MUST follow the standard IKEv2 exchange in the
bootstrapping solution of the split scenario [RFC-5026]. Home bootstrapping solution of the split scenario [RFC-5026]. Home
Address configuration maybe also be included, if necessary, for the Address configuration maybe also be included, if necessary, for the
first IKE exchange. After its Home Address is assigned or approved first IKE exchange. After its Home Address is assigned or approved
by the first home agent, mobile node SHOULD register itself with the by the first home agent, mobile node SHOULD register itself with the
second home agent with IKE using the same Home Address. Therefore, second home agent with IKE using the same Home Address. Therefore,
no home address configuration should be used in the second IKEv2 no home address configuration should be used in the second IKEv2
procedure. Note that the mobile node only sends a Binding Update procedure. Note that the mobile node only sends a Binding Update
message to the first home agent. message to the first home agent.
8.3. Receiving Home Agent Switch message 9.4.3. Receiving Home Agent Switch message
A mobile node must follow the operation specified in [ID-HASWITCH] A mobile node must follow the operation specified in [RFC-5142] when
when it receives a Home Agent Switch message. it receives a Home Agent Switch message.
If the I-flag is set in the received Home Agent Switch message, the If the I-flag is set in the received Home Agent Switch message, the
mobile node MUST re-key the SA with the home agent addresses stored mobile node MUST re-key the SA with the home agent addresses stored
in the Home Agent Addresses field. The mobile node MUST NOT change in the Home Agent Addresses field. The mobile node MUST NOT change
its active home agent when the I-flag is set. If the home agent 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, address is not known from the bootstrapping described in
the mobile node MUST NOT start an IKE session with the unknown home Section 9.4.1, the mobile node MUST NOT start an IKE session with the
agent. Instead, it SHOULD re-start home agent discovery again to unknown home agent. Instead, it SHOULD re-start home agent discovery
update its home agent address information. again to update its home agent address information.
When the mobile node receives a Home Agent Switch message without 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 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 home agent, it MUST select the standby home agent in the switch
message as the active home agent and send a Binding Update message to message as the active home agent and send a new Binding Update
it. Note that the standby home agent address in the switch message message to it. Note that the standby home agent address in the Home
MUST be equal to the sender of the Home Agent Switch message. This Agent Switch MUST be equal to the sender of the Home Agent Switch
is because the standby Home agent expects the Binding Update as an message. The standby Home agent expects the Binding Update as an
acknowledgement of the Home Agent Switch message. The mobile node acknowledgment of the Home Agent Switch message. The mobile node
already has a pre-established SA with the home agent and should use already has a pre-established SA with the standby home agents and
that SA to send the Binding Update. If the address stored in the should use that SA to send the Binding Update. If the address stored
Home agent address field is different from the sender, the mobile in the Home agent address field is different from the sender, the
node MUST send a binding update to the sender. mobile node MUST send a binding update to the sender.
9. Security Considerations 10. Security Considerations
Since Mobile IPv6 operation requires ESP in transport mode between Since Mobile IPv6 operation requires ESP in transport mode between
the mobile node and the home agent, we will discuss the ESP field the mobile node and the home agent, we will discuss the ESP field
synchronization issues between the mobile node and the redundant set synchronization issues between the mobile node and the redundant set
of home agents. This synchronization is required only for Home Agent of home agents. This synchronization is required only for Home Agent
Virtual Switch mode. Most of fields should be synchronized based on Virtual Switch mode. Most of fields should be synchronized based on
RFC4301 [RFC-4301]. The ESP header has the following fields: [RFC-4301]. The ESP header has the following fields:
SPI SPI
This field identifies the SAD at the receiver. This field identifies the SAD at the receiver.
The mobile node negotiates only one IPsec SA. Hence, the SPI The mobile node negotiates only one IPsec SA. Hence, the SPI
value will remain unchanged upon home agent failover. 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.
The mobile node and the redundant home agent set will have the 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 this synchronization of the sequence number field is mandatory in this
mode of operation. mode of operation.
As described in Section 4, the SA1, SA2, SA3, SA4 could be The SA1, SA2, SA3, SA4 could be synchronized between the home
synchronized between the home agents as these messages are not agents as these messages are not sent continuously. Moreover for
sent continuously. Moreover for the Binding Update case, if the the Binding Update case, if the mobile node is in the middle of
mobile node is in the middle of sending a Binding Update to an sending a Binding Update to an active home agent for a binding
active home agent for a binding refresh, and the active home agent refresh, and the active home agent is not available at that
is not available at that moment, the mobile node will not get any moment, the mobile node will not get any response from the active
response from the active home agent. After a standby home agent home agent. After a standby home agent becomes active, the mobile
becomes active, the mobile node will retry and it will receive the node will retry and it will receive the Binding Update from the
Binding Update from the mobile node with a sequence number that is mobile node with a sequence number that is +n from its last known
+n from its last known sequence number for SA1. For the Binding sequence number for SA1. For the Binding Acknowledgment case
Acknowledgement case (SA2), the standby home agent SHOULD add a (SA2), the standby home agent SHOULD add a random number to the
random number to the last known sequence number over and above the last known sequence number over and above the replay window to
replay window to ensure that the packet passes the replay check at ensure that the packet passes the replay check at the mobile node.
the mobile node. The same applies to HoTi and HoT messages with The same applies to HoTi and HoT messages with SA3 and SA4. Note
SA3 and SA4. Note that this windowing of the sequence numbers for that this windowing of the sequence numbers for Mobile IPv6
Mobile IPv6 signaling is only needed to cover the corner cases signaling is only needed to cover the corner cases when Binding
when Binding Update or HoTi is in-flight and the active home agent Update or HoTi is in-flight and the active home agent fails.
fails.
The technique explained above should work for user data packets if The technique explained above should work for user data packets if
ESP is used to encrypt user data traffic as well. The actual ESP is used to encrypt user data traffic as well. The actual
switchover time and the routing infrastructure convergence time is switchover time and the routing infrastructure convergence time is
the only latency that the user may perceive. the only latency that the user may perceive.
Initialization Vector Initialization Vector
Since the Initialization Vector will be delivered in each exchange Since the Initialization Vector will be delivered in each exchange
between a mobile node and home agent, this field is not between a mobile node and home agent, this field is not
skipping to change at page 44, line 5 skipping to change at page 41, line 5
Others Others
Other fields should be synchronized based on RFC4301 [RFC-4301] Other fields should be synchronized based on RFC4301 [RFC-4301]
In the Home Agent Hard Switch mode, the standby home agent needs to In the Home Agent Hard Switch mode, the standby home agent needs to
send a Home Agent Switch message using IPsec encryption. Since the send a Home Agent Switch message using IPsec encryption. Since the
mobile node has pre-established an IPsec SA with both the active and mobile node has pre-established an IPsec SA with both the active and
standby home agents, the standby home agent can send the message to standby home agents, the standby home agent can send the message to
the mobile node with the pre-established IPsec SA. the mobile node with the pre-established IPsec SA.
10. Protocol Constants 11. Protocol Constants
INITIAL_STATE_SYNC_REQ_TIMER: 3sec INITIAL_STATE_SYNC_REQ_TIMER: 3sec
INITIAL_SWICHOVER_REQ_TIMER: 1sec INITIAL_SWICHOVER_REQ_TIMER: 1sec
INITIAL_SWICHBACK_REQ_TIMER 1sec INITIAL_SWICHBACK_REQ_TIMER 1sec
LINK_TRAVERSAL_TIME 150msec LINK_TRAVERSAL_TIME 150msec
11. IANA Considerations 12. IANA Considerations
o The values for following mobility header message MUST be assigned o The values for following mobility header message MUST be assigned
by IANA. by IANA.
* State Synchronization Message * State Synchronization Message
* Home Agent Control Message * Home Agent Control Message
* Home Agent Hello Message * Home Agent Hello Message
* Home Agent Switch Message * Home Agent Switch Message
o The Type values for the State Synchronization Message
* 0: Request
* 1: Reply
* 2: Reply-Ack
o The Type values for the Home Agent Control Message
* 0: SwitchOver Request
* 1: SwitchOver Reply
* 2: SwitchBack Request
* 3: SwitchBack Reply
o The Status values for the Home Agent Control Message
* 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
o The values for following mobility options MUST be assigned by o The values for following mobility options MUST be assigned by
IANA. IANA.
1. Binding Cache Information Option 1. Binding Cache Information Option
2. AAA Information Option 2. AAA Information Option
o New Option Code for the IP address option defined in [RFC-4068] o New Option Code for the IP address option defined in [RFC-5268]
12. Contributors 13. Additional Authors
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 that Agent Reliability Design Team. The members of the design team that
are listed below are authors that have contributed to this document: are listed below are authors that have contributed to this document:
Samita Chakrabarti Samita Chakrabarti
samita.chakrabarti@azairenet.com samita.chakrabarti@azairenet.com
Kuntal Chowdhury Kuntal Chowdhury
skipping to change at page 47, line 43 skipping to change at page 43, line 43
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
13. Acknowledgements 14. Acknowledgements
This document includes a lot of text from [ID-LOCALHAHA] and [ID- This document includes a lot of text from [ID-LOCALHAHA] and [ID-
HAHA]. Therefore the authors of these two documents are HAHA]. Therefore the authors of these two documents are
acknowledged. We would also like to thank the authors of the home acknowledged. We would also like to thank the authors of the home
agent reliability problem statement [ID-PS-HARELIABILITY] for agent reliability problem statement [ID-PS-HARELIABILITY] for
describing the problem succinctly and Alice Qin for her work on the describing the problem succinctly and Alice Qin for her work on the
hello protocol. hello protocol.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
Standby Router Protocol (HSRP)", RFC 2281, March 1998. IPv6", RFC 3775, June 2004.
[RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC
5094, October 2007.
[RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message",
RFC-5142, November 2007.
[RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
scenario", RFC 5026, October 2007.
[ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via
DHCPv6 for the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress),
April 2008.
15.2. Informative References
[RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004. RFC 3768, April 2004.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
IPv6", RFC 3775, June 2004. Standby Router Protocol (HSRP)", RFC 2281, March 1998.
[RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC 3776, June 2004. RFC 3776, June 2004.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[ID-VSM] Devarapalli, V., "Mobile IPv6 Vendor Specific Option",
draft-ietf-mip6-vsm-03 (work in progress), October 2007.
14.2. Informative References
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[ID-HASWITCH] Haley, B., "Mobility Header Home Agent Switch Message", [RFC-5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June
draft-ietf-mip6-ha-switch-05 (work in progress), November 2007. 2008.
[RFC-4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
scenario", RFC 5026, October 2007.
[ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via
DHCPv6 for the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress),
June 2007.
[ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006.
[ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006.
[ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent
Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired),
February 2004. February 2004.
Appendix A. Change Log From Previous Versions Appendix A. Change Log From Previous Versions
Changes from draft-ietf-mip6-hareliability-02 Changes from draft-ietf-mip6-hareliability-03
o comment (see mail at 2007 June 20) from Wesley Eddy, Verizon
Federal Network Systems
o Support Mobile Node Identifier option (See Section 6.1.1)
o Change the usage of HA switch message: the standby HA MUST use its
address in the Home Agent Address field in the HA switch message.
Otherwise, the standby HA cannot receive the acknowledgement (i.e.
BU) of the HA switch message. (See Section 8.3)
o Defining a wildcard option for the State Sync Request message A
new boot up HA can retrieve all the active mobile nodes' state at
once. (see section 7.7.1)
o Defining a new type (Reply-ack) in State Sync Reply message (see
section 7.7.3). This is optional message.
o Defining a new type (SwitchCompletion) in HA Control message. For
the impact of HA switch in the HA hard switch scenario (see
section 7.8.3). This is optional.
o Adding IANA Consideration Section. (See Section 11) o Only Editorial Update and No Technical Change
Author's Address Author's Address
Ryuji Wakikawa (Editor) Ryuji Wakikawa
Faculty of Environment and Information Studies, Keio University Toyota ITC
Keio University, 5322 Endo 6-6-20 Akasaka, Minato-ku
Fujisawa, Kanagawa 252-8520 Tokyo 107-0052
Japan Japan
Phone: +81-466-49-1100 Phone: +81-3-5561-8276
Fax: +81-466-49-1395 Fax: +81-3-5561-8292
Email: ryuji@sfc.wide.ad.jp Email: ryuji@jp.toyota-itc.com
URI: http://www.wakikawa.org/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 228 change blocks. 
1052 lines changed or deleted 899 lines changed or added

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