Internet Engineering Task Force (IETF) B. Liu
Request for Comments: 7010 S. Jiang
Category: Informational Huawei Technologies Co., Ltd.
ISSN: 2070-1721 B. Carpenter
University of Auckland
S. Venaas
Cisco Systems
W. George
Time Warner Cable
September 2013
Internet Engineering Task Force (IETF) B. Liu
Request for Comments: 7010 S. Jiang
Category: Informational Huawei Technologies Co., Ltd.
ISSN: 2070-1721 B. Carpenter
University of Auckland
S. Venaas
Cisco Systems
W. George
Time Warner Cable
September 2013
IPv6 Site Renumbering Gap Analysis
IPv6站点重新编号差距分析
Abstract
摘要
This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering. The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.
本文档简要介绍了可用于IPv6站点重新编号的现有机制，并试图涵盖与IPv6重新编号相关的大多数明确问题和要求。内容主要是差距分析，为今后的工作提供基础，以确定和制定解决方案，或酌情促进此类发展。差距分析由重新编号过程的主要步骤组织。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7010.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7010.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 ....................................................4
2. Overall Requirements for Renumbering ............................4
3. Existing Components for IPv6 Renumbering ........................5
3.1. Relevant Protocols and Mechanisms ..........................5
3.2. Management Tools ...........................................6
3.3. Procedures and Policies ....................................7
4. Managing Prefixes ...............................................7
4.1. Prefix Delegation ..........................................7
4.2. Prefix Assignment ..........................................8
5. Address Configuration ...........................................8
5.1. Host Address Configuration .................................8
5.2. Router Address Configuration ...............................9
6. Updating Address-Relevant Entries ..............................10
6.1. DNS Records Update ........................................10
6.2. In-Host Server Address Update .............................11
6.3. Address Update in Scattered Configurations ................11
7. Renumbering Event Management ...................................13
7.1. Renumbering Notification ..................................13
7.2. Synchronization Management ................................14
7.3. Renumbering Monitoring ....................................15
8. Miscellaneous ..................................................15
8.1. Multicast .................................................15
8.2. Mobility ..................................................17
9. Gap Summary ....................................................17
9.1. Managing Prefixes .........................................17
9.2. Address Configuration .....................................17
9.3. Address-Relevant Entries Update ...........................18
9.4. Renumbering Event Management ..............................19
9.5. Miscellaneous .............................................19
10. Gaps Considered Unsolvable ....................................20
10.1. Address Configuration ....................................20
10.2. Address-Relevant Entries Update ..........................20
10.3. Miscellaneous ............................................21
11. Security Considerations .......................................21
12. Acknowledgments ...............................................22
13. References ....................................................23
13.1. Normative References .....................................23
13.2. Informative References ...................................23
1. Introduction ....................................................4
2. Overall Requirements for Renumbering ............................4
3. Existing Components for IPv6 Renumbering ........................5
3.1. Relevant Protocols and Mechanisms ..........................5
3.2. Management Tools ...........................................6
3.3. Procedures and Policies ....................................7
4. Managing Prefixes ...............................................7
4.1. Prefix Delegation ..........................................7
4.2. Prefix Assignment ..........................................8
5. Address Configuration ...........................................8
5.1. Host Address Configuration .................................8
5.2. Router Address Configuration ...............................9
6. Updating Address-Relevant Entries ..............................10
6.1. DNS Records Update ........................................10
6.2. In-Host Server Address Update .............................11
6.3. Address Update in Scattered Configurations ................11
7. Renumbering Event Management ...................................13
7.1. Renumbering Notification ..................................13
7.2. Synchronization Management ................................14
7.3. Renumbering Monitoring ....................................15
8. Miscellaneous ..................................................15
8.1. Multicast .................................................15
8.2. Mobility ..................................................17
9. Gap Summary ....................................................17
9.1. Managing Prefixes .........................................17
9.2. Address Configuration .....................................17
9.3. Address-Relevant Entries Update ...........................18
9.4. Renumbering Event Management ..............................19
9.5. Miscellaneous .............................................19
10. Gaps Considered Unsolvable ....................................20
10.1. Address Configuration ....................................20
10.2. Address-Relevant Entries Update ..........................20
10.3. Miscellaneous ............................................21
11. Security Considerations .......................................21
12. Acknowledgments ...............................................22
13. References ....................................................23
13.1. Normative References .....................................23
13.2. Informative References ...................................23
As introduced in [RFC5887], renumbering, especially for medium to large sites and networks, is currently viewed as expensive and painful. This error-prone process is avoided by network managers as much as possible. If IPv6 site renumbering continues to be considered difficult, network managers will turn to Provider Independent (PI) addressing for IPv6 as an attempt to minimize the need for future renumbering. However, widespread use of PI addressing may create very serious BGP4 scaling problems [RFC4984]. It is thus desirable to develop tools and practices that make renumbering a simpler process and reduces demand for IPv6 PI space.
正如[RFC5887]中介绍的那样，重新编号，特别是对于中大型站点和网络，目前被认为是昂贵和痛苦的。网络管理员尽可能避免这种容易出错的过程。如果IPv6站点重新编号仍然被认为是困难的，网络管理员将转向IPv6的独立于提供商（PI）寻址，以尽量减少未来重新编号的需要。然而，PI寻址的广泛使用可能会产生非常严重的BGP4扩展问题[RFC4984]。因此，需要开发工具和实践，使重新编号过程更简单，并减少对IPv6 PI空间的需求。
Building upon the IPv6 enterprise renumbering scenarios described in [RFC6879], this document performs a gap analysis to provide a basis for future work to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized according to the main steps of a renumbering process, which includes prefix management, node address (re)configuration, and updates to address-relevant entries in various devices such as firewalls, routers and servers, etc. Renumbering event management is presented independently from the steps of a renumbering process in order to identify some operational and administrative gaps in renumbering.
在[RFC6879]中描述的IPv6企业重新编号方案的基础上，本文档执行差距分析，为今后确定和开发解决方案或促进此类开发（视情况而定）提供基础。差距分析根据重新编号过程的主要步骤进行组织，包括前缀管理、节点地址（重新）配置和更新，以解决各种设备（如防火墙、路由器和服务器）中的相关条目，等。重新编号事件管理独立于重新编号过程的步骤，以确定重新编号过程中的一些操作和管理差距。
This document starts from existing work in [RFC5887] and [RFC4192]. It further analyzes and identifies the valuable and solvable issues, digs out of some undiscovered gaps, and gives some solution suggestions. This document considers the make-before-break approach as a premise for the gap analysis, so readers should be familiar with [RFC4192].
本文件从[RFC5887]和[RFC4192]中的现有工作开始。它进一步分析和确定了有价值和可解决的问题，挖掘了一些未发现的差距，并提出了一些解决建议。本文档将先制造后破坏的方法作为差距分析的前提，因此读者应该熟悉[RFC4192]。
Renumbering nodes with static addresses has a particular set of problems, thus discussion of that space has been covered in a related document [RFC6866].
使用静态地址对节点重新编号有一组特殊的问题，因此相关文档[RFC6866]中已经讨论了该空间。
This document does not cover the unplanned emergency renumbering cases.
本文件不包括计划外紧急重新编号案例。
This section introduces the overall goals of a renumbering event. In general, we need to leverage renumbering automation to avoid human intervention as much as possible at a reasonable cost. Some existing mechanisms already provide useful capabilities.
本节介绍重新编号事件的总体目标。一般来说，我们需要利用重新编号自动化，以合理的成本尽可能避免人为干预。一些现有机制已经提供了有用的功能。
The automation can be divided into four aspects as follows. (Detailed analysis of the four aspects is presented respectively in Sections 4 through 7.)
自动化可分为以下四个方面。（第4节至第7节分别介绍了这四个方面的详细分析。）
o Prefix delegation and delivery should be automatic and accurate in aggregation and coordination.
o 前缀委托和传递应在聚合和协调中自动且准确。
o Address reconfiguration should be automatically achieved through standard protocols with minimum human intervention.
o 地址重新配置应通过标准协议自动实现，且人工干预最少。
o Address-relevant entry updates should be performed together and without error.
o 与地址相关的条目更新应一起执行，且无错误。
o Renumbering event management is needed to provide the functions of renumbering notification, synchronization, and monitoring.
o 需要重新编号事件管理来提供重新编号通知、同步和监视的功能。
Besides automation, session survivability is another important issue during renumbering since application outage is one of the most obvious impacts that make renumbering painful and expensive. Session survivability is a fundamental issue that cannot be solved within a renumbering context only. However, the [RFC4192] make-before-break approach, which uses the address lifetime mechanisms in IPv6 Stateless Address Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for IPv6 (DHCPv6), allows for a smooth transition mechanism from old to new prefixes. In most cases, since we can set the transition period to be long enough to cover the ongoing sessions, we consider this mechanism sufficient to avoid broken sessions in IPv6 site renumbering. (Please note that if multiple addresses are running on hosts simultaneously, the address selection [RFC6724] needs to be carefully handled.)
除了自动化之外，会话生存性是重新编号过程中的另一个重要问题，因为应用程序中断是使重新编号变得痛苦和昂贵的最明显影响之一。会话生存性是一个根本问题，不能仅在重新编号的上下文中解决。然而，[RFC4192]先通后断方法使用IPv6无状态地址自动配置（SLAAC）和IPv6动态主机配置协议（DHCPv6）中的地址生存期机制，允许从旧前缀平滑过渡到新前缀。在大多数情况下，由于我们可以设置过渡期足够长以覆盖正在进行的会话，所以我们认为这种机制足以避免IPv6站点重新编号中的中断会话。（请注意，如果多个地址同时在主机上运行，则需要小心处理地址选择[RFC6724]）
Since renumbering is not a new issue, some protocols and mechanisms have already been utilized for this purpose. There are also some dedicated protocols and mechanisms that have been developed for renumbering. This section briefly reviews these existing protocols and mechanisms to provide a basis for the gap analysis.
由于重新编号不是一个新问题，一些协议和机制已经用于此目的。也有一些专门的协议和机制已被开发用于重新编号。本节简要回顾这些现有协议和机制，为差距分析提供基础。
o Router Advertisement (RA) messages, defined in [RFC4861], are used to deprecate prefixes that are old or announce prefixes that are new, and to advertise the availability of an upstream router. In renumbering, RA is one of the basic mechanisms for host configuration.
o [RFC4861]中定义的路由器通告（RA）消息用于弃用旧前缀或宣布新前缀，并通告上游路由器的可用性。在重新编号中，RA是主机配置的基本机制之一。
o When renumbering a host, SLAAC [RFC4862] may be used for address configuration with the new prefix(es). Hosts receive RA messages that contain a routable prefix(es) and the address(es) of the default router(s); then hosts can generate an IPv6 address(es) by themselves.
o 在对主机重新编号时，SLAAC[RFC4862]可用于带有新前缀的地址配置。主机接收包含可路由前缀和默认路由器地址的RA消息；然后主机可以自己生成IPv6地址。
o Hosts that are configured through DHCPv6 [RFC3315] obtain new addresses through the renewal process or when they receive the reconfiguration messages initiated by the DHCPv6 servers.
o 通过DHCPv6[RFC3315]配置的主机通过续订过程或在收到DHCPv6服务器启动的重新配置消息时获得新地址。
o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated delegation of IPv6 prefixes using the DHCPv6.
o DHCPv6 PD（前缀委派）[RFC3633]支持使用DHCPv6自动委派IPv6前缀。
o [RFC2894] defines standard ICMPv6 messages for router renumbering. This is a dedicated protocol for renumbering, but we are not aware of real network deployment.
o [RFC2894]定义用于路由器重新编号的标准ICMPv6消息。这是一个用于重新编号的专用协议，但我们不知道实际的网络部署。
Some renumbering operations could be automatically processed by management tools in order to make the renumbering process more efficient and accurate. The tools may be designed specifically for renumbering, or common tools could be utilized for some of the renumbering operations.
一些重新编号操作可以由管理工具自动处理，以便使重新编号过程更加高效和准确。这些工具可能是专门为重新编号而设计的，或者一些重新编号操作可以使用通用工具。
Following are examples of such tools:
以下是此类工具的示例：
o IP address management (IPAM) tools. There are both commercial and open-source solutions. IPAM tools are used to manage IP address plans and usually integrate the DHCPv6 and DNS services together as a whole solution. Many mature commercial tools can support management operations, but normally they do not have dedicated renumbering functions. However, the integrated DNS/DHCPv6 services and address management function can obviously facilitate the renumbering process.
o IP地址管理（IPAM）工具。有商业解决方案和开源解决方案。IPAM工具用于管理IP地址计划，通常将DHCPv6和DNS服务集成为一个整体解决方案。许多成熟的商业工具可以支持管理操作，但通常没有专门的重新编号功能。但是，集成的DNS/DHCPv6服务和地址管理功能显然可以促进重新编号过程。
o Third-party tools. Some organizations use third-party tools to push configuration to devices. This is sometimes used as a supplement to vendor-specific solutions. A representative of such a third-party tool is [CFENGINE].
o 第三方工具。一些组织使用第三方工具将配置推送到设备上。这有时用作供应商特定解决方案的补充。此类第三方工具的代表是[CFENGINE]。
o Macros. [LEROY] proposed a mechanism of macros to automatically update the address-relevant entries/configurations inside the DNS, firewall, etc. The macros can be delivered through the SOAP protocol from a network management server to the managed devices.
o 宏。[LEROY]提出了一种宏机制，用于自动更新DNS、防火墙等内部的地址相关条目/配置。宏可以通过SOAP协议从网络管理服务器传送到受管设备。
o Asset management tools/systems. These tools may provide the ability to manage configuration files in devices so that it is convenient to update the address-relevant configuration in these devices.
o 资产管理工具/系统。这些工具可以提供管理设备中配置文件的能力，以便方便地更新这些设备中与地址相关的配置。
o [RFC4192] proposed a procedure for renumbering an IPv6 network without a flag day. The document includes a set of operational suggestions that can be followed step by step by network administrators. It should be noted that the administrators need to carefully deal with the address selection issue, while the old and new prefixes are both available during the overlapping period as described in the procedures in [RFC4192]. The address selection policies might need to be updated after renumbering, so the administrator could leverage the address-selection-policy distribution mechanism as described in [6MAN-ADDR-OPT].
o [RFC4192]提出了在没有国旗日的情况下对IPv6网络重新编号的程序。该文档包括一组操作建议，网络管理员可以逐步遵循这些建议。应该注意的是，管理员需要仔细处理地址选择问题，而旧前缀和新前缀在重叠期间都可用，如[RFC4192]中的过程所述。重新编号后可能需要更新地址选择策略，因此管理员可以利用[6MAN-ADDR-OPT]中所述的地址选择策略分发机制。
o [RFC6879] analyzes the enterprise renumbering events and makes recommendations based on the existing renumbering mechanisms. According to the different stages, renumbering considerations are described in three categories: considerations and recommendations during network design, for the preparation of enterprise network renumbering, and during the renumbering operation.
o [RFC6879]分析企业重新编号事件，并根据现有的重新编号机制提出建议。根据不同阶段，重新编号注意事项分为三类：网络设计期间、企业网络重新编号准备期间和重新编号操作期间的注意事项和建议。
When renumbering an IPv6 enterprise site, the key procedural issue is switching the old prefix(es) to a new one(s). A new short prefix may be divided into longer ones for subnets, so we need to carefully manage the prefixes to ensure they are synchronized and coordinated within the whole network.
对IPv6企业站点重新编号时，关键的过程问题是将旧前缀切换为新前缀。对于子网，新的短前缀可能被划分为长前缀，因此我们需要仔细管理前缀，以确保它们在整个网络内同步和协调。
For big enterprises, the new short prefix(es) usually comes down through offline human communication. But, for the SOHO-style (Small Office, Home Office) SMEs (Small & Medium Enterprises), the prefixes might be dynamically received by DHCPv6 servers or routers inside the enterprise networks. The short prefix(es) could be automatically delegated through DHCPv6-PD. Then the downlink DHCPv6 servers or routers could begin advertising the longer prefixes to the subnets.
对于大企业来说，新的短前缀（es）通常是通过离线人际交流来实现的。但是，对于SOHO风格（小型办公室、家庭办公室）的SME（小型和中型企业），前缀可能由企业网络内的DHCPv6服务器或路由器动态接收。短前缀可以通过DHCPv6 PD自动委派。然后，下行DHCPv6服务器或路由器可以开始向子网宣传较长的前缀。
The delegation routers might need to renumber themselves with the new delegated prefixes. So, there should be a mechanism to inform the routers to renumber themselves by delegated prefixes; there should also be a mechanism for the routers to derive addresses automatically based on the delegated prefixes.
委派路由器可能需要使用新的委派前缀重新编号。因此，应该有一种机制来通知路由器通过授权前缀重新编号；路由器还应该有一种机制，根据委派的前缀自动派生地址。
When subnet routers receive the longer prefixes, they can advertise a prefix on a link to which hosts are connected. Host address configuration, rather than routers, is the primary concern for prefix assignment, which is described in Section 5.1.
当子网路由器收到较长的前缀时，它们可以在主机所连接的链路上播发前缀。主机地址配置，而不是路由器，是前缀分配的主要关注点，如第5.1节所述。
o SLAAC and DHCPv6 Interaction Problems
o SLAAC和DHCPv6交互问题
Both DHCPv6 and Neighbor Discovery (ND) protocols have an IP address configuration function, which are suitable for different scenarios. During renumbering, the SLAAC-configured hosts can reconfigure IP addresses by receiving ND Router Advertisement (RA) messages containing new prefix information. (It should be noted that the prefix delivery could be achieved through DHCPv6 according to [PREFIX-DHCPv6]). The DHCPv6-configured hosts can reconfigure addresses by initiating RENEW sessions [RFC3315] when the current addresses' lease times are expired or when they receive reconfiguration messages initiated by the DHCPv6 servers.
DHCPv6和邻居发现（ND）协议都具有IP地址配置功能，适用于不同的场景。在重新编号期间，SLAAC配置的主机可以通过接收包含新前缀信息的ND路由器公告（RA）消息来重新配置IP地址。（需要注意的是，根据[prefix-DHCPv6]），前缀传递可以通过DHCPv6实现。DHCPv6配置的主机可以在当前地址的租用时间到期或收到DHCPv6服务器启动的重新配置消息时，通过启动续订会话[RFC3315]来重新配置地址。
Sometimes the two address configuration modes may be available in the same network. This would add additional complexity for both the hosts and network management.
有时，两种地址配置模式可能在同一网络中可用。这将增加主机和网络管理的额外复杂性。
With the flags defined in RA (ManagedFlag (M) indicating the DHCPv6 service available in the network; OtherConfigFlag (O) indicating other configurations such as DNS/routing), the two separated address configuration modes are correlated. However, the ND protocol does not define the flags as prescriptive but only as advisory. This has led to variation in the behavior of hosts when interpreting the flags; different operating systems have followed different approaches. (For more details, please refer to [DHCPv6-SLAAC] and [6RENUM-SLAAC].)
使用RA中定义的标志（ManagedFlag（M）表示网络中可用的DHCPv6服务；OtherConfigFlag（O）表示DNS/路由等其他配置），这两种独立的地址配置模式相互关联。然而，ND协议并未将标志定义为规定性标志，而仅定义为建议性标志。这导致了在解释标志时主机行为的变化；不同的操作系统采用了不同的方法。（有关更多详细信息，请参阅[DHCPv6 SLAAC]和[6RENUM-SLAAC]。）
The impact of ambiguous M/O flags includes the following aspects:
不明确的M/O标志的影响包括以下方面：
- DHCPv6-configured hosts might not be able to be renumbered by RA
- DHCPv6配置的主机可能无法由RA重新编号
It is unclear whether a DHCPv6-configured host will accept address configuration though RA messages, especially when the M flag transitions from 1 to 0; this depends on the implementation of the operating system. It might not be possible for administrators to only use RA messages for
不清楚DHCPv6配置的主机是否会通过RA消息接受地址配置，特别是当M标志从1转换为0时；这取决于操作系统的实现。管理员可能不可能仅对其使用RA消息
renumbering, since renumbering might fail on some already DHCPv6-configured hosts. This means administrators have to use DHCPv6 reconfiguration for some DHCPv6-configured hosts. It is not convenient, and DHCPv6 reconfiguration is not suitable for bulk usage as analyzed below.
重新编号，因为在某些已配置DHCPv6的主机上重新编号可能会失败。这意味着管理员必须对一些配置了DHCPv6的主机使用DHCPv6重新配置。这并不方便，DHCPv6重新配置不适合批量使用，如下所述。
- DHCPv6-configured hosts might not be able to learn new RA prefixes
- DHCPv6配置的主机可能无法学习新的RA前缀
[RFC5887] mentions that DHCPv6-configured hosts may want to learn about the upstream availability of new prefixes or loss of prior prefixes dynamically by deducing this from periodic RA messages. Relevant standards [RFC4862] [RFC3315] are ambiguous about what approach should be taken by a DHCPv6-configured host when it receives RA messages containing a new prefix. Current behavior depends on the operating system of the host and cannot be predicted or controlled by the network.
[RFC5887]提到，DHCPv6配置的主机可能希望通过从周期性RA消息中推断，动态了解新前缀的上游可用性或先前前缀的丢失。相关标准[RFC4862][RFC3315]对DHCPv6配置的主机在接收包含新前缀的RA消息时应采取的方法不明确。当前行为取决于主机的操作系统，网络无法预测或控制。
- SLAAC-configured hosts might not be able to add a DHCPv6 address(es)
- SLAAC配置的主机可能无法添加DHCPv6地址
The behavior when the host receives RA messages with the M flag set is unspecified.
主机接收设置了M标志的RA消息时的行为未指定。
The host may start a DHCPv6 session and receive the DHCPv6 address configuration, or it may just ignore the messages. Whether the hosts start DHCPv6 configuration is outside the control of the network side.
主机可以启动DHCPv6会话并接收DHCPv6地址配置，也可以忽略消息。主机是否启动DHCPv6配置不在网络端的控制范围内。
o Learning New Prefixes
o 学习新前缀
As described in [RFC5887], "if a site wanted to be multihomed using multiple provider-aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths."
如[RFC5887]所述，“如果一个站点希望使用多个提供商聚合（PA）路由前缀（每个上游提供商一个前缀）进行多址，那么内部路由器将需要一种机制来了解哪些上游提供商和前缀当前可访问（且有效）。在这种情况下，可以动态更新它们的路由器播发消息，以便仅向主机播发当前有效的路由前缀。如果不同的提供程序前缀长度不同，或者如果站点具有非统一的子网前缀长度，则这将显着更加复杂。”
o Restarting After Renumbering
o 重新编号后重新启动
As [RFC2072] mentions, some routers cache IP addresses in some situations, so routers might need to be restarted as a result of site renumbering. While most modern systems support a cache-clear function that eliminates the need for restarts, there are always exceptions that must be taken into account.
正如[RFC2072]提到的，某些路由器在某些情况下会缓存IP地址，因此，由于站点重新编号，路由器可能需要重新启动。虽然大多数现代系统都支持缓存清除功能，无需重新启动，但总有一些例外情况需要考虑。
o Router Naming
o 路由器命名
[RFC4192] states that "To better support renumbering, switches and routers should use domain names for configuration wherever appropriate, and they should resolve those names using the DNS when the lifetime on the name expires". As [RFC5887] described, this capability is not new, and currently it is present in most IPsec VPN implementations. However, many administrators may need to be alerted to the fact that it can be utilized to avoid manual modification during renumbering.
[RFC4192]指出，“为了更好地支持重新编号，交换机和路由器应在适当的情况下使用域名进行配置，并且应在域名的生存期到期时使用DNS解析这些名称”。如[RFC5887]所述，此功能不是新功能，目前它存在于大多数IPsec VPN实现中。但是，可能需要提醒许多管理员，在重新编号过程中可以使用它来避免手动修改。
In conjunction with renumbering the nodes, any configuration or data store containing previous addresses must be updated as well. Some examples include DNS records and filters in various entities such as Access Control Lists (ACLs) in firewalls/gateways.
在对节点重新编号的同时，还必须更新包含以前地址的任何配置或数据存储。一些示例包括各种实体中的DNS记录和过滤器，例如防火墙/网关中的访问控制列表（ACL）。
o Secure Dynamic DNS (DDNS) Update
o 安全动态DNS（DDNS）更新
In real network operations, a DNS update is normally achieved by maintaining a DNS zone file and loading this file into the site's DNS server(s). Synchronization between host renumbering and the updating of its AAAA record is hard. [RFC5887] discusses an alternative that uses the Secure Dynamic DNS Update [RFC3007], in which a host informs its own DNS server when it receives a new address.
在实际网络操作中，DNS更新通常通过维护DNS区域文件并将该文件加载到站点的DNS服务器中来实现。主机重新编号和更新其AAAA记录之间的同步很困难。[RFC5887]讨论了一种使用安全动态DNS更新[RFC3007]的替代方案，其中主机在收到新地址时通知其自己的DNS服务器。
The Secure Dynamic DNS Update has been widely supported by the major DNS implementations, but it hasn't been widely deployed. Normal hosts are not suitable to do the update, mainly because of the complex key-management issues inherited from secure DNS mechanisms, so current practices usually assign DHCP servers to act as DNS clients to request that the DNS server update relevant records [RFC4704]. The key-management problem is tractable in the case of updates for a limited number of servers, so Dynamic DNS
安全动态DNS更新已得到主要DNS实现的广泛支持，但尚未得到广泛部署。普通主机不适合进行更新，主要是因为从安全DNS机制继承的复杂密钥管理问题，因此当前的做法通常将DHCP服务器分配为DNS客户端，以请求DNS服务器更新相关记录[RFC4704]。在更新数量有限的服务器时，密钥管理问题是可以解决的，因此动态DNS
updates could serve as a suitable solution for keeping server DNS records up to date on a typical enterprise network. However, this solution is not easily applicable to hosts in general.
更新可以作为一个合适的解决方案，用于在典型的企业网络上保持服务器DNS记录最新。但是，此解决方案通常不容易适用于主机。
To address the larger use case of arbitrary non-server hosts being renumbered, DHCP servers have to learn that the relevant hosts have changed their addresses and thus trigger the DDNS update. If the hosts were numbered and also renumbered by DHCP, it would be easy for the DHCP servers to learn the address changes; however, if the hosts were numbered by SLAAC, then there could be trouble.
为了解决任意非服务器主机被重新编号的更大用例，DHCP服务器必须了解相关主机已更改其地址，从而触发DDNS更新。如果主机通过DHCP进行编号和重新编号，DHCP服务器将很容易了解地址更改；但是，如果主机由SLAAC编号，则可能会出现问题。
While DNS stores the addresses of hosts in servers, hosts are also configured with the addresses of servers, such as DNS and RADIUS servers [RFC2865]. While renumbering, the hosts must update these addresses if the server addresses change.
虽然DNS将主机地址存储在服务器中，但主机也配置有服务器的地址，例如DNS和RADIUS服务器[RFC2865]。重新编号时，如果服务器地址发生更改，主机必须更新这些地址。
In principle, the addresses of DHCPv6 servers do not need to be updated since they could be dynamically discovered through DHCPv6-relevant multicast messages. But in practice, most relay agents have the option of being configured with a DHCPv6 server address rather than sending to a multicast address. Therefore, the DHCP server addresses update might be an issue in practice.
原则上，DHCPv6服务器的地址不需要更新，因为它们可以通过DHCPv6相关的多播消息动态发现。但实际上，大多数中继代理都可以选择使用DHCPv6服务器地址配置，而不是发送到多播地址。因此，DHCP服务器地址更新在实践中可能是一个问题。
Besides the DNS records and the in-host server address entries, there are also many places in which IP addresses are configured, for example, filters such as ACL and routing policies. There are even more sophisticated cases where the IP addresses are used for deriving values, for example, using the unique portion of the loopback address to generate an ISIS net ID.
除了DNS记录和主机服务器中的地址条目外，还有许多配置IP地址的位置，例如，ACL和路由策略等过滤器。甚至还有更复杂的情况，IP地址用于派生值，例如，使用环回地址的唯一部分生成ISIS网络ID。
In renumbering, updating the IP addresses in all the above mentioned places is burdensome and error-prone. We lack a "one-stop" mechanism to trigger the updates for all the subsystems on a host/server and all the external databases that refer to the IP address update. We break the general "one-stop" gap into the following two aspects.
在重新编号时，更新上述所有位置的IP地址既麻烦又容易出错。我们缺少一个“一站式”机制来触发主机/服务器上所有子系统以及所有引用IP地址更新的外部数据库的更新。我们将一般的“一站式”差距分为以下两个方面。
o Self-Contained Configuration in Individual Devices
o 单个设备中的自包含配置
Ideally, IP addresses can be defined as a value once, and then the administrators can use either keywords or variables to call the value in other places such as a sort of internal inheritance in CLI (command line interface) or other local configurations. This makes it easier to manage a renumbering event by reducing the number of places where a device's configuration must be updated.
理想情况下，可以将IP地址定义为一个值，然后管理员可以使用关键字或变量在其他位置调用该值，例如CLI（命令行界面）或其他本地配置中的某种内部继承。通过减少必须更新设备配置的位置数量，可以更轻松地管理重新编号事件。
However, it still means that every device needs to be individually updated, but only once instead of having to inspect the whole configuration to ensure that none of the separate places that a given IP address occurs is missed.
然而，这仍然意味着每个设备都需要单独更新，但只需更新一次，而不必检查整个配置，以确保不会遗漏给定IP地址出现的任何单独位置。
Among current devices, some routers support defining multiple loopback interfaces that can be called in other configurations. For example, when defining a tunnel, it can call the defined loopback interface to use its address as the local address of the tunnel. This can be considered as a kind of parameterized self-contained configuration. However, this only applies to certain use cases; it is impossible to use the loopback interfaces to represent external devices, and it is not always possible to call loopback interfaces in other configurations. Parameterized self-contained configuration is still a gap that needs to be filled.
在当前设备中，一些路由器支持定义多个可在其他配置中调用的环回接口。例如，在定义隧道时，它可以调用已定义的环回接口，将其地址用作隧道的本地地址。这可以看作是一种参数化的自包含配置。然而，这只适用于某些用例；不可能使用环回接口来表示外部设备，也不可能在其他配置中调用环回接口。参数化自包含配置仍然是一个需要填补的空白。
o Unified Configuration Management among Devices
o 设备间的统一配置管理
This refers to a more formalized central configuration management system, where all changes are made in one place, and the system manages how changes are pushed to the individual devices. This issue contains two aspects, as follows:
这是指一个更正式的中央配置管理系统，其中所有更改都在一个地方进行，系统管理如何将更改推送到各个设备。本期包括以下两个方面：
- Configuration Aggregation
- 配置聚合
Configuration data based on addresses or prefixes are usually spread out in various devices. As [RFC5887] describes, some address configuration data might be widely dispersed and much harder to find. Some will inevitably be found only after the renumbering event. Because there's a big gap in configuration aggregation, it is hard to get all the relevant configuration data together in one place.
基于地址或前缀的配置数据通常分布在各种设备中。正如[RFC5887]所描述的，一些地址配置数据可能分布广泛，很难找到。只有在重新编号事件之后，才能不可避免地找到一些。因为在配置聚合方面存在很大的差距，所以很难将所有相关的配置数据集中在一个地方。
- Configuration Update Automation
- 配置更新自动化
As mentioned in Section 3.2, [LEROY] proposes a mechanism that can automatically update the configurations. The mechanism utilizes macros suitable for various devices such as routers and firewalls to update configurations based on the new prefix. Such an automation tool is valuable for renumbering because it can reduce manual operation, which is error-prone and inefficient.
如第3.2节所述，[LEROY]提出了一种能够自动更新配置的机制。该机制利用适用于路由器和防火墙等各种设备的宏，根据新前缀更新配置。这种自动化工具对于重新编号很有价值，因为它可以减少容易出错且效率低下的手动操作。
Besides the macros, [LEROY] also proposes the use of SOAP to deliver the macros to the devices. Along with SOAP, we may consider whether it is possible and suitable to use other standardized protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241].
除了宏之外，[LEROY]还建议使用SOAP将宏传递到设备。与SOAP一起，我们可以考虑是否可能并且适合使用其他标准化协议，例如网络配置协议（NETCONF）[RCF6241]。
In current real networks, most devices use vendor-private protocols to update configurations, so it is not necessarily valid to assume that there is going to be a formalized configuration management system to leverage. Although there are some vendor-independent tools as mentioned in Section 3.2, a standard and comprehensive way to uniformly update configurations in multi-vendor devices is still missing.
在当前的实际网络中，大多数设备使用供应商专用协议来更新配置，因此，假设将有一个正式的配置管理系统可供利用并不一定有效。尽管第3.2节中提到了一些独立于供应商的工具，但仍然缺少统一更新多供应商设备配置的标准和全面方法。
From the perspective of network management, renumbering is an event that may need additional processes to make it easier and more manageable.
从网络管理的角度来看，重新编号是一个可能需要额外过程才能使其更容易管理的事件。
The process of renumbering could benefit from hosts or servers being made aware of an occurrence of a renumbering event. Following are several examples of additional processes that may ease renumbering.
重新编号的过程可能受益于主机或服务器知道发生了重新编号事件。下面是一些可以简化重新编号的附加过程的示例。
o A notification mechanism may be needed to indicate to hosts that a renumbering event has changed some DNS records in DNS servers (normally, in an enterprise, it is a local recursive DNS server(s)), and then the hosts might want to refresh the DNS cache. That mechanism may also need to indicate that such a change will happen at a specific time in the future.
o 可能需要一种通知机制来向主机指示重新编号事件已更改DNS服务器中的某些DNS记录（通常，在企业中，它是本地递归DNS服务器），然后主机可能希望刷新DNS缓存。该机制可能还需要表明，这种变化将在未来某个特定时间发生。
o As suggested in [RFC4192], if the DNS service can be given prior notice about a renumbering event, then delay in the transition to new IPv6 addresses could be reduced and thus improve the efficiency of renumbering.
o 正如[RFC4192]中所建议的，如果DNS服务可以事先得到关于重新编号事件的通知，则可以减少向新IPv6地址过渡的延迟，从而提高重新编号的效率。
o Router awareness: In a site with multiple domains that are connected by border routers, all border routers should be aware of renumbering in one domain or multiple domains and update the internal forwarding tables and the address-/prefix-based filters accordingly to correctly handle inbound packets.
o 路由器感知：在由边界路由器连接的多个域的站点中，所有边界路由器都应该知道在一个域或多个域中重新编号，并相应地更新内部转发表和基于地址/前缀的筛选器，以正确处理入站数据包。
o Ingress filtering: ISPs normally enable an ingress filter to drop packets with source addresses from other ISPs at the end-site routers to prevent IP spoofing [RFC2827]. In a multihomed site with multiple PA prefixes, the ingress router of ISP A should be notified if ISP B initiates a renumbering event in order to properly update its filters to permit the new legitimate prefix(es). For large enterprises, it might be practical to manage this new legitimate prefix information through human communication. However, for the millions of small enterprises, an automated notification mechanism is needed.
o 入口过滤：ISP通常允许入口过滤器从终端站点路由器的其他ISP丢弃带有源地址的数据包，以防止IP欺骗[RFC2827]。在具有多个PA前缀的多址站点中，如果ISP B启动重新编号事件，则应通知ISP a的入口路由器，以便正确更新其过滤器以允许使用新的合法前缀。对于大型企业来说，通过人工通信管理这种新的合法前缀信息可能是切实可行的。然而，对于数以百万计的小企业来说，需要一种自动通知机制。
o Log collectors: In the NMS (network management system), log collectors that collect logs through syslog, SNMP notification, IPFIX, etc. usually treat the UDP message source IP addresses as the host or router IDs. When one source IP address is changed, the log collectors will consider that a new device appeared in the network. Therefore, a mechanism is needed for the NMS applications to learn the renumbering event including the mappings of old and new IP addresses for each host/router, so that they could update the address-relevant mappings as described in Section 7.2.
o 日志收集器：在NMS（网络管理系统）中，通过syslog、SNMP通知、IPFIX等收集日志的日志收集器通常将UDP消息源IP地址视为主机或路由器ID。当一个源IP地址被改变时，日志收集器将考虑新的设备出现在网络中。因此，NMS应用程序需要一种机制来了解重新编号事件，包括每个主机/路由器的新旧IP地址映射，以便它们能够更新第7.2节中描述的地址相关映射。
o DNS Update Synchronization
o DNS更新同步
The DNS changes must be coordinated with node address configuration changes. DNS has a latency issue of propagating information from the server to the resolver. The latency is mainly caused by the Time to Live (TTL) assigned to individual DNS records and the timing of updates from primary to secondary servers [RFC4192].
DNS更改必须与节点地址配置更改相协调。DNS存在将信息从服务器传播到解析程序的延迟问题。延迟主要由分配给单个DNS记录的生存时间（TTL）以及从主服务器到辅助服务器的更新时间造成[RFC4192]。
Ideally, during a renumbering operation, the DNS TTLs should always be shorter than any other lifetimes associated with an address. If the TTLs were set correctly, then the DNS latency could be well controlled. However, there might be some exceptional situations in which the DNS TTLs were already set too long for the time available to plan and execute a renumbering event. In these situations, there are currently no mechanisms to deal with the already configured long DNS TTLs.
理想情况下，在重新编号操作期间，DNS TTL应始终短于与地址关联的任何其他生存期。如果TTL设置正确，那么DNS延迟可以得到很好的控制。但是，可能存在一些例外情况，其中DNS TTL设置的时间过长，无法计划和执行重新编号事件。在这些情况下，目前没有机制来处理已配置的长DNS TTL。
o NMS Address-Relevant Mapping Synchronization
o NMS地址相关映射同步
As described in Section 7.1, the NMS needs to learn the renumbering event and thus correlate the old and new address in the logs. If the NMS applies unique IDs for the hosts or routers, then the mappings between the unique IDs and IP addresses also need to be updated after renumbering.
如第7.1节所述，NMS需要了解重新编号事件，从而关联日志中的新旧地址。如果NMS为主机或路由器应用唯一ID，则在重新编号后还需要更新唯一ID和IP地址之间的映射。
While treating renumbering as a network event, mechanisms to monitor the renumbering process might be needed to inform the administrators whether the renumbering has been successful. Considering that the address configuration operation might be stateless (if ND is used for renumbering), it is difficult to monitor.
在将重新编号视为网络事件时，可能需要监控重新编号过程的机制来通知管理员重新编号是否成功。考虑到地址配置操作可能是无状态的（如果ND用于重新编号），很难进行监视。
Since multicast and mobility are special use cases that might not be included in routine or common renumbering operations, they are discussed separately in this miscellaneous section.
由于多播和移动性是特殊的用例，可能不包括在例行或常见的重新编号操作中，因此在本杂项部分中单独讨论它们。
From the perspective of interface renumbering operations, renumbering a multicast address is the same as renumbering a unicast address. So this section mainly discusses the issues from the perspective of the impact to the multicast application systems caused by renumbering. Renumbering also has an impact on multicast. Renumbering of unicast addresses affects multicast even if the multicast addresses are not changed. There may also be cases where the multicast addresses need to be renumbered.
从接口重新编号操作的角度来看，对多播地址重新编号与对单播地址重新编号相同。因此本节主要从重新编号对组播应用系统的影响的角度来讨论这些问题。重新编号也会对多播产生影响。单播地址的重新编号会影响多播，即使多播地址没有更改。也可能存在需要对多播地址重新编号的情况。
o Renumbering of Multicast Sources
o 多播源的重新编号
If a host that is a multicast source is renumbered, the application on the host may need to be restarted for it to successfully send packets with the new source address.
如果对作为多播源的主机重新编号，则可能需要重新启动主机上的应用程序才能成功发送具有新源地址的数据包。
For ASM (Any-Source Multicast), the impact on a receiver is that a new source appears to start sending and it no longer receives from the previous source. Whether this is an issue depends on the application, but we believe it is likely not to be a major issue.
对于ASM（任意源多播），对接收器的影响是新源开始发送，而不再从以前的源接收。这是否是一个问题取决于应用程序，但我们认为这可能不是一个主要问题。
For SSM (Source-Specific Multicast) however, there is one significant problem. The receiver needs to learn which source addresses it must join. Some applications may provide their own method for learning sources, where the source application may somehow signal the receiver.
然而，对于SSM（源特定多播），有一个重要的问题。接收器需要了解它必须加入的源地址。一些应用程序可能提供自己的学习源的方法，其中源应用程序可能以某种方式向接收器发送信号。
Otherwise, the receiver may, for example, need to get new SDP (Session Description Protocol) information with the new source address. This is similar to the process for learning a new group address; see the "Renumbering of Multicast Addresses" topic below.
否则，接收机可能例如需要获得具有新源地址的新SDP（会话描述协议）信息。这类似于学习新的组地址的过程；请参阅下面的“多播地址重新编号”主题。
o Renumbering of Rendezvous-Point
o 会合点重新编号
If the unicast addresses of routers in a network are renumbered, then the RP (Rendezvous-Point) address is also likely to change for at least some groups. An RP address is needed by PIM-SM (Protocol Independent Multicast - Sparse Mode) to provide ASM and for Bidir PIM. Changing the RP address is not a major issue, except that the multicast service may be impacted while the new RP addresses are configured. If dynamic protocols are used to
如果网络中路由器的单播地址被重新编号，那么至少某些组的RP（集合点）地址也可能改变。PIM-SM（协议独立多播-稀疏模式）需要一个RP地址来提供ASM和Bidir PIM。更改RP地址不是主要问题，但配置新RP地址时可能会影响多播服务。如果使用动态协议
distribute group-to-RP mappings, the change can be fairly quick and any impact time should be very brief. However, if routers are statically configured, the time impacted depends on how long it takes to update all the configurations.
分发组到RP映射，更改可以相当快，任何影响时间都应该非常短。但是，如果路由器是静态配置的，则受影响的时间取决于更新所有配置所需的时间。
For PIM-SM, one typically switches to SPT (Shortest-Path-Tree) when the first packet is received by the last-hop routers. Forwarding on the SPT should not be impacted by the change of IP address. A network operator should be careful not to deprecate the previous mapping before configuring a new one, because implementations may revert to Dense Mode if no RP is configured.
对于PIM-SM，当最后一跳路由器接收到第一个数据包时，通常会切换到SPT（最短路径树）。SPT上的转发不应受到IP地址更改的影响。在配置新映射之前，网络运营商应小心不要拒绝使用以前的映射，因为如果未配置RP，实现可能会恢复到密集模式。
o Renumbering of Multicast Addresses
o 多播地址的重新编号
In general, multicast addresses can be chosen independently of the unicast addresses, and the multicast addresses can remain fixed even if the unicast addresses are renumbered. However, for IPv6, there are useful ways of deriving multicast addresses from unicast addresses, such as described in "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] and "Embedded-RP IPv6 Multicast Addresses" [RFC3956]. In those cases, the multicast addresses used may have to be renumbered.
通常，可以独立于单播地址选择多播地址，并且即使单播地址被重新编号，多播地址也可以保持固定。然而，对于IPv6，存在从单播地址派生多播地址的有用方法，如“基于单播前缀的IPv6多播地址”[RFC3306]和“嵌入式RP IPv6多播地址”[RFC3956]中所述。在这些情况下，可能需要对所使用的多播地址重新编号。
Renumbering group addresses may be complicated. For multicast, it is common to use literal addresses and not DNS. When multicast addresses are changed, source applications need to be reconfigured and restarted.
对组地址重新编号可能很复杂。对于多播，通常使用文本地址而不是DNS。更改多播地址时，需要重新配置并重新启动源应用程序。
Multicast receivers need to learn the new group addresses to join.
多播接收者需要学习新的组地址才能加入。
Note that for SSM, receivers need to learn which multicast channels to join. A channel is a source and group pair. This means that for an SSM application, a change of source address is likely to have the same effect as a change of group address.
请注意，对于SSM，接收器需要了解要加入哪些多播信道。通道是源和组对。这意味着对于SSM应用程序，源地址的更改可能与组地址的更改具有相同的效果。
Some applications may have dynamic methods of learning which groups (and possibly sources) to join. If not, the application may have to be reconfigured and restarted.
有些应用程序可能有动态的方法来学习加入哪些组（可能还有来源）。否则，可能必须重新配置并重新启动应用程序。
One common way for receivers to learn the necessary parameters is by use of SDP. SDP information may be distributed via various application protocols or from a file. An SDP file may be distributed via HTTP, email, etc. If a user is using a web browser and clicking on a link to launch the application with the necessary data, it may be a matter of closing the current application and re-clicking the link.
接收机学习必要参数的一种常见方法是使用SDP。SDP信息可以通过各种应用协议或文件分发。SDP文件可以通过HTTP、电子邮件等方式分发。如果用户使用web浏览器并单击链接以启动包含必要数据的应用程序，则可能需要关闭当前应用程序并重新单击链接。
In summary, currently, multicast renumbering issues are basically handled by application-specific methods. There is no standard way to guarantee that multicast service could live across a renumbering event.
总之，目前，多播重新编号问题基本上是通过应用程序特定的方法来处理的。并没有标准的方法来保证多播服务能够在重新编号的事件中生存。
As described in [RFC5887], if a mobile node's home address changes unexpectedly, the node can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. However, if the mobile node is disconnected at the time of home address renumbering, it will no longer know a valid subnet anycast address for its home agent, leaving it to deduce a valid address on the basis of DNS information.
如[RFC5887]中所述，如果移动节点的家庭地址意外更改，则可以通过移动前缀请求和移动前缀广告ICMPv6消息[RFC6275]通知节点在家庭站点使用的新全局路由前缀。但是，如果移动节点在家庭地址重新编号时断开连接，则它将不再知道其家庭代理的有效子网选播地址，从而让它根据DNS信息推断有效地址。
So, for Mobile IP, we need a better mechanism to handle the change of home agent address while the mobile address is disconnected.
因此，对于移动IP，我们需要一种更好的机制来处理移动地址断开时归属代理地址的变化。
The following is a summary of the gaps identified previously in this document that are considered solvable, but may require process or protocol changes to resolve.
以下是本文件先前确定的差距的总结，这些差距被认为是可以解决的，但可能需要改变流程或协议才能解决。
o A mechanism informing the routers to renumber themselves by delegated prefixes.
o 一种通知路由器按指定前缀重新编号的机制。
o A mechanism for the routers to derive addresses automatically based on the delegated prefixes.
o 路由器根据委派的前缀自动导出地址的一种机制。
o Host Address Configuration
o 主机地址配置
- DHCPv6-configured hosts might not be able to be renumbered by RA on some current implementations.
- 在某些当前实现中，DHCPv6配置的主机可能无法由RA重新编号。
- DHCPv6-configured hosts might not be able to learn new RA prefixes on some current implementations.
- DHCPv6配置的主机可能无法在某些当前实现中学习新的RA前缀。
- SLAAC-configured hosts might not be able to add DHCPv6 address(es) on some current implementations.
- SLAAC配置的主机可能无法在某些当前实现上添加DHCPv6地址。
o Router Address Configuration
o 路由器地址配置
- A mechanism for interior routers in a multihomed site to learn which upstream providers and prefixes are currently reachable.
- 多址站点中的内部路由器了解当前可访问的上游提供者和前缀的一种机制。
- Cache-clear might need to restart (rarely in modern routers).
- 缓存清除可能需要重新启动（在现代路由器中很少）。
- Use of router domain names is not widely learned or deployed by administrators.
- 路由器域名的使用并没有被管理员广泛学习或部署。
o DNS Records Update
o DNS记录更新
- For key-management scalability issues, secure dynamic DNS update is usually done by DHCP servers on behalf of the hosts, so it might not be practical for SLAAC-configured hosts to do secure DDNS.
- 对于密钥管理可伸缩性问题，安全的动态DNS更新通常由DHCP服务器代表主机完成，因此SLAAC配置的主机执行安全的DDN可能不太现实。
o In-Host Server Address Update
o 主机内服务器地址更新
- DHCP relays might be configured with DHCP server addresses rather than by sending multicast messages to discover the DHCP server dynamically, so updating the DHCP server addresses might be an issue in practice.
- DHCP中继可能配置有DHCP服务器地址，而不是通过发送多播消息来动态发现DHCP服务器，因此在实践中更新DHCP服务器地址可能是一个问题。
o Address Update in Scattered Configurations
o 分散配置中的地址更新
- For devices that don't support parameterized configuration, administrators need to individually update all devices in which IP addresses were previously configured.
- 对于不支持参数化配置的设备，管理员需要单独更新以前配置了IP地址的所有设备。
- It is hard to get all the address-relevant configurations spread in various devices through one place.
- 很难通过一个地方将所有与地址相关的配置分布在各种设备中。
- Uniformly updating configurations in multi-vendor devices is currently a big gap that needs to be filled.
- 统一更新多供应商设备中的配置是目前需要填补的一大空白。
o Renumbering Notification
o 重新编号通知
- A mechanism to indicate a host's local recursive DNS is going to be renumbered.
- 指示主机的本地递归DNS将被重新编号的机制。
- A prior notice about a renumbering event for DNS.
- 关于DNS重新编号事件的事先通知。
- A mechanism for border routers to know internal partial renumbering.
- 边界路由器了解内部部分重新编号的机制。
- For multihomed sites, a mechanism is needed to notify the egress router connecting to ISP A that the egress router connecting to ISP B has initiated renumbering.
- 对于多址站点，需要一种机制来通知连接到ISP a的出口路由器连接到ISP B的出口路由器已启动重新编号。
- A mechanism is needed for the NMS applications to learn the renumbering event, so that they could correlate the old and new addresses in the logs, and update the unique ID of the device and address mappings.
- NMS应用程序需要一种机制来学习重新编号事件，以便它们能够关联日志中的新旧地址，并更新设备的唯一ID和地址映射。
o Synchronization Management
o 同步管理
- DNS information propagation latency issue.
- DNS信息传播延迟问题。
- Mechanisms are needed for the NMS applications to correlate the old and new addresses in logs and to update the unique ID of the device and address mappings.
- NMS应用程序需要机制来关联日志中的新旧地址，并更新设备的唯一ID和地址映射。
o Renumbering Monitoring
o 重新编号监测
- Mechanisms to monitor the process and feedback of renumbering might be needed.
- 可能需要监测重新编号过程和反馈的机制。
o Multicast
o 多播
- A mechanism for SSM receivers to learn the source addresses when multicast sources are renumbered.
- 当多播源重新编号时，SSM接收器学习源地址的一种机制。
o Mobility
o 流动性
- A better mechanism to handle a change of home agent address while the mobile address is disconnected.
- 在移动地址断开连接时处理归属代理地址更改的更好机制。
This section lists gaps that have been identified by other documents but are considered unsolvable.
本节列出了其他文件已确定但认为无法解决的差距。
o RA Prefix Lifetime Limitation
o RA前缀寿命限制
Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime." So when renumbering, if the previous RemainingLifetime is longer than two hours, it is impossible to reduce a prefix's lifetime to less than two hours. This limitation is to prevent denial-of-service attacks.
[RFC4862]第5.5.3节规定，“如果收到的有效生存期大于2小时或大于RemainingLifetime，则将相应地址的有效生存期设置为公布的有效生存期。”因此，在重新编号时，如果前一个RemainingLifetime大于2小时，不可能将前缀的生存时间缩短到两小时以下。此限制是为了防止拒绝服务攻击。
o DNS Authority
o DNS授权
In an enterprise that hosts servers on behalf of collaborators and customers, it is often the case that DNS zones outside the administrative control of the hosting enterprise maintain resource records concerning addresses for hosted nodes within its address space. When the hosting enterprise renumbers, it does not have sufficient authority to change those records.
在代表合作者和客户托管服务器的企业中，托管企业管理控制之外的DNS区域通常会在其地址空间内维护有关托管节点地址的资源记录。当托管企业重新编号时，它没有足够的权限更改这些记录。
This is an operational and policy issue. It is out of scope for this document to consider a technical solution or to propose an additional protocol or mechanism to standardize the interaction between DNS systems for authority negotiations.
这是一个操作和政策问题。本文件不考虑技术解决方案或提出附加协议或机制来规范DNS系统之间的交互以进行权威协商。
o DNS Entries
o DNS条目
DNS entries commonly have matching reverse DNS entries that will also need to be updated during renumbering. It might not be possible to combine forward and reverse DNS entry updates in one procedure where addresses are not being managed using DHCP.
DNS条目通常具有匹配的反向DNS条目，这些条目在重新编号期间也需要更新。如果不使用DHCP管理地址，则可能无法在一个过程中组合正向和反向DNS条目更新。
o DNS Data Structure Optimization
o DNS数据结构优化
[RFC2874] proposed an A6 record type for DNS recording of the IPv6 address and prefix. Several extensions to DNS query and processing were also proposed. A6 was designed to be a replacement for the AAAA record. The changes were designed to facilitate network renumbering and multihoming. With the A6 record and the extensions, an IPv6 address could be defined by
[RFC2874]提出了一种A6记录类型，用于IPv6地址和前缀的DNS记录。还提出了对DNS查询和处理的若干扩展。A6旨在取代AAAA记录。这些变化旨在促进网络重新编号和多归属。有了A6记录和扩展，IPv6地址可以由
using multiple DNS records. This feature would increase the complexity of resolvers but reduce the cost of zone file maintenance, so renumbering could be easier than with the AAAA record.
使用多个DNS记录。此功能将增加解析程序的复杂性，但会降低区域文件维护的成本，因此重新编号可能比使用AAAA记录更容易。
[RFC2874] has been deprecated and moved to Historic status by
[RFC6563]. The A6 record has not been widely used and has been
shown to have various problems and disadvantages (see Section 2 in
[RFC6563]). The idea of a structured record to separate prefix
and suffix is still potentially valuable for renumbering, but
avoiding the problems of the A6 record would require a major
development effort.
[RFC2874] has been deprecated and moved to Historic status by
[RFC6563]. The A6 record has not been widely used and has been
shown to have various problems and disadvantages (see Section 2 in
[RFC6563]). The idea of a structured record to separate prefix
and suffix is still potentially valuable for renumbering, but
avoiding the problems of the A6 record would require a major
development effort.
o For the transport layer, [RFC5887] said that TCP connections and UDP flows are rigidly bound to a given pair of IP addresses.
o 对于传输层，[RFC5887]表示TCP连接和UDP流严格绑定到给定的一对IP地址。
o For the application layer, in general, we can assert that any implementation is at risk from renumbering if it does not check whether an address is valid each time it starts session resumption (e.g., a laptop wakes from sleep state). It is also more or less risky when it opens a new communications session by using cached addresses.
o 对于应用层，一般来说，我们可以断言，如果任何实现在每次启动会话恢复时（例如，笔记本电脑从睡眠状态唤醒）都没有检查地址是否有效，那么它将面临重新编号的风险。当它使用缓存地址打开一个新的通信会话时，风险也或多或少。
We considered the above two points (ID/Locator overloading in transport layer and address caching in application layer) fundamental issues that might not be proper to deal with just in terms of renumbering.
我们考虑了以上两点（传输层中的ID/Locator重载和应用层中的地址缓存）可能不适合仅在重新编号方面处理的基本问题。
o Prefix Validation
o 前缀验证
Prefixes from the ISP may need authentication to prevent prefix fraud. Announcing changes of site prefix to other sites (for example, those that configure routers or VPNs to point to the site in question) also needs validation.
ISP的前缀可能需要身份验证以防止前缀欺诈。向其他站点（例如，那些配置路由器或VPN以指向相关站点的站点）宣布站点前缀的更改也需要验证。
In the LAN, Secure DHCPv6 [SECURE-DHCPv6] or Secure Neighbor Discovery (SEND) [RFC3971] deployment may be needed to validate prefixes.
在LAN中，可能需要安全DHCPv6[Secure-DHCPv6]或安全邻居发现（SEND）[RFC3971]部署来验证前缀。
o Influence on Security Controls
o 对安全控制的影响
During renumbering, security controls (e.g., ACLs) protecting legitimate resources should not be interrupted. For example, if some addresses are in a blacklist, they should not escape from the blacklist due to renumbering.
在重新编号期间，保护合法资源的安全控制（如ACL）不应中断。例如，如果某些地址在黑名单中，则它们不应因重新编号而从黑名单中逃逸。
Addresses in SEND certificates will need to get updated when renumbering. During the overlap between old and new addresses, both certificates must remain valid.
重新编号时，需要更新发送证书中的地址。在新旧地址重叠期间，两个证书必须保持有效。
o Security Protection for Renumbering Notification
o 重新编号通知的安全保护
Section 7.1 mentions possible notification mechanisms to signal a change in the DNS system or in the border routers related to a renumbering event. Since the DNS system and border routers are key elements in any network, and they might take action according to the notification, a security authentication for the renumbering notification is needed.
第7.1节提到了可能的通知机制，以通知DNS系统或边界路由器中与重新编号事件相关的更改。由于DNS系统和边界路由器是任何网络中的关键元素，它们可能根据通知采取行动，因此需要对重新编号通知进行安全认证。
o Security Protection for Configuration Update
o 配置更新的安全保护
Automated configuration update approaches like [LEROY] would increase the risk since a bad actor with the right permission could cause havoc to the networks.
像[LEROY]这样的自动配置更新方法会增加风险，因为拥有正确权限的坏角色可能会对网络造成严重破坏。
This work adopts significant amounts of content from [RFC5887]. In addition, it draws largely from the "DNS Authority" topic in Section 10.2 from [IPv6-RENUM-THINK]. Both documents offer such important input for this work that some principles and considerations applied in this work are implicitly inherited from them. So thanks go to Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some useful materials were provided by Oliver Bonaventure and his student, Damien Leroy.
本作品采用了[RFC5887]中的大量内容。此外，它主要借鉴了[IPv6 RENUM THINK]第10.2节中的“DNS授权”主题。这两份文件都为这项工作提供了如此重要的投入，以至于在这项工作中应用的一些原则和考虑因素都隐含地继承自它们。感谢兰德尔·阿特金森、汉努·弗林克、蒂姆·乔恩、马克·汤普森和艾伦·福特。Oliver Bonaventure和他的学生Damien Leroy提供了一些有用的资料。
Many useful comments and contributions were made by Ted Lemon, Lee Howard, Robert Sparks, S. Moonesamy, Fred Baker, Sean Turner, Benoit Claise, Stephen Farrell, Brian Haberman, Joel Jaeggli, Eric Vyncke, Phillips Matthew, Benedikt Stockebrand, Gustav Reinsberger, Teco Boot, and other members of the 6renum WG.
Ted Lemon、Lee Howard、Robert Sparks、S.Moonesamy、Fred Baker、Sean Turner、Benoit Claise、Stephen Farrell、Brian Haberman、Joel Jaeggli、Eric Vyncke、Phillips Matthew、Benedikt Stockebrand、Gustav Reinsberger、Teco Boot和6renum工作组的其他成员发表了许多有用的评论和贡献。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]克劳福德，M.，“IPv6的路由器重新编号”，RFC 28942000年8月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，2006年10月。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]Carpenter，B.，Atkinson，R.，和H.Flinck，“重新编号仍然需要工作”，RFC 5887，2010年5月。
[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月。
[RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to Historic Status", RFC 6563, March 2012.
[RFC6563]Jiang，S.，Conrad，D.，和B.Carpenter，“将A6推向历史地位”，RFC 6563，2012年3月。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013.
[RFC6866]Carpenter，B.和S.Jiang，“企业网络中使用静态地址重新编号IPv6主机的问题声明”，RFC 6866，2013年2月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879]Jiang，S.，Liu，B.和B.Carpenter，“IPv6企业网络重新编号方案、注意事项和方法”，RFC 6879，2013年2月。
[6MAN-ADDR-OPT] Matsumoto, A., Fujisaki T., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, August 2013.
[6MAN-ADDR-OPT]Matsumoto，A.，Fujisaki T.和T.Chown，“使用DHCPv6分发地址选择策略”，正在进行的工作，2013年8月。
[6RENUM-SLAAC] Liu, B., "DHCPv6/SLAAC Address Configuration Switching for Host Renumbering", Work in Progress, January 2013.
[6RENUM-SLAAC]Liu，B.，“用于主机重新编号的DHCPv6/SLAAC地址配置切换”，正在进行的工作，2013年1月。
[CFENGINE] CFEngine, <http://cfengine.com/what-is-cfengine>.
[CFENGINE]CFENGINE<http://cfengine.com/what-is-cfengine>.
[DHCPv6-SLAAC] Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, February 2013.
[DHCPv6 SLAAC]Liu，B.和R.Bonica，“DHCPv6/SLAAC解决配置交互问题声明”，正在进行的工作，2013年2月。
[IPv6-RENUM-THINK] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
[IPv6 RENUM THINK]Chown，T.，Thompson，M.，Ford，A.，和S.Venaas，“对IPv6网络重新编号时需要考虑的事情”，正在进行的工作，2006年9月。
[LEROY] Leroy, D. and O. Bonaventure, "Preparing network
configurations for IPv6 renumbering", International of
Network Management, 2009, <http://inl.info.ucl.ac.be/
system/files/dleroy-nem-2009.pdf>
[LEROY] Leroy, D. and O. Bonaventure, "Preparing network
configurations for IPv6 renumbering", International of
Network Management, 2009, <http://inl.info.ucl.ac.be/
system/files/dleroy-nem-2009.pdf>
[PREFIX-DHCPv6] Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment in DHCPv6", Work in Progress, February 2013.
[PREFIX-DHCPv6]Jiang，S.，Xia，F.，和B.Sarikaya，“DHCPv6中的前缀分配”，正在进行的工作，2013年2月。
[SECURE-DHCPv6] Jiang, S. and Shen S., "Secure DHCPv6 Using CGAs", Work in Progress, September 2012.
[SECURE-DHCPv6]蒋S.和沈S.，“使用CGAs保护DHCPv6”，正在进行的工作，2012年9月。
Authors' Addresses
作者地址
Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China EMail: leo.liubing@huawei.com
刘冰华为技术有限公司Q14，中国北京市海淀区北青路156号华为校区，邮编100095电子邮件：leo。liubing@huawei.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com
中国北京海淀区北青路156号华为校区盛江华为技术有限公司Q14邮编：100095电子邮件：jiangsheng@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com
Brian Carpenter奥克兰大学计算机系PB 92019奥克兰，1142新西兰电子邮件：布瑞恩。E。carpenter@gmail.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 United States EMail: stig@cisco.com
Stig Venaas Cisco Systems Tasman Drive San Jose，CA 95134美国电子邮件：stig@cisco.com
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States Phone: +1 703-561-2540 EMail: wesley.george@twcable.com
韦斯利·乔治·时代华纳有线电视13820美国弗吉尼亚州赫恩登日出谷大道20171电话：+1703-561-2540电子邮件：韦斯利。george@twcable.com