wdiff draft-jfaizan-mipv6-ha-reliability-00.txt draft-jfaizan-mipv6-ha-reliability-01.txt

Mobile IP Working Group Jahanzeb Faizan
Internet-Draft Hesham El-Rewini
Expires: May, August, 2004 Southern Methodist University
Mohammad Khalil
Nortel Networks
November, 2003
February, 2004

Problem Statement: Home Agent Reliability
draft-jfaizan-mipv6-ha-reliability-00.txt
draft-jfaizan-mipv6-ha-reliability-01.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, August, 2004.

Abstract

In Mobile-IPv6, Mobile IPv6, the Mobile Node is dependent on a single Home Agent
for the seamless roaming over the Internet. Mobile-IPv6 Mobile IPv6 also allows
deployment of multiple Home Agents on the subnet home link 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 home link is problematic and the base Mobile-IPv6 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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4

2. Mobile-IPv6 Mobile IPv6 Deployment Scenario . . . . . . . . . . . . . . . .5

3. Problem statement . . . . . . . . . . . . . . . . . . . . . . .5
3.1 Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Home Agent Failure . . . . . . . . . . . . . . . . 6
3.1.2 Home Link Failure . . . . . . . . . . . . . . . . .6
3.2 Failure Detection . . . . . . . . . . . . . . . . . . . . 6
3.3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . .7
3.4 IPsec Security Association with new Home Agent . . . . . .6 .7
3.4.1 Dynamic Keying . . . . . . . . . . . . . . . . . . 7
3.4.2 Manual Keying . . . . . . . . . . . . . . . . . . .7
3.5 Correct Ordering . . . . . . . . . . . . . . . . . . . . .8
3.6 Load Balancing . . . . . . . . . . . . . . . . . . . . . .8

4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . .7 .8
4.1 Security Implications . . . . . . . . . . . . . . . . . . 7 8
4.2 IPsec Security with new Home Agent . . . . . . . . . . . .7 .8
4.3 Seamless failure . . . . . . . . . . . . . . . . . . . . .7 .8
4.4 Mobile Node functionality . . . . . . . . . . . . . . . . 7 9
4.5 Messages over air interface . . . . . . . . . . . . . . . 7 9
4.6 Home Agent addition and failure . . . . . . . . . . . . . 7 9
4.7 Scalability Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . 8 9

References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .10

Acknowledgments. . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Acknowledgment . . . . . . . . . . . . . .10

Intellectual Property and Copyright Statements . . . . . . . .10

Appendix: Changes from the previous version. . . . .10 . . . . . .11

1. Introduction

Mobile-IPv6[1]

Mobile IPv6[1] is designed to allow a Mobile Node Node(MN) to change its
point of IP subnet attachment in the Internet at the network or IP
layer.
The Mobile Node MN 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 In Mobile Node and Home Agent. IPv6 system the Home Agent Agent(HA) remains
at conventional IPv6 subnet called the Home Subnet home link and when the Mobile Node MN is
at the
Home Subnet home link then the packets sent to it are routed through
conventional IPv6[5] routing mechanism. mechanisms. When the Mobile Node MN is not at Home Subnet home
link it registers its remote point of attachment address called Care of
Care-of Address with the Home Agent. HA. This allows Home
Agent HA to forward packets,
addressed to the Mobile Node MN at its Home
Network, home link, to its current location.

In Mobile-IPv6 Mobile IPv6 system, as currently specified, a single Home Agent HA services
multiple MNs. Mobile Node(s). Mobile-IPv6 IPv6 also allows deployment of multiple Home Agents HAs on
the same subnet link so that if the serving
Home Agent HA fails then any other Home Agent HA
on the subnet link can provide service to the Mobile Node. MN.

The goal of this draft is to:

o Articulate the problems resulting from the failure of a serving
Home Agent
HA and switching of service to another Home Agent. HA.

o Specify a set of framework guidelines to evaluate proposed
solutions.

1.1 Overview of the Problem

In Mobile-IPv6[1], Mobile Node IPv6, MN registers and establish establishes a connection with only
one Home Agent which provides continuous service to it. HA. The
Mobile Node MN is reliant on this Home Agent HA for its connectivity. Thus the Home Agent
HA represents the possibility of a single point of failure for Mobile-IPv6. Mobile
IPv6. A Home Agent HA may be responsible for multiple
Mobile Nodes MNs on the Home Subnet. home link. The
failure of a single Home Agent HA may then result in the loss of connectivity
for numerous Mobile Nodes MNs located throughout the Internet. Thus the Home Agent HA and Mobile Node MN
taken together have a shared fate. A Mobile Node MN cannot afford the loss of its Home Agent.
HA. To overcome this problem Mobile-IPv6 Mobile IPv6 allows deployment of
multiple Home Agents HAs on the Home Subnet home link so that upon the failure of serving Home Agent, HA,
another Home Agent HA can take over the functions of failed Home Agent HA and thus provide
continuous service to the Mobile Node(s) MN(s) registered with failed Home Agent. HA. This
transfer of service from the failed Home Agent HA to a new working Home
Agent HA is
problematic and the current specification of Mobile-IPv6 [1] Mobile IPv6 does not
provide solution to these problems.

1.2 Terminology

Mobile-IPv6

Following terms are not re-defined. They are included for the
convenience of the readers.

Mobile IPv6
Mobile IP for IPv6 [1]

Mobile Node (MN)
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, MN, used as the
permanent address of the Mobile Node. MN. This address is within the Mobile Node's Home Subnet. Conventional IPv6 MN's
home link. Standard IP routing mechanisms will deliver
packets destined for a Mobile
Node's Home Address MN's home address to its home
link.MNs can have multiple home addresses, for instance when
there are multiple home prefixes on the home link.

Home Subnet.

Home Network
A network, possibly virtual, having Link
The link on which a network MN's home subnet prefix matching
that of a Mobile Node's Home Address. is defined.

Home Agent (HA)
A router on a Mobile Node's Home Network MN's home link with which tunnels
datagrams for delivery to the Mobile Node when it MN has registered
its current Care-of address. While the MN is away from home,
the HA intercepts packets on the home link destined to the
MN's home address, encapsulates them, and maintains current location information for tunnels them to the
Mobile Node.

Care of
MN's registered Ccare-of address.

Care-of Address
A unicast routable address associated with a Mobile Node MN while
visiting a foreign network. link; the subnet prefix of this IP address
is a foreign subnet prefix. Among the multiple
Care-of addresses that a MN may have at any given time (e.g.,
with different subnet prefixes), the one registered with the
MN's HA for a given home address is called its "primary"
care-of address.

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.

Home Registration
The process during which a Mobile Node sends a Binding Update
to

A registration between the MN and its Home Agent causing a binding for HA, authorized by the Mobile Node to be
registered.
use of IPsec.

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 Mobile IPv6 Deployment Scenario

This section describes a basic deployment scenario where multiple
Home Agents,
HAs, referred as HAs 1..n, have to coexist on the same
Home Subnet home link to
provide continuous service to Mobile Node (MN) MN in case of failure of the serving Home Agent. Mobile Node
HA. MN runs both
Mobile-IPv6 Mobile Node IPv6 MN functionality along with IPsec client
software. the mobility signaling
messages protected by IPsec. Also all the HAs 1..n run Mobile-IPv6 Home Agent Mobile IPv6 HA
functionality along with IPsec server software. Initially MN is
registered and have has 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 HA and as the result
of this switching of service to another Home Agent HA on the subnet. home link. Consider
the failure of HA_1. and switching of service to a new HA_x
(where x = 2..n) on the same subnet. home link. This whole process of failure
detection and switching is problematic. The problems are discussed
in the following sub-sections.

3.1 Failure

The following sub-sections introduce two possible scenarios of
failure.

3.1.1 Home Agent Failure

There could be single or multiple HAs failure on the home link. Since
MN could register only with a single HA on the home link which is
HA_1 in our scenario, so failure of multiple HAs is not going to
effect the normal operation of Mobile IPv6. We are only concerned
with the serving HA failure on the home link.

3.1.2 Home Link Failure

There could be failure of home link which will make it inaccessible
to the MN. If this occurs then even the serving HA_1 is operational,
to the MN it would appear that its serving HA_1 has failed.

3.2 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.

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) Solicitation(MPS) message to
the failed HA_1 and does not receive Mobile Prefix Advertisement,
it will retransmit PSs MPSs until timeout occurs and that's how it will
come to know that HA_1 has failed.

According to Mobile-IPv6[1] Mobile IPv6 MN after sending first BU or PS MPS 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. MPS. This timeout period
will be doubled for each subsequent BU or PS MPS message until value of
MAX_BINACK_TIMEOUT (32 seconds) is reached. MN MAY send infinite BUs
or PSs MPSs 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 MPS are not
periodic rather on demand. MN will send BU only to register new Care of
Care-of Address or to extend the lifetime of existing registration
with its serving Home Agent. HA. Similarly MN will send PS MPS only when its serving Home Agent's
HA'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

3.3 Recovery

