Network Working Group J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track S. Gundavelli
Expires: December 31, 2011 Cisco
H. Yokota
KDDI Lab
X. Cui
Huawei Technologies
June 29, 2011
Runtime LMA Assignment Support for Proxy Mobile IPv6
draft-ietf-netext-redirect-08.txt
Abstract
This document describes a runtime Local Mobility Anchor assignment
functionality and corresponding mobility options for Proxy Mobile
IPv6.
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 December 31, 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
Korhonen, et al. Expires December 31, 2011 [Page 1]
Internet-Draft Runtime LMA Assignment June 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 5
4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 5
4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 6
5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 7
5.1. General Operation . . . . . . . . . . . . . . . . . . . . 7
5.2. Mobile Access Gateway Operation . . . . . . . . . . . . . 8
5.3. Local Mobility Anchor Operation . . . . . . . . . . . . . 9
5.3.1. Collocated rfLMA and r2LMA Functions . . . . . . . . . 10
5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) . . . . 11
6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12
7. Configuration Objects . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Korhonen, et al. Expires December 31, 2011 [Page 2]
Internet-Draft Runtime LMA Assignment June 2011
1. Introduction
This specification describes a runtime assignment of a Local Mobility
Anchor (LMA) for Proxy Mobile IPv6 (PMIPv6) [RFC5213] protocol. The
runtime LMA assignment takes place during a Proxy Binding Update
(PBU) and a Proxy Binding Acknowledgement (PBA) message exchange
between a Mobile Access Gateway (MAG) and a LMA. The runtime LMA
assignment functionality defined in this specification can be used,
for example, for load balancing purposes. MAGs and LMAs can also
implement other load balancing mechanisms that are completely
transparent at PMIPv6 protocol level and do not depend on the
functionality defined in this specification.
The runtime LMA assignment functionality does not depend on 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 LMA assignment is a
useful addition to the PMIPv6 protocol. Few identified ones are
listed below:
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 runtime
assignment 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
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 Mobile Node (MN) specific state information.
Korhonen, et al. Expires December 31, 2011 [Page 3]
Internet-Draft Runtime LMA Assignment June 2011
o Independence from DNS: DNS-based load balancing is a common
practice. However, keeping MAGs up-to-date with LMA load status
using DNS is hard e.g., due to caching and unpredictable zone
update delays [RFC6097]. 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 with
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 have an unique unicast IP address for
each blade and a single anycast address for all blades. 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 runtime assigned LMA blade through the
initial PBU/PBA exchange, the subsequent communication continues
using the unicast address.
As a summary, the DNS/AAA based approaches cannot be used to select
an "appropriate" LMA at runtime. Therefore, this specification
defines a solution that is applicable for blade/cluster LMA
implementations where the IP address known to the MAG is not the best
LMA of choice at runtime.
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:
Korhonen, et al. Expires December 31, 2011 [Page 4]
Internet-Draft Runtime LMA Assignment June 2011
rfLMA
An LMA which receives a PBU from a MAG and decides to assign an IP
mobility session with a new target LMA (r2LMA).
r2LMA
The LMA assigned to a MAG as a result of the runtime LMA
assignment.
Runtime Assignment Domain
A group of LMAs that consist of at least one rfLMA and one or more
r2LMAs. A rfLMA is allowed to assign MAGs only with r2LMAs that
belong to the same runtime assignment domain. The rfLMA and one
or more r2LMAs may consist of multiple blades in a single network
element, multiple physical network elements, or multiple LMAs
distributed geographically.
3. Proxy Mobile IPv6 Domain Assumptions
The runtime LMA assignment functionality has few assumptions within
the PMIPv6 domain.
Each LMA in a runtime assignment domain MUST be reachable at an
unicast IP address. The rfLMA and the r2LMA MUST have a prior
agreement, adequate means to secure their inter-LMA communication and
an established trust relationship to perform the runtime LMA
assignment.
Each LMA and MAG participating in the runtime LMA assignment is
assumed to have required Security Associations (SA) already set up in
advance. Dynamic negotiation of the SAs using e.g., IKEv2 [RFC5996]
SHOULD be supported but is out of scope of this specification.
4. Mobility Options
4.1. Redirect-Capability Mobility Option
The Redirect-Capability mobility option has the alignment requirement
of 4n. There can be zero or one Redirect-Capability mobility option
in the PBU. The format of the Redirect-Capability mobility option is
shown below:
Korhonen, et al. Expires December 31, 2011 [Page 5]
Internet-Draft Runtime LMA Assignment June 2011
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 | 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 Reserved: This field is reserved for future use. MUST be set to
zero by the sender and ignored by the receiver.
4.2. Redirect Mobility Option
The Redirect mobility option in the PBA MUST contain an unicast
address of the r2LMA and the address family MUST be the same as the
currently used transport between the MAG and the rfLMA. There can
zero or one Redirect mobility option in the PBA. The Redirect
mobility option has the alignment requirement of 4n. 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
Korhonen, et al. Expires December 31, 2011 [Page 6]
Internet-Draft Runtime LMA Assignment June 2011
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. Both 'K' and 'N' flags cannot be set or unset
simultaneously.
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 by the sender and ignored by the receiver.
o Optional IPv6 r2LMA Address: the unicast IPv6 address of the
r2LMA. This value is present when the r2LMA IPv6 address is
included and the corresponding PBU was received over IPv6
transport.
o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This
value is present when the r2LMA IPv4 address is included and the
corresponding PBU was received over IPv4 transport.
5. Runtime LMA Assignment
5.1. General Operation
During the runtime LMA assignment, the PBA is returned from the LMA
Address to which the PBU was sent to i.e., from the rfLMA address.
After the runtime LMA assignment all PMIPv6 communication continues
directly between the MAG and the r2LMA bypassing the rfLMA. The
overall runtime LMA assignment flow sequence is shown in Figure 1.
Korhonen, et al. Expires December 31, 2011 [Page 7]
Internet-Draft Runtime LMA Assignment June 2011
MAG rfLMA r2LMA
| | |
1) |--PBU---+ ~ ~ ~ >| (LMA assignment takes place, BCE gets created
2) |<--PBA--+ ~ ~ ~ ~| in 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 runtime assignment 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. 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. This
specification describes two:
o Collocated rfLMA & r2LMA functions, where the 'rfLMA side of the
LMA' is reachable via an anycast address or the loopback address
of the LMA. See Section 5.3.1 for further details.
o Separate rfLMA & r2LMA functions, where the rfLMA acts as a non-
transparent 'proxy-MAG' to a r2LMA. See Section 5.3.2 for further
details.
There are other possible implementations of the rfLMA and the r2LMA.
At the end, as long as the protocol between the MAG and the rfLMA
follows this specification , the collocation or inter-communication
properties of the rfLMA and the r2LMA do not matter.
5.2. Mobile Access Gateway Operation
In the base PMIPv6 protocol [RFC5213] a MAG sends a PBU to an LMA,
which results in a Binding Cache Entry (BCE) creation at the LMA and
the LMA sending a PBA sent back to the MAG. The MAG in turn creates
a corresponding Binding Update List Entry (BULE). This specification
extends the base protocol with the runtime LMA assignment
functionality.
If the MAG supports the runtime LMA assignment and the functionality
is also enabled (see EnableLMARedirectFunction configuration object
in Section 7), then the MAG includes the Redirect-Capability mobility
option in a PBU that establishes a new mobility session (i.e.
Korhonen, et al. Expires December 31, 2011 [Page 8]
Internet-Draft Runtime LMA Assignment June 2011
Handoff Indicator Option in the PBU has the value of 1). The
Redirect-Capability mobility option in the PBU is also an indication
to an LMA that the MAG supports the runtime LMA assignment
functionality and is prepared to be assigned with a different LMA.
The runtime LMA assignment concerns always one mobility session at a
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 process the PBA as described
in RFC 5213.
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 The MAG updates its BULE to contain the r2LMA address included in
the received Redirect mobility option.
o If there is no SA between the MAG and the r2LMA, the MAG SHOULD
initiate the dynamic creation of the SA between the MAG and the
r2LMA as described in Section 4 of RFC 5213. If the dynamic SA
creation fails, the MAG SHOULD log the event.
There is no need to resend a PBU to the r2LMA after a successful
runtime assignment. The mobility session has already been
established in the r2LMA as indicated by the Status Value TBD3
(Accepted_and_Redirected_with_Binding). The MAG MUST send subsequent
binding refreshing PBUs and user traffic to the new r2LMA address.
5.3. Local Mobility Anchor Operation
The text in the following sections refers to an 'LMA' when it means
the combination of the rfLMA and the r2LMA i.e., the entity where
runtime LMA assignment is possible. When the text points to a
specific LMA role during the runtime assignment, it uses either the
'rfLMA' or the 'r2LMA'.
If the runtime assignment functionality is enabled (see
EnableLMARedirectFunction configuration object in Section 7) in the
rfLMA but the LMA assignment is not going to take place for some
reason, and the rfLMA is not willing to serve (or capable of) as a
normal RFC 5213 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. If the rfLMA is able to make the assignment
Korhonen, et al. Expires December 31, 2011 [Page 9]
Internet-Draft Runtime LMA Assignment June 2011
to an r2LMA, it returns a PBA with the Redirect mobility option as
defined below. Otherwise, the rfLMA MUST act as a normal RFC 5213
defined LMA for the MAG.
The rfLMA MUST only assign the MAG to a new r2LMA with which it knows
the MAG has an SA or with which it knows the MAG can establish an SA
dynamically. The rfLMA MUST NOT assign the MAG with a r2LMA that the
rfLMA and the r2LMA do not have a prior agreement and an established
trust relationship for the runtime LMA assignment. These SA related
knowledge issues and trust relationships are deployment specific in a
PMIPv6 domain and in a runtime assignment 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 runtime assignment domain. The rfLMA MUST NOT
change the used transport IP address family during the runtime LMA
assignment.
As a result of a successful runtime LMA assignment, the PBA MUST
contain the Redirect mobility option with a valid r2LMA unicast
address and the PBA Status Value indicating success.
Next we describe two deployment and implementation models for the
runtime LMA assignment. In Section 5.3.1, we describe a model where
the rfLMA and r2LMA are collocated. In Section 5.3.2 we describe a
model where rfLMA acts as a non-transparent 'proxy MAG', and where
the rfLMA and the r2LMA are separate. There can be even more
implementation options depending on the rfLMA and the r2LMA
collocation properties, and how the inter-LMA communication is
arranged.
5.3.1. Collocated rfLMA and r2LMA Functions
In this solution approach the rfLMA and the r2LMA are part of the
same 'collocated LMA', and may even be using to the same physical
network interface. The rfLMA is reachable via an anycast or a
loopback address of the LMA. Each r2LMA is reachable via its unicast
address. The MAG-LMA SA is between the MAG and the rfLMA (i.e. the
anycast or the loopback address of the LMA). How this SA has been
set up is out of scope of this specification but a manual SA
configuration is one possibility.
The rfLMA becomes active when the runtime LMA assignment
functionality is enabled (see EnableLMARedirectFunction configuration
object in Section 7). When the rfLMA receives a PBU destined to it,
and the PBU contains the Redirect-Capability mobility option, then
the 'collocated LMA' MUST create a mobility session in a r2LMA role
using the procedures described in RFC 5213. If there in no existing
tunnel between the MAG and the r2LMA unicast address, then the r2LMA
Korhonen, et al. Expires December 31, 2011 [Page 10]
Internet-Draft Runtime LMA Assignment June 2011
creates one as described in Section 6.9.1 of [RFC5213]. The r2LMA
used for accepting and anchoring the mobility session MUST also have
the runtime LMA assignment functionality enabled (see
EnableLMARedirectAcceptFunction configuration object in Section 7).
If the mobility session creation succeeded, then 'collocated LMA' in
the rfLMA role sends a PBA to the MAG. The PBA is sourced using the
rfLMA address. The PBA MUST contain the r2LMA unicast address (IPv6
or IPv4) in the Redirect mobility option and the Status Value set to
TBD3 (Accepted_and_Redirected_with_Binding).
If the PBU is received on the r2LMA unicast address, then the PBU is
processed as described in RFC 5213 and the response PBA MUST NOT
contain the Redirect mobility option.
If the PBU is received on the rfLMA address and there is no Redirect-
Capability mobility option in the PBU, then the 'collocated LMA' MUST
reject the PBU and send back a PBA in a rfLMA role with Status Value
set to 130 (Insufficient resources) error code (as mentioned in
Section 5.3).
5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG)
In this solution approach the rfLMA and the r2LMA are two isolated
functions, and may even be physically separate networking nodes. The
r2LMA can be any RFC 5213 compliant LMA without any knowledge of this
specification.
The rfLMA is actually a non-transparent 'proxy-MAG' (see [RFC2616]
for a generic definition of a non-transparent proxy, although for
HTTP, but the idea also applies here) which shows up as an LMA
implementing this specification towards the MAG, and as a base RFC
5213 compliant MAG to the r2LMA. This type of operation is also
referred as 'chaining' in other contexts. The protocol between the
'proxy-MAG' and the r2LMA is the base RFC 5213 PMIPv6 protocol.
The MAG-LMA SA is between the MAG and the rfLMA, and RFC 5213 SA
considerations apply fully. The MAG has no knowledge of the 'proxy-
MAG'-r2LMA SA. RFC 5213 considerations regarding the SA between the
'proxy-MAG' and the r2LMA apply fully. It is also possible that
'proxy-MAG'-r2LMA security is arranged using other means than IPsec,
for example using layer-2 VPNs.
When the rfLMA receives a PBU, and the PBU contains the Redirect-
Capability mobility option, then the rfLMA in a 'proxy-MAG' role:
o Processes the PBU using the procedures described in RFC 5213
except that no mobility session gets created. Instead the rfLMA
Korhonen, et al. Expires December 31, 2011 [Page 11]
Internet-Draft Runtime LMA Assignment June 2011
creates a proxy state based on the received PBU,
o Assigns a r2LMA to the MAG,
o Creates a new PBU', which includes all non-security related
mobility options from the original PBU and the Alternate Care-of
Address option containing the address of the original MAG,
o Sends the new PBU' sourced from its 'proxy-MAG' address to the
r2LMA using the procedures described in RFC 5213.
The r2LMA processed the received PBU' using the procedures described
in RFC 5213.
Once the rfLMA in a 'proxy-MAG' role receives a reply PBA' from the
r2LMA and the mobility session creation succeeded in the r2LMA, the
rfLMA sends a PBA to the MAG. The PBA is sourced using the rfLMA
address. The PBA MUST contain the r2LMA unicast address (IPv6 or
IPv4) in the Redirect mobility option and the Status Value set to
TBD3 (Accepted_and_Redirected_with_Binding). Note that the Status
Value received from PBA' gets replaced by the rfLMA.
If the PBA' indicates that the mobility session creation failed in
the r2LMA, then the rfLMA MUST set the Status Value in the PBA as
received from the PBA' Status Value.
Once the rfLMA has sent the reply PBA to the MAG, it can remove the
proxy state. Subsequent traffic between the MAG and the r2LMA will
bypass the rfLMA.
If the rfLMA receives a PBU with no Redirect-Capability mobility
option in the PBU, then the PBU is processed as described in
Section 5.3), i.e. the rfLMA may or may not act as a RFC 5213 LMA to
the MAG.
6. Multi-Homing Considerations
A MN can be multi-homed i.e. have network connectivity over multiple
interfaces connected one or more accesses. A single LMA entity
SHOULD have the control over all possible multi-homed mobility
sessions the MN has or otherwise handovers between different accesses
and interfaces become challenged, if not impossible. 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
Korhonen, et al. Expires December 31, 2011 [Page 12]
Internet-Draft Runtime LMA Assignment June 2011
applying the runtime LMA assignment 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. Discovering the same r2LMA each time
has an assumption that the MN has an identity that can always point
to the same policy profile independent of the used access.
MAGs have a control over selectively enabling and disabling the
runtime assignment 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.
7. Configuration Objects
This specification defines two configuration objects that control the
runtime LMA assignment functionality within a PMIPv6 domain.
EnableLMARedirectFunction
This configuration object is available in both a MAG and in a
rfLMA. When set to TRUE (i.e., enabled), the PMIPv6 node enables
the runtime LMA assignment functionality. The default value is
FALSE (i.e., disabled).
EnableLMARedirectAcceptFunction
This configuration object is available in a r2LMA. When set to
TRUE (i.e., enabled), the r2LMA is able to accept runtime LMA
assignment mobility sessions from a rfLMA. The default value is
FALSE (i.e., disabled).
8. Security Considerations
The security considerations of PMIPv6 signaling described in RFC 5213
apply to this document. An incorrectly configured LMA may cause
unwanted runtime LMA assignment attempts to non-existing LMAs or to
other LMAs that do not have and will not have a SA with the MAG.
Consequently, the MAG will experience failed binding updates or
unsuccessful creation of mobility sessions. An incorrectly
Korhonen, et al. Expires December 31, 2011 [Page 13]
Internet-Draft Runtime LMA Assignment June 2011
configured LMA may also cause biased load distribution within a
PMIPv6 domain. This document also assumes that the LMAs that
participate to runtime LMA assignment have adequate prior agreement
and trust relationship between each other.
If the SAs between MAGs and LMAs are manually keyed (as it may be
needed by the scenario described in Section 5), then the anti-replay
service of ESP protected PMIPv6 traffic cannot typically be provided.
This is, however, deployment specific to a PMIPv6 domain.
If a PMIPv6 domain deployment with a runtime LMA assignment requires
that a rfLMA has to modify a PBU/PBA in any way e.g., by changing the
source and destination IP address or any other field of the
encapsulating IP packet, then the security mechanism (such as
possible authentication options) used to protect the PBU/PBA MUST NOT
cover the outer IP packet on those parts that might get modified.
Alternatively, the rfLMA can do all required security processing on
the PBU/PBA, and the communication between the rfLMA and the r2LMA
would be unprotected at the PMIPv6 protocol level. In this case the
runtime assignment domain MUST implement adequate level of security
using other means, such as layer-2 VPNs.
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
10. Acknowledgements
The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad
Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang and Qin Wu for
their discussion on this document.
Korhonen, et al. Expires December 31, 2011 [Page 14]
Internet-Draft Runtime LMA Assignment June 2011
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
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[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.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor
(LMA) Discovery for Proxy Mobile IPv6", RFC 6097,
February 2011.
Korhonen, et al. Expires December 31, 2011 [Page 15]
Internet-Draft Runtime LMA Assignment June 2011
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 December 31, 2011 [Page 16]