Internet Engineering Task Force (IETF)                           G. Zorn
Request for Comments: 7156                                   Network Zen
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                   Huawei
                                                             J. Korhonen
                                                                Broadcom
                                                              April 2014
        
Internet Engineering Task Force (IETF)                           G. Zorn
Request for Comments: 7156                                   Network Zen
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                   Huawei
                                                             J. Korhonen
                                                                Broadcom
                                                              April 2014
        

Diameter Support for Proxy Mobile IPv6 Localized Routing

Diameter支持代理移动IPv6本地化路由

Abstract

摘要

In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.

在代理移动IPv6中,由移动接入网关(MAG)从移动节点(MN)接收的数据包通常通过隧道传输到本地移动锚(LMA)以进行路由。术语“局部路由”是指在不涉及任何LMA的情况下在MN的MAG与其对应节点(CN)的MAG之间直接路由分组的方法。在代理移动IPv6部署中,可能希望通过要求对会话进行授权来控制代理移动IPv6域中两个mag之间的本地化路由会话的建立。本文档指定了如何使用Diameter协议完成此操作。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

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). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(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/rfc7156.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7156.

Copyright Notice

版权公告

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Attribute Value Pair Used in This Document  . . . . . . . . .   4
     4.1.  User-Name AVP . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . .   5
     4.3.  MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . .   5
     4.4.  MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . .   5
   5.  Example Signaling Flows for Localized Routing Service
       Authorization . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Attribute Value Pair Used in This Document  . . . . . . . . .   4
     4.1.  User-Name AVP . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . .   5
     4.3.  MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . .   5
     4.4.  MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . .   5
   5.  Example Signaling Flows for Localized Routing Service
       Authorization . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
        
1. Introduction
1. 介绍

Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobile Access Gateway (MAG) to optimize media delivery by locally routing packets from a Mobile Node (MN) to a Correspondent Node (CN) that is locally attached to an access link connected to the same Mobile Access Gateway, avoiding tunneling them to the Mobile Node's Local Mobility Anchor (LMA). This is referred to as "local routing" in RFC 5213 [RFC5213]. However, this mechanism is not applicable to the typical scenarios in which the MN and CN are connected to different MAGs and are registered to the same LMA or different LMAs. [RFC6279] takes those typical scenarios into account and defines the problem statement for PMIPv6 localized routing. Based on the scenarios A11, A12, and A21 described in [RFC6279], [RFC6705] specifies the PMIPv6 localized routing protocol that is used to establish a localized routing path between two Mobile Access Gateways in a PMIPv6 domain.

代理移动IPv6(PMIPv6)[RFC5213]允许移动接入网关(MAG)通过将分组从移动节点(MN)本地路由到本地连接到连接到同一移动接入网关的接入链路的对应节点(CN)来优化媒体递送,避免将它们隧道到移动节点的本地移动锚(LMA)。这在RFC 5213[RFC5213]中称为“本地路由”。然而,该机制不适用于MN和CN连接到不同mag并且注册到相同LMA或不同LMA的典型场景。[RFC6279]考虑了这些典型场景,并定义了PMIPv6本地化路由的问题陈述。基于[RFC6279]中描述的场景A11、A12和A21,[RFC6705]指定了用于在PMIPv6域中的两个移动接入网关之间建立本地化路由路径的PMIPv6本地化路由协议。

This document describes Authentication, Authorization, and Accounting (AAA) support using Diameter [RFC6733] for the authorization procedure between the PMIPv6 mobility entities (MAG or LMA) and a AAA server within a Proxy Mobile IPv6 domain for localized routing in the scenarios A11, A12, and A21 described in [RFC6279].

本文档描述了在[RFC6279]中描述的场景A11、A12和A21中,使用Diameter[RFC6733]对PMIPv6移动实体(MAG或LMA)和代理移动IPv6域内的AAA服务器之间的授权过程进行身份验证、授权和记帐(AAA)支持,以实现本地化路由。

2. Terminology
2. 术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

3. Solution Overview
3. 解决方案概述

This document addresses how to provide authorization information to the Mobile Node's MAG or LMA to enable localized routing and resolve the destination MN's MAG by means of interaction between the LMA and the AAA server. Figure 1 shows the reference architecture for Localized Routing Service Authorization. This reference architecture assumes that

本文档阐述了如何向移动节点的MAG或LMA提供授权信息,以通过LMA和AAA服务器之间的交互来实现本地化路由和解析目的地MN的MAG。图1显示了本地化路由服务授权的参考体系结构。此参考体系结构假定

o If the MN and CN belong to different LMAs, the MN and CN should share the same MAG (i.e., scenario A12 described in [RFC6279]), e.g., MN1 and CN2 in Figure 1 are attached to MAG1 and belong to LMA1 and LMA2, respectively. Note that LMA1 and LMA2 in Figure 1 are in the same provider domain (as described in [RFC6279]).

o 如果MN和CN属于不同的LMA,则MN和CN应共享相同的MAG(即,[RFC6279]中描述的场景A12),例如,图1中的MN1和CN2连接到MAG1,分别属于LMA1和LMA2。请注意,图1中的LMA1和LMA2位于同一提供者域中(如[RFC6279]中所述)。

o If the MN and CN are attached to different MAGs, the MN and CN should belong to the same LMA (i.e., scenario A21 described in [RFC6279]); for example, MN1 and CN3 in Figure 1 are attached to MAG1 and MAG3, respectively, but belong to LMA1.

o 如果MN和CN连接到不同的MAG,则MN和CN应属于相同的LMA(即[RFC6279]中描述的场景A21);例如,图1中的MN1和CN3分别连接到MAG1和MAG3,但属于LMA1。

o The MN and CN may belong to the same LMA and may be attached to the same MAG (i.e., scenario A11 described in [RFC6279]), e.g., MN1 and CN1 in Figure 1 are both attached to the MAG1 and belong to LMA1.

o MN和CN可以属于相同的LMA,并且可以连接到相同的MAG(即,[RFC6279]中描述的场景A11),例如,图1中的MN1和CN1都连接到MAG1并且属于LMA1。

o The MAG and LMA support Diameter client functionality.

o MAG和LMA支持Diameter客户端功能。

                                   +---------+
           +---------------------->|  AAA &  |
           |               +------>| Policy  |
           |               |       | Profile |
           |           Diameter    +---------+
           |               |
           |            +--V-+    +----+
           |   +------->|LMA1|    |LMA2|
           |   |        +---++    +----+
           |   |          | |       |
      Diameter |          | +-------+---------
           |   |          |         |        |
           |  PMIP        |         |        \\
           |   |         //        //         \\
           |   |        //        //           \\
           |   |       //        //             \\
           |   |       |         |               |
           |   +---->+---------------+         +----+
           |         |     MAG1      |         |MAG3|
           +-------->+---------------+         +----+
                       :    :      :              :
                    +---+  +---+  +---+         +---+
                    |MN1|  |CN1|  |CN2|         |CN3|
                    +---+  +---+  +---+         +---+
        
                                   +---------+
           +---------------------->|  AAA &  |
           |               +------>| Policy  |
           |               |       | Profile |
           |           Diameter    +---------+
           |               |
           |            +--V-+    +----+
           |   +------->|LMA1|    |LMA2|
           |   |        +---++    +----+
           |   |          | |       |
      Diameter |          | +-------+---------
           |   |          |         |        |
           |  PMIP        |         |        \\
           |   |         //        //         \\
           |   |        //        //           \\
           |   |       //        //             \\
           |   |       |         |               |
           |   +---->+---------------+         +----+
           |         |     MAG1      |         |MAG3|
           +-------->+---------------+         +----+
                       :    :      :              :
                    +---+  +---+  +---+         +---+
                    |MN1|  |CN1|  |CN2|         |CN3|
                    +---+  +---+  +---+         +---+
        

Figure 1: Localized Routing Service Authorization Reference Architecture

图1:本地化路由服务授权参考体系结构

The interaction of the MAG and LMA with the AAA server according to the extension specified in this document is used to authorize the localized routing service.

根据本文档中指定的扩展,MAG和LMA与AAA服务器的交互用于授权本地化路由服务。

4. Attribute Value Pair Used in This Document
4. 本文档中使用的属性-值对

This section describes Attribute Value Pairs (AVPs) and AVP values defined by this specification or reused from existing specifications in a PMIPv6-specific way.

本节描述本规范定义的属性值对(AVP)和AVP值,或以PMIPv6特定方式从现有规范中重用。

4.1. User-Name AVP
4.1. 用户名AVP

The User-Name AVP (AVP Code 1) is defined in [RFC6733], Section 8.14. This AVP is used to carry the Mobile Node identifier (MN-Identifier) [RFC5213] in the Diameter AA-Request message [RFC7155] sent to the AAA server. The MN-Identifier is defined in PMIPv6 [RFC5213].

[RFC6733]第8.14节定义了用户名AVP(AVP代码1)。此AVP用于携带发送到AAA服务器的Diameter AA请求消息[RFC7155]中的移动节点标识符(MN标识符)[RFC5213]。MN标识符在PMIPv6[RFC5213]中定义。

4.2. PMIP6-IPv4-Home-Address AVP
4.2. PMIP6-IPv4-Home-Address AVP
   The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in
   [RFC5779], Section 5.2.  This AVP is used to carry the Mobile Node's
   IPv4 home address (IPv4-MN-HoA) in the Diameter AA-Request message
   [RFC7155] sent to the AAA server.  The IPv4-MN-HoA is defined in
   [RFC5844].
        
   The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in
   [RFC5779], Section 5.2.  This AVP is used to carry the Mobile Node's
   IPv4 home address (IPv4-MN-HoA) in the Diameter AA-Request message
   [RFC7155] sent to the AAA server.  The IPv4-MN-HoA is defined in
   [RFC5844].
        
4.3. MIP6-Home-Link-Prefix AVP
4.3. MIP6主链接前缀AVP

The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779], Section 5.3. This AVP is used to carry the Mobile Node's home network prefix (MN-HNP) in the Diameter AA-Request [RFC7155] sent to the AAA server.

