draft-ietf-mip6-hareliability-07.txt   draft-ietf-mip6-hareliability-08.txt 
MEXT Working Group R. Wakikawa (Editor) MEXT Working Group R. Wakikawa (Editor)
Internet-Draft Toyota ITC USA. Internet-Draft Toyota ITC USA.
Intended status: Standards Track October 20, 2010 Intended status: Standards Track November 9, 2010
Expires: April 23, 2011 Expires: May 13, 2011
Home Agent Reliability Protocol (HARP) Home Agent Reliability Protocol (HARP)
draft-ietf-mip6-hareliability-07.txt draft-ietf-mip6-hareliability-08.txt
Abstract Abstract
The home agent can be a single point of failure when Mobile IPv6 and The home agent can be a single point of failure when Mobile IPv6 and
its associated supporting protocols are operated in a system. It is its associated supporting protocols are operated in a system. It is
critical to provide home agent reliability in the event of a home critical to provide home agent reliability in the event of a home
agent crashing or becoming unavailable. This would allow another agent crashing or becoming unavailable. This would allow another
home agent to take over and continue providing service to the mobile home agent to take over and continue providing service to the mobile
nodes. This document describes the problem scope briefly and nodes. This document describes the problem scope briefly, and
provides mechanisms of home agent failure detection, home agent state provides mechanisms of home agent failure detection, home agent state
transfer, and home agent switching for home agent redundancy and transfer, and home agent switching for home agent redundancy and
reliability. reliability.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 23, 2011. This Internet-Draft will expire on May 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem Statement and Requirements . . . . . . . . . . . . 6 1.2. Problem Statement and Requirements . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 12 3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 11
3.1. Network Configuration . . . . . . . . . . . . . . . . . . 12 3.1. Network Configuration . . . . . . . . . . . . . . . . . . 12
3.2. Home Agent Address Configuration . . . . . . . . . . . . . 13 3.2. Home Agent Address Configuration . . . . . . . . . . . . . 13
4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 13 4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 13
4.1. Home Agent List Management . . . . . . . . . . . . . . . . 13 4.1. Home Agent List Management . . . . . . . . . . . . . . . . 13
4.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 14 4.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 14
4.3. Processing the HARP Messages . . . . . . . . . . . . . . . 15 4.3. Processing the HARP Messages . . . . . . . . . . . . . . . 15
4.3.1. IP field and Security Descriptions of HARP message . . 15 4.3.1. IP field and Security Descriptions of HARP message . . 15
4.3.2. Processing Home Agent Hello (HA-HELLO) . . . . . . . . 16 4.3.2. Processing Home Agent Hello (HA-HELLO) . . . . . . . . 16
4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) . . . 17 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) . . . 17
4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) . . . 19 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) . . . 19
4.4. State Synchronization . . . . . . . . . . . . . . . . . . 20 4.4. State Synchronization . . . . . . . . . . . . . . . . . . 20
4.4.1. Binding Cache Information Management . . . . . . . . . 21 4.4.1. Binding Cache Information Management . . . . . . . . . 21
4.4.2. IP field and Security Descriptions of SS message . . . 21 4.4.2. IP field and Security Descriptions of State
Synchronization message . . . . . . . . . . . . . . . 21
4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 21 4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 21
4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 22 4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 22
4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 23 4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 23
4.5. Switching the Active Home Agent . . . . . . . . . . . . . 23 4.5. Switching the Active Home Agent . . . . . . . . . . . . . 24
4.6. Consideration of Routing and Neighbor Discovery 4.6. Consideration of Routing and Neighbor Discovery
Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 25 Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 25
4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 26 4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 26
4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26 4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 27 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 27
5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 27 5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 27
5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 28 5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 28
5.3. Synchronizing State: K-bit treatment . . . . . . . . . . . 28 5.3. Synchronizing State: K-bit treatment . . . . . . . . . . . 28
5.4. Receiving Home Agent Switch message . . . . . . . . . . . 29 5.4. Receiving Home Agent Switch message . . . . . . . . . . . 29
6. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 29 6. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 29 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 29
6.1.1. HARP Message Format . . . . . . . . . . . . . . . . . 29 6.1.1. HARP Message Format . . . . . . . . . . . . . . . . . 29
6.1.2. State Synchronization Message Format . . . . . . . . . 33 6.1.2. State Synchronization Message Format . . . . . . . . . 33
6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 35 6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 35
6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 36 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 36
6.2.1. Binding Cache Information Option . . . . . . . . . . . 36 6.2.1. Binding Cache Information Option . . . . . . . . . . . 36
6.2.2. State Synchronization Status Option . . . . . . . . . 37 6.2.2. State Synchronization Status Option . . . . . . . . . 38
6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 39 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 39
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 40 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 40 11. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 41
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
In Mobile IPv6 [RFC-3775] and its derivatives protocols like NEMO In Mobile IPv6 [RFC-3775, ID-3775bis] and its derivative protocols
Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC-5555], if a like NEMO Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC-
home agent loses the binding cache state or even network 5555], if a home agent loses binding cache state or even network
connectivity, due to its failure or some other reason, it results in connectivity due to its failure, or some other reason, the result is
a loss of service for the mobile nodes. It is beneficial to provide a loss of service for the mobile nodes. It is beneficial to provide
high availability and redundancy for a home agent so that mobile high availability and redundancy for a home agent so that mobile
nodes can avail of uninterrupted service even when one home agent nodes can have uninterrupted service even when one home agent crashes
crashes or loses state. The Home Agent Reliability protocol (HARP) or loses state. The Home Agent Reliability Protocol (HARP) is
is designed to manage standby home agents and switch service from an designed to manage standby home agents, and switch service from an
active to a standby home agent in the case of an active Home Agent active to a standby home agent in the case of an active home agent
failing. failure.
[RFC-3775] will be updated by [ID-3775bis] soon.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
In this document, the term mobile node refers both to a mobile host In this document, the term mobile node refers both to a mobile host
[RFC-3775] and a mobile router [RFC-3963]. [RFC-3775] and a mobile router [RFC-3963].
Mobility related terms used in this document are defined in [RFC- Mobility related terms used in this document are defined in [RFC-
3775] and [RFC-3753]. In addition or in replacement of these, the 3775] and [RFC-3753]. In addition or in replacement of these, the
following terms are defined or redefined: following terms are defined or redefined:
Home Agent Reliability Protocol (HARP) Home Agent Reliability Protocol (HARP)
A protocol between Mobile IPv6 Home agents which provides A protocol between Mobile IPv6 home agents that provides
reliability by moving state and service from an active home agent reliability by moving state and service from an active home agent
to a standby in the case of the active home agent failing. HARP to a standby, in the case of an active home agent failure. HARP
assumes multiple home agents placement on a same home link or can accomodate multiple home agents being placed on the same home
different links and groups them into a redundant home agent set. link, or on different links, by grouping them into a redundant
One of home agents is selected as an active home agent. In case home agent set. One of home agents is selected as an active home
of the active home agent's failure, a standby home agent can take agent. If the active home agent fails, a standby home agent can
over and become the active home agent. Since each home agent is take over and become the active home agent. Since each home agent
assigned individual home agent addresses, a mobile node is aware is assigned individual home agent addresses, a mobile node is
of home agent failures and needs to register its binding to the aware of home agent failures and needs to register its binding to
new active home agent again. the new active home agent again.
Virtual Home Agent Reliability Protocol (VHARP) Virtual Home Agent Reliability Protocol (VHARP)
A protocol between Mobile IPv6 Home agents which provides
A protocol between Mobile IPv6 home agents which provides
reliability by cloning an active home agent. Unlike HARP, the reliability by cloning an active home agent. Unlike HARP, the
standby home agents are an exact copy of the active home agent standby home agents are an exact copy of the active home agent,
including home agent IP address. It is similar to the virtual including home agent IP address. It is similar to the virtual
router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. router concept of VRRP [RFC-3768, RFC-5798] and HSRP [RFC-2281].
The VHARP operations are transparent to a mobile node. The VHARP operations are transparent to a mobile node.
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 can serve the mobile nodes when the active home A home agent which can serve the mobile nodes when the active home
agent fails. agent fails.
skipping to change at page 5, line 37 skipping to change at page 5, line 33
An IPv6 address of the Active Home Agent. An IPv6 address of the Active Home Agent.
Standby Home Agent Address Standby Home Agent Address
An IPv6 address of the Standby Home Agent. An IPv6 address of the Standby Home Agent.
Redundant Home Agent Set Redundant Home Agent Set
A grouping which includes an active and standby home agent(s). A grouping which includes an active and standby home agent(s).
The Group Identifier is used to identify a redundant home agent The Group Identifier is used to identify a redundant home agent
set. Operators need to configure a value per redundant home agent set. Operators need to configure a unique value per redundant
set. home agent set.
Virtual Home Agent Address Virtual Home Agent Address
A home agent address shared among home agents in a redundant home A home agent address shared among home agents in a redundant home
agent set. It is similar to virtual router address specified in agent set. It is similar to virtual router address specified in
VRRP [RFC-3768] [RFC-5798]. The address is only activated on an VRRP [RFC-3768, RFC-5798]. The address is only activated on an
active home agent. active home agent.
Home Agent Preference Home Agent Preference
This preference value is originally defined for Dynamic Home Agent
Address Discovery (DHAAD) in RFC3775. This protocol re-uses this This preference value was originally defined for Dynamic Home
preference value for home agent selection when an active home Agent Address Discovery (DHAAD) in RFC3775. This protocol re-uses
this preference value for home agent selection when an active home
agent has failed. A home agent SHOULD NOT share the same agent has failed. A home agent SHOULD NOT share the same
preference value with other home agents. Meanwhile, operators can preference value with other home agents. Meanwhile, operators can
also define an independent value for the home agent reliability also define an independent value for the home agent reliability
protocol. It is useful when operators want to have different protocol. It is useful when operators want to assign different
operational policy to the preference values of DHAAD and the Home operational policies to the preference values of DHAAD and the
Agent Reliability Protocol. Home Agent Reliability Protocol.
New Messages New Messages
Home Agent Reliability Protocol (HARP) message defined in Home Agent Reliability Protocol (HARP) message defined in
Section 6.1.1: Section 6.1.1:
SwitchOver Request (SWO-REQ) SwitchOver Request (SWO-REQ)
SwitchOver Reply (SWO-REP) SwitchOver Reply (SWO-REP)
skipping to change at page 7, line 15 skipping to change at page 7, line 7
agent to a new active home agent requires coordination or pre- agent to a new active home agent requires coordination or pre-
configuration among the home agents regarding security associations, configuration among the home agents regarding security associations,
transfer of mobile node bindings, and other service information for transfer of mobile node bindings, and other service information for
reliable Mobile IPv6 service in a deployment scenario. reliable Mobile IPv6 service in a deployment scenario.
For the home agent reliability solution, we define the following For the home agent reliability solution, we define the following
generic requirements: generic 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 [RFC-3775]. 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 agent(s). This
includes the Binding Cache, AAA information, other Mobile IPv6 and includes the Binding Cache, AAA information, and other Mobile IPv6
NEMO related information. Note that the Home Agent Reliability and NEMO related information. Note that the Home Agent
protocol exchanges only running states of mobile nodes. Reliability Protocol only exchanges state information for active
Therefore, we do not have any specific operation for synchronizing mobile nodes. Therefore, we do not have any specific operation
the configuration information. For instance, when Mobile IPv6 is for synchronizing the configuration information. For instance,
operated with Authentication protocol [RFC-4285], synchronizing when Mobile IPv6 is operated with Authentication protocol [RFC-
the configurations of the Authentication protocol is out of scope 4285], synchronizing the configurations of the Authentication
in this document. Operators MAY correctly set the configuration protocol is out of scope in this document. Operators MAY
information in multiple home agents. correctly set the configuration information 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. (Note this is out of scope in this document.) home agent set. (Note this is out of scope in this document.)
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[RFC-3768] or HSRP [RFC- failure detection mechanism such as VRRP [RFC-3768, RFC-5798] or
2281], it can re-use that mechanism to detect the home agent HSRP [RFC-2281], it can re-use that mechanism to detect home agent
failure. On the other hand, periodic Hello messages are failure. In addition, periodic Hello messages are introduced in
introduced to detect active home agent's service availability in this document to detect active an home agent's service
this document. availability.
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.
2. Protocol Overview 2. Protocol Overview
HARP works when one or more home agents are provisioned on a home HARP works when one or more home agents are provisioned on a home
link or different links and these are grouped into a redundant home link, or different links, and these are grouped into a redundant home
agent set. One of home agents is selected as an active home agent agent set. One home agent is selected as the active home agent and
and receives a binding update from mobile nodes. According to [RFC- receives binding updates from mobile nodes. According to [RFC- 3775,
3775, RFC-4877], an active home agent maintains not only binding RFC-4877], an active home agent maintains not only binding cache
cache but also IPsec/IKEv2 states per mobile node, because Mobile information, but also IPsec/IKEv2 states per mobile node, because
IPv6 relies on IPsec for securing the signaling and optionally user Mobile IPv6 relies on IPsec for securing the signaling, and
plane traffic. optionally user plane traffic.
If the active home agent fails, all state information associated with If the active home agent fails, all state information associated with
an MN is lost. As a result, all mobile nodes served by the failed a mobile node is lost. As a result, all mobile nodes served by the
home agent will be disconnected. In HARP, other home agents , named failed home agent will be disconnected. In HARP, other home agents,
standby home agent, exchange the required information with the active called standby home agents, exchange the required information with
home agent in case of failure of the active home agent. HARP can let the active home agent. In case of a failure of the active home
standby home agent take over the failed home agent with such agent, HARP can let a standby home agent take over for the failed
information of the serving mobile nodes. home agent with this information about the active mobile nodes.
MN HA1 HA2 MN HA1 HA2
| [HA1-addr] [HA2-addr] | [HA1-addr] [HA2-addr]
| | | | | |
| (active) (standby) | (active) (standby)
| | | | | |
| |<--------->| 1. Hello exchanges | |<--------->| 1. Hello exchanges
|<--------->| | 2. Binding Registration to HA1 |<--------->| | 2. Binding Registration to HA1
| |<--------->| 3. State exchanges | |<--------->| 3. State exchanges
| | | | | |
skipping to change at page 9, line 26 skipping to change at page 9, line 7
| X | 4. Failure Detection | X | 4. Failure Detection
|<----------------------| 5. Sending Home Agent Switch message |<----------------------| 5. Sending Home Agent Switch message
|<--------------------->| 6. Binding Registration to HA2 |<--------------------->| 6. Binding Registration to HA2
| X (active) RECOVERY COMPLETE | X (active) RECOVERY COMPLETE
| X | | X |
Figure 1: Overview of Home Agent Reliability Protocol (HARP) Figure 1: Overview of Home Agent Reliability Protocol (HARP)
Figure 1 shows an example of the HARP operations. HA1 and HA2 belong Figure 1 shows an example of the HARP operations. HA1 and HA2 belong
to the same redundant home agent set and are assigned with an to the same redundant home agent set and are assigned with an
individual IP address (HA1 and HA2-addr) at the home link. Each home individual IP address (HA1-addr and HA2-addr) at the home link. Each
agent can be seen as an individual home agent by mobile nodes. All home agent can be seen as an individual home agent by mobile nodes.
the home agents periodically send a hello message (named HA-HELLO) to All the home agents periodically send a Hello message (named HA-
exchange the home agent information and also monitor the active home HELLO) to exchange the home agent information, as well as monitor the
agent's status (1). The mobile node registers its binding only with state of the active home agent (1). The mobile node registers its
the active home agent (2). The active home agent synchronizes the binding with only the active home agent (2). The active home agent
serving mobile node information (i.e. home address) with the other synchronizes the active mobile node information with the other
standby home agents periodically (3). standby home agents periodically (3).
HARP introduces the new HA-HELLO message for failure detection, but HARP introduces the new HA-HELLO message for failure detection, but
it may use any types of information to detect that failure. After it may use any type of information to detect that failure. After
detecting failure of the active home agent (4), a standby home agent detecting the failure of the active home agent (4), the standby home
whose preference value is the highest takes over the failed home agent whose preference value is the highest takes over for the failed
agent. For doing so, the standby home agent sends a Home Agent home agent. Once completed, the standby home agent sends a Home
Switch message to all the mobile nodes that were registered at the Agent Switch message to all the mobile nodes that were registered at
failed home agent (5). The standby Home Agent sets its own address the failed home agent (5). The standby home agent puts its own
in the Home Agent Address field in the Home Agent Switch message so address in the Home Agent Address field of the Home Agent Switch
that it will receive the binding update from the mobile node as an message so that it will receive the binding update from the mobile
acknowledgment of the sent Home Agent Switch message. The home agent node as an acknowledgment of the sent Home Agent Switch message. The
switch-over is complete when it receives binding updates from all the home agent switch-over is complete when it receives binding updates
mobile nodes (6). For protecting the Home Agent Switch, the mobile from all the mobile nodes (6). For protecting the Home Agent Switch
node should have IPsec Security Associations (SA) with the standby message, the mobile node should have an IPsec Security Association
home agent before any failover. The mobile node may pre-establish (SA) with the standby home agent before the failover. The mobile
multiple IPsec SAs with all the home agents. node may pre-establish multiple IPsec SAs with all the home agents.
Although the active home agent manages IPsec/IKEv2 states per mobile Although the active home agent manages IPsec/IKEv2 states per mobile
node, HARP does not offer any recovery mechanism of these states by node, HARP does not offer any recovery mechanism of these states by
itself. IPsec/IKE states synchronization is out of scope in this itself. IPsec/IKE state synchronization is out of scope in this
document. If IPsec/IKEv2 states can be recovered from the active document. If IPsec/IKEv2 state can be recovered from the active home
home agent to standby one, HARP can be operated slightly in different agent on the standby home agent, HARP can be operated in a slightly
manner named Virtual-HARP (VHARP). Unlike HARP, the standby home different manner called Virtual-HARP (VHARP). Unlike HARP, the
agents are an exact copy of the active home agent. It is similar to standby home agents are an exact copy of the active home agent. It
the virtual router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC- is similar to the virtual router concept of VRRP [RFC-3768, RFC-5798]
2281]. Note that HARP is mandatory and VHARP is optional in this and HSRP [RFC- 2281]. Note that HARP is mandatory and VHARP is
document. VHARP is shown in Figure 2. optional in this document. VHARP is shown in Figure 2.
MN HA1 HA2 MN HA1 HA2
| [HA-addr] [HA-addr'] | [HA-addr] [HA-addr']
| | : | | :
| (active) (standby) | (active) (standby)
|<--------->| : 1. Binding Registration to HA1 |<--------->| : 1. Binding Registration to HA1
| |<--------->: 2. State exchanges | |<--------->: 2. State exchanges
| | : | | :
| X : HA1 FAILURE | X : HA1 FAILURE
| X : | X :
| X : 3. Failure Detection | X : 3. Failure Detection
| X | 4. HA2 takes over the HA1 | X | 4. HA2 takes over the HA1
| X (active) RECOVERY COMPLETE | X (active) RECOVERY COMPLETE
| X | | X |
Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP) Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP)
All the home agents (HA1 and HA2) in the redundant home agent set All the home agents (HA1 and HA2) in the redundant home agent set
share a virtual home agent address (HA-addr) and the routing will share a virtual home agent address (HA-addr), and routing ensures
ensure only the active home agent will be reachable using that only the active home agent will be reachable using that virtual home
virtual home agent address. After a mobile node's binding agent address. After a mobile node's binding registration (1), the
registration (1), the active home agent pushes all the states of its active home agent pushes the states of all of its mobile nodes to the
mobile nodes to the other standby home agents (2). In VHARP, all the other standby home agents (2). In VHARP, all the states of a mobile
states of a mobile node need to be synchronized. The example node need to be synchronized. For example, information such as the
information such as Binding Cache and Authentication, Authorization, Binding Cache, and Authentication, Authorization, and Accounting
and Accounting (AAA) information, etc. (AAA) information.
After detecting the active home agent has failed (3), the standby After detecting the active home agent has failed (3), the standby
home agent whose preference value is the highest takes over the home agent whose preference value is the highest takes over the
failed home agent. The standby home agent activates the virtual home failed home agent. The standby home agent activates the virtual home
agent address on its interface attached to the home link. The agent address on its interface attached to the home link. The
virtual home agent address's activation can be operated by VRRP. virtual home agent address activation can be operated by VRRP. Since
Since all the necessary states of mobile nodes have already been all the necessary states of mobile nodes have already been
transferred to this standby home agent, the standby home agent can transferred to this standby home agent, the standby home agent can
immediately start acting as the active home agent (4). Unlike HARP, immediately start acting as the active home agent (4). Unlike HARP,
the mobile node is not required to re-register its binding to a new the mobile node is not required to re-register its binding to a new
active home agent. The mobile node may use the IKEv2 resumption active home agent. The mobile node may use the IKEv2 resumption
mechanism [RFC-5723] to resume IPsec SA with the new active home mechanism [RFC-5723] to resume it's IPsec SA with the new active home
agent. agent.
This document offers a new management mechanism of active and standby This document offers a new management mechanism of active and standby
home agents by using a new Mobility Header (MH) message named a HARP home agents by using a new Mobility Header (MH) message called a HARP
message as shown in Figure 3. This mechanism can be used in both message as shown in Figure 3. This mechanism can be used in both
HARP and VHARP. Each home agent exchanges own home agent information HARP and VHARP. Each home agent exchanges its own home agent
with the other home agents in its redundancy home agent set by a Home information with the other home agents in its redundant home agent
Agent HELLO message (HA-HELLO) (1). The HA-HELLO message can also be set by a Home Agent HELLO message (HA-HELLO) (1). The HA-HELLO
used to monitor the availability of the active home agent. message can also be used to monitor the availability of the active
home agent.
HA1(active) HA2 HA3 .. HAn HA1(active) HA2 HA3 .. HAn
| | | | | | | |
|<------>|<---->|<---->| 1. HELLO exchange |<------>|<---->|<---->| 1. HELLO exchange
|------->| | | 2. HA1 sends SWB-REQ |------->| | | 2. HA1 sends SWB-REQ
|<-------| | | 3. HA2 sends SWB-REP |<-------| | | 3. HA2 sends SWB-REP
|------->| | | 4. HA2 sends SW-COMP |------->| | | 4. HA2 sends SW-COMP
(standby) (active) | | HA2 BECOMES ACTIVE HA (standby) (active) | | HA2 BECOMES ACTIVE HA
| | | | | | | |
SYSTEM MAINTENANCE, ETC. SYSTEM MAINTENANCE, ETC.
| | | | | | | |
|------->| | | 5. HA1 sends SWO-REQ |------->| | | 5. HA1 sends SWO-REQ
|<-------| | | 6. HA2 sends SWO-REP |<-------| | | 6. HA2 sends SWO-REP
|------->| | | 7. HA1 sends SW-COMP (optional) |------->| | | 7. HA1 sends SW-COMP (optional)
(active) (standby) | | 8. HA1 returns to active HA (active) (standby) | | 8. HA1 returns to active HA
| | | | HA1 BECOMES ACTIVE AGAIN | | | | HA1 BECOMES ACTIVE AGAIN
Figure 3: Home Agent Management Figure 3: Home Agent Management
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 enables mobile nodes for system maintenance. This specification enables
manual intervention for home agent management. As shown in Figure 3, manual intervention for home agent management. As shown in Figure 3,
the active home agent (HA1) sends a SwitchBack Request message (SWB- the active home agent (HA1) sends a SwitchBack Request message (SWB-
REQ) to a standby home agent (HA2) (2). HA2 will acknowledge the REQ) to a standby home agent (HA2) (2). HA2 will acknowledge the
message by sending a SwitchBack Reply message (SWB-REP) to HA1 (3). message by sending a SwitchBack Reply message (SWB-REP) to HA1 (3).
In the HARP operation, it takes certain time to complete home agent In HARP operation, it could take a long time to complete home agent
fail-over by mobile nodes' re-registration to the new home agent. failover since all mobile nodes must re-register with the new home
During this fail-over operations, HA1 may continue serving the mobile agent. During this failover operation, HA1 may continue serving the
nodes until the switch over is completed. When HA2 decides the mobile nodes until the switch-over is completed. When HA2 decides
switch-over is completed, it MAY send an optional message, SW-COMP, the switch-over has completed, it MAY send an optional message, SW-
to HA1 (4). As soon as HA2 sends the SW-COMP, it becomes the active COMP, to HA1 (4). As soon as HA2 sends the SW-COMP, it becomes the
home agent. HA1 becomes standby when it receives SW-COMP. If SW- active home agent. HA1 becomes a standby home agent when it receives
COMP is not used, HA2 and HA1 changes their status appropriately. SW-COMP. If SW-COMP is not used, HA2 and HA1 change their status
appropriately.
After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2 After maintenance is complete and HA1 is back online, HA1 sends a
in order to become the active home agent again (5). HA2 acknowledges SwitchOver Request (SWO-REQ) to HA2 in order to become the active
it by sending a SwitchOver Reply (SWO-REP) to HA1 (6). HA1 now home agent again (5). HA2 acknowledges it by sending a SwitchOver
starts home agent fail-over operation. After the completion of fail- Reply (SWO-REP) back to HA1 (6). HA1 now starts the home agent
over, HA1 sends a SW-COMP to HA2 (7). Then, HA1 returns to the failover operation. After the switch-over is complete, HA1 sends a
active home agent and HA2 fall back to a standby home agent (8). SW-COMP to HA2 (7). Then, HA1 becomes the active home agent and HA2
becomes a standby home agent (8).
3. Home Agent Configuration 3. Home Agent Configuration
3.1. Network Configuration 3.1. Network Configuration
HARP supports two different configurations for standby home agents. HARP supports two different configurations for standby home agents.
Standby home agents can be placed on the same home link or on a Standby home agents can be placed on the same home link or on
different link. Figure 4 depicts the configuration where home agents different links. Figure 4 depicts the configuration where home
serving the same home network are located on the same link as defined agents serving the same home network are located on the same link as
in [RFC-3775]. defined in [RFC-3775].
HA1 HA2 HA3 HA4 .... HAn HA1 HA2 HA3 HA4 .... HAn
| | | | | | | | | |
--------+------+------+------+--------+--------- --------+------+------+------+--------+---------
Home Link Home Link
Figure 4: Local Recovery Configuration Figure 4: Local Recovery Configuration
Figure 5 illustrates when standby home agents are located on a Figure 5 illustrates when standby home agents are located on
different link (illustrated as Recovery Link in Figure 5). Most different links (illustrated as Recovery Link in Figure 5). Most
large operators have a very stringent requirement on network large operators have a very stringent requirement on network
availability even in the worst type of disaster or outage. This availability even in the worst type of disaster or outage. This
configuration can achieve home agent recovery even if the entire home configuration can achieve home agent recovery even if the entire home
link fails. This is called geographic redundancy and a well-known link fails. This is called geographic redundancy, and is a well-
configuration for Telecommunications operators. In Figure 5, home known configuration for Telecommunications operators. In Figure 5,
agents (HA1-HA4) are placed in geographically separated regions home agents (HA1-HA4) are placed in geographically separated regions
(region-1 and -2). If region-1 suffers a down time due to any (region-1 and region-2). If region-1 suffers down time for any
reason, all the sessions will be seamlessly taken over by the nodes reason, all the sessions will be seamlessly taken over by the nodes
in region-2. Note that HA3 and HA4 cannot receive packets meant for in region-2. Note that HA3 and HA4 cannot receive packets meant for
the home network until the route on the Routers is changed. The the home network until the route on the Routers is changed. The
routing must be also updated to direct the packets meant for the home routing must also be updated to direct the packets meant for the home
link to the recovery link. link to the recovery link.
---------IGP------>|<---BGP--->|<-----IGP--------- ---------IGP------>|<---BGP--->|<-----IGP---------
HA1 HA2 HA3 HA4 HA1 HA2 HA3 HA4
| | | | | | | |
--------+------+-----+ R---R---R +-----+------+------- --------+------+-----+ R---R---R +-----+------+-------
Home Link Routers Recovery Link Home Link Routers Recovery Link
(region-1) (region-2) (region-1) (region-2)
Figure 5: Global Recovery Configuration Figure 5: Global Recovery Configuration
3.2. Home Agent Address Configuration 3.2. Home Agent Address Configuration
In HARP, each home agent obtains its individual IPv6 address from its In HARP, each home agent obtains its individual IPv6 address from its
serving home prefix. In VHARP, all the home agents use a virtual serving home prefix. In VHARP, all the home agents use a virtual
home agent address generated from the home prefix. home agent address generated from the home prefix.
In addition, each home agent running VHARP needs to obtain its In addition, each home agent running VHARP needs to obtain its
individual IPv6 address from its attached link. This IPv6 address is individual IPv6 address from its attached link. This IPv6 address is
skipping to change at page 13, line 14 skipping to change at page 13, line 13
Figure 5: Global Recovery Configuration Figure 5: Global Recovery Configuration
3.2. Home Agent Address Configuration 3.2. Home Agent Address Configuration
In HARP, each home agent obtains its individual IPv6 address from its In HARP, each home agent obtains its individual IPv6 address from its
serving home prefix. In VHARP, all the home agents use a virtual serving home prefix. In VHARP, all the home agents use a virtual
home agent address generated from the home prefix. home agent address generated from the home prefix.
In addition, each home agent running VHARP needs to obtain its In addition, each home agent running VHARP needs to obtain its
individual IPv6 address from its attached link. This IPv6 address is individual IPv6 address from its attached link. This IPv6 address is
used only for the VHARP operations between home agents and is not used only for VHARP operations between home agents and is not
revealed to mobile nodes for binding registration. revealed to mobile nodes for binding registration.
All the home agents MUST join the ALL_HA_MULTICAST_ADDR. In VHARP, All the home agents MUST join the ALL_HA_MULTICAST_ADDR. In VHARP,
each home agent join the multicast group with its individual IPv6 each home agent joins the multicast group with its individual IPv6
address, but not with virtual home agent address. This multicast address, but not with the virtual home agent address. This multicast
address can be used to exchange the HA-HELLO message among the home address can be used to exchange HA-HELLO messages among the home
agents. On the other hand, if a home recovery link is separately agents. Alternatively, if a remote home recovery link is defined,
defined, each home agent always unicast the HARP messages to home each home agent unicasts the HARP messages to home agents configured
agents configured at a geographically separated link. at the remote recovery link.
4. Home Agent Operations 4. Home Agent Operations
4.1. Home Agent List Management 4.1. Home Agent List Management
In Mobile IPv6, each home agent periodically sends router In Mobile IPv6, each home agent periodically sends router
advertisements with the Home Address Information option [RFC-3775]. advertisements with the Home Address Information option [RFC-3775].
HARP introduces a HARP HA-HELLO message to replace the router HARP introduces a HARP HA-HELLO message to replace the router
advertisement. There are several reasons to use HA-HELLO message advertisement. There are several reasons to use HA-HELLO messages
instead of the Router Advertisement such as: instead of a Router Advertisement such as:
o A HA-HELLO message can be sent beyond the link, while a router o A HA-HELLO message can be sent beyond the link, while a router
advertisement cannot be sent beyond the link. In case of advertisement cannot. In case of geographic redundancy, Router
geographic redundancy, router advertisements cannot be sent to the Advertisements cannot be sent to the recovery link unless the home
recovery link unless the home link and the recovery link are link and the recovery link are virtually connected, for example,
virtually connected by L2TP, etc. by L2TP.
o A HA-HELLO message is defined to manage additional information o A HA-HELLO message is defined to manage additional information,
such as Group ID and Active/Standby Status of the home agents in such as Group ID and Active/Standby Status of the home agents in
the home agent list. the home agent list.
o A HA-HELLO message is exchange only between home agents, while a o A HA-HELLO message is exchanged only between home agents, while a
router advertisement is also processed by mobile nodes attached to Router Advertisement is also processed by mobile nodes attached to
a home link. A HA-HELLO does not introduce any burden to the a home link. A HA-HELLO does not introduce any burden to the
mobile nodes even if it is frequently sent on the home link. mobile nodes even if it is frequently sent on the home link.
When a HA-HELLO is used to exchange the home agent information, each When a HA-HELLO is used to exchange home agent information, each home
home agent SHOULD NOT process the Home Agent Information option agent SHOULD NOT process the Home Agent Information option carried by
carried by a Router Advertisement. A router advertisement is only a Router Advertisement. Router Advertisements are only processed by
processed by mobile nodes. Operators may define different mobile nodes. Operators may define different configuration values to
configuration values to the parameters of the home agent information the parameters of the home agent information for a HA-HELLO and a
for a HA-HELLO and a Router Advertisement. Router Advertisement.
This document requires additional information to the home agent list This document requires additional information to be added the
defined in [RFC-3775]. The additional information is learned through conceptual Home Agents list defined in [RFC-3775]. The additional
HA-HELLO message exchange. information is learned through HA-HELLO message exchange.
o Group ID of a redundant home agent set. It is learned through the o Group ID of a redundant home agent set. It is learned through the
Group ID field of the HA-HELLO. Group ID field of the HA-HELLO.
o HA-HELLO Interval. This value is locally configured at every home o HA-HELLO Interval. This value is locally configured at every home
agent by operators and is learned through the Hello Interval field agent by operators, and is learned through the Hello Interval
of the HA-HELLO. field of the HA-HELLO.
o An individual home agent address used in the VHARP operation. o Individual home agent addresses used in the VHARP operation. This
This information is only required when VHARP is used in addition information is only required when VHARP is used in addition to the
to the virtual home agent address. It is learned through the virtual home agent address. It is learned through the Source
Source Address of the HA-HELLO message. Address of the HA-HELLO message.
o VHARP capability. This information is learned through the V flag o VHARP capability. This information is learned through the V flag
of the HA-HELLO message. of the HA-HELLO message.
o Current mode (HARP or VHARP). This information is learned through o Current mode (HARP or VHARP). This information is learned through
the M flag of the HA-HELLO message. the M flag of the HA-HELLO message.
o Active status. This information is learned through the A flag of o Active status. This information is learned through the A flag of
the HA-HELLO message. the HA-HELLO message.
4.2. Detecting Home Agent Failure 4.2. Detecting Home Agent Failure
An active and standby home agents can monitor each other in several Active and standby home agents can monitor each other in several
ways. One method is to reuse other failure detection mechanisms ways. One method is to reuse other failure detection mechanisms
defined in VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. However, defined in VRRP [RFC-3768, RFC-5798] and HSRP [RFC-2281]. However,
VRRP and HSRP are not sufficient since they cannot detect the case VRRP and HSRP are not sufficient since they cannot detect the case
where the system is running but the Mobile IPv6 stack is not where the system is running, but the Mobile IPv6 stack is not
operational. Failure events used in HARP/VHARP are listed below. operational. Failure events used in HARP/VHARP are listed below.
Loss of HA-HELLO Loss of HA-HELLO
HARP/VHARP is an extension to Mobile IPv6 and can monitor HARP/VHARP is an extension to Mobile IPv6, and can monitor the
availability of Mobile IPv6 stack on each home agent by availability of Mobile IPv6 services on each home agent by
periodically sending a HA-HELLO as a heart-beat. This HA-HELLO periodically sending a HA-HELLO as a heart-beat. This HA-HELLO
can also be exchanged frequently enough to detect the failure can be exchanged frequently enough to detect a failure without any
promptly without any additional overhead to mobile nodes attached additional overhead to mobile nodes attached to the home link. In
to the home link. In the event that a standby home agent does not the event that a standby home agent does not receive any HA-HELLOs
receive any HA-HELLOs from its peer for a configurable duration, from its peer for a configurable duration of time, the standby
the standby home agent assumes that home agent's failure. The home agent assumes the peer home agent has failed. Details of the
detail of the Hello message is described in Section 4.3.2. Hello message are described in Section 4.3.2.
Monitored Server Failure by the Active Home Agent Monitored Server Failure by the Active Home Agent
There may be number of critical servers such as an AAA server in There may be a number of critical servers, such as an AAA, in the
the network that are essential for the ongoing Mobile IPv6 network that are essential for ongoing Mobile IPv6 sessions at the
sessions at the home agent. Operators can have a policy in place home agent. Operators can have a policy in place for which the
that the active home agent is treated as a failed home agent upon active home agent is treated as a failed home agent upon detecting
detecting that the link to such servers has failed. that the link to such servers has failed.
Routing Peer/Link Failure Routing Peer/Link Failure
Operators may require the home agent to detect its next-hop Operators may require the home agent to detect its next-hop
routing peer failure. If the next-hop routing failure is fatal in routing peer failure. If the next-hop routing failure is fatal in
nature, or due to some other routing policies, the active home nature, or due to some other routing policies, the active home
agent is treated as a failed home gent and the recovering agent is treated as a failed home agent and the recovery operation
operation should be started. should be started.
4.3. Processing the HARP Messages 4.3. Processing the HARP Messages
4.3.1. IP field and Security Descriptions of HARP message 4.3.1. IP field and Security Descriptions of HARP message
The HARP message format is defined in Section 6.1.1. If a HARP The HARP message format is defined in Section 6.1.1. If a HARP
message is unicast, the destination address is one of Home Agent in message is unicast, the destination address MUST be one of the Home
the same Redundant Home Agent set. If it is HA-HELLO message (by Agents in the same Redundant Home Agent set. If it is a HA-HELLO
setting the type field to 4), it can be multicast. The destination message, designated by setting the type field to 4, it can be
address MUST be set to ALL_HA_MULTICAST_ADDR. The source address multicast. The destination address MUST be set to the
MUST be set to the sender's home agent address. Note that, in VHARP, ALL_HA_MULTICAST_ADDR address. The source address MUST be set to the
the virtual home agent address SHOULD NOT be set to source or sender's home agent address. Note that in VHARP, the virtual home
destination address. The IP address of the interface the packet is agent address SHOULD NOT be set to the source or destination address.
being sent from SHOULD be used. Instead, the IP address of the interface the packet is being sent
from SHOULD be used.
If a HARP message is unicast, it SHOULD be secured by IPsec ESP. If If a HARP message is unicast, it SHOULD be secured by IPsec ESP. If
a HA-HELLO message is multicast, multicast extensions to IPsec [RFC- a HA-HELLO message is multicast, multicast extensions to IPsec [RFC-
5374] SHOULD be applied. If all the home agents are placed in a 5374] SHOULD be applied. If all the home agents are placed in a
secure transport network to exchange a HARP message, authentication secure transport network to exchange a HARP message, authentication
and encryption MAY be omitted. Which security verification is used and encryption MAY be omitted. Which security verification is used
depends on operational policy. If security verification is failed depends on operational policy. If security verification fails for a
for a receiving HA-HELLO, the HA-HELLO MUST be discarded. received HA-HELLO, the HA-HELLO MUST be discarded.
The following operations MUST be performed when transmitting a HARP The following operations MUST be performed when transmitting a HARP
message. message:
o The incremented latest Sequence Number MUST be set to the Sequence o The incremented latest Sequence Number MUST be set in the Sequence
Number field. The Sequence Number SHOULD be initialized to zero Number field. The Sequence Number SHOULD be initialized to zero
for the first Hello message. To accomplish sequence number for the first Hello message. To accomplish sequence number
rollover, if the sequence number has already been assigned to be rollover, if the sequence number has already been assigned to be
the largest possible number representable as a 16-bit unsigned the largest possible number representable as a 16-bit unsigned
integer, then when it is incremented it will then have a value of integer, then when it is incremented it will then have a value of
zero (0). zero (0).
o The sender's Group ID MUST be set to the Group ID field. o The sender's Group ID MUST be set in the Group ID field.
o The V-flag MUST be set if the sender is capable of VHARP. o The V-flag MUST be set if the sender is capable of VHARP.
o The M-flag MUST be unset if the sender is operated with HARP. o The M-flag MUST be unset if the sender is operating in HARP mode.
o The M-flag MUST be set if the sender is operated with VHARP. o The M-flag MUST be set if the sender is operating in VHARP mode.
o The A-flag MUST be set if the sender is the active home agent. o The A-flag MUST be set if the sender is the active home agent.
The following functions MUST be performed when a HARP message is The following functions MUST be performed when a HARP message is
received. received:
o MUST verify the Group ID of the HARP message is equal to the o The Group ID in the HARP message MUST match the receiver's Group
receiver's Group ID. ID.
o MUST verify the sender of the HARP message belongs to the o The source address of the HARP message MUST belong to a home agent
receiver's same redundant home agent set in the receiver's redundant home agent set.
o MUST verify that the M flag is equal to the receiver's operating o The M-flag MUST match the receiver's operating mode.
mode.
o MUST verify the Sequence Number value in the HARP is larger than o The Sequence Number value in the HARP message MUST be larger than
the last received Sequence Number value. When the sequence number the last received Sequence Number value. When the sequence number
rollover is occurred, the sequence number value in the HA-HELLO is rollover occurrs, the sequence number value in the HA-HELLO MUST
zero. be zero.
If any one of the above checks fails, the receiver SHOULD discard the If any one of the above checks fails, the receiver SHOULD discard the
HARP message. HARP message.
4.3.2. Processing Home Agent Hello (HA-HELLO) 4.3.2. Processing Home Agent Hello (HA-HELLO)
4.3.2.1. Sending HA-Hello Message 4.3.2.1. Sending HA-Hello Messages
Each home agent MUST send a HA-HELLO in following case: Each home agent MUST send a HA-HELLO in the following cases:
o UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO. o UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO.
The interval time is configured locally at each home agent. The time interval is configured locally at each home agent.
o UNSOLICITED: When a home agent detects its local information o UNSOLICITED: When a home agent detects its local information has
change, it should immediately send a HA-HELLO. changed it should immediately send a HA-HELLO.
o SOLICITED: when a home agent receives a HA-HELLO with the R-flag o SOLICITED: When a home agent receives a HA-HELLO with the R-flag
set, the HA-HELLO can be requested to the destination home agent. set, the HA-HELLO can be sent to the destination home agent.
A home agent can solicit a HA-HELLO to a particular home agent(s) in A home agent can solicit a HA-HELLO from a particular home agent(s)
the same redundant home agent set by unicasting or multicasting a HA- in the same redundant home agent set by unicasting or multicasting a
HELLO with the R-flag set. Soliciting HA-HELLO is operated when: HA- HELLO with the R-flag set. Soliciting a HA-HELLO happens when:
o A new home agent boots up. The new home agent SHOULD solicit HA- o A new home agent boots up. The new home agent SHOULD solicit HA-
Hello messages by multicasting a HA-Hello message with the R-flag Hello messages by multicasting a HA-Hello message with the R-flag
set. set to 1.
o A HA-HELLO has not been received after the specified hello o If a HA-HELLO has not been received after the specified Hello
interval. The HA-HELLO MAY be solicited to the home agent. Interval, a HA-HELLO MAY be solicited to the home agent.
o A home agent entry in the redundant home agent set is about to be o A home agent entry in the redundant home agent set is about to be
removed due to home agent lifetime expiration. The HA-HELLO removed due to home agent lifetime expiration. A HA-HELLO SHOULD
SHOULD be solicited to the home agent whose lifetime is soon be solicited from the home agent whose lifetime is soon expired.
expired.
In addition to Section 4.3.1, the following operations MUST be In addition to Section 4.3.1, the following operations MUST be
performed when transmitting a HA-HELLO. performed when transmitting a HA-HELLO.
o The Type field MUST be set to 4. o The Type field MUST be set to 4.
o The R-flag MUST be set if the sender solicits a HA-HELLO to the o The R-flag MUST be set if the sender is soliciting a HA-HELLO from
other home agent(s). the other home agent(s).
o The appropriate home agent configuration values MUST be copied to o The appropriate home agent configuration values MUST be copied to
the Home Agent Preference, the Home Agent Lifetime, and Hello the Home Agent Preference, the Home Agent Lifetime, and Hello
Interval fields. Interval fields.
4.3.2.2. Receiving Hello Message 4.3.2.2. Receiving Hello Messages
The receiver MUST perform the verification to the HA-HELLO described The receiver MUST perform the verification of the HA-HELLO described
in Section 4.3.1. After the verification, the receiver copies the in Section 4.3.1. After the verification, the receiver copies the
value stored in the HA-HELLO message to the corresponding home agent values stored in the HA-HELLO message to the corresponding home agent
list entry according to Section 4.1. list entry according to Section 4.1.
If the home agent lifetime field in the HA-HELLO is set to 0, the If the home agent lifetime field in the HA-HELLO is set to 0, the
receiver MUST remove the sender home agent from the home agents list. receiver MUST remove the sending home agent from the home agents
list.
If the R-flag is set in the received HA-HELLO, the receiver MUST send If the R-flag is set in the received HA-HELLO, the receiver MUST send
a new HA-HELLO to the originator as described in Section 4.3.2.1. a new HA-HELLO to the originator as described in Section 4.3.2.1.
4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP)
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 (SWO-REQ) to the standby home agent sends a SwitchOver Request (SWO-REQ) to the
current active home agent with the following operations. current active home agent in the following way:
o MUST be unicast only to the current active home agent o It MUST be unicast to only the current active home agent.
o MUST be sent from a standby home agent. The active home Agent o It MUST be sent from a standby home agent. The active home agent
MUST NOT generate this message. MUST NOT generate this message.
When an active home agent receives a SWO-REQ, it MUST operate the When an active home agent receives a SWO-REQ, it MUST do the
following verifications and operations in addition to Section 4.3.1 following verifications and operations, in addition to what is
described in Section 4.3.1
o If the receiver of the SWO-REQ is not an active home agent, it o If the receiver of the SWO-REQ is not an active home agent, it
MUST send a SWO-REP with the Status field set to 130 (Not active MUST send a SWO-REP with the Status field set to 130 (Not active
home agent). home agent).
o If the sender home agent does not belong to the same redundant o If the sending home agent does not belong to the same redundant
home agent set, a SWO-REP message MUST be sent to the sender with home agent set, a SWO-REP message MUST be sent to the sender with
the Status field set to 132 (Not in same redundant home agent the Status field set to 132 (Not in same redundant home agent
set). set).
o If there are any other reasons that the receiver cannot accept the o If there are any other reasons that the receiver cannot accept the
SWO-REP, the active home agent MUST reply a SWO-REP with the SWO-REP, the active home agent MUST reply a SWO-REP with the
Status field set to 129 (Administratively prohibited). Status field set to 129 (Administratively prohibited).
o Otherwise, the active home agent MUST become a standby home agent o Otherwise, the active home agent MUST become a standby home agent
and reply with a SWO-REP message with the Status field set to 0 and reply with a SWO-REP message with the Status field set to 0
(Success). (Success).
When a standby home agent receives a SWO-REP, it MUST operate the When a standby home agent receives a SWO-REP, it MUST do the
following verifications and operations in addition to Section 4.3.1: following verifications and operations, in addition to what is
described in Section 4.3.1:
o If the receiver is an active home agent, the SWO-REP MUST be o If the receiver is an active home agent, the SWO-REP MUST be
discarded. discarded.
o If the standby home agent receives an unexpected SWO-REP which is o If the standby home agent receives an unsolicited SWO-REP which is
not in reply to its SWO-REQ, it MUST ignore the SWO-REP. not in reply to an SWO-REQ it has sent, it MUST ignore the SWO-
REP.
o Otherwise, if the Status field of the SWO-REP is 0 (Success), the o Otherwise, if the Status field of the SWO-REP is 0 (Success), the
standby home agent (the receiver of SWO-REP) immediately becomes standby home agent (the receiver of the SWO-REP) immediately
an active home agent. becomes an active home agent.
o If the value in the Status field is greater than 128 an error has o If the value in the Status field is greater than 128, an error has
occurred. In this case, the receiver MUST NOT attempt to be an occurred. In this case, the receiver MUST NOT attempt to be an
active home agent. active home agent.
4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP)
When an active home agent decides to become a standby home agent, it When an active home agent decides to become a standby home agent, it
sends a SWB-REQ to one of standby home agents. The reason for the sends a SWB-REQ to one of the standby home agents. The reason for
active home agent to send this message can be administrative the active home agent sending this message might be due to an
intervention, and events like Monitored Server Failure by the active administrative intervention, or an event like Monitored Server
home agent or Routing Peer/Link Failure. The following operations Failure by the active home agent, or due to a Routing Peer/Link
MUST be performed when SWB-REQ is sent. Failure. The following operations MUST be performed when SWB-REQ is
sent:
o MUST be unicast only to one of standby home agents in the same o It MUST be unicast to only one of the standby home agents in the
redundant home agent set same redundant home agent set.
o MUST be sent from an active home agent. A standby home Agent MUST o It MUST be sent from an active home agent. A standby home Agent
NOT generate this message. MUST NOT generate this message.
When a home agent receives a SWB-REQ message, it verifies the message When a home agent receives a SWB-REQ message, it verifies the message
as follows. as follows:
o If the sender home agent of the SWB-REQ is not an active home o If the sending home agent of the SWB-REQ is not an active home
agent, the receiver MUST reply a SWB-REP with the Status field is agent, a SWB-REP MUST be sent in which the Status field is set to
set to 130 (Not active home agent). 130 (Not active home agent).
o If the sending home agent does not belong to the same redundant o If the sending home agent does not belong to the same redundant
home agent set, a SWB-REP MUST be sent in which the Status field home agent set, a SWB-REP MUST be sent in which the Status field
set to 132 (Not in same redundant home agent set). is set to 132 (Not in same redundant home agent set).
o Otherwise, the receiving home agent MUST send a SWB-REP with the o Otherwise, the receiving home agent MUST send a SWB-REP with the
Status field set to 0 (Success). Status field set to 0 (Success).
o After sending the SWB-REP, the standby home agent MUST NOT become o After sending the SWB-REP, the standby home agent MUST NOT become
an active home agent immediately. This is because the active home an active home agent immediately. This is because the active home
agent is still active until it receives the SWB-REP which is agent is still active until it receives the SWB-REP acknowledging
acknowledging the SWB-REQ. The standby home agent SHOULD change the SWB-REQ it sent. The standby home agent SHOULD change to
to active at least after LINK_TRAVERSAL_TIME. The default value active after LINK_TRAVERSAL_TIME. The default value of
of LINK_TRAVERSAL_TIME is defined in Section 9. LINK_TRAVERSAL_TIME is defined in Section 9.
When a home agent receives a SWB-REP message, it verifies the message When a home agent receives a SWB-REP message, it verifies the message
as follows. as follows:
o If the standby home agent receives an unexpected SWB-REP which is o If the standby home agent received an unsolicited SWB-REP not in
not in reply to own SWB-REQ, it SHOULD ignore the SWO-REP. reply to it's own SWB-REQ, it SHOULD ignore the SWO-REP.
o If the Status field of the SWB-REP is 0 (Success), the active home o If the Status field of the SWB-REP is 0 (Success), the active home
agent immediately becomes a standby home agent. The sender home agent should immediately become a standby home agent. The sending
agent of SWB-REP becomes an active home agent after certain time, home agent of SWB-REP becomes an active home agent after
LINK_TRAVERSAL_TIME. LINK_TRAVERSAL_TIME.
o If the value in the Status field is greater than 128, the receiver o If the value in the Status field is greater than 128, the receiver
of SWB-REP (active home agent) cannot become a standby home agent of the SWB-REP (active home agent) cannot become a standby home
and MUST continue to be an active home agent. agent and MUST continue to be an active home agent.
4.4. State Synchronization 4.4. State Synchronization
A State Synchronization (SS) message format is defined in The State Synchronization (SS) message format is defined in
Section 6.1.2. It can carry multiple aspects of the state Section 6.1.2. It can carry multiple aspects of the state
information associated with a mobile node by setting mobility options information associated with a mobile node by setting mobility options
in the Mobility Options field. The following list shows examples of in the Mobility Options field. The following list shows examples of
the mobility options which can be specified in the state the mobility options which can be specified in the state
synchronization message. synchronization message:
o IPv6 Home Address (Binding Cache Option) o IPv6 Home Address (Binding Cache Option)
o Binding Cache Information (Binding Cache Option) o Binding Cache Information (Binding Cache Option)
o NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC- o NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC-
3963]) 3963])
o IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555]) o IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555])
skipping to change at page 20, line 39 skipping to change at page 20, line 39
o Binding Identifier (Binding Identifier Option [RFC-5648] o Binding Identifier (Binding Identifier Option [RFC-5648]
o AAA states (AAA Information Option) o AAA states (AAA Information Option)
o Miscellaneous states (Vendor Specific Mobility Option [RFC-5094]) o Miscellaneous states (Vendor Specific Mobility Option [RFC-5094])
When a home agent needs to send the state of multiple mobile nodes in When a home agent needs to send the state of multiple mobile nodes in
a single state synchronization message (SS-REQ or SS-REP), a Binding a single state synchronization message (SS-REQ or SS-REP), a Binding
Cache Information option is used as a separator. For each mobile Cache Information option is used as a separator. For each mobile
node, a Binding Cache Information option is placed first, followed by node, a Binding Cache Information option is placed first, followed by
any other options related to the mobile node if necessary. any other options related to the mobile node, if necessary.
In HARP, since a mobile node will re-register to the new active home In HARP, since a mobile node will re-register to the new active home
agent after home agent fail-over, it is not necessary for the standby agent after a home agent failover, it is not necessary for the
home agents to synchronize all the mobile nodes' state information. standby home agents to synchronize all the mobile nodes' state
The standby home agent only need to collect the home address information. The standby home agents only need to collect the home
information of all the mobile nodes served by the active home agent. address information of all the mobile nodes served by the active home
The information is used to send the Home Agent Switch messages to all agent. The information is used to send Home Agent Switch messages to
the mobile node when the home agent failure is occurred. all the mobile nodes when a home agent failure occurs.
In the case of VHARP, home agent fail-over is accomplished without In the case of VHARP, home agent fail-over is accomplished without
the mobile nodes having to perform re-registration. Therefore, the mobile nodes having to perform re-registration. Therefore,
standby home agents need to copy the complete state information of standby home agents need to copy the complete state information of
each mobile node registered with the active home agent. each mobile node registered with the active home agent.
4.4.1. Binding Cache Information Management 4.4.1. Binding Cache Information Management
In HARP, each standby home agent learns the partial binding cache In HARP, each standby home agent learns the partial binding cache
information such as a pair of a home address and a mobile node's information such as a pair of a home address and a mobile node's
registering home agent address. registering home agent address.
In VHARP, a standby home agent ideally copies the received binding In VHARP, a standby home agent ideally copies the received binding
cache information and other mobile node's information into the cache information and other mobile node's information into the
appropriate database so that it can act as an active home agent as appropriate database so that it can act as an active home agent as
soon as it takes over the failed home agent. soon as it takes over the failed home agent.
4.4.2. IP field and Security Descriptions of SS message 4.4.2. IP field and Security Descriptions of State Synchronization
message
A state synchronization message is unicast. The destination address A state synchronization message is unicast. The destination address
MUST be one of home agents in the same Redundant Home Agent set. The MUST be one of the home agents in the same Redundant Home Agent set.
source address MUST be set to the sender's home agent address. Note The source address MUST be set to the sender's home agent address.
that, in VHARP, the virtual home agent address MUST NOT be set to the Note, that in VHARP, the virtual home agent address MUST NOT be set
source address. IP address of the interface the packet is being sent to the source address, the IP address of the interface the packet is
from SHOULD be used. being sent from SHOULD be used.
It SHOULD be secured by IPsec ESP. If all the home agents are placed The message SHOULD be secured by IPsec ESP. If all the home agents
in a secure transport network to exchange the state synchronization are placed in a secure transport network to exchange the state
message, authentication and encryption MAY be omitted. If security synchronization message, authentication and encryption MAY be
verification is failed for a receiving state synchronization message, omitted. If security verification fails for a received state
the message MUST be discarded. The choice of security mechanism used synchronization message, the message MUST be discarded. The choice
depends on the operational model of the network. of security mechanism used depends on the operational model of the
network.
4.4.3. Requesting State of Mobile Nodes (SS-REQ) 4.4.3. Requesting State of Mobile Nodes (SS-REQ)
When a home agent needs the state information for a particular mobile When a home agent needs the state information for a particular mobile
node or a subset of mobile nodes, it sends a SS-REQ message node, or a subset of mobile nodes, it sends a SS-REQ message
constructed as follows: constructed as follows:
o MUST set the Type field to 0 (Request). o It MUST set the Type field to 0 (Request).
o 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 MUST include a Binding Cache Information option(s) which Home o It MUST include a Binding Cache Information option(s) in which the
Address field is set to the target home address. Other fields of Home Address field is set to the target home address. Other
the Binding Cache Information option can be omitted. fields of the Binding Cache Information option can be omitted.
o MUST set the unspecified address (::) in the Home Address field of o If the request is for the state of all the mobile nodes registered
the Binding Cache Information option, if it solicits the state of at the destination home agent for the SS-REQ message, it MUST set
all the mobile nodes registering at the destination home agent of the Home Address field of the Binding Cache Information option to
the SS-REQ message. the unspecified address (::).
o MUST include multiple binding cache information options in a SS- o If the sender is requesting information about multiple mobile
REQ, if the sender requests multiple mobile nodes' information. nodes, it MUST include multiple binding cache information options
The sender SHOULD NOT send multiple SS-REQs per mobile node. in a single SS-REQ. The sender SHOULD NOT send multiple SS-REQs
per mobile node.
o MUST send a SS-REQ to the active home agent of the target mobile o It MUST send a SS-REQ to the active home agent of the target
node(s). mobile node(s).
When a home agent receives a SS-REQ, it MUST perform the verification When a home agent receives a SS-REQ, it MUST perform the verification
described in Section 4.4.2 and following: described in Section 4.4.2 and the following:
o If the receiver does not know the binding cache for the target o If the receiver does not have binding cache information for the
mobile node(s) specified in the received Binding Cache Information target mobile node(s) specified in the received Binding Cache
option(s), it MUST ignore the SS-REQ and MUST NOT reply a SS-REQ. Information option(s), it MUST ignore the SS-REQ and MUST NOT
reply with a SS-REQ.
o Otherwise, the receiver MUST reply a SS-REP including all the o Otherwise, the receiver MUST reply with a SS-REP, including all
state information of the target mobile node(s). the state information of the target mobile node(s).
4.4.4. Sending State Information (SS-REP) 4.4.4. Sending State Information (SS-REP)
A SS-REP message(s) SHOULD be sent when: An SS-REP message(s) SHOULD be sent when:
1. The active home agent receives a SS-REQ. 1. The active home agent receives an SS-REQ.
2. The active home agent creates or deletes a binding cache entry 2. The active home agent creates or deletes a binding cache entry
for a particular mobile node. for a particular mobile node.
The active home agent MAY additionally send a SS-REP message in The active home agent MAY additionally send an SS-REP message in the
following cases: following cases:
1. The active home agent updates the state information for all 1. The active home agent updates the state information for all
sessions that changed since the last update in a periodic sessions that have changed since the last update in a periodic
interval interval.
2. Often in VHARP, the active home agent MAY update a binding cache 2. Often in VHARP, the active home agent MAY update a binding cache
entry for a particular mobile node whenever the binding cache entry for a particular mobile node whenever the binding cache
entry is updated. If an active home agent sends a SS-REP message entry is updated. If an active home agent sends an SS-REP
whenever the local state information changes, such as a binding message whenever the local state information changes, such as a
cache change, the number of the SS-REP messages can be quite binding cache change, the number of the SS-REP messages can be
large. quite large.
Following rules must be applied when the active home agent constructs The following rules must be applied when the active home agent
a SS-REP. constructs a SS-REP:
o MUST copy the Identifier field of the SS-REQ to the same field of o It MUST copy the Identifier field of the SS-REQ to the same field
the SS-REP, if the SS-REP is sent in response to the SS-REQ. of the SS-REP, if the SS-REP is sent in response to the SS-REQ.
o MUST set zero to the Identifier field if the SS-REP is sent o It MUST set the Identifier field to zero (0) if the SS-REP is sent
without solicitation (no SS-REQ). without solicitation (no SS-REQ).
o MUST include required mobility options in the SS-REP. o It MUST include the required mobility options in the SS-REP.
* In HARP, a partial Binding Cache Information Option (the Home * In HARP, a partial Binding Cache Information option (the Home
Address Field only) MUST be included in the SS-REP. Address Field only) MUST be included in the SS-REP.
* In VHARP, a full Binding Cache Information Option and other * In VHARP, a full Binding Cache Information option, and other
required options shown in Section 6.1.2 MUST be included in the required options shown in Section 6.1.2, MUST be included in
SS-REP. the SS-REP.
o MUST include the state of all the active mobile nodes registering o It MUST include the state of all the active mobile nodes
in the active home agent by the SS-REP when the unspecified registered at the active home agent in the SS-REP when the
address is found in the Home Address mobility option carried with unspecified address is found in the Home Address mobility option
the SS-REQ. The message may be fragmented depending on the total carried with the SS-REQ. The message may be fragmented depending
size needed to carry all states. on the total size needed to carry all states.
4.4.5. Synchronizing State (SS-REP and SS-ACK) 4.4.5. Synchronizing State (SS-REP and SS-ACK)
When a home agent receives a SS-REP, it MUST take the following When a home agent receives a SS-REP, it MUST take the following
operations. operations:
o If no options are carried in the SS-REP, the home agent just o If no options are carried in the SS-REP, the home agent MUST
ignores the SS-REP. ignore the SS-REP.
o If the sender of SS-REP is not in the same global home agent set, o If the sender of SS-REP is not in the same global home agent set,
the home agent MUST reject the SS-REP and MUST send SS-ACK with the home agent MUST reject the SS-REP and MUST send SS-ACK with
the Status Synchronization Status option which status value is set the Status Synchronization Status option in which status value is
to [130: Not in same global home agent set] set to [130: Not in same global home agent set]
o The receiver home agent MUST record the IPv6 address of the sender o The receiver MUST record the IPv6 address of the sender as the
as the active home agent of the mobile node in its local binding active home agent of the mobile node in its local binding cache.
cache.
o The receiver home agent MUST update its binding cache and all o The receiver MUST update its binding cache, and all other
other necessary information in a particular database(s). necessary information, in its database(s).
o The receiver home agent MUST send a SS-ACK with state o If the A-flag is set in the SS-REP, the receiver MUST reply with
synchronization status mobility options if A flag is set. an SS-ACK.
If an active home agent requires an acknowledgment of a SS-REP, it If an active home agent requires an acknowledgment of a SS-REP, it
MUST set the Ack flag in the SS-REP. The receiver of such SS-REP MUST set the A-flag (Ack) in the SS-REP. The receiver of the SS-REP
will send back a SS-ACK. The receiver MUST copy the Identifier value will send back an SS-ACK. The receiver MUST copy the Identifier
received in the SS-REP into SS-ACK in order to match the SS-REP and value received in the SS-REP into the SS-ACK in order to match the
SS-ACK. SS-REP and SS-ACK.
4.5. Switching the Active Home Agent 4.5. Switching the Active Home Agent
In HARP, the standby home agent which is going to be active MUST send In HARP, the standby home agent which is going to be active MUST send
a Home Agent Switch message [RFC-5142] to all the mobile nodes that a Home Agent Switch message [RFC-5142] to all the mobile nodes that
were being served by the failed home agent. The following rules MUST were being served by the failed home agent. The following rules MUST
be applied when transmitting a Home Agent Switch message. be applied when transmitting a Home Agent Switch message.
o MUST use IPsec ESP to protect the Home Agent Switch message. o MUST use IPsec ESP to protect the Home Agent Switch message.
o MUST set the address of the standby home agent address who is the o MUST set the address of the standby home agent address who is the
sender of this Home Agent Switch message in the Home Agent Address sender of this Home Agent Switch message in the Home Agent Address
field of the Home Agent Switch message [RFC-5142]. field of the Home Agent Switch message [RFC-5142].
If there are a large number of mobile nodes served by the failed home If there are a large number of mobile nodes served by the failed home
agent, the overhead sending Home Agent Switch messages is high. This agent, the overhead of sending Home Agent Switch messages is high.
overhead cannot be avoided if the active home agent suddenly stop This overhead cannot be avoided if the active home agent suddenly
serving mobile node because of unexpected reasons (crash, network stopped serving mobile nodes due to an unexpected reason (crash,
trouble, etc). However, if this switch over is operated under the network trouble, etc). However, if this switch-over is an
administrative operation (maintenance, etc), the previous active home administrative operation (maintenance, etc), the previous active home
agent may continue serving the mobile nodes until the switch over is agent may continue serving the mobile nodes until the switch-over is
completed. Until the mobile node sends a binding update to the new complete. Until the mobile node sends a binding update to the new
active home agent, it still sends the packet to the previous home active home agent, it still sends packets to the previous home agent.
agent.
Therefore, the new active home agent can notify the completion of When the new active home agent completes the switch-over, it SHOULD
switch-over to the previous active home agent by using a SW-COMP send a SW-COMP to the previous active home agent. Until the previous
message. When the new active home agent completes the switch-over, home agent receives this message, it SHOULD continue serving any
it SHOULD send a SW-COMP to the previous active home agent. Until mobile nodes that are registered with it. Once the previous home
the previous home agent receives this message, it SHOULD continue agent receives the SW-COMP message, it can be shutdown or detached
serving any mobile nodes that are registered with it. Once the from the network safely.
previous home agent receives the SW-COMP message, it can be shutdown
or detached from the network safely.
In VHARP, after detecting the active home agent has failed, the In VHARP, after detecting the active home agent has failed, the
standby home agent whose preference value is the highest MUST take standby home agent whose preference value is the highest MUST take
over the failed home agent. The standby home agent MUST activate the over for the failed home agent. The standby home agent MUST activate
virtual home agent address and its virtual MAC address. A virtual the virtual home agent address and its virtual MAC address. A
MAC address as introduced in [RFC-3768, RFC-5798] SHOULD be used in virtual MAC address as introduced in [RFC-3768, RFC-5798] SHOULD be
VHARP. If VHARP run with VRRP and HSRP as described in Section 4.7, used in VHARP. If VHARP is run with VRRP and HSRP as described in
the virtual home agent address can be treated as a virtual router Section 4.7, the virtual home agent address can be treated as a
address in VRRP and HSRP. Therefore, VRRP and HSRP can automatically virtual router address in VRRP and HSRP. Therefore, VRRP and HSRP
activate the virtual home agent address on the standby home agent can automatically activate the virtual home agent address on the
after their election mechanism. Since all the necessary state has standby home agent after their election mechanism has completed.
already been transferred to this standby home agent before the active Since all the necessary state has already been transferred to this
home agent failed, it can immediately start acting as the active home standby home agent before the active home agent failed, it can
agent. immediately start acting as the active home agent.
When the failed home agent recovers from failure and would return to When the failed home agent is restarted and wants to become the
the active home agent, it MUST re-establish IPsec SA with all the active home agent again, it MUST re-establish an IPsec SA with each
mobile nodes. All the mobile nodes lost IPsec SA with the home agent mobile node, as all the mobile nodes will have purged their IPsec SA
when the failure has occurred. Otherwise, it cannot be either a with the home agent when the failure occurred. Otherwise, it cannot
standby or active home agent for the mobile nodes. Therefore, as be a standby or active home agent for the mobile nodes. Therefore,
soon as the active home agent detects the recovery of the failed home as soon as the active home agent detects the recovery of the failed
agent, it sends a Home Agent Rekey message to all the mobile nodes home agent, it sends a Home Agent Rekey message to all the mobile
served by other home agents in the same redundant home agent set, and nodes served by other home agents in the same redundant home agent
includes the recovered home agent address in the Home Agent Addresses set, and includes the recovered home agent address in the Home Agent
field. The detail of the Home Agent Rekey message is described in Addresses field. The detail of the Home Agent Rekey message is
Section 6.1.3. The mobile node will re-key the SA by using The IKEv2 described in Section 6.1.3. The mobile node will re-key the SA by
resumption mechanism [RFC-5723]. Alternatively, the mobile node MAY using The IKEv2 resumption mechanism [RFC-5723]. Alternatively, the
start a new IKE session with the recovered home agent. mobile node MAY start a new IKE session with the recovered home
agent.
4.6. Consideration of Routing and Neighbor Discovery Protocol (VHARP) 4.6. Consideration of Routing and Neighbor Discovery Protocol (VHARP)
This section gives a brief explanation of how a home agent interacts This section gives a brief explanation of how a home agent interacts
with routing and Neighbor Discovery Protocol (NDP) when is VHARP with routing and Neighbor Discovery when VHARP is used.
used.
When a standby home agent becomes active in VHARP, it MUST start to When a standby home agent becomes active in VHARP, it MUST start to
advertise the home agent address and the home prefix of the home advertise the home agent address, and the home prefix of the home
addresses serviced by the redundant home agent set into the routing addresses serviced by the redundant home agent set, into the routing
infrastructure. This operation is normally done using a route infrastructure. This operation is normally done using a route
selector such as BGP or an OSPF modifier. For example, we can use selector such as BGP, or an OSPF modifier. For example, we can use
the AS_Path prepend operation for BGP, and the Metric field in OSPF the AS_Path prepend operation for BGP, and the Metric field in OSPF
for the route selection. When each home agent participates in OSPF for the route selection. When each home agent participates in OSPF
routing, each home agent should be configured with the appropriate routing, each home agent should be configured with the appropriate
metric matched to the home agent preference value. When the active metric matched to the home agent preference value. When the active
home agent fails, OSPF detects the failure and can dynamically switch home agent fails, OSPF detects the failure and can dynamically switch
the route to the standby home Agent based on the OSPF cost value. If the route to the standby home Agent based on the OSPF cost value. If
this creates conflicts with the home agent preference value due to this creates conflicts with the home agent preference value due to
configuration errors, the routers on the home link may not route configuration errors, the routers on the home link may not route
packets to the desired standby home agent. In order to change the packets to the desired standby home agent. In order to change the
OSPF cost correctly and dynamically, The operator takes other OSPF cost correctly and dynamically, the operator would use its
existing approaches. For example, most of router vendors have a existing approaches. For example, most router vendors have a private
private MIB to set the cost via SNMP, though this is a vendor- MIB to set the OSPF cost via SNMP, though this is a vendor- specific
specific function. function.
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 [RFC-3768, RFC-5798]. use a virtual MAC address as introduced in [RFC-3768, RFC-5798].
When the active home agent is changed, the neighbor cache of the When the active home agent is changed, the neighbor cache of the
active home agent is not necessarily updated on mobile nodes located active home agent is not necessarily updated on mobile nodes located
on the home link. Otherwise, the new home agent MUST update the on the home link. Otherwise, the new home agent MUST update the
neighbor cache entry for the home agent address on all the mobile neighbor cache entry for the home agent address on all the mobile
nodes located on the home link. In addition, Mobile IPv6 uses proxy nodes located on the home link. In addition, Mobile IPv6 uses proxy
NDP to intercept packets meant for mobile nodes which are away from Neighbour Discovery to intercept packets meant for mobile nodes which
the home link. However, it is unnecessary for the new active home are away from the home link. However, it is unnecessary for the new
agent to overwrite the existing proxy neighbor entries of the mobile active home agent to overwrite the existing proxy neighbor entries of
nodes. the mobile nodes.
4.7. Interworking with VRRP 4.7. 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 VHARP. For example, the VRRP LAN. This operation is similar to VHARP. For example, the VRRP
router controlling the IP address(es) associated with a virtual router controlling the IP address(es) associated with a virtual
router is called the Master, and forwards packets sent to these IP router is called the Master, and forwards packets sent to these IP
addresses. The election process provides dynamic fail over in the addresses. The election process provides dynamic failover in the
forwarding responsibility should the Master become unavailable. forwarding responsibility should the Master become unavailable.
Although VRRP is used to guarantee home agent address reachability, Although VRRP is used to guarantee home agent address reachability,
it cannot be used for state synchronization and explicit switching of it cannot be used for state synchronization and explicit switching of
Master and Backup. Thus, the Home Agent Reliability Protocol cannot Master and Backup. Thus, the Home Agent Reliability Protocol cannot
be replaced by VRRP. This section explains how VRRP can interwork be replaced by VRRP. This section explains how VRRP can interwork
with HARP/VHARP. with HARP/VHARP.
When VRRP is available, VRRP can replace the Hello message described When VRRP is available, VRRP can replace the Hello message described
in Section 6.1.1. However, some of information is missed by using in Section 6.1.1. However, some information is missing by using just
VRRP. After receiving a VRRP message, each home agent SHOULD process VRRP. After receiving a VRRP message, each home agent SHOULD process
the message and store the information as if it receives Home Agent the message and store the information as if it had received a Home
Hello messages Section 4.3.2.2. The message format of VRRP can be Agent Hello message, as described in Section 4.3.2.2. The message
found in Section 5.1 of [RFC-5798]. Each field is mapped as follows: format of VRRP can be found in Section 5.1 of [RFC-5798]. Each field
is mapped as follows:
o Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field. o Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field.
o Priority: Home Agent Preference is stored in the Priority field. o Priority: Home Agent Preference is stored in the Priority field.
Note that VRRP only has 8 bits for the Priority field. Therefore, Note that VRRP only has 8 bits for the Priority field. Therefore,
values larger than 255 MUST NOT be assigned to the preference values larger than 255 MUST NOT be assigned to the preference
value. value.
o Count IPv6 IPv6 Addr: This field MUST be always be 1. o Count IPv6 IPv6 Addr: This field MUST be always be 1.
o Max Advert Int: This field MUST be mapped to the Hello Interval o Max Advert Int: This field MUST be mapped to the Hello Interval
field of the Home Agent Hello message, though it only has 12 field of the Home Agent Hello message, though it only has 12
bytes. bytes.
o IPv6 address: A home agent address is stored in this field. o IPv6 address: A home agent address is stored in this field.
Home Agent Lifetime, Sequence Number and Flags field are missed in Home Agent Lifetime, Sequence Number and Flags fields are not present
the VRRP packet format. Therefore, operators SHOULD use the same in the VRRP packet format. Therefore, operators SHOULD use the same
statically configured value for Home Agent Lifetime. Each home agent statically configured value for Home Agent Lifetime. Each home agent
does not check freshness of received VRRP message because of no does not check the freshness of received VRRP message because there
sequence number. is no sequence number.
4.8. Retransmissions and Rate Limiting 4.8. Retransmissions and Rate Limiting
Home agents are responsible for retransmissions and rate limiting of Home agents are responsible for retransmissions and rate limiting of
SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response. SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response.
The home agent MUST determine a value for the initial transmission The home agent MUST determine a value for the initial transmission
timer: timer:
o If the home agent sends a SS-REQ message, it SHOULD use an initial o If the home agent sends a SS-REQ message, it SHOULD use an initial
retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.
o If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use o If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use
an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER. an initial retransmission interval of INITIAL_SWITCH_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
skipping to change at page 27, line 30 skipping to change at page 27, line 32
MAC_HARELIABILITY_TIMEOUT. The home agent SHOULD use a separate MAC_HARELIABILITY_TIMEOUT. The home agent SHOULD use a separate
back-off process for different message types and different back-off process for different message types and different
destinations. The rate limiting of Mobility Header messages is the destinations. The rate limiting of Mobility Header messages is the
same as one in [RFC-3775]. A home agent MUST NOT send Mobility same as one in [RFC-3775]. A home agent MUST NOT send Mobility
Header Messages to a particular home agent more than MAX_UPDATE_RATE Header Messages to a particular home agent more than MAX_UPDATE_RATE
(3) times a second, which is specified in [RFC-3775]. (3) times a second, which is specified in [RFC-3775].
5. Mobile Node Operation 5. Mobile Node Operation
This section describes the operations of a mobile node only when HARP This section describes the operations of a mobile node only when HARP
is used. None of the operations in this section is required in is used. None of the operations in this section are required with
VHARP. VHARP.
5.1. Home Agent Addresses Discovery 5.1. Home Agent Addresses Discovery
A mobile node authenticates itself to two or more home agents and A mobile node authenticates itself to two or more home agents and
creates IPsec SAs with them during bootstrapping. When the active creates IPsec SAs with them during bootstrapping. When the active
home agent fails, another home agent can use the pre-existing SA to home agent fails, another home agent can use the pre-existing SA to
notify the mobile node about the failure by sending a Home Agent notify the mobile node about the failure by sending a Home Agent
Switch message. Switch message.
skipping to change at page 28, line 5 skipping to change at page 28, line 6
mechanisms are defined in the bootstrapping solution in the split mechanisms are defined in the bootstrapping solution in the split
scenario [RFC-5026]. One is DNS lookup by home agent Name, the other scenario [RFC-5026]. One is DNS lookup by home agent Name, the other
is DNS lookup by Service Name. DHCPv6 can also be used in the is DNS lookup by Service Name. DHCPv6 can also be used in the
integrated scenario [ID-BOOTINT] to provide home agent provisioning integrated scenario [ID-BOOTINT] to provide home agent provisioning
to mobile nodes. to mobile nodes.
In the split scenario, a mobile node can use DNS lookup by Service In the split scenario, a mobile node can use DNS lookup by Service
Name to discover the home agents, as defined in [RFC-5026]. For Name to discover the home agents, as defined in [RFC-5026]. For
example, if home agent reliability is required by a mobile node, DNS example, if home agent reliability is required by a mobile node, DNS
lookup by Service Name method is recommended for the mobile node to lookup by Service Name method is recommended for the mobile node to
discover multiple home agents addresses. Therefore, mobile nodes discover multiple home agent addresses. Therefore, mobile nodes will
will query the DNS SRV records with a service name of mip6 and query the DNS SRV records with a service name of mip6 and protocol
protocol name of ipv6. The DNS SRV records includes multiple home name of ipv6. The DNS SRV records includes multiple home agent
agent addresses and different preference values and weights. The addresses and different preference values and weights. The mobile
mobile node SHOULD choose two or more home agents from the home node SHOULD choose two or more home agents from the home agents list
agents list according to their preference value. Then the mobile according to their preference value. Then the mobile node should
node should authenticate itself to these home agents via an IKEv2 authenticate itself to these home agents via an IKEv2 exchange.
exchange.
In the integrated scenario, a mobile node can use DHCPv6 to get home In the integrated scenario, a mobile node can use DHCPv6 to get home
agent provisioning from an MSP or ASP, as already defined in [ID- agent provisioning from an MSP or ASP, as already defined in [ID-
BOOTINT]. The only requirement is that the DHCPv6 response must BOOTINT]. The only requirement is that the DHCPv6 response must
include multiple home agents' information in order to support home include multiple home agents' information in order to support home
agent reliability. agent reliability.
5.2. IPsec/IKE Establishment to Home Agents 5.2. IPsec/IKE Establishment to Home Agents
In this document, a mobile node need to manage an IPsec SA with a In this document, a mobile node needs to manage an IPsec SA with a
home agent(s). The following mechanism can be used to manage the home agent(s). The following mechanisms can be used to manage the
IPsec SA(s) with a home agent(s). IPsec SA(s) with a home agent(s):
o IKEv1/v2 running per home agent (HARP) to establish multiple IPsec o IKEv1/v2 running per home agent (HARP) to establish multiple IPsec
SAs for home agents. SAs for home agents.
o The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA o The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA
with the new home agent (VHARP) with the new home agent (VHARP)
If IPsec/IKEv2 state synchronization mechanism is available in If an IPsec/IKEv2 state synchronization mechanism is available in
Virtual Private Network (VPN) products, none of above is required for Virtual Private Network (VPN) products, none of above is required for
the VHARP operation. The IPsec SAs per mobile node are seamlessly the VHARP operation. The IPsec SAs per mobile node are seamlessly
copied among multiple home agents. copied among multiple home agents.
The mobile node MUST follow the standard IKEv2 exchange in the The mobile node MUST follow the standard IKEv2 exchange in the
bootstrapping solution of the split scenario [RFC-5026]. If multiple bootstrapping solution of the split scenario [RFC-5026]. If multiple
IKEv2 are run per home agent, the mobile node MUST NOT attempt the IKEv2 operations are run per home agent, the mobile node MUST NOT
home address assignment to standby home agents. attempt the home address assignment to standby home agents.
5.3. Synchronizing State: K-bit treatment 5.3. Synchronizing State: K-bit treatment
When a mobile node moves and the care-of address changes, it can use When a mobile node moves and the care-of address changes, it can use
the Key Management Mobility Capability (K) bit in the Binding Update the Key Management Mobility Capability (K) bit in the Binding Update
in order to update the peer endpoint of the key management protocol in order to update the peer endpoint of the key management protocol,
(ex. IKE Security Association). for example, the IKE Security Association.
If an active home agent receives a Binding Update which K-bit is set, If an active home agent receives a Binding Update with the K-bit set,
it MUST process the Binding Update as [RFC-3775]. In addition, the it MUST process the Binding Update as specified in [RFC-3775]. In
active home agent MUST notify the care-of address change to the other addition, the active home agent MUST notify the other standby home
standby home agents. For doing so, it MUST send State agents of the care-of address change. To do so, it MUST send a State
Synchronization Reply message including Binding Cache Information Synchronization Reply message, including a Binding Cache Information
option to all the other standby home agents. The flags of the option, to all the other standby home agents. The flags of the
Binding Update (ex. K-bit) MUST be copied to the flags field of the Binding Update MUST be copied to the flags field of the Binding Cache
Binding Cache Information option. After all, the standby home agents Information option. The standby home agents will update the peer
know the existence of K-bit set in the Flag field of the Binding endpoint of the key management protocol upon detecting the K-bit it
Cache Information option and update the peer endpoint of the key set in the Flag field of the Binding Cache Information option.
management protocol.
If the K-bit is not set in the Binding Update, an active home agent If the K-bit is not set in the Binding Update, an active home agent
needs to rerun the key management protocol. The active home agent needs to rerun the key management protocol. The active home agent
MUST send State Synchronization Reply message including Binding Cache MUST send State Synchronization Reply messages, including Binding
Information option to all the other standby home agents. K-bit is Cache Information options, to all the other standby home agents. The
unset in the flags field of the Binding Cache Information option. flags of the Binding Update MUST be copied to the flags field of the
The receivers of the State Synchronization Reply message (i.e. Binding Cache Information option. The standby home agents that
standby home agents) detect the care-of address change and rerun the receive the State Synchronization Reply message will detect the
key management protocol. care-of address change and rerun the key management protocol.
5.4. Receiving Home Agent Switch message 5.4. Receiving Home Agent Switch message
A mobile node must follow the verification and operations specified A mobile node must follow the verification and operations specified
in [RFC-5142] when it receives a Home Agent Switch message. in [RFC-5142] when it receives a Home Agent Switch message.
The Home Agent Switch message MUST be securely exchanged between a The Home Agent Switch message MUST be securely exchanged between a
mobile node and a home agent by IPsec ESP. mobile node and a home agent by using IPsec ESP.
When the mobile node receives a Home Agent Switch message, and if the When the mobile node receives a Home Agent Switch message, if the
message contains the IPv6 address of a standby home agent, it MUST message contains the IPv6 address of a standby home agent, it MUST
select the standby home agent as its active home agent and MUST send select the standby home agent as its active home agent and MUST send
a new Binding Update message to it. a new Binding Update message to it.
The standby home agent address in the Home Agent Switch message MUST The standby home agent address in the Home Agent Switch message MUST
be equal to the sender of the Home Agent Switch message. If the IPv6 be equal to the sender of the Home Agent Switch message. If the IPv6
address stored in the Home agent address field is different from the address stored in the Home Agent address field is different from the
sender's source IPv6 address, the mobile node MUST send a binding sender's source IPv6 address, the mobile node MUST send a binding
update to the sender and MUST NOT use the IPv6 address in the Home update to the sender and MUST NOT use the IPv6 address in the Home
Agent Switch message. Agent Switch message.
6. Messages Format 6. Messages Format
6.1. New Mobility Header Messages 6.1. New Mobility Header Messages
6.1.1. HARP Message Format 6.1.1. HARP Message Format
The HARP message has the type field to identify different roles. The The HARP message has the type field to identify different roles. The
HARP message has the MH Type value TBD. HARP message has the MH Type value TBD.
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 | Group ID | | Type | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |A|R|V|M|Rsvd | Status | | Sequence # |A|R|V|M| Rsvd | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime | | Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | | | Hello Interval | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. Mobility Options . . Mobility Options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Home Agent Hello Message Figure 6: Home Agent Hello Message
Type Type
8-bit unsigned integer. It can be assigned one of the following 8-bit unsigned integer. It can be assigned one of the following
values: values:
0: SwitchOver Request (SWO-REQ) 0: SwitchOver Request (SWO-REQ)
It is unicast by a standby home agent that desires to become Unicast by a standby home agent that desires to become the
the active home agent. The receiver of the message MUST active home agent. The receiver of the message MUST transition
transition to standby state as soon as the message is received to standby state as soon as the message is received and
and validated successfully. validated successfully.
1: SwitchOver Reply (SWO-REP) 1: SwitchOver Reply (SWO-REP)
It is used to acknowledge the receipt of the corresponding SWO- Used to acknowledge the receipt of the corresponding SWO-REQ.
REQ.
2: SwitchBack Request (SWB-REQ) 2: SwitchBack Request (SWB-REQ)
It is unicast by an active home agent that desires to become a Unicast by an active home agent that desires to become a
standby home agent. The receiver of this message SHOULD standby home agent. The receiver of this message SHOULD
transition to active state as soon as the message is received transition to active state as soon as the message is received
and validated successfully. and validated successfully.
3: SwitchBack Reply (SWB-REP) 3: SwitchBack Reply (SWB-REP)
It is used to acknowledge the receipt of the corresponding SWB-
REQ. Used to acknowledge the receipt of the corresponding SWB-REQ.
4: Switch Complete (SW-COMP) 4: Switch Complete (SW-COMP)
This message is used to indicate the completion of switch over, Used to indicate the completion of a switch-over, (i.e. sending
(i.e. sending home agent switch messages and receiving binding Home Agent Switch messages, and receiving binding update
update messages from all the served mobile nodes). messages from all the served mobile nodes).
4: Home Agent HELLO (HA-HELLO) 4: Home Agent HELLO (HA-HELLO)
It MUST be either unicast or multicast to carry home agent Used to carry home agent information among the redundant home
information among the redundant home agent set. The HA-Hello agent set. MUST be either unicast or multicast. The HA-Hello
message is defined for two purpose: 1) an alive check and 2) message is defined for two purpose: 1) an alive check and 2)
home agent information exchange. home agent information exchange.
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.
Sequence # Sequence #
skipping to change at page 32, line 16 skipping to change at page 32, line 13
operates HARP. (HARP:0, VHARP:1) operates HARP. (HARP:0, VHARP:1)
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Status Status
8-bit unsigned integer indicating the disposition of a SWO-REQ or 8-bit unsigned integer indicating the disposition of a SWO-REQ or
SWB-REQ. This field is only valid in SWO-REP and SWB-REP. The SWB-REQ. This field is only valid in SWO-REP and SWB-REP
following Status values are defined: messages. The following Status values are defined:
0: Success 0: Success
128: Reason unspecified 128: Reason unspecified
129: Administratively prohibited 129: Administratively prohibited
130: Not active home agent (The receiver of SWO-REQ is not the 130: Not active home agent (The receiver of SWO-REQ is not the
active home agent) active home agent)
skipping to change at page 33, line 4 skipping to change at page 32, line 46
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
the HA-Hello message. This lifetime is the same as the Home Agent the HA-Hello message. This lifetime is the same as the Home Agent
Lifetime value of the Home Agent Information option as defined in Lifetime value of the Home Agent Information option as defined in
[RFC-3775]. [RFC-3775].
Hello Interval Hello Interval
16-bit unsigned integer. The interval for the home agent sending 16-bit unsigned integer. The interval for the home agent sending
this Hello message. this Hello message.
Mobility Options Mobility Options
No valid options are defined in this specification. Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [RFC-3775]. The
receiver MUST ignore and skip any options which it does not
understand. This specification does not define any options valid
for the HARP message.
6.1.2. State Synchronization Message Format 6.1.2. State Synchronization Message Format
This message is used to exchange state corresponding to a particular This message is used to exchange state corresponding to a particular
mobile node(s). It MUST be unicast and MUST be authenticated by mobile node(s). It MUST be unicast and MUST be authenticated by
IPsec ESP. This message has the MH Type value TBD. IPsec ESP. This message has the MH Type value TBD.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 39 skipping to change at page 33, line 43
Figure 7: State Synchronization Message Figure 7: State Synchronization Message
Type Type
8-bit unsigned integer. It can be assigned one of the following 8-bit unsigned integer. It can be assigned one of the following
values: values:
0: State Synchronization Request (SS-REQ) 0: State Synchronization Request (SS-REQ)
It is used to solicit the active state corresponding to a Used to solicit the active state corresponding to a particular
particular mobile node. mobile node.
1: State Synchronization Reply (SS-REP) 1: State Synchronization Reply (SS-REP)
Used between the home agents in the redundant home agent set to
It is used between the home agents in the redundant home agent exchange binding cache and any other information related to
set to exchange binding cache information and any other providing mobility service to the mobile nodes. Sent either
information related to providing mobility service to the mobile periodically or in response to a SS-REQ.
nodes either periodically or in response to a SS-REQ.
2: State Synchronization Reply-Ack (SS-ACK) 2: State Synchronization Reply-Ack (SS-ACK)
This message is optional and is specially used when the links This message is optional and is used only when the links
between home agents are not reliable. between home agents are not reliable.
(A)ck flag (A)ck flag
This flag is valid only for SS-REP. If the sender requires This flag is valid only for SS-REP. If the sender requires
explicit acknowledgment by SS-ACK, it MUST set this flag. explicit acknowledgment by an SS-ACK, it MUST set this flag.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Identifier Identifier
A 16-bit identifier to aid in matching state synchronization A 16-bit identifier to aid in matching state synchronization
message. The identifier should never be set to 0. It should messages. The identifier should never be set to 0. It should
always be more than 1. always be more than 1.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [RFC-3775]. The and format of defined options are described in [RFC-3775]. The
receiver MUST ignore and skip any options which it does not receiver MUST ignore and skip any options which it does not
understand. This message requires at least one mobility option, understand. This message requires at least one mobility option,
therefore, there is no default length for this message. therefore, there is no default length for this message.
Binding Cache Information Option is mandatory in SS-REQ message. Binding Cache Information Option is mandatory in the SS-REQ
Multiple options can be stored in the same SS-REQ message. A home message. Multiple options can be stored in the same SS-REQ
agent includes the mobile node's home address in the Binding Cache message. A home agent includes the mobile node's home address in
Information Option. If a home agent wants to solicit all the the Binding Cache Information option. If a home agent wants to
active mobile nodes' states, it can include the unspecified solicit all the active mobile nodes' states, it can include the
address (::) in an IPv6 address option. unspecified address (::) in an IPv6 address option.
Binding Cache Information Option is mandatory in SS-REP. SS-REP Binding Cache Information option is mandatory in SS-REP. SS-REP
can carry any of mobility options. The following options are just can carry many mobility options. The following options are just
examples. examples.
* AAA Information Option * AAA Information Option
* Vendor Specific Mobility Option [RFC-5094] * Vendor Specific Mobility Option [RFC-5094]
* Mobile Network Prefix Option [RFC-3963] * Mobile Network Prefix Option [RFC-3963]
* IPv4 Care-of Address Option [RFC-5555] * IPv4 Care-of Address Option [RFC-5555]
* IPv4 Home Address Option [RFC-5555] * IPv4 Home Address Option [RFC-5555]
* Binding Identifier Option [RFC-5648] * Binding Identifier Option [RFC-5648]
6.1.3. Home Agent Rekey Message 6.1.3. Home Agent Rekey Message
This message is used to indicate that the mobile node SHOULD start an This message is used to indicate that the mobile node SHOULD start an
IPsec re-key with the home agent specified in the Home Agent IPsec re-key with the home agent specified in the Home Agent
skipping to change at page 35, line 40 skipping to change at page 35, line 47
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility options . . Mobility options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Home Agent Rekey Message Figure 8: Home Agent Rekey Message
Reserved Reserved
The reserved field is 16 bits A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Home Agent Address Home Agent Address
The receiver of this message MUST rekey the security association The receiver of this message MUST re-key the security association
with the specified home agent. with the specified home agent.
When a mobile node receives a Home Agent Rekey message, it MUST When a mobile node receives a Home Agent Rekey message, it MUST
verify the message as following. verify the message as follows:
o The message MUST be sent from the receiver's active home agent. o The message MUST be sent from the receiver's active home agent.
Otherwise, the message MUST be discarded. Otherwise, the message MUST be discarded.
o The message MUST be protected by IPsec. Otherwise, the message o The message MUST be protected by IPsec ESP. Otherwise, the
MUST be discarded. message MUST be discarded.
o The message SHOULD contain one of standby home agent's address. o The message SHOULD contain one of the standby home agent's
If the home agent address is not known from the bootstrapping addresses. If the home agent address is not known from the
described in Section 5.1, the mobile node MUST NOT start an IKE bootstrapping described in Section 5.1, the mobile node MUST NOT
session with the unknown home agent. Instead, it SHOULD re-start start an IKE re-key session with the unknown home agent. Instead,
home agent discovery again to update its home agent address it SHOULD re-start home agent discovery to update its home agent
information. address information.
If all the above verifications are satisfied, the mobile node MUST If all the above verifications are satisfied, the mobile node MUST
re-key the SA with the home agent addresses stored in the Home Agent re-key the SA with the home agent addresses stored in the Home Agent
Addresses field. Addresses field.
6.2. New Mobility Options 6.2. New Mobility Options
6.2.1. Binding Cache Information Option 6.2.1. Binding Cache Information Option
The binding cache information option is used to carry binding cache The Binding Cache Information option is used to carry Binding Cache
information of each mobile node. It has two different lengths Information of each mobile node. This option is only valid in a
depending on the number of fields. Two lengths can be set, 16 and State Synchronization message. Its format is as follows:
40. The alignment requirement is either 8n+6 or 8n+2. The Binding
Cache Information option is only valid in a State Synchronization
message. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Home Address | | Home Address |
+ + + +
skipping to change at page 37, line 33 skipping to change at page 37, line 33
+ + + +
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Flags : Sequence Number : : Flags : Sequence Number :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Lifetime : Reserved : : Lifetime : Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Binding Cache Information Option Figure 9: Binding Cache Information Option
The fields of Home Address is always mandated in a Binding Cache Length
Information option. The Care-of Address, Flags, Sequence Number, and
Lifetime fields are presented only if these values are necessary (ex. 8-bit unsigned integer, representing the length in octets of the
VHARP). The corresponding value in the binding cache database of the mobility option, not including the Option Type and Option Length
active home agent is copied to each field. Note that the 16-bit fields. There are two valid length values, 16 and 40, depending
Reserved field MUST be set to zero. on the number of fields in use. The alignment requirement is
either 8n+6 (length 16) or 8n+2 (length 40).
Home Address
The Home Address of a mobile node.
Care-of Address
Flags
Sequence Number
Lifetime
Optional values only used in VHARP, in which case the
corresponding value from the binding cache database of the active
home agent is copied into each field.
Reserved
A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
6.2.2. State Synchronization Status Option 6.2.2. State Synchronization Status Option
Figure 10 is a new mobility option of State Synchronization message. The State Synchronization Status option is used to carry the status
In the global HAHA, SS-ACK is mandatory for receivers of SS-REP to value of an SS-ACK for a received SS-REP. In [ID-HAHA], SS-ACK is
notify the global binding registration status mandatory in response of an SS-REP to update global binding
registration status.
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 = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Home Address | | Home Address |
+ + + +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: State Synchronization Status Option Figure 10: State Synchronization Status Option
Type
8-bit Type value. The value is TBD.
Length
8-bit length value.
Status Status
8 bit Status value of global binding registration. 8-bit unsigned integer indicating the status of the SS-REP.
* 0: Success * 0: Success
* 128: Reason unspecified * 128: Reason unspecified
* 129: Malformed SS-REP * 129: Malformed SS-REP
* 130: Not in same global home agent set * 130: Not in same global home agent set
Reserved Reserved
24 bit Reserved fields A 24-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Home Address Home Address
Corresponding home address of the status code.
Corresponding home address of the mobile node.
6.2.3. AAA Information Option 6.2.3. AAA Information Option
This option is used to carry the AAA state of the mobile node's This option is used to carry the AAA state of the mobile node's
Mobile IPv6 sessions. The AAA state information can be carried in Mobile IPv6 sessions. The AAA state information can be carried in
RADIUS or Diameter AVP formats including the user and session info. RADIUS or Diameter AVP formats, including the user and session info.
This information option is only valid in a State Synchronization This information option is only valid in a State Synchronization
message. message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. AAA AVPs . . AAA AVPs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: AAA Information Option Figure 11: AAA Information Option
Type
8-bit Type value. The value is TBD.
Length Length
8-bit length value. 8-bit unsigned integer, representing the length in octets of the
mobility option, not including the Option Type and Option Length
fields.
AAA AVPs AAA AVPs
A series of TLV-encoded AAA AVPs (including vendor specific AVPs)
Series of TLV encoded AAA AVPs (including vendor specific AVPs)
carrying AAA-related information for each Mobile IPv6 and IPsec/ carrying AAA-related information for each Mobile IPv6 and IPsec/
IKE session. IKE session.
7. Security Considerations 7. Security Considerations
All the messages newly defined in this document SHOULD be secured by All the messages newly defined in this document SHOULD be secured by
IPsec ESP. When a HA-HELLO message is multicast, the multicast IPsec ESP. When a HA-HELLO message is multicast, the multicast
extensions to IPsec [RFC-5374] is used. In some operational extensions to IPsec [RFC-5374] is used. In some operational
scenarios, home agents are located in deeply core network and scenarios, home agents are located deep in the core network and
securely managed. If there is a secure transport network between securely managed. If there is a secure transport network between
home agents, some of security mechanism can be turned off depending home agents, some of security mechanism can be disabled, depending on
on administrative policy. administrative policy.
A home agent switch message is reused for signaling between a home A Home Agent Switch message is reused for signaling between a home
agent and a mobile node in HARP. It is protected by IPsec ESP as agent and a mobile node in HARP. It is protected by IPsec ESP as
defined in [RFC-5142]. defined in [RFC-5142].
When an active home agent fails, mobile nodes using that home agent When an active home agent fails, mobile nodes using that home agent
need to change its home agent to one of standby home agents. The need to change their home agent to one of standby home agents. The
mobile node need to update or establish the IPsec SA with the new mobile node needs to update or establish the IPsec SA with the new
home agent as described in Section 5.2. Existing mechanisms home agent as described in Section 5.2. Existing mechanisms
[RFC5723] are applied to this operation. [RFC5723] are applied to this operation.
8. Protocol Constants 8. Protocol Constants
INITIAL_STATE_SYNC_REQ_TIMER: 3sec INITIAL_STATE_SYNC_REQ_TIMER: 3sec
INITIAL_SWITCH_REQ_TIMER: 1sec INITIAL_SWITCH_REQ_TIMER: 1sec
MAC_HARELIABILITY_TIMEOUT 16sec MAC_HARELIABILITY_TIMEOUT 16sec
 End of changes. 217 change blocks. 
555 lines changed or deleted 586 lines changed or added

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