Internet Engineering Task Force (IETF) Z. Yan
Request for Comments: 8191 CNNIC
Category: Standards Track J. Lee
ISSN: 2070-1721 Sangmyung University
X. Lee
CNNIC
August 2017
Internet Engineering Task Force (IETF) Z. Yan
Request for Comments: 8191 CNNIC
Category: Standards Track J. Lee
ISSN: 2070-1721 Sangmyung University
X. Lee
CNNIC
August 2017
Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)
代理移动IPv6（PMIPv6）中的家庭网络前缀重新编号
Abstract
摘要
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.
在基本代理移动IPv6（PMIPv6）规范中，移动节点（MN）在其初始连接期间被分配有归属网络前缀（HNP），并且MN使用HNP配置其归属地址（HoA）。在MN移动期间，国家警察保持不变，以保持与HoA相关的持续通信。然而，当前的PMIPv6规范没有规定HNP重新编号时的相关操作（例如，由于服务提供商或站点拓扑结构的变化等）。在本文中，提出了一种支持HNP重新编号的解决方案，作为PMIPv6规范的可选扩展。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8191.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8191.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 4
4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 6
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 4
4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 6
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
At the time of writing, network managers prefer Provider-Independent (PI) addressing for IPv6 to attempt to minimize the need for future possible renumbering. However, a widespread use of PI addresses will cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It is thus desirable to develop tools and practices that make IPv6 renumbering a simpler process to reduce demand for IPv6 PI space [RFC6879]. In this document, we aim to support HNP renumbering when the HNP in PMIPv6 [RFC5213] is not a PI prefix.
在撰写本文时，网络经理倾向于IPv6的独立于提供商（PI）寻址，以尽量减少未来可能重新编号的需要。然而，PI地址的广泛使用将导致边界网关协议（BGP）的扩展问题[RFC7010]。因此，需要开发工具和实践，使IPv6重新编号成为一个更简单的过程，以减少对IPv6 PI空间的需求[RFC6879]。在本文中，我们的目标是在PMIPv6[RFC5213]中的HNP不是PI前缀时支持HNP重新编号。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
There are a number of reasons why HNP renumbering support in PMIPv6 is useful, and some scenarios are identified below:
国家警察在PMIPv6中重新编号支持之所以有用，有很多原因，下面列出了一些场景：
Scenario 1: the HNP set used by a PMIPv6 service provider is assigned by a different Internet Service Provider (ISP), and then HNP renumbering MAY occur if the PMIPv6 service provider switches to a different ISP.
场景1：PMIPv6服务提供商使用的HNP集由不同的互联网服务提供商（ISP）分配，如果PMIPv6服务提供商切换到不同的ISP，则可能会发生HNP重新编号。
Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed by the same PMIPv6 service provider, and then each LMA MAY serve for a specific HNP set. In this case, the HNP of an MN MAY change if the serving LMA is changed to another LMA that does not inherit the assigned HNP set [RFC6463].
场景2：多个本地移动锚（LMA）可由同一PMIPv6服务提供商部署，然后每个LMA可用于特定HNP集。在这种情况下，如果服务LMA改变为不继承分配的HNP集的另一LMA，则MN的HNP可能改变[RFC6463]。
Scenario 3: PMIPv6 HNP renumbering MAY be caused by the rebuilding of the network architecture as the companies split, merge, grow, relocate, or reorganize. For example, the PMIPv6 service provider MAY reorganize its network topology.
场景3:PMIPv6 HNP重新编号可能是由于公司拆分、合并、增长、重新定位或重组时网络架构的重建造成的。例如，PMIPv6服务提供商可以重新组织其网络拓扑。
In Scenario 1, we assume that only the HNP is renumbered, while the serving LMA remains unchanged; this is the basic scenario considered in this document. In Scenarios 2 and 3, more complex situations MAY result; for example, HNP renumbering MAY occur due to the switchover of a serving LMA.
在场景1中，我们假设只有HNP被重新编号，而服务LMA保持不变；这是本文档中考虑的基本场景。在场景2和场景3中，可能会导致更复杂的情况；例如，HNP重新编号可能由于服务LMA的切换而发生。
In the Mobile IPv6 (MIPv6) protocol, when an HNP changes, the Home Agent (HA) will actively notify its MN about the new prefix, and then the renumbering of the Home Network Address (HoA) can be well supported [RFC6275]. In basic PMIPv6, the PMIPv6 binding is triggered by a Mobile Access Gateway (MAG), which detects the attachment of the MN. A scheme is also needed for the LMA to immediately initiate the PMIPv6 binding state refreshment during the HNP renumbering process. Although this issue is also mentioned in Section 6.12 of [RFC5213], the related solution has not been specified.
在移动IPv6（MIPv6）协议中，当HNP更改时，归属代理（HA）将主动通知其MN有关新前缀，然后可以很好地支持对归属网络地址（HoA）重新编号[RFC6275]。在基本PMIPv6中，PMIPv6绑定由检测MN连接的移动接入网关（MAG）触发。在HNP重新编号过程中，LMA还需要一个方案来立即启动PMIPv6结合状态刷新。尽管[RFC5213]的第6.12节也提到了该问题，但尚未指定相关解决方案。
When HNP renumbering happens in PMIPv6, the LMA MUST notify the MAG about the new HNP, and then the MAG MUST announce the new HNP to the attached MN accordingly. Also, the LMA and the MAG MUST update the routing states for the HNP and the related addresses. To support this procedure, [RFC7077] can be adopted; it specifies an asynchronous update from the LMA to the MAG about specific session parameters. This document considers the following two cases:
当HNP在PMIPv6中重新编号时，LMA必须将新HNP通知MAG，然后MAG必须相应地向所附MN宣布新HNP。此外，LMA和MAG必须更新HNP和相关地址的路由状态。为支持该程序，可采用[RFC7077]；它指定从LMA到MAG的关于特定会话参数的异步更新。本文件考虑了以下两种情况：
(1) HNP is renumbered under the same LMA
(1) HNP在同一LMA下重新编号
In this case, the LMA remains unchanged as in Scenarios 1 and 3. The steps are shown in Figure 1.
在这种情况下，LMA与场景1和3一样保持不变。这些步骤如图1所示。
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
| | Allocate new HNP
| | |
| |<------------- UPN ---|
| | |
| | |
| | |
|<-----RA/DHCP --------| |
| | |
Address configuration | |
| | |
| Update binding & routing states |
| | |
| |--- UPA ------------->|
| | |
| | Update binding & routing states
| | |
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
| | Allocate new HNP
| | |
| |<------------- UPN ---|
| | |
| | |
| | |
|<-----RA/DHCP --------| |
| | |
Address configuration | |
| | |
| Update binding & routing states |
| | |
| |--- UPA ------------->|
| | |
| | Update binding & routing states
| | |
Figure 1: Signaling Call Flow for HNP Renumbering
图1：HNP重新编号的信令呼叫流
o When a PMIPv6 service provider renumbers the HNP set under the same LMA, the serving LMA SHOULD initiate the HNP renumbering operation. The LMA allocates a new HNP for the related MN.
o 当PMIPv6服务提供商对同一LMA下的HNP集重新编号时，服务LMA应启动HNP重新编号操作。LMA为相关MN分配新的HNP。
o The LMA sends the Update Notification (UPN) message to the MAG to update the HNP information. If the Dynamic Host Configuration Protocol (DHCP) is used to allocate the address, the DHCP infrastructure MUST also be notified about the new HNP.
o LMA向MAG发送更新通知（UPN）消息以更新HNP信息。如果使用动态主机配置协议（DHCP）分配地址，还必须将新HNP通知DHCP基础设施。
o Once the MAG receives this UPN message, it recognizes that the related MN has the new HNP. Then, the MAG MUST notify the MN about the new HNP with a Router Advertisement (RA) message or allocate a new address within the new HNP through a DHCP procedure.
o 一旦MAG接收到该UPN消息，它就识别出相关MN具有新的HNP。然后，MAG必须使用路由器广告（RA）消息通知MN关于新HNP，或者通过DHCP过程在新HNP内分配新地址。
o After the MN obtains the HNP information through the RA message, it deletes the old HoA and configures a new HoA with the newly allocated HNP.
o MN通过RA消息获取HNP信息后，删除旧HoA并用新分配的HNP配置新HoA。
o When the new HNP is announced or the new address is configured to the MN successfully, the MAG MUST update the related binding and routing states. Then, the MAG sends back the Update Notification Acknowledgement (UPA) message to the LMA for the notification of successful update of the HNP, related binding state, and routing state. Then, the LMA updates the routing and binding information corresponding to the MN in order to replace the old HNP with the new one.
o 当宣布新的HNP或将新地址成功配置到MN时，MAG必须更新相关的绑定和路由状态。然后，MAG将更新通知确认（UPA）消息发送回LMA，用于通知HNP、相关绑定状态和路由状态的成功更新。然后，LMA更新对应于MN的路由和绑定信息，以便用新的HNP替换旧的HNP。
(2) HNP renumbering is caused by the LMA switchover
(2) HNP重新编号是由LMA切换引起的
Since the HNP is assigned by the LMA, HNP renumbering MAY be caused by the LMA switchover, as in Scenarios 2 and 3.
由于HNP由LMA分配，HNP重新编号可能由LMA切换引起，如场景2和3中所示。
The LMA information is the basic configuration information of the MAG. When the LMA changes, the related profile SHOULD be updated by the service provider. In this way, the MAG initiates the binding registration to the MN's new LMA as specified in [RFC5213]. When HNP renumbering is caused in this case, the new HNP information is sent by the LMA during the new binding procedure. Accordingly, the MAG withdraws the old HNP of the MN and announces the new HNP to the MN, similar to the case when the HNP is renumbered under the same LMA.
LMA信息是MAG的基本配置信息。当LMA发生变化时，服务提供商应更新相关配置文件。通过这种方式，MAG启动对MN的新LMA的绑定注册，如[RFC5213]中所述。在这种情况下，当HNP重新编号时，新的HNP信息由LMA在新的绑定过程中发送。因此，MAG撤销MN的旧HNP并向MN宣布新HNP，类似于HNP在相同LMA下重新编号的情况。
HNP renumbering MAY cause the disconnection of the ongoing communications of the MN. Basically, there are two modes to manage the session connectivity during HNP renumbering.
HNP重新编号可能导致MN正在进行的通信中断。在HNP重新编号期间，基本上有两种模式来管理会话连接。
(1) Soft mode
(1) 软模式
The LMA will temporarily maintain the state of the old HNP during the HNP renumbering (after the UPA reception) in order to redirect the packets to the MN before the MN reconnects the ongoing session and notifies the Correspondent Node (CN) about its new HoA. This mode is aiming to reduce packet loss during HNP renumbering, but the binding state corresponding to the old HNP SHOULD be marked, for example, as transient binding [RFC6058]. Also, the LMA MUST stop broadcasting the routing information about the old HNP if the old HNP is no longer anchored at this LMA.
LMA将在HNP重新编号期间（在UPA接收之后）临时维持旧HNP的状态，以便在MN重新连接正在进行的会话之前将分组重定向到MN，并将其新HoA通知对应节点（CN）。此模式旨在减少HNP重新编号期间的数据包丢失，但与旧HNP对应的绑定状态应标记为瞬态绑定[RFC6058]。此外，如果旧HNP不再锚定在该LMA上，则LMA必须停止广播关于旧HNP的路由信息。
(2) Hard mode
(2) 硬模式
If HNP renumbering happens with the switchover of the LMA, hard mode is RECOMMENDED to keep the protocol simple. In this mode, the LMA deletes the binding state of the old HNP after it receives the UPA message from the MAG, and the LMA silently discards the packets destined to the old HNP.
如果在LMA切换时发生HNP重新编号，建议使用硬模式以保持协议简单。在该模式中，LMA在从MAG接收到UPA消息之后删除旧HNP的绑定状态，并且LMA静默地丢弃目的地为旧HNP的分组。
(1) UPN message
(1) UPN消息
In the UPN message sent from the LMA to the MAG, the notification reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP Option [RFC5213] containing the new HNP and the Mobile Node Identifier Option [RFC4283] (which identifies the MN) are contained as Mobility Options of UPN. The order of the HNP Option and Mobile Node Identifier Option in the UPN message is not mandated here.
在从LMA发送到MAG的UPN消息中，通知原因设置为2（更新会话参数）。此外，包含新HNP的HNP选项[RFC5213]和移动节点标识符选项[RFC4283]（识别MN）被包含为UPN的移动性选项。此处不强制规定UPN消息中HNP选项和移动节点标识符选项的顺序。
(2) UPA message
(2) UPA消息
The MAG sends this message in order to acknowledge that it has received an UPN message with the (A) flag set and to indicate the status after processing the message. If the MAG did not successfully renumber the HNP, which is required in the UPN message, the UPA message has the Status Code set to 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS), and the subsequent operation of the LMA is PMIPv6 service provider specific.
MAG发送此消息，以确认其已收到设置了（A）标志的UPN消息，并指示处理该消息后的状态。如果MAG没有成功地对HNP重新编号（这是UPN消息中需要的），UPA消息的状态代码设置为128（FAILED-to-UPDATE-SESSION-PARAMETERS），LMA的后续操作特定于PMIPv6服务提供商。
(3) RA message
(3) RA消息
When the RA message is used by the MAG to advise the new HNP, it contains two Prefix Information Options [RFC4861] [RFC4862]. In the first Prefix Information Option, the old HNP is carried, and the related Preferred Lifetime is set to 0. In the second Prefix Information Option, the new HNP is carried with the Valid Lifetime, and Preferred Lifetime set to larger than 0.
当MAG使用RA消息通知新HNP时，它包含两个前缀信息选项[RFC4861][RFC4862]。在第一个前缀信息选项中，携带旧的HNP，并且相关的首选生存期设置为0。在第二个前缀信息选项中，新HNP携带有效生存期，首选生存期设置为大于0。
(4) DHCP message
(4) DHCP消息
When the DHCP is used in PMIPv6 to configure the addresses for the MN, new IPv6 address or addresses (e.g., the HoA) will be generated based on the new HNP, and the related DHCP procedure is also triggered by the reception of the UPN message [RFC3315].
当在PMIPv6中使用DHCP来配置MN的地址时，将基于新的HNP生成新的IPv6地址（例如，HoA），并且相关的DHCP过程也由UPN消息的接收触发[RFC3315]。
In order to maintain the reachability of the MN, the Domain Name System (DNS) resource record corresponding to this MN MAY need to be updated when the HNP of the MN changes [RFC3007]. However, this is beyond the scope of this document.
为了保持MN的可达性，当MN的HNP改变时，可能需要更新对应于该MN的域名系统（DNS）资源记录[RFC3007]。但是，这超出了本文件的范围。
The UPN and UPA messages in this document MUST be protected using end-to-end security association(s) offering integrity and data origin authentication as specified in [RFC5213] and [RFC7077].
本文档中的UPN和UPA消息必须使用提供完整性和数据源身份验证的端到端安全关联进行保护，如[RFC5213]和[RFC7077]中所述。
When HNP renumbering is triggered, a new HNP SHOULD be allocated to the MN. The LMA MUST follow the procedure of PMIPv6 to make sure that only an authorized HNP can be assigned for the MN. In this way, the LMA is ready to be the topological anchor point of the new HNP, which is for that MN's exclusive use.
触发HNP重新编号时，应将新HNP分配给MN。LMA必须遵循PMIPv6的程序，以确保只能为MN分配授权的HNP。这样，LMA就可以成为新HNP的拓扑锚定点，这是该MN的专用。
Per [RFC4862], if the Valid Lifetime in a Prefix Information Option is set to less than 2 hours in an unauthenticated RA, it is ignored. Thus, when the old HNP that is being deprecated is included in an RA from the MAG, the Valid Lifetime SHOULD be set to 2 hours (and the Preferred Lifetime set to 0) for an unauthenticated RA. However, if the legality of the signaling messages exchanged between MAG and MN can be guaranteed, it MAY be acceptable to also set the Valid Lifetime to 0 for an unauthenticated RA.
根据[RFC4862]，如果在未经验证的RA中，前缀信息选项中的有效生存期设置为小于2小时，则忽略该选项。因此，当被弃用的旧HNP包含在来自MAG的RA中时，对于未经验证的RA，有效生存期应设置为2小时（首选生存期设置为0）。然而，如果可以保证在MAG和MN之间交换的信令消息的合法性，那么对于未经认证的RA，也可以将有效生存期设置为0。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <http://www.rfc-editor.org/info/rfc3007>.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，DOI 10.17487/RFC3007，2000年11月<http://www.rfc-editor.org/info/rfc3007>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, <http://www.rfc-editor.org/info/rfc4283>.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项（MIPv6）”，RFC 4283，DOI 10.17487/RFC4283，2005年11月<http://www.rfc-editor.org/info/rfc4283>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213]Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，DOI 10.17487/RFC5213，2008年8月<http://www.rfc-editor.org/info/rfc5213>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 6275，DOI 10.17487/RFC6275，2011年7月<http://www.rfc-editor.org/info/rfc6275>.
[RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463, February 2012, <http://www.rfc-editor.org/info/rfc6463>.
[RFC6463]Korhonen，J.，Ed.，Gundavelli，S.，Yokota，H.，和X.Cui，“代理移动IPv6的运行时本地移动锚（LMA）分配支持”，RFC 6463，DOI 10.17487/RFC6463，2012年2月<http://www.rfc-editor.org/info/rfc6463>.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, DOI 10.17487/RFC7077, November 2013, <http://www.rfc-editor.org/info/rfc7077>.
[RFC7077]Krishnan，S.，Gundavelli，S.，Liebsch，M.，Yokota，H.，和J.Korhonen，“代理移动IPv6的更新通知”，RFC 7077，DOI 10.17487/RFC7077，2013年11月<http://www.rfc-editor.org/info/rfc7077>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient Binding for Proxy Mobile IPv6", RFC 6058, DOI 10.17487/RFC6058, March 2011, <http://www.rfc-editor.org/info/rfc6058>.
[RFC6058]Liebsch，M.，Ed.，Muhanna，A.，和O.Blume，“代理移动IPv6的瞬态绑定”，RFC 6058，DOI 10.17487/RFC6058，2011年3月<http://www.rfc-editor.org/info/rfc6058>.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, <http://www.rfc-editor.org/info/rfc6879>.
[RFC6879]Jiang，S.，Liu，B.和B.Carpenter，“IPv6企业网络重新编号方案、注意事项和方法”，RFC 6879，DOI 10.17487/RFC6879，2013年2月<http://www.rfc-editor.org/info/rfc6879>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, DOI 10.17487/RFC7010, September 2013, <http://www.rfc-editor.org/info/rfc7010>.
[RFC7010]Liu，B.，Jiang，S.，Carpenter，B.，Venaas，S.，和W.George，“IPv6站点重新编号差距分析”，RFC 7010，DOI 10.17487/RFC7010，2013年9月<http://www.rfc-editor.org/info/rfc7010>.
Acknowledgements
致谢
The work of Jong-Hyouk Lee was supported by 'The Cross-Ministry Giga KOREA Project' grant from the Ministry of Science, ICT and Future Planning, Korea.
李钟赫的工作得到了韩国科学、信息通信技术和未来规划部的“跨部Giga韩国项目”资助。
Authors' Addresses
作者地址
Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China
中国北京中关村南四街4号志伟燕CNNIC 100190
Email: yan@cnnic.cn
Email: yan@cnnic.cn
Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan 31066 Republic of Korea
韩国东南固天安省三明大吉31号郑孝利三明大学31066
Email: jonghyouk@smu.ac.kr
Email: jonghyouk@smu.ac.kr
Xiaodong Lee CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China
中国北京中关村南四街4号李晓东CNNIC 100190
Email: xl@cnnic.cn
Email: xl@cnnic.cn