[RFC5779]第5.3节定义了MIP6主链路前缀AVP(AVP代码125)。此AVP用于在发送到AAA服务器的Diameter AA请求[RFC7155]中携带移动节点的家庭网络前缀(MN-HNP)。

4.4. MIP6-Feature-Vector AVP
4.4. MIP6特征向量AVP

The MIP6-Feature-Vector AVP is defined in [RFC5447] and contains a 64-bit flags field used to indicate supported capabilities to the AAA server. This document allocates a new capability flag bit according to the IANA rules in RFC 5447 [RFC5447].

MIP6特征向量AVP在[RFC5447]中定义,包含一个64位标志字段,用于指示AAA服务器支持的功能。本文档根据RFC 5447[RFC5447]中的IANA规则分配新的能力标志位。

INTER_MAG_ROUTING_SUPPORTED (0x0002000000000000)

支持的内部磁盘路由(0x0002000000000)

When set, this flag indicates support or authorization of Direct routing of IP packets between MNs anchored to different MAGs without involving any LMA.

设置时,此标志表示支持或授权在锚定到不同MAG的MN之间直接路由IP数据包,而不涉及任何LMA。

During the network access authentication and authorization procedure [RFC5779], this flag is set by the MAG or LMA in the MIP6-Feature-Vector AVP included in the request to indicate to the home AAA server (HAAA) that inter-MAG direct routing may be provided to the mobile node identified by the User-Name AVP. By setting the INTER_MAG_ROUTING_SUPPORTED flag in the response, the HAAA indicates to the MAG or LMA that direct routing of IP packets between this mobile node and another node anchored to a different MAG is authorized. The MAG and the LMA set also the INTER_MAG_ROUTING_SUPPORTED flag of the MIP6-Feature-Vector AVP in AA-R sent to the HAAA for requesting authorization of inter-MAG direct routing between the mobile nodes identified in the request by two distinct instances of the User-Name AVP. If this bit is set in

