Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6879 B. Liu
Category: Informational Huawei Technologies Co., Ltd.
ISSN: 2070-1721 B. Carpenter
University of Auckland
February 2013
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6879 B. Liu
Category: Informational Huawei Technologies Co., Ltd.
ISSN: 2070-1721 B. Carpenter
University of Auckland
February 2013
IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
IPv6企业网络重新编号方案、注意事项和方法
Abstract
摘要
This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.
本文档分析导致重新编号的事件，并介绍当前的重新编号方法。它们分为三类：网络设计期间适用的、重新编号准备期间适用的和重新编号操作期间适用的。
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/rfc6879.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6879.
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 ....................................................2
2. Enterprise Network Illustration for Renumbering .................3
3. Enterprise Network Renumbering Scenario Categories ..............5
3.1. Renumbering Caused by External Network Factors .............5
3.2. Renumbering Caused by Internal Network Factors .............5
4. Network Renumbering Considerations and Current Methods ..........6
4.1. Considerations and Current Methods during Network Design ...6
4.2. Considerations and Current Methods for the
Preparation of Renumbering ................................10
4.3. Considerations and Current Methods during
Renumbering Operation .....................................11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
1. Introduction ....................................................2
2. Enterprise Network Illustration for Renumbering .................3
3. Enterprise Network Renumbering Scenario Categories ..............5
3.1. Renumbering Caused by External Network Factors .............5
3.2. Renumbering Caused by Internal Network Factors .............5
4. Network Renumbering Considerations and Current Methods ..........6
4.1. Considerations and Current Methods during Network Design ...6
4.2. Considerations and Current Methods for the
Preparation of Renumbering ................................10
4.3. Considerations and Current Methods during
Renumbering Operation .....................................11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Site renumbering is difficult. Network managers frequently attempt to avoid future renumbering by numbering their network resources from Provider-Independent (PI) address space. However, widespread use of PI address space would aggravate BGP4 scaling problems [RFC4116] and, depending on Regional Internet Registry (RIR) policies, PI space is not always available for enterprises of all sizes. Therefore, it is desirable to develop mechanisms that simplify IPv6 renumbering for enterprises.
站点重新编号很困难。网络管理员经常试图通过从独立于提供商（PI）的地址空间对其网络资源进行编号来避免将来重新编号。然而，PI地址空间的广泛使用会加剧BGP4的扩展问题[RFC4116]，并且，根据区域互联网注册（RIR）政策，PI空间并非总是适用于所有规模的企业。因此，有必要开发简化企业IPv6重新编号的机制。
This document is an analysis of IPv6 site renumbering for enterprise networks. It undertakes scenario descriptions, including
本文档是对企业网络IPv6站点重新编号的分析。它进行场景描述，包括
documentation of current capabilities and existing practices. The reader is assumed to be familiar with [RFC4192] and [RFC5887]. Proposals for new technology and methods are out of scope.
记录当前能力和现有实践。假定读者熟悉[RFC4192]和[RFC5887]。关于新技术和方法的建议超出了范围。
Since IPv4 and IPv6 are logically separate from the perspective of renumbering, regardless of overlapping of the IPv4/IPv6 networks or devices, this document focuses on IPv6 only, leaving IPv4 out of scope. Dual-stack networks or IPv4/IPv6 transition scenarios are out of scope as well.
由于从重新编号的角度来看，IPv4和IPv6在逻辑上是分开的，因此，无论IPv4/IPv6网络或设备是否重叠，本文档仅关注IPv6，将IPv4排除在范围之外。双栈网络或IPv4/IPv6转换场景也不在范围之内。
This document focuses on enterprise network renumbering; however, most of the analysis is also applicable to ISP network renumbering. Renumbering in home networks is out of scope, but it can also benefit from the analysis in this document.
本文件重点介绍企业网络重新编号；然而，大多数分析也适用于ISP网络重新编号。在家庭网络中重新编号超出了范围，但也可以从本文的分析中获益。
The concept of an enterprise network and a typical network illustration are introduced first. Then, current renumbering methods are introduced according to the following categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.
首先介绍了企业网络的概念和一个典型的网络示例。然后，根据以下类别介绍了当前的重新编号方法：网络设计期间适用的方法、重新编号准备期间适用的方法和重新编号操作期间适用的方法。
An Enterprise Network, as defined in [RFC4057], is a network that has multiple internal links, has one or more router connections to one or more Providers, and is actively managed by a network operations entity.
[RFC4057]中定义的企业网络是具有多个内部链路、与一个或多个提供商有一个或多个路由器连接并由网络运营实体主动管理的网络。
Figure 1 provides a sample enterprise network architecture for a simple case. Those entities mainly affected by renumbering are illustrated:
图1提供了一个简单案例的示例企业网络体系结构。主要受重新编号影响的实体如下所示：
* Gateway (Border router, firewall, web cache, etc.)
* 网关（边界路由器、防火墙、web缓存等）
* Application server (for internal or external users)
* 应用程序服务器（用于内部或外部用户）
* DNS and DHCP servers
* DNS和DHCP服务器
* Routers
* 路由器
* Hosts (desktops, etc.)
* 主机（台式机等）
Uplink 1 Uplink 2
| |
+---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | |
| |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Uplink 1 Uplink 2
| |
+---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | |
| |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Figure 1. Enterprise Network Illustration
图1。企业网络图解
Address reconfiguration is fulfilled either by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) or by Neighbor Discovery (ND) for IPv6 protocols. During a renumbering event, the Domain Name Service (DNS) records need to be synchronized while routing tables, Access Control Lists (ACLs), and IP filtering tables in various devices also need to be updated. It is taken for granted that applications will work entirely on the basis of DNS names, but any direct dependencies on IP addresses in application-layer entities must also be updated.
地址重新配置由IPv6的动态主机配置协议（DHCPv6）或IPv6协议的邻居发现（ND）完成。在重新编号事件期间，需要同步域名服务（DNS）记录，同时还需要更新各种设备中的路由表、访问控制列表（ACL）和IP筛选表。应用程序将完全基于DNS名称工作，这是理所当然的，但对应用层实体中IP地址的任何直接依赖也必须更新。
The issue of static addresses is described in a dedicated document [RFC6866].
专用文档[RFC6866]中描述了静态地址的问题。
The emerging cloud-based enterprise network architecture might be different than Figure 1. However, it is out of the scope of this document since it is far from mature and has not been widely deployed yet.
新兴的基于云的企业网络架构可能与图1不同。但是，它不在本文档的范围内，因为它还远未成熟，尚未广泛部署。
It is assumed that IPv6 enterprise networks are IPv6-only or dual-stack in which a logical IPv6 plane is independent from IPv4. As mentioned above, IPv4/IPv6 coexistence scenarios are out of scope.
假设IPv6企业网络是纯IPv6或双栈，其中逻辑IPv6平面独立于IPv4。如上所述，IPv4/IPv6共存场景超出范围。
This document focuses on routable unicast addresses; link-local, multicast, and anycast addresses are also out of scope.
本文档重点介绍可路由单播地址；链路本地、多播和选播地址也超出范围。
In this section, we divide enterprise network renumbering scenarios into two categories defined by external and internal network factors, which require renumbering for different reasons.
在本节中，我们将企业网络重新编号场景分为两类，分别由外部和内部网络因素定义，这两类因素出于不同的原因需要重新编号。
The following ISP uplink-related events can cause renumbering:
以下ISP上行相关事件可能导致重新编号：
o The enterprise network switches to a new ISP. When this occurs, the enterprise stops numbering its resources from the prefix allocated by the old ISP and renumbers its resources from the prefix allocated by the new ISP.
o 企业网络切换到新的ISP。出现这种情况时，企业将停止根据旧ISP分配的前缀对其资源进行编号，并根据新ISP分配的前缀对其资源重新编号。
When the enterprise switches ISPs, a "flag day" renumbering event [RFC4192] may be averted if, during a transitional period, the enterprise network may number its resources from either prefix. One way to facilitate such a transitional period is for the enterprise to contract service from both ISPs during the transition.
当企业切换ISP时，如果在过渡期间，企业网络可以从任一前缀对其资源进行编号，则可以避免“国旗日”重新编号事件[RFC4192]。促进这种过渡期的一种方法是，企业在过渡期间从两个ISP承包服务。
o The renumbering event can be initiated by receiving new prefixes from the same uplink. This might happen if the enterprise network is switched to a different location within the network topology of the same ISP due to various considerations, such as commercial, performance or services reasons, etc. Alternatively, the ISP itself might be renumbered due to topology changes or migration to a different or additional prefix. These ISP renumbering events would initiate enterprise network renumbering events, of course.
o 可通过从同一上行链路接收新前缀来启动重新编号事件。如果出于各种考虑（如商业、性能或服务原因等），企业网络切换到同一ISP的网络拓扑中的不同位置，则可能会发生这种情况。或者，ISP本身可能因拓扑更改或迁移到不同或附加前缀而重新编号。当然，这些ISP重新编号事件将启动企业网络重新编号事件。
o The enterprise network adds a new uplink(s) for multihoming purposes. This might not be a typical renumbering case because the original addresses will not be changed. However, initial numbering may be considered as a special renumbering event. The enterprise network removes uplink(s) or old prefixes.
o 企业网络为多主目的添加了一个或多个新的上行链路。这可能不是典型的重新编号情况，因为原始地址不会更改。但是，初始编号可能被视为特殊的重新编号事件。企业网络删除上行或旧前缀。
o As companies split, merge, grow, relocate, or reorganize, the enterprise network architectures might need to be rebuilt. This will trigger partial or total internal renumbering.
o 随着公司的拆分、合并、成长、重新定位或重组，企业网络架构可能需要重建。这将触发部分或全部内部重新编号。
o The enterprise network might proactively adopt a new address scheme, for example, by switching to a new transition mechanism or stage of a transition plan.
o 企业网络可以主动采用新的地址方案，例如，通过切换到新的转换机制或转换计划的阶段。
o The enterprise network might reorganize its topology or subnets.
o 企业网络可能会重新组织其拓扑或子网。
In order to carry out renumbering in an enterprise network, systematic planning and administrative preparation are needed. Careful planning and preparation could make the renumbering process smoother.
为了在企业网络中进行重新编号，需要进行系统规划和行政准备。仔细的计划和准备可以使重新编号的过程更加顺利。
This section describes current considerations and methods for enterprise renumbering, chosen among existing mechanisms. There are known gaps analyzed by [GAP-ANALYSIS] and [RFC6866]. If these gaps are filled in the future, enterprise renumbering could be processed more automatically, with fewer issues.
本节介绍在现有机制中选择的企业重新编号的当前注意事项和方法。[GAP-ANALYSIS]和[RFC6866]分析了已知的差距。如果这些差距在未来得到填补，企业重新编号可以更自动地处理，问题更少。
This section describes the considerations or issues relevant to renumbering that a network architect should carefully plan when building or designing a new network.
本节描述了网络架构师在构建或设计新网络时应仔细规划的与重新编号相关的注意事项或问题。
- Prefix Delegation (PD)
- 前缀授权（PD）
In a large or a multisite enterprise network, the prefix should be carefully managed, particularly for renumbering events. Prefix information needs to be delegated from router to router. The DHCPv6 PD options ([RFC3633] and [RFC6603]) provide a mechanism for automated delegation of IPv6 prefixes. Normally, DHCPv6 PD options are used between the internal enterprise routers; for example, a router receives a prefix(es) from its upstream router (a border gateway or edge router, etc.) through DHCPv6 PD options and then advertises it (them) to the local hosts through Router Advertisement (RA) messages.
在大型或多站点企业网络中，应仔细管理前缀，尤其是对事件重新编号时。前缀信息需要从一个路由器委派到另一个路由器。DHCPv6 PD选项（[RFC3633]和[RFC6603]）为IPv6前缀的自动委派提供了一种机制。通常，内部企业路由器之间使用DHCPv6 PD选项；例如，路由器通过DHCPv6 PD选项从其上游路由器（边界网关或边缘路由器等）接收前缀，然后通过路由器通告（RA）消息将其通告给本地主机。
- Usage of Fully Qualified Domain Names (FQDNs)
- 完全限定域名（FQDNs）的使用
In general, FQDNs are recommended to be used to configure network connectivity, such as tunnels, servers, etc. The capability to use FQDNs as endpoint names has been standardized in several RFCs (e.g., for IPsec [RFC5996]) although many system/network administrators do not realize that it is there and it works well as a way to avoid manual modification during renumbering.
一般来说，建议使用FQDN来配置网络连接，如隧道、服务器等。在几个RFC中，将FQDN用作端点名称的功能已经标准化（例如，对于IPsec[RFC5996]）尽管许多系统/网络管理员没有意识到它的存在，但它可以很好地避免在重新编号过程中进行手动修改。
Note that using FQDNs would rely on DNS systems. For a link-local network that does not have a DNS system, multicast DNS [RFC6762] could be utilized. For some specific circumstances, using FQDNs might not be chosen if adding DNS service in the node/network would cause undesired complexity or issues.
请注意，使用FQDNs将依赖于DNS系统。对于没有DNS系统的链路本地网络，可以使用多播DNS[RFC6762]。对于某些特定情况，如果在节点/网络中添加DNS服务会导致不希望的复杂性或问题，则可能不会选择使用FQDNs。
Service discovery protocols such as the Service Location Protocol [RFC2608], multicast DNS with Service Records (SRVs), and DNS Service Discovery [RFC6763] use names and can reduce the number of places that IP addresses need to be configured. However, it should be noted that these protocols are normally used link-local only.
服务发现协议，如服务位置协议[RFC2608]、具有服务记录的多播DNS（SRV）和DNS服务发现[RFC6763]使用名称，可以减少需要配置IP地址的位置数量。然而，应该注意的是，这些协议通常仅用于本地链路。
Network designers generally have little control over the design of application software. However, it is important to avoid any software that has a built-in dependency on IP addresses instead of FQDNs [RFC6866].
网络设计者通常很少控制应用软件的设计。但是，重要的是避免任何内置依赖于IP地址而不是FQDNs的软件[RFC6866]。
- Usage of Parameterized Address Configuration
- 参数化地址配置的使用
Besides DNS records, IP addresses might also be configured in many other places such as ACLs, various IP filters, various kinds of text-based configuration files, etc.
除了DNS记录外，IP地址还可以在许多其他位置进行配置，例如ACL、各种IP筛选器、各种基于文本的配置文件等。
In some cases, one IP address 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 CLI (command line interface) or other local configuration. Among the real 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.
在某些情况下，可以将一个IP地址定义为一个值，然后管理员可以使用关键字或变量在其他位置调用该值，例如某种内部继承CLI（命令行界面）或其他本地配置。在当前的实际设备中，一些路由器支持定义多个可在其他配置中调用的环回接口。例如，在定义隧道时，它可以调用已定义的环回接口，将其地址用作隧道的本地地址。
This kind of parameterized address configuration is recommended, since it makes managing a renumbering event easier by reducing the number of places where a device's configuration must be updated.
建议使用这种参数化地址配置，因为它减少了必须更新设备配置的位置数量，从而使重新编号事件的管理更加容易。
- Usage of Unique Local Addresses (ULAs)
- 唯一本地地址（ULA）的使用
ULAs are defined in [RFC4193] as PI prefixes. Since there is a 40-bit pseudorandom field in the ULA prefix, there is no practical risk of collision (please refer to Section 3.2.3 in [RFC4193] for more detail). For enterprise networks, using ULA simultaneously with PA addresses can provide a local routing plane logically separated from the global routing plane. The benefit is to ensure stable and specific local communication regardless of any ISP uplink failure. This benefit is especially meaningful for renumbering. It mainly includes three use cases described below.
[RFC4193]将ULA定义为PI前缀。由于ULA前缀中有一个40位伪随机场，因此不存在实际的冲突风险（有关更多详细信息，请参阅[RFC4193]中的第3.2.3节）。对于企业网络，同时使用ULA和PA地址可以提供从逻辑上与全局路由平面分离的本地路由平面。这样做的好处是，无论ISP上行链路出现任何故障，都能确保稳定和特定的本地通信。这一好处对于重新编号特别有意义。它主要包括下面描述的三个用例。
o During the transition period, it is desirable to isolate local communication changes in the global routing plane. If we use ULA for the local communication, this isolation is achieved.
o 在过渡期间，希望隔离全局路由平面中的本地通信变化。如果我们使用ULA进行本地通信，则可以实现这种隔离。
o Enterprise administrators might want to avoid the need to renumber their internal-only, private nodes when they have to renumber the PA addresses of the whole network because of changing ISPs, ISPs restructuring their address allocation, or any other reasons. In these situations, a ULA is an effective tool for the internal-only nodes.
o 当由于ISP更改、ISP重新配置其地址分配或任何其他原因而必须重新编号整个网络的PA地址时，企业管理员可能希望避免重新编号其内部专用节点。在这些情况下，ULA是仅用于内部节点的有效工具。
o ULAs can be a way of avoiding renumbering from having an impact on multicast. In most deployments, multicast is only used internally (intra-domain), and the addresses used for multicast sources and Rendezvous Points need not be reachable nor routable externally. Hence, one may, at least internally, make use of ULAs for multicast-specific infrastructure.
o ULAs可以避免重新编号对多播造成影响。在大多数部署中，多播仅在内部（域内）使用，而用于多播源和集合点的地址不需要在外部可访问或可路由。因此，可以至少在内部将ULA用于多播特定的基础设施。
- Address Types
- 地址类型
This document focuses on the dynamically configured global unicast addresses in enterprise networks. They are the targets of renumbering events.
本文档重点介绍企业网络中动态配置的全局单播地址。他们是事件重新编号的目标。
Manually configured addresses are not scalable in medium to large sites; hence, they should be avoided for both network elements and application servers [RFC6866].
手动配置的地址在中大型站点中不可扩展；因此，网络元件和应用服务器都应避免使用它们[RFC6866]。
- Address configuration models
- 地址配置模型
In IPv6 networks, there are two autoconfiguration models for address assignment after each host obtains a link-local address: Stateless Address Autoconfiguration (SLAAC) [RFC4862] by ND [RFC4861] and stateful address configuration by DHCPv6 [RFC3315]. In the latest work, DHCPv6 may also support the host-generated address model by assigning a prefix through DHCPv6 messages [PREFIX-DHCPV6].
在IPv6网络中，在每个主机获得链路本地地址后，有两种地址分配自动配置模型：ND[RFC4861]的无状态地址自动配置（SLAAC）[RFC4862]和DHCPv6[RFC3315]的有状态地址配置。在最新的工作中，DHCPv6还可以通过DHCPv6消息[prefix-DHCPv6]分配前缀来支持主机生成的地址模型。
SLAAC is considered to support easy renumbering by broadcasting an RA message with a new prefix. DHCPv6 can also trigger the renumbering process by sending unicast RECONFIGURE messages, though it might cause a large number of interactions between hosts and the DHCPv6 server.
SLAAC被认为通过广播带有新前缀的RA消息来支持轻松重新编号。DHCPv6还可以通过发送单播重新配置消息触发重新编号过程，尽管这可能会导致主机和DHCPv6服务器之间发生大量交互。
This document has no preference between the SLAAC and DHCPv6 address configuration models. It is the network architect's job to decide which configuration model is employed. However, it should be noticed that using DHCPv6 and SLAAC together within one network, especially in one subnet, might cause operational issues. For example, some
本文档在SLAAC和DHCPv6地址配置模型之间没有首选项。网络架构师的工作是决定采用哪种配置模型。但是，应该注意的是，在一个网络中，特别是在一个子网中，同时使用DHCPv6和SLAAC可能会导致操作问题。例如，一些
hosts use DHCPv6 as the default configuration model while some use ND. Then, the host's address configuration model depends on the policies of operating systems and cannot be controlled by the network. Section 5.1 of [GAP-ANALYSIS] discusses more details on this topic. So, in general, this document recommends using DHCPv6 or SLAAC independently in different subnets.
主机使用DHCPv6作为默认配置模型，而有些主机使用ND。然后，主机的地址配置模型取决于操作系统的策略，不能由网络控制。[GAP-ANALYSIS]第5.1节讨论了该主题的更多细节。因此，一般来说，本文档建议在不同的子网中独立使用DHCPv6或SLAAC。
However, since DHCPv6 is also used to configure many other network parameters, there are ND and DHCPv6 coexistence scenarios. Combinations of address configuration models might coexist within a single enterprise network. [SAVI] provides recommendations to avoid collisions and to review collision handling in such scenarios.
但是，由于DHCPv6还用于配置许多其他网络参数，因此存在ND和DHCPv6共存的情况。地址配置模型的组合可能在单个企业网络中共存。[SAVI]提供了避免碰撞的建议，并在此类情况下审查碰撞处理。
- DNS
- 域名服务器
Although the A6 DNS record model [RFC2874] was designed for easier renumbering, it left many unsolved technical issues [RFC3364]. Therefore, it has been moved to Historic status [RFC6563] and should not be used.
虽然A6 DNS记录模型[RFC2874]的设计目的是更容易重新编号，但它留下了许多未解决的技术问题[RFC3364]。因此，它已移至历史状态[RFC6563]，不应使用。
Often, a small site depends on its ISP's DNS system rather than maintaining its own. When renumbering, this requires administrative coordination between the site and its ISP.
通常，小型站点依赖于其ISP的DNS系统，而不是维护自己的DNS系统。重新编号时，这需要站点及其ISP之间的管理协调。
It is recommended that the site have an automatic and systematic procedure for updating/synchronizing its DNS records, including both forward and reverse mapping. In order to simplify the operational procedure, the network architect should combine the forward and reverse DNS updates in a single procedure. A manual on-demand updating model does not scale and increases the chance of errors. Either a database-driven mechanism, a secure dynamic DNS update [RFC3007], or both could be used.
建议站点有一个自动和系统的程序来更新/同步其DNS记录，包括正向和反向映射。为了简化操作过程，网络架构师应将正向和反向DNS更新组合在一个过程中。手动按需更新模型无法扩展，并且会增加出错的机会。可以使用数据库驱动机制、安全动态DNS更新[RFC3007]，或者两者都可以使用。
A dynamic DNS update can be provided by the DHCPv6 client or by the server on behalf of individual hosts. [RFC4704] defines a DHCPv6 option to be used by DHCPv6 clients and servers to exchange information about the client's FQDN and about who has the responsibility for updating the DNS with the associated AAAA and PTR (Pointer Record) RRs (Resource Records). For example, if a client wants the server to update the FQDN-address mapping in the DNS server, it can include the Client FQDN option with proper settings in the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. When the DHCPv6 server gets this option, it can use a secure dynamic DNS update on behalf of the client. This document suggests use of this FQDN option. However, since it is a DHCPv6 option, only the DHCP-managed hosts can make use of it. In SLAAC mode, hosts need either to use a secure dynamic DNS update
动态DNS更新可以由DHCPv6客户机提供，也可以由服务器代表各个主机提供。[RFC4704]定义一个DHCPv6选项，供DHCPv6客户端和服务器使用，以交换有关客户端FQDN的信息，以及有关谁负责使用关联的AAAA和PTR（指针记录）RRs（资源记录）更新DNS的信息。例如，如果客户机希望服务器更新DNS服务器中的FQDN地址映射，则可以在客户机发出的快速提交、请求、续订和重新绑定请求消息中包含具有正确设置的客户机FQDN选项。当DHCPv6服务器获得此选项时，它可以代表客户端使用安全的动态DNS更新。本文档建议使用此FQDN选项。但是，由于它是DHCPv6选项，因此只有DHCP管理的主机可以使用它。在SLAAC模式下，主机需要使用安全的动态DNS更新
directly, or to register addresses on a registration server. This could in fact be a DHCPv6 server (as described in [ADDR-REG]); then the server would update corresponding DNS records.
直接，或在注册服务器上注册地址。这实际上可能是一个DHCPv6服务器（如[ADDR-REG]中所述）；然后服务器将更新相应的DNS记录。
- Security
- 安全
Any automatic renumbering scheme has a potential exposure to hijacking. A malicious entity in the network could forge prefixes to renumber the hosts, so proper network security mechanisms are needed. Further details are in the Security Considerations section below.
任何自动重新编号方案都有可能遭到劫持。网络中的恶意实体可能伪造前缀对主机重新编号，因此需要适当的网络安全机制。有关更多详细信息，请参阅下面的“安全注意事项”部分。
- Miscellaneous
- 混杂的
A site or network should also avoid embedding addresses from other sites or networks in its own configuration data. Instead, the FQDNs should be used. Thus, connections can be restored after renumbering events at other sites. This also applies to host-based connectivity.
站点或网络还应避免在其自身的配置数据中嵌入来自其他站点或网络的地址。相反，应使用FQDN。因此，在对其他站点上的事件重新编号后，可以恢复连接。这也适用于基于主机的连接。
4.2. Considerations and Current Methods for the Preparation of Renumbering
4.2. 重新编号准备的考虑因素和当前方法
In ND, it is not possible to reduce a prefix's lifetime to below two hours. So, renumbering should not be an unplanned sudden event. This issue could only be avoided by early planning and preparation.
在ND中，不可能将前缀的生存时间减少到两小时以下。因此，重新编号不应该是意外的突发事件。只有及早规划和准备，才能避免这个问题。
This section describes several recommendations for the preparation of an enterprise renumbering event. By adopting these recommendations, a site could be renumbered more easily. However, these recommendations might increase the daily traffic, server load, or burden of network operation. Therefore, only those networks that are expected to be renumbered soon, or very frequently, should adopt these recommendations, with balanced consideration between daily cost and renumbering cost.
本节介绍了有关准备企业重新编号事件的几项建议。通过采纳这些建议，网站可以更容易地重新编号。但是，这些建议可能会增加日常流量、服务器负载或网络操作负担。因此，只有那些预计将很快或非常频繁地重新编号的网络才应采用这些建议，并在每日费用和重新编号费用之间进行平衡考虑。
- Reduce the address preferred time or valid time or both
- 减少地址首选时间或有效时间或两者
Long-lifetime addresses might cause issues for renumbering events. Particularly, some offline hosts might reconnect using these addresses after renumbering events. Shorter, preferred lifetimes with relatively long valid lifetimes may allow short transition periods for renumbering events and avoid frequent address renewals.
长生存期地址可能会导致事件重新编号的问题。特别是，某些脱机主机可能会在对事件重新编号后使用这些地址重新连接。较短的首选生存期和相对较长的有效生存期可能允许较短的事件重新编号过渡期，并避免频繁的地址续订。
- Reduce the DNS record Time to Live (TTL) on the local DNS server
- 减少本地DNS服务器上的DNS记录生存时间（TTL）
The DNS AAAA RR TTL on the local DNS server should be manipulated to ensure that stale addresses are not cached.
应操作本地DNS服务器上的DNS AAAA RR TTL，以确保不缓存过时的地址。
Recent research [BA2011] [JSBM2002] indicates that it is both practical and reasonable for A, AAAA, and PTRs that belong to leaf nodes of the DNS (i.e., not including the DNS root or DNS top-level domains) to be configured with very short DNS TTL values, not only during renumbering events but also for longer-term operation.
最近的研究[BA2011][JSBM2002]表明，对于属于DNS叶节点（即，不包括DNS根或DNS顶级域）的A、AAAA和PTR，不仅在重新编号事件期间，而且在长期操作中，配置非常短的DNS TTL值，这既实用又合理。
- Reduce the DNS configuration lifetime on the hosts
- 减少主机上的DNS配置生存期
Since the DNS server could be renumbered as well, the DNS configuration lifetime of the hosts should also be reduced if renumbering events are expected. In ND, the DNS configuration can be done through reducing the lifetime value in the Recursive DNS Server (RDNSS) option [RFC6106]. In DHCPv6, the DNS configuration option specified in [RFC3646] doesn't provide a lifetime attribute, but we can reduce the DHCPv6 client lease time to achieve a similar effect.
由于DNS服务器也可以重新编号，因此如果预期会发生重新编号事件，则主机的DNS配置生存期也应该缩短。在ND中，DNS配置可以通过减少递归DNS服务器（RDNS）选项[RFC6106]中的生存期值来完成。在DHCPv6中，[RFC3646]中指定的DNS配置选项不提供生存期属性，但我们可以缩短DHCPv6客户端租用时间以实现类似效果。
- Identify long-living sessions
- 确定长寿课程
Any applications that maintain very long transport connections (hours or days) should be identified in advance, if possible. Such applications will need special handling during renumbering, so it is important to know that they exist.
如有可能，应提前确定任何保持很长传输连接（数小时或数天）的应用程序。在重新编号期间，此类应用程序需要特殊处理，因此了解它们的存在非常重要。
Renumbering events are not instantaneous events. Normally, there is transition period in which both the old prefix and the new prefix are used in the site. Better network design and management, better preparation, and a longer transition period are helpful to reduce the issues during a renumbering operation.
重新编号事件不是即时事件。通常，站点中会同时使用旧前缀和新前缀的过渡期。更好的网络设计和管理、更好的准备和更长的过渡期有助于减少重新编号操作期间的问题。
- Within/Without a flag day
- 卖旗日内/不卖旗日
As is described in [RFC4192] "a 'flag day' is a procedure in which the network, or a part of it, is changed during a planned outage, or suddenly, causing an outage while the network recovers".
如[RFC4192]中所述，“标记日”是指在计划中断期间或在网络恢复期间突然导致中断的网络或其一部分发生变化的过程。
If a renumbering event is processed within a flag day, the network service/connectivity will be unavailable for a period until the renumbering event is completed. It is efficient and provides convenience for network operation and management. However, a network outage is usually unacceptable for end users and enterprises. A renumbering procedure without a flag day provides smooth address switching, but much more operational complexity and difficulty is introduced.
如果在卖旗日内处理了重新编号事件，则网络服务/连接将在重新编号事件完成之前的一段时间内不可用。它效率高，为网络运行和管理提供了方便。然而，对于终端用户和企业来说，网络中断通常是不可接受的。没有卖旗日的重新编号过程提供了平滑的地址切换，但带来了更大的操作复杂性和难度。
- Transition period
- 过渡期
If a renumbering transition period is longer than all address lifetimes, after which the address leases expire, each host will automatically pick up its new IP address. In this case, it would be the DHCPv6 server or RA itself that automatically accomplishes client renumbering.
如果重新编号的过渡期长于所有地址的生存期（在此之后地址租约过期），则每个主机将自动拾取其新IP地址。在这种情况下，自动完成客户机重新编号的将是DHCPv6服务器或RA本身。
Address deprecation should be associated with the deprecation of associated DNS records. The DNS records should be deprecated as early as possible, before the addresses themselves.
地址弃用应与相关DNS记录的弃用相关联。DNS记录应该在地址本身之前尽早弃用。
- Network initiative enforced renumbering
- 网络倡议强制重新编号
If the network has to enforce renumbering before address leases expire, the network should initiate DHCPv6 RECONFIGURE messages. For some operating systems such as Windows 7, if the hosts receive RA messages with ManagedFlag=0, they will release the DHCPv6 addresses and utilize SLAAC according to the prefix information in the RA messages, so this could be another enforcement method for some specific scenarios.
如果网络必须在地址租约到期前强制重新编号，则网络应启动DHCPv6重新配置消息。对于某些操作系统（如Windows 7），如果主机接收到ManagedFlag=0的RA消息，它们将释放DHCPv6地址，并根据RA消息中的前缀信息使用SLAAC，因此这可能是某些特定场景的另一种强制方法。
- Impact on main and branch sites
- 对主站点和分支站点的影响
Renumbering in the main site might cause impact on branch site communications, and vice versa. The routes, ingress filtering of the site's gateways, and DNS might need to be updated. This needs careful planning and organizing.
在主站点中重新编号可能会影响分支站点通信，反之亦然。可能需要更新站点网关的路由、入口过滤和DNS。这需要仔细规划和组织。
- DNS record update and DNS configuration on hosts
- 主机上的DNS记录更新和DNS配置
DNS records on the local DNS server should be updated if hosts are renumbered. If the site depends on an ISP's DNS system, it should report the new hosts' DNS records to its ISP. During the transition period, both old and new DNS records are valid. If the TTLs of DNS records are shorter than the transition period, an administrative operation might not be necessary.
如果主机重新编号，则应更新本地DNS服务器上的DNS记录。如果站点依赖ISP的DNS系统，则应向其ISP报告新主机的DNS记录。在过渡期间，旧的和新的DNS记录都是有效的。如果DNS记录的TTL短于过渡期，则可能不需要进行管理操作。
DNS configuration on hosts should be updated if local recursive DNS servers are renumbered. During the transition period, both old and new DNS server addresses might coexist on the hosts. If the lifetime of DNS configuration is shorter than the transition period, name resolving failure may be reduced to a minimum.
如果对本地递归DNS服务器重新编号，则应更新主机上的DNS配置。在过渡期间，旧的和新的DNS服务器地址可能同时存在于主机上。如果DNS配置的生存期短于过渡期，则名称解析失败可能会减少到最低限度。
- Tunnel concentrator renumbering
- 隧道选矿机重新编号
A tunnel concentrator itself might be renumbered. This change should be reconfigured in relevant hosts or routers, unless the configuration of the tunnel concentrator was based on FQDN.
隧道集中器本身可能会重新编号。除非隧道集中器的配置基于FQDN，否则应在相关主机或路由器中重新配置此更改。
For IPsec, Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] defines the ID_FQDN Identification type, which could be used to identify an IPsec VPN concentrator associated with a site's domain name. For current practice, the community needs to change its bad habit of using IPsec in an address-oriented way, and renumbering is one of the main reasons for that.
对于IPsec，Internet密钥交换协议版本2（IKEv2）[RFC5996]定义了ID_FQDN标识类型，可用于标识与站点域名关联的IPsec VPN集中器。对于当前的实践，社区需要改变以面向地址的方式使用IPsec的坏习惯，而重新编号是其主要原因之一。
- Connectivity session survivability
- 连接会话生存性
During the renumbering operations, connectivity sessions in the IP layer would break if the old address is deprecated before the session ends. However, the upper-layer sessions can survive by using session survivability technologies, such as Stanza Headers and Internet Metadata 6 (SHIM6) [RFC5533]. As mentioned above, some long-living applications may need to be handled specially.
在重新编号操作期间，如果旧地址在会话结束前被弃用，则IP层中的连接会话将中断。然而，上层会话可以通过使用会话生存性技术生存，例如节头和Internet元数据6（SHIM6）[RFC5533]。如上所述，一些长期使用的申请可能需要专门处理。
- Verification of success
- 成功的验证
The renumbering operation should end with a thorough check that all network elements and hosts are using only the new prefixes and that network management and monitoring systems themselves are still operating correctly. A database clean up may also be needed.
重新编号操作结束时，应彻底检查所有网元和主机是否仅使用新前缀，以及网络管理和监控系统本身是否仍在正常运行。可能还需要进行数据库清理。
Any automatic renumbering scheme has a potential exposure to hijacking by an insider attack. For attacks on ND, SEcure Neighbor Discovery (SEND) [RFC3971] is a possible solution, but it is complex and there is almost no real deployment at the time of writing. Compared to the nontrivial deployment of SEND, RA-Guard [RFC6105] is a lightweight alternative that focuses on preventing rogue router advertisements in a network. However, it is also not widely deployed at the time when this memo was published.
任何自动重新编号方案都有可能遭到内部攻击的劫持。对于ND攻击，安全邻居发现（SEND）[RFC3971]是一种可能的解决方案，但它很复杂，在撰写本文时几乎没有实际部署。与非平凡的SEND部署相比，RA-Guard[RFC6105]是一个轻量级的替代方案，它专注于防止网络中的恶意路由器广告。然而，在本备忘录发布时，它也没有得到广泛部署。
For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 [SECURE-DHCPV6]), and authentication of DHCPv6 messages [RFC3315] could be utilized. However, these security mechanisms also have not been verified by widespread deployment at the time of writing.
对于DHCPv6，有内置的安全机制（如安全DHCPv6[secure-DHCPv6]），可以利用DHCPv6消息的身份验证[RFC3315]。然而，在撰写本文时，这些安全机制还没有得到广泛部署的验证。
A site that is listed by IP address in a blacklist can escape that list by renumbering itself. However, the new prefix might be back on a blacklist rather soon if the root cause for being added to such a list is not corrected. In practice, the cost of renumbering will typically be much larger than the cost of getting off the blacklist.
在黑名单中按IP地址列出的站点可以通过对自身重新编号来逃避黑名单。但是，如果添加到黑名单中的根本原因没有得到纠正，那么新前缀可能很快就会回到黑名单上。在实践中，重新编号的成本通常要比从黑名单上除名的成本大得多。
A Dynamic DNS update might bring risk of a Denial-of-Service (DoS) attack to the DNS server. So, along with the update authentication, session filtering/limitation might also be needed.
动态DNS更新可能会给DNS服务器带来拒绝服务（DoS）攻击的风险。因此，除了更新身份验证之外，还可能需要会话过滤/限制。
The "make-before-break" approach of [RFC4192] requires the routers to keep advertising the old prefixes for some time. However, if the ISP changes the prefixes very frequently, the coexistence of old and new prefixes might cause potential risk to the enterprise routing system, since the old address relevant route path might already be invalid and the routing system just doesn't know it. However, normally, enterprise scenarios don't involve this extreme situation.
[RFC4192]的“先制造后破坏”方法要求路由器在一段时间内不断宣传旧前缀。但是，如果ISP频繁更改前缀，新旧前缀共存可能会给企业路由系统带来潜在风险，因为与旧地址相关的路由路径可能已经无效，路由系统根本不知道。然而，通常情况下，企业场景并不涉及这种极端情况。
This work is inspired by RFC 5887; thank you to the authors (Randall Atkinson and Hannu Flinck). Useful ideas were also presented in documents by Tim Chown and Fred Baker. The authors also want to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald Bonica, other 6renum members, and several reviewers for their valuable comments.
这部作品的灵感来自RFC5887；感谢作者（兰德尔·阿特金森和汉努·弗林克）。Tim Chown和Fred Baker在文件中也提出了有用的想法。作者还想感谢韦斯利·乔治、奥利维尔·博纳文图尔、李·霍华德、罗纳德·博尼卡、其他6renum成员以及几位评论家的宝贵评论。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[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月。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，Ed.“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，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月。
[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057]Bound，J.，Ed.，“IPv6企业网络场景”，RFC 4057，2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[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月。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
[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月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364]Austein，R.，“互联网协议版本6（IPv6）的域名系统（DNS）支持权衡”，RFC 3364，2002年8月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116]Abley，J.，Lindqvist，K.，Davies，E.，Black，B.，和V.Gill，“IPv4多宿主实践和限制”，RFC 41162005年7月。
[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月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[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月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[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月。
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6603]Korhonen，J.，Ed.，Savolainen，T.，Krishnan，S.，和O.Troan，“基于DHCPv6的前缀委托的前缀排除选项”，RFC 6603，2012年5月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 67622013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[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月。
[ADDR-REG] Jiang, S., Chen, G., and S. Krishnan "A Generic IPv6 Addresses Registration Solution Using DHCPv6", Work in Progress, February 2013.
[ADDR-REG]Jiang，S.，Chen，G.和S.Krishnan，“使用DHCPv6的通用IPv6地址注册解决方案”，正在进行的工作，2013年2月。
[BA2011] S. Bhatti, and R. Atkinson, "Reducing DNS Caching", Proc. 14th IEEE Global Internet Symposium (GI2011), Shanghai, China, April 15 2011.
[BA2011]S.Bhatti和R.Atkinson，“减少DNS缓存”，Proc。第十四届IEEE全球互联网研讨会（GI2011），中国上海，2011年4月15日。
[GAP-ANALYSIS] Liu, B., Jiang, S., Carpenter, B. Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", Work in Progress, December 2012.
[差距分析]Liu，B.，Jiang，S.，Carpenter，B.Venaas，S.，和W.George，“IPv6站点重新编号差距分析”，正在进行的工作，2012年12月。
[JSBM2002] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, "DNS Performance and the Effectiveness of Caching", IEEE/ACM Transactions on Networking, 10(5):589-603, 2002.
[JSBM2002]J.Jung，E.Sit，H.Balakrishnan和R.Morris，“DNS性能和缓存的有效性”，IEEE/ACM网络事务，10（5）：589-603，2002。
[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月。
[SAVI] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI for Mixed Address Assignment Methods Scenario", Work in Progress, November 2012.
[SAVI]Bi，J.，Yao，G.，Halpern，J.，和E.Levy Abegnoli，“混合地址分配方法场景的SAVI”，正在进行的工作，2012年11月。
[SECURE-DHCPV6] Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", Work in Progress, March 2012.
[SECURE-DHCPV6]Jiang，S.和S.Shen，“使用CGAs保护DHCPV6”，正在进行的工作，2012年3月。
Authors' Addresses
作者地址
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China
盛江华为技术有限公司中国北京市海淀区北青路156号华为校区Q14，邮编100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com
Bing Liu Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China
刘冰华为技术有限公司中国北京市海淀区北青路156号华为校区Q14，邮编100095
EMail: leo.liubing@huawei.com
EMail: leo.liubing@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com