Network Working Group J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track S. Gundavelli
Expires: November 25, 2010 Cisco
H. Yokota
KDDI Lab
X. Cui
Huawei Technologies
May 24, 2010
Runtime LMA Assignment Support for Proxy Mobile IPv6
draft-ietf-netext-redirect-03.txt
Abstract
This document describes a redirect functionality and corresponding
mobility options for Proxy Mobile IPv6. The redirect functionality
allows a dynamic runtime assignment of a Local Mobility Anchor and
redirecting the mobility session to the assigned Local Mobility
Anchor.
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 November 25, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Korhonen, et al. Expires November 25, 2010 [Page 1]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 6
4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 7
4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 7
5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 10
5.1. Common Mobile Access Gateway Operation . . . . . . . . . . 10
5.2. Common Local Mobility Anchor Operation . . . . . . . . . . 10
5.3. Mobility Session Created During the Redirection . . . . . 11
5.3.1. General Operation . . . . . . . . . . . . . . . . . . 11
5.3.2. Mobile Access Gateway Operation . . . . . . . . . . . 12
5.3.3. Local Mobility Anchor Operation . . . . . . . . . . . 13
5.4. Mobility Session Created After the Redirection . . . . . . 13
5.4.1. General Operation . . . . . . . . . . . . . . . . . . 13
5.4.2. Mobile Access Gateway Operation . . . . . . . . . . . 14
5.4.3. Local Mobility Anchor Operation . . . . . . . . . . . 15
6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 16
7. Configuration Variables . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Korhonen, et al. Expires November 25, 2010 [Page 2]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
1. Introduction
This document describes the Redirect-Capability and the Redirect
mobility options, and the corresponding functionality for a runtime
assignment of the Local Mobility Anchor (LMA) for Proxy Mobile IPv6
(PMIPv6). Hereafter the terms 'runtime assignment' and 'redirection'
are used interchangeably throughout this specification. The runtime
assignment takes place during a Proxy Binding Update (PBU) and a
Proxy Binding Acknowledgement (PBA) messages exchange between a
Mobile Access Gateway (MAG) and a LMA. The runtime assignment
functionality defined in this specification can be used, for example,
for load balancing purposes during the initial PBU/PBA messages
exchange. However, other use cases are also possible. In case of
load balancing, the runtime assignment approach is just one
implementation option. MAGs and LMAs can implement other solutions
that are, for example, completely transparent at PMIPv6 protocol
level and do not depend on the functionality defined in this
specification.
The runtime assignment functionality described in this specification
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 trust relationship and
coordination management between LMAs within a PMIPv6 domain is
deployment specific and not described in this specification.
There are number of reasons, why the runtime assignment is an useful
addition to the PMIPv6 protocol. The following list describes some
identified ones:
o LMAs with multiple IP addresses: a cluster of LMAs or 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. However, MAG's initial selection may be
suboptimal from the LMA point of view and immediate redirection to
a "proper LMA" would be needed. The LMA could use [RFC5142] based
approach but that would imply unnecessary setting up of a mobility
session in a "wrong LMA" with associated backend support system
interactions, involve additional signaling between the MAG and the
LMA, and re-establishing mobility session to the new LMA again
with associated signaling.
o Bypassing a load balancer: a cluster of LMAs or a blade
architecture LMA may have a load balancer in front of them or
integrated in one of the LMAs. The load balancer would represent
multiple LMAs during the LMA discovery phase and only its IP
address would be exposed to the MAG hiding possible individual LMA
Korhonen, et al. Expires November 25, 2010 [Page 3]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
or LMA blade IP addresses from the MAG. However, if all traffic
must always go through the load balancer it becomes quickly a
bottleneck. Therefore, a PMIPv6 protocol level support for
bypassing the load balancer after the initial PBU/PBA exchange
would greatly help scalability. Also bypassing the load balancer
as soon as possible allows implementing load balancers that do not
maintain any MN specific state information.
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 [I-D.ietf-netlmm-lma-discovery]. 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].
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 [RFC5779]. 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 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. 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. A MAG could then initially
send a PBU to an anycast LMA address and receive a PBA from an
anycast LMA address. Once the MAG receives the unicast address of
the selected r2LMA through the initial PBU/PBA exchange, the MAG
MUST immediately start using that unicast address for the
redirected mobility session.
Korhonen, et al. Expires November 25, 2010 [Page 4]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
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 [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 to the target LMA (r2LMA).
r2LMA
The LMA to which a MAG was redirected to.
Redirection Domain
A group of LMAs that consist of at least one rfLMA and one or more
r2LMAs. A rfLMA is allowed to redirect mobility sessions only to
r2LMAs that belong to the same redirection domain.
Korhonen, et al. Expires November 25, 2010 [Page 5]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
3. Proxy Mobile IPv6 Domain Assumptions
The redirection functionality has several assumptions on the PMIPv6
domain. They are discussed here as they have impact on PMIPv6
deployment.
Each functional LMA, whether that is a separate LMA in a cluster or
an individual blade in a chassis, participating to the redirection
MUST be reachable at an unicast IP address. The rfLMA and the r2LMA
MUST have a prior agreement and an established trust relationship to
perform the redirection. In this case, the rfLMA and the r2LMA are
said to belong to the same 'redirection domain'.
The rfLMA MUST NOT redirect the mobility session to a r2LMA that is
not able to accept the redirected mobility session. That is, the
redirection functionality is not enabled in the r2LMA, or the r2LMA
does not belong to the same redirection domain as the rfLMA, or the
r2LMA is down or otherwise unreachable. How the rfLMA learns and
knows of other r2LMAs in the redirection domain, is not covered by
this specification.
Each LMA and MAG participating to the redirection is assumed to have
required Security Associations (SA) already set up in advance.
Dynamic negotiation of the SAs using e.g., IKEv2 [RFC4306] SHOULD be
supported but is out of scope of this specification.
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 using the Redirection-
Capability mobility option. 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.
MAGs and LMAs MUST support the redirection functionality only during
the initial PBU/PBA exchange that creates a new mobility session.
Korhonen, et al. Expires November 25, 2010 [Page 6]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
4. Mobility Options
4.1. Redirect-Capability Mobility Option
A PBU message MAY contain the Redirect-Capability mobility option as
an indication to a LMA that a MAG supports the redirection
functionality. When this option is included, the MAG may be
redirected to another LMA, and the redirected to LMA may
simultaneously create a Binding Cache Entry (BCE). Hence, the MAG
including this option MUST be able to support both redirection, and
redirection with BCE creation. The Redirect-Capability mobility
option has the alignment requirement of 4n. There can zero or one
Redirect-Capability mobility option in the PBU. The format of the
Redirect-Capability mobility option is shown below:
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 |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect-Capability Mobility Option
o Option Type: 8-bit identifier set to TBD1.
o Option Length: 8-bit unsigned integer, representing the length of
the Redirect-Capability mobility option in octets, excluding the
Option Type and Length fields. The Option Length MUST be set to
2.
o 'F' flag: This bit is set (1) if the MAG supports IPv4 transport.
Otherwise, the bit is unset (0).
o Reserved: This field is reserved for future use. MUST be set to
zero.
4.2. Redirect Mobility Option
The LMA MAY include the Redirect mobility option in a PBA only if the
MAG indicated support for the redirection functionality and the MAG
got redirected from a LMA to another. The Redirect mobility option
in the PBA MUST contain an unicast IPv6 address of the r2LMA. The
Redirect mobility option in the PBA MAY contain an IPv4 address of
the r2LMA. There can zero or one Redirect mobility option in the
PBA.
The Redirect mobility option has the alignment requirement of 4n.
Korhonen, et al. Expires November 25, 2010 [Page 7]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
The format of the Redirect mobility option is shown below:
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 |K|N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional IPv6 r2LMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 r2LMA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirect Mobility Option
o Option Type: 8-bit identifier set to TBD2.
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 'K' flag is set and 'N' is unset, then the
length MUST be 18. If 'K' flag is unset and 'N' is set, then the
length MUST be 6. If both 'K' and 'N' flags are set, then the
length MUST be 22.
o 'K' flag: This bit is set (1) if the 'Optional IPv6 r2LMA Address'
is included in the mobility option. Otherwise, the bit is unset
(0).
o 'N' flag: This bit is set (1) if the 'Optional IPv4 r2LMA Address'
is included in the mobility option. Otherwise, the bit is unset
(0).
o Reserved: This field is reserved for future use. MUST be set to
zero.
o Optional IPv6 r2LMA Address: the unicast IPv6 address of the
r2LMA. This value is present if the r2LMA IPv6 address is
available.
o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This
value is present if the r2LMA IPv4 address is available and the
'F' flag was set in the corresponding Redirect-Capability Mobility
Option.
Korhonen, et al. Expires November 25, 2010 [Page 8]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
Both 'K' and 'N' flags MUST NOT be unset at the same time.
Similarly, r2LMA IPv6 and/or IPv4 addresses MUST be included in the
mobility option.
Korhonen, et al. Expires November 25, 2010 [Page 9]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
5. Runtime LMA Assignment
5.1. Common Mobile Access Gateway Operation
The base PMIPv6 protocol [RFC5213] operation is such that a MAG sends
a PBU to an LMA which results in a BCE being created at the LMA and a
PBA sent back (from the LMA) to the MAG, which in turn creates an
entry in the Binding Update List (BUL). The semantics of the base
protocol operation are extended with the redirection feature by
having the rfLMA forward the PBU sent by a MAG to the r2LMA (which
creates the BCE) and the PBA which is routed back to the sending MAG
through rfLMA, causing the MAG to create a BUL which points to r2LMA.
The semantics in the case where the rfLMA does not forward the PBU
but instead returns a PBA to the MAG which includes the Redirect
Mobility option which has the address of the r2LMA are also extended
from the base protocol operation.
Backwards compatibility is maintained in a deployment wherein some
MAGs may have the ability to support redirection while others do not.
This is accomplished by the use of the Redirect-Capability Mobility
Option being included in the PBU sent by the MAG. An LMA which has
the capability to redirect a MAG to a target r2LMA on receiving a PBU
from a legacy MAG can only respond with a PBA which does not include
any r2LMA address.
When the redirection functionality is enabled, then the MAG MAY
include the Redirect-Capability mobility option in a PBU that
establishes a new mobility session. The Redirect-Capability mobility
option in the PBU is also an indication to a LMA that the MAG
supports the redirection functionality and is prepared to be
redirected. The redirection concerns always one mobility session at
time.
If the MAG receives a PBA that contains the Redirect mobility option
without first including the Redirect-Capability mobility option in
the corresponding PBU, then the MAG MUST treat the PBA as if the
binding update failed and log the event.
5.2. Common Local Mobility Anchor Operation
The text in the following sections refers to a 'LMA' when it means
the combination of the rfLMA and the r2LMA i.e., the entity where
redirection is possible. When the text points to a specific LMA role
during the redirection, it uses either the 'rfLMA' or the 'r2LMA'.
If the redirection functionality is enabled in the LMA but the
redirection is not going to take place for a reason or other, and the
rfLMA is not willing to serve (or capable of) as a normal RFC 5213
Korhonen, et al. Expires November 25, 2010 [Page 10]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
LMA for the MAG, then the rfLMA MUST reject the PBU and send back a
PBA with Status Value set to 130 (Insufficient resources) error code.
Otherwise, the rfLMA MUST act as a normal RFC 5213 defined LMA for
the MAG.
The rfLMA MUST only redirect the MAG to a new r2LMA that it knows the
MAG has a SA with or the MAG and the r2LMA are able to create it
dynamically. The rfLMA MUST NOT redirect the MAG to a r2LMA that the
rfLMA and the r2LMA do not have a prior redirection agreement and an
established trust relationship for the redirection. These SA related
knowledge issues and trust relationships are deployment specific in a
PMIPv6 domain and in a redirection domain, and out of scope of this
specification. Possible context transfer and other coordination
management between the rfLMA and the r2LMA, are again deployment
specific for LMAs in a redirection domain.
The rfLMA MUST NOT redirect a MAG using IPv6 transport to a new r2LMA
using IPv4 transport, if the MAG does not indicate support for IPv4
in the Redirect-Capability mobility option, as there is no guarantee
that the MAG supports switching from IPv6 transport to IPv4
transport. The same also applies for redirecting a MAG using IPv4
transport to a r2LMA supporting only IPv6 transport.
As a result of a successful redirection, the PBA MUST contain the
Redirect mobility option with a valid r2LMA Address and the PBA
Status Value indicating successful redirection.
In general the r2LMA may be a normal RFC 5213 LMA without any
redirection functionality. The r2LMA MAY also include rfLMA
functionality in which case the consideration described in the
following sections for the rfLMA apply. If the redirection
functionality is implemented but not enabled in a LMA, then the LMA
MUST ignore the Redirect-Capability mobility option received in PBUs
and act as a LMA defined in RFC 5213.
5.3. Mobility Session Created During the Redirection
5.3.1. General Operation
During the redirection, the PBA is returned from the LMA Address
where the PBU was sent to i.e., from the rfLMA. After the
redirection all PMIPv6 communication continues directly between the
MAG and the r2LMA. The overall redirection flow sequence is shown in
Figure 1.
Korhonen, et al. Expires November 25, 2010 [Page 11]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
MAG rfLMA r2LMA
| | |
1) |--PBU-->| ~ ~ ~ | (redirection takes place, BCE gets created in
2) |<--PBA--| ~ ~ ~ | r2LMA, PBA contains r2LMA information and
| | | Status Value set to
| | | Accepted_and_Redirected_with_Binding)
3) |<=====data======>|
| | |
4) |-------PBU------>| (lifetime extension,
5) |<------PBA-------| de-registration, etc.)
| | |
Figure 1: Runtime LMA assignment from rfLMA to r2LMA and setting up a
mobility session in the r2LMA within a redirection domain
The assumption in the signaling flow step 1) shown in Figure 1 is
that the mobility session gets created in the r2LMA, although the
rfLMA is responsible for interfacing with the MAG. The interaction
between the rfLMA and the r2LMA in the redirection domain is not
defined in this specification. There are several possible solutions
for the rfLMA and the r2LMA interaction depending on e.g. the
collocation properties of the rfLMA and the r2LMA, and whether the
rfLMA and the r2LMA implement an interface that is interoperable
among multiple LMA vendors.
5.3.2. Mobile Access Gateway Operation
In addition to MAG operations described in Section 5.1, the following
considerations has to taken into account during the redirection.
If the MAG receives a PBA that contains the Redirect mobility option
and the Status Value set to TBD3
(Accepted_and_Redirected_with_Binding), and the MAG had included the
Redirect-Capability mobility option in the corresponding PBU, then
the MAG MUST perform the following steps in addition to the normal
RFC 5213 PBA processing:
o If there is no SA between the MAG and the r2LMA, the MAG MAY treat
the PBA as if the binding update failed and log the event. The
MAG SHOULD initiate a dynamic creation of the SA between the MAG
and the r2LMA (note that the dynamic creation of the SA is outside
of the scope of this specification).
If the redirection was successful, the MAG updates the BUL to
correspond the r2LMA Address included in the received Redirect
mobility option. There is no need to resend any PBUs to the r2LMA
after a successful redirection. The mobility session has already
been established in the r2LMA as indicated by the Status Value TBD3
Korhonen, et al. Expires November 25, 2010 [Page 12]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
(Accepted_and_Redirected_with_Binding). The MAG MUST send subsequent
binding refreshing PBUs and user traffic to the new r2LMA Address.
5.3.3. Local Mobility Anchor Operation
If the redirection functionality is enabled in the LMA and the
received PBU contains the Redirect-Capability mobility option, then
the rfLMA MAY redirect the MAG to a new r2LMA. In the case of
redirection, the PBA returned to the MAG MUST always include the
unicast IPv6 address of the r2LMA in the Redirect mobility option and
the Status Value set to TBD3 (Accepted_and_Redirected_with_Binding).
If the r2LMA has IPv4 support enabled, then the PBA returned to the
MAG SHOULD include the IPv4 address of the r2LMA in the Redirect
mobility option. If the rfLMA did not redirect the MAG to a new
r2LMA or the redirection failed, then the PBA MUST NOT contain the
Redirect mobility option.
If the redirection was successful, the mobility session MUST be
established in the r2LMA. The actual PBU processing that creates the
mobility session and the corresponding BCE takes place in the r2LMA.
However, depending on the LMA's implementation of the PMIPv6 security
framework, the security processing (such as IPsec) of the PBU may
take place in the rfLMA before the PBU is transferred from the rfLMA
to the r2LMA. Whenever the redirection processing has involved the
r2LMA, the PBA sent by the rfLMA to the MAG MUST reflect the
information the r2LMA would include in its PBA (such as mobility
options, Status Value and so on). The only exceptions are possible
security related options that the rfLMA MAY need to modify or remove.
The rfLMA is always allowed to add more mobility options to the PBA.
During the redirection process, the rfLMA MAY need to maintain a
temporary MAG-rfLMA-r2LMA state and may even act as a "proxy MAG" to
the r2LMA. This, however, depends on the collocation properties of
the rfLMA and the r2LMA, and how the rfLMA interact with the r2LMA.
The interaction may happen as a PBU/PBA packet forwarding in a
conventional sense or as an inter-blade communication using some LMA
architecture specific communication method. Once the redirection has
completed successfully from the rfLMA point of view and it has sent
the PBA to the MAG, the rfLMA can remove all state information
regarding the recent redirection.
5.4. Mobility Session Created After the Redirection
5.4.1. General Operation
During the redirection the PBA is returned from the LMA Address where
the PBU was sent to i.e., from the rfLMA. After the redirection, the
MAG has to initiate another PBU/PBA exchange with the r2LMA and after
Korhonen, et al. Expires November 25, 2010 [Page 13]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
that all PMIPv6 communication continues between the MAG and the
r2LMA. The overall redirection flow sequence is shown in Figure 2.
MAG rfLMA r2LMA
| | |
1) |--PBU-->| | (redirection takes place, PBA contain
2) |<--PBA--| | r2LMA information, Status Value set
| | | to Rejected_but_Redirected)
| | |
3) |-------PBU------>| (BCE gets created in r2LMA)
4) |<------PBA-------|
| | |
5) |<=====data======>|
| | |
6) |-------PBU------>| (lifetime extension,
7) |<------PBA-------| de-registration, etc.)
| | |
Figure 2: Runtime LMA assignment from rfLMA to r2LMA within a
redirection domain
The assumption in the signaling flow steps 1) and 2) shown in
Figure 2 is that the MAG is only redirected to the r2LMA. The
mobility session creation with the r2LMA requires a new PBU/PBA
exchange with the r2LMA using the normal RFC 5213 procedures.
5.4.2. Mobile Access Gateway Operation
The MAG operation is exactly the same as described in Section 5.1 and
Section 5.3.2 except for two aspects:
o The Status Value in the received PBA is set to TBD4
(Rejected_but_Redirected). This indicates to the MAG that there
is no mobility session (i.e. BCE) created in the r2LMA and not in
the rfLMA either. The MAG was only assigned with a new r2LMA
Address information.
o The MAG MUST initiate a new PBU/PBA exchange with the r2LMA in
order to establish a mobility session. Only after a successful
PBU/PBA exchange with the r2LMA, the redirection has completed.
The initial PBU sent to the r2LMA SHOULD NOT contain the Redirect-
Capability mobility option in order to avoid possible immediate
new redirection.
Korhonen, et al. Expires November 25, 2010 [Page 14]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
5.4.3. Local Mobility Anchor Operation
If the redirection functionality is enabled in the LMA and the
received PBU contains the Redirect-Capability mobility option, then
the rfLMA MAY redirect the MAG to a new r2LMA. In the case of
redirection, the PBA returned to the MAG MUST always include the
unicast IPv6 address of the r2LMA in the Redirect mobility option and
the Status Value set to TBD4 (Rejected_but_Redirected). If the r2LMA
has IPv4 support enabled, then the PBA returned to the MAG SHOULD
include the IPv4 address of the r2LMA in the Redirect mobility
option. If the rfLMA did not redirect the MAG to a new r2LMA or the
redirection failed, then the PBA MUST NOT contain the Redirect
mobility option and the PBA is processed according to RFC 5213.
Korhonen, et al. Expires November 25, 2010 [Page 15]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
6. Multi-Homing Considerations
A MN can be multi-homed. A single LMA entity should have the control
over all possible multi-homed mobility sessions the MN has. All
mobility sessions a multi-homed MN may have SHOULD be anchored in the
single LMA entity. Therefore, once the MN has established one
mobility session with one LMA, the subsequent mobility sessions of
the same MN SHOULD be anchored to the LMA that was initially
assigned.
One possible solution already supported by this specification is
applying the redirection only for the very first initial attach a
multi-homed MN does towards a PMIPv6 domain. After the initial
attach, the assigned r2LMA Address has been stored in the policy
profile. For the subsequent mobility sessions of the multi-homed MN,
the same assigned r2LMA Address would be used and there is no need to
contact the rfLMA.
MAGs have a control over selectively enabling and disabling the
redirection of the LMA. If the multi-homed MN is attached to a
PMIPv6 domain via multiple MAGs, the assigned r2LMA Address should be
stored in the remote policy store and downloaded as a part of the
policy profile download to a MAG. Alternatively, MAGs can share
policy profile information using other means. In both cases, the
actual implementation of the policy profile information sharing is
specific to a PMIPv6 deployment and out of scope of this
specification.
Korhonen, et al. Expires November 25, 2010 [Page 16]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
7. Configuration Variables
This specification defines three configuration variables that control
the redirection functionality within a PMIPv6 domain.
EnableLMARedirectFunction
This configuration variable is available in both a MAG and in a
rfLMA. When set to 1 (i.e., enabled), the PMIPv6 node enables the
redirection functionality. The default value is 0 (i.e.,
disabled).
EnableLMARedirectAcceptFunction
This configuration variable is available in a r2LMA. When set to
1 (i.e., enabled), the r2LMA is able to accept redirected mobility
sessions from a rfLMA. The default value is 0 (i.e., disabled).
Korhonen, et al. Expires November 25, 2010 [Page 17]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
8. Security Considerations
The security considerations of PMIPv6 signaling described in RFC 5213
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.
If the SAs between MAGs and LMAs are manually keyed (as it might be
needed by the 'direct redirection answer' scenario), then the anti-
replay service of ESP protected PMIPv6 traffic cannot typically be
provided. This is, however, deployment specific for a PMIPv6 domain.
If a PMIPv6 domain deployment with a redirection requires that a
rfLMA has to modify a received PBU in any way e.g., by changing the
destination IP address field of the outer IP header, then the
security mechanism (such as possible authentication options) used to
protect the PBU must not cover the outer IP header on those parts
that might get modified. Alternatively, the rfLMA can do all
required security mechanism processing on the received PBU and remove
those security related options from the PBU that would cause the
security check to fail on the r2LMA.
Korhonen, et al. Expires November 25, 2010 [Page 18]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
9. IANA Considerations
Two new mobility options for the use with PMIPv6 are defined in the
[RFC3775] "Mobility Options" registry. The mobility options are
defined in Section 4:
Redirect-Capability Mobility Option is set to TBD1
Redirect Mobility Option is set to TBD2
This document defines the following new Status values for use in PBA
messages. The values are to be allocated from the same number space,
as defined in Section 6.1.8 of [RFC3775].
The value below MUST be less than 128 indicating that the PBU was
accepted by the LMA:
Accepted_and_Redirected_with_Binding is set to TBD3
The value below MUST be greater than 128 indicating that the PBU was
rejected by the LMA:
Rejected_but_Redirected is set to TBD4
Korhonen, et al. Expires November 25, 2010 [Page 19]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
10. Acknowledgements
The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad
Muhanna and Qin Wu for their reviews and comments on this document.
The authors also thank Yungui Wang for his comments and discussion on
this document.
Korhonen, et al. Expires November 25, 2010 [Page 20]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
11. References
11.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.
11.2. Informative References
[I-D.ietf-netlmm-lma-discovery]
Korhonen, J. and V. Devarapalli, "LMA Discovery for Proxy
Mobile IPv6", draft-ietf-netlmm-lma-discovery-03 (work in
progress), February 2010.
[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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
"Mobility Header Home Agent Switch Message", RFC 5142,
January 2008.
[RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
Gateway and Local Mobility Anchor Interaction with
Diameter Server", RFC 5779, February 2010.
Korhonen, et al. Expires November 25, 2010 [Page 21]
Internet-Draft LMA Redirect Support for PMIPv6 May 2010
Authors' Addresses
Jouni Korhonen (editor)
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
Email: jouni.nospam@gmail.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sri.gundavelli@cisco.com
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
Japan
Email: yokota@kddilabs.jp
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Korhonen, et al. Expires November 25, 2010 [Page 22]