MIP6/NEMO Working Group V. Devarapalli
Internet-Draft Nokia
Expires: January 2, 2006 R. Wakikawa
Keio University and WIDE
P. Thubert
Cisco Systems
July 1, 2005
Local HA to HA protocol
draft-devarapalli-mip6-nemo-local-haha-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the use of an Inter Home Agents protocol
(HAHA) to achieve Home Agent reliability and load balancing. The
protocol allows Home Agents serving the same home link to share the
binding cache contents, and switch a mobile node from one home agent
to another. It also allows a mobile node to utilize multiple Home
Devarapalli, et al. Expires January 2, 2006 [Page 1]
Internet-Draft Local HA to HA protocol July 2005
Agents simultaneously. A mobile node picks one Home Agent as its
primary Home Agent and registers with it. The primary Home Agent
synchronizes the binding cache information with other Home Agents.
Any of Home Agents can intercept a packet meant for the mobile node
and tunnel the packet directly to its current Care-of address.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Home Agent List Management . . . . . . . . . . . . . . . . 4
3.2 Home Agent Failure Detection . . . . . . . . . . . . . . . 4
3.3 Binding Synchronization . . . . . . . . . . . . . . . . . 5
3.4 Home Agent Switching . . . . . . . . . . . . . . . . . . . 6
4. Interworking with VRRP for IPv6 . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 10
Devarapalli, et al. Expires January 2, 2006 [Page 2]
Internet-Draft Local HA to HA protocol July 2005
1. Introduction
Mobile nodes [3] and mobile routers [5] may use a bi-directional
tunnel with their Home Agents for all traffic with the correspondent
nodes. Note that in this document, the term mobile node refers to
both a mobile node and a mobile router. A Home Agent on the home
link maintains a binding cache entry for each mobile node and uses
the binding cache entry to route any traffic meant for the mobile
node or the mobile network. If the mobile node does not have a
binding cache entry at the Home Agent, it is neither reachable at its
home address nor able to setup new sessions with its home address.
If a Home Agent loses the binding cache state, due to failure or some
other reason, it results in loss of service for the mobile nodes.
It would be very beneficial to provide high availability and
redundancy for a Home Agent so that the mobile nodes can avail of
uninterrupted service even when one Home Agent crashes or loses
state.
Mobile IPv6 defines a rudimentary load balancing mechanism based on
the Dynamic Home Agent Address discovery mechanism (DHAAD). Each
Home Agent advertises a preference value on the home link. The home
agents are ordered based on the preference values in a DHAAD reply.
A mobile node typically picks the Home Agent that appears first on
the list of Home Agents in the DHAAD reply. A Home Agent can
dynamically alter its position on the list by changing its preference
value.
But the DHAAD mechanism is useful only when the mobile node tries to
discover a Home Agent when it does not have one configured. It
cannot be used dynamically to switch a mobile node to another Home
Agent. Moreover, DHAAD is only initiated by the mobile node. Also
the mechanism is too slow for the mobile node to recover when its
Home Agent fails. In this document we present a mechanism, based on
the HAHA protocol, for switching a mobile node to another Home Agent
at any time and thus achieve load balancing. The switch to another
Home Agent can be initiated by the mobile node or a Home Agent on the
home link.
We also discuss how the local HAHA protocol can be used with VRRPv6
[7] to achieve redundancy.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Devarapalli, et al. Expires January 2, 2006 [Page 3]
Internet-Draft Local HA to HA protocol July 2005
For the HAHA protocol related terminology, please see [4]
3. Protocol Operation
The following sections describe the local HAHA protocol.
3.1 Home Agent List Management
RFC 3775 defines a mechanism for maintaining a home agent list when
there are multiple home agents present on a link. It is based on
each Home Agent sending a router advertisement periodically on the
home link with a Home Address Information option [3]. However, this
mechanism is governed by how a router sends a router advertisement as
defined in [8]. There are restrictions on how often a router
advertisement can be sent and on how they are processed by routers
that receive them. Moreover, the router advertisements are not sent
frequently enough to rely on the absence of the router advertisement
to detect a Home Agent failure. We show in Section 3.2, how the
Hello messages can be used to detect Home Agent failure.
In this document, we present another mechanism based on the Home
Agent Hello message defined in [4]. The Hello message includes the
home agent preference, lifetime and the prefix the Home Agent serves.
Each Home Agent MUST periodically send a Home Agent Hello message.
The Home Agent SHOULD also send a Home Agent Hello message when its
local information such as preference, lifetime, and registration
status, etc. changes. The interval between two Hello messages is
configurable on the Home Agents. The Hello messages should be sent a
new link-local scope multicast address (to be assigned by the IANA).
All the Home Agents on the home link should join this multicast
address.
When a Home Agent receives and processes a Hello message, it adds the
Home Agent to its list of known Home Agents on the home link. The
Home Agents list is ordered based on the home agent preference value.
If the home agent lifetime field in the Hello message is set to 0,
the Home Agent removes the Home Agent that sent the Hello message
from the Home Agents list.
This mechanism should be used only when all the Home Agents on a
particular link support sending and receiving these Hello messages.
When the Hello messages are used for maintaining the Home Agents
list, the Home Agent MUST NOT use the Home Agent Information option
in the router advertisements to manage the Home Agents list.
3.2 Home Agent Failure Detection
Failure detection is based on Hello messages [4]. Each Home Agent is
Devarapalli, et al. Expires January 2, 2006 [Page 4]
Internet-Draft Local HA to HA protocol July 2005
expected to send the Hello message periodically. This interval is
indicated by the Hello interval field in the Hello message. If a
Hello message is not received from a Home Agent within a multiple of
the interval value, then the Home Agent is considered to have failed.
A Home Agent that is designated as a backup for the failed Home Agent
takes over and sends a Home Agent Switch Request (Section 3.4)
message to all the mobile nodes that were being served by the failed
Home Agent to switch to it.
VRRP for IPv6 can also be used for detecting a Home Agent failure.
The operation of local HAHA with VRRP is explained in Section 4.
3.3 Binding Synchronization
Binding cache entries are synchronized between all the Home Agents on
the home link. The Home Agent that had actually processed the
Binding Update from the mobile node is considered the primary Home
Agent for a particular mobile node. Each Home Agent sends a Binding
Information Update message, gratuitously, whenever it creates or
updates a binding cache entry for a mobile node. The Binding
Information Update message is sent unicast to all the Home Agents in
the home agents list. A Home Agent can send information on multiple
binding cache entries in a Binding Information Update message by
including multiple Binding Cache Entry Information options. The
Binding Cache Entry Information option is defined in [4]. If the
Binding Cache entry is for a mobile router, the mobile network prefix
information is also sent in the option.
When a Home Agent receives a Binding Information Update message, it
stores the binding cache entry information locally and marks the
entries as having received from a particular Home Agent. If the
Binding Information Update message was unicast to the Home Agent, it
sends a unicast Binding Information Acknowledgement message in
response to the Home Agent that sent the Binding Information Update
message.
A Home Agent can also query another Home Agent for the binding cache
information for a particular mobile node by sending a Binding
Information Request Message [4]. If a Home Agents wants the Binding
Cache Information for a particular mobile node it includes a Home
Address mobility option, defined in [4], to carry the home address of
the mobile node. If a Home Agent wants to know the forwarding state
setting up for a particular Mobile Network Prefix, it includes the
Mobile Network Prefix Option, defined in [2]. When a Home Agent
receives a Binding Information Request message, it responds with a
Binding Information Update message for the corresponding binding
cache entry.
Devarapalli, et al. Expires January 2, 2006 [Page 5]
Internet-Draft Local HA to HA protocol July 2005
3.4 Home Agent Switching
If a Home Agent is no longer able to provide service to a particular
mobile node, due to excessive load or due to an administrative
reason, it can tell the mobile node to use another Home Agent on the
home link by sending a Home Agent Switch Request message. This
message is defined in [4]. The Home Agent MAY include the IP address
of another Home Agent in the Home Agent Switch Request message. The
request message MUST only be sent to mobile nodes that are not on the
home link.
When the mobile node receives a Home Agent Switch Request message,
and if the request message contains the IP address of another Home
Agent, it picks the Home Agent in the request message as the primary
Home Agent and sends a Binding Update message to it. If the Home
Agent Switch Request message does not contain another Home Agent
address, the mobile node should perform DHAAD and obtain the current
list of Home Agents. If the mobile node already has a list of Home
Agents from performing DHAAD earlier, it MAY pick a Home Agent from
the list and send a Binding Update message to it.
If a Home Agent fails, another Home Agent on the home link can act as
a backup for the failed Home Agent. The backup Home Agent sends a
Home Agent Switch Request message to all the mobile nodes that were
being served by the failed Home Agent. The backup Home Agent should
include its IP address in the request message.
The primary Home Agent switching is completed when the mobile node
sends a Binding Update and creates a binding at the new Home Agent.
The Home Agent that the mobile node was previously using, deletes the
binding cache entry, when it receives a Binding Information Update
message that contains the binding cache information for the mobile
node, from the new Home Agent
4. Interworking with VRRP for IPv6
VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a
LAN. 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.
VRRP, however, cannot be used for binding cache synchronization. It
can replace the failure detection mechanism described in Section 3.2.
Therefore, when VRRP is available, the Home Agent Hello messages
should not be used. The Home Agents should still perform binding
Devarapalli, et al. Expires January 2, 2006 [Page 6]
Internet-Draft Local HA to HA protocol July 2005
cache synchronization as described in Section 3.3 and support the
Home Agent switch mechanism as described in Section 3.4.
A protocol similar to VRRP was developed for HA reliability. It is
described in [9]. But this protocol cannot be used if the Home
Agents are distributed geographically [6].
5. Security Considerations
When the Home Agents exchange binding cache information, they MUST
use IPsec ESP to encrypt the messages. Other nodes on the home link
MUST NOT be able to observe the contents of the Binding Information
Update messages. The Home Agents can be connected through a
dedicated subnet, separate from the home link, for exchanging
information. In this case, Home Agents MAY skip confidentiality
protection for the binding synchronization messages. However, no
other host should be allowed to connect to this dedicated subnet.
The Home Agent switching mechanism described in Section 3.4 can
result in disrupting the service for the mobile node for a brief
while. Therefore, the Home Agent Switch Request message MUST be
protected by IPsec ESP in transport mode. If there is no existing
security association, the Home Agent must negotiate an IPsec SA, as
defined in [5], to protect the request message.
The Home Agent Hello messages cannot be protected since they are sent
to a multicast address. The Hello messages do not contain any
information that requires confidentiality protection. A malicious
user on the home link could send fake Hello messages and populate the
Home Agents list on the Home Agents. But this mechanism is no worse
than the current router advertisements based Home Agents list
maintenance. The authors believe that the home link will have
restricted access, which will prevent such malicious users from
connecting to the home link.
6. IANA Considerations
The Home Agent Hello messages are sent to an IPv6 link-local scope
multicast address. This needs to be assigned by the IANA. The
address should be of the following form:
FF02:0:0:0:0:0:XXXX:XXXX
7. References
Devarapalli, et al. Expires January 2, 2006 [Page 7]
Internet-Draft Local HA to HA protocol July 2005
7.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Wakikawa, R., "Inter Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress),
October 2004.
7.2 Informative References
[5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[6] Thubert, P., "Global HA to HA protocol",
draft-thubert-nemo-global-haha-00 (work in progress),
October 2004.
[7] Hinden, R., "Virtual Router Redundancy Protocol for IPv6",
draft-ietf-vrrp-ipv6-spec-07 (work in progress), October 2004.
[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] El-Rewini, H., Khalil, M., and J. Faizan, "Virtual Home Agent
Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-02 (work
in progress), April 2004.
Authors' Addresses
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Devarapalli, et al. Expires January 2, 2006 [Page 8]
Internet-Draft Local HA to HA protocol July 2005
Ruyji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252-8520
Japan
Email: ryuji@sfc.wide.ad.jp
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
France
Email: pthubert@cisco.com
Devarapalli, et al. Expires January 2, 2006 [Page 9]
Internet-Draft Local HA to HA protocol July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Devarapalli, et al. Expires January 2, 2006 [Page 10]