Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6705 Ericsson
Category: Standards Track R. Koodli
ISSN: 2070-1721 Cisco Systems
P. Loureiro
NEC
Q. Wu
Huawei
A. Dutta
NIKSUN
September 2012
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6705 Ericsson
Category: Standards Track R. Koodli
ISSN: 2070-1721 Cisco Systems
P. Loureiro
NEC
Q. Wu
Huawei
A. Dutta
NIKSUN
September 2012
Localized Routing for Proxy Mobile IPv6
代理移动IPv6的本地化路由
Abstract
摘要
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism.
代理移动IPv6（PMIPv6）是一种基于网络的移动性管理协议，它支持主机的IP移动性，而无需参与任何移动性相关信令。PMIPv6要求所有通信都通过本地移动锚。由于这可能是次优的，本地化路由（LR）允许连接到相同或不同移动接入网关（MAG）的移动节点（MN）通过使用网关之间的本地化转发或直接隧道来路由流量。本文档提出了代理移动IPv6域内移动访问网关之间的本地化路由的启动、利用和终止机制。它定义了两个新的信令消息，本地化路由发起（LRI）和本地路由确认（LRA），用于实现该机制。
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/rfc6705.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6705.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Conventions Used in This Document ...............................3
3. Initiation of Localized Routing .................................3
3.1. MAG Behavior ...............................................4
3.2. LMA Behavior ...............................................4
4. Teardown of Localized Routing ...................................4
5. Scenario A11: Two MNs Attached to the Same MAG and LMA ..........4
5.1. Handover Considerations ....................................6
6. Scenario A21: Two MNs Attached to Different MAGs but the
Same LMA ........................................................7
6.1. Handover Considerations ....................................9
6.2. Tunneling between the MAGs .................................9
7. Scenario A12: Two MNs Attached to the Same MAG with
Different LMAs .................................................10
7.1. Handover Considerations ...................................12
8. Scenario A22: Two MNs Attached to Different MAGs with
Different LMAs .................................................13
9. IPv4 Support in Localized Routing ..............................13
10. Message Formats ...............................................13
10.1. Localized Routing Initiation (LRI) .......................14
10.2. Localized Routing Acknowledgment (LRA) ...................15
11. New Mobility Option ...........................................16
11.1. MAG IPv6 Address .........................................16
12. Configuration Variables .......................................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
15. Contributors ..................................................18
16. Acknowledgments ...............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Initiation of Localized Routing .................................3
3.1. MAG Behavior ...............................................4
3.2. LMA Behavior ...............................................4
4. Teardown of Localized Routing ...................................4
5. Scenario A11: Two MNs Attached to the Same MAG and LMA ..........4
5.1. Handover Considerations ....................................6
6. Scenario A21: Two MNs Attached to Different MAGs but the
Same LMA ........................................................7
6.1. Handover Considerations ....................................9
6.2. Tunneling between the MAGs .................................9
7. Scenario A12: Two MNs Attached to the Same MAG with
Different LMAs .................................................10
7.1. Handover Considerations ...................................12
8. Scenario A22: Two MNs Attached to Different MAGs with
Different LMAs .................................................13
9. IPv4 Support in Localized Routing ..............................13
10. Message Formats ...............................................13
10.1. Localized Routing Initiation (LRI) .......................14
10.2. Localized Routing Acknowledgment (LRA) ...................15
11. New Mobility Option ...........................................16
11.1. MAG IPv6 Address .........................................16
12. Configuration Variables .......................................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
15. Contributors ..................................................18
16. Acknowledgments ...............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
Proxy Mobile IPv6 [RFC5213] describes the protocol operations to maintain reachability and session persistence for a Mobile Node (MN) without the explicit participation from the MN in signaling operations at the Internet Protocol (IP) layer. In order to facilitate such network-based mobility, the PMIPv6 protocol defines a Mobile Access Gateway (MAG), which acts as a proxy for the Mobile IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA), which acts similar to a Home Agent. The LMA and the MAG establish a bidirectional tunnel for forwarding all data traffic belonging to the Mobile Nodes. In the case where both endpoints are located in the same PMIPv6 domain, this can be suboptimal and result in increased delay and congestion in the network. Moreover, it increases transport costs and traffic load at the LMA.
代理移动IPv6[RFC5213]描述了在没有移动节点（MN）明确参与互联网协议（IP）层信令操作的情况下，保持移动节点（MN）的可达性和会话持久性的协议操作。为了促进这种基于网络的移动性，PMIPv6协议定义了作为移动IPv6[RFC6275]信令的代理的移动接入网关（MAG）和作为类似于归属代理的本地移动性锚（LMA）。LMA和MAG建立用于转发属于移动节点的所有数据业务的双向隧道。如果两个端点位于同一个PMIPv6域中，这可能是次优的，并导致网络中的延迟和拥塞增加。此外，它增加了LMA的运输成本和交通负荷。
To overcome these issues, localized routing can be used to allow nodes attached to the same or different MAGs to directly exchange traffic by using localized forwarding or a direct tunnel between the gateways. [RFC6279] defines the problem statement for PMIPv6 localized routing. This document describes a solution for PMIPv6 localized routing between two MNs in the same PMIPv6 domain. The protocol specified here assumes that each MN is attached to a MAG and that each MN's MAG has established a binding for the attached MN at its selected LMA according to [RFC5213]. The protocol builds on the scenarios defined in [RFC6279].
为了克服这些问题，可以使用本地化路由来允许连接到相同或不同MAG的节点通过使用网关之间的本地化转发或直接隧道来直接交换流量。[RFC6279]定义PMIPv6本地化路由的问题陈述。本文档描述了同一PMIPv6域中两个MN之间的PMIPv6本地化路由解决方案。此处指定的协议假设每个MN连接到MAG，并且每个MN的MAG已根据[RFC5213]在其所选LMA处为连接的MN建立绑定。该协议以[RFC6279]中定义的场景为基础。
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]中所述进行解释。
This document also uses the terminology defined in Section 2 of [RFC6279].
本文件还使用了[RFC6279]第2节中定义的术语。
Since the traffic to be localized passes through both the LMA and the MAGs, it is possible, at least in some scenarios, for either of them to initiate Localized Routing (LR). In order to eliminate ambiguity, the protocol described in this document selects the initiator of LR based on the rules below.
由于要本地化的业务同时通过LMA和mag，因此至少在某些情况下，它们中的任何一个都有可能发起本地化路由（LR）。为了消除歧义，本文档中描述的协议根据以下规则选择LR的发起方。
The MAG MUST initiate LR if both of the communicating MNs are attached to it and the MNs are anchored at different LMAs. The MAG MUST NOT initiate LR in any other case.
如果两个通信MN都连接到MAG并且MN锚定在不同的LMA上，则MAG必须启动LR。在任何其他情况下，MAG不得启动LR。
The LMA MUST initiate LR if both of the communicating MNs are anchored to it. The LMA MUST NOT initiate LR in any other case.
如果两个通信MN都锚定到LMA，则LMA必须启动LR。在任何其他情况下，LMA不得启动LR。
The use of localized routing is not persistent. Localized routing has a defined lifetime as specified by the initiator; upon expiry, the forwarding MUST revert to using bidirectional tunneling. When localized routing ceases, the corresponding Localized Routing Entries (LREs) MUST be removed.
本地化路由的使用不是持久性的。本地化路由具有启动器指定的定义生存期；到期后，转发必须恢复为使用双向隧道。当本地化路由停止时，必须删除相应的本地化路由条目（LRE）。
If the initiator of LR wishes to terminate localized routing before the expiry of the lifetime specified in the LRI message, it MUST do so by sending a new LRI message with the lifetime set to zero.
如果LR的发起方希望在LRI消息中指定的生存期到期之前终止本地化路由，则必须发送一条新的LRI消息，并将生存期设置为零。
In this scenario, the two Mobile Nodes involved in communication are attached to a single MAG and both are anchored at the same LMA as shown in Figure 1.
在该场景中，通信中涉及的两个移动节点连接到单个MAG，并且都锚定在相同的LMA上，如图1所示。
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1
图1
The LMA initiates a localized routing session by detecting traffic between two MNs attached to the same MAG. The exact traffic identification mechanism is not specified in this document and is left open for implementations and specific deployments. An example trigger could be that an application-layer signaling entity detects the possibility of localized routing and notifies the LMA about the two endpoints, and the LMA determines that the two endpoints are attached to the same MAG. Such a trigger mechanism offers localized routing at the granularity of an individual application session, providing flexibility in usage. It is also possible that one of the mobility entities (LMA or MAG) could decide to initiate localized routing based on configured policy. Please note that a MAG implementing the protocol specified in this document will not dynamically initiate LR in the same LMA case (i.e., by sending an LRI), but can statically initiate LR based on the EnableMAGLocalRouting configuration variable specified in [RFC5213].
LMA通过检测连接到同一MAG的两个MN之间的通信量来启动本地化路由会话。本文档中未指定确切的通信量标识机制，并对实施和特定部署保持开放。一个示例触发器可以是应用层信令实体检测本地化路由的可能性，并将两个端点的情况通知LMA，LMA确定两个端点连接到同一MAG。这种触发器机制在单个应用会话的粒度上提供本地化路由，提供灵活的使用。移动实体（LMA或MAG）中的一个也可能决定基于所配置的策略发起局部路由。请注意，在相同的LMA情况下（即，通过发送LRI），实现本文件中指定协议的MAG不会动态启动LR，但可以基于[RFC5213]中指定的EnableMAGLocalRouting配置变量静态启动LR。
+----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |LMA |
+----+ +----+ +----+ +----+
| | | |
| data | data |
|<--------------------->|<------------->|
| | | |
| | data | data |
| |<--------->|<------------->|
| | | LR decision
| | | LRI(Opt1) |
| | |<--------------|
| | | |
| | | LRA(Opt2) |
| | |-------------->|
| | | |
| data | |
|<--------------------->| |
| | | |
| | data | |
| |<--------->| |
| | | |
| | | |
+----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |LMA |
+----+ +----+ +----+ +----+
| | | |
| data | data |
|<--------------------->|<------------->|
| | | |
| | data | data |
| |<--------->|<------------->|
| | | LR decision
| | | LRI(Opt1) |
| | |<--------------|
| | | |
| | | LRA(Opt2) |
| | |-------------->|
| | | |
| data | |
|<--------------------->| |
| | | |
| | data | |
| |<--------->| |
| | | |
| | | |
Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
Opt1:MN1-ID，MN1-HNP，MN2-ID，MN2-HNP Opt2:U=0，MN1-ID，MN1-HNP，MN2-ID，MN2-HNP
where U is the flag defined in Section 10.2.
其中U是第10.2节中定义的标志。
Figure 2
图2
After detecting a possibility for localized routing, the LMA SHOULD construct an LRI message that is used to signal the intent to initiate localized routing and to convey parameters for the same. This is a Mobility Header message and it MUST contain the MN-Identifier (MN-ID) and the Home Network Prefix (HNP) (as Mobility Header options) for each of the MNs involved. The LMA MUST then send the LRI message to the MAG (MAG1) where the two MNs are attached. The initiation of the LR procedure is shown in Figure 2.
在检测到局部路由的可能性之后，LMA应当构造LRI消息，该LRI消息用于表示发起局部路由的意图并传送用于该意图的参数。这是一个移动报头消息，它必须包含涉及的每个MN的MN标识符（MN-ID）和家庭网络前缀（HNP）（作为移动报头选项）。然后，LMA必须将LRI消息发送到连接两个MN的MAG（MAG1）。LR程序的启动如图2所示。
The MAG (MAG1) MUST verify the attachment status of the two MNs locally by checking the binding cache. The MAG MUST then verify if the EnableMAGLocalRouting flag is set to 1. If it is not, the MAG has not been configured to allow localized routing, and it MUST reject the LRI and MUST send an LRA with Status code "Localized Routing Not Allowed". Please note that this does not update behavior specified in [RFC5213] but merely implements the LMA enforcement specified in Section 6.10.3 of [RFC5213]. If the MAG is configured to allow localized routing, it MUST then create LREs for each direction of the communication between the two MNs. The exact form of the forwarding entries is left for the implementations to decide; however, they SHOULD contain the HNP corresponding to the destination IP address and a next-hop identifier (e.g., the layer-2 address of the next hop). These LREs MUST override the Binding Update List (BUL) entries for the specific HNPs identified in the LRI message. Hence, all traffic matching the HNPs is forwarded locally.
MAG（MAG1）必须通过检查绑定缓存在本地验证两个MN的连接状态。然后，MAG必须验证EnableMAGLocalRouting标志是否设置为1。如果不是，则MAG未配置为允许本地化路由，它必须拒绝LRI，并且必须发送状态代码为“不允许本地化路由”的LRA。请注意，这不会更新[RFC5213]中规定的行为，而只是实现[RFC5213]第6.10.3节中规定的LMA实施。如果MAG配置为允许本地化路由，则必须为两个MN之间的每个通信方向创建LRE。转发条目的确切形式由实现决定；然而，它们应该包含对应于目的地IP地址的HNP和下一跳标识符（例如，下一跳的第2层地址）。这些LRE必须覆盖LRI消息中标识的特定HNP的绑定更新列表（BUL）条目。因此，所有与HNP匹配的流量都在本地转发。
If the MAG is unable to deliver packets using the LREs, it is possible that one of the MNs is no longer attached to the MAG. Hence, the MAG MUST fall back to using the BUL entry, and the LMA MUST forward the received packets using its Binding Cache Entry (BCE).
如果MAG无法使用LRE传送数据包，则有可能其中一个MN不再连接到MAG。因此，MAG必须退回到使用BUL条目，LMA必须使用其绑定缓存条目（BCE）转发接收到的数据包。
After processing the LRI message, the MAG MUST respond with a Local Routing Acknowledgment (LRA) message. This Mobility Header message MUST also include the MN-ID and the HNP for each of the communicating MNs, as well as an appropriate Status code indicating the outcome of LRI processing. Status code 0 indicates localized routing was successfully offered by the MAG. Any other value for Status code indicates the reason for the failure to offer localized routing service. When Status code is 0, the LMA sets a flag in the BCE corresponding to the HNPs to record that localized routing is in progress for that HNP.
处理LRI消息后，MAG必须使用本地路由确认（LRA）消息进行响应。该移动性报头消息还必须包括每个通信MN的MN-ID和HNP，以及指示LRI处理结果的适当状态码。状态代码0表示MAG已成功提供本地化路由。状态代码的任何其他值表示无法提供本地化路由服务的原因。当状态代码为0时，LMA在BCE中设置与HNP对应的标志，以记录该HNP正在进行本地化路由。
If one of the MNs, say MN1, detaches from the MAG and attaches to another MAG (say nMAG), the localized routing state needs to be re-established. When the LMA receives the PBU from nMAG for MN1, it
如果其中一个MN（例如MN1）从MAG分离并连接到另一个MAG（例如nMAG），则需要重新建立本地化路由状态。当LMA从nMAG接收MN1的PBU时，它
will see that localized routing is active for MN1. The LMA MUST hence initiate LR at nMAG and update the LR state of pMAG. After the handover completes, LR will resemble Scenario A21. The pMAG MUST follow the forwarding rules described in Section 6.10.5 of [RFC5213] and decide that it will no longer perform LR for MN1.
将看到MN1的本地化路由处于活动状态。因此，LMA必须在nMAG处启动LR，并更新pMAG的LR状态。移交完成后，LR将类似于场景A21。pMAG必须遵守[RFC5213]第6.10.5节所述的转发规则，并决定不再对MN1执行LR。
The LMA may choose to support local forwarding to Mobile Nodes attached to two different MAGs within a single PMIPv6 domain.
LMA可以选择支持到连接到单个PMIPv6域内的两个不同mag的移动节点的本地转发。
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
+----+-----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
+----+-----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 3
图3
As earlier, the LMA initiates LR as a response to some trigger mechanism. In this case, however, it MUST send two separate LRI messages to the two MAGs. In addition to the MN-ID and the HNP options, each LRI message MUST contain the IP address of the counterpart MAG. When the MAG IP address option is present, each MAG MUST create a local forwarding entry such that the packets for the MN attached to the remote MAG are sent over a tunnel associated with that remote MAG. The tunnel between the MAGs is assumed to be established following the considerations mentioned in Section 6.2.
如前所述，LMA发起LR作为对某些触发机制的响应。但是，在这种情况下，它必须向两个MAG发送两条单独的LRI消息。除MN-ID和HNP选项外，每个LRI消息必须包含对应MAG的IP地址。当存在MAG IP地址选项时，每个MAG必须创建一个本地转发条目，以便连接到远程MAG的MN的数据包通过与该远程MAG相关联的隧道发送。假定MAG之间的隧道是根据第6.2节中提到的考虑因素建立的。
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |LMA |
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data |
|<--------------------->|<----------------------->|
| | | | |
| | data | data |
| |<--------------------->|<----------->|
| | | | |
| | | | |
| | | LRI(Opt1) |
| | |<------------------------|
| | | | |
| | | | LRI(Opt2) |
| | | |<------------|
| | | | |
| | | LRA(Opt3) |
| | |------------------------>|
| | | | |
| | | | LRA(Opt4) |
| | | |------------>|
| | | | |
| | | | |
| | | | |
| data | data | |
|<--------------------->|<--------->| |
| | | | |
| | data | |
| |<--------------------->| |
| | | | |
| | | | |
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |LMA |
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data |
|<--------------------->|<----------------------->|
| | | | |
| | data | data |
| |<--------------------->|<----------->|
| | | | |
| | | | |
| | | LRI(Opt1) |
| | |<------------------------|
| | | | |
| | | | LRI(Opt2) |
| | | |<------------|
| | | | |
| | | LRA(Opt3) |
| | |------------------------>|
| | | | |
| | | | LRA(Opt4) |
| | | |------------>|
| | | | |
| | | | |
| | | | |
| data | data | |
|<--------------------->|<--------->| |
| | | | |
| | data | |
| |<--------------------->| |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address
Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address
where U is the flag defined in Section 10.2.
其中U是第10.2节中定义的标志。
Figure 4
图4
In this case, each MAG responds to the LRI with an LRA message. All subsequent packets are routed between the MAGs locally, without traversing the LMA. If one of the MAGs (say MAG1) responds with a successful LRA (Status value is zero) and the other (say MAG2)
在这种情况下，每个MAG用LRA消息响应LRI。所有后续数据包在本地MAG之间路由，而不穿过LMA。如果其中一个MAG（如MAG1）响应成功的LRA（状态值为零），另一个MAG（如MAG2）
responds with an error (Status value is non-zero), LR will still be performed in one direction (MN1->MAG1->MAG2->MN2), but the packets flowing the other way will take the LMA path (MN2->MAG2->LMA->MAG1->MN1).
响应错误（状态值为非零），LR仍将在一个方向（MN1->MAG1->MAG2->MN2）上执行，但流向另一方向的数据包将采用LMA路径（MN2->MAG2->LMA->MAG1->MN1）。
The protocol does not require any synchronization between the MAGs before local forwarding begins. Each MAG begins its local forwarding independent of the other.
在本地转发开始之前，协议不要求MAG之间进行任何同步。每个MAG独立于其他MAG开始其本地转发。
No synchronization between the MAGs is required because each MAG initiates LR in one direction. After the LMA instructs MAG1 to initiate LR, packets from MN1 to MN2 will take the path MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path MN2->MAG2->LMA->MAG1->MN1 until the LMA instructs MAG2 to initiate LR as well. A MAG will forward a packet towards either another MAG or its own LMA; therefore, there would be no duplication of packets.
由于每个MAG在一个方向上启动LR，因此不需要在MAG之间进行同步。在LMA指示MAG1启动LR后，从MN1到MN2的数据包将采用路径MN1->MAG1->MAG2->MN2，而从MN2到MN1的数据包将采用路径MN2->MAG2->LMA->MAG1->MN1，直到LMA也指示MAG2启动LR。MAG将向另一MAG或其自己的LMA转发分组；因此，数据包不会重复。
If one of the MNs, say MN1, detaches from its current MAG (in this case MAG1) and attaches to another MAG (say nMAG1), the localized routing state needs to be re-established. When the LMA receives the PBU from nMAG1 for MN1, it will see that localized routing is active for MN1. The LMA MUST then initiate LR at nMAG1 and update the LR state of MAG2 to use nMAG1 instead of MAG1.
如果其中一个MN（例如MN1）与其当前MAG（在本例中为MAG1）分离并连接到另一个MAG（例如nMAG1），则需要重新建立本地化路由状态。当LMA从MN1的nMAG1接收PBU时，它将看到MN1的本地化路由处于活动状态。然后，LMA必须在nMAG1处启动LR，并更新MAG2的LR状态，以使用nMAG1而不是MAG1。
In order to support localized routing, both MAGs SHOULD support the following encapsulation modes for the user packets, which are also defined for the tunnel between the LMA and MAG:
为了支持本地化路由，两个MAG都应支持用户分组的以下封装模式，这些封装模式也为LMA和MAG之间的隧道定义：
o IPv4-or-IPv6-over-IPv6 [RFC5844]
o IPv4-or-IPv6-over-IPv6[RFC5844]
o IPv4-or-IPv6-over-IPv4 [RFC5844]
o IPv4-or-IPv6-over-IPv4[RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP[RFC5844]
o TLV-header UDP tunneling [RFC5845]
o TLV头UDP隧道[RFC5845]
o Generic Routing Encapsulation (GRE) tunneling with or without GRE key(s) [RFC5845]
o 带或不带GRE密钥的通用路由封装（GRE）隧道[RFC5845]
MAG1 and MAG2 MUST use the same tunneling mechanism for the data traffic tunneled between them. The encapsulation mode to be employed SHOULD be configurable. It is RECOMMENDED that:
MAG1和MAG2之间的数据传输必须使用相同的隧道机制。要采用的封装模式应该是可配置的。建议：
1. As the default behavior, the inter-MAG tunnel uses the same encapsulation mechanism as that being used for the PMIPv6 tunnel between the LMA and the MAGs. MAG1 and MAG2 automatically start using the same encapsulation mechanism without a need for a special configuration on the MAGs or a dynamic tunneling mechanism negotiation between them.
1. 作为默认行为，MAG间隧道使用与LMA和MAG之间PMIPv6隧道相同的封装机制。MAG1和MAG2使用相同的封装机制自动启动，而无需在MAG上进行特殊配置或它们之间的动态隧道机制协商。
2. Configuration on the MAGs can override the default mechanism specified in Option 1 above. MAG1 and MAG2 MUST be configured with the same mechanism, and this configuration is most likely to be uniform throughout the PMIPv6 domain. If the packets on the PMIPv6 tunnel cannot be uniquely mapped onto the configured inter-MAG tunnel, this scenario is not applicable, and Option 3 below SHOULD directly be applied.
2. MAG上的配置可以覆盖上述选项1中指定的默认机制。MAG1和MAG2必须使用相同的机制进行配置，并且此配置很可能在整个PMIPv6域中是一致的。如果PMIPv6隧道上的数据包无法唯一映射到配置的MAG间隧道，则此场景不适用，应直接应用下面的选项3。
3. An implicit or explicit tunnel negotiation mechanism between the MAGs can override the default mechanism specified in Option 1 above. The employed tunnel negotiation mechanism is outside the scope of this document.
3. MAG之间的隐式或显式隧道协商机制可以覆盖上述选项1中指定的默认机制。所采用的隧道协商机制不在本文件范围内。
In this scenario, both the MNs are attached to the same MAG, but are
anchored at two different LMAs. MN1 is anchored at LMA1, and MN2 is
anchored at LMA2. Note that the two LMAs are part of the same
Provider Domain.
Internet
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+------------------+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
In this scenario, both the MNs are attached to the same MAG, but are
anchored at two different LMAs. MN1 is anchored at LMA1, and MN2 is
anchored at LMA2. Note that the two LMAs are part of the same
Provider Domain.
Internet
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+------------------+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 5
图5
Hence, neither LMA has a means to determine that the two Mobile Nodes are attached to the same MAG. Only the MAG can possibly determine that the two Mobile Nodes involved in communication are attached to it. Therefore, localized routing MUST be initiated by the MAG.
因此，两个LMA都没有方法确定两个移动节点连接到同一MAG。只有MAG可能确定参与通信的两个移动节点连接到它。因此，本地化路由必须由MAG启动。
The MAG sends an LRI message containing the MN-ID, HNP, and the counterpart LMA address to each LMA. Each LMA makes a decision to support local forwarding independently based on configured policy for the corresponding LMA. Each LMA MUST respond to the LRI message with an LRA message. If the initiation of LR on the LMA was successful, the Status value in the received LRA would be set to zero. After the MAG receives both the LRA messages, each with the Status value set to zero (success) from the two different LMAs, the MAG will conclude that it can provide local forwarding support for the two Mobile Nodes.
MAG向每个LMA发送包含MN-ID、HNP和对应LMA地址的LRI消息。每个LMA根据为相应LMA配置的策略独立地做出支持本地转发的决策。每个LMA必须使用LRA消息响应LRI消息。如果LMA上的LR启动成功，则接收到的LRA中的状态值将设置为零。在MAG从两个不同的LMA接收到两个LRA消息（每个消息的状态值设置为零（成功））后，MAG将得出结论，它可以为两个移动节点提供本地转发支持。
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG | |LMA1| |LMA2|
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data | data |
|<--------------------->|<--------->|<----------->|
| | | | |
| | data | data |
| |<--------->|<----------------------->|
| | | | |
| | | | |
| | | LRI(Opt1) | |
| | |---------->| |
| | | | |
| | | LRI(Opt2) |
| | |------------------------>|
| | | | |
| | | LRA(Opt3) | |
| | |<----------| |
| | | | |
| | | LRA(Opt4) |
| | |<------------------------|
| | | | |
| | | | |
| | | | |
| data | | |
|<--------------------->| | |
| | | | |
| | data | | |
| |<--------->| | |
| | | | |
| | | | |
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG | |LMA1| |LMA2|
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data | data |
|<--------------------->|<--------->|<----------->|
| | | | |
| | data | data |
| |<--------->|<----------------------->|
| | | | |
| | | | |
| | | LRI(Opt1) | |
| | |---------->| |
| | | | |
| | | LRI(Opt2) |
| | |------------------------>|
| | | | |
| | | LRA(Opt3) | |
| | |<----------| |
| | | | |
| | | LRA(Opt4) |
| | |<------------------------|
| | | | |
| | | | |
| | | | |
| data | | |
|<--------------------->| | |
| | | | |
| | data | | |
| |<--------->| | |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP
Opt2: MN2-ID,MN2-HNP
Opt3: U=0,MN1-ID,MN1-HNP
Opt4: U=0,MN2-ID,MN2-HNP
Opt1: MN1-ID,MN1-HNP
Opt2: MN2-ID,MN2-HNP
Opt3: U=0,MN1-ID,MN1-HNP
Opt4: U=0,MN2-ID,MN2-HNP
where U is the flag defined in Section 10.2.
其中U是第10.2节中定义的标志。
Figure 6
图6
If one of the MNs, say MN1, detaches from its current MAG (in this case MAG1) and attaches to another MAG (say nMAG1), the current MAG MUST immediately stop using the LRE and MUST send all packets originated by the other MN (MN2) towards its LMA (in this case LMA2).
如果其中一个MN（例如MN1）从其当前MAG（在本例中为MAG1）分离并连接到另一个MAG（例如nMAG1），则当前MAG必须立即停止使用LRE，并且必须向其LMA（在本例中为LMA2）发送由另一个MN（MN2）发起的所有分组。
This scenario will not be covered in this document since PMIPv6 does not define any form of inter-LMA communication. When a supported scenario, such as Scenario A12, morphs into Scenario A22, the node that initiated the localized routing session MUST tear it down in order to prevent lasting packet loss. This can result in transient packet loss when routing switches between the localized path into the normal path through the LMAs. In applications that are loss sensitive, this can lead to observable service disruptions. In deployments where Scenario A22 is possible, the use of localized routing is NOT RECOMMENDED when packet-loss-sensitive applications are in use.
由于PMIPv6未定义任何形式的LMA间通信，因此本文档将不涵盖此场景。当受支持的场景（如场景A12）演变为场景A22时，启动本地化路由会话的节点必须将其拆除，以防止持久的数据包丢失。当路由在局部路径之间切换到通过LMA的正常路径时，这可能导致暂时的数据包丢失。在对损失敏感的应用程序中，这可能导致可观察到的服务中断。在可能出现方案A22的部署中，当使用对数据包丢失敏感的应用程序时，不建议使用本地化路由。
PMIPv6 MNs can use an IPv4 Home Address (HoA) as described in [RFC5844]. In order to support the setup and maintenance of localized routes for these IPv4 HoAs in PMIPv6, the MAGs MUST add the IPv4 HoAs into their LREs. The MAGs MUST also support encapsulation of IPv4 packets as described in [RFC5844]. The localized routing protocol messages MUST include an IPv4 HoA option in their signaling messages in order to support IPv4 addresses for localized routing.
PMIPv6 MNs可以使用[RFC5844]中所述的IPv4主地址（HoA）。为了支持在PMIPv6中为这些IPv4 HOA设置和维护本地化路由，MAG必须将IPv4 HOA添加到其LRE中。MAG还必须支持[RFC5844]中所述的IPv4数据包封装。本地化路由协议消息必须在其信令消息中包含IPv4 HoA选项，以便为本地化路由支持IPv4地址。
If the transport network between the PMIPv6 entities involved in localized routing is IPv4-only, the LRI and LRA messages MUST be encapsulated similar to the PBU/PBA messages as specified in [RFC5844]. The encapsulation mode used SHOULD be identical to the one used to transport PBU and PBA messages.
如果本地化路由中涉及的PMIPv6实体之间的传输网络仅为IPv4，则必须按照[RFC5844]中的规定封装LRI和LRA消息，类似于PBU/PBA消息。使用的封装模式应与用于传输PBU和PBA消息的封装模式相同。
The localized routing messages use two new Mobility Header types (17 and 18). The LRI message requests creation or deletion of the localized routing state, and the LRA message acknowledges the creation or deletion of such localized routing state.
本地化路由消息使用两种新的移动报头类型（17和18）。LRI消息请求创建或删除本地化路由状态，LRA消息确认创建或删除此类本地化路由状态。
The LRI messages use a new Mobility Header type (17). The LMA sends an LRI message to a MAG to request local forwarding for a pair of MNs. The MAG may also send this message to request the two LMAs for offering local forwarding as described in Section 7.
LRI消息使用新的移动报头类型（17）。LMA向MAG发送LRI消息以请求一对mn的本地转发。MAG还可以发送该消息以请求两个LMA提供第7节中描述的本地转发。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: A monotonically increasing integer. Set by a sending node in a request message and used to match a reply to the request.
序列号：单调递增的整数。由发送节点在请求消息中设置，用于匹配对请求的回复。
Reserved: This field is unused and MUST be set to zero.
保留：此字段未使用，必须设置为零。
Lifetime: The requested time, in seconds, for which the sender wishes to have local forwarding. A value of 0xffff (all ones) indicates an infinite lifetime. When set to 0, indicates a request to stop localized routing.
生存期：发送方希望本地转发的请求时间（秒）。0xffff（所有值）表示无限的生存期。设置为0时，表示停止本地化路由的请求。
Mobility Options: MUST contain two separate MN-ID options, followed by one or more HNPs for each of the MNs. For instance, for Mobile Nodes MN1 and MN2 with identifiers MN1-ID and MN2-ID, and Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple MUST be present in the following order: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP]. The MN-ID and HNP options are the same as in [RFC5213]. The LRI MAY contain the remote MAG IPv6 address option, which is formatted identically to the HNP option, except that it uses a different Type code and the Prefix Length is always equal to 128 bits (see Section 10.1).
移动性选项：必须包含两个单独的MN-ID选项，然后是每个MN的一个或多个HNP。例如，对于标识符为MN1-ID和MN2-ID、家庭网络前缀为MN1-HNP和MN2-HNP的移动节点MN1和MN2，以下元组必须按以下顺序出现：[MN1-ID，MN1-HNP]，[MN2-ID，MN2-HNP]。MN-ID和HNP选项与[RFC5213]中的相同。LRI可能包含远程MAG IPv6地址选项，该选项的格式与HNP选项相同，但它使用不同的类型代码，且前缀长度始终等于128位（见第10.1节）。
The LRI message SHOULD be re-transmitted if a corresponding LRA message is not received within LRA_WAIT_TIME time units, up to a maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units.
如果在LRA_WAIT_时间单位内未收到相应的LRA消息，则应重新传输LRI消息，最多可重试LRI_次，每次重试由LRA_WAIT_时间单位分隔。
The LRA messages use a new Mobility Header type (18). A MAG sends an LRA message to the LMA as a response to the LRI message. An LMA may also send this message to a MAG as a response to the LRI message as described in Section 7.
LRA消息使用新的移动性报头类型（18）。MAG向LMA发送LRA消息作为对LRI消息的响应。LMA还可以将该消息发送给MAG，作为对LRI消息的响应，如第7节所述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: Copied from the sequence number field of the LRI message being responded to.
序列号：从要响应的LRI消息的序列号字段复制。
'U' flag: When set to 1, the LRA message is sent unsolicited.
“U”标志：当设置为1时，LRA消息将主动发送。
The Lifetime field indicates a new requested value. The MAG MUST wait for the regular LRI message to confirm that the request is acceptable to the LMA.
生存期字段表示新请求的值。MAG必须等待常规LRI消息，以确认LMA可接受该请求。
Reserved: This field is unused and MUST be set zero.
保留：此字段未使用，必须设置为零。
Status: 8-bit unsigned integer indicating the result of processing the Localized Routing Acknowledgment message. Values of the Status field less than 128 indicate that the Localized Routing Acknowledgment was processed successfully by the mobility entities(LMA or MAG). Values greater than or equal to 128 indicate that the Localized Routing Acknowledgment was rejected by the mobility entities. The following Status values are currently defined:
状态：8位无符号整数，指示处理本地化路由确认消息的结果。状态字段小于128的值表示移动性实体（LMA或MAG）成功地处理了本地化路由确认。大于或等于128的值表示移动实体拒绝了本地化路由确认。当前定义了以下状态值：
0: Success 128: Localized Routing Not Allowed 129: MN Not Attached
0:成功128:不允许本地化路由129:未连接MN
Lifetime: The time, in seconds, for which local forwarding is supported. It is typically copied from the corresponding field in the LRI message.
生存期：支持本地转发的时间（秒）。它通常从LRI消息中的相应字段复制。
Mobility Options: When Status code is 0, MUST contain the [MN-ID, HNP] tuples in the same order as in the LRI message. When Status code is not 0, MUST contain only those [MN-ID, HNP] tuples for which local forwarding is supported. The MN-ID and HNP options are the same as those described in [RFC5213].
移动性选项：当状态代码为0时，必须以与LRI消息中相同的顺序包含[MN-ID，HNP]元组。当状态代码不是0时，必须仅包含支持本地转发的[MN-ID，HNP]元组。MN-ID和HNP选项与[RFC5213]中描述的选项相同。
The MAG IPv6 address mobility option contains the IPv6 address of a MAG involved in localized routing. The MAG IPv6 address option has an alignment requirement of 8n+4.
MAG IPv6地址移动选项包含参与本地化路由的MAG的IPv6地址。MAG IPv6地址选项的对齐要求为8n+4。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MAG IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MAG IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
51
51
Length
长
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为18。
Reserved (R)
保留（R）
This 8-bit field is unused. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
此8位字段未使用。发送方必须将该值初始化为0，接收方必须忽略该值。
Address Length
地址长度
This field MUST be set to 128.
此字段必须设置为128。
MAG IPv6 Address
MAG IPv6地址
A 16-byte field containing the MAG's IPv6 address.
包含MAG IPv6地址的16字节字段。
The LMA and the MAG must allow the following variables to be configurable:
LMA和MAG必须允许配置以下变量：
LRA_WAIT_TIME: This variable is used to set the time interval, in seconds, between successive retransmissions of an LRI message. The default value is 3 seconds.
LRA_WAIT_TIME：此变量用于设置LRI消息连续重新传输之间的时间间隔（以秒为单位）。默认值为3秒。
LRI_RETRIES: This variable indicates the maximum number of times the initiator retransmits an LRI message before stopping. The default value for this variable is 3.
LRI_RETRIES：此变量表示启动器在停止之前重新传输LRI消息的最大次数。此变量的默认值为3。
The protocol inherits the threats to [RFC5213] that are identified in [RFC4832]. The protocol specified in this document uses the same security association as defined in [RFC5213] for use between the LMA and the MAG to protect the LRI and LRA messages. This document also assumes the preexistence of a MAG-MAG security association if LR needs to be supported between them. Support for integrity protection using IPsec is REQUIRED, but support for confidentiality is OPTIONAL. The MAGs MUST perform ingress filtering on the MN-sourced packets before encapsulating them into MAG-MAG tunnels in order to prevent address spoofing.
该协议继承了[RFC4832]中确定的对[RFC5213]的威胁。本文件中规定的协议使用[RFC5213]中定义的相同安全关联，用于LMA和MAG之间保护LRI和LRA消息。如果需要在MAG-MAG安全关联之间支持LR，则本文档还假设先前存在MAG-MAG安全关联。需要使用IPsec支持完整性保护，但支持机密性是可选的。MAG必须在将MN源数据包封装到MAG-MAG隧道之前对其执行入口过滤，以防止地址欺骗。
The Localized Routing Initiation (described in Section 10.1) and the Localized Routing Acknowledgment (described in Section 10.2) have each been assigned a Mobility Header type (17 and 18, respectively) from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry at http://www.iana.org/assignments/mobility-parameters.
本地化路由发起（如第10.1节所述）和本地化路由确认（如第10.2节所述）均已从位于的“移动性头部类型-用于移动性头部中的MH类型”注册表中分配了移动性头部类型（分别为17和18）http://www.iana.org/assignments/mobility-parameters.
The MAG IPv6 Address has been assigned a Mobility Option type (51) from the "Mobility Options" registry at http://www.iana.org/assignments/mobility-parameters.
MAG IPv6地址已从位于的“移动选项”注册表中分配了移动选项类型（51）http://www.iana.org/assignments/mobility-parameters.
This document merges ideas from five different draft documents addressing the PMIP localized routing problem. The authors of these drafts are listed below (in alphabetical order).
本文档合并了五个不同的草案文档中的想法，以解决PMIP本地化路由问题。这些草案的作者如下（按字母顺序排列）。
Kuntal Chowdhury <kchowdhury@starentnetworks.com>
Kuntal Chowdhury <kchowdhury@starentnetworks.com>
Ashutosh Dutta <adutta@niksun.com>
Ashutosh Dutta <adutta@niksun.com>
Rajeev Koodli <rkoodli@starentnetworks.com>
Rajeev Koodli <rkoodli@starentnetworks.com>
Suresh Krishnan <suresh.krishnan@ericsson.com>
Suresh Krishnan <suresh.krishnan@ericsson.com>
Marco Liebsch <marco.liebsch@nw.neclab.eu>
Marco Liebsch <marco.liebsch@nw.neclab.eu>
Paulo Loureiro <loureiro@neclab.eu>
Paulo Loureiro <loureiro@neclab.eu>
Desire Oulai <desire.oulai@videotron.com>
Desire Oulai <desire.oulai@videotron.com>
Behcet Sarikaya <sarikaya@ieee.org>
Behcet Sarikaya <sarikaya@ieee.org>
Qin Wu <sunseawq@huawei.com>
Qin Wu <sunseawq@huawei.com>
Hidetoshi Yokota <yokota@kddilabs.jp>
Hidetoshi Yokota <yokota@kddilabs.jp>
The authors would like to thank Sri Gundavelli, Julien Abeille, Tom Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les Ginsberg, Russ Housley, Carl Wallace, Ralph Droms, Adrian Farrel, and Stephen Farrell for their comments and suggestions.
作者要感谢斯里·冈达维利、朱利安·阿贝尔、汤姆·泰勒、肯特·梁、莫哈娜·杰亚塔兰、朱尼·科霍宁、格伦·佐恩、艾哈迈德·穆哈纳、佐尔坦·图兰尼、德克·冯·雨果、皮特·麦肯、崔显松、卡洛斯·贝尔纳多、巴萨瓦拉·帕蒂尔、贾里·阿尔科、玛丽·巴恩斯、莱斯·金斯堡、罗斯·霍斯利、卡尔·华莱士、拉尔夫·德罗姆斯、阿德里安·法雷尔、，以及斯蒂芬·法雷尔的评论和建议。
[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., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[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月。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
[RFC5845]Muhanna，A.，Khalil，M.，Gundavelli，S.，和K.Leung，“代理移动IPv6的通用路由封装（GRE）密钥选项”，RFC 58452010年6月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[RFC4832]Vogt，C.和J.Kempf，“基于网络的本地化移动性管理（NETLMM）的安全威胁”，RFC 4832，2007年4月。
[RFC6279] Liebsch, M., Ed., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011.
[RFC6279]Liebsch，M.，Ed.，Jeong，S.，和Q.Wu，“代理移动IPv6（PMIPv6）本地化路由问题声明”，RFC 6279，2011年6月。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson加拿大魁北克皇家山Decarie镇8400大道
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Rajeev Koodli Cisco Systems
拉吉耶夫·库德利思科系统公司
EMail: rkoodli@cisco.com
EMail: rkoodli@cisco.com
Paulo Loureiro NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Paulo Loureiro NEC Laboratories Europe NEC Europe Ltd.Kurfuersten Anlage 36 69115德国海德堡
EMail: loureiro@neclab.eu
EMail: loureiro@neclab.eu
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 21001 China
中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司21001
Phone: +86-25-56623633
EMail: sunseawq@huawei.com
Phone: +86-25-56623633
EMail: sunseawq@huawei.com
Ashutosh Dutta NIKSUN
阿舒托什·杜塔·尼克森
EMail: adutta@niksun.com
EMail: adutta@niksun.com