在网络接入认证和授权过程[RFC5779]期间,该标志由请求中包括的MIP6特征向量AVP中的MAG或LMA设置,以向家庭AAA服务器(HAAA)指示可以向由用户名AVP标识的移动节点提供MAG间直接路由。通过在响应中设置INTER_MAG_ROUTING_SUPPORTED标志,HAAA向MAG或LMA指示该移动节点与锚定到不同MAG的另一节点之间的IP分组的直接路由被授权。MAG和LMA还设置AA-R中的MIP6特征向量AVP的INTER-MAG-ROUTING-SUPPORTED标志,用于请求授权由用户名AVP的两个不同实例在请求中标识的移动节点之间的INTER-MAG-direct ROUTING。如果此位设置为

the returned MIP6-Feature-Vector AVP, the HAAA authorizes direct routing of packets between MNs anchored to different MAGs. When the INTER_MAG_ROUTING_SUPPORTED flag is cleared, either in request or response, it indicates that the procedures related to authorization of localized routing between MNs anchored to different MAGs is not supported or not authorized. MAG and LMA compliant to this specification MUST support this policy feature on a per-MN and per-subscription basis.

根据返回的MIP6特征向量AVP,HAAA授权在锚定到不同MAG的MN之间直接路由数据包。当在请求或响应中清除INTER_MAG_ROUTING_SUPPORTED标志时,它表示不支持或未授权与锚定到不同MAG的MN之间的本地化路由授权相关的过程。符合本规范的MAG和LMA必须在每个MN和每个订阅的基础上支持此策略功能。