Once the failure is detected, according to the current specifications
of Mobile IPv6 MN will try to register its Care of Care-of Address with any
other Home Agent HA on the subnet. home link. For this MN must know which other Home Agents HAs are
available on the subnet. home link. MN MAY start Dynamic Home Agent Discovery(DHAD)[1]
discovery(DHAD)[1] protocol and as the a result will get a list of
available Home Agents HAs on the subnet. home link. MN could then select HA_x (in our
scenario) on the list as its potential serving Home Agent. HA. MN will send BU
message to HA_x setting Home Registration(H) bit.

But this recovery mechanism is problematic. If there is only one
HA available on the home link then according to current
specifications of Mobile IPv6 even if the retransmission parameter
MAX_BINACK_TIMEOUT (32 seconds) is reached MN will continue to send
BU messages to the HA_1 until it receives valid BA message and this
will never happen because HA_1 has failed. This makes the MN enter
into an endless loop.

Even if there are multiple HAs exist (as in our scenario), besides
failure detection, there is an extra burden on MN to perform
Home Registration with the new HA and in some cases multiple
Home Registrations if there are unsuccessful attempts. Also if there
is no information about the available HAs on the home link then MN
has to perform DHAD. All these factors together result in extra
messages overhead on the air interface, service interruption and
burden on MN.

3.4 IPsec Security Association with new Home Agent

According to the base specification current specifications of Mobile-IPv6[1] Mobile IPv6 MN and HA_x
MUST use IPsec Security Associations to protect the integrity and
authenticity of the BUs and BAs. There are two methods of
establishing such Associations.

3.4.1 Dynamic Keying

If there is no MN and the new HA_x does not have existing Security Association to
protect the BU, MN will initiate IKE[2] (referred as Dynamic Keying) will be
initiated according to the guidelines defined in [3]. The latency casued
caused by IKE transcations transactions might cause performance degradation.

3.4.2 Manual Keying

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. HA. MN
can be statically configured for a set of Home Agents HAs among HAs 1..n and
corresponding Security Associations before launching MN in the Mobile-IPv6
Mobile IPv6 network. This will allow MN to register with any other Home Agent
HA and use appropriate Security Associations upon the failure of it's
serving Home Agent. HA. But this policy is not flexible enough to accommodate the
dynamic nature of subnets. home link.

3.5 Correct Ordering

Upon the HA_1 failure the sequence number information in the Binding
Cache of HA_1 will also be lost. The new HA_x to which MN will switch
will not have the knowledge about the sequence number of last sent BU
by the MN. This introduces new security vulnerabilities to the
Mobile IPv6.

3.6 Load Balancing

Mobile IPv6 does not include any specification about how the HAs
on home link will do load balancing among them. This is important for
utilizing the services of all HAs on the home link efficiently.

4. Solution Guidelines

This section describes guidelines for a solution to the above
mentioned problems. The subsections sub-sections 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]. Mobile IPv6.

4.2 IPsec Security with new Home Agent

The solution SHOULD provide a mechanism to quickly establish IPsec
Security Association between the Mobile Node MN and the new Home Agent HA such that the
service interruption is minimimal. minimal.

4.3 Seamless failure

It is strongly recommendated recommended that the failure of Home Agent HA should be transparent from
the Mobile Node. MN. 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 MN operation
as it is defined by Mobile-IPv6[1]. Mobile IPv6.

4.5 Messages over air interface

The solution SHOULD avoid introducing use minimal new messages more than what has
been defined by Mobile-IPv6[1]. messages.

4.6 Home Agent addition and failure

The solution SHOULD provide recovery mechanism for the failed Home
Agent. HA.
Also any new Home Agent HA added on the subnet home link SHOULD be ready to serve in
minimum amount of time possible.

4.7 Scalability Load Balancing

The solution complexity MUST increase at most linearly with SHOULD provide load balancing mechanism for the
number of Mobile Nodes registered and Home Agents configured HAs on
the
subnet. home link. It could be of centralized or distributed nature.

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

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

Acknowledgements

The authors would like to thank Vijay Devarapalli and Ryuji Wakikawa
for their continuous feedback and helping us improve this draft.

Funding for the RFC Editor function is currently provided by the
Internet Society.

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

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
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

Appendix: Changes from Previous Version

The following changes have been made to this document from version
00:

o Addition of types of failure, correct ordering and load balancing
sections in the RFC Editor function problem statement.

o Also failure detection and recovery sections are explained in
more detail in the problem statement.

o IPsec Security Associations with the new Home Agent section is currently provided by
organized into Dynamic and Manual Keying sub-sections.

o Load balancing requirement is added in the
Internet Society. solution guidelines
section.