draft-ietf-mip6-hareliability-02.txt   draft-ietf-mip6-hareliability-03.txt 
MIP6 Working Group R. Wakikawa (Editor) MIP6 Working Group R. Wakikawa (Editor)
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track July 17, 2007 Intended status: Standards Track November 19, 2007
Expires: January 18, 2008 Expires: May 22, 2008
Home Agent Reliability Protocol Home Agent Reliability Protocol
draft-ietf-mip6-hareliability-02.txt draft-ietf-mip6-hareliability-03.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 January 18, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The home agent can be a single point of failure when Mobile IPv6 is The home agent can be a single point of failure when Mobile IPv6 is
used in a system. It is critical to provide home agent reliability used in a system. It is critical to provide home agent reliability
in the event of a home agent crashing or becoming unavailable. This in the event of a home agent crashing or becoming unavailable. This
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3. Problem Statement and Requirements . . . . . . . . . . . . . . 6 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6
4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Home Agent Network Configuration . . . . . . . . . . . . . 10 5.1. Home Agent Network Configuration . . . . . . . . . . . . . 10
5.2. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 11 5.2. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 11
5.3. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12 5.3. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12
5.4. Active Home Agent Management . . . . . . . . . . . . . . . 13 5.4. Active Home Agent Management . . . . . . . . . . . . . . . 13
6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 14 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 15
6.1.1. State Synchronization Message . . . . . . . . . . . . 14 6.1.1. State Synchronization Message . . . . . . . . . . . . 15
6.1.2. Home Agent Control Message . . . . . . . . . . . . . . 16 6.1.2. Home Agent Control Message . . . . . . . . . . . . . . 17
6.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 18 6.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 19
6.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 20 6.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 21
6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 20 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 22
6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 20 6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 22
6.2.2. Binding Cache Information Option . . . . . . . . . . . 21 6.2.2. Binding Cache Information Option . . . . . . . . . . . 22
6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 22 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 24
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 23 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 25
7.1. Home Agent Address Configuration . . . . . . . . . . . . . 23 7.1. Home Agent Address Configuration . . . . . . . . . . . . . 25
7.2. Consideration of Routing and Neighbor Discovery 7.2. Consideration of Routing and Neighbor Discovery
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Home Agent List Management . . . . . . . . . . . . . . . . 24 7.3. Home Agent List Management . . . . . . . . . . . . . . . . 26
7.4. Detecting Home Agent Failure . . . . . . . . . . . . . . . 25 7.4. Detecting Home Agent Failure . . . . . . . . . . . . . . . 27
7.5. Home Agent Switch Over . . . . . . . . . . . . . . . . . . 26 7.5. Home Agent Switch Over . . . . . . . . . . . . . . . . . . 28
7.6. Processing Hello Messages . . . . . . . . . . . . . . . . 27 7.6. Processing Hello Messages . . . . . . . . . . . . . . . . 29
7.6.1. Requesting Hello Message . . . . . . . . . . . . . . . 27 7.6.1. Requesting Hello Message . . . . . . . . . . . . . . . 29
7.6.2. Sending Hello Message . . . . . . . . . . . . . . . . 27 7.6.2. Sending Hello Message . . . . . . . . . . . . . . . . 30
7.6.3. Receiving Hello Message . . . . . . . . . . . . . . . 28 7.6.3. Receiving Hello Message . . . . . . . . . . . . . . . 30
7.7. Processing State Synchronization Messages . . . . . . . . 29 7.7. Processing State Synchronization Messages . . . . . . . . 31
7.7.1. Soliciting State of a Particular Mobile Node or 7.7.1. Soliciting State of a Particular Mobile Node or
Subset of Mobile Nodes . . . . . . . . . . . . . . . . 29 Subset of Mobile Nodes . . . . . . . . . . . . . . . . 31
7.7.2. Synchronizing State of Mobile Nodes . . . . . . . . . 30 7.7.2. Synchronizing State of Mobile Nodes . . . . . . . . . 32
7.8. Processing Home Agent Control Messages . . . . . . . . . . 31 7.7.3. Explicit Acknowledgement of the State
7.8.1. Standby Home Agent becomes an Active Home Agent . . . 31 Synchronization Reply message . . . . . . . . . . . . 34
7.8.2. Active Home Agent becomes in-active . . . . . . . . . 32 7.8. Processing Home Agent Control Messages . . . . . . . . . . 34
7.9. Sending Home Agent Switch Messages . . . . . . . . . . . . 32 7.8.1. Standby Home Agent becomes an Active Home Agent . . . 34
7.10. Interworking with VRRP . . . . . . . . . . . . . . . . . . 33 7.8.2. Active Home Agent becomes in-active . . . . . . . . . 35
7.11. Retransmissions and Rate Limiting . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 36 8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 40
8.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 36 8.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 40
8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 36 8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 40
8.3. Receiving Home Agent Switch message . . . . . . . . . . . 37 8.3. Receiving Home Agent Switch message . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 44
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Change Log From Previous Versions . . . . . . . . . . 44 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.2. Informative References . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 Appendix A. Change Log From Previous Versions . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51
1. Introduction 1. Introduction
In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a In Mobile IPv6 [RFC-3775] and NEMO Basic Support[RFC-3963], mobile
bi-directional tunnel with their home agents for all traffic with nodes may use a bi-directional tunnel with their home agents for all
correspondent nodes. A home agent on the home link maintains a traffic with correspondent nodes. A home agent on the home link
binding cache entry for each mobile node and uses the binding cache maintains a binding cache entry for each mobile node and uses the
entry to route any traffic meant for the mobile node or the mobile binding cache entry to route any traffic meant for the mobile node or
network. If the mobile node is not on the home link and does not the mobile network. If the mobile node is not on the home link and
have a binding cache entry at the home agent, it is neither reachable does not have a binding cache entry at the home agent, it is neither
at its home address nor able to setup new sessions with its home reachable at its home address nor able to setup new sessions with its
address. If a home agent loses the binding cache state, due to 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 failure or some other reason, it results in a loss of service for the
mobile nodes. 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3]. document are to be interpreted as described in [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
[1] and a mobile router [2]. [RFC-3775] and a mobile router [RFC-3963].
Some of the mobility related terms used in this document are defined Some of the mobility related terms used in this document are defined
in [1] and [10]. In addition or in replacement of these, the in [RFC-3775] and [RFC-3753]. In addition or in replacement of
following terms are defined or redefined: these, the 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.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
Discovery (DHAAD) in RFC3775. This protocol uses this preference Discovery (DHAAD) in RFC3775. This protocol uses this preference
value for home agent selection when an active home agent has value for home agent selection when an active home agent has
failed. However, an operator can also define an independent value failed. However, an operator can also define an independent value
used only for the home agent reliability protocol if the operator used only for the home agent reliability protocol if the operator
wants to have different preference values for DHAAD and the home wants to have different preference values for DHAAD and the home
agent reliability protocol. A home agent SHOULD NOT use the same agent reliability protocol. A home agent SHOULD NOT use the same
preference value as other home agents for this protocol. preference value as other home agents for this protocol.
3. Problem Statement and Requirements 3. Problem Statement and Requirements
In Mobile IPv6 [1], a mobile node registers and establishes a binding In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a
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 may be responsible for multiple mobile nodes on the home link.
The failure of the home agent may then result in the loss of The failure of the home agent may then result in the loss of
connectivity for numerous mobile nodes located throughout the connectivity for numerous mobile nodes located throughout the
Internet. To overcome this problem, Mobile IPv6 allows deployment of Internet. To overcome this problem, Mobile IPv6 allows deployment of
multiple home agents on the home link so that upon the failure of a multiple home agents on the home link so that upon the failure of a
home agent, a mobile node can re-establish its connection through a home agent, a mobile node can re-establish its connection through a
new home agent. However, the base Mobile IPv6 specification does not new home agent. However, the base Mobile IPv6 specification does not
address home agent failover and dynamic transfer of service from one address home agent failover and dynamic transfer of service from one
home agent to another. This transfer of service from the failed home home agent to another. This transfer of service from the failed home
skipping to change at page 6, line 34 skipping to change at page 6, line 34
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
should not take longer than the care-of-addresses update procedure should not take longer than the care-of-addresses update procedure
described in Mobile IPv6 [1]. described in Mobile IPv6 [RFC-3775].
Availability of a redundant home agent set Availability of a redundant home agent set
Availability of an active home agent address and a standby home Availability of an active home agent address and a standby home
agent address at the bootstrapping period for the mobile node is agent address at the bootstrapping period for the mobile node is
assumed. assumed.
State Synchronization State Synchronization
The information for mobile nodes must be able to be synchronized The information for mobile nodes must be able to be synchronized
between an active home agent and standby home agents. This between an active home agent and standby home agents. This
includes the Binding Cache, AAA information, other Mobile IPv6 and includes the Binding Cache, AAA information, other Mobile IPv6 and
NEMO related information. NEMO related information. Note that the Home Agent Reliability
protocol exchanges only running states of mobile nodes.
Therefore, we do not have any specific operation for synchronizing
the configuration information. For instance, when Mobile IPv6 is
operated with Authentication protocol, the synchronizing the
configurations of the Authentication protocol is out of scope in
this document. Operators MAY correctly configure in multiple home
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 9.
Secured Message Exchanges Secured Message Exchanges
The messages used between the home agents to transfer binding The messages used between the home agents to transfer binding
cache information MAY be authenticated and encrypted. cache information MAY be authenticated and encrypted.
Failure Detection Failure Detection
skipping to change at page 7, line 17 skipping to change at page 7, line 22
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
failure detection mechanism such as VRRP[4] or HSRP[5], it can re- failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC-
use that mechanism to detect the home agent failure. On the other 2281], it can re-use that mechanism to detect the home agent
hand, periodic Hello messages are introduced to detect active home failure. On the other hand, periodic Hello messages are
agent's service availability in this document. introduced to detect active home agent's service availability in
this document.
Failure Notification Failure Notification
If necessary, a mobile node is notified about the active home 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 Design
Mobile IPv6 depends on IPsec and IKE for home binding registration as Mobile IPv6 depends on IPsec and IKE for home binding registration as
described in [6]. A mobile node must encrypt a Binding Update sent described in [RFC-3776]. A mobile node must encrypt a Binding Update
to a home agent. In addition, the mobile node exchanges HoTI and HoT sent to a home agent. In addition, the mobile node exchanges HoTI
messages through the home agent by using IPsec tunnel mode. and HoT messages through the home agent by using IPsec tunnel mode.
Therefore, before home agent failure, these IPsec states should be Therefore, before home agent failure, these IPsec states should be
synchronized among home agents of a redundant home agent set. A synchronized among home agents of a redundant home agent set. A
mobile node may also encrypt particular data traffic sent to nodes in mobile node may also encrypt particular data traffic sent to nodes in
the Internet. IPsec information required by Mobile IPv6 is listed the Internet. IPsec information required by Mobile IPv6 is listed
below. below.
o Security Policy Database (SPD) and Selector Information o Security Policy Database (SPD) and Selector Information
o Security Association (SA) for Binding Registration (SA1 and SA2) o Security Association (SA) for Binding Registration (SA1 and SA2)
skipping to change at page 9, line 14 skipping to change at page 9, line 14
Home Agent Hard Switch Home Agent Hard Switch
The home agents are addressed by different IP addresses and the The home agents are addressed by different IP addresses and the
mobile node is aware of the change of home agent. A Mobile node mobile node is aware of the change of home agent. A Mobile node
and all home agents in a redundant home agent set negotiate and all home agents in a redundant home agent set negotiate
independent IPsec SAs. This mode is especially useful when the independent IPsec SAs. This mode is especially useful when the
IPsec/IKE states cannot be synchronized. However, the home agent IPsec/IKE states cannot be synchronized. However, the home agent
change is not transparent to the mobile node. When an active home change is not transparent to the mobile node. When an active home
agent fails, a mobile node will receive a notification (a Home agent fails, a mobile node will receive a notification (a Home
Agent Switch message [11]) from a standby home agent, and send a Agent Switch message [ID-HASWITCH]) from a standby home agent, and
Binding Update to the standby home agent. In order to exchange send a Binding Update to the standby home agent. In order to
the Home Agent Switch message securely between the standby home exchange the Home Agent Switch message securely between the
agent and a mobile node, the mobile node needs to establish an standby home agent and a mobile node, the mobile node needs to
IPsec SA with both the active and the standby home agents in the establish an IPsec SA with both the active and the standby home
redundant home agent set beforehand. agents in the redundant home agent set beforehand.
Since each home agent has a different address, an active home Since each home agent has a different address, an active home
agent can be defined for each mobile node. When a mobile node agent can be defined for each mobile node. When a mobile node
boots, it will discover home agents and create IPsec SAs with boots, it will discover home agents and create IPsec SAs with
them. It will then decide which one of the home agents is its 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 active home agent. For example, when two home agents serve a home
network, half of the mobile nodes might register with one home network, half of the mobile nodes might register with one home
agent and the rest of mobile nodes with another home agent. When agent and the rest of mobile nodes with another home agent. When
one of the home agents fails, a standby home agent, whose one of the home agents fails, a standby home agent, whose
preference value is next highest than the failed home agent, can preference value is next highest than the failed home agent, can
skipping to change at page 13, line 20 skipping to change at page 13, line 20
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 5.4. Active 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)
(standby) (active) | | HA2 BECOMES ACTIVE HA (standby) (active) | | HA2 BECOMES ACTIVE HA
| | | | | | | |
SYSTEM MAINTENANCE, ETC. SYSTEM MAINTENANCE, ETC.
| | | | | | | |
|------->| | | 3. HA1 sends SwitchOver Request |------->| | | 4. HA1 sends SwitchOver Request
|<-------| | | 4. HA2 sends SwitchOver Reply |<-------| | | 5. HA2 sends SwitchOver Reply
| | | | | | | |
(active) (standby) | | 5. HA1 returns to active HA |------->| | | 6. HA1 sends SwitchCompl (optional)
(active) (standby) | | 7. HA1 returns to active HA
| | | | HA1 BECOMES ACTIVE AGAIN | | | | HA1 BECOMES ACTIVE AGAIN
Figure 5: Manual Home Agent Change Figure 5: 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 5, 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.
As shown in Section 5.3, it takes certain time to complete the home
agent switch. Thus, the old active home agent continue serving the
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
SwitchCompl message to the previous active home agent. This is
optional operation in this specification.
6. Messages 6. Messages
6.1. New Mobility Header Messages 6.1. New Mobility Header Messages
6.1.1. State Synchronization Message 6.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. It MUST be unicasted and MUST be authenticated by IPsec mobile node(s). It MUST be unicasted and MUST be authenticated by
ESP. The State Synchronization message has the MH Type value TBD. IPsec ESP. The State Synchronization message has the MH Type value
When this value is indicated in the MH Type field, the format of the TBD. When this value is indicated in the MH Type field, the format
Message Data field in the Mobility Header is as follows: 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 | Reserved | | Type |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | | Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Mobility Options . . Mobility Options .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: State Synchronization Message Figure 6: State Synchronization Message
skipping to change at page 15, line 7 skipping to change at page 16, line 7
1: Reply 1: Reply
The message is called State Synchronization Reply and is used The message is called State Synchronization Reply and is used
between the home agents in the redundant home agent set to between the home agents in the redundant home agent set to
exchange binding cache information and any other information 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. The
State Synchronization Reply can be sent by an active home agent State Synchronization Reply can be sent by an active home agent
either periodically or in response to a State Synchronization either periodically or in response to a State Synchronization
Request. Request.
2: Reply-Ack (optional)
The message is called State Synchronization Reply-Ack and is
used to acknowledge to the State Synchronization Reply message.
This message is optional and is used when the link between two
home agents is not reliable.
Ack flag
This flag is valid only for State Synchronization Reply message.
If the sender requires explicit acknowledgment (i.e. State
Synchronization Reply-Ack), it MUST set this flag.
Reserved Reserved
8-bit unsigned integer. 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
messages. 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 [1]. The receiver and format of defined options are described in [RFC-3775]. The
MUST ignore and skip any options which it does not understand. receiver MUST ignore and skip any options which it does not
understand.
One of the following options is mandatory in State Synchronization One of the following options is mandatory in State Synchronization
Request message. : Request message. Multiple same options can be stored in the same
request message, (ex. two IP address options for two mobile
nodes):
* IP Address Option (Sub-type: Home Address)[12]. If a home * IP Address Option (Sub-type: Home Address) defined in [RFC-
agent wants the Binding Cache information for a particular 4068]. If a home agent wants the Binding Cache information for
mobile node, it includes an IPv6 Address Option. a particular mobile node, it includes the mobile node's home
address in an IPv6 Address Option. If a home agent want to
solicit all the active mobile nodes' states, it can include the
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 [2]. 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 [7]. defined in [ID-VSM].
One of the following options is mandatory in State Synchronization One of the following options is mandatory in State Synchronization
Reply. : Reply. :
* Binding Cache Information Option * Binding Cache Information Option
* AAA Information Option * AAA Information Option
* Vendor Specific Mobility Option * Vendor Specific Mobility Option
skipping to change at page 17, line 8 skipping to change at page 18, line 26
1: SwitchOver Reply 1: SwitchOver Reply
This message is called SwitchOver Reply. It is used to This message is called SwitchOver Reply. It is used to
acknowledge the receipt of the corresponding SwitchOver acknowledge the receipt of the corresponding SwitchOver
Request. Request.
2: SwitchBack Request 2: SwitchBack Request
This message is called SwitchBack Request. It is unicasted by This message is called SwitchBack Request. It is unicasted by
an active home agent that desires to become the a standby home an active home agent that desires to become a standby home
agent. The receiver of this message SHOULD transition to agent. The receiver of this message SHOULD transition to
active state as soon as the message is received and validated active state as soon as the message is received and validated
successfully. successfully.
3: SwitchBack Reply 3: SwitchBack Reply
This message is called SwitchBack Reply. It is used to This message is called SwitchBack Reply. It is used to
acknowledge the receipt of the corresponding SwitchBack acknowledge the receipt of the corresponding SwitchBack
Request. Request.
4: Switch Complete
This message is used to indicate the completion of switch over,
(i.e. sending home agent switch messages and receiving binding
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 Switchover
Request or SwitchBack Request message. This field is only valid Request or SwitchBack Request message. This field is only valid
in SwitchOver Reply and SwitchBack Reply messages. The following in SwitchOver Reply and SwitchBack Reply messages. The following
Status values are defined: Status values are defined:
0: Success 0: Success
128: Reason unspecified 128: Reason unspecified
skipping to change at page 17, line 45 skipping to change at page 19, line 24
131: Not standby home agent (The receiver of the SwitchBack 131: Not standby home agent (The receiver of the SwitchBack
Request is already the active home agent) Request is already the active home agent)
132: Not in same redundant home agent set 132: Not in same redundant home agent set
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [1]. The receiver and format of defined options are described in [RFC-3775]. The
MUST ignore and skip any options which it does not understand. No receiver MUST ignore and skip any options which it does not
options are defined in this specification understand. No options are defined in this specification
If no options are present in this message, no padding is necessary If no options are present in this message, no padding is necessary
and the Header Len field will be set to 1. and the Header Len field will be set to 1.
6.1.3. Home Agent Hello Message 6.1.3. Home Agent Hello Message
This messages can be replaced by other protocols as described in This messages can be replaced by other protocols as described in
Section 7.10. If this message is used, it MUST be either unicasted Section 7.10. If this message is used, it MUST be either unicasted
or multicasted to carry home agent information among the redundant or multicasted to carry home agent information among the redundant
home agent set. The Hello message is defined for two purpose: 1) an home agent set. The Hello message is defined for two purpose: 1) an
skipping to change at page 18, line 50 skipping to change at page 20, line 34
16-bit unsigned integer. The Sequence number of the Hello message 16-bit unsigned integer. The Sequence number of the Hello message
can be used to verify whether this Hello message is the latest one can be used to verify whether this Hello message is the latest one
or not. or not.
Home Agent Preference Home Agent Preference
16-bit unsigned integer. The preference for the home agent 16-bit unsigned integer. The preference for the home agent
sending this Hello message. This preference is the same as the sending this 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 [1]. 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 this 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
[1]. [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 If this flag is set, the sender of this Hello message is an active
home agent. Otherwise, the sender is standby home agent home agent. Otherwise, the sender is a standby home agent.
R flag R flag
If this flag is set, the receiver of this Hello message must send If this flag is set, the receiver of this Hello message must send
back a Hello message to the sender. back a Hello message to the sender.
Reserved Reserved
6-bit unsigned integer. 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 Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [1]. The receiver and format of defined options are described in [RFC-3775]. The
MUST ignore and skip any options which it does not understand. No receiver MUST ignore and skip any options which it does not
valid options are defined in this specification. understand. No valid options are defined in this specification.
If no options are present in this message, 0 octets of padding are If no options are present in this message, 0 octets of padding are
necessary and the Header Len field will be set to 2. necessary and the Header Len field will be set to 2.
6.1.4. Home Agent Switch Message 6.1.4. Home Agent Switch Message
This message is defined in Section 8.3. The Home Agent Reliability This message is defined in Section 8.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
skipping to change at page 20, line 32 skipping to change at page 22, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Home Agent Switch Message Figure 9: 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 rekey (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. mobile node. When this flag is set, the mobile node does not
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 6.2. New Mobility Options
6.2.1. IP address Option 6.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 [12]. This document introduces new Sub-Type (FMIP) specification [RFC-4068]. This document introduces new Sub-
values for home agent address and Home Address. Type values for home agent address and Home Address.
Option-Code Option-Code
* 4: Home Agent Address * 4: Home Address
* 5: Home Address
6.2.2. Binding Cache Information Option 6.2.2. Binding Cache Information Option
The binding cache information option has an alignment requirement of The binding cache information option has an alignment requirement of
8n+2. Its format is as follows: 8n+2. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 40 | | Type = TBD | Length = 40 |
skipping to change at page 22, line 26 skipping to change at page 24, line 22
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 11: Vendor Specific Inforamtion Option
Type Type
8-bit Type value. The value is TBD. 8-bit Type value. The value is TBD.
Length Length
skipping to change at page 24, line 17 skipping to change at page 26, line 17
value. If this cost conflicts with the home agent preference value value. If this cost conflicts with the home agent preference value
due to misconfiguration, the routers on the home link may not route due to misconfiguration, the routers on the home link may not route
packets to the desired standby home agent. Therefore, the home agent packets to the desired standby home agent. Therefore, the home agent
MAY dynamically change the OSPF cost based on 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 preference value. Most of router vendors have a private MIB to set
the cost via SNMP, though this is a vendor-specific function. The the cost via SNMP, though this is a vendor-specific function. The
operator can consider other existing approaches to update routes on operator can consider other existing approaches to update routes on
the routers at the home link. the routers at the home link.
When an active home agent activates a home agent address, it SHOULD When an active home agent activates a home agent address, it SHOULD
use a virtual MAC address as introduced in [4]. When the active home use a virtual MAC address as introduced in [RFC-3768]. When the
agent is changed, the neighbor cache of the active home agent is not active home agent is changed, the neighbor cache of the active home
necessarily updated on mobile nodes located on the home link. agent is not necessarily updated on mobile nodes located on the home
Otherwise, the new home agent MUST update the neighbor cache entry link. Otherwise, the new home agent MUST update the neighbor cache
for the home agent address on all the mobile nodes located on the entry for the home agent address on all the mobile nodes located on
home link. In addition, Mobile IPv6 uses proxy NDP to intercept the home link. In addition, Mobile IPv6 uses proxy NDP to intercept
packets meant for mobile nodes which are away from the home link. packets meant for mobile nodes which are away from the home link.
However, it is unnecessary for the new active home agent to overwrite However, it is unnecessary for the new active home agent to overwrite
the existing proxy neighbor entries of the mobile nodes. the existing proxy neighbor entries of the mobile nodes.
7.3. Home Agent List Management 7.3. Home Agent List Management
In Mobile IPv6 [1], each home agent periodically sends router In Mobile IPv6 [RFC-3775], each home agent periodically sends router
advertisements with a Home Address Information option [1] for advertisements with a Home Address Information option [RFC-3775] for
exchanging home agent information when there are multiple home agents exchanging home agent information when there are multiple home agents
present on a link. This information is managed in a home agent list present on a link. This information is managed in a home agent list
introduced in [1]. When the Home Agent Reliability Protocol is used, introduced in [RFC-3775]. When the Home Agent Reliability Protocol
Hello messages are used to update the home agent list. There are is used, Hello messages are used to update the home agent list.
several reasons to use Hello message instead of Router Advertisement There are several reasons to use Hello message instead of Router
on the Home Agent Reliability protocol: Advertisement on the Home Agent Reliability protocol:
1. Router Advertisements are sent among home agents and also to 1. Router Advertisements are sent among home agents and also to
mobile nodes. When the Home Agent Virtual Switch is used, mobile nodes. When the Home Agent Virtual Switch mode is used,
standby home agents MUST NOT generate unsolicited Router standby home agents MUST NOT generate unsolicited Router
Advertisements. The standby home agents MUST be transparent to Advertisements. The standby home agents MUST be transparent to
all mobile nodes. Hello messages are exchanged only with other all mobile nodes. Hello messages are exchanged only with other
home agents. home agents.
2. Router Solicitation and Advertisement messages [8] cannot be used 2. Router Solicitation and Advertisement messages [RFC-2461] cannot
due to link-local limitations. However, as shown in Section 5.1, be used due to link-local limitations. However, as shown in
standby home agents are not always configured on the same link. Section 5.1, standby home agents are not always configured on the
Router Advertisements cannot be used in this case. same link. Router Advertisements cannot be used in this case.
3. The Home Agent Reliability protocol is required to exchange 3. The Home Agent Reliability protocol is required to exchange
additional information such as Group ID and Active/Standby Status additional information such as Group ID and Active/Standby Status
of the home agents. of the home agents.
When Hello messages are used, the Home Agent Information Option [1] When Hello messages are used, the Home Agent Information Option [RFC-
MAY NOT be used in Router Advertisements on the home link, because 3775] MAY NOT be used in Router Advertisements on the home link,
all necessary information will be present in the Hello messages. because all necessary information will be present in the Hello
However, mobile nodes located on the home link require this messages. However, mobile nodes located on the home link require
information for home agent discovery. In addition, if operators want this information for home agent discovery. In addition, if operators
to use different parameters such as Preference value for home agents want to use different parameters such as Preference value for home
and mobile nodes, they can utilize both Router Advertisements and agents and mobile nodes, they can utilize both Router Advertisements
Hello messages. Router Advertisements are used to carry the home and Hello messages. Router Advertisements are used to carry the home
agent information for mobile nodes, and Hello message are used to agent information for mobile nodes, and Hello message are used to
carry information for Home Agent Reliability operation. If an carry information for Home Agent Reliability operation. If an
operator decides not to use the Hello messages, Router Advertisements operator decides not to use the Hello messages, Router Advertisements
MUST be used to update the home agent list. MUST be used to update the home agent list.
Since Hello messages carry all the necessary information filled-in Since Hello messages carry all the necessary information filled-in
from the home agent list, the management of the home agent list is from the home agent list, the management of the home agent list is
unchanged. If a standby home agent removes an active home agent from unchanged. If a standby home agent removes an active home agent from
the list because its lifetime has become zero, it can start recovery the list because its lifetime has become zero, it can start recovery
according to this document. Section 7.4 describes failure detection according to this document. Section 7.4 describes failure detection
in detail. in detail.
7.4. Detecting Home Agent Failure 7.4. Detecting Home Agent Failure
The active and standby home agents can monitor each other's status in The active and standby home agents can monitor each other's status in
multiple ways. One method is to reuse other failure detection multiple ways. One method is to reuse other failure detection
mechanisms such as VRRP[4] and HSRP[5] described in Section 7.10. mechanisms such as VRRP[RFC-3768] and HSRP [RFC-2281] described in
This document also defines its own method by using periodic exchanges Section 7.10. This document also defines its own method by using
of Hello messages to monitor status. The reasons to specify Hello periodic exchanges of Hello messages to monitor status. The reasons
messages are: to specify Hello messages are:
1. Hello messages can be sent off-link for global recovery is 1. Hello messages can be sent off-link for global recovery is
required by an operator. Router Advertisements cannot be used in required by an operator. Router Advertisements cannot be used in
this scenario since their scope is link-local. Thus, Hello this scenario since their scope is link-local. Thus, Hello
messages are necessary to exchange home agent information among messages are necessary to exchange home agent information among
home agents in a globally redundant home agent set. home agents in a globally redundant home agent set.
2. If Router Advertisements and VRRP are used for periodic messages, 2. If Router Advertisements and VRRP are used for periodic messages,
they may not detect the case where the system is running but the they may not detect the case where the system is running but the
Mobile IPv6 stack is not operational. Mobile IPv6 may be Mobile IPv6 stack is not operational. Mobile IPv6 may be
skipping to change at page 26, line 42 skipping to change at page 28, line 42
Routing Peer/Link Failure Routing Peer/Link Failure
In some cases, an operator may require the home agent to detect a In some cases, an operator may require the home agent to detect a
next-hop routing peer failure. If the next-hop routing peer next-hop routing peer failure. If the next-hop routing peer
fails, the operator may want the home agent to initiate a switch- fails, the operator may want the home agent to initiate a switch-
over procedure if the failure is fatal in nature, or due to some over procedure if the failure is fatal in nature, or due to some
other routing policies. other routing policies.
7.5. Home Agent Switch Over 7.5. Home Agent Switch Over
After detecting the active home agent has failed, a standby home After detecting the active home agent has failed, the standby home
agent whose preference value is the highest MUST take over for the agent whose preference value is the highest MUST take over for the
failed home agent. 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 In the Home Agent Virtual Switch mode, the standby home agent MUST
activate the virtual home agent address. If a virtual MAC address as activate the virtual home agent address. If a virtual MAC address as
introduced in [4] is used, the standby home agent MUST start using introduced in [RFC-3768] is used, the standby home agent MUST start
the virtual MAC address as well. Since all the necessary state has using the virtual MAC address as well. Since all the necessary state
already been transferred to this standby home agent before the active has already been transferred to this standby home agent before the
home agent failed, it can immediately start acting as the active home active home agent failed, it can immediately start acting as the
agent. active home agent.
In the Home Agent Hard Switch mode, the standby home agent MUST send In the Home Agent Hard Switch mode, the standby home agent MUST send
a Home Agent Switch message to all the mobile nodes that were a Home Agent Switch message to all the mobile nodes that were
registered at the failed home agent as described in Section 7.9, registered at the failed home agent as described in Section 7.9,
using the pre-established IPsec SA. The home agent switch-over is using the pre-established IPsec SA. The standby Home Agent MUST set
complete when it receives binding updates from all the mobile nodes. 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
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 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 7.6. Processing Hello Messages
Hello messages can be unicasted or multicasted. A new multicast Hello messages can be unicasted or multicasted. A new multicast
address will be assigned by the IANA. When all home agents in a 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 redundant home agent set are configured on a same home link, they
MUST join a new multicast address (TBA) and multicast Hello. On the 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, other hand, if a home link is separated as described in Figure 2,
each home agent MUST unicast Hello messages. each home agent MUST unicast Hello messages.
7.6.1. Requesting Hello Message 7.6.1. Requesting Hello Message
A home agent can solicit a Hello message from a particular home agent A home agent can solicit a Hello message from a particular home agent
in the same redundant home agent set by unicasting or multicasting a in the same redundant home agent set by unicasting a Hello message
Hello message with the R-flag set. The sender MUST fill the fields with the R-flag set. The sender MUST fill the fields of the Hello
of the Hello message with it's home agent information. When a Hello message with its home agent information. A home agent can solicit a
message is unicasted, only the destination of the Hello message will Hello message from all the home agents in the multicast group by
answer it. On the other hand, if a Hello message is multicasted, all multicasting a Hello message with the R-flag set. This Hello request
the home agents in the multicast group will reply to the Hello message SHOULD be generated when:
message. This Hello request message SHOULD be generated when:
o A new home agent needs to collect information of the other home o A new home agent needs to collect information of the other home
agents in the same redundant home agent set. In this case it agents in the same redundant home agent set. In this case it
SHOULD multicast a Hello message in which the R-flag is set. 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 A home agent entry in the redundant home agent list is about to be
removed due to home agent lifetime expiration. removed due to home agent lifetime expiration.
o A Hello message has not been received during the specified hello o A Hello message has not been received during the specified hello
interval. interval.
skipping to change at page 29, line 30 skipping to change at page 31, line 48
When a standby home agent wants state information for a particular When a standby home agent wants state information for a particular
mobile node or a subset of mobile nodes, such as Binding Cache, AAA, mobile node or a subset of mobile nodes, such as Binding Cache, AAA,
etc., it MAY solicit this state by sending a State Synchronization etc., it MAY solicit this state by sending a State Synchronization
message 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 Home Address mobility option indicating o It MUST include either a IP address mobility option which subtype
the mobile node, or a Mobile Network Prefix mobility option is set to home address indicating the mobile node, or a Mobile
indicating the mobile router. The standby home agent can send Network Prefix mobility option indicating the mobile router. The
multiple home address and mobile network prefix mobility options standby home agent can send multiple home address and mobile
to request state information for multiple mobile nodes in a single network prefix mobility options to request state information for
State Synchronization request message. 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 When a home agent receives the State Synchronization message with the
Type field set to 0 (Request), it MUST verify the message as follows: Type field set to 0 (Request), it MUST verify the message as follows:
o The state synchronization message MUST be protected by IPsec ESP. o The state synchronization message MUST be protected by IPsec ESP.
o The sending home agent MUST belong to the same redundant home o The sending home agent MUST belong to the same redundant home
agent set agent set
o The receiver MUST be the active home agent for the requested home o The receiver MUST be the active home agent for the requested home
skipping to change at page 31, line 6 skipping to change at page 33, line 31
Identifier field to 0. Identifier field to 0.
When the active home agent stores the state of multiple mobile nodes When the active home agent stores the state of multiple mobile nodes
in a state synchronization message, a Binding Cache Information in a state synchronization message, a Binding Cache Information
option is used as a separator. For each mobile node, a Binding Cache option is used as a separator. For each mobile node, a Binding Cache
Information option is placed first, followed by any other options. Information option is placed first, followed by any other options.
When the next Binding Cache Information option is reached in the When the next Binding Cache Information option is reached in the
State Synchronization message, it indicates the information of a State Synchronization message, it indicates the information of a
different mobile node. different mobile node.
If the unspecified address is found in the Home Address mobility
option carried with the State Synchronization request message, the
active home agent MUST return all the active mobile nodes' and mobile
routers' states by the State Synchronization reply message. The IP
fragmentation can be occurred depending on the total size of all the
states.
A State Synchronization message MUST be authenticated and encrypted A State Synchronization message MUST be authenticated and encrypted
by IPsec ESP mode, otherwise the message MUST be ignored. When a by IPsec ESP mode, otherwise the message MUST be ignored. When a
home agent receives a State Synchronization message, it MUST verify home agent receives a State Synchronization message, it MUST verify
the Source address field of the IPv6 header. If the source address the Source address field of the IPv6 header. If the source address
does not belong to any home agent in the redundant home agent set, does not belong to any home agent in the redundant home agent set,
the message MUST be silently discarded. After successfully verifying the message MUST be silently discarded. After successfully verifying
the message, the receiving home agent MUST update its binding cache the message, the receiving home agent MUST update its binding cache
and all other necessary information such as AAA and vendor specific and all other necessary information such as AAA and vendor specific
information in the particular database. In the Home Agent Hard information in the particular database. In the Home Agent Hard
Switch mode, the receiver MUST also record the IPv6 address of the Switch mode, the receiver MUST also record the IPv6 address of the
sender (the active home agent). sender (the active home agent).
7.7.3. Explicit Acknowledgement of the State Synchronization Reply
message
The Home Agent Reliability protocol does not support any reliable
transport mechanism for Mobility Header signaling, this specification
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
Synchronization Reply message, it MUST set the Ack flag in the
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
Synchronization Reply message into the Reply-Ack and set the type
field to 2 (Reply-Ack).
7.8. Processing Home Agent Control Messages 7.8. Processing Home Agent Control Messages
7.8.1. Standby Home Agent becomes an Active Home Agent 7.8.1. Standby Home Agent becomes an Active Home Agent
When a standby home agent decides to become an active home agent, the When a standby home agent decides to become an active home agent, the
standby home agent sends a SwitchOver Request message (a Home Agent standby home agent sends a SwitchOver Request message (a Home Agent
Control message in which the Type field is set to 0) to the active Control message in which the Type field is set to 0) to the active
home agent. This message MUST be unicasted to the active home agent home agent. This message MUST be unicasted to the active home agent
and MUST be encrypted and authenticated by IPsec ESP. The active and MUST be encrypted and authenticated by IPsec ESP. The active
home Agent MUST NOT generate this message. home Agent MUST NOT generate this message.
skipping to change at page 31, line 45 skipping to change at page 35, line 5
agent). If the receiver is an active home agent and does not want 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 this standby home agent to become the active home agent, it MUST
reply a SwitchOver reply with the Status field set to 129 reply a SwitchOver reply with the Status field set to 129
(Administratively prohibited). In addition, if the sending home (Administratively prohibited). In addition, if the sending home
agent does not belong to the same redundant home agent set, a agent does not belong to the same redundant home agent set, a
SwitchOver Reply message MUST be sent to the sender with the Status SwitchOver Reply message MUST be sent to the sender with the Status
field set to 132 (Not in same redundant home agent set). Otherwise, 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 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). a SwitchOver Reply message with the Status field set to 0 (Success).
If a home agent receives a SwitchOver Reply message, it MUST be The SwitchOver Reply message MUST be protected by IPsec ESP.
protected by IPsec ESP. Otherwise, the message MUST be silently Otherwise, the message MUST be silently discarded. If the receiving
discarded. If the receiving home agent did not send a SwitchOver home agent did not send a SwitchOver Request message (i.e. unexpected
Request message, the message MUST be silently ignored. If the Status SwitchOver Reply), the message MUST be silently ignored. If the
field of the SwitchOver Reply message is 0 (Success), the receiving Status field of the SwitchOver Reply message is 0 (Success), the
standby home agent immediately becomes an active home agent. If the receiving standby home agent immediately becomes an active home agent
value in the Status field is greater than 128 an error has occurred. 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
In this case, the receiver MUST NOT become an active home agent. MUST NOT become an active home agent.
7.8.2. Active Home Agent becomes in-active 7.8.2. Active Home Agent becomes in-active
When an active home agent decides to become an in-active home agent, When an active home agent decides to become an in-active home agent,
it sends a SwitchBack Request message (i.e. a Home Agent Control 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 message with Type field set to 3) to a standby home agent. The
reason for the active home agent to send this message can be reason for the active home agent to send this message can be
administrative intervention, and events like Monitored Server Failure administrative intervention, and events like Monitored Server Failure
by the active home agent or Routing Peer/Link Failure. This message 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 MUST be unicasted to one of the standby home agents and MUST be
skipping to change at page 32, line 43 skipping to change at page 35, line 51
immediately. This is because the active home agent is still active immediately. This is because the active home agent is still active
until it receives the SwitchBack Reply message acknowledging the until it receives the SwitchBack Reply message acknowledging the
SwitchBack Request. The standby home agent SHOULD change to active SwitchBack Request. The standby home agent SHOULD change to active
at least after LINK_TRAVERSAL_TIME. at least after LINK_TRAVERSAL_TIME.
If a home agent receives a SwitchBack Reply message, it MUST be If a home agent receives a SwitchBack Reply message, it MUST be
protected by IPsec ESP, otherwise the message MUST be silently protected by IPsec ESP, otherwise the message MUST be silently
discarded. If the receiving home agent did not send a SwitchBack discarded. If the receiving home agent did not send a SwitchBack
Request message beforehand, the message MUST be silently discarded. Request message beforehand, the message MUST be silently discarded.
If the Status field of the SwitchBack Reply message is 0 (Success), If the Status field of the SwitchBack Reply message is 0 (Success),
the receiving home agent immediately becomes an in-active home agent. the receiving home agent immediately becomes an in-active home agent
If the value in the Status field is greater than 128, an error has and the standby home agent becomes active home agent as described in
occurred. In this case, the receiver cannot become an in-active home Section 7.5. If the value in the Status field is greater than 128,
agent and MUST continue to be an active home agent. 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
If the new active home agent completes the switch-over as described
in Section 7.5, it SHOULD send a Home Agent Control message with the
type field set to 4 (Switch Complete) 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 a Switch Complete message, it can stop offering home agent
services.
7.9. Sending Home Agent Switch Messages 7.9. Sending Home Agent Switch Messages
This operation is valid only for the Home Agent Hard Switch mode. This operation is valid only for the Home Agent Hard Switch mode.
The standby home agent MUST send a Home Agent Switch message as The standby home agent MUST send a Home Agent Switch message as
defined in [11] to all the mobile nodes that were being served by the defined in [ID-HASWITCH] to all the mobile nodes that were being
failed home agent. Since the active home agent address is recorded served by the failed home agent. Since the active home agent address
in each synchronized binding cache, the standby home agent knows is recorded in each synchronized binding cache, the standby home
which mobile nodes were served by the failed home agent. The Home agent knows which mobile nodes were served by the failed home agent.
Agent Switch message must be encrypted with a pre-established SA. The Home Agent Switch message must be encrypted with a pre-
The standby home agent should include its own IPv6 address in the established SA. The standby home agent MUST include only its own
Home Agent Switch message. Note that a Home Agent Switch message is IPv6 address in the Home Agent Switch message. Note that a Home
sent to each mobile node served by the home agent. If there is a Agent Switch message is sent to each mobile node served by the home
large number of mobile nodes, sending Home Agent Switch messages will agent. If there is a large number of mobile nodes, sending Home
cause a lot of signaling overhead on the network. 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 When a failed home agent recovers, it MUST re-establish an IPsec SA
with each mobile node served by its redundant home agent set. with each mobile node served by its redundant home agent set.
Otherwise, it cannot be either a standby or active home agent for the Otherwise, it cannot be either a standby or active home agent for the
mobile nodes. Therefore, it sends a Home Agent Switch message with mobile nodes. Therefore, as soon as the active home agent detects
the I-flag set to all the mobile nodes serving by other home agents the recovery of the failed home agent, it sends a Home Agent Switch
in the same redundant home agent set, and includes its own home agent message with the I-flag set to all the mobile nodes serving by other
address in the Home Agent Addresses field. 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 on.
7.10. Interworking with VRRP 7.10. 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
skipping to change at page 35, line 43 skipping to change at page 39, line 19
o If an active home agent sends a SwitchBack Request message, it o If an active home agent sends a SwitchBack Request message, it
SHOULD use an initial retransmission interval of SHOULD use an 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 10.
The retransmission MUST use an exponential backoff process as The retransmission MUST use an exponential backoff process as
described in [1] until either the home agent receives a response, or described in [RFC-3775] until either the home agent receives a
the timeout period reaches the value MAC_HARELIABILITY_TIMEOUT response, or the timeout period reaches the value
(16sec). The home agent SHOULD use a separate back-off process for MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a
different message types and different destinations. The rate separate back-off process for different message types and different
limiting of Mobility Header messages is the same as one in [1]. A destinations. The rate limiting of Mobility Header messages is the
home agent MUST NOT send Mobility Header Messages to a particular same as one in [RFC-3775]. A home agent MUST NOT send Mobility
home agent more than MAX_UPDATE_RATE (3) times a second, which is Header Messages to a particular home agent more than MAX_UPDATE_RATE
specified in [1]. (3) times a second, which is specified in [RFC-3775].
8. Mobile Node Operation 8. Mobile Node Operation
Operations described in this section are valid only for the Home Operations described in this section are valid only for the Home
Agent Hard Switch mode. When the Home Agent Virtual Switch is used, Agent Hard Switch mode. When the Home Agent Virtual Switch is used,
all these operations can be skipped. all these operations can be skipped.
8.1. Home Agent Addresses Discovery 8.1. Home Agent Addresses Discovery
To provide home agent reliability with the Home Agent Hard Switch To provide home agent reliability with the Home Agent Hard Switch
mode, a mobile node authenticates itself to two or more home agents mode, a mobile node authenticates itself to two or more home agents
and creates IPsec SAs with them during bootstrapping. When one home and creates IPsec SAs with them during bootstrapping. When one home
agent fails, another home agent can use the pre-existing SA to notify agent fails, another home agent can use the pre-existing SA to notify
the mobile node about the failure. the mobile node about the failure.
Multiple home agent addresses are available in a home network. In Multiple home agent addresses are available in a home network. In
order to discover these home agent addresses, two different order to discover these 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 [13]. One is DNS lookup by home agent Name, the other is scenario [RFC-5026]. One is DNS lookup by home agent Name, the other
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 [14] to provide home agent provisioning to mobile integrated scenario [ID-BOOTINT] to provide home agent provisioning
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 [13]. For example, Name to discover the home agents, as defined in [RFC-5026]. For
if home agent reliability is required by a mobile node, DNS lookup by example, if home agent reliability is required by a mobile node, DNS
Service Name method is recommended for the mobile node to discover lookup by Service Name method is recommended for the mobile node to
multiple home agents addresses. Therefore, mobile nodes will query discover multiple home agents addresses. Therefore, mobile nodes
the DNS SRV records with a service name of mip6 and protocol name of will query the DNS SRV records with a service name of mip6 and
ipv6. The DNS SRV records includes multiple home agent addresses and protocol name of ipv6. The DNS SRV records includes multiple home
different preference values and weights. The mobile node SHOULD agent addresses and different preference values and weights. The
choose two or more home agents from the home agents list according to mobile node SHOULD choose two or more home agents from the home
their preference value. Then the mobile node should authenticate agents list according to their preference value. Then the mobile
itself to these home agents via an IKEv2 exchange. node should authenticate itself to these home agents via an IKEv2
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 [14]. agent provisioning from an MSP or ASP, as already defined in [ID-
The only requirement is that the DHCPv6 response must include BOOTINT]. The only requirement is that the DHCPv6 response must
multiple home agents' information in order to support home agent include multiple home agents' information in order to support home
reliability. agent reliability.
8.2. IKE/IPsec pre-establishment to Home Agents 8.2. IKE/IPsec pre-establishment to Home Agents
After a mobile node gets multiple home agent addresses, it needs to After a mobile node gets multiple home agent addresses, it needs to
trigger multiple IKE exchanges with theh multiple home agents trigger multiple IKE exchanges with the multiple home agents selected
selected from the home agent list. Since both IKEv1 and IKEv2 can be from the home agent list. Since both IKEv1 and IKEv2 can be used to
used to bootstrap Mobile IPv6, this solution does not introduce any bootstrap Mobile IPv6, this solution does not introduce any new
new operations to co-operate with IKEv1 or IKEv2. It should initiate operations to co-operate with IKEv1 or IKEv2. It should initiate IKE
IKE for home agents as soon as home registration is complete. 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 [13], or the IKEv1 bootstrapping solution of the split scenario [RFC-5026]. Home
bootstrapping solution [15]. Home Address configuration maybe also Address configuration maybe also be included, if necessary, for the
be included, if necessary, for the first IKE exchange. After its first IKE exchange. After its Home Address is assigned or approved
Home Address is assigned or approved by the first home agent, mobile by the first home agent, mobile node SHOULD register itself with the
node SHOULD register itself with the second home agent with IKE using second home agent with IKE using the same Home Address. Therefore,
the same Home Address. Therefore, no home address configuration no home address configuration should be used in the second IKEv2
should be used in the second IKEv2 procedure. Note that the mobile procedure. Note that the mobile node only sends a Binding Update
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 8.3. Receiving Home Agent Switch message
A mobile node must follow the operation specified in [11] when it A mobile node must follow the operation specified in [ID-HASWITCH]
receives a Home Agent Switch message. when 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 Section 8.1,
the mobile node MUST NOT start an IKE session with the unknown home the mobile node MUST NOT start an IKE session with the unknown home
agent. Instead, it SHOULD re-start home agent discovery again to agent. Instead, it SHOULD re-start home agent discovery again to
update its home agent address information. 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 SHOULD pick 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 Binding Update message to
it. The mobile node already has a pre-established SA with the home it. Note that the standby home agent address in the switch message
agent and should use that SA to send the Binding Update. MUST be equal to the sender of the Home Agent Switch message. This
is because the standby Home agent expects the Binding Update as an
acknowledgement of the Home Agent Switch message. The mobile node
already has a pre-established SA with the home agent and should use
that SA to send the Binding Update. If the address stored in the
Home agent address field is different from the sender, the mobile
node MUST send a binding update to the sender.
9. Security Considerations 9. 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 [9]. The ESP header has the following fields: RFC4301 [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
skipping to change at page 39, line 18 skipping to change at page 43, line 18
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
necessarily synchronized between home agents. necessarily synchronized between home agents.
Others Others
Other fields should be synchronized based on RFC4301[9] 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 10. 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. Contributors 11. IANA Considerations
o The values for following mobility header message MUST be assigned
by IANA.
* State Synchronization Message
* Home Agent Control Message
* Home Agent Hello 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
IANA.
1. Binding Cache Information Option
2. AAA Information Option
o New Option Code for the IP address option defined in [RFC-4068]
12. Contributors
This document is a result of discussions in the Mobile IPv6 Home This document is a result of discussions in the Mobile IPv6 Home
Agent Reliability Design Team. The members of the design team 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
kchowdhury@starentnetworks.com kchowdhury@starentnetworks.com
Hui Deng Hui Deng
hdeng@hitachi.cn denghui@chinamobile.com
Vijay Devarapalli Vijay Devarapalli
vijay.devarapalli@azairenet.com vijay.devarapalli@azairenet.com
Sri Gundavelli Sri Gundavelli
sgundave@cisco.com sgundave@cisco.com
Brian Haley Brian Haley
skipping to change at page 41, line 43 skipping to change at page 47, 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
12. Acknowledgements 13. Acknowledgements
This document includes a lot of text from [16] and [17]. Therefore This document includes a lot of text from [ID-LOCALHAHA] and [ID-
the authors of these two documents are acknowledged. We would also HAHA]. Therefore the authors of these two documents are
like to thank the authors of the home agent reliability problem acknowledged. We would also like to thank the authors of the home
statement [18] for describing the problem succinctly and Alice Qin agent reliability problem statement [ID-PS-HARELIABILITY] for
for her work on the hello protocol. describing the problem succinctly and Alice Qin for her work on the
hello protocol.
13. References 14. References
13.1. Normative References 14.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
IPv6", RFC 3775, June 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Standby Router Protocol (HSRP)", RFC 2281, March 1998.
January 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Levels", BCP 14, RFC 2119, March 1997. Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004. RFC 3768, April 2004.
[5] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
Router Protocol (HSRP)", RFC 2281, March 1998. IPv6", RFC 3775, June 2004.
[6] 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 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
Agents", RFC 3776, June 2004. RFC 3776, June 2004.
[7] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
draft-ietf-mip6-vsm-00 (work in progress), December 2006. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
for IP Version 6 (IPv6)", RFC 2461, December 1998. Internet Protocol", RFC 4301, December 2005.
[9] Kent, S. and K. Seo, "Security Architecture for the Internet [ID-VSM] Devarapalli, V., "Mobile IPv6 Vendor Specific Option",
Protocol", RFC 4301, December 2005. draft-ietf-mip6-vsm-03 (work in progress), October 2007.
13.2. Informative References 14.2. Informative References
[10] 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.
[11] Haley, B., "Mobility Header Home Agent Switch Message", [ID-HASWITCH] Haley, B., "Mobility Header Home Agent Switch Message",
draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. draft-ietf-mip6-ha-switch-05 (work in progress), November 2007.
[12] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, [RFC-4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005. July 2005.
[13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
draft-ietf-mip6-bootstrapping-split-02 (work in progress), scenario", RFC 5026, October 2007.
March 2006.
[14] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
progress), October 2005.
[15] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via
Bootstrapping with IKEv1", DHCPv6 for the Integrated Scenario",
draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress),
March 2006. June 2007.
[16] Wakikawa, R., "Inter Home Agents Protocol Specification", [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006.
March 2006.
[17] Devarapalli, V., "Local HA to HA protocol", [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006.
March 2006.
[18] Faizan, J., "Problem Statement: Home Agent Reliability", [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent
draft-jfaizan-mipv6-ha-reliability-01 (work in progress), 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-00 Changes from draft-ietf-mip6-hareliability-02
o comment (see mail at 2007 June 20) from Wesley Eddy, Verizon o comment (see mail at 2007 June 20) from Wesley Eddy, Verizon
Federal Network Systems 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)
Author's Address Author's Address
Ryuji Wakikawa (Editor) Ryuji Wakikawa (Editor)
Keio University Faculty of Environment and Information Studies, Keio University
Department of Environmental Information, Keio University. Keio University, 5322 Endo
5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Phone: +81-466-49-1100 Phone: +81-466-49-1100
Fax: +81-466-49-1395 Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/ URI: http://www.wakikawa.org/
Full Copyright Statement Full Copyright Statement
 End of changes. 108 change blocks. 
295 lines changed or deleted 492 lines changed or added

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