Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6
Ways for a Proxy Mobile IPv6 gateway to find the right mobility anchor automatically instead of by static configuration.
Korhonen, J. and V. Devarapalli, "Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, DOI 10.17487/RFC6097, February 2011, <https://www.rfc-editor.org/info/rfc6097>.
@misc{rfc6097,
series = {Request for Comments},
number = 6097,
howpublished = {RFC 6097},
publisher = {RFC Editor},
doi = {10.17487/RFC6097},
url = {https://www.rfc-editor.org/info/rfc6097},
author = {J. Korhonen and V. Devarapalli},
title = {{Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6}},
pagetotal = 10,
year = 2011,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Korhonen
Request for Comments: 6097 Nokia Siemens Networks
Category: Informational V. Devarapalli
ISSN: 2070-1721 Vasona Networks
February 2011
Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6
Abstract
Large Proxy Mobile IPv6 deployments would benefit from a
functionality where a Mobile Access Gateway could dynamically
discover a Local Mobility Anchor for a Mobile Node attaching to a
Proxy Mobile IPv6 domain. The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the
Mobile Access Gateway. This document describes several possible
dynamic Local Mobility Anchor discovery solutions.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6097.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. AAA-Based Discovery Solutions ...................................3
2.1. Receiving the LMA Address during Network Access
Authentication .............................................4
2.2. Receiving the LMA FQDN during Network Access
Authentication .............................................4
3. Discovery Solutions Based on Data from Lower Layers .............5
3.1. Constructing the LMA FQDN from a Mobile Node Identity ......5
3.2. Receiving the LMA FQDN or IP Address from Lower Layers .....5
3.3. Constructing the LMA FQDN from a Service Name ..............6
4. Handover Considerations .........................................6
5. Recommendations .................................................7
6. Security Considerations .........................................8
7. Acknowledgements ................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
1. Introduction
A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from
a functionality where a Mobile Access Gateway (MAG) can dynamically
discover a Local Mobility Anchor (LMA) for a Mobile Node (MN)
attaching to a PMIPv6 domain. The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the
MAG. Other drivers for the dynamic discovery of an LMA include LMA
load balancing solutions and selecting an LMA based on desired
services (i.e., allowing service-specific routing of traffic)
[RFC5149]. This document describes several possible dynamic LMA
discovery approaches and makes a recommendation of the preferred one.
The following list briefly introduces solution approaches that will
be discussed in this document. The approaches discussed do not
include all possible discovery mechanisms, but are limited to those
considered to fit most simply into the PMIPv6 environment.
o LMA Address is retrieved from the Authentication, Authorization,
and Accounting (AAA) infrastructure during the network access
authentication procedure when the MN attaches to the MAG.
o LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA
infrastructure during the network access authentication, followed
by a Domain Name System (DNS) lookup.
o LMA FQDN is derived from the MN identity received from the lower
layers during the network attachment, followed by a DNS lookup.
o LMA FQDN or IP address is received from the lower layers during
the network attachment. The reception of an FQDN from the lower
layers is followed by a DNS lookup.
o LMA FQDN is derived from the service selection indication received
from lower layers during the network attachment, followed by a DNS
lookup.
When an MN performs a handover from one MAG to another, the new MAG
must use the same LMA that the old MAG was using. This is required
for session continuity. The LMA discovery mechanism in the new MAG
should be able to return the information of the same LMA that was
being used by the old MAG. This document also discusses solutions
for LMA discovery during a handover.
2. AAA-Based Discovery Solutions
This section presents an LMA discovery solution that requires a MAG
to be connected to an AAA infrastructure (as described in [RFC5779],
for instance). The AAA infrastructure is also assumed to be aware of
PMIPv6. An MN attaching to a PMIPv6 domain is typically required to
provide authentication for network access and to be authorized for
mobility services before the MN is allowed to send or receive any IP
packets or even complete its IP level configuration.
The AAA-based LMA discovery solution hooks into the network access
authentication and authorization process. The MAG also has the role
of a Network Access Server (NAS) at this step. While the MN is
attaching to the network, the PMIPv6-related parameters are
bootstrapped in parallel with authentication for the network access
and authorization for the mobility services. The bootstrapping of
PMIPv6 parameters involves the policy profile download over the AAA
infrastructure to the MAG (see Appendix A of [RFC5213]).
2.1. Receiving the LMA Address during Network Access Authentication
After the MN has been successfully authenticated for network access
and authorized for the mobility service, the MAG receives the LMA IP
address from the AAA server over the AAA infrastructure. The LMA IP
address information would be part of the AAA message that ends the
successful authentication and authorization portion of the AAA
exchange.
Once the MAG receives the LMA IP address, it sends a Proxy Binding
Update (PBU) message for the newly authenticated and authorized MN.
The MAG expects that the LMA returned by the AAA server is able to
provide mobility session continuity for the MN, i.e., after a
handover, the LMA would be the same one the MN already has a mobility
session set up with.
2.2. Receiving the LMA FQDN during Network Access Authentication
This solution is similar to the procedure described in Section 2.1.
The difference is that the MAG receives an FQDN of the LMA instead of
the IP address(es). The MAG has to query the DNS infrastructure in
order to resolve the FQDN to the LMA IP address(es).
The LMA FQDN might be a generic name for a PMIPv6 domain that
resolves to one or more LMAs in the PMIPv6 domain. Alternatively,
the LMA FQDN might be resolved to exactly one LMA within the PMIPv6
domain. The latter approach would obviously be useful if a new
target MAG, after a handover, resolved the LMA FQDN to the LMA IP
address where the MN mobility session is already located.
The procedures described in this section and in Section 2.1 may also
be used together. For example, the AAA server might return a generic
LMA FQDN during the MN's initial attachment, and once the LMA gets
selected, return the LMA IP address during the subsequent attachments
to other MAGs in the PMIPv6 domain. In order for this to work, the
resolved and selected LMA IP address must be updated to the remote
policy store. For example, the LMA could perform the policy store
update using the AAA infrastructure once it receives the initial PBU
from the MAG for the new mobility session.
3. Discovery Solutions Based on Data from Lower Layers
The following section discusses solutions where a MAG acquires
information from layers below the IP layer. Based on this
information, the MAG is able to determine which LMA to contact when
the MN attaches to the MAG. The lower layers discussed here are not
explicitly defined but include different radio access technologies
and tunneling solutions such as an Internet Key Exchange version 2
(IKEv2) [RFC5996] IPsec tunnel [RFC4303].
3.1. Constructing the LMA FQDN from a Mobile Node Identity
A MAG acquires an MN identity from lower layers. The MAG can use the
information embedded in the identity to construct a generic LMA FQDN
(based on some pre-configured formatting rules) and then proceed to
resolve the LMA IP address(es) using the DNS. Obviously, the MN
identity must embed information that can be used to uniquely identify
the entity hosting and operating the LMA for the MN. Examples of
such MN identities are the International Mobile Subscriber Identity
(IMSI) and the Globally Unique Temporary User Equipment Identity
(GUTI) [3GPP.23.003]. These MN identities contain information that
can uniquely identify the operator to whom the subscription belongs.
3.2. Receiving the LMA FQDN or IP Address from Lower Layers
The solution described here is similar to the solution discussed in
Section 3.1. A MAG receives an LMA FQDN or an IP address from lower
layers, for example, as a part of the normal lower-layer signaling
when the MN attaches to the network. IKEv2 could be an existing
example of such lower-layer signaling where IPsec is the "lower
layer" for the MN [3GPP.24.302]. IKEv2 has an IKEv2
Identification - Responder (IDr) payload, which is used by the IKEv2
initiator (i.e., the MN in this case) to specify which of the
responder's identities (i.e., the LMA in this case) it wants to talk
to. And here the responder identity could be an FQDN or an IP
address of the LMA (as the IKEv2 identification payload can be an IP
address or an FQDN). Another existing example is the Access Point
Name Information Element (APN IE) [3GPP.24.008] used in 3GPP radio
network access signaling and capable of carrying an FQDN. However,
in general, this means the MN is also the originator of the LMA
information. The LMA information content as such can be transparent
to the MN, meaning the MN does not associate the information with any
LMA function.
3.3. Constructing the LMA FQDN from a Service Name
Some network access technologies (including tunneling solutions)
allow the MN to signal the service name that identifies a particular
service or the external network it wants to access [3GPP.24.302]
[RFC5996]. If the MN-originated service name also embeds the
information of the entity hosting the service, or the hosting
information can be derived from other information available at the
same time (e.g., see Section 3.1), then the MAG can construct a
generic LMA FQDN (e.g., based on some pre-defined formatting rules)
providing an access to the service or the external network. The
pre-defined formatting rules [3GPP.23.003] are usually agreed on
among operators that belong to the same inter-operator roaming
consortium or by network infrastructure vendors defining an open
networking system architecture.
Once the MAG has the FQDN, it can proceed to resolve the LMA IP
address(es) using the DNS. An example of such a service or external
network name is the Access Point Name (APN) [3GPP.23.003] that
contains the information of the operator providing the access to the
given service or the external network. For example, an FQDN for an
"ims" APN could be "ims.apn.epc.mnc015.mcc234.3gppnetwork.org".
4. Handover Considerations
Whenever an MN moves and attaches to a new MAG in a PMIPv6 domain,
all the MAGs that the MN attaches to should use the same LMA. If
there is only one LMA per PMIPv6 domain, then there is no issue. If
there is a context transfer mechanism available between the MAGs,
then the new MAG knows the LMA information from the old MAG. Such a
mechanism is described in [RFC5949]. If the MN-related context is
not transferred between the MAGs, then a mechanism to deliver the
current LMA information to the new MAG is required.
Relying on DNS during handovers is not generally a working solution
if the PMIPv6 domain has more than one LMA, unless the DNS
consistently assigns a specific LMA for each given MN. In most cases
described in Section 3, where the MAG derives the LMA FQDN, there is
no prior knowledge whether the LMA FQDN resolves to one or more LMA
IP address(es) in the PMIPv6 domain. However, depending on the
deployment and deployment-related regulations (such as inter-operator
roaming consortium agreements), the situation might not be this
desperate. For example, a MAG might be able to synthesize an
LMA-specific FQDN (e.g., out of an MN identity or some other
service-specific parameters). Alternatively, the MAG could use (for
example), an MN identity as an input to an algorithm that
deterministically assigns the same LMA out of a pool of LMAs
(assuming the MAG has, e.g., learned a group of LMA FQDNs via an SRV
[RFC2782] query). These approaches would guarantee that DNS always
returns the same LMA Address to the MAG.
Once the MN completes its initial attachment to a PMIPv6 domain, the
information about the LMA that is selected to serve the MN is stored
in the policy store (or the AAA server). The LMA information is
conveyed to the policy store by the LMA after the initial attachment
is completed [RFC5779]. Typically, AAA infrastructure is used for
exchanging information between the LMA and the policy store.
When the MN moves and attaches to another MAG in the PMIPv6 domain,
then the AAA server delivers the existing LMA information to the new
MAG as part of the authentication and authorization procedure as
described in Section 2.1.
5. Recommendations
This document discussed several solution approaches for a dynamic LMA
discovery. All discussed solution approaches actually require
additional functionality or infrastructure support that the base
PMIPv6 specification [RFC5213] does not require.
Solutions in Section 3 all depend on lower layers being able to
provide information that a MAG can then use to query the DNS and
discover a suitable LMA. The capabilities of the lower layers and
the interactions with them are generally out of scope of the IETF,
and specific to a certain system and architecture.
Solutions in Section 2 depend on the existence of an AAA
infrastructure, which is able to provide to a MAG either an LMA IP
address or an LMA FQDN. While there can be system- and architecture-
specific details regarding the AAA interactions and the use of DNS,
the dynamic LMA discovery can be implemented in an access- and
technology-agnostic manner, and work in the same way across
heterogeneous environments. Therefore, using AAA-based LMA discovery
solutions is recommended by this document. Furthermore, following
the guidance in Section 4, Paragraph 4.1 of [RFC1958], the use of
FQDNs should be preferred over IP addresses in the context of
AAA-based LMA discovery solutions.
6. Security Considerations
The use of DNS for obtaining the IP address of a mobility agent
carries certain security risks. These are explained in detail in
Section 9.1 of [RFC5026]. However, the risks described in [RFC5026]
are mitigated to a large extent in this document, since the MAG and
the LMA belong to the same PMIPv6 domain. The DNS server that the
MAG queries is also part of the same PMIPv6 domain. Even if the MAG
obtains the IP address of a bogus LMA from a bogus DNS server,
further harm is prevented since the MAG and the LMA should
authenticate each other before exchanging PMIPv6 signaling messages.
[RFC5213] specifies the use of IKEv2 between the MAG and the LMA to
authenticate each other and set up IPsec security associations for
protecting the PMIPv6 signaling messages.
The AAA infrastructure may be used to transport the LMA-discovery-
related information between the MAG and the AAA server via one or
more AAA brokers and/or AAA proxies. In this case, the MAG-to-AAA-
server communication relies on the security properties of the
intermediate AAA brokers and AAA proxies.
7. Acknowledgements
The authors would like to thank Julien Laganier, Christian Vogt,
Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu,
Jari Arkko, and Xiangsong Cui for their comments, extensive
discussions, and suggestions on this document.
8. References
8.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 v10.0.0, December 2010.
[3GPP.24.008]
3GPP, "Mobile radio interface Layer 3 specification", 3GPP
TS 24.008 v10.1.0, December 2010.
[3GPP.24.302]
3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via
non-3GPP access networks", 3GPP TS 24.302 v10.2.0,
December 2010.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
"Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
October 2007.
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5779] Korhonen, J., Ed., 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.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Authors' Addresses
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
FIN-02600 Espoo
Finland
EMail: jouni.nospam@gmail.com
Vijay Devarapalli
Vasona Networks
EMail: dvijay@gmail.com
ISO Plain Language
On this page
§1Why a Gateway Needs to Find an Anchor
A Proxy Mobile IPv6 (RFC 5213) deployment benefits from a function where a Mobile Access Gateway (MAG) can dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node (MN) attaching to a PMIPv6 domain. The purpose of the dynamic discovery function is to reduce the amount of static configuration in the MAG. Other drivers for the dynamic discovery of an LMA include LMA load balancing solutions and selecting an LMA based on desired services, that is, allowing service-specific routing of traffic (RFC 5149).
The document describes several possible dynamic LMA discovery approaches and makes a recommendation of the preferred one. The approaches discussed do not include all possible discovery mechanisms, but are limited to those considered to fit most simply into the PMIPv6 environment. They are: the LMA address is retrieved from the Authentication, Authorization and Accounting (AAA) infrastructure during the network access authentication procedure when the MN attaches to the MAG; the LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA infrastructure during network access authentication, followed by a DNS lookup; the LMA FQDN is derived from the MN identity received from the lower layers during network attachment, followed by a DNS lookup; the LMA FQDN or IP address is received from the lower layers during network attachment, where reception of an FQDN is followed by a DNS lookup; and the LMA FQDN is derived from the service selection indication received from the lower layers during network attachment, followed by a DNS lookup.
When an MN performs a handover from one MAG to another, the new MAG must use the same LMA that the old MAG was using, because the session has to stay continuous. The discovery mechanism in the new MAG should return the information of the same LMA that the old MAG was using.
Every mobile session lives on an anchor server. A gateway that has to keep a list of those servers by hand stops being manageable once there are many of them, so the gateway should be able to look one up when a device joins. The document narrows the many possible ways down to five and looks at each.
§2Discovery Through the AAA Infrastructure
This solution requires a MAG to be connected to an AAA infrastructure, as described for instance in RFC 5779, and the AAA infrastructure is assumed to be aware of PMIPv6. A mobile node attaching to a PMIPv6 domain is typically required to provide authentication for network access and to be authorized for mobility services before it is allowed to send or receive any IP packets, or even to complete its IP level configuration.
The AAA-based discovery hooks into the network access authentication and authorization process. The MAG also has the role of a Network Access Server at this step. While the node is attaching to the network, the PMIPv6-related parameters are bootstrapped in parallel with authentication for network access and authorization for mobility services, involving the policy profile download over the AAA infrastructure to the MAG.
In the first variant, after the node has been successfully authenticated for network access and authorized for the mobility service, the MAG receives the LMA IP address from the AAA server over the AAA infrastructure. The address is part of the AAA message that ends the successful authentication and authorization portion of the exchange. Once it has the address, the MAG sends a Proxy Binding Update (PBU) message for the newly authenticated and authorized node. The MAG expects that the LMA returned by the AAA server is able to provide mobility session continuity, so that after a handover the LMA is the same one the node already has a session with.
In the second variant, the procedure is the same except that the MAG receives an FQDN for the LMA instead of the IP address, and has to query DNS to resolve it. The FQDN might be a generic name for a PMIPv6 domain that resolves to one or more LMAs, or it might resolve to exactly one LMA within the domain. The second case is useful if a new target MAG, after a handover, resolves the FQDN to the LMA where the node's session already is.
The two procedures may also be used together. The AAA server might return a generic LMA FQDN during the initial attachment, and once the LMA has been selected, return the LMA IP address during subsequent attachments to other MAGs. For that to work, the resolved and selected LMA IP address must be updated to the remote policy store, which the LMA could do using the AAA infrastructure once it receives the initial PBU.
The AAA server already has to authenticate the device before it is allowed to send any packets, so the natural place to say which anchor to use is that same exchange. The server can hand over the anchor's address, or a name that the gateway then looks up in DNS. The two can be mixed: a generic name on the first join, the exact address on later joins.
- Network access authenticationThe node authenticates before it may send any IP packets.
- Authentication and authorizationThe gateway asks the AAA server to authenticate the node and authorize it for mobility.
- LMA address or FQDNThe AAA server returns the anchor address, or a name to look up in DNS.
- Proxy Binding UpdateThe gateway registers the new session with the anchor.
§3Discovery From the Layers Below IP
The remaining solutions are for a MAG that acquires information from layers below the IP layer. Based on that information the MAG can determine which LMA to contact when the node attaches. The lower layers discussed here are not explicitly defined, but include different radio access technologies and tunnelling solutions such as an IKEv2 (RFC 5996) IPsec tunnel (RFC 4303).
The first solution builds the name from the node's identity. A MAG acquires an MN identity from the lower layers and uses information embedded in it to construct a generic LMA FQDN, based on pre-configured formatting rules, and then resolves the LMA IP address using DNS. The identity must embed information that can be used to uniquely identify the entity hosting and operating the LMA for the node. Examples of such identities are the International Mobile Subscriber Identity (IMSI) and the Globally Unique Temporary User Equipment Identity (GUTI), which contain information that can uniquely identify the operator to whom the subscription belongs.
The second solution takes the name or the address straight from the lower layers, for example as part of the normal lower-layer signalling when the node attaches. IKEv2 is an existing example of such signalling where IPsec is the lower layer for the node. IKEv2 has an IKEv2 Identification - Responder (IDr) payload, used by the IKEv2 initiator, which is the node in this case, to specify which of the responder's identities, the LMA in this case, it wants to talk to. The responder identity could be an FQDN or an IP address of the LMA. Another existing example is the Access Point Name Information Element used in 3GPP radio network access signalling and capable of carrying an FQDN. In general this means the node is also the originator of the LMA information, and the content can be transparent to the node, so the node does not associate the information with any LMA function.
The third solution builds the name from a service name. Some network access technologies, including tunnelling solutions, allow the node to signal the service name that identifies a particular service or the external network it wants to reach. If the node-originated service name also embeds the information of the entity hosting the service, or that information can be derived from other information available at the same time, the MAG can construct a generic LMA FQDN providing access to the service or the external network. The pre-defined formatting rules are usually agreed among operators that belong to the same inter-operator roaming consortium, or by network infrastructure vendors defining an open networking system architecture. An example of such a service or external network name is the Access Point Name, which contains the information of the operator providing access to the given service or external network. For example, an FQDN for an ims APN could be ims.apn.epc.mnc015.mcc234.3gppnetwork.org.
Three more routes start below IP. The node's own identity says which operator it belongs to, so a name can be built from it. The signalling that carries the node onto the network may already name the anchor it wants to reach. Or the service the node asked for names the operator, and the name follows from that. Each of these still ends in a DNS lookup.
- AAA returns the addressThe anchor's IP address arrives with the successful authentication and authorization message.
- AAA returns the nameThe anchor's fully qualified domain name arrives instead, and the gateway looks it up in DNS.
- The node's identity gives the nameThe identity names the operator, so the gateway builds a name from it and looks it up.
- The lower layers supply itSignalling below IP already names the anchor the node wants to reach.
- The service name gives the nameThe service the node asked for names the operator, and the name follows from that.
§4Keeping the Same Anchor Across a Handover
Whenever a node moves and attaches to a new MAG in a PMIPv6 domain, all the MAGs that the node attaches to should use the same LMA. If there is only one LMA per PMIPv6 domain, there is no issue. If a context transfer mechanism is available between the MAGs, the new MAG knows the LMA information from the old MAG, and such a mechanism is described in RFC 5949. If the node-related context is not transferred between the MAGs, a mechanism is required to deliver the current LMA information to the new MAG.
Relying on DNS during handovers is not generally a working solution if the PMIPv6 domain has more than one LMA, unless the DNS consistently assigns a specific LMA for each given node. In most cases where the MAG derives the LMA FQDN, there is no prior knowledge of whether the FQDN resolves to one or more LMA IP addresses in the domain. Depending on the deployment and deployment-related regulations, such as inter-operator roaming consortium agreements, the situation might not be this desperate. For example, a MAG might be able to synthesize an LMA-specific FQDN out of a node identity or other service-specific parameters. Alternatively the MAG could use a node identity as an input to an algorithm that deterministically assigns the same LMA out of a pool of LMAs, assuming the MAG has, for example, learned a group of LMA FQDNs via an SRV query (RFC 2782). These approaches would guarantee that DNS always returns the same LMA address to the MAG.
Once the node completes its initial attachment to a PMIPv6 domain, the information about the LMA selected to serve it is stored in the policy store, or the AAA server. The LMA conveys that information to the policy store after the initial attachment is completed, and AAA infrastructure is typically used for exchanging information between the LMA and the policy store. When the node moves and attaches to another MAG in the domain, the AAA server delivers the existing LMA information to the new MAG as part of the authentication and authorization procedure.
A handover only works if the new gateway uses the anchor the old one was using. The document lists three ways to make that happen: there is only one anchor anyway, the gateways hand the information to each other, or the AAA server remembers the choice and tells the new gateway during authentication. Using DNS alone is unreliable unless the name always resolves to the same anchor.
| Approach | How it works |
|---|---|
| One anchor per domain | Every gateway already knows it, so there is nothing to look up |
| Context transfer between gateways | The new gateway is handed the anchor information by the old one |
| The AAA server delivers it | The server stores the chosen anchor and passes it to the new gateway at authentication |
| DNS with a consistent per-node answer | The name always resolves to the same anchor for that node |
§5What the Document Recommends
All the approaches discussed require additional functionality or infrastructure support that the base PMIPv6 specification (RFC 5213) does not require.
The solutions in the section on discovery from lower layers all depend on the lower layers being able to provide information that a MAG can use to query DNS and discover a suitable LMA. The capabilities of the lower layers and the interactions with them are generally out of the scope of the IETF, and specific to a certain system and architecture.
The solutions in the AAA section depend on the existence of an AAA infrastructure able to provide a MAG with either an LMA IP address or an LMA FQDN. While there can be system- and architecture-specific details regarding the AAA interactions and the use of DNS, the dynamic LMA discovery can be implemented in an access- and technology-agnostic manner, and work in the same way across heterogeneous environments. Using AAA-based LMA discovery solutions is therefore recommended by the document. Furthermore, following the guidance in Section 4, Paragraph 4.1 of RFC 1958, the use of FQDNs should be preferred over IP addresses in the context of AAA-based LMA discovery solutions.
The recommendation is the AAA route, and inside it, names rather than addresses. The reason is portability: a name still resolves if the anchor moves, and the method works the same whether the access network is Ethernet, wireless or something else.
§6Security Considerations
The use of DNS for obtaining the IP address of a mobility agent carries certain security risks, explained in detail in Section 9.1 of RFC 5026. The risks described in RFC 5026 are mitigated to a large extent in this document, since the MAG and the LMA belong to the same PMIPv6 domain, and the DNS server that the MAG queries is also part of the same PMIPv6 domain. Even if the MAG obtains the IP address of a bogus LMA from a bogus DNS server, further harm is prevented because the MAG and the LMA should authenticate each other before exchanging PMIPv6 signalling messages. RFC 5213 specifies the use of IKEv2 between the MAG and the LMA to authenticate each other and set up IPsec security associations for protecting the PMIPv6 signalling messages.
The AAA infrastructure may be used to transport the LMA-discovery-related information between the MAG and the AAA server via one or more AAA brokers and/or AAA proxies. In that case, the MAG-to-AAA-server communication relies on the security properties of the intermediate AAA brokers and AAA proxies.
A poisoned name lookup is not fatal here, because the gateway and the anchor still authenticate each other with IKEv2 before they exchange anything. What remains in the operator's hands is the security of the AAA brokers in between.