One document matched: draft-korhonen-netext-redirect-01.txt
Differences from draft-korhonen-netext-redirect-00.txt
Network Working Group J. Korhonen
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track March 9, 2009
Expires: September 10, 2009
Redirect Option for Proxy Mobile IPv6
draft-korhonen-netext-redirect-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 10, 2009.
Copyright Notice
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
This document describes a Redirect mobility option and redirect
functionality for Proxy Mobile IPv6. The redirection takes place
during a Proxy Binding Update and Acknowledgement messages exchange.
Korhonen Expires September 10, 2009 [Page 1]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Redirect Mobility Option . . . . . . . . . . . . . . . . . . . 5
4. Proxy Mobile IPv6 Domain Considerations . . . . . . . . . . . . 6
5. Processing Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Mobile Access Gateway Considerations . . . . . . . . . . . 7
5.2. Local Mobility Anchor Considerations . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Korhonen Expires September 10, 2009 [Page 2]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
1. Introduction
This document describes a Redirect mobility option and redirect
functionality for Proxy Mobile IPv6 (PMIPv6). The redirection takes
place during a Proxy Binding Update (PBU) and a Proxy Binding
Acknowledgement (PBA) messages exchange between a Mobile Access
Gateway (MAG) and a Local Mobility Anchor (LMA). The redirection
functionality defined in this document can especially be used for
load balancing purposes during the initial PBU/PBA messages exchange,
but also for general purpose administrative and mobility services
subscription provisioning reasons.
The redirection functionality described in this document does not
depend on information provisioned to external entities, such as the
Domain Name System (DNS) or the Authentication, Authorization and
Accounting (AAA) infrastructure. The redirection is only applicable
between MAGs and LMAs that have an existing Security Association (SA)
set up. The trust relationship and coordination management between
LMAs within a PMIPv6 Domain is deployment specific and not described
in this document.
There are several reasons, why the redirection is an useful addition
to the PMIPv6 protocol. In order to reduce the signaling load
between the MAG and the LMA, and also towards the supporting backend
systems, the redirection should take place during the PBU/PBA message
exchange. The following list describes some of the identified
reasons:
o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6
specification does not specify how the PMIPv6 protocol should
treat anycast addresses assigned to mobility agents. Although RFC
4291 [RFC4291] now allows using anycast addresses as source
addresses, it does not make much sense to send a PBA from an
anycast address in a case where a PBU was sent to an anycast LMA
address. For example, a blade architecture LMA may appear to the
routing system as multiple LMAs with separate unicast IP addresses
and with one or more "grouping" anycast addresses.
o Independence from DNS: DNS-based load balancing is a common
practise. However, keeping MAGs up-to-date with LMA load status
using DNS is hard e.g., due caching and unpredictable zone update
delays. Generally, LMAs constantly updating [RFC2136] zone's
master DNS server might not feasible in a large PMIPv6 Domain due
to increased load on the master DNS server and additional
background signaling. Furthermore, MAGs may do (LMA) destination
address selection decisions that are not in-line what the DNS
administrator actually wanted [RFC3484].
Korhonen Expires September 10, 2009 [Page 3]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
o Independence from AAA: AAA-based solutions have basically the same
arguments as DNS-based solutions above. It is also typical that
AAA-based solutions offload the initial LMA selection to the DNS
infrastructure. The AAA infrastructure does not return an IP
address or a Fully Qualified Domain Name (FQDN) to a single LMA,
rather a FQDN representing a group of LMAs.
o LMAs with multiple IP addresses: a blade architecture LMA may
appear to the routing system as multiple LMAs with separate
unicast IP addresses. A MAG can initially select any of those LMA
IP addresses as the LMA Address using e.g., DNS- and AAA-based
solutions mentioned above. However, MAG's decision may be
suboptimal from the LMA point of view and immediate redirection to
a "proper LMA" would be needed. The LMA could use RFC 5142
[RFC5142] based approach but that would imply unnecessary setting
up of a mobility session in a "wrong LMA" with associated backend
system interactions, involve additional signaling between the MAG
and the LMA, and re-establishing mobility session to the new LMA
again with associated signaling interactions.
2. Requirements and Terminology
2.1. Requirements
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 [RFC2119].
2.2. Terminology
In addition to the terminology defined in RFC 5213 [RFC5213], the
following terminology is also used:
rfLMA
The LMA which receives the PBU from a MAG and decides to redirect
the IP mobility session, and forwards the PBU to the target LMA
(r2LMA).
r2LMA
The LMA to which a MAG was redirected to. During the redirection,
the PBA is already sent to the MAG from this LMA.
Korhonen Expires September 10, 2009 [Page 4]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
3. Redirect Mobility Option
The Redirect mobility option allows a LMA to inform a MAG of a
redirection to a new LMA during any PBU/PBA exchange. The
redirection functionality can be used, for example, for load
balancing purposes or for administrative and mobility services
subscription provisioning reasons. After the redirection, the MAG
MUST send subsequent PBUs and user traffic to the redirected LMA
address for the mobility session that the redirection concerned.
A PBU message MAY contain the Redirect mobility option as an
indication to a LMA that a MAG supports the redirection
functionality. In the PBU, the LMA Address included in the Redirect
mobility option MUST be set to an unspecified address (0::0 for IPv6
and 0.0.0.0 for IPv4). The LMA MAY include the Redirection mobility
option in a PBA only if the MAG indicated support for the redirection
functionality and the mobility session was redirected from the LMA to
another. The Redirect mobility option in the PBA MUST contain the
IPv6 address (unicast or anycast) of the rfLMA and MAY contain the
IPv4 address of the rfLMA. The PBA containing the Redirect mobility
option MUST be sent from the r2LMA. After receiving the PBA
containing the Redirect mobility option from the r2LMA, the MAG MUST
send subsequent PBUs and user traffic to the r2LMA that concern the
redirected mobility session.
The redirection functionality negotiation during the PBU/PBA exchange
is stateless. The LMA MUST NOT include the Redirect mobility option
in the PBA and perform the redirection, unless the MAG indicated the
redirection functionality support in the corresponding PBU. The LMA
MUST NOT include the Redirect mobility option unsolicited even if the
MAG had earlier indicated support for the redirection functionality.
The MAG MUST NOT conclude LMA's redirection functionality support
based on the absence of the Redirect mobility option in the PBA.
The Redirect mobility option has the alignment requirement of 4n+2.
There can zero or one Redirect mobility option in the PBU or in the
PBA. The format of the Redirect mobility option is shown below:
Korhonen Expires September 10, 2009 [Page 5]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 LMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 LMA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect Mobility Option
o Option Type: 8-bit identifier set to TBD1.
o Option Length: 8-bit unsigned integer, representing the length of
the Redirect mobility option in octets, excluding the Option Type
and Length fields. If the IPv4 LMA Address is included in the
option, the Option Length MUST be set to 20. Otherwise, the
Option Length MUST be set to 16.
o IPv6 LMA Address: the IPv6 address of the rfLMA or an unspecified
IPv6 address (i.e., 0::0).
o Optional IPv4 LMA Address: the IPv4 address of the rfLMA or an
unspecified IPv4 address (i.e., 0.0.0.0).
4. Proxy Mobile IPv6 Domain Considerations
The redirection solution defined in this document is only possible
between MAGs and LMAs that have an existing SA set up. It is the
responsibility of the rfLMA that receives a PBU from a MAG to
redirect the MAG to a such r2LMA whom the MAG already has a SA set up
with. Furthermore, the rfLMA and the r2LMA MUST have a prior
agreement and an established trust relationship to perform the
redirection. How a LMA learns and knows of other LMAs where the
mobility session can be redirected, is not covered by this document.
Dynamic negotiation of the SA during the redirection process is not
either covered by this document.
5. Processing Considerations
Korhonen Expires September 10, 2009 [Page 6]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
5.1. Mobile Access Gateway Considerations
If a MAG supports the redirection functionality defined in this
document, then the MAG MAY include the Redirect mobility option in
any PBU as an indication to a LMA that it supports the redirection
functionality. The Redirect mobility option MAY be included in the
initial PBU sent to the LMA or in any binding refreshing PBU. When
the MAG includes the Redirect mobility option in the PBU, the IPv6
LMA Address in the option MUST be set to unspecified address (i.e.,
0::0). If the MAG has IPv4 support enabled and the MAG supports
switching from IPv6 transport to IPv4 transport, the MAG SHOULD also
include an unspecified IPv4 address (i.e., 0.0.0.0) in the Redirect
mobility option.
If the MAG receives a PBA that contains the Redirect mobility option
from a LMA without first including the Redirect mobility option in
the corresponding PBU, the MAG MUST treat the PBA as if the binding
update failed and log the event. If the MAG receives a PBA that
contains the Redirect mobility option and the MAG had included the
Redirect mobility option in the corresponding PBU, then the MAG MUST
perform the following steps in addition to the normal RFC 5213 PBA
processing:
o Check if the Redirect mobility option contains the IP address of
the LMA to whom the MAG originally sent the PBU (i.e. the rfLMA).
If the check fails, then the MAG MUST treat the PBA as if the
binding update failed and log the event.
o Update the Binding Update List to correspond to the LMA Address
where the newly received PBA came from.
If the redirection was successful, the MAG MUST send subsequent PBUs
and user traffic to the new r2LMA Address for the mobility session
that the redirection concerned. The redirection concerns always one
mobility session at time. If the MAG includes the Redirect mobility
option in subsequent PBUs, the LMA MAY redirect the MAG again.
5.2. Local Mobility Anchor Considerations
If a LMA does not support the redirection functionality and the
Redirect mobility option defined in this document, then the LMA MUST
ignore the option received in PBUs. If the LMA supports the
redirection functionality and the received PBU contains the Redirect
mobility option, then the LMA MAY redirect the MAG to a new LMA. In
the case of redirection, the r2LMA MUST always include the IPv6
address (unicast or anycast) of the rfLMA in the Redirect mobility
option in the PBA. If the rfLMA had IPv4 support enabled, then the
Korhonen Expires September 10, 2009 [Page 7]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
r2LMA MUST include the IPv4 address of the rfLMA in the Redirect
mobility option.
If the redirection takes place during an established mobility
session, then the rfLMA MUST clean up and remove the mobility session
after redirecting the MAG to the new LMA.
The LMA MUST NOT redirect the MAG to a new LMA that it knows the MAG
does not have a SA with. The LMA MUST NOT redirect the MAG to a LMA
that the LMA does not have a prior redirection agreement and an
established trust relationship to perform the redirection. These SA
related knowledge issues and trust relationships are deployment
specific in a PMIPv6 Domain. If the redirection were to involve
context transfer and other coordination management between LMAs, that
is again deployment specific for LMAs and in a PMIPv6 Domain.
The LMA MUST NOT redirect a MAG using IPv6 transport to a new LMA
using IPv4 transport, if the MAG does not indicate support for IPv4
in the Redirect mobility option, as there is no guarantee that the
MAG supports switching from IPv6 transport to IPv4 transport.
6. Security Considerations
The security considerations of PMIPv6 signaling described in RFC 5213
[RFC5213] apply to this document. An incorrectly configured LMA may
cause unwanted redirection attempts to non-existing LMAs or to other
LMAs that do not have and will not have a SA with the redirected MAG.
At the same time, a falsely redirected MAG will experience failed
binding updates or creation of mobility sessions. An incorrectly
configured LMA may also cause biased load distribution within a
PMIPv6 Domain. This document also assumes that the LMAs that
participate to redirection have adequate prior agreement and trust
relationship between each other.
7. IANA Considerations
A new mobility option for the use with PMIPv6 is defined in the RFC
3775 [RFC3775] "Mobility Options" registry. The mobility option is
defined in Section 3:
Redirect Mobility Option is set to TBD1
Korhonen Expires September 10, 2009 [Page 8]
Internet-Draft Redirect Option for Proxy Mobile IPv6 March 2009
8. Acknowledgements
The author would like to thank Basavaraj Patil and Domagoj Premec for
their reviews and comments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
"Mobility Header Home Agent Switch Message", RFC 5142,
January 2008.
Author's Address
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
Email: jouni.nospam@gmail.com
Korhonen Expires September 10, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 07:35:56 |