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
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
代理移动IPv6的本地移动锚（LMA）发现
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.
大型代理移动IPv6部署将受益于这样一种功能，即移动接入网关可以为连接到代理移动IPv6域的移动节点动态发现本地移动锚。动态发现功能的目的是减少移动接入网关中的静态配置量。本文档描述了几种可能的动态本地移动锚发现解决方案。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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.
代理移动IPv6（PMIPv6）[RFC5213]部署将受益于移动接入网关（MAG）可以动态发现连接到PMIPv6域的移动节点（MN）的本地移动锚（LMA）的功能。动态发现功能的目的是减少MAG中的静态配置量。LMA动态发现的其他驱动程序包括LMA负载平衡解决方案和基于所需服务选择LMA（即，允许特定于服务的流量路由）[RFC5149]。本文档描述了几种可能的动态LMA发现方法，并推荐了首选方法。
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.
以下列表简要介绍了本文档中将讨论的解决方案方法。讨论的方法不包括所有可能的发现机制，但仅限于那些被认为最适合PMIPv6环境的机制。
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 当MN连接到MAG时，在网络访问认证过程中，从认证、授权和计费（AAA）基础设施检索LMA地址。
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）在网络访问身份验证期间从AAA基础设施中检索，然后进行域名系统（DNS）查找。
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源自在网络连接期间从较低层接收的MN标识，然后是DNS查找。
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或IP地址在网络连接期间从较低层接收。从较低层接收FQDN之后是DNS查找。
o LMA FQDN is derived from the service selection indication received from lower layers during the network attachment, followed by a DNS lookup.
o LMA FQDN源自在网络连接期间从较低层接收的服务选择指示，然后是DNS查找。
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.
当MN执行从一个MAG到另一个MAG的切换时，新MAG必须使用旧MAG使用的相同LMA。这是会话连续性所必需的。新MAG中的LMA发现机制应能够返回旧MAG使用的相同LMA的信息。本文档还讨论了切换期间LMA发现的解决方案。
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.
本节介绍一种LMA发现解决方案，该解决方案要求MAG连接到AAA基础设施（如[RFC5779]中所述）。AAA基础设施也被认为知道PMIPv6。在允许MN发送或接收任何IP分组或甚至完成其IP级配置之前，通常需要连接到PMIPv6域的MN来为网络接入提供认证，并被授权用于移动服务。
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]).
基于AAA的LMA发现解决方案与网络访问身份验证和授权过程挂钩。在此步骤中，MAG还具有网络访问服务器（NAS）的角色。当MN连接到网络时，PMIPv6相关参数与网络接入的认证和移动服务的授权并行引导。PMIPv6参数的引导涉及通过AAA基础设施将策略配置文件下载到MAG（参见[RFC5213]的附录A）。
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.
在MN已成功地针对网络接入进行认证并针对移动服务进行授权之后，MAG通过AAA基础设施从AAA服务器接收LMA IP地址。LMA IP地址信息将是AAA消息的一部分，该消息结束AAA交换的成功身份验证和授权部分。
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.
一旦MAG接收到LMA IP地址，它就为新认证和授权的MN发送代理绑定更新（PBU）消息。MAG期望由AAA服务器返回的LMA能够为MN提供移动性会话连续性，即，在切换之后，LMA将与MN已经设置了移动性会话的LMA相同。
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).
该解决方案类似于第2.1节中描述的程序。区别在于MAG接收LMA的FQDN而不是IP地址。MAG必须查询DNS基础设施，以便将FQDN解析为LMA IP地址。
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.
LMA FQDN可能是解析为PMIPv6域中的一个或多个LMA的PMIPv6域的通用名称。或者，LMA FQDN可以解析为PMIPv6域中的一个LMA。如果在切换之后，新的目标MAG将LMA FQDN解析为MN移动会话已经位于的LMA IP地址，则后一种方法显然是有用的。
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.
本节和第2.1节中描述的程序也可一起使用。例如，AAA服务器可能在MN的初始连接期间返回通用LMA FQDN，并且一旦选择了LMA，则在随后连接到PMIPv6域中的其他MAG期间返回LMA IP地址。为了使其工作，必须将解析和选择的LMA IP地址更新到远程策略存储。例如，LMA一旦从MAG接收到用于新移动会话的初始PBU，就可以使用AAA基础设施执行策略存储更新。
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].
下一节讨论MAG从IP层以下的层获取信息的解决方案。基于此信息，当MN连接到MAG时，MAG能够确定要接触哪个LMA。此处讨论的较低层没有明确定义，但包括不同的无线接入技术和隧道解决方案，例如Internet密钥交换版本2（IKEv2）[RFC5996]IPsec隧道[RFC4303]。
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.
MAG从较低层获取MN标识。MAG可以使用身份中嵌入的信息构造通用LMA FQDN（基于一些预先配置的格式化规则），然后继续使用DNS解析LMA IP地址。显然，MN标识必须嵌入可用于唯一标识承载和操作MN LMA的实体的信息。此类MN标识的示例是国际移动用户标识（IMSI）和全球唯一临时用户设备标识（GUTI）[3GPP.23.003]。这些MN标识包含可以唯一标识订阅所属的操作员的信息。
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.1节中讨论的解决方案类似。例如，当MN连接到网络时，MAG从较低层接收LMA FQDN或IP地址，作为正常较低层信令的一部分。IKEv2可以是这样的低层信令的现有示例，其中IPsec是MN的“低层”[3GPP.24.302]。IKEv2有一个IKEv2标识-响应器（IDr）有效载荷，IKEv2启动器（即，本例中的MN）使用该有效载荷来指定它想要与哪个响应器的身份（即，本例中的LMA）对话。这里，响应者标识可以是FQDN或LMA的IP地址（因为IKEv2标识有效负载可以是IP地址或FQDN）。另一个现有示例是在3GPP无线网络接入信令中使用并能够承载FQDN的接入点名称信息元素（APN IE）[3GPP.24.008]。然而，一般而言，这意味着MN也是LMA信息的发起人。LMA信息内容本身可以对MN透明，这意味着MN不将该信息与任何LMA功能相关联。
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.
一些网络接入技术（包括隧道解决方案）允许MN向服务名称发送信号，以标识特定服务或其想要访问的外部网络[3GPP.24.302][RFC5996]。如果源于MN的服务名称还嵌入了托管服务的实体的信息，或者托管信息可以同时从其他可用信息中派生（例如，参见第3.1节），则MAG可以构造通用LMA FQDN（例如，基于一些预定义的格式规则）提供对服务或外部网络的访问。预定义的格式化规则[3GPP.23.003]通常由属于同一运营商间漫游联盟的运营商或定义开放网络系统架构的网络基础设施供应商商定。
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".
一旦MAG拥有FQDN，它可以继续使用DNS解析LMA IP地址。这种服务或外部网络名称的一个示例是接入点名称（APN）[3GPP.23.003]，其中包含提供对给定服务或外部网络的访问的运营商的信息。例如，“ims”APN的FQDN可以是“ims.APN.epc.mnc015.mcc234.3gppnetwork.org”。
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.
每当MN移动并连接到PMIPv6域中的新MAG时，MN连接到的所有MAG都应使用相同的LMA。如果每个PMIPv6域只有一个LMA，则不存在问题。如果MAG之间存在可用的上下文传输机制，则新MAG从旧MAG知道LMA信息。此类机制在[RFC5949]中描述。如果MN相关上下文未在MAG之间传输，则需要将当前LMA信息传递给新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 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
如果PMIPv6域具有多个LMA，则在切换期间依赖DNS通常不是有效的解决方案，除非DNS一致地为每个给定MN分配特定的LMA。在第3节中描述的大多数情况下，当MAG导出LMA FQDN时，事先不知道LMA FQDN是否解析为PMIPv6域中的一个或多个LMA IP地址。然而，根据部署和部署相关法规（如运营商间漫游联盟协议），情况可能不会如此危急。例如，MAG可能能够合成LMA特定FQDN（例如，从MN身份或某些其他身份）
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.
服务特定参数）。或者，MAG可以使用（例如）MN标识作为算法的输入，该算法从LMA池中确定地分配相同的LMA（假设MAG已经例如通过SRV[RFC2782]查询学习了一组LMA fqdn）。这些方法将保证DNS总是向MAG返回相同的LMA地址。
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.
一旦MN完成其到PMIPv6域的初始连接，关于选择为MN服务的LMA的信息存储在策略存储（或AAA服务器）中。初始连接完成后，LMA将LMA信息传送到策略存储[RFC5779]。通常，AAA基础设施用于在LMA和策略存储之间交换信息。
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.
当MN移动并连接到PMIPv6域中的另一个MAG时，AAA服务器将现有LMA信息传递给新的MAG，作为第2.1节所述认证和授权过程的一部分。
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.
本文讨论了动态LMA发现的几种解决方案。所有讨论的解决方案方法实际上都需要基本PMIPv6规范[RFC5213]不需要的附加功能或基础设施支持。
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.
第3节中的解决方案都依赖于较低层能够提供信息，然后MAG可以使用这些信息查询DNS并发现合适的LMA。较低层的能力及其交互通常不在IETF的范围内，并且特定于某个系统和架构。
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.
第2节中的解决方案取决于AAA基础设施的存在，该基础设施能够向MAG提供LMA IP地址或LMA FQDN。虽然可能存在关于AAA交互和DNS使用的系统和体系结构特定的详细信息，但动态LMA发现可以以访问和技术无关的方式实现，并且在异构环境中以相同的方式工作。因此，本文档建议使用基于AAA的LMA发现解决方案。此外，根据[RFC1958]第4节第4.1段中的指导，在基于AAA的LMA发现解决方案中，FQDN的使用应优先于IP地址。
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.
使用DNS获取移动代理的IP地址会带来一定的安全风险。[RFC5026]的第9.1节对此进行了详细说明。然而，由于MAG和LMA属于同一PMIPv6域，因此[RFC5026]中描述的风险在本文件中得到了很大程度的缓解。MAG查询的DNS服务器也是同一PMIPv6域的一部分。即使MAG从伪DNS服务器获得伪LMA的IP地址，也可以防止进一步的伤害，因为MAG和LMA应该在交换PMIPv6信令消息之前相互认证。[RFC5213]指定在MAG和LMA之间使用IKEv2相互验证并建立IPsec安全关联以保护PMIPv6信令消息。
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.
AAA基础设施可用于经由一个或多个AAA代理和/或AAA代理在MAG和AAA服务器之间传输LMA发现相关信息。在这种情况下，MAG到AAA服务器的通信依赖于中间AAA代理和AAA代理的安全属性。
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.
作者感谢Julien Laganier、Christian Vogt、Ryuji Wakikawa、Frank Xia、Behcet Sarikaya、Charlie Perkins、秦武、Jari Arkko和崔祥松对本文件的评论、广泛讨论和建议。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 v10.0.0, December 2010.
[3GPP.23.003]3GPP，“编号、寻址和标识”，3GPP TS 23.003 v10.0.012010年12月。
[3GPP.24.008] 3GPP, "Mobile radio interface Layer 3 specification", 3GPP TS 24.008 v10.1.0, December 2010.
[3GPP.24.008]3GPP，“移动无线电接口第3层规范”，3GPP TS 24.008 v10.1.012010年12月。
[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.
[3GPP.24.302]3GPP，“通过非3GPP接入网络访问3GPP演进包核心（EPC）”，3GPP TS 24.302 v10.2.02010年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]Giaretta，G.，Ed.，Kempf，J.，和V.Devarapalli，Ed.，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5149]Korhonen，J.，Nilsson，U.，和V.Devarapalli，“移动IPv6的服务选择”，RFC 5149，2008年2月。
[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.
[RFC5779]Korhonen，J.，Ed.，Bournelle，J.，Chowdhury，K.，Muhanna，A.，和U.Meyer，“Diameter代理移动IPv6：移动接入网关和本地移动锚与Diameter服务器的交互”，RFC 5779，2010年2月。
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010.
[RFC5949]横田，H.，乔杜里，K.，库德利，R.，帕蒂尔，B.，和夏菲，“代理移动IPv6的快速切换”，RFC 59492010年9月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
Authors' Addresses
作者地址
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FIN-02600 Espoo Finland
Jouni Korhonen诺基亚西门子网络公司Linnoitustie 6 FIN-02600 Espoo芬兰
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Vijay Devarapalli Vasona Networks
Vijay Devarapalli Vasona网络
EMail: dvijay@gmail.com
EMail: dvijay@gmail.com