From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6097.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc6097.txt (limited to 'doc/rfc/rfc6097.txt') 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] + -- cgit v1.2.3