5. Example Signaling Flows for Localized Routing Service Authorization
5. 本地化路由服务授权的信令流示例

Localized Routing Service Authorization can happen during the network access authentication procedure [RFC5779] before localized routing is initialized. In this case, the preauthorized pairs of LMA / prefix sets can be downloaded to Proxy Mobile IPv6 entities during the procedure from [RFC5779]. Localized routing can be initiated once the destination of a received packet matches one or more of the prefixes received during the procedure from [RFC5779].

在初始化本地化路由之前,可以在网络访问身份验证过程[RFC5779]中进行本地化路由服务授权。在这种情况下,预授权的LMA/前缀集对可以在过程中从[RFC5779]下载到代理移动IPv6实体。一旦接收到的数据包的目的地与[RFC5779]过程中接收到的一个或多个前缀匹配,就可以启动本地化路由。

Figure 2 shows an example scenario in which MAG1 acts as a Diameter client, processing the data packet from MN1 to MN2 and requesting authorization of localized routing (i.e., MAG-Initiated LR authorization). In this example scenario, MN1 and MN2 are attached to the same MAG and anchored to the different LMAs (i.e., scenario A12 described in [RFC6279]). In this case, MAG1 knows that MN2 belongs to a different LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA1 and LMA2). In order to set up a localized routing path with MAG2, MAG1 acts as Diameter client and sends an AA-Request message to the AAA server. The message contains an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set, two instances of the User-Name AVP [RFC6733] containing the identifiers of MN1 and MN2. In addition, the message may contain either:

图2显示了一个示例场景,其中MAG1充当Diameter客户端,处理从MN1到MN2的数据包,并请求本地化路由的授权(即,MAG发起的LR授权)。在此示例场景中,MN1和MN2连接到同一MAG并锚定到不同的LMA(即,[RFC6279]中描述的场景A12])。在这种情况下,MAG1知道MN2属于不同的LMA(这可以通过查找对应于MN1和MN2的绑定缓存条目并比较LMA1和LMA2的地址来确定)。为了使用MAG2建立本地化路由路径,MAG1充当Diameter客户端并向AAA服务器发送AA请求消息。该消息包含MIP6特征向量(MFV)AVP[RFC5447]的一个实例和本地MAG路由支持位([RFC5779],第5.5节)的设置,以及包含MN1和MN2标识符的用户名AVP[RFC6733]的两个实例。此外,消息可能包含以下内容之一:

- an instance of the MIP6-Home-Link-Prefix AVP [RFC5779] carrying the MN1's IPv4 address;

- 携带MN1的IPv4地址的MIP6归属链路前缀AVP[RFC5779]的实例;

- an instance of the PMIP6-IPv4-Home-Address AVP [RFC5779] carrying the MN1's home network prefix (MN-HNP).

- 携带MN1的家庭网络前缀(MN-HNP)的PMIP6-IPv4-Home-Address AVP[RFC5779]的实例。

The AAA server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the AAA server responds with a AAA message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set indicating that direct routing of IP packets between MNs anchored to the same MAG is authorized. MAG1 then knows that the localized

