draft-ietf-mip6-hareliability-06.txt   draft-ietf-mip6-hareliability-07.txt 
MEXT Working Group R. Wakikawa (Editor) MEXT Working Group R. Wakikawa (Editor)
Internet-Draft Toyota ITC Internet-Draft Toyota ITC USA.
Intended status: Standards Track July 12, 2010 Intended status: Standards Track October 20, 2010
Expires: January 13, 2011 Expires: April 23, 2011
Home Agent Reliability Protocol (HARP) Home Agent Reliability Protocol (HARP)
draft-ietf-mip6-hareliability-06.txt draft-ietf-mip6-hareliability-07.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 compatible protocols are operated in a system. It is critical to its associated supporting protocols are operated in a system. It is
provide home agent reliability in the event of a home agent crashing critical to provide home agent reliability in the event of a home
or becoming unavailable. This would allow another home agent to take agent crashing or becoming unavailable. This would allow another
over and continue providing service to the mobile nodes. This home agent to take over and continue providing service to the mobile
document describes the problem scope briefly and provides mechanisms nodes. This document describes the problem scope briefly and
of home agent failure detection, home agent state transfer, and home provides mechanisms of home agent failure detection, home agent state
agent switching for home agent redundancy and reliability. transfer, and home agent switching for home agent redundancy and
reliability.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 23, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the 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 . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 11 3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 12
3.1. Network Configuration . . . . . . . . . . . . . . . . . . 11 3.1. Network Configuration . . . . . . . . . . . . . . . . . . 12
3.2. Home Agent Address Configuration . . . . . . . . . . . . . 12 3.2. Home Agent Address Configuration . . . . . . . . . . . . . 13
4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 12 4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 13
4.1. Home Agent List Management . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . 14 4.3. Processing the HARP Messages . . . . . . . . . . . . . . . 15
4.3.1. IP field and Security Descriptions of HARP message . . 14 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) . . . 18 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) . . . 19
4.4. State Synchronization . . . . . . . . . . . . . . . . . . 19 4.4. State Synchronization . . . . . . . . . . . . . . . . . . 20
4.4.1. Binding Cache Information Management . . . . . . . . . 20 4.4.1. Binding Cache Information Management . . . . . . . . . 21
4.4.2. IP field and Security Descriptions of SS message . . . 20 4.4.2. IP field and Security Descriptions of SS message . . . 21
4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 20 4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 21
4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 21 4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 22
4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 22 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 . . . . . . . . . . . . . 23
4.6. Consideration of Routing and Neighbor Discovery 4.6. Consideration of Routing and Neighbor Discovery
Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 24 Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 25
4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 25 4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 26
4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26 4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 26 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 27
5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 26 5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 27
5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 27 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 . . . . . . . . . . . 28 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 . . . . . . . . . 32 6.1.2. State Synchronization Message Format . . . . . . . . . 33
6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 34 6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 35
6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 35 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 36
6.2.1. Binding Cache Information Option . . . . . . . . . . . 35 6.2.1. Binding Cache Information Option . . . . . . . . . . . 36
6.2.2. State Synchronization Status Option . . . . . . . . . 36 6.2.2. State Synchronization Status Option . . . . . . . . . 37
6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 38 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 39
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 40
10. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 11. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
In Mobile IPv6 [RFC-3775] and its compatible protocols like NEMO In Mobile IPv6 [RFC-3775] and its derivatives protocols like NEMO
Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC-5555], if a Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC-5555], if a
home agent loses the binding cache state, due to failure or some home agent loses the binding cache state or even network
other reason, it results in a loss of service for the mobile nodes. connectivity, due to its failure or some other reason, it results in
It is beneficial to provide high availability and redundancy for a a loss of service for the mobile nodes. It is beneficial to provide
home agent so that mobile nodes can avail of uninterrupted service high availability and redundancy for a home agent so that mobile
even when one home agent crashes or loses state. The Home Agent nodes can avail of uninterrupted service even when one home agent
Reliability protocol (HARP) is designed to manage standby home agents crashes or loses state. The Home Agent Reliability protocol (HARP)
and switch a home agent in case of the active home agent failure. is 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
failing.
[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 to both a mobile node 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)
Providing reliability by using multiple home agents with A protocol between Mobile IPv6 Home agents which provides
individual home agent addresses. It requires binding re- reliability by moving state and service from an active home agent
registration to the new home agent. to a standby in the case of the active home agent failing. HARP
assumes multiple home agents placement on a same home link or
different links and groups them into a redundant home agent set.
One of home agents is selected as an active home agent. In case
of the active home agent's failure, a standby home agent can take
over and become the active home agent. Since each home agent is
assigned individual home agent addresses, a mobile node is aware
of home agent failures and needs to register its binding to 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
Providing reliability by using multiple home agents and single reliability by cloning an active home agent. Unlike HARP, the
virtual home agent address. It can virtually switch to the new standby home agents are an exact copy of the active home agent
home agent without binding re-registration to the new home agent. including home agent IP address. It is similar to the virtual
router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281].
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 will serve the mobile nodes when the active A home agent which can serve the mobile nodes when the active home
home agent fails. agent fails.
Failed Home Agent Failed Home Agent
A home agent that is not available due to hardware or software A home agent that is not available due to hardware or software
failure, system maintenance, etc. failure, system maintenance, etc.
Active Home Agent Address
An IPv6 address of the Active Home Agent.
Standby Home Agent Address
An IPv6 address of the Standby Home Agent.
Redundant Home Agent Set Redundant Home Agent Set
A group of an active and standby home agent(s). The Group A grouping which includes an active and standby home agent(s).
Identifier is used to identify a redundant home agent set. The Group Identifier is used to identify a redundant home agent
Operators need to configure a value per redundant home agent set. set. Operators need to configure a value per redundant 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 This preference value is originally defined for Dynamic Home Agent
Address Discovery (DHAAD) in RFC3775. This protocol re-uses this Address Discovery (DHAAD) in RFC3775. This protocol re-uses this
preference value for home agent selection when an active home preference value for home agent selection when an active home
agent has failed. However, an operator can also define an agent has failed. A home agent SHOULD NOT share the same
independent value used only for the home agent reliability preference value with other home agents. Meanwhile, operators can
protocol if the operator wants to have different preference values also define an independent value for the home agent reliability
for DHAAD and the home agent reliability protocol. A home agent protocol. It is useful when operators want to have different
SHOULD NOT use the same preference value of other home agents. operational policy to the preference values of DHAAD and the 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 6, line 33 skipping to change at page 7, line 11
home agent, a mobile node can re-establish its connection through a home agent, a mobile node can re-establish its connection through a
new home agent. However, the base Mobile IPv6 specification does not new home agent. However, the base Mobile IPv6 specification does not
address home agent fail-over and dynamic transfer of service from one address home agent fail-over and dynamic transfer of service from one
home agent to another. This transfer of service from the failed home home agent to another. This transfer of service from the failed home
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
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
skipping to change at page 7, line 14 skipping to change at page 7, line 37
State Synchronization State Synchronization
The information for mobile nodes must be able to be synchronized The information for mobile nodes must be able to be synchronized
between an active home agent and standby home agents. This between an active home agent and standby home agents. This
includes the Binding Cache, AAA information, other Mobile IPv6 and includes the Binding Cache, AAA information, other Mobile IPv6 and
NEMO related information. Note that the Home Agent Reliability NEMO related information. Note that the Home Agent Reliability
protocol exchanges only running states of mobile nodes. protocol exchanges only running states of mobile nodes.
Therefore, we do not have any specific operation for synchronizing Therefore, we do not have any specific operation for synchronizing
the configuration information. For instance, when Mobile IPv6 is the configuration information. For instance, when Mobile IPv6 is
operated with Authentication protocol, synchronizing the operated with Authentication protocol [RFC-4285], synchronizing
configurations of the Authentication protocol is out of scope in the configurations of the Authentication protocol is out of scope
this document. Operators MAY correctly set the configuration in this document. Operators MAY correctly set the configuration
information in multiple home agents. 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. The details are described in Section 7. 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] or HSRP [RFC-
2281], it can re-use that mechanism to detect the home agent 2281], it can re-use that mechanism to detect the home agent
failure. On the other hand, periodic Hello messages are failure. On the other hand, periodic Hello messages are
skipping to change at page 7, line 47 skipping to change at page 8, line 24
introduced to detect active home agent's service availability in introduced to detect active home agent's service availability in
this document. this document.
Failure Notification Failure Notification
If necessary, a mobile node is notified about the active home If necessary, a mobile node is notified about the active home
agent failure by the standby home agent. agent failure by the standby home agent.
2. Protocol Overview 2. Protocol Overview
HARP assumes multiple home agents placement on a same home link or HARP works when one or more home agents are provisioned on a home
different links and groups them into a redundant home agent set. One link or different links and these are grouped into a redundant home
of home agents is selected as an active home agent and receives a agent set. One of home agents is selected as an active home agent
binding update from mobile nodes. According to [RFC-3775, RFC-4877], and receives a binding update from mobile nodes. According to [RFC-
an active home agent maintains not only binding cache but also IPsec/ 3775, RFC-4877], an active home agent maintains not only binding
IKEv2 states per mobile node, because Mobile IP adapts IPsec as its cache but also IPsec/IKEv2 states per mobile node, because Mobile
security mechanism for signaling. IPv6 relies on IPsec for securing the signaling and optionally user
plane traffic.
If the active home agent fails, all these information per mobile node If the active home agent fails, all state information associated with
is vanished. As a result, all mobile nodes served by the failed home an MN is lost. As a result, all mobile nodes served by the failed
agent will be disconnected. In HARP, other home agents , named home agent will be disconnected. In HARP, other home agents , named
standby home agent, exchange the required information with the active standby home agent, exchange the required information with the active
home agent in case of failure of the active home agent. HARP can let home agent in case of failure of the active home agent. HARP can let
standby home agent take over the failed home agent with such standby home agent take over the failed home agent with such
information of the serving mobile nodes. information of the serving 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
| | | | | |
| X | HA1 FAILURE | X | HA1 FAILURE
| X | | X |
| X | 4. Failure Detection | X | 4. Failure Detection
skipping to change at page 8, line 46 skipping to change at page 9, line 36
individual IP address (HA1 and HA2-addr) at the home link. Each home individual IP address (HA1 and HA2-addr) at the home link. Each home
agent can be seen as an individual home agent by mobile nodes. All agent can be seen as an individual home agent by mobile nodes. All
the home agents periodically send a hello message (named HA-HELLO) to the home agents periodically send a hello message (named HA-HELLO) to
exchange the home agent information and also monitor the active home exchange the home agent information and also monitor the active home
agent's status (1). The mobile node registers its binding only with agent's status (1). The mobile node registers its binding only with
the active home agent (2). The active home agent synchronizes the the active home agent (2). The active home agent synchronizes the
serving mobile node information (i.e. home address) with the other serving mobile node information (i.e. home address) 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 should use any types of information to detect that failure. After it may use any types of information to detect that failure. After
detecting failure of the active home agent (4), a standby home agent detecting failure of the active home agent (4), a standby home agent
whose preference value is the highest takes over the failed home whose preference value is the highest takes over the failed home
agent. For doing so, the standby home agent sends a Home Agent agent. For doing so, the standby home agent sends a Home Agent
Switch message to all the mobile nodes that were registered at the Switch message to all the mobile nodes that were registered at the
failed home agent (5). The standby Home Agent set its own address in failed home agent (5). The standby Home Agent sets its own address
the Home Agent Address field in the Home Agent Switch message so that in the Home Agent Address field in the Home Agent Switch message so
it will receive the binding update from the mobile node as an that it will receive the binding update from the mobile node as an
acknowledgment of the sent Home Agent Switch message. The home agent acknowledgment of the sent Home Agent Switch message. The home agent
switch-over is complete when it receives binding updates from all the switch-over is complete when it receives binding updates from all the
mobile nodes (6). For protecting the Home Agent Switch, the mobile mobile nodes (6). For protecting the Home Agent Switch, the mobile
node should have IPsec Security Associations (SA) with the standby node should have IPsec Security Associations (SA) with the standby
home agent before any failover. The mobile node may pre-establish home agent before any failover. The mobile node may pre-establish
multiple IPsec SAs with all the home agents. 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 states synchronization is out of scope in this
document. However, some Virtual Private Network (VPN) products have document. If IPsec/IKEv2 states can be recovered from the active
proprietary IPsec/IKEv2 state synchronization among multiple boxes. home agent to standby one, HARP can be operated slightly in different
If IPsec/IKEv2 states can be recovered from the active home agent to manner named Virtual-HARP (VHARP). Unlike HARP, the standby home
standby one, HARP can be operated slightly in different manner named agents are an exact copy of the active home agent. It is similar to
Virtual-HARP (VHARP). Unlike HARP, the standby home agents are an the virtual router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-
exact copy of the active home agent. It is similar to the virtual 2281]. Note that HARP is mandatory and VHARP is optional in this
router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. Note document. VHARP is shown in Figure 2.
that HARP is mandatory and VHARP is 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
skipping to change at page 10, line 21 skipping to change at page 11, line 7
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's activation can be operated by VRRP.
Since all the necessary states of mobile nodes have already been Since 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 IPsec SA with the new active home
agent. agent.
This document offers a new management mechanism of an active and This document offers a new management mechanism of active and standby
standby home agents by using a new Mobility Header (MH) message named home agents by using a new Mobility Header (MH) message named a HARP
a HARP message as shown in Figure 3. This mechanism can be used in message as shown in Figure 3. This mechanism can be used in both
both HARP and VHARP. Each home agent exchanges own home agent HARP and VHARP. Each home agent exchanges own home agent information
information with the other home agents in its redundancy home agent with the other home agents in its redundancy home agent set by a Home
set by a Home Agent HELLO message (HA-HELLO) (1). The HA-HELLO Agent HELLO message (HA-HELLO) (1). The HA-HELLO message can also be
message can also be used to monitor the availability of the active used to monitor the availability of the active home agent.
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 provides for mobile nodes for system maintenance. This specification enables
a manual home agent management. As shown in Figure 3, the active manual intervention for home agent management. As shown in Figure 3,
home agent (HA1) sends a SwitchBack Request message (SWB-REQ) to a the active home agent (HA1) sends a SwitchBack Request message (SWB-
standby home agent (HA2) (2). HA2 will acknowledge the message by REQ) to a standby home agent (HA2) (2). HA2 will acknowledge the
sending a SwitchBack Reply message (SWB-REP) to HA1 (3). In the HARP message by sending a SwitchBack Reply message (SWB-REP) to HA1 (3).
operation, it takes certain time to complete home agent fail-over by In the HARP operation, it takes certain time to complete home agent
mobile nodes' re-registration to the new home agent. During this fail-over by mobile nodes' re-registration to the new home agent.
fail-over operations, HA1 may continue serving the mobile nodes until During this fail-over operations, HA1 may continue serving the mobile
the switch over is completed. When HA2 completes the switch-over, it nodes until the switch over is completed. When HA2 decides the
SHOULD send a SW-COMP to HA1 (4). As soon as HA2 sends the SW-COMP, switch-over is completed, it MAY send an optional message, SW-COMP,
it becomes the active home agent. HA1 becomes standby when it to HA1 (4). As soon as HA2 sends the SW-COMP, it becomes the active
receives SW-COMP. home agent. HA1 becomes standby when it receives SW-COMP. If SW-
COMP is not used, HA2 and HA1 changes their status appropriately.
After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2 After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2
in order to become the active home agent again (5). HA2 acknowledge in order to become the active home agent again (5). HA2 acknowledges
it by sending a SwitchOver Reply (SWO-REP) to HA1 (6). HA1 now it by sending a SwitchOver Reply (SWO-REP) to HA1 (6). HA1 now
starts home agent fail-over operation. After the completion of fail- starts home agent fail-over operation. After the completion of fail-
over, HA1 sends a SW-COMP to HA2 (7). Then, HA1 returns to the over, HA1 sends a SW-COMP to HA2 (7). Then, HA1 returns to the
active home agent and HA2 fall back to a standby home agent (8). active home agent and HA2 fall back to 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.
skipping to change at page 12, line 17 skipping to change at page 13, line 4
routing must be also updated to direct the packets meant for the home routing must be also 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 need 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 the 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 join the multicast group with its individual IPv6
address, but not with virtual home agent address. This multicast address, but not with 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 the HA-HELLO message among the home
agents. On the other hand, if a home recovery link is separately agents. On the other hand, if a home recovery link is separately
defined, each home agent always unicasts the HARP messages to home defined, each home agent always unicast the HARP messages to home
agents configured at a geographically separated link. agents configured at a geographically separated 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 message
skipping to change at page 14, line 47 skipping to change at page 15, line 29
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 gent and the recovering
operation should be started. operation 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 unicasted, the destination address is one of Home Agent in message is unicast, the destination address is one of Home Agent in
the same Redundant Home Agent set. If it is HA-HELLO message (by the same Redundant Home Agent set. If it is HA-HELLO message (by
setting the type field to 4), it can be multicasted. The destination setting the type field to 4), it can be multicast. The destination
address MUST be set to ALL_HA_MULTICAST_ADDR. The source address address MUST be set to ALL_HA_MULTICAST_ADDR. The source address
MUST be set to the sender's home agent address. Note that, in VHARP, MUST be set to the sender's home agent address. Note that, in VHARP,
the virtual home agent address SHOULD NOT be set to source and the virtual home agent address SHOULD NOT be set to source or
destination address. The IP address of the interface the packet is destination address. The IP address of the interface the packet is
being sent from SHOULD be used. being sent from SHOULD be used.
If a HARP message is unicasted, it SHOULD be authenticated by IPsec If a HARP message is unicast, it SHOULD be secured by IPsec ESP. If
AH and MAY be encrypted by IPsec ESP. If a HA-HELLO message is a HA-HELLO message is multicast, multicast extensions to IPsec [RFC-
multicasted, multicast extensions to IPsec [RFC-5374] SHOULD be 5374] SHOULD be applied. If all the home agents are placed in a
applied. If all the home agents are placed in a secure transport secure transport network to exchange a HARP message, authentication
network to exchange a HARP message, authentication and encryption MAY and encryption MAY be omitted. Which security verification is used
be omitted. Which security verification is used depends on depends on operational policy. If security verification is failed
operational policy. If security verification is failed for a for a receiving HA-HELLO, the HA-HELLO MUST be discarded.
receiving 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 to 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
skipping to change at page 15, line 37 skipping to change at page 16, line 19
o The sender's Group ID MUST be set to the Group ID field. o The sender's Group ID MUST be set to 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 operated with HARP.
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 operated with VHARP.
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.
Performed the following functions when a HARP message is received. The following functions MUST be performed when a HARP message is
received.
o MUST verify the Group ID of the HARP message is equal to the o MUST verify the Group ID of the HARP message is equal to the
receiver's Group ID. receiver's Group ID.
o MUST verify the sender of the HARP message belongs to the o MUST verify the sender of the HARP message belongs to the
receiver's same redundant home agent set receiver's same redundant home agent set
o MUST verify that the M flag is equal to the receiver's operating o MUST verify that the M flag is equal to the receiver's operating
mode. mode.
skipping to change at page 16, line 21 skipping to change at page 17, line 6
Each home agent MUST send a HA-HELLO in following case: Each home agent MUST send a HA-HELLO in following case:
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 interval time 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
change, it should immediately send a HA-HELLO. change, 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. When the R-flag is set, the HA-HELLO can be requested to the set, the HA-HELLO can be requested to the destination home agent.
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 to a particular home agent(s) in
the same redundant home agent set by unicasting or multicasting a HA- the same redundant home agent set by unicasting or multicasting a HA-
HELLO with the R-flag set. Soliciting HA-HELLO is operated when: HELLO with the R-flag set. Soliciting HA-HELLO is operated 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.
o A HA-HELLO has not been received after the specified hello o A HA-HELLO has not been received after the specified hello
skipping to change at page 17, line 24 skipping to change at page 18, line 6
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 with the following operations.
o MUST be unicasted only to the current active home agent o MUST be unicast only to the current active home agent
o MUST be sent from a standby home agent. The active home Agent o 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 operate the
following verification and operations in addition to Section 4.3.1: following verifications and operations in addition to 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 sender 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 There is a case where the active home agent cannot be standby home o If there are any other reasons that the receiver cannot accept the
agent. The active home agent MUST reply a SWO-REP with the Status SWO-REP, the active home agent MUST reply a SWO-REP with the
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 operate the
following verification and operations in addition to Section 4.3.1: following verifications and operations in addition to 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 unexpected SWO-REP which is
not in reply to its SWO-REQ, it MUST ignore the SWO-REP. not in reply to its SWO-REQ, 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 SWO-REP) immediately becomes
an active home agent. an active home agent.
skipping to change at page 18, line 28 skipping to change at page 19, line 14
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 standby home agents. The reason for the
active home agent to send this message can be administrative active home agent to send this message can be administrative
intervention, and events like Monitored Server Failure by the active intervention, and events like Monitored Server Failure by the active
home agent or Routing Peer/Link Failure. The following operations home agent or Routing Peer/Link Failure. The following operations
MUST be performed when SWB-REQ is sent. MUST be performed when SWB-REQ is sent.
o MUST be unicasted only to one of standby home agents in the same o MUST be unicast only to one of standby home agents in the same
redundant home agent set redundant home agent set
o MUST be sent from an active home agent. The standby home Agent o MUST be sent from an active home agent. A standby home Agent MUST
MUST NOT generate this message. 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 sender 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, the receiver MUST reply a SWB-REP with the Status field is
set to 130 (Not active home agent). set to 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). 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 is 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 which is
acknowledging the SWB-REQ. The standby home agent SHOULD change acknowledging the SWB-REQ. The standby home agent SHOULD change
to active at least after LINK_TRAVERSAL_TIME. to active at least after LINK_TRAVERSAL_TIME. The default value
of 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 receives an unexpected SWB-REP which is
not in reply to own SWB-REQ, it SHOULD ignore the SWO-REP. not in reply to 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 immediately becomes a standby home agent. The sender home
agent of SWB-REP becomes an active home agent after certain time, agent of SWB-REP becomes an active home agent after certain time,
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 SWB-REP (active home agent) cannot become a standby home agent
and MUST continue to be an active home 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 A State Synchronization (SS) message format is defined in
Section 6.1.2. It can carry several state information about a mobile Section 6.1.2. It can carry multiple aspects of the state
node by setting mobility options in the Mobility Options field. The information associated with a mobile node by setting mobility options
following list shows examples of the mobility options which can be in the Mobility Options field. The following list shows examples of
specified in the state synchronization message. the mobility options which can be specified in the state
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])
o IPv4 Home Address (IPv4 Home Address Option [RFC-5555]) o IPv4 Home Address (IPv4 Home Address Option [RFC-5555])
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 need 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 home agent fail-over, it is not necessary for the standby
home agents to synchronize all the mobile nodes' state information. home agents to synchronize all the mobile nodes' state information.
The standby home agent only need to collect the home address The standby home agent only need to collect the home address
information of all the mobile nodes served by the active home agent. information of all the mobile nodes served by the active home agent.
The information is used to send the Home Agent Switch messages to all The information is used to send the Home Agent Switch messages to all
the mobile node when the home agent failure is occurred. the mobile node when the home agent failure is occurred.
In VHARP, home agent fail-over is completed without mobile nodes' In the case of VHARP, home agent fail-over is accomplished without
binding re-registration. Therefore, standby home agents need to copy the mobile nodes having to perform re-registration. Therefore,
the complete state information of each mobile node registered with standby home agents need to copy the complete state information of
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. This information is stored somewhere registering home agent address.
in a standby home agent.
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 SS message
A state synchronization message is only unicasted. The destination A state synchronization message is unicast. The destination address
address MUST be one of home agents in the same Redundant Home Agent MUST be one of home agents in the same Redundant Home Agent set. The
set. The source address MUST be set to the sender's home agent source address MUST be set to the sender's home agent address. Note
address. Note that, in VHARP, the virtual home agent address MUST that, in VHARP, the virtual home agent address MUST NOT be set to the
NOT be set to the source address. IP address of the interface the source address. IP address of the interface the packet is being sent
packet is being sent from SHOULD be used. from SHOULD be used.
If a state synchronization message is unicasted, it SHOULD be It SHOULD be secured by IPsec ESP. If all the home agents are placed
authenticated by IPsec AH and MAY be encrypted by IPsec ESP. If all in a secure transport network to exchange the state synchronization
the home agents are placed in a secure transport network to exchange message, authentication and encryption MAY be omitted. If security
the state synchronization message, authentication and encryption MAY verification is failed for a receiving state synchronization message,
be omitted. If security verification is failed for a receiving state the message MUST be discarded. The choice of security mechanism used
synchronization message, the message MUST be discarded. Which depends on the operational model of the network.
security mechanism is used depend on the operational policy.
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 MUST set the Type field to 0 (Request).
o MUST set a random value in the Identifier field that does not o MUST set a random value in the Identifier field that does not
skipping to change at page 22, line 37 skipping to change at page 23, line 25
in the active home agent by the SS-REP when the unspecified in the active home agent by the SS-REP when the unspecified
address is found in the Home Address mobility option carried with address is found in the Home Address mobility option carried with
the SS-REQ. The message may be fragmented depending on the total the SS-REQ. The message may be fragmented depending on the total
size needed to carry all states. 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 MUST o If no options are carried in the SS-REP, the home agent just
ignore the SS-REP and MUST send SS-ACK with the Status ignores the SS-REP.
Synchronization Status option which status value is set to [131:
No Mobility Option]
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 which status value is set
to [130: Not in same global home agent 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 home agent MUST record the IPv6 address of the sender
as the active home agent of the mobile node in its local binding as the active home agent of the mobile node in its local binding
cache. cache.
skipping to change at page 23, line 24 skipping to change at page 24, line 7
received in the SS-REP into SS-ACK in order to match the SS-REP and received in the SS-REP into SS-ACK in order to match the SS-REP and
SS-ACK. 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 the Home Agent Switch message. o MUST use IPsec ESP to protect the Home Agent Switch message.
o MUST set only that standby home agent address in the Home Agent o MUST set the address of the standby home agent address who is the
Switch message sender of this Home Agent Switch message in the Home Agent Address
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 sending Home Agent Switch messages is high. This
overhead cannot be avoided if the active home agent suddenly stop overhead cannot be avoided if the active home agent suddenly stop
serving mobile node because of unexpected reasons (crash, network serving mobile node because of unexpected reasons (crash, network
trouble, etc). However, if this switch over is operated under the trouble, etc). However, if this switch over is operated under the
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 completed. 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 the packet to the previous home
skipping to change at page 23, line 52 skipping to change at page 24, line 36
message. When the new active home agent completes the switch-over, message. When the new active home agent completes the switch-over,
it SHOULD send a SW-COMP to the previous active home agent. Until it SHOULD send a SW-COMP to the previous active home agent. Until
the previous home agent receives this message, it SHOULD continue the previous home agent receives this message, it SHOULD continue
serving any mobile nodes that are registered with it. Once the serving any mobile nodes that are registered with it. Once the
previous home agent receives the SW-COMP message, it can be shutdown previous home agent receives the SW-COMP message, it can be shutdown
or detached from the network safely. 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 the failed home agent. The standby home agent MUST activate the
virtual home agent address. If a virtual MAC address as introduced virtual home agent address and its virtual MAC address. A virtual
in [RFC-3768, RFC-5798] is used, the standby home agent MUST start MAC address as introduced in [RFC-3768, RFC-5798] SHOULD be used in
using that virtual MAC address as well. If VHARP run with VRRP and VHARP. If VHARP run with VRRP and HSRP as described in Section 4.7,
HSRP as described in Section 4.7, the virtual home agent address can the virtual home agent address can be treated as a virtual router
be treated as a virtual router address in VRRP and HSRP. Therefore, address in VRRP and HSRP. Therefore, VRRP and HSRP can automatically
VRRP and HSRP can automatically activate the virtual home agent activate the virtual home agent address on the standby home agent
address on the standby home agent after their election mechanism. after their election mechanism. Since all the necessary state has
Since all the necessary state has already been transferred to this already been transferred to this standby home agent before the active
standby home agent before the active home agent failed, it can home agent failed, it can immediately start acting as the active home
immediately start acting as the active home agent. agent.
When the failed home agent recovers from failure and would return to When the failed home agent recovers from failure and would return to
the active home agent, it MUST re-establish IPsec SA with all the the active home agent, it MUST re-establish IPsec SA with all the
mobile nodes. All the mobile nodes lost IPsec SA with the home agent mobile nodes. All the mobile nodes lost IPsec SA with the home agent
when the failure is occurred. Otherwise, it cannot be either a when the failure has occurred. Otherwise, it cannot be either a
standby or active home agent for the mobile nodes. Therefore, as standby or active home agent for the mobile nodes. Therefore, as
soon as the active home agent detects the recovery of the failed home soon as the active home agent detects the recovery of the failed home
agent, it sends a Home Agent Rekey message to all the mobile nodes agent, it sends a Home Agent Rekey message to all the mobile nodes
served by other home agents in the same redundant home agent set, and served by other home agents in the same redundant home agent set, and
includes the recovered home agent address in the Home Agent Addresses includes the recovered home agent address in the Home Agent Addresses
field. The detail of the Home Agent Rekey message is described in field. The detail of the Home Agent Rekey message is described in
Section 6.1.3. The mobile node will re-key the SA by using The IKEv2 Section 6.1.3. The mobile node will re-key the SA by using The IKEv2
resumption mechanism [RFC-5723]. Alternatively, the mobile node MAY resumption mechanism [RFC-5723]. Alternatively, the mobile node MAY
start a new IKE session with the recovered home agent. start a new IKE session with the recovered home agent.
skipping to change at page 25, line 28 skipping to change at page 26, line 16
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 the 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 fail over 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 of information is missed by using
VRRP. After receiving a VRRP message, each home agent SHOULD process VRRP. After receiving a VRRP message, each home agent SHOULD process
the message and store the information as if it receives Home Agent the message and store the information as if it receives Home Agent
Hello messages Section 4.3.2.2. The message format of VRRP can be Hello messages Section 4.3.2.2. The message format of VRRP can be
found in Section 5.1 of [RFC-5798]. Each field is mapped as follows: found in Section 5.1 of [RFC-5798]. Each field is mapped as follows:
skipping to change at page 26, line 44 skipping to change at page 27, line 30
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. Non of operations in this section is required in VHARP. is used. None of the operations in this section is required in
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.
In order to discover multiple home agent addresses, two different In order to discover multiple home agent addresses, two different
skipping to change at page 28, line 14 skipping to change at page 28, line 50
home address assignment to standby home agents. 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). (ex. 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 which K-bit is set,
it MUST proceed the Binding Update as [RFC-3775]. In addition, the it MUST process the Binding Update as [RFC-3775]. In addition, the
active home agent MUST notify the care-of address change to the other active home agent MUST notify the care-of address change to the other
standby home agents. For doing so, it MUST send State standby home agents. For doing so, it MUST send State
Synchronization Reply message including Binding Cache Information Synchronization Reply message including 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 (ex. K-bit) MUST be copied to the flags field of the
Binding Cache Information option. After all, the standby home agents Binding Cache Information option. After all, the standby home agents
know the existence of K-bit set in the Flag field of the Binding know the existence of K-bit set in the Flag field of the Binding
Cache Information option and update the peer endpoint of the key Cache Information option and update the peer endpoint of the key
management protocol. management protocol.
skipping to change at page 29, line 40 skipping to change at page 30, line 30
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 unicasted by a standby home agent that desires to become It is unicast by a standby home agent that desires to become
the active home agent. The receiver of the message MUST the active home agent. The receiver of the message MUST
transition to standby state as soon as the message is received transition to standby state as soon as the message is received
and validated successfully. and validated successfully.
1: SwitchOver Reply (SWO-REP) 1: SwitchOver Reply (SWO-REP)
It is used to acknowledge the receipt of the corresponding SWO- It is used to acknowledge the receipt of the corresponding SWO-
REQ. REQ.
2: SwitchBack Request (SWB-REQ) 2: SwitchBack Request (SWB-REQ)
It is unicasted by an active home agent that desires to become It is unicast by an active home agent that desires to become a
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- It is used to acknowledge the receipt of the corresponding SWB-
REQ. REQ.
4: Switch Complete (SW-COMP) 4: Switch Complete (SW-COMP)
This message is used to indicate the completion of switch over, This message is used to indicate the completion of switch over,
(i.e. sending home agent switch messages and receiving binding (i.e. sending home agent switch messages and receiving binding
update messages from all the served mobile nodes). update messages from all the served mobile nodes).
4: Home Agent HELLO (HA-HELLO) 4: Home Agent HELLO (HA-HELLO)
skipping to change at page 30, line 27 skipping to change at page 31, line 15
REQ. REQ.
4: Switch Complete (SW-COMP) 4: Switch Complete (SW-COMP)
This message is used to indicate the completion of switch over, This message is used to indicate the completion of switch over,
(i.e. sending home agent switch messages and receiving binding (i.e. sending home agent switch messages and receiving binding
update messages from all the served mobile nodes). update messages from all the served mobile nodes).
4: Home Agent HELLO (HA-HELLO) 4: Home Agent HELLO (HA-HELLO)
It MUST be either unicasted or multicasted to carry home agent It MUST be either unicast or multicast to carry home agent
information among the redundant home agent set. The HA-Hello information among the redundant home agent set. 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 24 skipping to change at page 33, line 14
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. No valid options are defined in this specification.
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 unicasted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A| Reserved | | Type |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | | Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
skipping to change at page 34, line 27 skipping to change at page 35, line 16
* 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
Addresses field. This message is used when a failed home agent Addresses field. This message is used when a failed home agent
recovers and needs to re-establish IPsec SA/IKE state with a mobile recovers and needs to re-establish IPsec SA/IKE state with a mobile
node. This message MUST be unicasted to a mobile node by the active node. This message MUST be unicast to a mobile node by the active
home agent and MUST be authenticated and encrypted by IPsec ESP. The home agent and MUST be authenticated and encrypted by IPsec ESP. The
Home Agent Rekey message has the MH Type value TBD. If no options Home Agent Rekey message has the MH Type value TBD. If no options
are present in this message, no padding is necessary and the Header are present in this message, no padding is necessary and the Header
Len field will be set to 2. Len field will be set to 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 11 skipping to change at page 35, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Home Agent Rekey Message Figure 8: Home Agent Rekey Message
Reserved Reserved
The reserved field is 16 bits The reserved field is 16 bits
Home Agent Address Home Agent Address
The receiver of this message MUST rekey the security asscoation The receiver of this message MUST rekey 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 following.
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. Otherwise, the message
MUST be discarded. MUST be discarded.
o The message SHOULD contain one of standby home agent's address. o The message SHOULD contain one of standby home agent's address.
If the home agent address is not known from the bootstrapping If the home agent address is not known from the bootstrapping
described in Section 5.1, the mobile node MUST NOT start an IKE described in Section 5.1, the mobile node MUST NOT start an IKE
session with the unknown home agent. Instead, it SHOULD re-start session with the unknown home agent. Instead, it SHOULD re-start
home agent discovery again to update its home agent address home agent discovery again to update its home agent address
information. information.
If all the above verfications are satisified, 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. It has two different lengths
depending on the number of fields. Two lengths can be set, 16 and depending on the number of fields. Two lengths can be set, 16 and
skipping to change at page 37, line 42 skipping to change at page 38, line 42
8 bit Status value of global binding registration. 8 bit Status value of global binding registration.
* 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
* 131: No Mobility Option
Reserved Reserved
24 bit Reserved fields 24 bit Reserved fields
Home Address Home Address
Corresponding home address of the status code. Corresponding home address of the status code.
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.
skipping to change at page 38, line 45 skipping to change at page 39, line 42
8-bit length value. 8-bit length value.
AAA AVPs AAA AVPs
Series of TLV encoded AAA AVPs (including vendor specific AVPs) Series of TLV encoded AAA AVPs (including vendor specific AVPs)
carrying AAA-related information for each Mobile IPv6 and IPsec/ carrying AAA-related information for each Mobile IPv6 and IPsec/
IKE session. IKE session.
7. Security Considerations 7. Security Considerations
All the messages newly defined in this document SHOULD be All the messages newly defined in this document SHOULD be secured by
authenticated by IPsec AH and MAY be encrypted by IPsec ESP. When a IPsec ESP. When a HA-HELLO message is multicast, the multicast
HA-HELLO message is multicasted, the multicast extensions to IPsec extensions to IPsec [RFC-5374] is used. In some operational
[RFC-5374] is used. In some operational scenarios, home agents are scenarios, home agents are located in deeply core network and
located in deeply core network and securely managed. If there is a securely managed. If there is a secure transport network between
secure transport network between home agents, some of security home agents, some of security mechanism can be turned off depending
mechanism can be turned off depending on administrative policy. on 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 its home agent to one of standby home agents. The
mobile node need to update or establish the IPsec SA with the new mobile node need 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_SWICH_REQ_TIMER: 1sec INITIAL_SWITCH_REQ_TIMER: 1sec
LINK_TRAVERSAL_TIME 150msec
MAC_HARELIABILITY_TIMEOUT 16sec MAC_HARELIABILITY_TIMEOUT 16sec
ALL_HA_MULTICAST_ADDR: TBD ALL_HA_MULTICAST_ADDR: TBD
9. IANA Considerations 9. Protocol Configuration Variables
LINK_TRAVERSAL_TIME: default 150msec
10. IANA Considerations
The following Extension Types MUST be assigned by IANA: The following Extension Types MUST be assigned by IANA:
o Home Agent Reliability Protocol (HARP) Message o Home Agent Reliability Protocol (HARP) Message
o State Synchronization (SS) Message o State Synchronization (SS) Message
o Binding Cache Information Option o Binding Cache Information Option
o AAA Information Option o AAA Information Option
o A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all o A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all
home agents will be assigned by the IANA. home agents will be assigned by the IANA.
10. Additional Authors 11. Additional Authors
This document is a result of discussions in the Mobile IPv6 Home This document is a result of discussions in the Mobile IPv6 Home
Agent Reliability Design Team. The members of the design team that Agent Reliability Design Team. The members of the design team that
are listed below are authors that have contributed to this document: are listed below are authors that have contributed to this document:
Samita Chakrabarti Samita Chakrabarti
samita.chakrabarti@azairenet.com samita.chakrabarti@azairenet.com
Kuntal Chowdhury Kuntal Chowdhury
skipping to change at page 40, line 37 skipping to change at page 41, line 37
brian.haley@hp.com brian.haley@hp.com
Behcet Sarikaya Behcet Sarikaya
bsarikaya@huawei.com bsarikaya@huawei.com
Ryuji Wakikawa Ryuji Wakikawa
ryuji.wakikawa@gmail.com ryuji.wakikawa@gmail.com
11. Acknowledgements 12. Acknowledgements
This document includes a lot of text from [ID-LOCALHAHA] and [ID- This document includes a lot of text from [ID-LOCALHAHA] and [ID-
HAHA]. Therefore the authors of these two documents are HAHA]. Therefore the authors of these two documents are
acknowledged. We would also like to thank the authors of the home acknowledged. We would also like to thank the authors of the home
agent reliability problem statement [ID-PS-HARELIABILITY] for agent reliability problem statement [ID-PS-HARELIABILITY] for
describing the problem succinctly and Alice Qin for her work on the describing the problem succinctly and Alice Qin for her work on the
hello protocol. hello protocol.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[ID-3775bis] Perkins, C., Johnson, D., Arkko, J., "Mobility Support
in IPv6", draft-ietf-mext-rfc3775bis-10.txt, Octover 2010.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
scenario", RFC 5026, October 2007. scenario", RFC 5026, October 2007.
[RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC
5094, October 2007. 5094, October 2007.
skipping to change at page 41, line 41 skipping to change at page 42, line 44
[RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., [RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648,
October 2009. October 2009.
[ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via
DHCPv6 for the Integrated Scenario", DHCPv6 for the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress),
April 2008. April 2008.
12.2. Informative References 13.2. Informative References
[RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
Standby Router Protocol (HSRP)", RFC 2281, March 1998. Standby Router Protocol (HSRP)", RFC 2281, March 1998.
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004. RFC 3768, April 2004.
[RFC-4285] A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury,
"Authentication Protocol for Mobile IPv6", RFC 4285, January 2006
[RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol [RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol
Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010. Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010.
[RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3 [RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3
for IPv4 and IPv6", RFC 5798 (soon?), December 2009. for IPv4 and IPv6", RFC 5798 (soon?), December 2009.
[ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification",
skipping to change at page 43, line 13 skipping to change at page 44, line 13
February 2004. February 2004.
Author's Address Author's Address
Ryuji Wakikawa Ryuji Wakikawa
TOYOTA InfoTechnology Center, U.S.A., Inc. TOYOTA InfoTechnology Center, U.S.A., Inc.
465 Bernardo Avenue 465 Bernardo Avenue
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: ryuji@us.toyota-itc.com Email: ryuji.wakikawa@gmail.com
 End of changes. 100 change blocks. 
240 lines changed or deleted 261 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/