draft-ietf-mip6-hareliability-05.txt   draft-ietf-mip6-hareliability-06.txt 
MEXT Working Group R. Wakikawa (Editor) MEXT Working Group R. Wakikawa (Editor)
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track July 13, 2009 Intended status: Standards Track July 12, 2010
Expires: January 14, 2010 Expires: January 13, 2011
Home Agent Reliability Protocol Home Agent Reliability Protocol (HARP)
draft-ietf-mip6-hareliability-05.txt draft-ietf-mip6-hareliability-06.txt
Abstract
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
provide home agent reliability in the event of a home agent crashing
or becoming unavailable. This would allow another home agent to take
over and continue providing service to the mobile nodes. This
document describes the problem scope briefly and provides mechanisms
of home agent failure detection, home agent state 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 to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The home agent can be a single point of failure when Mobile IPv6 is described in the BSD License.
operated in a system. It is critical to provide home agent
reliability in the event of a home agent crashing or becoming
unavailable. This would allow another home agent to take over and
continue providing service to the mobile nodes. This document
describes the problem scope briefly and provides a mechanism of home
agent failure detection, home agent state transfer, and home agent
switching for home agent redundancy and reliability.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem Statement and Requirements . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3. Problem Statement and Requirements . . . . . . . . . . . . . . 6
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 8
4.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 9
4.3. Home Agent Management . . . . . . . . . . . . . . . . . . 10
5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. New Mobility Header Messages . . . . . . . . . . . . . . . 11
5.1.1. State Synchronization Message . . . . . . . . . . . . 11
5.1.2. Home Agent Control Message . . . . . . . . . . . . . . 13
5.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 15
5.1.4. Home Agent Rekey Message . . . . . . . . . . . . . . . 17
5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 17
5.2.1. IP address Option . . . . . . . . . . . . . . . . . . 18
5.2.2. Binding Cache Information Option . . . . . . . . . . . 18
5.2.3. AAA Information Option . . . . . . . . . . . . . . . . 19
6. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 20
6.1. Network Configuration . . . . . . . . . . . . . . . . . . 20
6.2. Address Configuration for Virtual Switch . . . . . . . . . 21
6.3. Address Configuration for Hard Switch . . . . . . . . . . 21
7. Home Agent Common Operation . . . . . . . . . . . . . . . . . 22 3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 11
7.1. Home Agent List Management . . . . . . . . . . . . . . . . 22 3.1. Network Configuration . . . . . . . . . . . . . . . . . . 11
7.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 22 3.2. Home Agent Address Configuration . . . . . . . . . . . . . 12
7.3. Processing Hello Messages . . . . . . . . . . . . . . . . 23
7.3.1. Requesting Hello Message . . . . . . . . . . . . . . . 24
7.3.2. Sending Hello Message . . . . . . . . . . . . . . . . 24
7.3.3. Receiving Hello Message . . . . . . . . . . . . . . . 25
7.4. Processing State Synchronization Messages . . . . . . . . 26 4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 12
7.4.1. Requesting State of a Particular Mobile Node(s) . . . 26 4.1. Home Agent List Management . . . . . . . . . . . . . . . . 12
7.4.2. Synchronizing State . . . . . . . . . . . . . . . . . 27 4.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 14
7.4.3. Reliable Transmission by Explicit Acknowledgement . . 28 4.3. Processing the HARP Messages . . . . . . . . . . . . . . . 14
7.5. Processing Home Agent Control Messages . . . . . . . . . . 29 4.3.1. IP field and Security Descriptions of HARP message . . 14
7.5.1. Standby Home Agent becomes an Active Home Agent . . . 29 4.3.2. Processing Home Agent Hello (HA-HELLO) . . . . . . . . 16
7.5.2. Active Home Agent becomes inactive . . . . . . . . . . 30 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) . . . 17
7.6. Interworking with VRRP . . . . . . . . . . . . . . . . . . 31 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) . . . 18
7.7. Retransmissions and Rate Limiting . . . . . . . . . . . . 32 4.4. State Synchronization . . . . . . . . . . . . . . . . . . 19
4.4.1. Binding Cache Information Management . . . . . . . . . 20
4.4.2. IP field and Security Descriptions of SS message . . . 20
4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 20
4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 21
4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 22
4.5. Switching the Active Home Agent . . . . . . . . . . . . . 23
4.6. Consideration of Routing and Neighbor Discovery
Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 24
4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 25
4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26
8. Home Agent Virtual Switch . . . . . . . . . . . . . . . . . . 34 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 26
8.1. Consideration of Routing and Neighbor Discovery 5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 26
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 27
8.2. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 34 5.3. Synchronizing State: K-bit treatment . . . . . . . . . . . 28
5.4. Receiving Home Agent Switch message . . . . . . . . . . . 28
9. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35 6. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 35 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 29
9.2. Sending Home Agent Switch Messages . . . . . . . . . . . . 35 6.1.1. HARP Message Format . . . . . . . . . . . . . . . . . 29
9.3. Sending Home Agent Rekey Messages . . . . . . . . . . . . 36 6.1.2. State Synchronization Message Format . . . . . . . . . 32
9.4. Notification of Home Agent Switch Completion . . . . . . . 36 6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 34
9.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 36 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 35
9.5.1. Home Agent Addresses Discovery . . . . . . . . . . . . 36 6.2.1. Binding Cache Information Option . . . . . . . . . . . 35
9.5.2. IKE/IPsec pre-establishment to Home Agents . . . . . . 37 6.2.2. State Synchronization Status Option . . . . . . . . . 36
9.5.3. Synchronizing State: K-bit treatment . . . . . . . . . 37 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 38
9.5.4. Receiving Home Agent Switch message . . . . . . . . . 38
9.5.5. Receiving Home Agent Rekey message . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 42 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 44 10. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 39
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Normative References . . . . . . . . . . . . . . . . . . . 45 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41
15.2. Informative References . . . . . . . . . . . . . . . . . . 45 12.2. Informative References . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
In Mobile IPv6 [RFC-3775] and NEMO Basic Support [RFC-3963], if a In Mobile IPv6 [RFC-3775] and its compatible protocols like NEMO
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, due to failure or some
other reason, it results in a loss of service for the mobile nodes. other reason, it results in a loss of service for the mobile nodes.
It is beneficial to provide high availability and redundancy for a It is beneficial to provide high availability and redundancy for a
home agent so that mobile nodes can avail of uninterrupted service home agent so that mobile nodes can avail of uninterrupted service
even when one home agent crashes or loses state. The Home Agent even when one home agent crashes or loses state. The Home Agent
Reliability protocol is designed to synchronize the Mobile IPv6 Reliability protocol (HARP) is designed to manage standby home agents
states between active and standby home agents as VRRP[RFC-3768] or and switch a home agent in case of the active home agent failure.
HSRP [RFC-2281]. A home agent maintains not only binding cache but
also IPsec and IKE related states per mobile node. Mobile IPv6
mandates IPsec encryption for signaling of home binding registration
(BU and BA) and return routability (HoTI and HoT) as described in
[RFC-3776]. However, IPsec states synchronization is out of scope in
this document. The scope of Home Agent Reliability protocol is
limited to the management of Mobile IPv6 related states. Thus, we
define two different approaches such as Home Agent Virtual Switch and
Home Agent Hard Switch depending on the capability of IPsec state
synchronization. In both cases, a mobile node maintains only one
home binding at any given time.
Home Agent Virtual Switch
The Home Agent Virtual Switch operation can be used only if IPsec
state synchronization mechanism is available (outside of Home
Agent Reliability Protocol). The IPsec state per mobile node MUST
be shared between the active home agent and standby home agents in
the background. The active and the standby home agents are
addressed by the same home agent address, although only the active
home agent is accessible with the home agent address. Each mobile
node negotiates just one Security Association with the active home
agent. In case there is a failure of the active home agent, the
standby home agent takes over without the mobile node being aware
of the change in the home agent.
Home Agent Hard Switch
In the Home Agent Hard Switch, IPsec/IKE states synchronization is
not required. The home agents are addressed by different IP
addresses. When an active home agent fails, a mobile node will
receive a notification (Home Agent Switch message [RFC-5142]) from
a standby home agent, and send a Binding Update to the standby
home agent. In order for the mobile node to receive the Home
Agent Switch message securely from the standby home agent, the
mobile node needs to establish an IPsec SA with both the active
and the standby home agents beforehand.
2. Terminology 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 to both a mobile node
[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)
Providing reliability by using multiple home agents with
individual home agent addresses. It requires binding re-
registration to the new home agent.
Virtual Home Agent Reliability Protocol (VHARP)
Providing reliability by using multiple home agents and single
virtual home agent address. It can virtually switch to the new
home agent without binding re-registration to the new home agent.
Active Home Agent Active Home Agent
A home agent that is currently serving the mobile nodes. A home agent that is currently serving the mobile nodes.
Standby Home Agent Standby Home Agent
A home agent which will serve the mobile nodes when the active A home agent which will serve the mobile nodes when the active
home agent fails. home agent fails.
Failed Home Agent Failed Home Agent
A home agent that is not available due to hardware or software A home agent that is not available due to hardware or software
failure, system maintenance, etc. failure, system maintenance, etc.
Redundant Home Agent Set Redundant Home Agent Set
A group of active and standby home agent(s). The Group Identifier A group of an active and standby home agent(s). The Group
is used to identify a redundant home agent set. Identifier is used to identify a redundant home agent 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 and used only in the Home Agent Virtual Switch case. agent set. It is similar to virtual router address specified in
The address is only activated on an active home agent. VRRP [RFC-3768] [RFC-5798]. The address is only activated on an
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. However, an operator can also define an
independent value used only for the home agent reliability independent value used only for the home agent reliability
protocol if the operator wants to have different preference values protocol if the operator wants to have different preference values
for DHAAD and the home agent reliability protocol. A home agent for DHAAD and the home agent reliability protocol. A home agent
SHOULD NOT use the same preference value of other home agents. SHOULD NOT use the same preference value of other home agents.
3. Problem Statement and Requirements New Messages
In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a Home Agent Reliability Protocol (HARP) message defined in
binding with only one home agent. Thus the home agent represents the Section 6.1.1:
possibility of a single point of failure for Mobile IPv6. A home
agent is responsible for multiple mobile nodes on its home link. The SwitchOver Request (SWO-REQ)
failure of the home agent may then result in the loss of connectivity
for numerous mobile nodes located throughout the Internet. To SwitchOver Reply (SWO-REP)
overcome this problem, Mobile IPv6 allows deployment of multiple home
agents on the home link so that upon the failure of a home agent, a SwitchBack Request (SWB-REQ)
mobile node can re-establish its connection through a new home agent.
However, the base Mobile IPv6 specification does not address home SwitchBack Reply (SWB-REP)
agent failover and dynamic transfer of service from one home agent to
another. This transfer of service from the failed home agent to a Switch Complete (SW-COMP)
new active home agent requires coordination or pre-configuration
among the home agents regarding security associations, transfer of Home Agent HELLO (HA-HELLO)
mobile node bindings, and other service information for reliable
Mobile IPv6 service in a deployment scenario. State Synchronization (SS) message defined in Section 6.1.2:
State Synchronization Request (SS-REQ)
State Synchronization Reply (SS-REP)
State Synchronization Reply-Ack (SS-ACK)
1.2. Problem Statement and Requirements
In Mobile IPv6 [RFC-3775, RFC-4877], a mobile node registers and
establishes a binding with only one home agent. The home agent
represents the possibility of a single point of failure for Mobile
IPv6. A home agent is responsible for multiple mobile nodes on its
home link. The failure of the home agent may then result in the loss
of connectivity for numerous mobile nodes located throughout the
Internet. To overcome this problem, Mobile IPv6 allows deployment of
multiple home agents on the home link so that upon the failure of a
home agent, a mobile node can re-establish its connection through a
new home agent. However, the base Mobile IPv6 specification does not
address home agent fail-over and dynamic transfer of service from one
home agent to another. This transfer of service from the failed home
agent to a new active home agent requires coordination or pre-
configuration among the home agents regarding security associations,
transfer of mobile node bindings, and other service information for
reliable Mobile IPv6 service in a deployment scenario.
For the home agent reliability solution, we define the following For the home agent reliability solution, we define the following
requirements: requirements:
Reliable Home agent service Reliable Home agent service
Multiple home agents are available for a home prefix and one of Multiple home agents are available for a home prefix and one of
them actively serves the mobile nodes. A standby home agent takes them actively serves the mobile nodes. A standby home agent takes
over when the active home agent becomes unavailable. The transfer over when the active home agent becomes unavailable. The transfer
of the MN-HA association should be transparent to applications and of the MN-HA association should be transparent to applications and
skipping to change at page 7, line 11 skipping to change at page 7, line 23
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, synchronizing the
configurations of the Authentication protocol is out of scope in configurations of the Authentication protocol is out of scope in
this document. Operators MAY correctly set the configuration 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 10. home agent set. The details are described in Section 7.
Secured Message Exchanges Secured Message Exchanges
The messages used between the home agents to transfer binding The messages used between the home agents to transfer binding
cache information MAY be authenticated and encrypted. cache information MAY be authenticated and encrypted.
Failure Detection Failure Detection
Redundant home agents must actively check for possible failure of Redundant home agents must actively check for possible failure of
an active home agent. If a home agent supports an existing an active home agent. If a home agent supports an existing
skipping to change at page 8, line 5 skipping to change at page 7, line 45
2281], it can re-use that mechanism to detect the home agent 2281], it can re-use that mechanism to detect the home agent
failure. On the other hand, periodic Hello messages are failure. On the other hand, periodic Hello messages are
introduced to detect active home agent's service availability in introduced to detect active home agent's service availability in
this document. this document.
Failure Notification Failure Notification
If necessary, a mobile node is notified about the active home If necessary, a mobile node is notified about the active home
agent failure by the standby home agent. agent failure by the standby home agent.
4. Protocol Overview 2. Protocol Overview
4.1. Home Agent Virtual Switch 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 and receives a
binding update from mobile nodes. According to [RFC-3775, RFC-4877],
an active home agent maintains not only binding cache but also IPsec/
IKEv2 states per mobile node, because Mobile IP adapts IPsec as its
security mechanism for signaling.
A mobile node remains unaware about the change in the active home If the active home agent fails, all these information per mobile node
agent since the home agents have replicated all session state is vanished. As a result, all mobile nodes served by the failed home
including IPsec/IKE states. IPsec/IKE state transfer is out of scope agent will be disconnected. In HARP, other home agents , named
of this document. standby home agent, exchange the required information with the active
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
information of the serving mobile nodes.
MN HA1(active) HA2(Standby) MN HA1 HA2
| | . | |<-HA1-addr |<-HA2-addr
|<--------->| | 1. IKE exchange (with HoA assignment) | | |
|---------->| . 2. Binding Update | (active) (standby)
|<----------| . 3. Binding Acknowledgment | | |
| | . | |<--------->| 1. Hello exchanges
| |<--------->. 4. State exchanges (binding cache/IPsec) |<--------->| | 2. Binding Registration to HA1
| | . | |<--------->| 3. State exchanges
| X . HA1 FAILURE | | |
| X . | X | HA1 FAILURE
| X<----------. 5. Failure Detection | X |
| X | 6. HA2 takes over the HA1 | X | 4. Failure Detection
|<----------------------| 5. Sending Home Agent Switch message
|<--------------------->| 6. Binding Registration to HA2
| X (active) RECOVERY COMPLETE
| X | | X |
| X | RECOVERY COMPLETE
Figure 1: Overview of Home Agent Virtual Switch
The operations of the Home Agent Virtual Switch mode are shown in Figure 1: Overview of Home Agent Reliability Protocol (HARP)
Figure 1. A mobile node first attempts the IKE exchange for Security
Association (SA) setup and home address assignment (1). After
binding registration is done (2, 3), the active home agent pushes all
the states of its mobile nodes with a state synchronization message
(4). The standby home agent(s) is not active unless it takes over
from a failed home Agent.
When the active home agent's failure is detected (5), the standby Figure 1 shows an example of the HARP operations. HA1 and HA2 belong
home agent activates the virtual home agent address on its interface to the same redundant home agent set and are assigned with an
and takes over for the failed home agent. All the home agents in the individual IP address (HA1 and HA2-addr) at the home link. Each home
redundant home agent set share a virtual home agent address and the agent can be seen as an individual home agent by mobile nodes. All
routing will ensure only the active home agent will be reachable the home agents periodically send a hello message (named HA-HELLO) to
using that virtual home agent address. The standby home agent can exchange the home agent information and also monitor the active home
serve all the mobile nodes for which the states are synchronized, agent's status (1). The mobile node registers its binding only with
without any further message exchange, because it has all the the active home agent (2). The active home agent synchronizes the
necessary information which it obtained from the failed home agent. serving mobile node information (i.e. home address) with the other
standby home agents periodically (3).
4.2. Home Agent Hard Switch HARP introduces the new HA-HELLO message for failure detection, but
it should use any types of information to detect that failure. After
detecting failure of the active home agent (4), a standby home agent
whose preference value is the highest takes over the failed home
agent. For doing so, the standby home agent sends a Home Agent
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
the Home Agent Address field in the Home Agent Switch message so that
it will receive the binding update from the mobile node as an
acknowledgment of the sent Home Agent Switch message. The home agent
switch-over is complete when it receives binding updates from all the
mobile nodes (6). For protecting the Home Agent Switch, the mobile
node should have IPsec Security Associations (SA) with the standby
home agent before any failover. The mobile node may pre-establish
multiple IPsec SAs with all the home agents.
The overview of the Home Agent Hard Switch is shown in Figure 2. Although the active home agent manages IPsec/IKEv2 states per mobile
This mode is not transparent to the mobile node when the active home node, HARP does not offer any recovery mechanism of these states by
agent failure occurs. itself. IPsec/IKE states synchronization is out of scope in this
document. However, some Virtual Private Network (VPN) products have
proprietary IPsec/IKEv2 state synchronization among multiple boxes.
If IPsec/IKEv2 states can be recovered from the active home agent to
standby one, HARP can be operated slightly in different manner named
Virtual-HARP (VHARP). Unlike HARP, the standby home agents are an
exact copy of the active home agent. It is similar to the virtual
router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. Note
that HARP is mandatory and VHARP is optional in this document. VHARP
is shown in Figure 2.
MN HA1(active) HA2(Standby) MN HA1 HA2
| | | | |<-HA-addr :<-HA-addr'
|<--------->| | 1. IKE exchange (with HoA assignment) | | :
|---------->| | 2. Binding Update | (active) (standby)
|<----------| | 3. Binding Acknowledgment |<--------->| : 1. Binding Registration to HA1
|<--------------------->| 4. IKE exchange (without HoA assignment) | |<--------->: 2. State exchanges
| | | | | :
| |<--------->. 5. State exchanges (binding cache) | X : HA1 FAILURE
| | | | X :
| X | HA1 FAILURE | X : 3. Failure Detection
| X | | X | 4. HA2 takes over the HA1
| X<----------| 6. Failure Detection | X (active) RECOVERY COMPLETE
|<----------------------| 7. Sending Home Agent
| X | Switch message
|<--------------------->| 8. Binding Registration
| X | | X |
| X | RECOVERY COMPLETE
Figure 2: Overview of Home Agent Hard Switch Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP)
The mobile node establishes IPsec/IKE state with all the home agents All the home agents (HA1 and HA2) in the redundant home agent set
in the redundant home agent set beforehand (1 and 4), however it share a virtual home agent address (HA-addr) and the routing will
registers its binding only with the active home agent (2 and 3). ensure only the active home agent will be reachable using that
When an active home agent fails, a standby home agent uses a pre- virtual home agent address. After a mobile node's binding
existing IPsec SA to notify the mobile node about the failure by registration (1), the active home agent pushes all the states of its
securely sending a Home Agent Switch message. In order to discover mobile nodes to the other standby home agents (2). In VHARP, all the
home agent addresses, two different mechanisms are defined, as states of a mobile node need to be synchronized. The example
described in Section 9.5.1. The active home agent synchronizes the information such as Binding Cache and Authentication, Authorization,
required states of the mobile nodes, such as Binding Cache and AAA and Accounting (AAA) information, etc.
information, with other standby home agents periodically (5). The
mobile node MUST NOT request a home address(es) assignment through
the IKE exchange to the standby home agent when it establishes an SA
with it (4).
When the standby home agent detects the failure of the active home After detecting the active home agent has failed (3), the standby
agent (6), it sends a Home Agent Switch message to all the mobile home agent whose preference value is the highest takes over the
nodes that were registered with the failed home agent (7). The Home failed home agent. The standby home agent activates the virtual home
Agent Switch message must be encrypted by a pre-established IPsec SA. agent address on its interface attached to the home link. The
After the switch message, the mobile node MUST send a binding update virtual home agent address's activation can be operated by VRRP.
to the new active home agent in order to update the Mobile IPv6 Since all the necessary states of mobile nodes have already been
tunnel endpoints (8). transferred to this standby home agent, the standby home agent can
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
active home agent. The mobile node may use the IKEv2 resumption
mechanism [RFC-5723] to resume IPsec SA with the new active home
agent.
4.3. Home Agent Management This document offers a new management mechanism of an active and
standby home agents by using a new Mobility Header (MH) message named
a HARP message as shown in Figure 3. This mechanism can be used in
both HARP and VHARP. Each home agent exchanges own home agent
information with the other home agents in its redundancy home agent
set by a Home Agent HELLO message (HA-HELLO) (1). The HA-HELLO
message can also be used to monitor the availability of the active
home agent.
HA1(active) HA2 HA3 .. HAn HA1(active) HA2 HA3 .. HAn
| | | | | | | |
|------->| | | 1. HA1 sends SwitchBack Request |<------>|<---->|<---->| 1. HELLO exchange
|<-------| | | 2. HA2 sends SwitchBack Reply |------->| | | 2. HA1 sends SWB-REQ
| | | | |<-------| | | 3. HA2 sends SWB-REP
|<-------| | | 3. HA2 sends SwitchCompl (optional) |------->| | | 4. HA2 sends SW-COMP
(standby) (active) | | HA2 BECOMES ACTIVE HA (standby) (active) | | HA2 BECOMES ACTIVE HA
| | | | | | | |
SYSTEM MAINTENANCE, ETC. SYSTEM MAINTENANCE, ETC.
| | | | | | | |
|------->| | | 4. HA1 sends SwitchOver Request |------->| | | 5. HA1 sends SWO-REQ
|<-------| | | 5. HA2 sends SwitchOver Reply |<-------| | | 6. HA2 sends SWO-REP
| | | | |------->| | | 7. HA1 sends SW-COMP (optional)
|------->| | | 6. HA1 sends SwitchCompl (optional) (active) (standby) | | 8. HA1 returns to active HA
(active) (standby) | | 7. HA1 returns to active HA
| | | | HA1 BECOMES ACTIVE AGAIN | | | | HA1 BECOMES ACTIVE AGAIN
Figure 3: Manual Home Agent Change 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 provides for
a manual home agent switch by using SwitchBack Request and Reply a manual home agent management. As shown in Figure 3, the active
messages. As shown in Figure 3, the active home agent (HA1) sends a home agent (HA1) sends a SwitchBack Request message (SWB-REQ) to a
SwitchBack Request message to a standby home agent (HA2). As soon as standby home agent (HA2) (2). HA2 will acknowledge the message by
HA2 receives the message, it becomes the active home agent. HA2 will sending a SwitchBack Reply message (SWB-REP) to HA1 (3). In the HARP
acknowledge the message by sending a SwitchBack Reply message to HA1. operation, it takes certain time to complete home agent fail-over by
HA1 becomes a standby home agent when it receives the SwitchBack mobile nodes' re-registration to the new home agent. During this
Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in fail-over operations, HA1 may continue serving the mobile nodes until
order to become the active home agent again. the switch over is completed. When HA2 completes the switch-over, it
SHOULD send a SW-COMP to HA1 (4). As soon as HA2 sends the SW-COMP,
it becomes the active home agent. HA1 becomes standby when it
receives SW-COMP.
The SwitchCompl message is used only in the Home Agent Hard Switch. After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2
As shown in Section 9, it takes certain time to complete the home in order to become the active home agent again (5). HA2 acknowledge
agent switch. Thus, the old active home agent continues serving the it by sending a SwitchOver Reply (SWO-REP) to HA1 (6). HA1 now
received packets for the mobile nodes during the switch process. As starts home agent fail-over operation. After the completion of fail-
soon as the new home agent completes the recovery, it sends over, HA1 sends a SW-COMP to HA2 (7). Then, HA1 returns to the
SwitchCompl message to the previous active home agent. SwitchCompl active home agent and HA2 fall back to a standby home agent (8).
is an optional operation in this specification.
5. Messages 3. Home Agent Configuration
5.1. New Mobility Header Messages 3.1. Network Configuration
5.1.1. State Synchronization Message HARP supports two different configurations for standby home agents.
Standby home agents can be placed on the same home link or on a
different link. Figure 4 depicts the configuration where home agents
serving the same home network are located on the same link as defined
in [RFC-3775].
This message is used to exchange state corresponding to a particular HA1 HA2 HA3 HA4 .... HAn
mobile node(s). It MUST be unicasted and MUST be authenticated by | | | | |
IPsec ESP. This message has the MH Type value TBD. --------+------+------+------+--------+---------
Home Link
0 1 2 3 Figure 4: Local Recovery Configuration
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: State Synchronization Message Figure 5 illustrates when standby home agents are located on a
different link (illustrated as Recovery Link in Figure 5). Most
large operators have a very stringent requirement on network
availability even in the worst type of disaster or outage. This
configuration can achieve home agent recovery even if the entire home
link fails. This is called geographic redundancy and a well-known
configuration for Telecommunications operators. In Figure 5, home
agents (HA1-HA4) are placed in geographically separated regions
(region-1 and -2). If region-1 suffers a down time due to any
reason, all the sessions will be seamlessly taken over by the nodes
in region-2. Note that HA3 and HA4 cannot receive packets meant for
the home network until the route on the Routers is changed. The
routing must be also updated to direct the packets meant for the home
link to the recovery link.
Type ---------IGP------>|<---BGP--->|<-----IGP---------
8-bit unsigned integer. It can be assigned one of the following HA1 HA2 HA3 HA4
values: | | | |
--------+------+-----+ R---R---R +-----+------+-------
Home Link Routers Recovery Link
(region-1) (region-2)
0: Request Figure 5: Global Recovery Configuration
This message is called State Synchronization Request (SS-REQ) 3.2. Home Agent Address Configuration
and used to solicit the active state corresponding to a
particular mobile node.
1: Reply In HARP, each home agent obtains its individual IPv6 address from its
serving home prefix. In VHARP, all the home agents use a virtual
home agent address generated from the home prefix.
The message is called State Synchronization Reply (SS-REP) and In addition, each home agent running VHARP need to obtain its
is used between the home agents in the redundant home agent set individual IPv6 address from its attached link. This IPv6 address is
to exchange binding cache information and any other information used only for the VHARP operations between home agents and is not
related to providing mobility service to the mobile nodes revealed to mobile nodes for binding registration.
either periodically or in response to a SS-REQ.
2: Reply-Ack All the home agents MUST join the ALL_HA_MULTICAST_ADDR. In VHARP,
each home agent join the multicast group with its individual IPv6
address, but not with virtual home agent address. This multicast
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
defined, each home agent always unicasts the HARP messages to home
agents configured at a geographically separated link.
The message is called State Synchronization Reply-Ack (SS-ACK) 4. Home Agent Operations
and is used to acknowledge the SS-REP. This message is
optional and is specially used when the links between home
agents are not reliable.
Ack flag 4.1. Home Agent List Management
This flag is valid only for SS-REP. If the sender requires In Mobile IPv6, each home agent periodically sends router
explicit acknowledgment by SS-ACK, it MUST set this flag. advertisements with the Home Address Information option [RFC-3775].
HARP introduces a HARP HA-HELLO message to replace the router
advertisement. There are several reasons to use HA-HELLO message
instead of the Router Advertisement such as:
Reserved o A HA-HELLO message can be sent beyond the link, while a router
advertisement cannot be sent beyond the link. In case of
geographic redundancy, router advertisements cannot be sent to the
recovery link unless the home link and the recovery link are
virtually connected by L2TP, etc.
This field is unused. It MUST be initialized to zero by the o A HA-HELLO message is defined to manage additional information
sender and MUST be ignored by the receiver. such as Group ID and Active/Standby Status of the home agents in
the home agent list.
Identifier o A HA-HELLO message is exchange only between home agents, while a
router advertisement is also processed by mobile nodes attached to
a home link. A HA-HELLO does not introduce any burden to the
mobile nodes even if it is frequently sent on the home link.
A 16-bit identifier to aid in matching state synchronization When a HA-HELLO is used to exchange the home agent information, each
message. The identifier should never be set to 0. It should home agent SHOULD NOT process the Home Agent Information option
always be more than 1. carried by a Router Advertisement. A router advertisement is only
processed by mobile nodes. Operators may define different
configuration values to the parameters of the home agent information
for a HA-HELLO and a Router Advertisement.
Mobility Options This document requires additional information to the home agent list
defined in [RFC-3775]. The additional information is learned through
HA-HELLO message exchange.
Variable-length field of such length that the complete Mobility o Group ID of a redundant home agent set. It is learned through the
Header is an integer multiple of 8 octets long. This field Group ID field of the HA-HELLO.
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in [RFC-3775]. The
receiver MUST ignore and skip any options which it does not
understand. This message requires at least one mobility option,
therefore, there is no default length for this message.
One of the following options is mandatory in SS-REQ message. o HA-HELLO Interval. This value is locally configured at every home
Multiple same options can be stored in the same SS-REQ message, agent by operators and is learned through the Hello Interval field
(ex. two IP address options for two mobile nodes): of the HA-HELLO.
* IP Address Option (Sub-type: Home Address) defined in [RFC- o An individual home agent address used in the VHARP operation.
5268]. If a home agent wants the Binding Cache information for This information is only required when VHARP is used in addition
a particular mobile node, it includes the mobile node's home to the virtual home agent address. It is learned through the
address in an IPv6 Address Option. If a home agent wants to Source Address of the HA-HELLO message.
solicit all the active mobile nodes' states, it can include the
unspecified address (::) in an IPv6 address option.
* Mobile Network Prefix Option. If a home agent wants to know o VHARP capability. This information is learned through the V flag
the forwarding state setup for a particular Mobile Network of the HA-HELLO message.
Prefix, it includes a Mobile Network Prefix Option as defined
in [RFC-3963].
* The Mobile Node Identifier option defined in [RFC4283]. If a o Current mode (HARP or VHARP). This information is learned through
home agent wants the Binding Cache information for a particular the M flag of the HA-HELLO message.
mobile node, it can include the mobile node's identifier (ex.
Network Access Identifier (NAI) [RFC4282]) in this option.
* Vendor Specific Mobility Option. If a home agent wants vendor o Active status. This information is learned through the A flag of
specific information, it can solicit with this option as the HA-HELLO message.
defined in [RFC-5094].
One of the following options is mandatory in SS-REP: 4.2. Detecting Home Agent Failure
* Binding Cache Information Option An active and standby home agents can monitor each other in several
ways. One method is to reuse other failure detection mechanisms
defined in VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. However,
VRRP and HSRP are not sufficient since they cannot detect the case
where the system is running but the Mobile IPv6 stack is not
operational. Failure events used in HARP/VHARP are listed below.
* AAA Information Option Loss of HA-HELLO
* Vendor Specific Mobility Option HARP/VHARP is an extension to Mobile IPv6 and can monitor
availability of Mobile IPv6 stack on each home agent by
periodically sending a HA-HELLO as a heart-beat. This HA-HELLO
can also be exchanged frequently enough to detect the failure
promptly without any additional overhead to mobile nodes attached
to the home link. In the event that a standby home agent does not
receive any HA-HELLOs from its peer for a configurable duration,
the standby home agent assumes that home agent's failure. The
detail of the Hello message is described in Section 4.3.2.
5.1.2. Home Agent Control Message Monitored Server Failure by the Active Home Agent
This message is used to control the status of a home agent to either There may be number of critical servers such as an AAA server in
active or standby. This message MUST be unicasted between home the network that are essential for the ongoing Mobile IPv6
agents and MUST be authenticated and encrypted by IPsec ESP. The sessions at the home agent. Operators can have a policy in place
Home Agent Control message has the MH Type value TBD. If no options that the active home agent is treated as a failed home agent upon
are present in this message, no padding is necessary and the Header detecting that the link to such servers has failed.
Len field will be set to 1.
0 1 2 3 Routing Peer/Link Failure
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Home Agent Control Message Operators may require the home agent to detect its next-hop
routing peer failure. If the next-hop routing failure is fatal in
nature, or due to some other routing policies, the active home
agent is treated as a failed home gent and the recovering
operation should be started.
Type 4.3. Processing the HARP Messages
8-bit unsigned integer. It can be assigned one of the following 4.3.1. IP field and Security Descriptions of HARP message
values:
0: SwitchOver Request (SO-REQ) 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
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
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,
the virtual home agent address SHOULD NOT be set to source and
destination address. The IP address of the interface the packet is
being sent from SHOULD be used.
It is unicasted by a standby home agent that desires to become If a HARP message is unicasted, it SHOULD be authenticated by IPsec
the active home agent. The receiver of the message MUST AH and MAY be encrypted by IPsec ESP. If a HA-HELLO message is
transition to standby state as soon as the message is received multicasted, multicast extensions to IPsec [RFC-5374] SHOULD be
and validated successfully. applied. If all the home agents are placed in a secure transport
network to exchange a HARP message, authentication and encryption MAY
be omitted. Which security verification is used depends on
operational policy. If security verification is failed for a
receiving HA-HELLO, the HA-HELLO MUST be discarded.
1: SwitchOver Reply (SO-REP) The following operations MUST be performed when transmitting a HARP
message.
It is used to acknowledge the receipt of the corresponding SO- o The incremented latest Sequence Number MUST be set to the Sequence
REQ. Number field. The Sequence Number SHOULD be initialized to zero
for the first Hello message. To accomplish sequence number
rollover, if the sequence number has already been assigned to be
the largest possible number representable as a 16-bit unsigned
integer, then when it is incremented it will then have a value of
zero (0).
2: SwitchBack Request (SB-REQ) o The sender's Group ID MUST be set to the Group ID field.
It is unicasted by an active home agent that desires to become o The V-flag MUST be set if the sender is capable of VHARP.
a standby home agent. The receiver of this message SHOULD
transition to active state as soon as the message is received
and validated successfully.
3: SwitchBack Reply (SB-REP) o The M-flag MUST be unset if the sender is operated with HARP.
It is used to acknowledge the receipt of the corresponding SB- o The M-flag MUST be set if the sender is operated with VHARP.
REQ.
4: Switch Complete (SW-COMP) o The A-flag MUST be set if the sender is the active home agent.
This message is used to indicate the completion of switch over, Performed the following functions when a HARP message is received.
(i.e. sending home agent switch messages and receiving binding
update messages from all the served mobile nodes).
Status o MUST verify the Group ID of the HARP message is equal to the
receiver's Group ID.
8-bit unsigned integer indicating the disposition of a SO-REQ or o MUST verify the sender of the HARP message belongs to the
SB-REQ. This field is only valid in SO-REP and SB-REP. The receiver's same redundant home agent set
following Status values are defined:
0: Success o MUST verify that the M flag is equal to the receiver's operating
mode.
128: Reason unspecified o MUST verify the Sequence Number value in the HARP is larger than
the last received Sequence Number value. When the sequence number
rollover is occurred, the sequence number value in the HA-HELLO is
zero.
129: Administratively prohibited If any one of the above checks fails, the receiver SHOULD discard the
HARP message.
130: Not active home agent (The receiver of SO-REQ is not the 4.3.2. Processing Home Agent Hello (HA-HELLO)
active home agent)
131: Not standby home agent (The receiver of SB-REQ is already
the active home agent)
132: Not in same redundant home agent set 4.3.2.1. Sending HA-Hello Message
Mobility Options Each home agent MUST send a HA-HELLO in following case:
No options are defined in this specification o UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO.
The interval time is configured locally at each home agent.
5.1.3. Home Agent Hello Message o UNSOLICITED: When a home agent detects its local information
change, it should immediately send a HA-HELLO.
The Home Agent Hello (HA-HELLO) message MUST be either unicasted or o SOLICITED: when a home agent receives a HA-HELLO with the R-flag
multicasted to carry home agent information among the redundant home set. When the R-flag is set, the HA-HELLO can be requested to the
agent set. The HA-Hello message is defined for two purpose: 1) an destination home agent.
alive check and 2) home agent information exchange. A HA-HELLO
SHOULD be authenticated and encrypted by IPsec ESP when it is
unicasted. If a HA-Hello message is multicasted, IPsec ESP cannot be
applied. In this case the redundant home agent set should be located
in a secure network. Alternatively, all the home agents MUST have a
secure channel with each other. The HA-Hello has the MH Type value
TBD. If no options are present in this message, 0 octets of padding
are necessary and the Header Len field will be set to 2.
0 1 2 3 A home agent can solicit a HA-HELLO to a particular home agent(s) in
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 the same redundant home agent set by unicasting or multicasting a HA-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HELLO with the R-flag set. Soliciting HA-HELLO is operated when:
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | Group ID |A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Home Agent Hello Message 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
set.
Sequence # o A HA-HELLO has not been received after the specified hello
16-bit unsigned integer. The Sequence number of the HA-Hello interval. The HA-HELLO MAY be solicited to the home agent.
message can be used to verify whether this Hello message is the
latest one or not.
Home Agent Preference o A home agent entry in the redundant home agent set is about to be
removed due to home agent lifetime expiration. The HA-HELLO
SHOULD be solicited to the home agent whose lifetime is soon
expired.
16-bit unsigned integer. The preference for the home agent In addition to Section 4.3.1, the following operations MUST be
sending the HA-Hello message. This preference is the same as the performed when transmitting a HA-HELLO.
Home Agent Preference value of the Home Agent Information option
as defined in [RFC-3775]. However, operators MAY use a different
preference value for this operation.
Home Agent Lifetime o The Type field MUST be set to 4.
16-bit unsigned integer. The lifetime for the home agent sending o The R-flag MUST be set if the sender solicits a HA-HELLO to the
the HA-Hello message. This lifetime is the same as the Home Agent other home agent(s).
Lifetime value of the Home Agent Information option as defined in
[RFC-3775].
Hello Interval o The appropriate home agent configuration values MUST be copied to
the Home Agent Preference, the Home Agent Lifetime, and Hello
Interval fields.
16-bit unsigned integer. The interval for the home agent sending 4.3.2.2. Receiving Hello Message
this Hello message.
Group Identifier The receiver MUST perform the verification to the HA-HELLO described
in Section 4.3.1. After the verification, the receiver copies the
value stored in the HA-HELLO message to the corresponding home agent
list entry according to Section 4.1.
8-bit unsigned integer. This value is used to identify a If the home agent lifetime field in the HA-HELLO is set to 0, the
particular redundant home agent set. receiver MUST remove the sender home agent from the home agents list.
A flag 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.
Active Home Agent flag. If this flag is set, the sender of this 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP)
HA-Hello message is an active home agent.
R flag When a standby home agent decides to become an active home agent, the
standby home agent sends a SwitchOver Request (SWO-REQ) to the
current active home agent with the following operations.
HA-HELLO requesting flag. If this flag is set, the receiver of o MUST be unicasted only to the current active home agent
this HA-Hello message must send back a HA-Hello message to the
sender.
Reserved o MUST be sent from a standby home agent. The active home Agent
MUST NOT generate this message.
This field is unused. It MUST be initialized to zero by the When an active home agent receives a SWO-REQ, it MUST operate the
sender and MUST be ignored by the receiver. following verification and operations in addition to Section 4.3.1:
Mobility Options 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
home agent).
No valid options are defined in this specification. 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
the Status field set to 132 (Not in same redundant home agent
set).
5.1.4. Home Agent Rekey Message o There is a case where the active home agent cannot be standby home
agent. The active home agent MUST reply a SWO-REP with the Status
field set to 129 (Administratively prohibited).
This message is used to indicate that the mobile node SHOULD start an o Otherwise, the active home agent MUST become a standby home agent
IPsec re-key with the home agent specified in the Home Agent and reply with a SWO-REP message with the Status field set to 0
Addresses field. This message is used when a failed home agent (Success).
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
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
are present in this message, no padding is necessary and the Header
Len field will be set to 2.
0 1 2 3 When a standby home agent receives a SWO-REP, it MUST operate the
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 following verification and operations in addition to Section 4.3.1:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. Home Agent Addresses .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Home Agent Rekey Message o If the receiver is an active home agent, the SWO-REP MUST be
discarded.
Reserved 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.
The reserved field is 16 bits o Otherwise, if the Status field of the SWO-REP is 0 (Success), the
standby home agent (the receiver of SWO-REP) immediately becomes
an active home agent.
Home Agent Address o If the value in the Status field is greater than 128 an error has
occurred. In this case, the receiver MUST NOT attempt to be an
active home agent.
The receiver of this message MUST rekey the security asscoation 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP)
with the specified home agent.
5.2. New Mobility Options When an active home agent decides to become a standby home agent, it
5.2.1. IP address Option sends a SWB-REQ to one of standby home agents. The reason for the
active home agent to send this message can be administrative
intervention, and events like Monitored Server Failure by the active
home agent or Routing Peer/Link Failure. The following operations
MUST be performed when SWB-REQ is sent.
This option is already defined in the Fast Handovers for Mobile IPv6 o MUST be unicasted only to one of standby home agents in the same
(FMIP) specification [RFC-5268]. This document introduces new Sub- redundant home agent set
Type values for home agent address and Home Address.
Option-Code o MUST be sent from an active home agent. The standby home Agent
MUST NOT generate this message.
* 4: Home Address When a home agent receives a SWB-REQ message, it verifies the message
as follows.
5.2.2. Binding Cache Information Option 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
set to 130 (Not active home agent).
The binding cache information option has an alignment requirement of o If the sending home agent does not belong to the same redundant
8n+2. The Binding Cache Information option is only valid in a State home agent set, a SWB-REP MUST be sent in which the Status field
Synchronization message. Its format is as follows: set to 132 (Not in same redundant home agent set).
0 1 2 3 o Otherwise, the receiving home agent MUST send a SWB-REP with the
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Status field is set to 0 (Success).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Mobile Network Prefix Option .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Binding Cache Information Option
The fields of Home Address, Care-of Address, Flags, Sequence Number, o After sending the SWB-REP, the standby home agent MUST NOT become
and Lifetime are copied from the registered binding of a particular an active home agent immediately. This is because the active home
mobile node or mobile router. The 16-bit Reserved field MUST be set agent is still active until it receives the SWB-REP which is
to zero. If the R-flag is set to indicate this binding cache entry acknowledging the SWB-REQ. The standby home agent SHOULD change
is for a mobile router, then this option will be immediately followed to active at least after LINK_TRAVERSAL_TIME.
by one or more Mobile Network Prefix options.
5.2.3. AAA Information Option When a home agent receives a SWB-REP message, it verifies the message
as follows.
This option is used to carry the AAA state of the mobile node's o If the standby home agent receives an unexpected SWB-REP which is
Mobile IPv6 sessions. The AAA state information can be carried in not in reply to own SWB-REQ, it SHOULD ignore the SWO-REP.
RADIUS or Diameter AVP formats including the user and session info.
This information option is only valid in a State Synchronization
message.
0 1 2 3 o If the Status field of the SWB-REP is 0 (Success), the active home
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 agent immediately becomes a standby home agent. The sender home
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ agent of SWB-REP becomes an active home agent after certain time,
| Type = TBD | Length | LINK_TRAVERSAL_TIME.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. AAA AVPs .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Vendor Specific Information Option 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
and MUST continue to be an active home agent.
Type 4.4. State Synchronization
8-bit Type value. The value is TBD. A State Synchronization (SS) message format is defined in
Section 6.1.2. It can carry several state information about a mobile
node by setting mobility options in the Mobility Options field. The
following list shows examples of the mobility options which can be
specified in the state synchronization message.
Length o IPv6 Home Address (Binding Cache Option)
8-bit length value. o Binding Cache Information (Binding Cache Option)
AAA AVPs o NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC-
3963])
Series of TLV encoded AAA AVPs (including vendor specific AVPs) o IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555])
carrying AAA-related information for each Mobile IPv6 and IPsec/
IKE session.
6. Home Agent Configuration o IPv4 Home Address (IPv4 Home Address Option [RFC-5555])
6.1. Network Configuration o Binding Identifier (Binding Identifier Option [RFC-5648]
The Home Agent Reliability protocol supports two different o AAA states (AAA Information Option)
configurations for standby home agents. Standby home agents can be
placed on the same home link or on a different link.
HA1 HA2 HA3 HA4 .... HAn o Miscellaneous states (Vendor Specific Mobility Option [RFC-5094])
| | | | |
--------+------+------+------+--------+---------
Home Link
Figure 10: Local Recovery Configuration When a home agent need to send the state of multiple mobile nodes in
a single state synchronization message (SS-REQ or SS-REP), a Binding
Cache Information option is used as a separator. For each mobile
node, a Binding Cache Information option is placed first, followed by
any other options related to the mobile node if necessary.
Figure 10 depicts the configuration where home agents serving the In HARP, since a mobile node will re-register to the new active home
same home network are located on the same link. For example, HA2, agent after home agent fail-over, it is not necessary for the standby
HA3 and HA4 are standby home agents of HA1. This is the same as what home agents to synchronize all the mobile nodes' state information.
Mobile IPv6 defines for home agent configuration. The standby home agent only need to collect the home address
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 mobile node when the home agent failure is occurred.
---------IGP------>|<---BGP--->|<-----IGP--------- In VHARP, home agent fail-over is completed without mobile nodes'
binding re-registration. Therefore, standby home agents need to copy
the complete state information of each mobile node registered with
the active home agent.
HA1 HA2 HA3 HA4 4.4.1. Binding Cache Information Management
| | | |
--------+------+-----+ R---R---R +-----+------+-------
Home Link Routers Recovery Link
(region-1) (region-2)
Figure 11: Global Recovery Configuration 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
registering home agent address. This information is stored somewhere
in a standby home agent.
Figure 11 illustrates when standby home agents are located on a In VHARP, a standby home agent ideally copies the received binding
different link (illustrated as Recovery Link in Figure 11). Most cache information and other mobile node's information into the
large operators have a very stringent requirement on network appropriate database so that it can act as an active home agent as
availability even in the worst type of disaster or outage. For soon as it takes over the failed home agent.
example, HAs in region-1 are backed up by HAs in region-2. These two
regions are geographically separated. If region-1 suffers a downtime
due to any reason, all the sessions will be seamlessly taken over by
the nodes in region-2. This is called geographic redundancy. This
is a well-known configuration for Telecommunications operators. It
can achieve home agent recovery even if the entire home link fails.
In Figure 11, HA3 and HA4 are standby home agents of HA1 and HA2. In
this case, HA3 and HA4 cannot receive packets meant for the home
network until the route on the Routers is changed. The routing must
be also updated to direct the packets meant for the home link to the
recovery link.
6.2. Address Configuration for Virtual Switch 4.4.2. IP field and Security Descriptions of SS message
Each standby home agent obtains its individual IPv6 address from its A state synchronization message is only unicasted. The destination
attached link. This IPv6 address is used by the home agent address MUST be one of home agents in the same Redundant Home Agent
reliability protocol to exchange information with the associated home set. The source address MUST be set to the sender's home agent
agents. The link between home agents should be secured. address. Note that, in VHARP, the virtual home agent address MUST
NOT be set to the source address. IP address of the interface the
packet is being sent from SHOULD be used.
The virtual home agent's IPv6 address which is known by the mobile If a state synchronization message is unicasted, it SHOULD be
node is shared with the standby home agents. When a home agent authenticated by IPsec AH and MAY be encrypted by IPsec ESP. If all
fails, the standby home agent activates the IPv6 address of the the home agents are placed in a secure transport network to exchange
failed home agent and becomes the active home agent. The standby the state synchronization message, authentication and encryption MAY
home agent should not activate the IPv6 address until it knows the be omitted. If security verification is failed for a receiving state
active home agent is no longer reachable at the address, otherwise synchronization message, the message MUST be discarded. Which
address duplication will occur. To guarantee transparency of the security mechanism is used depend on the operational policy.
home agent virtual switch to mobile nodes located on the home link,
the neighbor cache of the home agent IP address MUST be carefully
operated. See Section 8.1 in detail.
6.3. Address Configuration for Hard Switch 4.4.3. Requesting State of Mobile Nodes (SS-REQ)
Each standby home agent obtains its individual IPv6 address from its When a home agent needs the state information for a particular mobile
attached link. This IPv6 address is used by the home agent node or a subset of mobile nodes, it sends a SS-REQ message
reliability protocol to exchange information with the associated home constructed as follows:
agents. The link between home agents should be secured.
Each home agent configures itself with a different IPv6 address from o MUST set the Type field to 0 (Request).
the same home prefix. This IPv6 address can be used for the Home
Agent Reliability protocol if the standby home agents are located at
the same link of the active home agent (Figure 10). In case of
Figure 11, the router must carefully route packets to the standby
home agents as described in Section 8.1. Once a mobile node
registers its binding with the active home agent, it may solicit an
IPsec/IKE exchange with standby home agents. These packets must be
routed to the recovery link. This can be achieved by installing host
routes for the standby home agents on the recovery link of the
router.
7. Home Agent Common Operation o MUST set a random value in the Identifier field that does not
coincide with any other currently pending Requests.
7.1. Home Agent List Management o MUST include a Binding Cache Information option(s) which Home
Address field is set to the target home address. Other fields of
the Binding Cache Information option can be omitted.
In Mobile IPv6 [RFC-3775], each home agent periodically sends router o MUST set the unspecified address (::) in the Home Address field of
advertisements with the Home Address Information option [RFC-3775] the Binding Cache Information option, if it solicits the state of
when there are multiple home agents present on a link. This all the mobile nodes registering at the destination home agent of
information is managed in a home agent list. For the Home Agent the SS-REQ message.
Reliability Protocol, HA-HELLO messages are used to manage the home
agent list. There are several reasons to use HA-HELLO message
instead of Router Advertisement such as:
1. In the Home Agent Virtual Switch mode, if the standby home agents o MUST include multiple binding cache information options in a SS-
send unsolicited Router Advertisements to the home link, the REQ, if the sender requests multiple mobile nodes' information.
mobile nodes attached to the home link are aware of the presence The sender SHOULD NOT send multiple SS-REQs per mobile node.
of standby home agents. However, the standby home agents must be
hidden until the active home agent fails. HA-Hello messages are
exchanged only between home agents.
2. As shown in Section 6.1, standby home agents are not always o MUST send a SS-REQ to the active home agent of the target mobile
configured at the same link. In this case, Router Advertisements node(s).
cannot be sent to the recovery link unless the home link and the
recovery link are connected (ex. L2TP). HA-HELLO can be sent
beyond the link.
3. The Home Agent Reliability protocol is defined to manage When a home agent receives a SS-REQ, it MUST perform the verification
additional information such as Group ID and Active/Standby Status described in Section 4.4.2 and following:
of the home agents in the home agent list.
In Mobile IPv6, Router Advertisement are to carry the home agent o If the receiver does not know the binding cache for the target
information to both mobile nodes on the home link and the home mobile node(s) specified in the received Binding Cache Information
agents. On the other hand, in the Home Agent Reliability protocol, option(s), it MUST ignore the SS-REQ and MUST NOT reply a SS-REQ.
HA-Hello is to exchange the information among the home agents and the
Router Advertisement is used to notify the information to the mobile
nodes on the home link. The home agents SHOULD NOT process the Home
Agent Information option carried by Router Advertisement if HA-HELLO
is available. Operators can define different values to the
parameters of the home agent information for HA-HELLO and Router
Advertisement. The management operation of the home agent list is
unchanged and defined in [RFC-3775].
7.2. Detecting Home Agent Failure o Otherwise, the receiver MUST reply a SS-REP including all the
state information of the target mobile node(s).
The active and standby home agents can monitor each other in several 4.4.4. Sending State Information (SS-REP)
ways. One method is to reuse other failure detection mechanisms
defined in VRRP[RFC-3768] and HSRP [RFC-2281] (see Section 7.6).
However, VRRP and HSRP cannot detect the case where the system is
running but the Mobile IPv6 stack is not operational. In the Home
Agent Reliability protocol, a new message called HA-HELLO is
periodically exchanged in the redundant home agent set as a heart-
beat. If HA-HELLO is implemented as a part of Mobile IPv6 stack, it
can detect the home agent failure (Mobile IPv6 stack failure). This
HA-HELLO can also be exchanged frequently enough to detect the
failure promptly and does not introduce any processing overhead to
the mobile node attached to the home link.
Failure events used in the Home Agent Reliability protocol are listed A SS-REP message(s) SHOULD be sent when:
below.
Loss of HA-HELLO 1. The active home agent receives a SS-REQ.
In the event that a standby home agent does not receive any HA- 2. The active home agent creates or deletes a binding cache entry
HELLO from its peer which is currently the active home agent for a for a particular mobile node.
configurable duration, the standby home agent assumes the active
home agent's failure. Any home agents can also request the home
agent information of the other home agent in the same redundant
home agent set by sending HA-HELLO with R-flag set. If HA-HELLO
is not replied from the target home agent within a configurable
amount of time, that home agent peer is considered to have failed.
The detail of the Hello message is described in Section 7.3.
Monitored Server Failure by the Active Home Agent The active home agent MAY additionally send a SS-REP message in
following cases:
There may be number of critical servers such as AAA server in the 1. The active home agent updates the state information for all
network that are essential for the ongoing Mobile IPv6 sessions at sessions that changed since the last update in a periodic
the home agent. Operators can have a policy in place that the interval
active home agent is treated as a failed home agent upon detecting
that the link to such servers has failed.
Routing Peer/Link Failure 2. Often in VHARP, the active home agent MAY update a binding cache
entry for a particular mobile node whenever the binding cache
entry is updated. If an active home agent sends a SS-REP message
whenever the local state information changes, such as a binding
cache change, the number of the SS-REP messages can be quite
large.
Operators may require the home agent to detect its next-hop Following rules must be applied when the active home agent constructs
routing peer failure. If the next-hop routing failure is fatal in a SS-REP.
nature, or due to some other routing policies, the active home
agent is treated as a failed home gent and the recovering
operation should be started.
7.3. Processing Hello Messages o MUST copy the Identifier field of the SS-REQ to the same field of
the SS-REP, if the SS-REP is sent in response to the SS-REQ.
HA-HELLO MUST be either unicasted or multicasted. A new multicast o MUST set zero to the Identifier field if the SS-REP is sent
address (all_homeagent_multicast_address) will be assigned by the without solicitation (no SS-REQ).
IANA. When all the home agents in a redundant home agent set are
configured on a same home link, they MUST join the
all_homeagent_multicast_address. On the other hand, if a home
recovery link is separately defined as described in Figure 11, each
home agent SHOULD unicast HA-HELLO.
7.3.1. Requesting Hello Message o MUST include required mobility options in the SS-REP.
A home agent can solicit HA-HELLO to a particular home agent in the * In HARP, a partial Binding Cache Information Option (the Home
same redundant home agent set by unicasting HA-HELLO with the R-flag Address Field only) MUST be included in the SS-REP.
set. The sender MUST fill the fields of the HA-HELLO with its home
agent information. If a home agent needs to request HA-HELLO to all
the home agents, it sends the HA-HELLO with R-flag set to the
all_homeagent_multicast_address. Requesting HA-HELLO SHOULD be
operated when:
1. A new home agent needs to collect the information of all the * In VHARP, a full Binding Cache Information Option and other
other home agents in the same redundant home agent set. The HA- required options shown in Section 6.1.2 MUST be included in the
HELLO with R-flag set is multicasted to SS-REP.
all_homeagent_multicast_address.
2. A home agent entry in the redundant home agent list is about to o MUST include the state of all the active mobile nodes registering
be removed due to home agent lifetime expiration. The HA-HELLO in the active home agent by the SS-REP when the unspecified
with R-flag set is unicasted to the home agent whose lifetime is address is found in the Home Address mobility option carried with
soon expired. the SS-REQ. The message may be fragmented depending on the total
size needed to carry all states.
3. HA-HELLO has not been received during the specified hello 4.4.5. Synchronizing State (SS-REP and SS-ACK)
interval. The HA-HELLO with R-flag set is unicasted to the
target home agent.
7.3.2. Sending Hello Message When a home agent receives a SS-REP, it MUST take the following
operations.
Each home agent periodically sends HA-HELLO for the home agent's o If no options are carried in the SS-REP, the home agent MUST
failure detection. The interval time is configured at each home ignore the SS-REP and MUST send SS-ACK with the Status
agent. Each home agent MUST also send a HA-HELLO in following case: Synchronization Status option which status value is set to [131:
No Mobility Option]
1. when a home agent receives a HA-HELLO with the R-flag 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 Status Synchronization Status option which status value is set
to [130: Not in same global home agent set]
2. When a home agent detects its local information such as home o The receiver home agent MUST record the IPv6 address of the sender
agent preference, home agent lifetime, and registration status as the active home agent of the mobile node in its local binding
change. cache.
3. When a new home agent boots up, it SHOULD solicit Hello messages o The receiver home agent MUST update its binding cache and all
by multicasting a Hello message with the R-flag set in parallel other necessary information in a particular database(s).
with sending its own Hello message.
When a home agent sends HA-HELLO, the following rule MUST be applied. o The receiver home agent MUST send a SS-ACK with state
synchronization status mobility options if A flag is set.
o Whenever a home agent generates HA-HELLO, it MUST increment the If an active home agent requires an acknowledgment of a SS-REP, it
Sequence Number. The Sequence Number SHOULD be initialized to MUST set the Ack flag in the SS-REP. The receiver of such SS-REP
zero for the first Hello message. To accomplish sequence number will send back a SS-ACK. The receiver MUST copy the Identifier value
rollover, if the sequence number has already been assigned to be received in the SS-REP into SS-ACK in order to match the SS-REP and
the largest possible number representable as a 16-bit unsigned SS-ACK.
integer, then when it is incremented it will then have a value of
zero (0).
o It MUST also specify its own Group ID in HA-HELLO. 4.5. Switching the Active Home Agent
o If a home agent is the active home agent, it MUST set the A-flag In HARP, the standby home agent which is going to be active MUST send
in HA-HELLO. 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
be applied when transmitting a Home Agent Switch message.
o In the Home Agent Hard Switch mode, the source IPv6 address of HA- o MUST use IPsec ESP to the Home Agent Switch message.
HELLO MUST be the home agent address.
o In the Home Agent Virtual Switch mode, the home agent local o MUST set only that standby home agent address in the Home Agent
address MUST be used. Switch message
7.3.3. Receiving Hello Message If there are a large number of mobile nodes served by the failed home
agent, the overhead sending Home Agent Switch messages is high. This
overhead cannot be avoided if the active home agent suddenly stop
serving mobile node because of unexpected reasons (crash, network
trouble, etc). However, if this switch over is operated under the
administrative operation (maintenance, etc), the previous active home
agent may continue serving the mobile nodes until the switch over is
completed. Until the mobile node sends a binding update to the new
active home agent, it still sends the packet to the previous home
agent.
When a home agent receives HA-HELLO, it SHOULD verify the HA-HELLO as Therefore, the new active home agent can notify the completion of
follows: switch-over to the previous active home agent by using a SW-COMP
message. When the new active home agent completes the switch-over,
it SHOULD send a SW-COMP to the previous active home agent. Until
the previous home agent receives this message, it SHOULD continue
serving any mobile nodes that are registered with it. Once the
previous home agent receives the SW-COMP message, it can be shutdown
or detached from the network safely.
o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be In VHARP, after detecting the active home agent has failed, the
discarded. Note that, only if the HA-HELLO is sent on a dedicated standby home agent whose preference value is the highest MUST take
link between the home agents, IPsec protection might not be always over the failed home agent. The standby home agent MUST activate the
required. This depends on the operational policy. virtual home agent address. If a virtual MAC address as introduced
in [RFC-3768, RFC-5798] is used, the standby home agent MUST start
using that virtual MAC address as well. If VHARP run with VRRP and
HSRP as described in Section 4.7, the virtual home agent address can
be treated as a virtual router address in VRRP and HSRP. Therefore,
VRRP and HSRP can automatically activate the virtual home agent
address on the standby home agent after their election mechanism.
Since all the necessary state has already been transferred to this
standby home agent before the active home agent failed, it can
immediately start acting as the active home agent.
o If HA-HELLO is sent from non global IPv6 address, it MUST be When the failed home agent recovers from failure and would return to
discarded. 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
when the failure is occurred. Otherwise, it cannot be either a
standby or active home agent for the mobile nodes. Therefore, as
soon as the active home agent detects the recovery of the failed home
agent, it sends a Home Agent Rekey message to all the mobile nodes
served by other home agents in the same redundant home agent set, and
includes the recovered home agent address in the Home Agent Addresses
field. The 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
resumption mechanism [RFC-5723]. Alternatively, the mobile node MAY
start a new IKE session with the recovered home agent.
o If the source IPv6 address of HA-HELLO does not belong to one of 4.6. Consideration of Routing and Neighbor Discovery Protocol (VHARP)
the home agents in the redundant home agent set, the HA-HELLO MUST
be ignored.
o If the Group ID field of the received HA-HELLO and the receiver's This section gives a brief explanation of how a home agent interacts
Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST with routing and Neighbor Discovery Protocol (NDP) when is VHARP
NOT be unicasted to home agents whose Group ID is different from used.
the sender.
o If the Sequence Number value in the HA-HELLO is equal to or less When a standby home agent becomes active in VHARP, it MUST start to
than the last received Sequence Number value stored in the home advertise the home agent address and the home prefix of the home
agent list entry, the HA-HELLO MUST be discarded. When the addresses serviced by the redundant home agent set into the routing
sequence number rollover is occurred, the sequence number value in infrastructure. This operation is normally done using a route
the HA-HELLO SHOULD be zero. selector such as BGP or an OSPF modifier. For example, we can use
the AS_Path prepend operation for BGP, and the Metric field in OSPF
for the route selection. When each home agent participates in OSPF
routing, each home agent should be configured with the appropriate
metric matched to the home agent preference value. When the active
home agent fails, OSPF detects the failure and can dynamically switch
the route to the standby home Agent based on the OSPF cost value. If
this creates conflicts with the home agent preference value due to
configuration errors, the routers on the home link may not route
packets to the desired standby home agent. In order to change the
OSPF cost correctly and dynamically, The operator takes other
existing approaches. For example, most of router vendors have a
private MIB to set the cost via SNMP, though this is a vendor-
specific function.
o HA-HELLO satisfying all of above tests MUST be processed by When an active home agent activates a home agent address, it SHOULD
receiver. The receiver copies home agent information in HA-HELLO use a virtual MAC address as introduced in [RFC-3768, RFC-5798].
to the corresponding home agent list entry. The home agent When the active home agent is changed, the neighbor cache of the
address of the sender is retrieved from the Source Address field active home agent is not necessarily updated on mobile nodes located
of the IPv6 header of the HA-HELLO. on the home link. Otherwise, the new home agent MUST update the
neighbor cache entry for the home agent address on all the mobile
nodes located on the home link. In addition, Mobile IPv6 uses proxy
NDP to intercept packets meant for mobile nodes which are away from
the home link. However, it is unnecessary for the new active home
agent to overwrite the existing proxy neighbor entries of the mobile
nodes.
o If the home agent lifetime field in the HA-HELLO is set to 0, the 4.7. Interworking with VRRP
receiver removes the sender from the home agents list.
o If the R-flag is set in the received HA-HELLO, the receiver MUST VRRP and HSRP specify an election protocol that dynamically assigns
send a new HA-HELLO to the originator as described in responsibility for a virtual router to one of the VRRP routers on a
Section 7.3.2. LAN. This operation is similar to the VHARP. For example, the VRRP
router controlling the IP address(es) associated with a virtual
router is called the Master, and forwards packets sent to these IP
addresses. The election process provides dynamic fail over in the
forwarding responsibility should the Master become unavailable.
Although VRRP is used to guarantee home agent address reachability,
it cannot be used for state synchronization and explicit switching of
Master and Backup. Thus, the Home Agent Reliability protocol cannot
be replaced by VRRP. This section explains how VRRP can interwork
with HARP/VHARP.
7.4. Processing State Synchronization Messages When VRRP is available, VRRP can replace the Hello message described
in Section 6.1.1. However, some of information is missed by using
VRRP. After receiving a VRRP message, each home agent SHOULD process
the message and store the information as if it receives Home Agent
Hello messages Section 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:
It is necessary for standby home agents to synchronize the state o Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field.
information of each mobile node registered with the active home
agent. In the Home Agent Hard Switch mode, it is not necessary for
the home agents to synchronize the complete binding cache
information. The standby home agent needs the mapping information of
the active home agent and the mobile node. The information is used
to send the Home Agent Switch messages to all the mobile node served
by the failed home agent.
7.4.1. Requesting State of a Particular Mobile Node(s) o Priority: Home Agent Preference is stored in the Priority field.
Note that VRRP only has 8 bits for the Priority field. Therefore,
values larger than 255 MUST NOT be assigned to the preference
value.
When a home agent needs the state information for a particular mobile o Count IPv6 IPv6 Addr: This field MUST be always be 1.
node or a subset of mobile nodes, it sends a SS-REQ message
constructed as follows:
o It MUST set the Type field to 0 (Request). o Max Advert Int: This field MUST be mapped to the Hello Interval
field of the Home Agent Hello message, though it only has 12
bytes.
o It MUST set a random value in the Identifier field that does not o IPv6 address: A home agent address is stored in this field.
coincide with any other currently pending Requests.
o It MUST include an IP address mobility option(s) which subtype is Home Agent Lifetime, Sequence Number and Flags field are missed in
set to the home address if the target is mobile node(s). the VRRP packet format. Therefore, operators SHOULD use the same
statically configured value for Home Agent Lifetime. Each home agent
does not check freshness of received VRRP message because of no
sequence number.
o It MUST include a Mobile Network Prefix mobility option(s) for 4.8. Retransmissions and Rate Limiting
mobile router(s).
o It MUST set the unspecified address (::) in the Home Address Home agents are responsible for retransmissions and rate limiting of
mobility option if it solicits the state of all the mobile nodes SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response.
and mobile routers registering at the receiver of SS-REQ The home agent MUST determine a value for the initial transmission
(i.e.destination of SS-REQ). timer:
o In the Home Agent Virtual Switch, the sender of the SS-REQ MUST be o If the home agent sends a SS-REQ message, it SHOULD use an initial
a home agent local address of one of the home agents in the same retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.
redundant home agent set.
o In the Home Agent Hard Switch, the sender of the SS-REQ MUST be a o If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use
home agent address of one of the home agents in the same redundant an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER.
home agent set.
o The destination of the SS-REQ MUST be the active home agent for If the sending home agent fails to receive a valid matching response
the requesting home address or mobile network prefix. The standby within the selected initial retransmission interval, it SHOULD
home agent MUST NOT reply the SS-RREP to the sender. retransmit the message until a response is received. All of the
above constants are specified in Section 8.
When a home agent receives the SS-REQ, it MUST verify if SS-REQ is The retransmission MUST use an exponential backoff process as
constructed with the above rules. If SS-REQ satisfy all the above described in [RFC-3775] until either the home agent receives a
tests, the receiver of the SS-REQ MUST reply SS-REP including the response, or the timeout period reaches the value
state information of the requested mobile node(s) and/or mobile MAC_HARELIABILITY_TIMEOUT. The home agent SHOULD use a separate
network prefix(es) as described in Section Section 7.4.2. back-off process for different message types and different
destinations. The rate limiting of Mobility Header messages is the
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
(3) times a second, which is specified in [RFC-3775].
7.4.2. Synchronizing State 5. Mobile Node Operation
State synchronization messages SHOULD be sent when: This section describes the operations of a mobile node only when HARP
is used. Non of operations in this section is required in VHARP.
1. The active home agent receives SS-REQ. 5.1. Home Agent Addresses Discovery
2. The active home agent creates a binding cache entry for a A mobile node authenticates itself to two or more home agents and
particular mobile node. creates IPsec SAs with them during bootstrapping. When the active
home agent fails, another home agent can use the pre-existing SA to
notify the mobile node about the failure by sending a Home Agent
Switch message.
3. The active home agent deletes a binding cache entry for a In order to discover multiple home agent addresses, two different
particular mobile node. mechanisms are defined in the bootstrapping solution in the split
scenario [RFC-5026]. One is DNS lookup by home agent Name, the other
is DNS lookup by Service Name. DHCPv6 can also be used in the
integrated scenario [ID-BOOTINT] to provide home agent provisioning
to mobile nodes.
The active home agent MAY additionally send state synchronization In the split scenario, a mobile node can use DNS lookup by Service
message in following cases: Name to discover the home agents, as defined in [RFC-5026]. For
example, if home agent reliability is required by a mobile node, DNS
lookup by Service Name method is recommended for the mobile node to
discover multiple home agents addresses. Therefore, mobile nodes
will query the DNS SRV records with a service name of mip6 and
protocol name of ipv6. The DNS SRV records includes multiple home
agent addresses and different preference values and weights. The
mobile node SHOULD choose two or more home agents from the home
agents list according to their preference value. Then the mobile
node should authenticate itself to these home agents via an IKEv2
exchange.
1. The active home agent update the state information for all In the integrated scenario, a mobile node can use DHCPv6 to get home
sessions that changed since the last update in a periodic agent provisioning from an MSP or ASP, as already defined in [ID-
interval BOOTINT]. The only requirement is that the DHCPv6 response must
include multiple home agents' information in order to support home
agent reliability.
2. Only for the Home Agent Virtual Switch mode, the active home 5.2. IPsec/IKE Establishment to Home Agents
agent updates a binding cache entry for a particular mobile node
whenever the binding cache entry is updated. In the Home Agent
Hard Switch mode, standby home agents only need the mapping
information of a home address of the mobile node/router and the
home agent address of the active home agent to which the mobile
node/router is currently registering. This mapping is used to
send a Home Agent Switch message.
If an active home agent sends a State Synchronization message In this document, a mobile node need to manage an IPsec SA with a
whenever the local state information changes, such as a binding cache home agent(s). The following mechanism can be used to manage the
change, the number of the State Synchronization messages sent can be IPsec SA(s) with a home agent(s).
quite large.
All the state information of the requested mobile nodes is stored in o IKEv1/v2 running per home agent (HARP) to establish multiple IPsec
the SS-REP. Following rules must be applied when the active home SAs for home agents.
agent constructs SS-REP.
o If the SS-REP is sent in response to the SS-REQ, the active home o The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA
agent MUST copy the Identifier field of the State Synchronization with the new home agent (VHARP)
request message to the Identifier field in the SS-REP. Otherwise,
it MUST set the Identifier field to 0.
o When the active home agent stores the state of multiple mobile If IPsec/IKEv2 state synchronization mechanism is available in
nodes in a SS-REP, a Binding Cache Information option is used as a Virtual Private Network (VPN) products, none of above is required for
separator. For each mobile node, a Binding Cache Information the VHARP operation. The IPsec SAs per mobile node are seamlessly
option is placed first, followed by any other options such as AAA copied among multiple home agents.
option. When the next Binding Cache Information option is reached
in the State Synchronization message, it indicates the information
of a different mobile node.
o If the unspecified address is found in the Home Address mobility The mobile node MUST follow the standard IKEv2 exchange in the
option carried with the SS-REQ, the active home agent MUST return bootstrapping solution of the split scenario [RFC-5026]. If multiple
the state of all the active mobile nodes and mobile routers by the IKEv2 are run per home agent, the mobile node MUST NOT attempt the
SS-REP. The message may be fragemented depending on the total home address assignment to standby home agents.
size needed to carry all states.
o A SS-REP MUST be authenticated and encrypted by IPsec ESP. 5.3. Synchronizing State: K-bit treatment
o The destination and source home agents MUST belong to the same When a mobile node moves and the care-of address changes, it can use
redundant home agent set. the Key Management Mobility Capability (K) bit in the Binding Update
in order to update the peer endpoint of the key management protocol
(ex. IKE Security Association).
o In the Home Agent Hard Switch, the IPv6 source address MUST be set If an active home agent receives a Binding Update which K-bit is set,
to the home agent address of the sender. it MUST proceed the Binding Update as [RFC-3775]. In addition, the
active home agent MUST notify the care-of address change to the other
standby home agents. For doing so, it MUST send State
Synchronization Reply message including Binding Cache Information
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 Cache Information option. After all, the standby home agents
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
management protocol.
o In the Home Agent Virtual Switch, the IPv6 source address MUST be If the K-bit is not set in the Binding Update, an active home agent
set to the home agent local address of the sender. needs to rerun the key management protocol. The active home agent
MUST send State Synchronization Reply message including Binding Cache
Information option to all the other standby home agents. K-bit is
unset in the flags field of the Binding Cache Information option.
The receivers of the State Synchronization Reply message (i.e.
standby home agents) detect the care-of address change and rerun the
key management protocol.
When a home agent receives a SS-REP, it MUST verify whether the SS- 5.4. Receiving Home Agent Switch message
REP is constructed with the above rules or not. If the SS-REP does
not satisfy all the rules above, it is discarded. Otherwise, the
following operation must be taken.
o The receiver of SS-REP MUST update its binding cache and all other A mobile node must follow the verification and operations specified
necessary information such as AAA and vendor specific information in [RFC-5142] when it receives a Home Agent Switch message.
in the particular database.
o In the Home Agent Hard Switch mode, the receiver MUST record the The Home Agent Switch message MUST be securely exchanged between a
IPv6 address of the sender as the active home agent of the mobile mobile node and a home agent by IPsec ESP.
node.
7.4.3. Reliable Transmission by Explicit Acknowledgement When the mobile node receives a Home Agent Switch message, and if the
message contains the IPv6 address of a standby home agent, it MUST
select the standby home agent as its active home agent and MUST send
a new Binding Update message to it.
Signaling messages of the Home Agent Reliability protocol are not The standby home agent address in the Home Agent Switch message MUST
guaranteed reliable transmission due to the Mobility Header use. be equal to the sender of the Home Agent Switch message. If the IPv6
This is not always critical, because the link between home agents is address stored in the Home agent address field is different from the
carefully managed as stable and reliable. However, operators may sender's source IPv6 address, the mobile node MUST send a binding
need more explicit notification to confirm the message exchanges update to the sender and MUST NOT use the IPv6 address in the Home
between home agents. This specification provides an optional Agent Switch message.
acknowledgment to SS-REP messages.
If an active home agent requires an acknowledgment of SS-REP, it set 6. Messages Format
the Ack flag in the SS-REP. The receiver of such SS-REP will send
back a SS-ACK. The receiver MUST copy the Identifier value received
in the SS-REP into SS-ACK in order to match the SS-REP and SS-ACK.
7.5. Processing Home Agent Control Messages 6.1. New Mobility Header Messages
7.5.1. Standby Home Agent becomes an Active Home Agent 6.1.1. HARP Message Format
When a standby home agent decides to become an active home agent, the The HARP message has the type field to identify different roles. The
standby home agent sends a SO-REQ to the active home agent. This HARP message has the MH Type value TBD.
message MUST be unicasted to the active home agent and MUST be
encrypted and authenticated by IPsec ESP. The active home Agent MUST
NOT generate this message.
When an active home agent receives a SO-REQ, it MUST operate the 0 1 2 3
following verification and operations: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |A|R|V|M|Rsvd | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. Mobility Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o If the SO-REQ is not protected by IPsec, it MUST be discarded. Figure 6: Home Agent Hello Message
o If the receiver of the SO-REQ is not an active home agent, it MUST Type
send a SO-REP with the Status field set to 130 (Not active home
agent).
o If the sender home agent does not belong to the same redundant 8-bit unsigned integer. It can be assigned one of the following
home agent set, a SO-REP message MUST be sent to the sender with values:
the Status field set to 132 (Not in same redundant home agent
set).
o If the receiver is an active home agent, there is case where the 0: SwitchOver Request (SWO-REQ)
active home agent cannot be standby home agent. In such case, the
active home agent can reply a SO-REP with the Status field set to
129 (Administratively prohibited).
o Otherwise, the active home agent MUST become a standby home agent It is unicasted by a standby home agent that desires to become
and reply with a SO-REP message with the Status field set to 0 the active home agent. The receiver of the message MUST
(Success). transition to standby state as soon as the message is received
and validated successfully.
The SO-REP MUST be also protected by IPsec ESP. Otherwise, the 1: SwitchOver Reply (SWO-REP)
message MUST be silently discarded. If the receiver of SO-REP did It is used to acknowledge the receipt of the corresponding SWO-
not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST REQ.
be ignored. If the Status field of the SwitchOver Reply message is 0
(Success), the receiving standby home agent immediately becomes an
active home agent as described in Section 8.2. If the value in the
Status field is greater than 128 an error has occurred. In this
case, the receiver MUST NOT attempt to be an active home agent.
7.5.2. Active Home Agent becomes inactive 2: SwitchBack Request (SWB-REQ)
When an active home agent decides to become a standby home agent, it It is unicasted by an active home agent that desires to become
sends a SB-REQ to one of standby home agent. The reason for the a standby home agent. The receiver of this message SHOULD
active home agent to send this message can be administrative transition to active state as soon as the message is received
intervention, and events like Monitored Server Failure by the active and validated successfully.
home agent or Routing Peer/Link Failure. This message MUST be
unicasted to one of the standby home agents and MUST be encrypted and
authenticated by IPsec ESP. A standby home agent MUST NOT generate
this message.
When a home agent receives a SwitchBack Request message, it first 3: SwitchBack Reply (SWB-REP)
verifies the message.
o If the SwitchBack Request message is not protected by IPsec ESP, It is used to acknowledge the receipt of the corresponding SWB-
it MUST be discarded. REQ.
o If the sender home agent of the SB-REQ is not an active home 4: Switch Complete (SW-COMP)
agent, the receiver MUST reply a SB-REP with the Status field is
set to 130 (Not active home agent).
o If the sending home agent does not belong to the same redundant This message is used to indicate the completion of switch over,
home agent set, a SB-REP MUST be sent in which the Status field (i.e. sending home agent switch messages and receiving binding
set to 132 (Not in same redundant home agent set). update messages from all the served mobile nodes).
o Otherwise, the receiving home agent MUST send a SB-REP with the 4: Home Agent HELLO (HA-HELLO)
Status field is set to 0 (Success).
After sending the SwitchBack reply, it MUST NOT become an active home It MUST be either unicasted or multicasted to carry home agent
agent immediately. This is because the active home agent is still information among the redundant home agent set. The HA-Hello
active until it receives the SB-REP which is acknowledging the SB- message is defined for two purpose: 1) an alive check and 2)
REQ. The standby home agent SHOULD change to active at least after home agent information exchange.
LINK_TRAVERSAL_TIME.
If a home agent receives a SB-REP, it MUST be protected by IPsec ESP, Group Identifier
otherwise the message MUST be silently discarded. If the receiving
home agent did not send a SB-REQ matched to the received SB-REP, the
message MUST be silently discarded. If the Status field of the SB-
REP is 0 (Success), the active home agent immediately becomes a
standby home agent. The sender home agent of SB-REP becomes active
home agent as described in Section 8.2. If the value in the Status
field is greater than 128, the receiver of SB-REP (active home agent)
cannot become a standby home agent and MUST continue to be an active
home agent.
7.6. Interworking with VRRP 8-bit unsigned integer. This value is used to identify a
particular redundant home agent set.
VRRP and HSRP specify an election protocol that dynamically assigns Sequence #
responsibility for a virtual router to one of the VRRP routers on a
LAN. This operation is similar to the Home Agent Virtual Switch
operation. For example, the VRRP router controlling the IP
address(es) associated with a virtual router is called the Master,
and forwards packets sent to these IP addresses. The election
process provides dynamic fail over in the forwarding responsibility
should the Master become unavailable. Although VRRP is used to
guarantee home agent address reachability, it cannot be used for
state synchronization and explicit switching of Master and Backup.
Thus, the Home Agent Reliability protocol cannot be replaced by VRRP.
This section explains how VRRP can interwork with the Home Agent
Reliability protocol.
When VRRP is available, VRRP can replace the Hello message described 16-bit unsigned integer. The Sequence number of the HA-Hello
in Section 5.1.3. However, some of information is missed by using message can be used to verify whether this Hello message is the
VRRP. After receiving a VRRP message, each home agent SHOULD process latest one or not.
the message and store the information as if it receives Home Agent
Hello messages Section 7.3.3. The Home Agents SHOULD still perform
binding cache synchronization as described in Section 7.4 and SHOULD
support the Home Agent Switch message as described in Section 9.2.
In addition to this, VRRP is useful only if all home agents are (A)ctive flag
located on the same link. If the home agents are topologically
separated, the Home Agent Reliability protocol MUST be used.
0 1 2 3 Active Home Agent flag. If this flag is set, the sender of this
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 HA-Hello message is an active home agent.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(rsvd) | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Address(es) |
+ +
+ +
+ +
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: VRRP Packet Format
The message format of VRRP is described in Figure 12. Each field is (R)equest flag
mapped as follows: HA-HELLO requesting flag. If this flag is set, the receiver of
this HA-Hello message must send back a HA-Hello message to the
sender.
Virtual Rtr ID (V)HARP capability flag
Group ID is stored in the Virtual Rtr ID field. VHARP capability Flag. If a home agent is capable of IPsec/IKE
state synchronization, it MUST set this flag.
Priority (M)ode flag
Home Agent Preference is stored in the Priority field. Note that A home agent MUST set this flag only when VHARP is used in the
VRRP only has 8 bits for the Priority field. Therefore, values current operation. If the flag is unset, the home agent currently
larger than 255 MUST NOT be assigned to the preference value. operates HARP. (HARP:0, VHARP:1)
Count IPv6 IPv6 Addr Reserved
This field MUST be always be 1. This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Advert Int Status
This field MUST be mapped to the Hello Interval field of the Home 8-bit unsigned integer indicating the disposition of a SWO-REQ or
Agent Hello message, though it only has 12 bytes. SWB-REQ. This field is only valid in SWO-REP and SWB-REP. The
following Status values are defined:
IPv6 address 0: Success
A home agent address is stored in this field. 128: Reason unspecified
Home Agent Lifetime, Sequence Number and Flags field are missing in 129: Administratively prohibited
the VRRP packet format. Therefore, operators SHOULD use the same
statically configured value for Home Agent Lifetime. Each home agent
does not check freshness of received VRRP message because of no
sequence number. If VRRP is used, a home agent cannot determine the
active home agent from the VRRP message due to lack of A flag, and
cannot request a VRRP advertisement to other home agents.
7.7. Retransmissions and Rate Limiting 130: Not active home agent (The receiver of SWO-REQ is not the
active home agent)
Standby and active home agents are responsible for retransmissions 131: Not standby home agent (The receiver of SWB-REQ is already
and rate limiting of a SS-REQ, SO-REQ, SB-REQ messages for which they the active home agent)
expect a response. The home agent MUST determine a value for the
initial transmission timer:
o If the home agent sends a SS-REQ message, it SHOULD use an initial 132: Not in same redundant home agent set
retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER.
o If a standby home agent sends a SO-REQ message, it SHOULD use an Home Agent Preference
initial retransmission interval of INITIAL_SWICHOVER_REQ_TIMER.
o If an active home agent sends a SB-REQ message, it SHOULD use an 16-bit unsigned integer. The preference for the home agent
initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER . sending the HA-Hello message. This preference is the same as the
Home Agent Preference value of the Home Agent Information option
as defined in [RFC-3775]. However, operators MAY use a different
preference value for this operation.
If the sending home agent fails to receive a valid matching response Home Agent Lifetime
within the selected initial retransmission interval, it SHOULD
retransmit the message until a response is received. All of the
above constants are specified in Section 11.
The retransmission MUST use an exponential backoff process as 16-bit unsigned integer. The lifetime for the home agent sending
described in [RFC-3775] until either the home agent receives a the HA-Hello message. This lifetime is the same as the Home Agent
response, or the timeout period reaches the value Lifetime value of the Home Agent Information option as defined in
MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a [RFC-3775].
separate back-off process for different message types and different
destinations. The rate limiting of Mobility Header messages is the
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
(3) times a second, which is specified in [RFC-3775].
8. Home Agent Virtual Switch Hello Interval
8.1. Consideration of Routing and Neighbor Discovery Protocol 16-bit unsigned integer. The interval for the home agent sending
this Hello message.
This section gives a brief explanation of how a home agent interacts Mobility Options
with routing and Neighbor Discovery Protocol (NDP) when the Home
Agent Virtual Switch mode is used.
When a standby home agent becomes active in the Home Agent Virtual No valid options are defined in this specification.
Switch mode, it MUST start to advertise the home agent address and
the home prefix of the home addresses serviced by the redundant home
agent set into the routing infrastructure. This operation is
normally done using a route selector such as BGP or an OSPF modifier.
For example, we can use the AS_Path prepend operation for BGP, and
the Metric field in OSPF for the route selection. When each home
agent participates in OSPF routing, each home agent should be
configured with the appropriate metric matched to the home agent
preference value. When the active home agent fails, OSPF detects the
failure and can dynamically switch the route to the standby home
Agent based on the OSPF cost value. If this creates conflicts with
the home agent preference value due to configuration errors, the
routers on the home link may not route packets to the desired standby
home agent. In order to change the OSPF cost correctly and
dynamically, The operator takes other existing approaches. For
example, most of router vendors have a private MIB to set the cost
via SNMP, though this is a vendor-specific function.
When an active home agent activates a home agent address, it SHOULD 6.1.2. State Synchronization Message Format
use a virtual MAC address as introduced in [RFC-3768]. When the
active home agent is changed, the neighbor cache of the active home
agent is not necessarily updated on mobile nodes located on the home
link. Otherwise, the new home agent MUST update the neighbor cache
entry for the home agent address on all the mobile nodes located on
the home link. In addition, Mobile IPv6 uses proxy NDP to intercept
packets meant for mobile nodes which are away from the home link.
However, it is unnecessary for the new active home agent to overwrite
the existing proxy neighbor entries of the mobile nodes.
8.2. Home Agent Recovery This message is used to exchange state corresponding to a particular
mobile node(s). It MUST be unicasted and MUST be authenticated by
IPsec ESP. This message has the MH Type value TBD.
After detecting the active home agent has failed, the standby home 0 1 2 3
agent whose preference value is the highest MUST take over the failed 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
home agent. The standby home agent MUST activate the virtual home +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
agent address. If a virtual MAC address as introduced in [RFC-3768] | Type |A| Reserved |
is used, the standby home agent MUST start using that virtual MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
address as well. Since all the necessary state has already been | Identifier | |
transferred to this standby home agent before the active home agent +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
failed, it can immediately start acting as the active home agent. . .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Home Agent Hard Switch Figure 7: State Synchronization Message
9.1. Home Agent Recovery Type
After detecting the active home agent has failed, the standby home 8-bit unsigned integer. It can be assigned one of the following
agent whose preference value is the highest MUST take over the failed values:
home agent. The standby home agent MUST send a Home Agent Switch
message to all the mobile nodes that were registered at the failed
home agent as described in Section 9.2, using the pre-established
IPsec SA. The standby Home Agent MUST set its own address in the
Home Agent Address field in the Home Agent Switch message so that it
will receive the binding update from the mobile node as an
acknowledgement of the sent Home Agent Switch message. The home
agent switch-over is complete when it receives binding updates from
all the mobile nodes. It is important to remark that sending Home
Agent Switch messages to all the mobile nodes at once may bring non-
negligible overhead to the home agent.
This overhead cannot be avoided if the active home agent suddenly 0: State Synchronization Request (SS-REQ)
stop serving mobile node because of unexpected reasons (crash, It is used to solicit the active state corresponding to a
network trouble, etc). However, if this switch over is operated particular mobile node.
under the administrative operation (maintenance, etc), the previous
active home agent may continue serving the mobile nodes until the
switch over is completed. Until the mobile node sends a binding
update to the new active home agent, it still sends the packet to the
previous home agent in the Home Agent Hard Switch. Therefore, the
new active home agent can notify the completion of switch-over to the
previous active home agent by using Home Agent Control message as
described in Section 9.4. As soon as this message is received, the
previous active home agent can be shutdown or detached from the
network safely.
9.2. Sending Home Agent Switch Messages 1: State Synchronization Reply (SS-REP)
The standby home agent which is going to be active MUST send a Home It is used between the home agents in the redundant home agent
Agent Switch message as defined in [RFC-5142] to all the mobile nodes set to exchange binding cache information and any other
that were being served by the failed home agent. The Home Agent information related to providing mobility service to the mobile
Switch message must be securely sent to the mobile node by using nodes either periodically or in response to a SS-REQ.
IPsec ESP. The standby home agent MUST include only its own home
agent address in the Home Agent Switch message. If there are a large
number of mobile nodes served by the failed home agent, the overhead
sending Home Agent Switch messages is high. Until a mobile node
receives this Home Agent Switch messages, the mobile node's
communication is discontinued. Therefore, until the standby home
agent completes sending the Home Agent Switch message to all the
mobile nodes and receives Binding Updates from all the mobile node,
the failed home agent SHOULD serve mobile nodes if possible. This is
the case when the active home agent is replaced by administrative
operation with the Home Agent Control messages as described in
Section 9.4.
9.3. Sending Home Agent Rekey Messages 2: State Synchronization Reply-Ack (SS-ACK)
When a failed home agent recovers, it MUST re-establish an IPsec SA This message is optional and is specially used when the links
with each mobile node served by its redundant home agent set. between home agents are not reliable.
Otherwise, it cannot be either a standby or active home agent for the
mobile nodes. Therefore, as soon as the active home agent detects
the recovery of the failed home agent, it sends a Home Agent Rekey
message to all the mobile nodes served by other home agents in the
same redundant home agent set, and includes the recovered home agent
address in the Home Agent Addresses field. The mobile node will re-
key the SA.
9.4. Notification of Home Agent Switch Completion (A)ck flag
If the new active home agent completes the switch-over as described This flag is valid only for SS-REP. If the sender requires
in Section 8.2, it SHOULD send a SW-COMP to the previous active home explicit acknowledgment by SS-ACK, it MUST set this flag.
agent in the Home Agent Hard Switch case. Until the previous home
agent receives this message, it SHOULD continue serving any mobile
nodes that are registered with it. Once the previous home agent
receives the SW-COMP message, it can stop home agent services.
9.5. Mobile Node Operation Reserved
9.5.1. Home Agent Addresses Discovery This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
In the Home Agent Hard Switch mode, a mobile node authenticates Identifier
itself to two or more home agents and creates IPsec SAs with them
during bootstrapping. When the active home agent fails, another home
agent can use the pre-existing SA to notify the mobile node about the
failure by sending a Home Agent Switch message.
In order to discover multiple home agent addresses, two different A 16-bit identifier to aid in matching state synchronization
mechanisms are defined in the bootstrapping solution in the split message. The identifier should never be set to 0. It should
scenario [RFC-5026]. One is DNS lookup by home agent Name, the other always be more than 1.
is DNS lookup by Service Name. DHCPv6 can also be used in the
integrated scenario [ID-BOOTINT] to provide home agent provisioning
to mobile nodes.
In the split scenario, a mobile node can use DNS lookup by Service Mobility Options
Name to discover the home agents, as defined in [RFC-5026]. For
example, if home agent reliability is required by a mobile node, DNS
lookup by Service Name method is recommended for the mobile node to
discover multiple home agents addresses. Therefore, mobile nodes
will query the DNS SRV records with a service name of mip6 and
protocol name of ipv6. The DNS SRV records includes multiple home
agent addresses and different preference values and weights. The
mobile node SHOULD choose two or more home agents from the home
agents list according to their preference value. Then the mobile
node should authenticate itself to these home agents via an IKEv2
exchange.
In the integrated scenario, a mobile node can use DHCPv6 to get home Variable-length field of such length that the complete Mobility
agent provisioning from an MSP or ASP, as already defined in [ID- Header is an integer multiple of 8 octets long. This field
BOOTINT]. The only requirement is that the DHCPv6 response must contains zero or more TLV-encoded mobility options. The encoding
include multiple home agents' information in order to support home and format of defined options are described in [RFC-3775]. The
agent reliability. receiver MUST ignore and skip any options which it does not
understand. This message requires at least one mobility option,
therefore, there is no default length for this message.
9.5.2. IKE/IPsec pre-establishment to Home Agents Binding Cache Information Option is mandatory in SS-REQ message.
Multiple options can be stored in the same SS-REQ message. A home
agent includes the mobile node's home address in the Binding Cache
Information Option. If a home agent wants to solicit all the
active mobile nodes' states, it can include the unspecified
address (::) in an IPv6 address option.
After a mobile node obtains multiple home agent addresses, it needs Binding Cache Information Option is mandatory in SS-REP. SS-REP
to trigger multiple IKE exchanges with the multiple home agents can carry any of mobility options. The following options are just
selected from the home agent list. Since both IKEv1 and IKEv2 can be examples.
used to bootstrap Mobile IPv6, this solution does not introduce any
new operations to co-operate with IKEv1 or IKEv2. It should initiate
IKE for home agents as soon as home registration is complete.
The mobile node MUST follow the standard IKEv2 exchange in the * AAA Information Option
bootstrapping solution of the split scenario [RFC-5026]. Home
Address configuration maybe also be included, if necessary, for the
first IKE exchange. After its Home Address is assigned or approved
by the first home agent, mobile node SHOULD register itself with the
second home agent with IKE using the same Home Address. Therefore,
no home address configuration should be used in the second IKEv2
procedure. Note that the mobile node only sends a Binding Update
message to the first home agent.
9.5.3. Synchronizing State: K-bit treatment * Vendor Specific Mobility Option [RFC-5094]
When a mobile node moves and the care-of address changes, it can use * Mobile Network Prefix Option [RFC-3963]
the Key Management Mobility Capability (K) bit in the Binding Update
in order to update the peer endpoint of the key management protocol
(ex. IKE Security Association).
If an active home agent receives a Binding Update which K-bit is set, * IPv4 Care-of Address Option [RFC-5555]
it MUST proceed the Binding Update as [RFC-3775]. In addition, the
active home agent MUST notify the care-of address change to the other
standby home agents. For doing so, it MUST send State
Synchronization Reply message including Binding Cache Information
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 Cache Information option. After all, the standby home agents
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
management protocol.
If the K-bit is not set in the Binding Update, an active home agent * IPv4 Home Address Option [RFC-5555]
needs to rerun the key management protocol. The active home agent
MUST send State Synchronization Reply message including Binding Cache
Information option to all the other standby home agents. K-bit is
unset in the flags field of the Binding Cache Information option.
The receivers of the State Synchronization Reply message (i.e.
standby home agents) detect the care-of address change and rerun the
key management protocol.
9.5.4. Receiving Home Agent Switch message * Binding Identifier Option [RFC-5648]
A mobile node must follow the operation specified in [RFC-5142] when 6.1.3. Home Agent Rekey Message
it receives a Home Agent Switch message.
When the mobile node receives a Home Agent Switch message, and if the This message is used to indicate that the mobile node SHOULD start an
message contains the IPv6 address of a standby home agent, it MUST IPsec re-key with the home agent specified in the Home Agent
select the standby home agent in the switch message as the active Addresses field. This message is used when a failed home agent
home agent and send a new Binding Update message to it. Note that recovers and needs to re-establish IPsec SA/IKE state with a mobile
the standby home agent address in the Home Agent Switch MUST be equal node. This message MUST be unicasted to a mobile node by the active
to the sender of the Home Agent Switch message. The standby Home home agent and MUST be authenticated and encrypted by IPsec ESP. The
agent expects the Binding Update as an acknowledgment of the Home Home Agent Rekey message has the MH Type value TBD. If no options
Agent Switch message. The mobile node already has a pre-established are present in this message, no padding is necessary and the Header
SA with the standby home agents and should use that SA to send the Len field will be set to 2.
Binding Update. If the address stored in the Home agent address
field is different from the sender, the mobile node MUST send a
binding update to the sender.
9.5.5. Receiving Home Agent Rekey message 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. Home Agent Addresses .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Home Agent Rekey Message
Reserved
The reserved field is 16 bits
Home Agent Address
The receiver of this message MUST rekey the security asscoation
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 9.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 verfications are satisified, 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.
10. Security Considerations 6.2. New Mobility Options
Since Mobile IPv6 operation requires ESP in transport mode between 6.2.1. Binding Cache Information Option
the mobile node and the home agent, we will discuss the ESP field
synchronization issues between the mobile node and the redundant set
of home agents. This synchronization is required only for Home Agent
Virtual Switch mode. Most of fields should be synchronized based on
[RFC-4301]. The ESP header has the following fields:
SPI The binding cache information option is used to carry binding cache
information of each mobile node. It has two different lengths
depending on the number of fields. Two lengths can be set, 16 and
40. The alignment requirement is either 8n+6 or 8n+2. The Binding
Cache Information option is only valid in a State Synchronization
message. Its format is as follows:
This field identifies the SAD at the receiver. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+ +
: :
+ Care-of Address +
: :
+ +
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Flags : Sequence Number :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Lifetime : Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The mobile node negotiates only one IPsec SA. Hence, the SPI Figure 9: Binding Cache Information Option
value will remain unchanged upon home agent failover.
Sequence Number The fields of Home Address is always mandated in a Binding Cache
Information option. The Care-of Address, Flags, Sequence Number, and
Lifetime fields are presented only if these values are necessary (ex.
VHARP). The corresponding value in the binding cache database of the
active home agent is copied to each field. Note that the 16-bit
Reserved field MUST be set to zero.
This field is used for "anti-replay" feature of ESP. The 6.2.2. State Synchronization Status Option
transmitter must include this monotonically increasing number.
The receiver may process the sequence number based on local
policy.
The mobile node and the redundant home agent set will have the Figure 10 is a new mobility option of State Synchronization message.
same set of sequence numbers for transmit and receive. Hence, In the global HAHA, SS-ACK is mandatory for receivers of SS-REP to
synchronization of the sequence number field is mandatory in this notify the global binding registration status
mode of operation. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SA1, SA2, SA3, SA4 could be synchronized between the home Figure 10: State Synchronization Status Option
agents as these messages are not sent continuously. Moreover for
the Binding Update case, if the mobile node is in the middle of
sending a Binding Update to an active home agent for a binding
refresh, and the active home agent is not available at that
moment, the mobile node will not get any response from the active
home agent. After a standby home agent becomes active, the mobile
node will retry and it will receive the Binding Update from the
mobile node with a sequence number that is +n from its last known
sequence number for SA1. For the Binding Acknowledgment case
(SA2), the standby home agent SHOULD add a random number to the
last known sequence number over and above the replay window to
ensure that the packet passes the replay check at the mobile node.
The same applies to HoTi and HoT messages with SA3 and SA4. Note
that this windowing of the sequence numbers for Mobile IPv6
signaling is only needed to cover the corner cases when Binding
Update or HoTi is in-flight and the active home agent fails.
The technique explained above should work for user data packets if Type
ESP is used to encrypt user data traffic as well. The actual
switchover time and the routing infrastructure convergence time is
the only latency that the user may perceive.
Initialization Vector 8-bit Type value. The value is TBD.
Since the Initialization Vector will be delivered in each exchange Length
between a mobile node and home agent, this field is not
necessarily synchronized between home agents.
Others 8-bit length value.
Other fields should be synchronized based on RFC4301 [RFC-4301] Status
In the Home Agent Hard Switch mode, the standby home agent needs to 8 bit Status value of global binding registration.
send a Home Agent Switch message using IPsec encryption. Since the
mobile node has pre-established an IPsec SA with both the active and
standby home agents, the standby home agent can send the message to
the mobile node with the pre-established IPsec SA.
11. Protocol Constants * 0: Success
INITIAL_STATE_SYNC_REQ_TIMER: 3sec * 128: Reason unspecified
INITIAL_SWICHOVER_REQ_TIMER: 1sec * 129: Malformed SS-REP
INITIAL_SWICHBACK_REQ_TIMER 1sec * 130: Not in same global home agent set
LINK_TRAVERSAL_TIME 150msec * 131: No Mobility Option
12. IANA Considerations Reserved
o The values for following mobility header message MUST be assigned 24 bit Reserved fields
by IANA.
* State Synchronization Message Home Address
* Home Agent Control Message Corresponding home address of the status code.
* Home Agent Hello Message 6.2.3. AAA Information Option
* Home Agent Rekey Message 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
RADIUS or Diameter AVP formats including the user and session info.
This information option is only valid in a State Synchronization
message.
o The values for following mobility options MUST be assigned by 0 1 2 3
IANA. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. AAA AVPs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. Binding Cache Information Option Figure 11: AAA Information Option
2. AAA Information Option Type
o New Option Code for the IP address option defined in [RFC-5268] 8-bit Type value. The value is TBD.
13. Additional Authors Length
8-bit length value.
AAA AVPs
Series of TLV encoded AAA AVPs (including vendor specific AVPs)
carrying AAA-related information for each Mobile IPv6 and IPsec/
IKE session.
7. Security Considerations
All the messages newly defined in this document SHOULD be
authenticated by IPsec AH and MAY be encrypted by IPsec ESP. When a
HA-HELLO message is multicasted, the multicast extensions to IPsec
[RFC-5374] is used. In some operational scenarios, home agents are
located in deeply core network and securely managed. If there is a
secure transport network between home agents, some of security
mechanism can be turned off depending on administrative policy.
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
defined in [RFC-5142].
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
mobile node need to update or establish the IPsec SA with the new
home agent as described in Section 5.2. Existing mechanisms
[RFC5723] are applied to this operation.
8. Protocol Constants
INITIAL_STATE_SYNC_REQ_TIMER: 3sec
INITIAL_SWICH_REQ_TIMER: 1sec
LINK_TRAVERSAL_TIME 150msec
MAC_HARELIABILITY_TIMEOUT 16sec
ALL_HA_MULTICAST_ADDR: TBD
9. IANA Considerations
The following Extension Types MUST be assigned by IANA:
o Home Agent Reliability Protocol (HARP) Message
o State Synchronization (SS) Message
o Binding Cache Information Option
o AAA Information Option
o A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all
home agents will be assigned by the IANA.
10. 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 44, line 41 skipping to change at page 40, line 35
Brian Haley Brian Haley
brian.haley@hp.com brian.haley@hp.com
Behcet Sarikaya Behcet Sarikaya
bsarikaya@huawei.com bsarikaya@huawei.com
Ryuji Wakikawa Ryuji Wakikawa
ryuji@sfc.wide.ad.jp ryuji.wakikawa@gmail.com
14. Acknowledgements 11. 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.
15. References 12. References
12.1. Normative References
15.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-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.
[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.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
Network Access Identifier", RFC 4282, December 2005. scenario", RFC 5026, October 2007.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
RFC 4283, November 2005.
[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.
[RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message", [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message",
RFC-5142, November 2007. RFC-5142, November 2007.
[RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split [RFC-5374] B. Weis, G. GrossD. Ignjatic, "Multicast Extensions to
scenario", RFC 5026, October 2007. the Security Architecture for the Internet Protocol", RFC 5374,
November 2008
[RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", RFC-5555, June 2009.
[RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648,
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.
15.2. Informative References 12.2. Informative References
[RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[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-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC 3776, June 2004.
[RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[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-5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
2008. RFC 3768, April 2004.
[RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol
Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010.
[RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3
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",
draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006.
[ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006.
[ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent
Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired),
February 2004. February 2004.
 End of changes. 364 change blocks. 
1328 lines changed or deleted 1295 lines changed or added

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