AAA服务器通过检查是否允许MN1和MN2使用本地化路由来授权本地化路由服务。如果是这样,AAA服务器响应AAA消息,该消息封装MIP6特征向量(MFV)AVP[RFC5447]的实例,并设置本地MAG路由支持位([RFC5779],第5.5节),指示在锚定到同一MAG的MN之间的IP包的直接路由被授权。MAG1随后知道

routing between MN1 and MN2 is allowed. Then, MAG1 sends the Request messages respectively to LMA1 and LMA2. The request message is the Localized Routing Initialization (LRI) message in Figure 2 and belongs to the Initial phase of the localized routing. LMA1 and LMA2 respond to MAG1 using the Localized Routing Acknowledge message (LRA in Figure 2) in accordance with [RFC6705].

允许在MN1和MN2之间进行路由。然后,MAG1分别向LMA1和LMA2发送请求消息。请求消息是图2中的本地化路由初始化(LRI)消息,属于本地化路由的初始阶段。根据[RFC6705],LMA1和LMA2使用本地化路由确认消息(图2中的LRA)响应MAG1。

In case of LRA_WAIT_TIME expiration [RFC6705], MAG1 should ask for authorization of localized routing again according to the procedure described above before the LRI is retransmitted up to a maximum of LRI_RETRIES.

在LRA_等待_时间到期[RFC6705]的情况下,MAG1应在LRI重新传输最多LRI_重试次数之前,根据上述程序再次请求授权本地化路由。

      +---+   +---+    +----+    +----+       +---+   +----+
      |MN2|   |MN1|    |MAG1|    |LMA1|       |AAA|   |LMA2|
      +-|-+   +-+-+    +-+--+    +-+--+       +-+-+   +-+--+
        |       |     Anchored     |            |       |
        o-----------------------------------------------o
        |       |     Anchored     |            |       |
        |       o------------------o            |       |
        |     Data[MN1->MN2]       |            |       |
        |       |------->|         |            |       |
        |       |        |  AA-Request(MFV, MN1,MN2)    |
        |       |        |--------------------> |       |
        |       |        |     AA-Answer(MFV)   |       |
        |       |        |<-------------------- |       |
        |       |        |   LRI   |            |       |
        |       |        |-------->|            |       |
        |       |        |         |   LRI      |       |
        |       |        |----------------------------->|
        |       |        |   LRA   |            |       |
        |       |        |<--------|            |       |
        |       |        |         |   LRA      |       |
        |       |        |<-----------------------------|
        
      +---+   +---+    +----+    +----+       +---+   +----+
      |MN2|   |MN1|    |MAG1|    |LMA1|       |AAA|   |LMA2|
      +-|-+   +-+-+    +-+--+    +-+--+       +-+-+   +-+--+
        |       |     Anchored     |            |       |
        o-----------------------------------------------o
        |       |     Anchored     |            |       |
        |       o------------------o            |       |
        |     Data[MN1->MN2]       |            |       |
        |       |------->|         |            |       |
        |       |        |  AA-Request(MFV, MN1,MN2)    |
        |       |        |--------------------> |       |
        |       |        |     AA-Answer(MFV)   |       |
        |       |        |<-------------------- |       |
        |       |        |   LRI   |            |       |
        |       |        |-------->|            |       |
        |       |        |         |   LRI      |       |
        |       |        |----------------------------->|
        |       |        |   LRA   |            |       |
        |       |        |<--------|            |       |
        |       |        |         |   LRA      |       |
        |       |        |<-----------------------------|
        

Figure 2: MAG-Initiated Localized Routing Authorization in A12

图2:A12中MAG发起的本地化路由授权

Figure 3 shows the second example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to a different MAG and anchored to the same LMA (i.e., A21 described in [RFC6279]), LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of the LMA corresponding to MN1 and LMA corresponding to MN2). In contrast with the signaling flow shown in Figure 2, it is LMA1 instead of MAG1 that initiates the setup of the localized routing path.

图3显示了第二个示例场景,其中LMA1充当Diameter客户端,处理从MN2到MN1的数据包,并请求本地化路由的授权。在这种情况下,MN1和MN2连接到不同的MAG并锚定到相同的LMA(即,[RFC6279]中描述的A21),LMA知道MN1和MN2属于相同的LMA(这可以通过查找对应于MN1和MN2的绑定缓存项并比较对应于MN1的LMA和对应于MN2的LMA的地址来确定)。与图2中所示的信令流相比,是LMA1而不是MAG1启动了本地化路由路径的设置。

