RFC 6097

Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6

📅 published February 2011, from ietf

Abstract ✨

Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 🎀

Big Proxy Mobile IPv6 deployments would be so much happier if a Mobile Access Gateway could find a Local Mobility Anchor for a Mobile Node all on its own 🥹 That's the whole point: less static configuration sitting in the Mobile Access Gateway. This document walks through several possible dynamic LMA discovery solutions 💖

Document facts 🦋 This is RFC 6097, and it's Informational, so it's published for info and isn't a Standards Track spec. It's from February 2011 (ISSN 2070-1721) and was written by J. Korhonen (Nokia Siemens Networks) and V. Devarapalli (Vasona Networks). The title block doesn't list anything it obsoletes or updates, so it stands on its own 💅

Status of This Memo 📋

Real talk, this one isn't an Internet Standards Track spec. It's just published for informational purposes 🌸

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6097 🔗

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 👀 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 🌷

Okay so, a Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would be lowkey iconic with a feature where a Mobile Access Gateway (MAG) can dynamically find a Local Mobility Anchor (LMA) for a Mobile Node (MN) that's attaching to a PMIPv6 domain 🦋 The whole goal is to cut down the static configuration in the MAG. Other reasons to discover an LMA dynamically include LMA load balancing and picking an LMA based on the services you want (like service-specific routing of traffic) [RFC5149]. This document describes a few possible dynamic LMA discovery approaches and recommends the one it likes best ✨

Here's a quick list of the solution approaches we'll cover 💅 Just a heads up, they don't cover every discovery mechanism out there. They're limited to the ones that fit most simply into the PMIPv6 environment 🫶

  • 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.
  • 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.
  • LMA FQDN is derived from the MN identity received from the lower layers during the network attachment, followed by a DNS lookup.
  • 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.
  • LMA FQDN is derived from the service selection indication received from lower layers during the network attachment, followed by a DNS lookup.

Now the main drama 😭 When an MN hands over 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 covers solutions for LMA discovery during a handover 🧚

2. AAA-Based Discovery Solutions 🔐

This section introduces an LMA discovery solution that needs the 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 it's allowed to send or receive any IP packets or even finish its IP level configuration. Strict, but make it make sense 😤

The AAA-based LMA discovery solution hooks into the network access authentication and authorization process. The MAG also takes on the role of a Network Access Server (NAS) at this step ✨ While the MN is attaching to the network, the PMIPv6-related parameters get bootstrapped in parallel with the authentication for network access and the authorization for mobility services. Bootstrapping the 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 📍

Once 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 info would be part of the AAA message that ends the successful authentication and authorization portion of the AAA exchange 🫶

After the MAG gets 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 the AAA server returned is able to provide mobility session continuity for the MN. In other words, 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 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 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 that domain. Alternatively, the LMA FQDN might resolve 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's mobility session is already located 💅

The procedures 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. 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 📡

This section talks about solutions where a MAG gets information from layers below the IP layer. Based on that info, the MAG can figure out which LMA to contact when the MN attaches to it ✨ The lower layers discussed here aren't explicitly defined, but they 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 the lower layers. The MAG can use the information embedded in that identity to construct a generic LMA FQDN (based on some pre-configured formatting rules), and then go ahead and resolve the LMA IP address(es) using 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 the subscription belongs to 🥰

3.2. Receiving the LMA FQDN or IP Address from Lower Layers 📶

This solution is similar to the one in Section 3.1. A MAG receives an LMA FQDN or an IP address from the lower layers, for example, as part of the normal lower-layer signaling when the MN attaches to the network 🎀 IKEv2 could be an existing example of that lower-layer signaling, where IPsec is the "lower layer" for the MN [3GPP.24.302]. IKEv2 has an IKEv2 Identification - Responder (IDr) payload, which the IKEv2 initiator (the MN in this case) uses to specify which of the responder's identities (the LMA in this case) it wants to talk to. The responder identity here could be an FQDN or an IP address of the LMA, since the IKEv2 identification payload can be either an IP address or an FQDN 🤓 Another existing example is the Access Point Name Information Element (APN IE) [3GPP.24.008], which is used in 3GPP radio network access signaling and can carry 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 doesn't associate that information with any LMA function 🦋

3.3. Constructing the LMA FQDN from a Service Name 💅

okay so some network access technologies (tunneling stuff included) let the MN tell the network which service it wants, or which external network it's trying to reach 🌸 [3GPP.24.302] [RFC5996]. if that service name already includes info about the entity hosting the service, or the hosting info can be figured out from other stuff that's available at the same time (see Section 3.1, bestie), then the MAG can build a generic LMA FQDN 🧚 (like, using some predefined formatting rules) that gives access to that service or external network. those formatting rules [3GPP.23.003] are usually agreed on by operators in the same inter-operator roaming consortium, or by network infrastructure vendors designing an open networking system architecture. it's giving teamwork 🫶

once the MAG has the FQDN, it can go ahead and resolve the LMA IP address(es) using the DNS ✨. an example of a service or external network name like this is the Access Point Name (APN) [3GPP.23.003], which contains info about the operator providing access to that service or external network. for instance, an FQDN for an "ims" APN could be ims.apn.epc.mnc015.mcc234.3gppnetwork.org 💖

4. Handover Considerations 🦋

okay this part is giving main character energy 👑 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's only one LMA per PMIPv6 domain, then no issue, we're good 🎀. if there's a context transfer mechanism between the MAGs, then the new MAG knows the LMA info from the old MAG. that mechanism is described in [RFC5949]. if the MN-related context isn't transferred between the MAGs, then a mechanism to deliver the current LMA info 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 of the cases from Section 3, where the MAG derives the LMA FQDN, there's no prior knowledge of whether the LMA FQDN resolves to one or more LMA IP address(es) in the PMIPv6 domain. ngl that's kind of a lot 😭 but depending on the deployment and deployment-related regulations (like inter-operator roaming consortium agreements), it might not be this desperate 🌈. for example, a MAG might be able to synthesize an LMA-specific FQDN (say, out of an MN identity or some other service-specific parameters) ✨. or 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 finishes its initial attachment to a PMIPv6 domain, the info about the LMA selected to serve the MN is stored in the policy store (or the AAA server) 📦. the LMA sends that info to the policy store after the initial attachment is completed [RFC5779]. typically, AAA infrastructure is what's used for exchanging info between the LMA and the policy store 🔥

when the MN moves and attaches to another MAG in the PMIPv6 domain, the AAA server delivers the existing LMA info to the new MAG as part of the authentication and authorization procedure, as described in Section 2.1 🫶

5. Recommendations 🌸

so this document talked through several solution approaches for dynamic LMA discovery 🧠. all of them actually need extra functionality or infrastructure support that the base PMIPv6 specification [RFC5213] doesn't require, which is kind of a plot twist 😭

the solutions in Section 3 all depend on lower layers being able to provide info that a MAG can use to query the DNS and discover a suitable LMA ✨. what the lower layers can do, and how they interact with that stuff, is generally out of scope for the IETF, and it's specific to a certain system and architecture 🙈

the solutions in Section 2 depend on an AAA infrastructure existing, one that can give a MAG either an LMA IP address or an LMA FQDN 🦋. there can be system- and architecture-specific details about the AAA interactions and the use of DNS, but dynamic LMA discovery can be implemented in an access- and technology-agnostic way and work the same way across heterogeneous environments. so this document recommends using AAA-based LMA discovery solutions 👑. also, following the guidance in Section 4, Paragraph 4.1 of [RFC1958], FQDNs should be preferred over IP addresses in the context of AAA-based LMA discovery solutions 💖

6. Security Considerations 😭

okay, lowkey serious moment, bestie 🚨. using DNS to get 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 that same PMIPv6 domain. even if the MAG gets 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 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 info 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 those intermediate AAA brokers and AAA proxies. so yeah, the chain is only as strong as its weakest link, periodt 💀

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 💖 the whole squad that showed up for this one 🎀

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
📦 where this page comes from