Mobility Extensions for IPv6 (MEXT) G. Hampel
Internet Draft T. Klein
Intended status: Standards Track Alcatel-Lucent
Expires: September 27, 2011 Feb 23, 2011
Mobile IPv6 Route Optimization without Home Agent
draft-hampel-mext-ro-without-ha-00
Abstract
This document describes extensions to Mobile IPv6 (MIPv6), which
permit hosts to conduct route optimization (RO) without home agent.
These extensions add robustness and flexibility to MIPv6 since
mobility can be supported when the home agent becomes temporarily
unavailable or when home-agent support is not desirable. These
extensions are compliant with all peer-to-peer signaling
solutions that are currently supported for RO.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 27, 2011.
Hampel et al. Expires September 27, 2011 [Page 1]
Internet-Draft Route Optimization without Home Agent Feb 2011
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operation of Route Optimizaiton without Home Agent . . . . . . 4
3.1. Operations on network layer . . . . . . . . . . . . . . . 5
3.2. Operations on higher protocol layers . . . . . . . . . . . 6
3.3. Operation during unavailability of HA . . . . . . . . . . 7
3.4. Learning about correspondent's RO support . . . . . . . . 8
4. HoA Support Mobility Option . . . . . . . . . . . . . . . . . . 8
5. Policy Changes . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Performance Limitations of HA-free RO . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
MIPv6 Route Optimization (RO) [1] enables hosts to move between
networks during ongoing traffic connections, while permitting traffic
to flow along the shortest routing path. RO hence minimizes end-to-
end transport delay and it relieves the home agent (HA) from
the processing-intense task of relaying payload traffic.
Hampel et al. Expires September 27, 2011 [Page 2]
Internet-Draft Route Optimization without Home Agent Feb 2011
During RO, the HA's relay function is still required for a variety of
purposes. It supports a location service in case the mobile has to be
reached while away from home. It further relays mobility headers sent
by mobile correspondents. The HA also provides an alternative path
for home tests when the mobile is away from home. Finally the HA's
relay function is used as a fallback in case the correspondent does
not support RO.
While providing these benefits, the requirement for HA support comes
at a certain cost:
- Reliability problem: The HA is a single point of failure. When it
becomes unavailable, RO is not supported anymore.
- Lack of flexibility: When the mobile does not have a HA, RO is not
supported at all.
- Packet and processing overhead: When the mobile is away from home,
it must use a home address (HoA) pertaining to its home link
to enjoy RO support. This adds significant overhead to payload
packets due to Type 2 Routing headers and Home Address Option
headers as well as processing overhead. This overhead applies even
if the mobile remains stationary.
- Additional signaling traffic: Signaling handshakes have to be
conducted between mobile and HA at every mobility event.
In many cases, the HA's relay function is not needed during RO, or it
is undesirable in case the cost outweighs the benefits:
- For traffic between mobile clients and stationary servers, the HA's
location service is not needed. This applies to a large fraction of
mobile internet traffic. Further, location service may also be
provided by other means such as dynamic DNS or on application layer
(e.g. SIP registrar).
- When the correspondent is mobile, it can send its mobility header
messages along the shortest routing path to the mobile's CoA
instead of using the detour via the mobile's HA.
- The home-test requirement does not imply the need for a HA but the
availability of a routable path to the mobile's HoA. Multi-homed
hosts that wish to migrate connections from their home link to
another simultaneously supported link can conduct the home test
without HA. If RO is secured via cryptographically generated
addresses (CGA) according to RFC 4866 [2], only one initial home
test is necessary, which can be conducted while the mobile is
Hampel et al. Expires September 27, 2011 [Page 3]
Internet-Draft Route Optimization without Home Agent Feb 2011
still at home. If stronger security is used such as outlined by
RFC 4449 [3], the home test can be completely avoided.
- When the mobile knows about the correspondent's RO support it does
not need the HA as a fallback relay. This knowledge may be
available from prior connections or through means external to the
standard.
Based on these reasons, it makes sense to support RO without HA.
Note that such an enhancement was first proposed by RFC 4651 [4].
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 [RFC 2119].
In this document, the following terms are used:
Legacy Mobile IPv6
Refers to MIPv6 [1] and its extensions excluding those
described in this document.
HA-bound RO
Refers to RO according to legacy MIPv6
HA-free RO
Refers to RO where the mobile does not have a HA
Permanent Home Address
Home address (HoA) according to legacy MIPv6
Virtual Home Address
IPv6 address that holds the equivalent function in
HA-free RO as the permanent HoA in HA-bound RO.
3. Operation of Route Optimization without Home Agent
Two distinct scenarios are considered. In the first scenario, the
mobile desires to conduct RO without HA support even if a HA is
available. This scenario is referred to as HA-free RO and described
in subsection 3.1 and 3.2. In the second scenario, the mobile seeks
HA-support during RO but the HA becomes unavailable prior or during
RO. This scenario can be treated as a special case of HA-free RO
and is discussed in subsection 3.3. Subsection 3.4 elaborates on how
the mobile can identify the correspondent's support of RO.
Hampel et al. Expires September 27, 2011 [Page 4]
Internet-Draft Route Optimization without Home Agent Feb 2011
3.1. Operations on network layer
HA-free RO implies that all traffic and all signaling messages flow
on the shortest routing path between mobile and correspondent.
In the absence of a HA, the mobile does not have a home network.
Therefore, the mobile interprets the IPv6 address of one of its links
as a "virtual" HoA as if it resided in its home network. The virtual
HoA MUST be a unicast routable IPv6 address. The mobile uses the
virtual HoA to start transport connections subject to the limitations
discussed in 3.2.
When the mobile moves to another IPv6 address, it interprets this
address as a care-of-address (CoA). Consequently, it conducts a
correspondent registration, which creates a binding between virtual
HoA and CoA. The CoA MUST also be a unicast routable IPv6 address.
If a home test is required prior to the correspondent registration,
the home test MUST be based on the mobile's virtual HoA. This means
that the virtual HoA must still be supported during the home test.
The mobile omits the home registration.
All signaling between mobile and correspondent is the same for
HA-free RO as for HA-bound RO. In HA-free RO, the mobile MAY omit
message exchanges with the HA.
When the correspondent is also mobile, it can send its mobility
header messages to either the mobile's virtual HoA or to the
mobile's CoA. If the mobile's virtual HoA is not on link anymore,
the correspondent MUST send its mobility header messages to the
mobile's CoA. This policy is in departure from RFC 3775 [1], which
requires that mobile correspondents MUST always send their mobility
header messages to the mobile's permanent HoA.
To provide clarification to the correspondent on where it should
send its own mobility header messages, the mobile has to inform the
correspondent about the on-link support of its virtual HoA. This
requires introduction of a new mobility header option, referred to as
HoA-Support Mobility option, which the mobile inserts into
mobility header messages such as BU, Early BU, Home Test Init and
Care-of Test Init [1][2]. This option holds a HoA Support flag
with settings "supported" or "not supported". The mobile SHOULD
insert this option only when the on-link support of the virtual HoA
has changed. The HoA-Support Mobility option is defined in section 4.
Hampel et al. Expires September 27, 2011 [Page 5]
Internet-Draft Route Optimization without Home Agent Feb 2011
The correspondent SHOULD support an additional field in its binding
cache referred to as the HoA Support field, which is updated
according to the entry in the mobile's HoA-Support Mobility
option. The HoA Support field is initialized with "supported".
If this field is set to "not supported", the correspondent MUST send
its mobility header messages to the mobile's CoA and it MUST insert
the Type-2 Routing header into these messages. Otherwise the
correspondent MUST proceed according to legacy MIPv6 and send
its mobility header messages to the mobile's HoA (this can be the
mobile's virtual or permanent HoA).
When the correspondent receives a HoA-Support Mobility option in
a mobility header message, it MUST attach a copy of this option in
the associated response message such as Binding Acknowledgement (BA),
early BA, Home Test and Care-of Test. This informs the mobile that
the correspondent complies with the extensions of HA-free RO.
In case the correspondent does not support the extensions for HA-free
RO provided by this document, it simply ignores the new mobility
option. The missing HoA-Support Mobility option in the return message
is an indicator for the mobile that HA-free is not supported
by the correspondent. In this case, connections make break in case
both peers are mobile and the correspondent moves while the mobile's
virtual HoA is not on link. Subsection 3.4 discusses on how such a
situation can be avoided.
3.2. Operations on higher protocol layers
Legacy MIPv6 uses the permanent HoA as an invariant on higher
protocol layers (e.g. transport layer), which shuns IP mobility from
these layers. For HA-free RO, the same functionality is accomplished
by using the virtual HoA instead of the permanent HoA. Although the
virtual HoA may have limited lifetime on the link, it is used by
higher protocol layers throughout the lifetime of the connection.
For new connections, higher protocol layers use one of the host's
current on-link addresses as the virtual HoA unless an active BU
entry exists in the BU list or binding cache. If such an entry
exists, higher protocol layers should use the virtual HoA of this
entry. This guarantees that temporally overlapping connections with
the same correspondent use the same virtual HoA.
A multi-homed host MAY start connections from different
simultaneously supported IP addresses and declare each IP address as
a virtual HoA for the associated connection unless the host already
holds a BU entry or binding cache entry for that correspondent. This
behavior is compliant with the spirit of RFC 3775 [1], which permits
Hampel et al. Expires September 27, 2011 [Page 6]
Internet-Draft Route Optimization without Home Agent Feb 2011
behavior is compliant with the spirit of RFC 3775 [1], which permits
simultaneous support of multiple permanent HoAs pertaining to
different home subnet prefixes. RFC 3755 makes no restrictions to
the topological distance between the home subnet prefixes pertaining
to these HoAs.
It is also permissible that the mobile uses an HA for some
connections and HA-free RO for others. In this case the HoA can be of
permanent and virtual nature at the same time.
Under all circumstances, the HoA (virtual or permanent) used for the
home test MUST always match the HoA used by higher protocol layers.
3.3. Operation during unavailability of home agent
The mobile determines that the HA is unavailable after it has tried
to communicate with the HA and the HA hasn't responded within an
adequate timeframe or after a certain number of message
retransmissions.
When the mobile has decided that the HA is unavailable, it switches
to HA-free RO. The following scenarios have to be considered:
- In case the mobile cannot obtain an ICMP HA discovery response
message or an ICMP Mobile Prefix Advertisement message from the HA,
the mobile MAY continue operation using HA-free RO.
- In case the home registration fails while the mobile resides in its
home network, the mobile MAY use its permanent HoA as a virtual HoA
and continue operation using HA-free RO. It MAY also decide to use
another on-link address as its virtual HoA.
- In case the home registration fails while the mobile resides in a
foreign network and before the first correspondent registration has
successfully completed, the connection breaks since mobile and
correspondent have not yet successfully engaged into RO.
- In case the mobile resides in a foreign network and the home
registration or the home test fails after the first correspondent
registration has successfully completed, the mobile MAY use its
permanent HoA as a virtual HoA and continue operation using HA-free
RO. In this case, the mobile SHOULD send a BU to the correspondent
rightaway and insert the HoA Support Mobility option.
When the HA is unavailable and the mobile enters HA-free RO, it MAY
still follow a retransmission schedule to re-engage into
Hampel et al. Expires September 27, 2011 [Page 7]
Internet-Draft Route Optimization without Home Agent Feb 2011
HA-bound RO. In case the HA becomes responsive again, the mobile
MAY return to HA-bound RO for all those connections, whose
virtual HoAs match the permanent HoA. All other connections MUST
remain in HA-free RO.
If HA-bound RO is resumed, the mobile SHOULD send a BU with HoA-
Support Mobility option to the correspondent to update the
correspondent about the availability of its HoA.
3.4. Learning about correspondent's RO Support
Prior to engaging into HA-free RO, the mobile can determine if the
correspondent supports HA-bound RO or HA-free RO. The mobile MAY
pursue one of the following strategies:
- For frequently contacted correspondents, the mobile MAY cache
from prior sessions if HA-bound or HA-free RO is supported.
- The mobile MAY conduct a home test prior to connection
establishment and include the HoA Support Mobility Option.
- The mobile MAY start the connection in HA-bound RO and switch
to HA-free RO as soon as the correspondent registration has
succeeded.
4. HoA Support Mobility Option
The HoA Support Mobility option is inserted into a mobile header
message to inform the correspondent about the on-link support of its
virtual HoA. The correspondent reflects this mobility option in the
response message.
The HoA Support Mobility option has the following entries:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | HoA Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HoA Routability
8-bit unsigned integer indicating the connectivity of the virtual
HoA. The following values are supported:
0 HoA is not supported
1 HoA is supported
Hampel et al. Expires September 27, 2011 [Page 8]
Internet-Draft Route Optimization without Home Agent Feb 2011
5. Policy Changes
All mobiles that follow the extensions for HA-free RO described in
this document MAY omit signaling handshakes with their HA.
6. Security Considerations
HA-free RO is subject to the same security concerns as HA-bound RO.
These concerns have been addressed by RFC 3775 [1] and RFC 4225 [5].
Since HA-free RO does not alter the signaling between mobile and
correspondent and since the HA does not provide additional security
support for RO, omission of HA-support should not negatively impact
the security of HA-free RO beyond that of HA-bound RO.
7. Performance Limitations of HA-free RO
HA-free RO has some principle limitations regarding operation and
performance:
- When a mobile uses the return routability procedure according to
RFC 3775, it always has to sustain the virtual HoA on one link to
conduct the home tests.
- Mobile hosts may require a location service external to MIPv6 in
case they support a server function and move to foreign networks.
- Simultaneous movement of mobile and correspondent cannot be
supported unless both nodes are multi-homed and sustain an extended
"make-before-break" time period.
8. IANA Considerations
The value for the HoA Support Mobility option type must be assinged
by IANA.
9. References
9.1. Normative References
[1] D. Johnson, C. Perkins and J. Arkko, "Mobile Support in IPv6",
RFC3775, June 2004
[2] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route Optimization for
Mobile IPv6", RFC4866, May 2007
Hampel et al. Expires September 27, 2011 [Page 9]
Internet-Draft Route Optimization without Home Agent Feb 2011
[3] C. Perkins, "Securing Mobile IPv6 Route Optimization Using a
Static Shared Key", RFC4449, June 2006.
[4] C. Vogt and J. Arkko, "A Taxonomy and Analysis of Enhancements to
Mobile IPv6 Route Optimization", RFC4651, February 2007
[5] P. Nikander, J. Arkko, T. Aura, G. Montenegro and E. Nordmark,
"Mobile IP Version 6 Route Optimization Security Design
Background", RFC4225, December 2005
Authors' Addresses
Georg Hampel
Bell Labs, Alcatel-Lucent
600 Mountain Avenue
Murray Hill, NJ 07974
USA
Tel: +1 908 582 2377
Email: georg.hampel@alcatel-lucent.com
Thierry Klein
Bell Labs, Alcatel-Lucent
600 Mountain Avenue
Murray Hill, NJ 07974
USA
Tel: +1 908 582 3585
Email: thierry.klein@alcatel-lucent.com
Hampel et al. Expires September 27, 2011 [Page 10]