The Diameter client in LMA1 sends an AA-Request message to the AAA server. The message contains an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct routing of IP packets between MNs anchored to different MAGs is supported and two instances of the User-Name AVP [RFC6733] containing identifiers of MN1 and MN2. The AAA server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the AAA server responds with an AA-Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating that direct routing of IP packets between MNs anchored to different MAGs is authorized. LMA1 then knows the localized routing is allowed. In a successful case, LMA1 responds to MAG1 in accordance with [RFC6705].

LMA1中的Diameter客户端向AAA服务器发送AA请求消息。该消息包含MIP6特征向量(MFV)AVP[RFC5447]的一个实例,其中设置了受支持的位(第4.5节),该位指示支持锚定到不同MAG的MN之间的IP数据包的直接路由,并且包含MN1和MN2标识符的用户名AVP[RFC6733]的两个实例。AAA服务器通过检查是否允许MN1和MN2使用本地化路由来授权本地化路由服务。如果是这样,AAA服务器用AA应答消息响应,该消息封装了MIP6特征向量(MFV)AVP[RFC5447]的实例,并设置了支持的位(第4.5节),指示在锚定到不同MAG的MN之间直接路由IP数据包已获授权。然后LMA1知道允许局部路由。在成功的情况下,LMA1根据[RFC6705]响应MAG1。

In the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask for authorization of localized routing again according to the procedure described above before the LRI is retransmitted up to a maximum of LRI_RETRIES.

在LRA_等待_时间到期[RFC6705]的情况下,LMA1应在LRI重传最多LRI_重试次数之前,根据上述程序再次请求授权本地化路由。

   +---+    +----+  +----+     +---+    +----+   +---+
   |MN1|    |MAG1|  |LMA1|     |AAA|    |MAG2|   |MN2|
   +-+-+    +-+--+  +-+--+     +-+-+    +-+--+   +-+-+
     |        |       |         Anchored  |        |
     |     Anchored   o-------------------+--------o
     o--------+-------o Data[MN2->MN1]    |        |
     |        |       |<-----    |        |        |
     |        |       |AA-Request(MFV,MN1,MN2)     |
     |        |       |--------->|        |        |
     |        |       |AA-Answer(MFV)     |        |
     |        |  LRI  |<---------|        |        |
     |        |<------|        LRI        |        |
     |        |  LRA  |------------------>|        |
     |        |------>|        LRA        |        |
     |        |       |<------------------|        |
        
   +---+    +----+  +----+     +---+    +----+   +---+
   |MN1|    |MAG1|  |LMA1|     |AAA|    |MAG2|   |MN2|
   +-+-+    +-+--+  +-+--+     +-+-+    +-+--+   +-+-+
     |        |       |         Anchored  |        |
     |     Anchored   o-------------------+--------o
     o--------+-------o Data[MN2->MN1]    |        |
     |        |       |<-----    |        |        |
     |        |       |AA-Request(MFV,MN1,MN2)     |
     |        |       |--------->|        |        |
     |        |       |AA-Answer(MFV)     |        |
     |        |  LRI  |<---------|        |        |
     |        |<------|        LRI        |        |
     |        |  LRA  |------------------>|        |
     |        |------>|        LRA        |        |
     |        |       |<------------------|        |
        

Figure 3: LMA-Initiated Localized Routing Authorization in A21

图3:A21中LMA发起的本地化路由授权

Figure 4 shows another example scenario, in which LMA1 acts as a Diameter client, processing the data packet from MN2 to MN1 and requesting the authorization of localized routing. In this scenario, MN1 and MN2 are attached to the same MAG and anchored to the same LMA (i.e., A11 described in [RFC6279]), the LMA knows that MN1 and MN2 belong to the same LMA (which can be determined by looking up the binding cache entries corresponding to MN1 and MN2 and comparing the addresses of LMA corresponding to MN1 and LMA corresponding to MN2).

图4显示了另一个示例场景,其中LMA1充当Diameter客户端,处理从MN2到MN1的数据包,并请求本地化路由的授权。在这种情况下,MN1和MN2连接到相同的MAG并锚定到相同的LMA(即,[RFC6279]中描述的A11),LMA知道MN1和MN2属于相同的LMA(可通过查找对应于MN1和MN2的绑定缓存项并比较对应于MN1的LMA和对应于MN2的LMA的地址来确定)。

The Diameter client in LMA1 sends an AA-Request message to the AAA server. The message contains an instance of the MIP6-Feature-Vector AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit set and two instances of the User-Name AVP [RFC6733] containing the identifiers MN1 and MN2. The AAA server authorizes the localized routing service by checking if MN1 and MN2 are allowed to use localized routing. If so, the AAA server responds with an AA-Answer message encapsulating an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set indicating that direct routing of IP packets between MNs anchored to the same MAG is authorized. LMA1 then knows the localized routing is allowed and responds to MAG1 for localized routing in accordance with [RFC6705].

LMA1中的Diameter客户端向AAA服务器发送AA请求消息。该消息包含一个MIP6特征向量AVP[RFC5447]的实例,该实例具有本地\u MAG\u ROUTING \u支持的位集,以及两个用户名AVP[RFC6733]的实例,其中包含标识符MN1和MN2。AAA服务器通过检查是否允许MN1和MN2使用本地化路由来授权本地化路由服务。如果是这样,AAA服务器响应AA应答消息,该消息封装了MIP6特征向量(MFV)AVP[RFC5447]的实例,并设置了本地MAG路由支持位([RFC5779],第5.5节),指示授权在锚定到同一MAG的MN之间直接路由IP数据包。然后LMA1知道允许本地化路由,并根据[RFC6705]响应MAG1进行本地化路由。

In the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask for authorization of localized routing again according to the procedure described above before the LRI is retransmitted up to a maximum of LRI_RETRIES.

在LRA_等待_时间到期[RFC6705]的情况下,LMA1应在LRI重传最多LRI_重试次数之前,根据上述程序再次请求授权本地化路由。

   +---+  +---+    +----+  +----+     +---+
   |MN2|  |MN1|    |MAG1|  |LMA1|     |AAA|
   +-+-+  +-+-+    +-+--+  +-+--+     +-|-+
     |      |     Anchored   |          |
     o-----------------------o          |
     |      |     Anchored   |          |
     |      o--------+-------o Data[MN2->MN1]
     |      |        |       |<-----    |
     |      |        |       |AA-Request(MFV,MN1,MN2)
     |      |        |       |--------->|
     |      |        |       |AA-Answer(MFV)
     |      |        |  LRI  |<---------|
     |      |        |<------|          |
     |      |        |  LRA  |          |
     |      |        |------>|          |
        
   +---+  +---+    +----+  +----+     +---+
   |MN2|  |MN1|    |MAG1|  |LMA1|     |AAA|
   +-+-+  +-+-+    +-+--+  +-+--+     +-|-+
     |      |     Anchored   |          |
     o-----------------------o          |
     |      |     Anchored   |          |
     |      o--------+-------o Data[MN2->MN1]
     |      |        |       |<-----    |
     |      |        |       |AA-Request(MFV,MN1,MN2)
     |      |        |       |--------->|
     |      |        |       |AA-Answer(MFV)
     |      |        |  LRI  |<---------|
     |      |        |<------|          |
     |      |        |  LRA  |          |
     |      |        |------>|          |
        

Figure 4: LMA-Initiated Localized Routing Authorization in A11

图4:A11中LMA发起的本地化路由授权

6. Security Considerations
6. 安全考虑

The security considerations for the Diameter Network Access Server Requirements (NASREQ) [RFC7155] and Diameter Proxy Mobile IPv6 [RFC5779] applications are also applicable to this document.

Diameter网络访问服务器要求(NASREQ)[RFC7155]和Diameter代理移动IPv6[RFC5779]应用程序的安全注意事项也适用于本文档。

The service authorization solicited by the MAG or the LMA relies upon the existing trust relationship between the MAG/LMA and the AAA server.

MAG或LMA请求的服务授权依赖于MAG/LMA和AAA服务器之间的现有信任关系。

An authorized MAG could, in principle, track the movement of any participating mobile nodes at the level of the MAG to which they are anchored. If such a MAG were compromised, or under the control of a bad actor, then such tracking could represent a privacy breach for the set of tracked mobile nodes. In such a case, the traffic pattern from the compromised MAG might be notable, so monitoring for, e.g., excessive queries from MAGs, might be worthwhile.

原则上,授权MAG可以在其所锚定的MAG级别上跟踪任何参与移动节点的移动。如果这样一个MAG被破坏,或者在一个坏角色的控制下,那么这样的跟踪可能代表对被跟踪移动节点集的隐私侵犯。在这种情况下,来自受损MAG的流量模式可能是值得注意的,因此监视(例如)来自MAG的过多查询可能是值得的。

7. IANA Considerations
7. IANA考虑

This specification defines a new value in the "Mobility Capability Registry" [RFC5447] for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (see Section 4.4).

本规范在“移动能力注册表”[RFC5447]中定义了一个新值,用于支持MIP6特征向量AVP:INTER_MAG_ROUTING_(参见第4.4节)。

8. Contributors
8. 贡献者

Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document.

Paulo Loureiro、Jinwei Xia和Yungui Wang都对本文件的早期版本做出了贡献。

9. Acknowledgements
9. 致谢

The authors would like to thank Lionel Morand, Marco Liebsch, Carlos Jesus Bernardos Cano, Dan Romascanu, Elwyn Davies, Basavaraj Patil, Ralph Droms, Stephen Farrel, Robert Sparks, Benoit Claise, and Abhay Roy for their valuable comments and suggestions on this document.

作者要感谢莱昂内尔·莫兰德、马可·利伯什、卡洛斯·耶稣·贝尔纳多·卡诺、丹·罗马斯卡努、埃尔温·戴维斯、巴萨瓦拉伊·帕蒂尔、拉尔夫·德罗姆斯、斯蒂芬·法雷尔、罗伯特·斯帕克斯、贝诺特·克莱斯和阿比·罗伊对本文件提出的宝贵意见和建议。

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[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月。

[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.

[RFC5447]Korhonen,J.,Bournelle,J.,Tschofenig,H.,Perkins,C.,和K.Chowdhury,“Diameter移动IPv6:支持网络访问服务器到Diameter服务器的交互”,RFC 5447,2009年2月。

[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", RFC 5779, February 2010.

[RFC5779]Korhonen,J.,Bournelle,J.,Chowdhury,K.,Muhanna,A.,和U.Meyer,“Diameter代理移动IPv6:移动接入网关和本地移动锚与Diameter服务器的交互”,RFC 5779,2010年2月。

[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.

[RFC5844]Wakikawa,R.和S.Gundavelli,“代理移动IPv6的IPv4支持”,RFC 5844,2010年5月。

[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012.

[RFC6705]Krishnan,S.,Koodli,R.,Loureiro,P.,Wu,Q.,和A.Dutta,“代理移动IPv6的本地化路由”,RFC 67052012年9月。

[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.

[RFC6733]Fajardo,V.,Arkko,J.,Loughney,J.,和G.Zorn,“直径基准协议”,RFC 67332012年10月。

[RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, April 2014.

[RFC7155]Zorn,G.,编辑,“Diameter网络访问服务器应用”,RFC 7155,2014年4月。

10.2. Informative References
10.2. 资料性引用

[RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011.

[RFC6279]Liebsch,M.,Jeong,S.,和Q.Wu,“代理移动IPv6(PMIPv6)本地化路由问题声明”,RFC 6279,2011年6月。

Authors' Addresses

作者地址

Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand

格伦佐恩网络禅宗227/358泰国曼谷Thanon Sanphawut Bang Na 10260

   Phone: +66 (0) 87-040-4617
   EMail: glenzorn@gmail.com
        
   Phone: +66 (0) 87-040-4617
   EMail: glenzorn@gmail.com
        

Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China

中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司210012

   Phone: +86-25-56623633
   EMail: bill.wu@huawei.com
        
   Phone: +86-25-56623633
   EMail: bill.wu@huawei.com
        

Jouni Korhonen Broadcom Porkkalankatu 24 FIN-00180 Helsinki Finland

Jouni Korhonen Broadcom Porkkalankatu 24 FIN-00180芬兰赫尔辛基

   EMail: jouni.nospam@gmail.com
        
   EMail: jouni.nospam@gmail.com