LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-07.txt

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 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 April 15, 2011.

Copyright Notice

Copyright (c) 2010 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.  AAA-based Discovery Solutions
    2.1.  Receiving LMA Address during the Network Access Authentication
    2.2.  Receiving LMA FQDN during the Network Access Authentication
3.  Discovery Solutions based on Data from Lower Layers
    3.1.  Constructing the LMA FQDN from a Mobile Node Identity
    3.2.  Receiving LMA FQDN or IP Address from Lower Layers
    3.3.  Constructing the LMA FQDN from a Service Name
4.  Handover Considerations
5.  Recommendations
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

1.  Introduction

A Proxy Mobile IPv6 (PMIPv6) [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) 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 a LMA include LMA load balancing solutions and selecting a LMA based on desired services (i.e. allowing service-specific routing of traffic) [RFC5149] (Korhonen, J., Nilsson, U., and V. Devarapalli, “Service Selection for Mobile IPv6,” February 2008.). 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:

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 a 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 a LMA discovery solution that requires a MAG to be connected to an AAA infrastructure for instance as described in [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,” February 2010.). The AAA infrastructure is also assumed to be aware of PMIPv6. A 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 has also 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 PMIPv6 parameters bootstrapping involves the Policy Profile download over the AAA infrastructure to the MAG (see Appendix A of [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.)).

2.1.  Receiving LMA Address during the Network Access Authentication

After the MN has successfully authenticated for the 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 AAA exchange.

Once the MAG receives the LMA IP address, it sends 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 LMA FQDN during the Network Access Authentication

This solution is similar to the procedure described in Section 2.1 (Receiving LMA Address during the Network Access Authentication). 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 should resolve 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 (Receiving LMA Address during the Network Access Authentication) may also be used together. For example, the AAA server might return a generic LMA FQDN during the MN initial attach 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 IKEv2 [RFC5996] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol Version 2 (IKEv2),” September 2010.) IPsec tunnel [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.).

3.1.  Constructing the LMA FQDN from a Mobile Node Identity

A MAG acquires a 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 Globally Unique Temporary User Equipment Identity (GUTI) [3GPP.23.003] (3GPP, “Numbering, addressing and identification,” September 2008.). These MN identities contain information that can uniquely identify the operator where the subscription belongs to.

3.2.  Receiving LMA FQDN or IP Address from Lower Layers

The solution described here is similar to the solution discussed in Section 3.1 (Constructing the LMA FQDN from a Mobile Node Identity). A MAG receives a 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 existing example of such lower layer signaling where IPsec is the "lower layer" for the MN [3GPP.24.302] (3GPP, “Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks,” June 2010.). IKEv2 has an IKEv2 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) in 3GPP radio's network access signaling capable of carrying a FQDN [3GPP.24.008] (3GPP, “Mobile radio interface Layer 3 specification,” June 2009.). 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] (3GPP, “Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks,” June 2010.) [RFC5996] (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol Version 2 (IKEv2),” September 2010.). 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 (Constructing the LMA FQDN from a Mobile Node Identity)), 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] (3GPP, “Numbering, addressing and identification,” September 2008.) 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 service or external network name is the Access Point Name (APN) [3GPP.23.003] (3GPP, “Numbering, addressing and identification,” September 2008.) that contain 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 a 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] (Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, “Fast Handovers for Proxy Mobile IPv6,” September 2010.). 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 (Discovery Solutions based on Data from Lower Layers), 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 regulation (such as inter-operator roaming consortium agreements) the situation might not be this desperate. For example, a MAG might be able to synthesize a LMA specific FQDN (e.g. out of MN identity or some other service specific parameters). Alternatively, the MAG could use (for example), a 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 SRV [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) query). These approaches would guarantee that DNS returns always 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] (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,” February 2010.). 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 servers delivers the existing LMA information to the new MAG as part of the authentication and authorization procedure as described in Section 2.1 (Receiving LMA Address during the Network Access Authentication)

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 [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) does not require.

Solutions in Section 3 (Discovery Solutions based on Data from Lower Layers) all depend on lower layers being able to provide information that a MAG can then use to query DNS and discover a suitable LMA. The capabilities of the lower layers and the interactions with them are generally out of scope of IETF, and specific to a certain system and architecture.

Solutions in Section 2 (AAA-based Discovery Solutions) depend on the existence of an AAA infrastructure, which is able to provide a MAG either a LMA IP address or a 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 are recommended by this document.

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] (Giaretta, G., Kempf, J., and V. Devarapalli, “Mobile IPv6 Bootstrapping in Split Scenario,” October 2007.). However, the risks described in [RFC5026] (Giaretta, G., Kempf, J., and V. Devarapalli, “Mobile IPv6 Bootstrapping in Split Scenario,” October 2007.) 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] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) specifies the use of IKEv2 between the MAG and the LMA to authenticate each other and setup 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 the AAA server communication relies on the security properties of the intermediate AAA brokers and AAA proxies.

7.  IANA Considerations

This document has no actions for IANA.

8.  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.

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses