summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6097.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6097.txt')
-rw-r--r--doc/rfc/rfc6097.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6097.txt b/doc/rfc/rfc6097.txt
new file mode 100644
index 0000000..c17656b
--- /dev/null
+++ b/doc/rfc/rfc6097.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 1]
+
+RFC 6097 LMA Discovery February 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ 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.
+
+
+
+
+Korhonen & Devarapalli Informational [Page 2]
+
+RFC 6097 LMA Discovery February 2011
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 3]
+
+RFC 6097 LMA Discovery February 2011
+
+
+ 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.
+
+
+
+Korhonen & Devarapalli Informational [Page 4]
+
+RFC 6097 LMA Discovery February 2011
+
+
+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.
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 5]
+
+RFC 6097 LMA Discovery February 2011
+
+
+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
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 6]
+
+RFC 6097 LMA Discovery February 2011
+
+
+ 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.
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 7]
+
+RFC 6097 LMA Discovery February 2011
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 8]
+
+RFC 6097 LMA Discovery February 2011
+
+
+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.
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 9]
+
+RFC 6097 LMA Discovery February 2011
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Devarapalli Informational [Page 10]
+