One document matched: draft-korhonen-netext-redirect-02.txt
Differences from draft-korhonen-netext-redirect-01.txt
Network Working Group J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track S. Gundavelli
Expires: November 12, 2009 Cisco
H. Yokota
KDDI Lab
May 11, 2009
Runtime LMA Assignment Support for Proxy Mobile IPv6
draft-korhonen-netext-redirect-02.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 November 12, 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.
Korhonen, et al. Expires November 12, 2009 [Page 1]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
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.
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 . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 6
4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 7
5. Redirection Scenarios . . . . . . . . . . . . . . . . . . . . 8
5.1. Proxied Redirection Answer . . . . . . . . . . . . . . . . 8
5.2. Direct Redirection Answer . . . . . . . . . . . . . . . . 9
6. Processing Considerations . . . . . . . . . . . . . . . . . . 10
6.1. Mobile Access Gateway Considerations . . . . . . . . . . . 10
6.2. Local Mobility Anchor Considerations . . . . . . . . . . . 11
7. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12
8. Configuration Variables . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Korhonen, et al. Expires November 12, 2009 [Page 2]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
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 12, 2009 [Page 3]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
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. 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. 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. Although
[RFC4291] now allows using anycast addresses as source addresses,
it does not make much sense using anycast addresses for the MAG to
the LMA communication after the initial PBU/PBA exchange. 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.
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 November 12, 2009 [Page 4]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
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 MAY already be sent to the MAG from this LMA.
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 a unicast IP address. The rfLMA and the r2LMA
MUST have a prior agreement and an established trust relationship to
perform the redirection. The rfLMA MUST NOT redirect the mobility
session to a r2LMA that is not able accept the redirected mobility
session. That is, the redirection functionality in not enabled in
the r2LMA, or the r2LMA is down or otherwise unreachable. How the
rfLMA learns and knows of other r2LMAs where the mobility session can
be redirected to, 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] MAY be
supported but is out of scope of this specification. However, it
should be noted that if anycast addresses are used within the PMIPv6
domain to contact the rfLMA, then manual keying of the SAs may be
required [RFC4303].
During the redirection, the authorization, setting up and the final
anchoring of the mobility session takes place at the r2LMA. After a
successful redirection, the r2LMA is always contacted directly. This
approach supports the attempt of complete bypassing of the rfLMA and
allows implementing rfLMAs without any MN specific state information.
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 using the
Redirection-Capability mobility option. The LMA MUST NOT include the
Korhonen, et al. Expires November 12, 2009 [Page 5]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
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.
4. Mobility Options
The Redirect mobility options allow a LMA to inform a MAG of a
redirection to a new LMA during a PBU/PBA exchange. MAGs and LMAs
that implement the Redirect mobility option MUST support the
redirection functionality during the initial PBU/PBA exchange that
creates a new mobility session. MAGs and LMAs that implement the
Redirect mobility option MAY support the redirection of an
established mobility session.
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. 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 |D| 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 'D' flag: The 'D'irect flag indicates whether a MAG is able to
receive PBAs directly from the r2LMA. The MAG sets the 'D' flag
to 1 (one) if it is able to receive a PBA containing the Redirect
mobility option directly from the r2LMA Address. The MAG sets the
'D' flag to 0 (zero) if it MUST receive a PBA containing the
Redirect mobility option from the rfLMA Address.
Korhonen, et al. Expires November 12, 2009 [Page 6]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
o Reserved: This field is unused. MUST be set 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
mobility session was redirected from the LMA to another. The
Redirect mobility option in the PBA MUST contain the IPv6 addresses
(unicast or anycast) of the rfLMA and the r2LMA. The Redirect
mobility option in the PBA MAY contain the IPv4 addresses of the
rfLMA and the r2LMA.
The Redirect mobility option has the alignment requirement of 4n+2.
There can zero or one Redirect mobility option in the PBA. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 rfLMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 r2LMA Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional IPv4 rfLMA 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 the IPv4 LMA Addresses are included in the
option, the Option Length MUST be set to 40. Otherwise, the
Option Length MUST be set to 32.
Korhonen, et al. Expires November 12, 2009 [Page 7]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
o IPv6 rfLMA Address: the IPv6 address of the rfLMA.
o IPv6 r2LMA Address: the IPv6 address of the r2LMA.
o Optional IPv4 rfLMA Address: the IPv4 address of the rfLMA. This
value is present if the rfLMA IPv4 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.
Note that IPv4 LMA addresses are always used in pairs. The option
cannot include, for example, only the r2LMA IPv4 address or the rfLMA
IPv4 address.
5. Redirection Scenarios
The following sections describe the supported redirection scenarios
that are possible using the redirection functionality defined in this
specification. We describe two different scenarios and discuss
general PMIPv6 domain assumptions.
5.1. Proxied Redirection Answer
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 between the MAG and the r2LMA.
The proxied redirection answer scenario is shown in Figure 1. In
this scenario, the MAG requested proxied redirection answer by
setting the D-flag to 0 in the Redirect-Capability mobility option in
the PBU. Alternatively, this scenario also applies when the 'LMA'
(consisting of the rfLMA and the r2LMA) does not support returning a
PBA directly from the r2LMA even if the MAG indicated a support for
it.
The proxied redirection answer scenario has several benefits:
o Easier deployment with IPsec. The security model including
possible dynamic negotiation of the MAG-LMA Security Association
(SA) is completely align with the PMIPv6 base protocol as defined
in [RFC5213].
o Easier deployment with firewalls. As the PBA is always returned
from the same LMA Address where the PBU was sent to (even in case
of anycast LMA Address), stateful firewall rules can still be used
for PBU/PBA traffic.
Korhonen, et al. Expires November 12, 2009 [Page 8]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
MAG rfLMA r2LMA
| | |
|--PBU-->|--PBU-->| (redirection takes place,
|<--PBA--|<--PBA--| PBA contains rfLMA & r2LMA
| | | information)
| | |
|<=====data======>|
| | |
|-------PBU------>| (lifetime extension,
|<------PBA-------| de-registration, etc.)
Figure 1: A MAG sets D-flag to 0, or a 'LMA' does not support D-flag
set to 1 functionality
5.2. Direct Redirection Answer
During the redirection the PBA is returned directly from the
redirected to LMA Address i.e., from the r2LMA. After the
redirection all PMIPv6 communication continues between the MAG and
the r2LMA.
The direct redirection answer scenario is shown in Figure 2. In this
scenario, the MAG indicates a support for direct redirection answer
by setting the D-flag to 1 in the Redirect-Capability mobility option
in the PBU. The 'LMA' (consisting of the rfLMA and the r2LMA) also
has a support for returning a PBA directly from the r2LMA.
The direct redirection scenario 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.
The direct redirection answer scenario has the following benefits:
o In a load balancing case (where the rfLMA acts as a load
balancer), the direct answer scenario allows complete bypassing of
the load balancer after the redirection decision, including the
response traffic during the redirection. The load balancer can
also be made completely stateless. This is especially valuable
when the rfLMA and the r2LMA are separate physical entities.
o For anycast traffic the answer (i.e., the PBA) can already be sent
from the real unicast LMA Address (i.e., the r2LMA Address).
The direct redirection answer scenario has the following deployment
related concerns:
Korhonen, et al. Expires November 12, 2009 [Page 9]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
o Deployment of stateful firewalls within a PMIPv6 domain becomes a
challenge as responses arrive from a different address than where
requests were sent to.
o Synchronizing PBU/PBA Sequence Numbers become more complicated.
The sequence are matched between the MAG-LMA pairs, so there is no
"pending" request for the PBA coming from the r2LMA. Using a
timestamp-based solution instead of sequence numbers is an easy
solution for message ordering. Alternatively, on the MAG side the
PBU/PBA matching MUST be based on the rfLMA address included in
the Redirect mobility option instead of the IP address where the
PBA came from.
MAG rfLMA r2LMA
| | |
|--PBU-->|--PBU-->| (redirection takes place,
|<-----------PBA--| PBA contains rfLMA & r2LMA
| | | information)
| | |
|<=====data======>|
| | |
|-------PBU------>| (lifetime extension,
|<------PBA-------| de-registration, etc.)
Figure 2: A MAG sets D-flag to 1 and a 'LMA' supports D-flag set to 1
functionality
6. Processing Considerations
6.1. Mobile Access Gateway Considerations
If the redirection functionality is enabled, then the MAG MAY include
the Redirect-Capability mobility option in any PBU. The Redirect-
Capability mobility option in the PBU is also an indication to a LMA
that the MAG supports the redirection functionality. The redirection
concerns always one mobility session at time.
If the "direct redirection answer" functionality is enabled, then the
MAG sets the D-flag to 1 in the Redirect-Capability mobility option.
Otherwise, the MAG sets the D-flag to 0 in the Redirect-Capability
mobility option.
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. If the MAG receives a PBA
Korhonen, et al. Expires November 12, 2009 [Page 10]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
that contains the Redirect mobility option 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 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
Address field). If the check fails, then the MAG MUST treat the
PBA as if the binding update failed and log the event.
o Perform the PBU and the PBA matching using the rfLMA Address field
from the Redirect mobility option. This applies especially to the
case where the MAG supports the "direct redirection answer"
scenario.
If the redirection was successful, the MAG updates the Binding Update
List to correspond to 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. The MAG MUST send subsequent
binding refreshing PBUs and user traffic to the new r2LMA Address.
If the MAG includes the Redirect-Capability mobility option in
subsequent PBUs, the LMA MAY redirect the MAG again.
6.2. Local Mobility Anchor Considerations
The text in this section 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 not enabled in a LMA, then the
LMA MUST ignore the Redirect-Capability mobility option received in
PBUs. 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 r2LMA MUST always include the IPv6 address (unicast
or anycast) of the rfLMA and the IPv6 address (unicast) of the r2LMA
in the Redirect mobility option in the PBA. If the LMA has IPv4
support enabled, then the r2LMA MUST include the IPv4 address of the
rfLMA and the r2LMA in the Redirect mobility option.
If the received PBU contains the Redirect-Capability mobility option
with D-flag set to 1, the LMA MAY return the PBA directly from the
r2LMA Address. Otherwise, if the D-flag is set to 0 or the LMA does
not support the 'direct redirection answer' scenario, the PBA MUST be
returned from the rfLMA Address.
Korhonen, et al. Expires November 12, 2009 [Page 11]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
The rfLMA MUST only redirect the MAG to a new r2LMA that it knows the
MAG has a SA with. 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 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 PMIPv6 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.
If the redirection was successful, the mobility session is
established in the r2LMA. The actual PBU processing takes place in
the r2LMA. However, depending on the LMA's implementation of the
PMIPv6 security framework, the IPsec processing of the PBU may take
place in the rfLMA before the PBU is forwarded to the r2LMA.
7. 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
Korhonen, et al. Expires November 12, 2009 [Page 12]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
specific to a PMIPv6 deployment and out of scope of this
specification.
8. 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).
EnableDirectLMARedirectionFunction
This configuration variable is available in both a MAG and in a
r2LMA. When set to 1 (i.e., enabled), the r2LMA can return a PBA
directly using its own unicast LMA Address after a successful
redirection. The default value is 0 (i.e., disabled).
9. 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.
Korhonen, et al. Expires November 12, 2009 [Page 13]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
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.
10. 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
11. Acknowledgements
The author would like to thank Basavaraj Patil and Domagoj Premec for
their reviews and comments on the initial versions of this document.
12. References
12.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.
12.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.
Korhonen, et al. Expires November 12, 2009 [Page 14]
Internet-Draft LMA Redirect Support for PMIPv6 May 2009
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[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.
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
Korhonen, et al. Expires November 12, 2009 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 07:36:26 |