draft-ietf-mip6-hareliability-04.txt   draft-ietf-mip6-hareliability-05.txt 
MEXT (MIP6) Working Group R. Wakikawa (Editor) MEXT Working Group R. Wakikawa (Editor)
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track July 14, 2008 Intended status: Standards Track July 13, 2009
Expires: January 15, 2009 Expires: January 14, 2010
Home Agent Reliability Protocol Home Agent Reliability Protocol
draft-ietf-mip6-hareliability-04.txt draft-ietf-mip6-hareliability-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 15, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The home agent can be a single point of failure when Mobile IPv6 is The home agent can be a single point of failure when Mobile IPv6 is
operated in a system. It is critical to provide home agent operated in a system. It is critical to provide home agent
reliability in the event of a home agent crashing or becoming reliability in the event of a home agent crashing or becoming
unavailable. This would allow another home agent to take over and unavailable. This would allow another home agent to take over and
continue providing service to the mobile nodes. This document continue providing service to the mobile nodes. This document
describes the problem scope briefly and provides a mechanism of home describes the problem scope briefly and provides a mechanism of home
agent failure detection, home agent state transfer, and home agent agent failure detection, home agent state transfer, and home agent
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 8 4.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 8
4.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 9 4.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 9
4.3. Home Agent Management . . . . . . . . . . . . . . . . . . 10 4.3. Home Agent Management . . . . . . . . . . . . . . . . . . 10
5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. New Mobility Header Messages . . . . . . . . . . . . . . . 11 5.1. New Mobility Header Messages . . . . . . . . . . . . . . . 11
5.1.1. State Synchronization Message . . . . . . . . . . . . 11 5.1.1. State Synchronization Message . . . . . . . . . . . . 11
5.1.2. Home Agent Control Message . . . . . . . . . . . . . . 13 5.1.2. Home Agent Control Message . . . . . . . . . . . . . . 13
5.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 15 5.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 15
5.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 16 5.1.4. Home Agent Rekey Message . . . . . . . . . . . . . . . 17
5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 17 5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 17
5.2.1. IP address Option . . . . . . . . . . . . . . . . . . 17 5.2.1. IP address Option . . . . . . . . . . . . . . . . . . 18
5.2.2. Binding Cache Information Option . . . . . . . . . . . 17 5.2.2. Binding Cache Information Option . . . . . . . . . . . 18
5.2.3. AAA Information Option . . . . . . . . . . . . . . . . 18 5.2.3. AAA Information Option . . . . . . . . . . . . . . . . 19
6. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 20 6. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 20
6.1. Network Configuration . . . . . . . . . . . . . . . . . . 20 6.1. Network Configuration . . . . . . . . . . . . . . . . . . 20
6.2. Address Configuration for Virtual Switch . . . . . . . . . 21 6.2. Address Configuration for Virtual Switch . . . . . . . . . 21
6.3. Address Configuration for Hard Switch . . . . . . . . . . 21 6.3. Address Configuration for Hard Switch . . . . . . . . . . 21
7. Home Agent Common Operation . . . . . . . . . . . . . . . . . 22 7. Home Agent Common Operation . . . . . . . . . . . . . . . . . 22
7.1. Home Agent List Management . . . . . . . . . . . . . . . . 22 7.1. Home Agent List Management . . . . . . . . . . . . . . . . 22
7.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 22 7.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 22
7.3. Processing Hello Messages . . . . . . . . . . . . . . . . 23 7.3. Processing Hello Messages . . . . . . . . . . . . . . . . 23
7.3.1. Requesting Hello Message . . . . . . . . . . . . . . . 24 7.3.1. Requesting Hello Message . . . . . . . . . . . . . . . 24
7.3.2. Sending Hello Message . . . . . . . . . . . . . . . . 24 7.3.2. Sending Hello Message . . . . . . . . . . . . . . . . 24
7.3.3. Receiving Hello Message . . . . . . . . . . . . . . . 25 7.3.3. Receiving Hello Message . . . . . . . . . . . . . . . 25
7.4. Processing State Synchronization Messages . . . . . . . . 26 7.4. Processing State Synchronization Messages . . . . . . . . 26
7.4.1. Requesting State of a Particular Mobile Node(s) . . . 26 7.4.1. Requesting State of a Particular Mobile Node(s) . . . 26
7.4.2. Synchronizing State . . . . . . . . . . . . . . . . . 27 7.4.2. Synchronizing State . . . . . . . . . . . . . . . . . 27
7.4.3. Reliable Transmission by Explicit Acknowledgement . . 28 7.4.3. Reliable Transmission by Explicit Acknowledgement . . 28
7.5. Processing Home Agent Control Messages . . . . . . . . . . 29 7.5. Processing Home Agent Control Messages . . . . . . . . . . 29
7.5.1. Standby Home Agent becomes an Active Home Agent . . . 29 7.5.1. Standby Home Agent becomes an Active Home Agent . . . 29
7.5.2. Active Home Agent becomes in-active . . . . . . . . . 30 7.5.2. Active Home Agent becomes inactive . . . . . . . . . . 30
7.6. Interworking with VRRP . . . . . . . . . . . . . . . . . . 31 7.6. Interworking with VRRP . . . . . . . . . . . . . . . . . . 31
7.7. Retransmissions and Rate Limiting . . . . . . . . . . . . 32 7.7. Retransmissions and Rate Limiting . . . . . . . . . . . . 32
8. Home Agent Virtual Switch . . . . . . . . . . . . . . . . . . 34 8. Home Agent Virtual Switch . . . . . . . . . . . . . . . . . . 34
8.1. Consideration of Routing and Neighbor Discovery 8.1. Consideration of Routing and Neighbor Discovery
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 34 8.2. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 34
9. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35 9. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35
9.1. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 35 9.1. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 35
9.2. Sending Home Agent Switch Messages . . . . . . . . . . . . 35 9.2. Sending Home Agent Switch Messages . . . . . . . . . . . . 35
9.3. Notification of Home Agent Switch Completion . . . . . . . 36 9.3. Sending Home Agent Rekey Messages . . . . . . . . . . . . 36
9.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 36 9.4. Notification of Home Agent Switch Completion . . . . . . . 36
9.4.1. Home Agent Addresses Discovery . . . . . . . . . . . . 36 9.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 36
9.4.2. IKE/IPsec pre-establishment to Home Agents . . . . . . 37 9.5.1. Home Agent Addresses Discovery . . . . . . . . . . . . 36
9.4.3. Receiving Home Agent Switch message . . . . . . . . . 37 9.5.2. IKE/IPsec pre-establishment to Home Agents . . . . . . 37
9.5.3. Synchronizing State: K-bit treatment . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9.5.4. Receiving Home Agent Switch message . . . . . . . . . 38
9.5.5. Receiving Home Agent Rekey message . . . . . . . . . . 38
11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 42
13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 44
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
15.1. Normative References . . . . . . . . . . . . . . . . . . . 44
15.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Change Log From Previous Versions . . . . . . . . . . 46 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
15.1. Normative References . . . . . . . . . . . . . . . . . . . 45
15.2. Informative References . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
In Mobile IPv6 [RFC-3775] and NEMO Basic Support [RFC-3963], if a In Mobile IPv6 [RFC-3775] and NEMO Basic Support [RFC-3963], if a
home agent loses the binding cache state, due to failure or some 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 is designed to synchronize the Mobile IPv6
skipping to change at page 5, line 41 skipping to change at page 5, line 41
Redundant Home Agent Set Redundant Home Agent Set
A group of active and standby home agent(s). The Group Identifier A group of active and standby home agent(s). The Group Identifier
is used to identify a redundant home agent set. is used to identify a 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 and used only in the Home Agent Virtual Switch case.
The address is only acitivated on an active home agent. 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
skipping to change at page 6, line 51 skipping to change at page 6, line 51
State Synchronization State Synchronization
The information for mobile nodes must be able to be synchronized The information for mobile nodes must be able to be synchronized
between an active home agent and standby home agents. This between an active home agent and standby home agents. This
includes the Binding Cache, AAA information, other Mobile IPv6 and includes the Binding Cache, AAA information, other Mobile IPv6 and
NEMO related information. Note that the Home Agent Reliability NEMO related information. Note that the Home Agent Reliability
protocol exchanges only running states of mobile nodes. protocol exchanges only running states of mobile nodes.
Therefore, we do not have any specific operation for synchronizing Therefore, we do not have any specific operation for synchronizing
the configuration information. For instance, when Mobile IPv6 is the configuration information. For instance, when Mobile IPv6 is
operated with Authentication protocol, the 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 configure in multiple home this document. Operators MAY correctly set the configuration
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 10.
Secured Message Exchanges Secured Message Exchanges
The messages used between the home agents to transfer binding The messages used between the home agents to transfer binding
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 4. Protocol Overview
4.1. Home Agent Virtual Switch 4.1. Home Agent Virtual Switch
A mobile node remains unaware about the change in the active home A mobile node remains unaware about the change in the active home
agent since the home agents have replicated all session state agent since the home agents have replicated all session state
including IPsec/IKE/ESP states. IPsec/IKE/ESP state transfer is out including IPsec/IKE states. IPsec/IKE state transfer is out of scope
of scope of this document. of this document.
MN HA1(active) HA2(Standby) MN HA1(active) HA2(Standby)
| | . | | .
|<--------->| | 1. IKE exchange (with HoA assignment) |<--------->| | 1. IKE exchange (with HoA assignment)
|---------->| . 2. Binding Update |---------->| . 2. Binding Update
|<----------| . 3. Binding Acknowledgment |<----------| . 3. Binding Acknowledgment
| | . | | .
| |<--------->. 4. State exchanges (binding cache/IPsec) | |<--------->. 4. State exchanges (binding cache/IPsec)
| | . | | .
| X . HA1 FAILURE | X . HA1 FAILURE
skipping to change at page 9, line 38 skipping to change at page 9, line 38
Figure 2: Overview of Home Agent Hard Switch Figure 2: Overview of Home Agent Hard Switch
The mobile node establishes IPsec/IKE state with all the home agents The mobile node establishes IPsec/IKE state with all the home agents
in the redundant home agent set beforehand (1 and 4), however it in the redundant home agent set beforehand (1 and 4), however it
registers its binding only with the active home agent (2 and 3). registers its binding only with the active home agent (2 and 3).
When an active home agent fails, a standby home agent uses a pre- When an active home agent fails, a standby home agent uses a pre-
existing IPsec SA to notify the mobile node about the failure by existing IPsec SA to notify the mobile node about the failure by
securely sending a Home Agent Switch message. In order to discover securely sending a Home Agent Switch message. In order to discover
home agent addresses, two different mechanisms are defined, as home agent addresses, two different mechanisms are defined, as
described in Section 9.4.1. The active home agent synchronizes the described in Section 9.5.1. The active home agent synchronizes the
required states of the mobile nodes, such as Binding Cache and AAA required states of the mobile nodes, such as Binding Cache and AAA
information, with other standby home agents periodically (5). The information, with other standby home agents periodically (5). The
mobile node MUST NOT request a home address(es) assignment through mobile node MUST NOT request a home address(es) assignment through
the IKE exchange to the standby home agent when it establishes an SA the IKE exchange to the standby home agent when it establishes an SA
with it (4). with it (4).
When the standby home agent detects the failure of the active home When the standby home agent detects the failure of the active home
agent (6), it sends a Home Agent Switch message to all the mobile agent (6), it sends a Home Agent Switch message to all the mobile
nodes that were registered with the failed home agent (7). The Home nodes that were registered with the failed home agent (7). The Home
Agent Switch message must be encrypted by a pre-established IPsec SA. Agent Switch message must be encrypted by a pre-established IPsec SA.
skipping to change at page 12, line 8 skipping to change at page 12, line 8
The message is called State Synchronization Reply (SS-REP) and The message is called State Synchronization Reply (SS-REP) and
is used between the home agents in the redundant home agent set is used between the home agents in the redundant home agent set
to exchange binding cache information and any other information to exchange binding cache information and any other information
related to providing mobility service to the mobile nodes related to providing mobility service to the mobile nodes
either periodically or in response to a SS-REQ. either periodically or in response to a SS-REQ.
2: Reply-Ack 2: Reply-Ack
The message is called State Synchronization Reply-Ack (SS-ACK) The message is called State Synchronization Reply-Ack (SS-ACK)
and is used to acknowledge to the SS-REP. This message is and is used to acknowledge the SS-REP. This message is
optional and is specially used when the links between home optional and is specially used when the links between home
agents are not reliable. agents are not reliable.
Ack flag Ack flag
This flag is valid only for SS-REP. If the sender requires This flag is valid only for SS-REP. If the sender requires
explicit acknowledgment by SS-ACK, it MUST set this flag. explicit acknowledgment by SS-ACK, it MUST set this flag.
Reserved Reserved
skipping to change at page 12, line 45 skipping to change at page 12, line 45
understand. This message requires at least one mobility option, understand. This message requires at least one mobility option,
therefore, there is no default length for this message. therefore, there is no default length for this message.
One of the following options is mandatory in SS-REQ message. One of the following options is mandatory in SS-REQ message.
Multiple same options can be stored in the same SS-REQ message, Multiple same options can be stored in the same SS-REQ message,
(ex. two IP address options for two mobile nodes): (ex. two IP address options for two mobile nodes):
* IP Address Option (Sub-type: Home Address) defined in [RFC- * IP Address Option (Sub-type: Home Address) defined in [RFC-
5268]. If a home agent wants the Binding Cache information for 5268]. If a home agent wants the Binding Cache information for
a particular mobile node, it includes the mobile node's home a particular mobile node, it includes the mobile node's home
address in an IPv6 Address Option. If a home agent want to address in an IPv6 Address Option. If a home agent wants to
solicit all the active mobile nodes' states, it can include the solicit all the active mobile nodes' states, it can include the
unspecified address (0::0) in an IPv6 address option. unspecified address (::) in an IPv6 address option.
* Mobile Network Prefix Option. If a home agent wants to know * Mobile Network Prefix Option. If a home agent wants to know
the forwarding state setup for a particular Mobile Network the forwarding state setup for a particular Mobile Network
Prefix, it includes a Mobile Network Prefix Option as defined Prefix, it includes a Mobile Network Prefix Option as defined
in [RFC-3963]. in [RFC-3963].
* The Mobile Node Identifier option defined in [RFC4283]. If a
home agent wants the Binding Cache information for a particular
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 * Vendor Specific Mobility Option. If a home agent wants vendor
specific information, it can solicit with this option as specific information, it can solicit with this option as
defined in [RFC-5094]. defined in [RFC-5094].
One of the following options is mandatory in SS-REP: One of the following options is mandatory in SS-REP:
* Binding Cache Information Option * Binding Cache Information Option
* AAA Information Option * AAA Information Option
skipping to change at page 16, line 43 skipping to change at page 17, line 9
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Mobility Options Mobility Options
No valid options are defined in this specification. No valid options are defined in this specification.
5.1.4. Home Agent Switch Message 5.1.4. Home Agent Rekey Message
This message is defined in Section 9.4.3. The Home Agent Reliability This message is used to indicate that the mobile node SHOULD start an
protocol extends this message for the Home Agent Hard Switch. IPsec re-key with the home agent specified in the Home Agent
Addresses field. This message is used when a failed home agent
recovers and needs to re-establish IPsec SA/IKE state with a mobile
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 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of Addresses |I| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. Home Agent Addresses . . Home Agent Addresses .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility options . . Mobility options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Home Agent Switch Message Figure 7: Home Agent Rekey Message
IPsec Re-key (I) Reserved
The IPsec re-key (I) bit is set to indicate that the mobile node The reserved field is 16 bits
SHOULD start an IPsec re-key with the home agent specified in the
Home Agent Addresses field. This flag is used when a failed home
agent recovers and needs to re-establish IPsec SA/IKE state with a
mobile node. When this flag is set, the mobile node does not
switch the home agent, but only re-key the SA.
Reserved Home Agent Address
The reserve field is reduced from 8 to 7 bits The receiver of this message MUST rekey the security asscoation
with the specified home agent.
5.2. New Mobility Options 5.2. New Mobility Options
5.2.1. IP address Option 5.2.1. IP address Option
This option is already defined in the Fast Handovers for Mobile IPv6 This option is already defined in the Fast Handovers for Mobile IPv6
(FMIP) specification [RFC-5268]. This document introduces new Sub- (FMIP) specification [RFC-5268]. This document introduces new Sub-
Type values for home agent address and Home Address. Type values for home agent address and Home Address.
Option-Code Option-Code
skipping to change at page 18, line 36 skipping to change at page 19, line 4
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. Mobile Network Prefix Option . . Mobile Network Prefix Option .
. . . .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Binding Cache Information Option Figure 8: Binding Cache Information Option
The fields of Home Address, Care-of Address, Flags, Sequence Number, The fields of Home Address, Care-of Address, Flags, Sequence Number,
and Lifetime are copied from the registered binding of a particular and Lifetime are copied from the registered binding of a particular
mobile node or mobile router. The 8-bit Reserved field MUST be set mobile node or mobile router. The 16-bit Reserved field MUST be set
to zero. If the R-flag is set to indicate this binding cache entry to zero. If the R-flag is set to indicate this binding cache entry
is for a mobile router, then this option will be immediately followed is for a mobile router, then this option will be immediately followed
by one or more Mobile Network Prefix options. by one or more Mobile Network Prefix options.
5.2.3. AAA Information Option 5.2.3. AAA Information Option
This option is used to carry the AAA state of the mobile node's This option is used to carry the AAA state of the mobile node's
Mobile IPv6 sessions. The AAA state information can be carried in Mobile IPv6 sessions. The AAA state information can be carried in
RADIUS or Diameter AVP formats including the user and session info. RADIUS or Diameter AVP formats including the user and session info.
This information option is only valid in a State Synchronization This information option is only valid in a State Synchronization
skipping to change at page 19, line 18 skipping to change at page 19, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. AAA AVPs . . AAA AVPs .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Vendor Specific Inforamtion Option Figure 9: Vendor Specific Information Option
Type Type
8-bit Type value. The value is TBD. 8-bit Type value. The value is TBD.
Length Length
8-bit length value. 8-bit length value.
AAA AVPs AAA AVPs
skipping to change at page 22, line 30 skipping to change at page 22, line 30
of standby home agents. However, the standby home agents must be of standby home agents. However, the standby home agents must be
hidden until the active home agent fails. HA-Hello messages are hidden until the active home agent fails. HA-Hello messages are
exchanged only between home agents. exchanged only between home agents.
2. As shown in Section 6.1, standby home agents are not always 2. As shown in Section 6.1, standby home agents are not always
configured at the same link. In this case, Router Advertisements configured at the same link. In this case, Router Advertisements
cannot be sent to the recovery link unless the home link and the cannot be sent to the recovery link unless the home link and the
recovery link are connected (ex. L2TP). HA-HELLO can be sent recovery link are connected (ex. L2TP). HA-HELLO can be sent
beyond the link. beyond the link.
3. The Home Agent Reliability protocol defines to manage additional 3. The Home Agent Reliability protocol is defined to manage
information such as Group ID and Active/Standby Status of the additional information such as Group ID and Active/Standby Status
home agents in the home agent list. of the home agents in the home agent list.
In Mobile IPv6, Router Advertisement are to carry the home agent In Mobile IPv6, Router Advertisement are to carry the home agent
information to both mobile nodes on the home link and the home information to both mobile nodes on the home link and the home
agents. On the other hand, in the Home Agent Reliability protocol, agents. On the other hand, in the Home Agent Reliability protocol,
HA-Hello is to exchange the information among the home agents and the HA-Hello is to exchange the information among the home agents and the
Router Advertisement is used to notify the information to the mobile Router Advertisement is used to notify the information to the mobile
nodes. The home agents SHOULD NOT process the Home Agent Information nodes on the home link. The home agents SHOULD NOT process the Home
option carried by Router Advertisement if HA-HELLO is available. Agent Information option carried by Router Advertisement if HA-HELLO
Operators can define different values to the parameters of the home is available. Operators can define different values to the
agent information for HA-HELLO and Router Advertisement. The parameters of the home agent information for HA-HELLO and Router
management operation of the home agent list is unchanged and defined Advertisement. The management operation of the home agent list is
in [RFC-3775]. unchanged and defined in [RFC-3775].
7.2. Detecting Home Agent Failure 7.2. Detecting Home Agent Failure
The active and standby home agents can monitor each other in several The active and standby home agents can monitor each other in several
ways. One method is to reuse other failure detection mechanisms ways. One method is to reuse other failure detection mechanisms
defined in VRRP[RFC-3768] and HSRP [RFC-2281] (see Section 7.6). 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 However, VRRP and HSRP cannot detect the case where the system is
running but the Mobile IPv6 stack is not operational. In the Home running but the Mobile IPv6 stack is not operational. In the Home
Agent Reliability protocol, a new message called HA-HELLO is Agent Reliability protocol, a new message called HA-HELLO is
periodically exchanged in the redundant home agent set as a heart- periodically exchanged in the redundant home agent set as a heart-
skipping to change at page 24, line 47 skipping to change at page 24, line 47
2. When a home agent detects its local information such as home 2. When a home agent detects its local information such as home
agent preference, home agent lifetime, and registration status agent preference, home agent lifetime, and registration status
change. change.
3. When a new home agent boots up, it SHOULD solicit Hello messages 3. When a new home agent boots up, it SHOULD solicit Hello messages
by multicasting a Hello message with the R-flag set in parallel by multicasting a Hello message with the R-flag set in parallel
with sending its own Hello message. with sending its own Hello message.
When a home agent sends HA-HELLO, the following rule MUST be applied. When a home agent sends HA-HELLO, the following rule MUST be applied.
o Whenever a home agent generates HA-HELLO, it MUST increment in the o Whenever a home agent generates HA-HELLO, it MUST increment the
Sequence Number. The Sequence Number SHOULD be initialized to Sequence Number. The Sequence Number SHOULD be initialized to
zero for the first Hello message. To accomplish sequence number zero for the first Hello message. To accomplish sequence number
rollover, if the sequence number has already been assigned to be rollover, if the sequence number has already been assigned to be
the largest possible number representable as a 16-bit unsigned the largest possible number representable as a 16-bit unsigned
integer, then when it is incremented it will then have a value of integer, then when it is incremented it will then have a value of
zero (0). zero (0).
o It MUST also specify its own Group ID in HA-HELLO. o It MUST also specify its own Group ID in HA-HELLO.
o If a home agent is the active home agent, it MUST set the A-flag o If a home agent is the active home agent, it MUST set the A-flag
skipping to change at page 25, line 30 skipping to change at page 25, line 30
follows: follows:
o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be
discarded. Note that, only if the HA-HELLO is sent on a dedicated discarded. Note that, only if the HA-HELLO is sent on a dedicated
link between the home agents, IPsec protection might not be always link between the home agents, IPsec protection might not be always
required. This depends on the operational policy. required. This depends on the operational policy.
o If HA-HELLO is sent from non global IPv6 address, it MUST be o If HA-HELLO is sent from non global IPv6 address, it MUST be
discarded. discarded.
o If the source IPv6 address of HA-HELLO is not belong to one of the o If the source IPv6 address of HA-HELLO does not belong to one of
home agents in the redundant home agent set, the HA-HELLO MUST be the home agents in the redundant home agent set, the HA-HELLO MUST
ignored. be ignored.
o If the Group ID field of the received HA-HELLO and the receiver's o If the Group ID field of the received HA-HELLO and the receiver's
Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST
NOT be sent to home agents whose Group ID is different from the NOT be unicasted to home agents whose Group ID is different from
sender. the sender.
o If the Sequence Number value in the HA-HELLO is equal to or less o If the Sequence Number value in the HA-HELLO is equal to or less
than the last received Sequence Number value stored in the home than the last received Sequence Number value stored in the home
agent list entry, the HA-HELLO MUST be discarded. agent list entry, the HA-HELLO MUST be discarded. When the
sequence number rollover is occurred, the sequence number value in
the HA-HELLO SHOULD be zero.
o HA-HELLO satisfying all of above tests MUST be processed by o HA-HELLO satisfying all of above tests MUST be processed by
receiver. The receiver copies home agent information in HA-HELLO receiver. The receiver copies home agent information in HA-HELLO
to the corresponding home agent list entry. The home agent to the corresponding home agent list entry. The home agent
address of the sender is retrieved from the Source Address field address of the sender is retrieved from the Source Address field
of the IPv6 header of the HA-HELLO. of the IPv6 header of the HA-HELLO.
o If the home agent lifetime field in the HA-HELLO is set to 0, the o If the home agent lifetime field in the HA-HELLO is set to 0, the
receiver removes the sender from the home agents list. receiver removes the sender from the home agents list.
skipping to change at page 26, line 37 skipping to change at page 26, line 40
o It MUST set a random value in the Identifier field that does not o It MUST set a random value in the Identifier field that does not
coincide with any other currently pending Requests. coincide with any other currently pending Requests.
o It MUST include an IP address mobility option(s) which subtype is o It MUST include an IP address mobility option(s) which subtype is
set to the home address if the target is mobile node(s). set to the home address if the target is mobile node(s).
o It MUST include a Mobile Network Prefix mobility option(s) for o It MUST include a Mobile Network Prefix mobility option(s) for
mobile router(s). mobile router(s).
o It MUST set the unspecified address (0::0) in the Home Address o It MUST set the unspecified address (::) in the Home Address
mobility option if it solicits the state of all the mobile nodes mobility option if it solicits the state of all the mobile nodes
and mobile routers registering at the receiver of SS-REQ and mobile routers registering at the receiver of SS-REQ
(i.e.destination of SS-REQ). (i.e.destination of SS-REQ).
o In the Home Agent Virtual Switch, the sender of the SS-REQ MUST be o In the Home Agent Virtual Switch, the sender of the SS-REQ MUST be
a home agent local address of one of the home agents in the same a home agent local address of one of the home agents in the same
redundant home agent set. redundant home agent set.
o In the Home Agent Hard Switch, the sender of the SS-REQ MUST be a o In the Home Agent Hard Switch, the sender of the SS-REQ MUST be a
home agent address of one of the home agents in the same redundant home agent address of one of the home agents in the same redundant
skipping to change at page 27, line 46 skipping to change at page 27, line 50
node/router is currently registering. This mapping is used to node/router is currently registering. This mapping is used to
send a Home Agent Switch message. send a Home Agent Switch message.
If an active home agent sends a State Synchronization message If an active home agent sends a State Synchronization message
whenever the local state information changes, such as a binding cache whenever the local state information changes, such as a binding cache
change, the number of the State Synchronization messages sent can be change, the number of the State Synchronization messages sent can be
quite large. quite large.
All the state information of the requested mobile nodes is stored in All the state information of the requested mobile nodes is stored in
the SS-REP. Following rules must be applied when the active home the SS-REP. Following rules must be applied when the active home
constructs SS-REP. agent constructs SS-REP.
o If the SS-REP is sent in response to the SS-REQ, the active home o If the SS-REP is sent in response to the SS-REQ, the active home
agent MUST copy the Identifier field of the State Synchronization agent MUST copy the Identifier field of the State Synchronization
request message to the Identifier field in the SS-REP. Otherwise, request message to the Identifier field in the SS-REP. Otherwise,
it MUST set the Identifier field to 0. it MUST set the Identifier field to 0.
o When the active home agent stores the state of multiple mobile o When the active home agent stores the state of multiple mobile
nodes in a SS-REP, a Binding Cache Information option is used as a nodes in a SS-REP, a Binding Cache Information option is used as a
separator. For each mobile node, a Binding Cache Information separator. For each mobile node, a Binding Cache Information
option is placed first, followed by any other options such as AAA option is placed first, followed by any other options such as AAA
option. When the next Binding Cache Information option is reached option. When the next Binding Cache Information option is reached
in the State Synchronization message, it indicates the information in the State Synchronization message, it indicates the information
of a different mobile node. of a different mobile node.
o If the unspecified address is found in the Home Address mobility o If the unspecified address is found in the Home Address mobility
option carried with the SS-REQ, the active home agent MUST return option carried with the SS-REQ, the active home agent MUST return
the state of all the active mobile nodes and mobile routers by the the state of all the active mobile nodes and mobile routers by the
SS-REP. The IP fragmentation can be occurred depending on the SS-REP. The message may be fragemented depending on the total
total size of all the states. size needed to carry all states.
o A SS-REP MUST be authenticated and encrypted by IPsec ESP. o A SS-REP MUST be authenticated and encrypted by IPsec ESP.
o The destination and source home agents MUST belong to the same o The destination and source home agents MUST belong to the same
redundant home agent set. redundant home agent set.
o In the Home Agent Hard Switch, the IPv6 source address MUST be set o In the Home Agent Hard Switch, the IPv6 source address MUST be set
to the home agent address of the sender. to the home agent address of the sender.
o In the Home Agent Virtual Switch, the IPv6 source address MUST be o In the Home Agent Virtual Switch, the IPv6 source address MUST be
skipping to change at page 30, line 5 skipping to change at page 30, line 8
The SO-REP MUST be also protected by IPsec ESP. Otherwise, the The SO-REP MUST be also protected by IPsec ESP. Otherwise, the
message MUST be silently discarded. If the receiver of SO-REP did message MUST be silently discarded. If the receiver of SO-REP did
not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST
be ignored. If the Status field of the SwitchOver Reply message is 0 be ignored. If the Status field of the SwitchOver Reply message is 0
(Success), the receiving standby home agent immediately becomes an (Success), the receiving standby home agent immediately becomes an
active home agent as described in Section 8.2. If the value in the 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 Status field is greater than 128 an error has occurred. In this
case, the receiver MUST NOT attempt to be an active home agent. case, the receiver MUST NOT attempt to be an active home agent.
7.5.2. Active Home Agent becomes in-active 7.5.2. Active Home Agent becomes inactive
When an active home agent decides to become a standby home agent, it When an active home agent decides to become a standby home agent, it
sends a SB-REQ to one of standby home agent. The reason for the sends a SB-REQ to one of standby home agent. The reason for the
active home agent to send this message can be administrative active home agent to send this message can be administrative
intervention, and events like Monitored Server Failure by the active intervention, and events like Monitored Server Failure by the active
home agent or Routing Peer/Link Failure. This message MUST be home agent or Routing Peer/Link Failure. This message MUST be
unicasted to one of the standby home agents and MUST be encrypted and unicasted to one of the standby home agents and MUST be encrypted and
authenticated by IPsec ESP. A standby home agent MUST NOT generate authenticated by IPsec ESP. A standby home agent MUST NOT generate
this message. this message.
skipping to change at page 34, line 24 skipping to change at page 34, line 24
Switch mode, it MUST start to advertise the home agent address and Switch mode, it MUST start to advertise the home agent address and
the home prefix of the home addresses serviced by the redundant home the home prefix of the home addresses serviced by the redundant home
agent set into the routing infrastructure. This operation is agent set into the routing infrastructure. This operation is
normally done using a route selector such as BGP or an OSPF modifier. 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 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 the Metric field in OSPF for the route selection. When each home
agent participates in OSPF routing, each home agent should be agent participates in OSPF routing, each home agent should be
configured with the appropriate metric matched to the home agent configured with the appropriate metric matched to the home agent
preference value. When the active home agent fails, OSPF detects the preference value. When the active home agent fails, OSPF detects the
failure and can dynamically switch the route to the standby home failure and can dynamically switch the route to the standby home
Agent based on the OSPF cost value. If this cost conflicts with the Agent based on the OSPF cost value. If this creates conflicts with
home agent preference value due to configuration errors, the routers the home agent preference value due to configuration errors, the
on the home link may not route packets to the desired standby home routers on the home link may not route packets to the desired standby
agent. In order to change the OSPF cost correctly and dynamically, home agent. In order to change the OSPF cost correctly and
The operator takes other existing approaches. For example, most of dynamically, The operator takes other existing approaches. For
router vendors have a private MIB to set the cost via SNMP, though example, most of router vendors have a private MIB to set the cost
this is a vendor-specific function. via SNMP, though this is a vendor-specific function.
When an active home agent activates a home agent address, it SHOULD When an active home agent activates a home agent address, it SHOULD
use a virtual MAC address as introduced in [RFC-3768]. When the use a virtual MAC address as introduced in [RFC-3768]. When the
active home agent is changed, the neighbor cache of the active home active home agent is changed, the neighbor cache of the active home
agent is not necessarily updated on mobile nodes located on the home agent is not necessarily updated on mobile nodes located on the home
link. Otherwise, the new home agent MUST update the neighbor cache link. Otherwise, the new home agent MUST update the neighbor cache
entry for the home agent address on all the mobile nodes located on 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 the home link. In addition, Mobile IPv6 uses proxy NDP to intercept
packets meant for mobile nodes which are away from the home link. packets meant for mobile nodes which are away from the home link.
However, it is unnecessary for the new active home agent to overwrite However, it is unnecessary for the new active home agent to overwrite
skipping to change at page 35, line 17 skipping to change at page 35, line 17
9.1. Home Agent Recovery 9.1. Home Agent Recovery
After detecting the active home agent has failed, the standby home After detecting the active home agent has failed, the standby home
agent whose preference value is the highest MUST take over the failed agent whose preference value is the highest MUST take over the failed
home agent. The standby home agent MUST send a Home Agent Switch home agent. The standby home agent MUST send a Home Agent Switch
message to all the mobile nodes that were registered at the failed message to all the mobile nodes that were registered at the failed
home agent as described in Section 9.2, using the pre-established 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 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 Home Agent Address field in the Home Agent Switch message so that it
will receive the binding update from the mobile node as an will receive the binding update from the mobile node as an
acknowledgment of the sent Home Agent Switch message. The home agent acknowledgement of the sent Home Agent Switch message. The home
switch-over is complete when it receives binding updates from all the agent switch-over is complete when it receives binding updates from
mobile nodes. It is important to remark that sending Home Agent all the mobile nodes. It is important to remark that sending Home
Switch messages to all the mobile nodes at once may bring non- Agent Switch messages to all the mobile nodes at once may bring non-
negligible overhead to the home agent. negligible overhead to the home agent.
This overhead cannot be avoided if the active home agent suddenly This overhead cannot be avoided if the active home agent suddenly
stop serving mobile node because of unexpected reasons (crash, stop serving mobile node because of unexpected reasons (crash,
network trouble, etc). However, if this switch over is operated network trouble, etc). However, if this switch over is operated
under the administrative operation (maintenance, etc), the previous under the administrative operation (maintenance, etc), the previous
active home agent may continue serving the mobile nodes until the active home agent may continue serving the mobile nodes until the
switch over is completed. Until the mobile node sends a binding 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 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 previous home agent in the Home Agent Hard Switch. Therefore, the
new active home agent can notify the completion of switch-over to 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 previous active home agent by using Home Agent Control message as
described in Section 9.3. As soon as this message is received, the described in Section 9.4. As soon as this message is received, the
previous active home agent can be shutdown or detached from the previous active home agent can be shutdown or detached from the
network safely. network safely.
9.2. Sending Home Agent Switch Messages 9.2. Sending Home Agent Switch Messages
The standby home agent which is going to be active MUST send a Home The standby home agent which is going to be active MUST send a Home
Agent Switch message as defined in [RFC-5142] to all the mobile nodes Agent Switch message as defined in [RFC-5142] to all the mobile nodes
that were being served by the failed home agent. The Home Agent that were being served by the failed home agent. The Home Agent
Switch message must be securely sent to the mobile node by using Switch message must be securely sent to the mobile node by using
IPsec ESP. The standby home agent MUST include only its own home 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 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 number of mobile nodes served by the failed home agent, the overhead
sending Home Agent Switch messages is high. Until a mobile node sending Home Agent Switch messages is high. Until a mobile node
receives this Home Agent Switch messages, the mobile node's receives this Home Agent Switch messages, the mobile node's
communication is discontinued. Therefore, until the standby home communication is discontinued. Therefore, until the standby home
agent completes sending the Home Agent Switch message to all the agent completes sending the Home Agent Switch message to all the
mobile nodes and receives Binding Updates from all the mobile node, mobile nodes and receives Binding Updates from all the mobile node,
the failed home agent SHOULD serve mobile nodes if possible. This is the failed home agent SHOULD serve mobile nodes if possible. This is
the case when the active home agent is replaced by administrative the case when the active home agent is replaced by administrative
operation with the Home Agent Control messages as described in operation with the Home Agent Control messages as described in
Section 9.3. Section 9.4.
9.3. Sending Home Agent Rekey Messages
When a failed home agent recovers, it MUST re-establish an IPsec SA When a failed home agent recovers, it MUST re-establish an IPsec SA
with each mobile node served by its redundant home agent set. with each mobile node served by its redundant home agent set.
Otherwise, it cannot be either a standby or active home agent for the Otherwise, it cannot be either a standby or active home agent for the
mobile nodes. Therefore, as soon as the active home agent detects mobile nodes. Therefore, as soon as the active home agent detects
the recovery of the failed home agent, it sends a Home Agent Switch the recovery of the failed home agent, it sends a Home Agent Rekey
message with the I-flag set to all the mobile nodes serving by other message to all the mobile nodes served by other home agents in the
home agents in the same redundant home agent set, and includes the same redundant home agent set, and includes the recovered home agent
recovered home agent address in the Home Agent Addresses field. The address in the Home Agent Addresses field. The mobile node will re-
mobile node will re-key the SA, but it will not change the home agent key the SA.
by this home agent switch message which I-flag is set.
9.3. Notification of Home Agent Switch Completion 9.4. Notification of Home Agent Switch Completion
If the new active home agent completes the switch-over as described If the new active home agent completes the switch-over as described
in Section 8.2, it SHOULD send a SW-COMP to the previous active home in Section 8.2, it SHOULD send a SW-COMP to the previous active home
agent in the Home Agent Hard Switch case. Until the previous home agent in the Home Agent Hard Switch case. Until the previous home
agent receives this message, it SHOULD continue serving any mobile agent receives this message, it SHOULD continue serving any mobile
nodes that are registered with it. Once the previous home agent nodes that are registered with it. Once the previous home agent
receives the SW-COMP message, it can stop home agent services. receives the SW-COMP message, it can stop home agent services.
9.4. Mobile Node Operation 9.5. Mobile Node Operation
9.4.1. Home Agent Addresses Discovery 9.5.1. Home Agent Addresses Discovery
In the Home Agent Hard Switch mode, a mobile node authenticates In the Home Agent Hard Switch mode, a mobile node authenticates
itself to two or more home agents and creates IPsec SAs with them itself to two or more home agents and creates IPsec SAs with them
during bootstrapping. When the active home agent fails, another home during bootstrapping. When the active home agent fails, another home
agent can use the pre-existing SA to notify the mobile node about the agent can use the pre-existing SA to notify the mobile node about the
failure by sending a Home Agent Switch message. failure by sending a Home Agent Switch message.
In order to discover multiple home agent addresses, two different In order to discover multiple home agent addresses, two different
mechanisms are defined in the bootstrapping solution in the split mechanisms are defined in the bootstrapping solution in the split
scenario [RFC-5026]. One is DNS lookup by home agent Name, the other scenario [RFC-5026]. One is DNS lookup by home agent Name, the other
skipping to change at page 37, line 15 skipping to change at page 37, line 16
agents list according to their preference value. Then the mobile agents list according to their preference value. Then the mobile
node should authenticate itself to these home agents via an IKEv2 node should authenticate itself to these home agents via an IKEv2
exchange. exchange.
In the integrated scenario, a mobile node can use DHCPv6 to get home In the integrated scenario, a mobile node can use DHCPv6 to get home
agent provisioning from an MSP or ASP, as already defined in [ID- agent provisioning from an MSP or ASP, as already defined in [ID-
BOOTINT]. The only requirement is that the DHCPv6 response must BOOTINT]. The only requirement is that the DHCPv6 response must
include multiple home agents' information in order to support home include multiple home agents' information in order to support home
agent reliability. agent reliability.
9.4.2. IKE/IPsec pre-establishment to Home Agents 9.5.2. IKE/IPsec pre-establishment to Home Agents
After a mobile node obtains multiple home agent addresses, it needs After a mobile node obtains multiple home agent addresses, it needs
to trigger multiple IKE exchanges with the multiple home agents to trigger multiple IKE exchanges with the multiple home agents
selected from the home agent list. Since both IKEv1 and IKEv2 can be selected from the home agent list. Since both IKEv1 and IKEv2 can be
used to bootstrap Mobile IPv6, this solution does not introduce any used to bootstrap Mobile IPv6, this solution does not introduce any
new operations to co-operate with IKEv1 or IKEv2. It should initiate new operations to co-operate with IKEv1 or IKEv2. It should initiate
IKE for home agents as soon as home registration is complete. IKE for home agents as soon as home registration is complete.
The mobile node MUST follow the standard IKEv2 exchange in the The mobile node MUST follow the standard IKEv2 exchange in the
bootstrapping solution of the split scenario [RFC-5026]. Home bootstrapping solution of the split scenario [RFC-5026]. Home
Address configuration maybe also be included, if necessary, for the Address configuration maybe also be included, if necessary, for the
first IKE exchange. After its Home Address is assigned or approved first IKE exchange. After its Home Address is assigned or approved
by the first home agent, mobile node SHOULD register itself with the by the first home agent, mobile node SHOULD register itself with the
second home agent with IKE using the same Home Address. Therefore, second home agent with IKE using the same Home Address. Therefore,
no home address configuration should be used in the second IKEv2 no home address configuration should be used in the second IKEv2
procedure. Note that the mobile node only sends a Binding Update procedure. Note that the mobile node only sends a Binding Update
message to the first home agent. message to the first home agent.
9.4.3. Receiving Home Agent Switch message 9.5.3. Synchronizing State: K-bit treatment
When a mobile node moves and the care-of address changes, it can use
the Key Management Mobility Capability (K) bit in the Binding Update
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,
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
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
A mobile node must follow the operation specified in [RFC-5142] when A mobile node must follow the operation specified in [RFC-5142] when
it receives a Home Agent Switch message. it receives a Home Agent Switch message.
If the I-flag is set in the received Home Agent Switch message, the When the mobile node receives a Home Agent Switch message, and if the
mobile node MUST re-key the SA with the home agent addresses stored message contains the IPv6 address of a standby home agent, it MUST
in the Home Agent Addresses field. The mobile node MUST NOT change select the standby home agent in the switch message as the active
its active home agent when the I-flag is set. If the home agent home agent and send a new Binding Update message to it. Note that
address is not known from the bootstrapping described in the standby home agent address in the Home Agent Switch MUST be equal
Section 9.4.1, the mobile node MUST NOT start an IKE session with the to the sender of the Home Agent Switch message. The standby Home
unknown home agent. Instead, it SHOULD re-start home agent discovery agent expects the Binding Update as an acknowledgment of the Home
again to update its home agent address information. Agent Switch message. The mobile node already has a pre-established
SA with the standby home agents and should use that SA to send the
Binding Update. If the address stored in the Home agent address
field is different from the sender, the mobile node MUST send a
binding update to the sender.
When the mobile node receives a Home Agent Switch message without 9.5.5. Receiving Home Agent Rekey message
I-flag set, and if the message contains the IPv6 address of a standby
home agent, it MUST select the standby home agent in the switch When a mobile node receives a Home Agent Rekey message, it MUST
message as the active home agent and send a new Binding Update verify the message as following
message to it. Note that the standby home agent address in the Home
Agent Switch MUST be equal to the sender of the Home Agent Switch o The message MUST be sent from the receiver's active home agent.
message. The standby Home agent expects the Binding Update as an Otherwise, the message MUST be discarded.
acknowledgment of the Home Agent Switch message. The mobile node
already has a pre-established SA with the standby home agents and o The message MUST be protected by IPsec. Otherwise, the message
should use that SA to send the Binding Update. If the address stored MUST be discarded.
in the Home agent address field is different from the sender, the
mobile node MUST send a binding update to the sender. o The message SHOULD contain one of standby home agent's address.
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
session with the unknown home agent. Instead, it SHOULD re-start
home agent discovery again to update its home agent address
information.
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
Addresses field.
10. Security Considerations 10. Security Considerations
Since Mobile IPv6 operation requires ESP in transport mode between Since Mobile IPv6 operation requires ESP in transport mode between
the mobile node and the home agent, we will discuss the ESP field the mobile node and the home agent, we will discuss the ESP field
synchronization issues between the mobile node and the redundant set synchronization issues between the mobile node and the redundant set
of home agents. This synchronization is required only for Home Agent of home agents. This synchronization is required only for Home Agent
Virtual Switch mode. Most of fields should be synchronized based on Virtual Switch mode. Most of fields should be synchronized based on
[RFC-4301]. The ESP header has the following fields: [RFC-4301]. The ESP header has the following fields:
skipping to change at page 42, line 16 skipping to change at page 43, line 16
o The values for following mobility header message MUST be assigned o The values for following mobility header message MUST be assigned
by IANA. by IANA.
* State Synchronization Message * State Synchronization Message
* Home Agent Control Message * Home Agent Control Message
* Home Agent Hello Message * Home Agent Hello Message
* Home Agent Switch Message * Home Agent Rekey Message
o The values for following mobility options MUST be assigned by o The values for following mobility options MUST be assigned by
IANA. IANA.
1. Binding Cache Information Option 1. Binding Cache Information Option
2. AAA Information Option 2. AAA Information Option
o New Option Code for the IP address option defined in [RFC-5268] o New Option Code for the IP address option defined in [RFC-5268]
skipping to change at page 44, line 19 skipping to change at page 45, line 19
[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
Network Access Identifier", RFC 4282, December 2005.
[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-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split
scenario", RFC 5026, October 2007. scenario", RFC 5026, October 2007.
[ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via
skipping to change at page 46, line 5 skipping to change at page 47, line 5
[ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006.
[ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol",
draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006.
[ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent
Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired),
February 2004. February 2004.
Appendix A. Change Log From Previous Versions
Changes from draft-ietf-mip6-hareliability-03
o Only Editorial Update and No Technical Change
Author's Address Author's Address
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC TOYOTA InfoTechnology Center, U.S.A., Inc.
6-6-20 Akasaka, Minato-ku 465 Bernardo Avenue
Tokyo 107-0052 Mountain View, CA 94043
Japan USA
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF Email: ryuji@us.toyota-itc.com
Administrative Support Activity (IASA).
 End of changes. 64 change blocks. 
181 lines changed or deleted 192 lines changed or added

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