Mobile IP Working Group Jahanzeb Faizan
Internet-Draft Hesham El-Rewini
Expires: May, 2004 Southern Methodist University
Mohammad Khalil
Nortel Networks
November, 2003
Problem Statement: Home Agent Reliability
draft-jfaizan-mipv6-ha-reliability-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 May, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
In Mobile-IPv6, Mobile Node is dependent on a single Home Agent for
the seamless roaming over the Internet. Mobile-IPv6 also allows
deployment of multiple Home Agents on the subnet for providing
continuous service to Mobile Node in case of serving Home Agent
failure. But switching of service from the failed Home Agent to
another functional Home Agent on the Home Subnet is problematic and
the base Mobile-IPv6 specifications does not currently have
well-described solutions. This document aims to describe and
illustrate these problems, and propose some guidelines for possible
solutions.
Faizan. Expires May, 2004 [Page 1]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mobile-IPv6 Deployment Scenario . . . . . . . . . . . . . . . .5
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . .5
3.1 Failure Detection . . . . . . . . . . . . . . . . . . . . 5
3.2 IPsec Security Association with new Home Agent . . . . . .6
4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . .7
4.1 Security Implications . . . . . . . . . . . . . . . . . . 7
4.2 IPsec Security with new Home Agent . . . . . . . . . . . .7
4.3 Seamless failure . . . . . . . . . . . . . . . . . . . . .7
4.4 Mobile Node functionality . . . . . . . . . . . . . . . . 7
4.5 Messages over air interface . . . . . . . . . . . . . . . 7
4.6 Home Agent addition and failure . . . . . . . . . . . . . 7
4.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . .10
Faizan. Expires May, 2004 [Page 2]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
1. Introduction
Mobile-IPv6[1] is designed to allow a Mobile Node to change its point
of IP subnet attachment in the Internet at the network or IP layer.
The Mobile Node is always identified by it Home Address regardless
of its current network location. Its mobility is not limited by
conventional IP network boundaries. The Mobile-IPv6 system consists
of Mobile Node and Home Agent. Home Agent remains at conventional
IPv6 subnet called the Home Subnet and when the Mobile Node is at the
Home Subnet then the packets sent to it are routed through
conventional IPv6[5] routing mechanism. When the Mobile Node is not
at Home Subnet it registers its remote point of attachment address
called Care of Address with the Home Agent. This allows Home
Agent to forward packets, addressed to the Mobile Node at its Home
Network, to its current location.
In Mobile-IPv6 system, as currently specified, a single Home Agent
services Mobile Node(s). Mobile-IPv6 also allows deployment of
multiple Home Agents on the same subnet so that if the serving
Home Agent fails then any other Home Agent on the subnet can provide
service to the Mobile Node.
The goal of this draft is to:
o Articulate the problems resulting from the failure of a serving
Home Agent and switching of service to another Home Agent.
o Specify a set of framework guidelines to evaluate proposed
solutions.
1.1 Overview of the Problem
In Mobile-IPv6[1], Mobile Node registers and establish a connection
with only one Home Agent which provides continuous service to it. The
Mobile Node is reliant on this Home Agent for its connectivity. Thus
the Home Agent represents the possibility of a single point of
failure for Mobile-IPv6. A Home Agent may be responsible for multiple
Mobile Nodes on the Home Subnet. The failure of a single Home Agent
may then result in the loss of connectivity for numerous Mobile Nodes
located throughout the Internet. Thus the Home Agent and Mobile Node
taken together have a shared fate. A Mobile Node cannot afford the
loss of its Home Agent. To overcome this problem Mobile-IPv6 allows
deployment of multiple Home Agents on the Home Subnet so that upon
the failure of serving Home Agent, another Home Agent can take over
the functions of failed Home Agent and thus provide continuous
service to the Mobile Node(s) registered with failed Home Agent. This
transfer of service from the failed Home Agent to a new working Home
Agent is problematic and the current specification of Mobile-IPv6 [1]
Faizan. Expires May, 2004 [Page 3]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
does not provide solution to these problems.
1.2 Terminology
Mobile-IPv6
Mobile IP for IPv6 [1]
Mobile Node
A node that can change its point of attachment from one link
to another, while still being reachable via its home address.
IP
Internet Protocol Version 6 (IPv6).[5]
Home Address
A unicast routable address assigned to a Mobile Node, used as
the permanent address of the Mobile Node. This address is
within the Mobile Node's Home Subnet. Conventional IPv6
routing mechanisms will deliver packets destined for a Mobile
Node's Home Address to its Home Subnet.
Home Network
A network, possibly virtual, having a network prefix matching
that of a Mobile Node's Home Address.
Home Agent
A router on a Mobile Node's Home Network which tunnels
datagrams for delivery to the Mobile Node when it is away
from home, and maintains current location information for the
Mobile Node.
Care of Address
A unicast routable address associated with a Mobile Node
while visiting a foreign network.
IPsec Security Association
An IPSec security association is a cooperative relationship
formed by the sharing of cryptographic keying material and
associated context. Security associations are simplex. That
is, two security associations are needed to protect
bidirectional traffic between two nodes, one for each
direction.
Registration
The process during which a Mobile Node sends a Binding Update
to its Home Agent causing a binding for the Mobile Node to be
registered.
Faizan. Expires May, 2004 [Page 4]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6].
2. Mobile-IPv6 Deployment Scenario
This section describes a basic deployment scenario where multiple
Home Agents, referred as HAs 1..n, have to coexist on the same
Home Subnet to provide continuous service to Mobile Node (MN) in case
of failure of the serving Home Agent. Mobile Node runs both
Mobile-IPv6 Mobile Node functionality along with IPsec client
software. Also all the HAs 1..n run Mobile-IPv6 Home Agent
functionality along with IPsec server software. Initially MN is
registered and have IPv6 tunnel with HA_1.
..Foreign Network.. ......Home Network............
. . . .
. +----+ . . +-------+ .
. |MN | .<=========> . | HA_1 | .
. | | . . +-------+ +-------+ .
. +----+ . . ..... | HA_n | .
. . . +-------+ +-------+ .
. . . | HA_2 | .
. . . +-------+ .
................... ..............................
Figure 1
3. Problem statement
This section uses the scenario discussed in section 2 to describe
the problems associated with the failure of serving Home Agent and
as the result of this switching of service to another Home Agent on
the subnet. Consider the failure of HA_1. and switching of service
to a new HA_x (where x = 2..n) on the same subnet. This whole process
of failure and switching is problematic. The problems are discussed
in the following sub-sections.
3.1 Failure Detection
Transfer of service from the failed HA_1 to new HA_x will occur after
the detection of failure by MN. MN could detect the failure of HA_1
under certain conditions. These are listed below.
Faizan. Expires May, 2004 [Page 5]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
o When MN sends Binding Update(BU) message to the failed HA_1 and
does not receive matching Binding Acknowledgment(BA) message, it
will retransmit BUs until timeout occurs. Upon this MN will come to
know about the failure of HA_1.
o Similarly when MN sends Mobile Prefix Solicitation(PS) message to
the failed HA_1 and does not receive Mobile Prefix Advertisement,
it will retransmit PSs until timeout occurs and that's how it will
come to know that HA_1 has failed.
According to Mobile-IPv6[1] MN after sending first BU or PS message
to failed HA_1 will wait for a initial timeout period which is set to
INITIAL_BINDACK_TIMEOUT (1 second) in case of BU and
INITIAL_SOLICIT_TIMER (3 seconds) in case of PS. This timeout period
will be doubled for each subsequent BU or PS message until value of
MAX_BINACK_TIMEOUT (32 seconds) is reached. MN MAY send infinite BUs
or PSs to failed HA_1 before the final timeout occurs.
So the detection of failed HA_1 will be delayed by a considerable
amount of time. Also there will be many useless messages transmitted
over the air interface during this period. Moreover BU and PS are
not periodic rather on demand. MN will send BU only to register
new Care of Address or to extend the lifetime of existing
registration with its serving Home Agent. Similarly MN will send PS
only when its serving Home Agent's address is about to become
invalid. As a result MN will suffer packet loss and disconnectivity
problems. This could have noticeable performance implications on
real-time applications.
3.2 IPsec Security Association with new Home Agent
Once the failure is detected, MN will try to register its Care of
Address with any other Home Agent on the subnet. For this MN must
know which other Home Agents are available on the subnet. MN MAY
start Dynamic Home Agent Discovery(DHAD)[1] protocol and as the
result will get list of available Home Agents on the subnet. MN could
then select HA_x (in our scenario) on the list as its potential
serving Home Agent. MN will send BU message to HA_x setting Home
Registration(H) bit.
According to the base specification of Mobile-IPv6[1] MN and HA_x
MUST use IPsec Security Associations to protect the integrity and
authenticity of the BUs and BAs. If there is no existing Security
Association to protect the BU, MN will initiate IKE[2] (referred as
Dynamic Keying) according to the guidelines defined in [3]. The
latency casued by IKE transcations might cause performance
degradation.
Faizan. Expires May, 2004 [Page 6]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
The problem of Dynamic Keying can be avoided by Manual Keying. It
involves out-of-band entry of Security Associations in MN and Home
Agent. MN can be statically configured for a set of Home Agents among
HAs 1..n and corresponding Security Associations before launching
MN in the Mobile-IPv6 network. This will allow MN to register with
any other Home Agent and use appropriate Security Associations upon
the failure of it's serving Home Agent. But this policy is not
flexible enough to accommodate the dynamic nature of subnets.
4. Solution Guidelines
This section describes guidelines for a solution to the above
mentioned problems. The subsections discuss the guidelines in a
decreasing order of importance.
4.1 Security Implications
The solution MUST NOT introduce any new security vulnerabilities to
the Mobile-IPv6[1].
4.2 IPsec Security with new Home Agent
The solution SHOULD provide a mechanism to quickly establish IPsec
Security Association between the Mobile Node and the new Home Agent
such that the service interruption is minimimal.
4.3 Seamless failure
It is strongly recommendated that the failure of Home Agent should be
transparent from the Mobile Node. This will contribute in minimizing
the period of service interruption.
4.4 Mobile Node functionality
The solution SHOULD cause minimal modification to the Mobile Node as
it is defined by Mobile-IPv6[1].
4.5 Messages over air interface
The solution SHOULD avoid introducing new messages more than what has
been defined by Mobile-IPv6[1].
4.6 Home Agent addition and failure
The solution SHOULD provide recovery mechanism for the failed Home
Agent. Also any new Home Agent added on the subnet SHOULD be ready to
serve in minimum amount of time possible.
Faizan. Expires May, 2004 [Page 7]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
4.7 Scalability
The solution complexity MUST increase at most linearly with the
number of Mobile Nodes registered and Home Agents configured on the
subnet.
References
[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), August
2003.
[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in
progress), June 2003.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Jahanzeb Faizan
Southern Methodist University
Computer Science and Engineering Department.
6425 N Ownby Dr., SIC #300D
Dallas, TX, 75205, USA
Phone +1 214-768-3712, Fax +1 214-768-3085
EMail: jfaizan@smu.edu
Hesham El-Rewini
Southern Methodist University
Computer Science and Engineering Department.
6425 N Ownby Dr., SIC #306C
Dallas, TX, 75205, USA
Faizan. Expires May, 2004 [Page 8]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
Phone +1 214-768-3278, Fax +1 214-768-3085
EMail: rewini@engr.smu.edu
Mohammad Khalil
Nortel Networks
Richardson, TX, USA
Phone: +1 972-685-0564
EMail: mkhalil@nortelnetworks
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
Faizan. Expires May, 2004 [Page 9]
Internet-Draft Home Agent Reliability, Problem Statement November, 2003
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Faizan. Expires May, 2004 [Page 10]