Network Working Group F. Baker
Request for Comments: 4192 Cisco Systems
Updates: 2072 E. Lear
Category: Informational Cisco Systems GmbH
R. Droms
Cisco Systems
September 2005
Network Working Group F. Baker
Request for Comments: 4192 Cisco Systems
Updates: 2072 E. Lear
Category: Informational Cisco Systems GmbH
R. Droms
Cisco Systems
September 2005
Procedures for Renumbering an IPv6 Network without a Flag Day
在没有卖旗日的情况下对IPv6网络重新编号的步骤
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.
本文档描述了一个可用于将网络从一个前缀重新编号到另一个前缀的过程。它利用IPv6的固有能力向网络接口分配多个地址，通过“先通后断”转换以及地址命名和配置管理问题提供网络服务的连续性。它还使用其他IPv6功能来最小化完成从旧前缀到新前缀的转换所需的工作量和时间。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Summary of the Renumbering Procedure .......................3
1.2. Terminology ................................................4
1.3. Summary of What Must Be Changed ............................4
1.4. Multihoming Issues .........................................5
2. Detailed Review of Procedure ....................................5
2.1. Initial Condition: Stable Using the Old Prefix .............6
2.2. Preparation for the Renumbering Process ....................6
2.2.1. Domain Name Service .................................7
2.2.2. Mechanisms for Address Assignment to Interfaces .....7
2.3. Configuring Network Elements for the New Prefix ............8
2.4. Adding New Host Addresses ..................................9
2.5. Stable Use of Either Prefix ...............................10
2.6. Transition from Use of the Old Prefix to the New Prefix ...10
2.6.1. Transition of DNS Service to the New Prefix ........10
2.6.2. Transition to Use of New Addresses .................10
2.7. Removing the Old Prefix ...................................11
2.8. Final Condition: Stable Using the New Prefix ..............11
3. How to Avoid Shooting Yourself in the Foot .....................12
3.1. Applications Affected by Renumbering ......................12
3.2. Renumbering Switch and Router Interfaces ..................12
3.3. Ingress Filtering .........................................13
3.4. Link Flaps in BGP Routing .................................13
4. Call to Action for the IETF ....................................14
4.1. Dynamic Updates to DNS Across Administrative Domains ......14
4.2. Management of the Reverse Zone ............................14
5. Security Considerations ........................................14
6. Acknowledgements ...............................................16
7. References .....................................................17
7.1. Normative References ......................................17
7.2. Informative References ....................................17
Appendix A. Managing Latency in the DNS ..........................20
1. Introduction ....................................................2
1.1. Summary of the Renumbering Procedure .......................3
1.2. Terminology ................................................4
1.3. Summary of What Must Be Changed ............................4
1.4. Multihoming Issues .........................................5
2. Detailed Review of Procedure ....................................5
2.1. Initial Condition: Stable Using the Old Prefix .............6
2.2. Preparation for the Renumbering Process ....................6
2.2.1. Domain Name Service .................................7
2.2.2. Mechanisms for Address Assignment to Interfaces .....7
2.3. Configuring Network Elements for the New Prefix ............8
2.4. Adding New Host Addresses ..................................9
2.5. Stable Use of Either Prefix ...............................10
2.6. Transition from Use of the Old Prefix to the New Prefix ...10
2.6.1. Transition of DNS Service to the New Prefix ........10
2.6.2. Transition to Use of New Addresses .................10
2.7. Removing the Old Prefix ...................................11
2.8. Final Condition: Stable Using the New Prefix ..............11
3. How to Avoid Shooting Yourself in the Foot .....................12
3.1. Applications Affected by Renumbering ......................12
3.2. Renumbering Switch and Router Interfaces ..................12
3.3. Ingress Filtering .........................................13
3.4. Link Flaps in BGP Routing .................................13
4. Call to Action for the IETF ....................................14
4.1. Dynamic Updates to DNS Across Administrative Domains ......14
4.2. Management of the Reverse Zone ............................14
5. Security Considerations ........................................14
6. Acknowledgements ...............................................16
7. References .....................................................17
7.1. Normative References ......................................17
7.2. Informative References ....................................17
Appendix A. Managing Latency in the DNS ..........................20
The Prussian military theorist Carl von Clausewitz [Clausewitz]
wrote, "Everything is very simple in war, but the simplest thing is
difficult. These difficulties accumulate and produce a friction,
which no man can imagine exactly who has not seen war.... So in war,
through the influence of an 'infinity of petty circumstances' which
cannot properly be described on paper, things disappoint us and we
fall short of the mark". Operating a network is aptly compared to
conducting a war. The difference is that the opponent has the futile
expectation that homo ignoramus will behave intelligently.
The Prussian military theorist Carl von Clausewitz [Clausewitz]
wrote, "Everything is very simple in war, but the simplest thing is
difficult. These difficulties accumulate and produce a friction,
which no man can imagine exactly who has not seen war.... So in war,
through the influence of an 'infinity of petty circumstances' which
cannot properly be described on paper, things disappoint us and we
fall short of the mark". Operating a network is aptly compared to
conducting a war. The difference is that the opponent has the futile
expectation that homo ignoramus will behave intelligently.
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. Avoiding outages requires the network to be modified using what in mobility might be called a "make before break" procedure: the network is enabled to use a new prefix while the old one is still operational, operation is switched to that prefix, and then the old one is taken down.
“标记日”是指网络或其一部分在计划停机期间发生变化，或在网络恢复时突然发生停机的过程。为了避免中断，需要使用在移动性中可能被称为“先通后断”的过程来修改网络：当旧前缀仍在运行时，网络可以使用新前缀，操作切换到该前缀，然后取下旧前缀。
This document addresses the key procedural issues in renumbering an IPv6 [RFC2460] network without a "flag day". The procedure is straightforward to describe, but operationally can be difficult to automate or execute due to issues of statically configured network state, which one might aptly describe as "an infinity of petty circumstances". As a result, in certain areas, this procedure is necessarily incomplete, as network environments vary widely and no one solution fits all. It points out a few of many areas where there are multiple approaches. This document updates [RFC2072]. This document also contains recommendations for application design and network management, which, if taken seriously, may avoid or minimize the impact of the issues.
本文件阐述了在没有“卖旗日”的情况下对IPv6[RFC2460]网络重新编号的关键程序问题。该过程描述简单，但由于静态配置的网络状态问题，在操作上可能难以自动化或执行，人们可以恰当地将其描述为“无限的小环境”。因此，在某些领域，这一过程必然是不完整的，因为网络环境千差万别，没有一种解决方案适合所有人。它指出了有多种方法的许多领域中的一些领域。本文件更新了[RFC2072]。本文档还包含有关应用程序设计和网络管理的建议，如果认真对待，可能会避免或尽量减少问题的影响。
By "renumbering a network", we mean replacing the use of an existing (or "old") prefix throughout a network with a new prefix. Usually, both prefixes will be the same length. The procedures described in this document are, for the most part, equally applicable if the two prefixes are not the same length. During renumbering, sub-prefixes (or "link prefixes") from the old prefix, which have been assigned to links throughout the network, will be replaced by link prefixes from the new prefix. Interfaces on systems throughout the network will be configured with IPv6 addresses from the link prefixes of the new prefix, and any addresses from the old prefix in services like DNS [RFC1034][RFC1035] or configured into switches and routers and applications will be replaced by the appropriate addresses from the new prefix.
通过“重新编号网络”，我们的意思是用新前缀替换整个网络中现有（或“旧”）前缀的使用。通常，两个前缀的长度相同。如果两个前缀的长度不相同，则本文档中描述的步骤在大多数情况下同样适用。在重新编号过程中，旧前缀中分配给整个网络链路的子前缀（或“链路前缀”）将被新前缀中的链路前缀替换。整个网络中系统上的接口将配置新前缀的链路前缀中的IPv6地址，DNS[RFC1034][RFC1035]等服务中的旧前缀中的任何地址或配置到交换机、路由器和应用程序中的任何地址将替换为新前缀中的适当地址。
The renumbering procedure described in this document can be applied to part of a network as well as to an organization's entire network. In the case of a large organization, it may be advantageous to treat the network as a collection of smaller networks. Renumbering each of the smaller networks separately will make the process more manageable. The process described in this document is generally applicable to any network, whether it is an entire organization network or part of a larger network.
本文档中描述的重新编号过程可应用于网络的一部分以及组织的整个网络。在大型组织的情况下，将网络视为较小网络的集合可能是有利的。将每个较小的网络分别重新编号将使流程更易于管理。本文件中描述的过程通常适用于任何网络，无论是整个组织网络还是更大网络的一部分。
DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through the use of SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG [RFC2845].
DDNS：动态DNS[RFC2136][RFC3007]更新可以通过使用SIG（0）[RFC4033][RFC4034][RFC4035][RFC2931]和TSIG[RFC2845]来保护。
DHCP prefix delegation: An extension to DHCP [RFC3315] to automate the assignment of a prefix, for example, from an ISP to a customer [RFC3633].
DHCP前缀委派：DHCP[RFC3315]的扩展，用于自动分配前缀，例如从ISP到客户[RFC3633]。
flag day: A transition that involves a planned service outage.
卖旗日：涉及计划服务中断的过渡。
ingress/egress filters: Filters applied to a router interface connected to an external organization, such as an ISP, to exclude traffic with inappropriate IPv6 addresses.
入口/出口过滤器：应用于连接到外部组织（如ISP）的路由器接口的过滤器，用于排除具有不适当IPv6地址的流量。
link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
链接前缀：分配给链接的前缀，通常为A/64[RFC3177]。
SLAC: StateLess Address AutoConfiguration [RFC2462].
SLAC：无状态地址自动配置[RFC2462]。
Addresses from the old prefix that are affected by renumbering will appear in a wide variety of places in the components in the renumbered network. The following list gives some of the places that may include prefixes or addresses that are affected by renumbering, and gives some guidance about how the work required during renumbering might be minimized:
受重新编号影响的旧前缀中的地址将出现在重新编号的网络组件中的各种位置。以下列表给出了一些可能包括受重新编号影响的前缀或地址的位置，并给出了一些关于如何最小化重新编号过程中所需工作的指导：
o Link prefixes assigned to links. Each link in the network must be assigned a link prefix from the new prefix.
o 指定给链接的链接前缀。网络中的每个链路都必须从新前缀中分配一个链路前缀。
o IPv6 addresses assigned to interfaces on switches and routers. These addresses are typically assigned manually, as part of configuring switches and routers.
o 分配给交换机和路由器上接口的IPv6地址。这些地址通常是手动分配的，作为配置交换机和路由器的一部分。
o Routing information propagated by switches and routers.
o 由交换机和路由器传播的路由信息。
o Link prefixes advertised by switches and routers [RFC2461].
o 交换机和路由器公布的链路前缀[RFC2461]。
o Ingress/egress filters.
o 入口/出口过滤器。
o ACLs and other embedded addresses on switches and routers.
o 交换机和路由器上的ACL和其他嵌入式地址。
o IPv6 addresses assigned to interfaces on hosts. Use of StateLess Address Autoconfiguration (SLAC) [RFC2462] or DHCP [RFC3315] can mitigate the impact of renumbering the interfaces on hosts.
o 分配给主机上接口的IPv6地址。使用无状态地址自动配置（SLAC）[RFC2462]或DHCP[RFC3315]可以减轻对主机上接口重新编号的影响。
o DNS entries. New AAAA and PTR records are added and old ones removed in several phases to reflect the change of prefix. Caching times are adjusted accordingly during these phases.
o DNS条目。分几个阶段添加新的AAAA和PTR记录，删除旧记录，以反映前缀的变化。在这些阶段，缓存时间会相应调整。
o IPv6 addresses and other configuration information provided by DHCP.
o DHCP提供的IPv6地址和其他配置信息。
o IPv6 addresses embedded in configuration files, applications, and elsewhere. Finding everything that must be updated and automating the process may require significant effort, which is discussed in more detail in Section 3. This process must be tailored to the needs of each network.
o 配置文件、应用程序和其他地方嵌入的IPv6地址。查找所有必须更新的内容并使流程自动化可能需要付出巨大的努力，第3节将对此进行更详细的讨论。此过程必须根据每个网络的需要进行调整。
In addition to the considerations presented, the operational matters of multihoming may need to be addressed. Networks are generally renumbered for one of three reasons: the network itself is changing its addressing policy and must renumber to implement the new policy (for example, a company has been acquired and is changing addresses to those used by its new owner), an upstream provider has changed its prefixes and its customers are forced to do so at the same time, or a company is changing providers and must perforce use addresses assigned by the new provider. The third case is common.
除了所提出的考虑之外，可能还需要解决多宿的操作问题。网络重新编号通常有三个原因之一：网络本身正在更改其地址策略，并且必须重新编号以实施新策略（例如，一家公司已被收购，并且正在将地址更改为其新所有者使用的地址），上游提供商已更改其前缀，其客户被迫同时更改前缀，或者公司正在更改提供商，必须使用新提供商分配的地址。第三种情况很常见。
When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the company is multihomed during such a period. Although this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document also needs to be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704].
当一家公司更换供应商时，通常会设定一个重叠期，在此期间由两个供应商提供服务。根据定义，该公司在此期间是多家公司。虽然本文档本身并不涉及多宿主，但由于上游提供商或其一个上游提供商应用的入口过滤策略，可能会出现问题，因此本文档的用户也需要了解这些问题。[RFC2827]和[RFC3704]对此进行了详细讨论，并描述了处理方法。
During the renumbering process, the network transitions through eight states. In the initial state, the network uses just the prefix that is to be replaced during the renumbering process. At the end of the process, the old prefix has been entirely replaced by the new prefix, and the network is using just the new prefix. To avoid a flag day transition, the new prefix is deployed first and the network reaches an intermediate state in which either prefix can be used. In this state, individual hosts can make the transition to using the new prefix as appropriate to avoid disruption of applications. Once all
在重新编号过程中，网络通过八种状态进行转换。在初始状态下，网络仅使用在重新编号过程中要替换的前缀。在该过程结束时，旧前缀已被新前缀完全替换，网络仅使用新前缀。为了避免卖旗日转换，首先部署新前缀，然后网络进入中间状态，在该状态下可以使用任何一个前缀。在此状态下，各个主机可以根据需要转换为使用新前缀，以避免中断应用程序。一劳永逸
of the hosts have made the transition to the new prefix, the network is reconfigured so that the old prefix is no longer used in the network.
如果主机已转换为新前缀，则会重新配置网络，以便旧前缀不再在网络中使用。
In this discussion, we assume that an entire prefix is being replaced with another entire prefix. It may be that only part of a prefix is being changed, or that more than one prefix is being changed to a single joined prefix. In such cases, the basic principles apply, but will need to be modified to address the exact situation. This procedure should be seen as a skeleton of a more detailed procedure that has been tailored to a specific environment. Put simply, season to taste.
在本讨论中，我们假设一个完整前缀被另一个完整前缀替换。可能只是更改了前缀的一部分，或者将多个前缀更改为单个连接的前缀。在这种情况下，基本原则适用，但需要根据具体情况进行修改。该程序应被视为针对特定环境定制的更详细程序的框架。简单地说，根据口味调味。
Initially, the network is using an old prefix in routing, device interface addresses, filtering, firewalls, and other systems. This is a stable configuration.
最初，网络在路由、设备接口地址、过滤、防火墙和其他系统中使用旧前缀。这是一个稳定的配置。
The first step is to obtain the new prefix and new reverse zone from the delegating authority. These delegations are performed using established procedures, from either an internal or external delegating authority.
第一步是从授权机构获得新前缀和新反向区域。这些授权使用内部或外部授权机构的既定程序执行。
Before any devices are reconfigured as a result of the renumbering event, each link in the network must be assigned a sub-prefix from the new prefix. While this assigned link prefix does not explicitly appear in the configuration of any specific switch, router, or host, the network administrator performing the renumbering procedure must make these link prefix assignments prior to beginning the procedure to guide the configuration of switches and routers, assignment of addresses to interfaces, and modifications to network services such as DNS and DHCP.
在由于重新编号事件而重新配置任何设备之前，必须从新前缀中为网络中的每个链路分配一个子前缀。虽然此分配的链路前缀未明确出现在任何特定交换机、路由器或主机的配置中，但执行重新编号过程的网络管理员必须在开始指导交换机和路由器的配置、接口地址分配的过程之前进行这些链路前缀分配，以及对DNS和DHCP等网络服务的修改。
Prior to renumbering, various processes will need to be reconfigured to confirm bindings between names and addresses more frequently. In normal operation, DNS name translations and DHCP bindings are often given relatively long lifetimes to limit server load. In order to reduce transition time from old to new prefix, it may be necessary to reduce the time to live (TTL) associated with DNS records and increase the frequency with which DHCP clients contact the DHCP server. At the same time, a procedure must be developed through which other configuration parameters will be updated during the transition period when both prefixes are available.
在重新编号之前，需要重新配置各种进程，以更频繁地确认名称和地址之间的绑定。在正常操作中，DNS名称转换和DHCP绑定通常被赋予相对较长的生命周期，以限制服务器负载。为了减少从旧前缀到新前缀的转换时间，可能需要减少与DNS记录相关联的生存时间（TTL），并增加DHCP客户端联系DHCP服务器的频率。同时，必须制定一个程序，在两个前缀都可用的过渡期内，通过该程序更新其他配置参数。
During the renumbering process, the DNS database must be updated to add information about addresses assigned to interfaces from the new prefix and to remove addresses assigned to interfaces from the old prefix. The changes to the DNS must be coordinated with the changes to the addresses assigned to interfaces.
在重新编号过程中，必须更新DNS数据库，以添加有关从新前缀分配给接口的地址的信息，并从旧前缀中删除分配给接口的地址。DNS的更改必须与分配给接口的地址的更改相协调。
Changes to the information in the DNS have to propagate from the server at which the change was made to the resolvers where the information is used. The speed of this propagation is controlled by the TTL for DNS records and the frequency of updates from primary to secondary servers.
对DNS中信息的更改必须从进行更改的服务器传播到使用该信息的解析程序。此传播的速度由DNS记录的TTL和从主服务器到辅助服务器的更新频率控制。
The latency in propagating changes in the DNS can be managed through the TTL assigned to individual DNS records and through the timing of updates from primary to secondary servers. Appendix A gives an analysis of the factors controlling the propagation delays in the DNS.
在DNS中传播更改的延迟可以通过分配给各个DNS记录的TTL和从主服务器到辅助服务器的更新定时来管理。附录A分析了控制DNS中传播延迟的因素。
The suggestions for reducing the delay in the transition to new IPv6 addresses applies when the DNS service can be given prior notice about a renumbering event. However, the DNS service for a host may be in a different administrative domain than the network to which the host is attached. For example, a device from organization A that roams to a network belonging to organization B, but the device's DNS A record is still managed by organization A, where the DNS service won't be given advance notice of a renumbering event in organization B.
当DNS服务可以得到重新编号事件的事先通知时，减少向新IPv6地址过渡的延迟的建议适用。但是，主机的DNS服务可能位于与主机所连接的网络不同的管理域中。例如，来自组织a的设备漫游到属于组织B的网络，但该设备的DNS a记录仍由组织a管理，其中DNS服务不会提前收到组织B中重新编号事件的通知。
One strategy for updating the DNS is to allow each system to manage its own DNS information through Dynamic DNS (DDNS) [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly recommended and can be accomplished through TSIG and SIG(0). Both TSIG and SIG(0) require configuration and distribution of keys to hosts and name servers in advance of the renumbering event.
更新DNS的一种策略是允许每个系统通过动态DNS（DDN）[RFC2136][RFC3007]管理自己的DNS信息。强烈建议通过TSIG和SIG（0）对这些DDNS更新进行身份验证。TSIG和SIG（0）都需要在重新编号事件之前配置密钥并将其分发到主机和名称服务器。
IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If DHCP is used for IPv6 address assignment, there may be some delay in the assignment of IPv6 addresses from the new prefix because hosts using DHCP only contact the server periodically to extend the lifetimes on assigned addresses. This delay can be reduced in two ways:
IPv6地址可以通过SLAC、DHCP和手动过程分配。如果DHCP用于IPv6地址分配，则从新前缀分配IPv6地址时可能会有一些延迟，因为使用DHCP的主机仅定期联系服务器以延长分配地址的生存期。这种延迟可以通过两种方式减少：
o Prior to the renumbering event, the T1 parameter (which controls the time at which a host using DHCP contacts the server) may be reduced.
o 在重新编号事件之前，T1参数（控制使用DHCP的主机与服务器联系的时间）可能会减少。
o The DHCP Reconfigure message may also be sent from the server to the hosts to trigger the hosts to contact the server immediately.
o DHCP重新配置消息也可以从服务器发送到主机，以触发主机立即与服务器联系。
In this step, switches and routers and services are prepared for the new prefix but the new prefix is not used for any datagram forwarding. Throughout this step, the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix. For example, addresses assigned from the new prefix are configured in addition to any addresses from the old prefix assigned to interfaces on the switches and routers. Changes to the routing infrastructure for the new prefix are added in parallel with the old prefix so that forwarding for both prefixes operates in parallel. At the end of this step, the network is still running on the old prefix but is ready to begin using the new prefix.
在此步骤中，交换机、路由器和服务为新前缀做好准备，但新前缀不用于任何数据报转发。在整个步骤中，新前缀与旧前缀并行（且不干扰）添加到网络基础设施中。例如，除了从旧前缀分配给交换机和路由器上的接口的任何地址之外，还配置了从新前缀分配的地址。新前缀的路由基础结构更改与旧前缀并行添加，以便两个前缀的转发并行运行。此步骤结束时，网络仍在使用旧前缀运行，但已准备好开始使用新前缀。
The new prefix is added to the routing infrastructure, firewall filters, ingress/egress filters, and other forwarding and filtering functions. Routes for the new link prefixes may be injected by routing protocols into the routing subsystem, but the router advertisements should not cause hosts to perform SLAC on the new link prefixes; in particular the "autonomous address-configuration" flag [RFC2461] should not be set in the advertisements for the new link prefixes. The reason hosts should not be forming addresses at this point is that routing to the new addresses may not yet be stable.
新前缀将添加到路由基础结构、防火墙过滤器、入口/出口过滤器以及其他转发和过滤功能中。路由协议可将新链路前缀的路由注入路由子系统，但路由器公告不应导致主机对新链路前缀执行SLAC；特别是，不应在新链路前缀的播发中设置“自治地址配置”标志[RFC2461]。主机此时不应形成地址的原因是，到新地址的路由可能还不稳定。
The details of this step will depend on the specific architecture of the network being renumbered and the capabilities of the components that make up the network infrastructure. The effort required to complete this step may be mitigated by the use of DNS, DHCP prefix delegation [RFC3633], and other automated configuration tools.
此步骤的细节将取决于重新编号的网络的特定体系结构以及构成网络基础设施的组件的能力。通过使用DNS、DHCP前缀委派[RFC3633]和其他自动配置工具，可以减轻完成此步骤所需的工作量。
While the new prefix is being added, it will of necessity not be working everywhere in the network, and unless properly protected by some means such as ingress and egress access lists, the network may be attacked through the new prefix in those places where it is operational.
当添加新前缀时，它必然不会在网络中的任何地方工作，并且除非通过诸如入口和出口访问列表之类的一些手段进行适当保护，否则网络可能会在其可操作的地方通过新前缀受到攻击。
Once the new prefix has been added to the network infrastructure, access-lists, route-maps, and other network configuration options that use IP addresses should be checked to ensure that hosts and services that use the new prefix will behave as they did with the old one. Name services other than DNS and other services that provide
将新前缀添加到网络基础结构后，应检查使用IP地址的访问列表、路由映射和其他网络配置选项，以确保使用新前缀的主机和服务的行为与使用旧前缀的主机和服务的行为相同。命名DNS以外的服务和提供
information that will be affected by renumbering must be updated in such a way as to avoid responding with stale information. There are several useful approaches to identify and augment configurations:
必须更新将受重新编号影响的信息，以避免使用过时信息进行响应。有几种有用的方法可以识别和增强配置：
o Develop a mapping from each network and address derived from the old prefix to each network and address derived from the new prefix. Tools such as the UNIX "sed" or "perl" utilities are useful to then find and augment access-lists, route-maps, and the like.
o 开发从旧前缀派生的每个网络和地址到从新前缀派生的每个网络和地址的映射。UNIX“sed”或“perl”实用程序等工具可用于查找和扩充访问列表、路由图等。
o A similar approach involves the use of such mechanisms as DHCP prefix delegation to abstract networks and addresses.
o 类似的方法包括使用DHCP前缀委托等机制来抽象网络和地址。
Switches and routers or manually configured hosts that have IPv6 addresses assigned from the new prefix may be used at this point to test the network infrastructure.
此时，可以使用具有从新前缀分配的IPv6地址的交换机和路由器或手动配置的主机来测试网络基础设施。
Advertisement of the prefix outside its network is the last thing to be configured during this phase. One wants to have all of one's defenses in place before advertising the prefix, if only because the prefix may come under immediate attack.
在其网络外公布前缀是此阶段最后要配置的内容。人们希望在宣传前缀之前做好所有防御措施，哪怕只是因为前缀可能会立即受到攻击。
At the end of this phase, routing, access control, and other network services should work interchangeably for both old and new prefixes.
在这个阶段结束时，路由、访问控制和其他网络服务应该可以为新旧前缀互换工作。
Once the network infrastructure for the new prefix is in place and tested, IPv6 addresses from the new prefix may be assigned to host interfaces while the addresses from the old prefix are retained on those interfaces. The new IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If SLAC is used in the network, the switches and routers are configured to indicate that hosts should use SLAC to assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 address assignment, the DHCP service is configured to assign addresses from both prefixes to hosts. The addresses from the new prefixes will not be used until they are inserted into the DNS.
一旦新前缀的网络基础设施就位并经过测试，新前缀的IPv6地址可以分配给主机接口，而旧前缀的地址保留在这些接口上。新的IPv6地址可以通过SLAC、DHCP和手动过程分配。如果网络中使用SLAC，交换机和路由器将配置为指示主机应使用SLAC从新前缀分配IPv6地址。如果DHCP用于IPv6地址分配，则DHCP服务配置为将两个前缀的地址分配给主机。新前缀中的地址在插入DNS之前不会被使用。
Once the new IPv6 addresses have been assigned to the host interfaces, both the forward and reverse maps within DNS should be updated for the new addresses, either through automated or manual means. In particular, some clients may be able to update their forward maps through DDNS, but automating the update of the reverse zone may be more difficult as discussed in Section 4.2.
一旦将新的IPv6地址分配给主机接口，应通过自动或手动方式更新DNS中的正向和反向映射以获得新地址。特别是，一些客户可能能够通过DDN更新其正向地图，但如第4.2节所述，反向区域的自动更新可能更困难。
Once the network has been configured with the new prefix and has had sufficient time to stabilize, it becomes a stable platform with two addresses configured on each and every infrastructure component interface (apart from interfaces that use only the link-local address), and two non-link-local addresses are available for the use of any host, one in the old prefix and one in the new. This is a stable configuration.
一旦网络配置了新前缀并有足够的时间稳定，它将成为一个稳定的平台，在每个基础设施组件接口上配置两个地址（除了仅使用链路本地地址的接口），并且两个非链路本地地址可供任何主机使用，一个在旧前缀中，一个在新前缀中。这是一个稳定的配置。
When the new prefix has been fully integrated into the network infrastructure and has been tested for stable operation, hosts, switches, and routers can begin using the new prefix. Once the transition has completed, the old prefix will not be in use in the network.
当新前缀完全集成到网络基础设施中并经过稳定运行测试后，主机、交换机和路由器可以开始使用新前缀。转换完成后，旧前缀将不会在网络中使用。
The DNS service is configured to use the new prefix by removing any IPv6 addresses from the old prefix from the DNS server configuration. External references to the DNS servers, such as in the DNS service from which this DNS domain was delegated, are updated to use the IPv6 addresses from the new prefix.
DNS服务配置为通过从DNS服务器配置中删除旧前缀中的任何IPv6地址来使用新前缀。对DNS服务器的外部引用（例如从中委派此DNS域的DNS服务中）将更新为使用新前缀中的IPv6地址。
When both prefixes are usable in the network, each host can make the transition from using the old prefix to the new prefix at a time that is appropriate for the applications on the host. If the host transitions are randomized, DNS dynamic update mechanisms can better scale to accommodate the changes to the DNS.
当两个前缀在网络中都可用时，每个主机都可以在适合主机上的应用程序的时间从使用旧前缀转换为新前缀。如果主机转换是随机的，DNS动态更新机制可以更好地扩展以适应对DNS的更改。
As services become available through addresses from the new prefix, references to the hosts providing those services are updated to use the new prefix. Addresses obtained through DNS will be automatically updated when the DNS names are resolved. Addresses may also be obtained through DHCP and will be updated as hosts contact DHCP servers. Addresses that are otherwise configured must be updated appropriately.
随着服务通过新前缀中的地址变得可用，对提供这些服务的主机的引用将更新为使用新前缀。解析DNS名称时，通过DNS获得的地址将自动更新。地址也可以通过DHCP获得，并将在主机与DHCP服务器联系时更新。必须适当更新以其他方式配置的地址。
It may be necessary to provide users with tools or other explicit procedures to complete the transition from the use of the old prefix to the new prefix, because some applications and operating system functions may be configured in ways that do not use DNS at all or will not use DNS to resolve a domain name to a new address once the new prefix is available. For example, a device that only uses DNS to
可能需要向用户提供工具或其他明确的程序，以完成从使用旧前缀到使用新前缀的转换，因为某些应用程序和操作系统功能的配置方式可能根本不使用DNS，或者在新前缀可用时不会使用DNS将域名解析为新地址。例如，仅使用DNS的设备
resolve the name of an NTP server when the device is initialized will not obtain the address from the new prefix for that server at this point in the renumbering process.
初始化设备时解析NTP服务器的名称在重新编号过程中，此时将无法从该服务器的新前缀中获取地址。
This last point warrants repeating (in a slightly different form). Applications may cache addressing information in different ways, for varying lengths of time. They may cache this information in memory, on a file system, or in a database. Only after careful observation and consideration of one's environment should one conclude that a prefix is no longer in use. For more information on this issue, see [DNSOP].
最后一点值得重复（以稍微不同的形式）。应用程序可能会以不同的方式缓存寻址信息，时间长度也会有所不同。他们可以将这些信息缓存在内存、文件系统或数据库中。只有在仔细观察和考虑环境后，才能得出前缀不再使用的结论。有关此问题的更多信息，请参阅[DNSOP]。
The transition of critical services such as DNS, DHCP, NTP [RFC1305], and important business services should be managed and tested carefully to avoid service outages. Each host should take reasonable precautions prior to changing to the use of the new prefix to minimize the chance of broken connections. For example, utilities such as netstat and network analyzers can be used to determine if any existing connections to the host are still using the address from the old prefix for that host.
应对DNS、DHCP、NTP[RFC1305]等关键服务和重要业务服务的转换进行仔细管理和测试，以避免服务中断。在使用新前缀之前，每个主机都应采取合理的预防措施，以将断开连接的可能性降至最低。例如，可以使用诸如netstat和网络分析器之类的实用程序来确定与主机的任何现有连接是否仍在使用该主机的旧前缀中的地址。
Link prefixes from the old prefix in router advertisements and addresses from the old prefix provided through DHCP should have their preferred lifetimes set to zero at this point, so that hosts will not use the old prefixes for new communications.
路由器广告中旧前缀的链路前缀和通过DHCP提供的旧前缀的地址此时应将其首选寿命设置为零，以便主机不会将旧前缀用于新通信。
Once all sessions are deemed to have completed, there will be no dependence on the old prefix. It may be removed from the configuration of the routing system and from any static configurations that depend on it. If any configuration has been created based on DNS information, the configuration should be refreshed after the old prefixes have been removed from the DNS.
一旦所有会话都被视为已完成，就不会依赖旧前缀。它可以从路由系统的配置以及依赖于它的任何静态配置中删除。如果根据DNS信息创建了任何配置，则应在从DNS中删除旧前缀后刷新配置。
During this phase, the old prefix may be reclaimed by the provider or Regional Internet Registry that granted it, and addresses within that prefix are removed from the DNS.
在此阶段，授予旧前缀的提供商或区域Internet注册中心可以回收旧前缀，并且该前缀内的地址将从DNS中删除。
In addition, DNS reverse maps for the old prefix may be removed from the primary name server and the zone delegation may be removed from the parent zone. Any DNS, DHCP, or SLAC timers that were changed should be reset to their original values (most notably the DNS forward map TTL).
此外，可以从主名称服务器中删除旧前缀的DNS反向映射，并且可以从父区域中删除区域委派。任何更改的DNS、DHCP或SLAC计时器都应重置为其原始值（最明显的是DNS前向映射TTL）。
This is equivalent to the first state, but using the new prefix.
这相当于第一个状态，但使用新前缀。
The difficult operational issues in Section 2.3, Section 2.6, and Section 2.7 are in dealing with the configurations of routers and hosts that are not under the control of the network administrator or are manually configured. Examples of such devices include Voice over IP (VoIP) telephones with static configuration of boot or name servers, dedicated devices used in manufacturing that are configured with the IP addresses for specific services, the boot servers of routers and switches, etc.
第2.3节、第2.6节和第2.7节中的操作难题涉及不受网络管理员控制或手动配置的路由器和主机的配置。此类设备的示例包括具有引导服务器或名称服务器的静态配置的IP语音（VoIP）电话、使用特定服务的IP地址配置的制造中使用的专用设备、路由器和交换机的引导服务器等。
Applications may inadvertently ignore DNS caching semantics associated with IP addresses obtained through DNS resolution. The result is that a long-lived application may continue to use a stale IP address beyond the time at which the TTL for that address has expired, even if the DNS is updated with new addresses during a renumbering event.
应用程序可能会无意中忽略与通过DNS解析获得的IP地址相关联的DNS缓存语义。结果是，即使DNS在重新编号事件期间使用新地址更新，长期应用程序可能会在该地址的TTL过期后继续使用过时的IP地址。
For example, many existing applications make use of standard POSIX functions such as getaddrinfo(), which do not preserve DNS caching semantics. If the application caches the response or for whatever reason actually records the response on disk, the application will have no way to know when the TTL for the response has expired. Any application that requires repeated use of an IP address should either not cache the result or make use of an appropriate function that also conveys the TTL of the record (e.g., getrrsetbyname()).
例如，许多现有应用程序使用标准POSIX函数，如getaddrinfo（），这些函数不保留DNS缓存语义。如果应用程序缓存响应或出于任何原因在磁盘上实际记录响应，则应用程序将无法知道响应的TTL何时过期。任何需要重复使用IP地址的应用程序都不应缓存结果，也不应使用同样传递记录TTL的适当函数（例如getrrsetbyname（））。
Application designers, equipment vendors, and the Open Source community should take note. There is an opportunity to serve their customers well in this area, and network operators should either develop or purchase appropriate tools.
应用程序设计人员、设备供应商和开源社区应该注意。在这方面有机会为客户提供良好的服务，网络运营商应该开发或购买适当的工具。
The configuration and operation of switches and routers are often designed to use static configuration with IP addresses or to resolve domain names only once and use the resulting IP addresses until the element is restarted. These static configurations complicate the process of renumbering, requiring administration of all of the static information and manual configuration during a renumbering event.
交换机和路由器的配置和操作通常设计为使用IP地址的静态配置，或者只解析一次域名，并使用生成的IP地址，直到元素重新启动。这些静态配置使重新编号的过程复杂化，需要在重新编号事件期间管理所有静态信息和手动配置。
Because switches and routers are usually single-purpose devices, the user interface and operating functions (software and hardware) are often better integrated than independent services running on a server platform. Thus, it is likely that switch vendors and router vendors
由于交换机和路由器通常是单用途设备，因此用户界面和操作功能（软件和硬件）通常比在服务器平台上运行的独立服务集成得更好。因此，交换机供应商和路由器供应商可能
can design and implement consistent support for renumbering across all of the functions of switches and routers.
能够设计并实现对交换机和路由器所有功能重新编号的一致支持。
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.
为了更好地支持重新编号，交换机和路由器应该在适当的情况下使用域名进行配置，并且应该在域名的生存期到期时使用DNS解析这些名称。
An important consideration in Section 2.3, in the case where the network being renumbered is connected to an external provider, is the network's ingress filtering policy and its provider's ingress filtering policy. Both the network firewall's ingress filter and the provider's ingress filter on the access link to the network should be configured to prevent attacks that use source address spoofing. Ingress filtering is considered in detail in "Ingress Filtering for Multihomed Networks" [RFC3704].
第2.3节中的一个重要考虑因素是，在重新编号的网络连接到外部提供商的情况下，网络的入口过滤策略及其提供商的入口过滤策略。网络访问链路上的网络防火墙入口过滤器和提供商入口过滤器都应配置为防止使用源地址欺骗的攻击。“多宿网络的入口过滤”[RFC3704]中详细考虑了入口过滤。
A subtle case arises during step 2 in BGP routing when renumbering the address(es) used to name the BGP routers. Two practices are common: one is to identify a BGP router by a stable address such as a loopback address; another is to use the interface address facing the BGP peer. In each case, when adding a new prefix, a certain ambiguity is added: the systems must choose between the addresses, and depending on how they choose, different events can happen.
在BGP路由的第2步中，当对用于命名BGP路由器的地址重新编号时，会出现一个微妙的情况。通常有两种做法：一种是通过稳定地址（如环回地址）识别BGP路由器；另一种是使用面向BGP对等方的接口地址。在每种情况下，当添加一个新前缀时，都会增加某种模糊性：系统必须在地址之间进行选择，并且根据它们的选择方式，可能会发生不同的事件。
o If the existing address remains in use until removed, then this is minimized to a routing flap on that event.
o 如果现有地址在删除之前一直处于使用状态，那么这将最小化为该事件上的路由皮瓣。
o If both systems decide to use the address in the new prefix simultaneously, the link flap may occur earlier in the process, and if this is being done automatically (such as via the router renumbering protocol), it may result in route flaps throughout the network.
o 如果两个系统决定同时使用新前缀中的地址，链路翻转可能会在该过程的早期发生，并且如果这是自动完成的（例如通过路由器重新编号协议），则可能会导致整个网络中的路由翻转。
o If the two systems choose differently (one uses the old address and one uses the new address), a stable routing outage occurs.
o 如果两个系统选择不同（一个使用旧地址，另一个使用新地址），则会发生稳定的路由中断。
This is not addressed by proposals such as [IDR-RESTART], as it changes the "name" of the system, making the matter not one of a flap in an existing relationship but (from BGP's perspective) the replacement of one routing neighbor with another. Ideally, one should bring up the new BGP connection for the new address while the old remains stable and in use, and only then take down the old. In this manner, while there is a TCP connection flap, routing remains stable.
[IDR-RESTART]等提案并未解决这一问题，因为它改变了系统的“名称”，使问题不再是现有关系中的一个问题，而是（从BGP的角度）用另一个路由邻居替换一个路由邻居。理想情况下，应该在旧地址保持稳定并处于使用状态时为新地址建立新的BGP连接，然后才取下旧地址。通过这种方式，虽然存在TCP连接，但路由保持稳定。
The more automated one can make the renumbering process, the better for everyone. Sadly, there are several mechanisms that either have not been automated or have not been automated consistently across platforms.
自动化程度越高，重新编号过程对每个人都越有利。可悲的是，有几种机制要么没有实现自动化，要么没有跨平台实现一致的自动化。
The configuration files for a DNS server (such as named.conf) will contain addresses that must be reconfigured manually during a renumbering event. There is currently no easy way to automate the update of these addresses, as the updates require both complex trust relationships and automation to verify them. For instance, a reverse zone is delegated by an upstream ISP, but there is currently no mechanism to note additional delegations.
DNS服务器的配置文件（如named.conf）将包含在重新编号事件期间必须手动重新配置的地址。目前没有简单的方法来自动更新这些地址，因为更新需要复杂的信任关系和自动化来验证它们。例如，反向区域由上游ISP授权，但目前没有机制记录其他授权。
In networks where hosts obtain IPv6 addresses through SLAC, updates of reverse zone are problematic because of lack of trust relationship between administrative domain owning the prefix and the host assigning the low 64 bits using SLAC. For example, suppose a host, H, from organization A is connected to a network owned by organization B. When H obtains a new address during a renumbering event through SLAC, H will need to update its reverse entry in the DNS through a DNS server from B that owns the reverse zone for the new address. For H to update its reverse entry, the DNS server from B must accept a DDNS request from H, requiring that an inter-administrative domain trust relationship exist between H and B. The IETF should develop a BCP recommendation for addressing this problem.
在主机通过SLAC获得IPv6地址的网络中，反向区域的更新是有问题的，因为拥有前缀的管理域和使用SLAC分配低64位的主机之间缺乏信任关系。例如，假设来自组织a的主机H连接到组织B所拥有的网络。当H在通过SLAC重新编号事件期间获得新地址时，H需要通过拥有新地址反向区域的B的DNS服务器更新其在DNS中的反向条目。为使H更新其反向条目，B的DNS服务器必须接受H的DDNS请求，要求H和B之间存在管理域间信任关系。IETF应制定解决此问题的BCP建议。
The process of renumbering is straightforward in theory but can be difficult and dangerous in practice. The threats fall into two broad categories: those arising from misconfiguration and those that are actual attacks.
重新编号的过程在理论上是简单的，但在实践中可能是困难和危险的。威胁分为两大类：由错误配置引起的威胁和实际攻击引起的威胁。
Misconfigurations can easily arise if any system in the network "knows" the old prefix, or an address in it, a priori and is not configured with the new prefix, or if the new prefix is configured in a manner that replaces the old instead of being co-equal to it for a period of time. Simplistic examples include the following:
如果网络中的任何系统事先“知道”旧前缀或其中的地址，并且没有配置新前缀，或者如果新前缀的配置方式是替换旧前缀，而不是在一段时间内与旧前缀共同相等，则很容易出现错误配置。简单的例子包括：
Neglecting to reconfigure a system that is using the old prefix in some static configuration: in this case, when the old prefix is removed from the network, whatever feature was so configured becomes inoperative - it is not configured for the new prefix, and the old prefix is irrelevant.
忽略重新配置在某些静态配置中使用旧前缀的系统：在这种情况下，当旧前缀从网络中删除时，任何这样配置的功能都将不起作用-它不是为新前缀配置的，旧前缀是无关的。
Configuring a system via an IPv6 address, and replacing that old address with a new address: because the TCP connection is using the old and now invalid IPv6 address, the SSH session will be terminated and you will have to use SSH through the new address for additional configuration changes.
通过IPv6地址配置系统，并用新地址替换旧地址：由于TCP连接使用的是旧的且现在无效的IPv6地址，SSH会话将被终止，您必须通过新地址使用SSH进行其他配置更改。
Removing the old configuration before supplying the new: in this case, it may be necessary to obtain on-site support or travel to the system and access it via its console.
在提供新配置之前移除旧配置：在这种情况下，可能需要获得现场支持或前往系统并通过其控制台访问。
Clearly, taking the extra time to add the new prefix to the configuration, allowing the network to settle, and then removing the old obviates this class of issue. A special consideration applies when some devices are only occasionally used; the administration must allow a sufficient length of time in Section 2.6 or apply other verification procedures to ensure that their likelihood of detection is sufficiently high.
显然，花额外的时间将新前缀添加到配置中，允许网络稳定，然后删除旧前缀可以避免此类问题。当某些设备只是偶尔使用时，需要特别考虑；管理部门必须在第2.6节中留出足够的时间，或采用其他验证程序，以确保其被检测的可能性足够高。
A subtle case of this type can result when the DNS is used to populate access control lists and similar security or QoS configurations. DNS names used to translate between system or service names and corresponding addresses are treated in this procedure as providing the address in the preferred prefix, which is either the old or new prefix but not both. Such DNS names provide a means, as described in Section 2.6, to cause systems in the network to stop using the old prefix to access servers or peers and cause them to start using the new prefix. DNS names used for access control lists, however, need to go through the same three-step procedure used for other access control lists, having the new prefix added to them as discussed in Section 2.3 and the old prefix removed as discussed in Section 2.7.
当DNS用于填充访问控制列表和类似的安全或QoS配置时，可能会出现这种类型的微妙情况。在此过程中，用于在系统或服务名称与相应地址之间转换的DNS名称被视为在首选前缀中提供地址，首选前缀是旧前缀或新前缀，但不是两者都提供。如第2.6节所述，此类DNS名称提供了一种方法，使网络中的系统停止使用旧前缀访问服务器或对等方，并使它们开始使用新前缀。然而，用于访问控制列表的DNS名称需要经过与用于其他访问控制列表相同的三步程序，如第2.3节所述向其添加新前缀，如第2.7节所述删除旧前缀。
It should be noted that the use of DNS names in this way is not universally accepted as a solution to this problem; [RFC3871] especially notes cases where static IP addresses are preferred over DNS names, in order to avoid a name lookup when the naming system is inaccessible or when the result of the lookup may be one of several interfaces or systems. In such cases, extra care must be taken to manage renumbering properly.
应该注意的是，以这种方式使用DNS名称并不是普遍接受的解决方案；[RFC3871]特别注意静态IP地址优先于DNS名称的情况，以避免在命名系统无法访问或查找结果可能是多个接口或系统之一时进行名称查找。在这种情况下，必须格外注意正确管理重新编号。
Attacks are also possible. Suppose, for example, that the new prefix has been presented by a service provider, and the service provider
攻击也是可能的。例如，假设新前缀已由服务提供商提供，并且服务提供商
starts advertising the prefix before the customer network is ready. The new prefix might be targeted in a distributed denial of service attack, or a system might be broken into using an application that would not cross the firewall using the old prefix, before the network's defenses have been configured. Clearly, one wants to configure the defenses first and only then accessibility and routing, as described in Section 2.3 and Section 3.3.
在客户网络准备就绪之前开始播发前缀。新前缀可能是分布式拒绝服务攻击的目标，或者在配置网络防御之前，系统可能会使用不会使用旧前缀穿越防火墙的应用程序被入侵。显然，我们希望首先配置防御，然后才配置可访问性和路由，如第2.3节和第3.3节所述。
The SLAC procedure described in [RFC2462] renumbers hosts. Dynamic DNS provides a capability for updating DNS accordingly. Managing configuration items apart from those procedures is most obviously straightforward if all such configurations are generated from a central configuration repository or database, or if they can all be read into a temporary database, changed using appropriate scripts, and applied to the appropriate systems. Any place where scripted configuration management is not possible or is not used must be tracked and managed manually. Here, there be dragons.
[RFC2462]中描述的SLAC程序对主机重新编号。动态DNS提供相应更新DNS的功能。如果所有这些配置都是从中央配置存储库或数据库生成的，或者如果它们都可以读入临时数据库，使用适当的脚本进行更改，并应用于适当的系统，那么除了这些过程之外，管理配置项显然是最简单的。任何无法或未使用脚本化配置管理的地方都必须手动跟踪和管理。这里有龙。
In ingress filtering of a multihomed network, an easy solution to the issues raised in Section 3.3 might recommend that ingress filtering should not be done for multihomed customers or that ingress filtering should be special-cased. However, this has an impact on Internet security. A sufficient level of ingress filtering is needed to prevent attacks using spoofed source addresses. Another problem comes from the fact that if ingress filtering is made too difficult (e.g., by requiring special-casing in every ISP doing it), it might not be done at an ISP at all. Therefore, any mechanism depending on relaxing ingress filtering checks should be dealt with with extreme care.
在多址网络的入口过滤中，第3.3节中提出的问题的简单解决方案可能建议不应为多址客户进行入口过滤，或者入口过滤应为特殊情况。然而，这对互联网安全产生了影响。需要足够级别的入口过滤，以防止使用伪造源地址的攻击。另一个问题来自这样一个事实，即如果入口过滤变得太困难（例如，每个ISP都需要特殊的外壳进行过滤），则ISP可能根本无法进行过滤。因此，任何依赖于放松入口过滤检查的机制都应极其小心地处理。
This document grew out of a discussion on the IETF list. Commentary on the document came from Bill Fenner, Christian Huitema, Craig Huegen, Dan Wing, Fred Templin, Hans Kruse, Harald Tveit Alvestrand, Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford, Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain.
本文件源于IETF列表上的讨论。对该文件的评论来自比尔·芬纳、克里斯蒂安·惠特马、克雷格·休根、丹·温、弗雷德·坦普林、汉斯·克鲁斯、哈拉尔·特维特·阿尔韦斯特兰德、伊尔吉奇·范·贝伊纳姆、杰夫·威尔斯、约翰·施尼兹莱因、劳伦特·尼古拉斯、迈克尔·托马斯、米歇尔·皮、奥勒·特罗安、佩卡·萨沃拉、彼得·埃尔福德、罗兰·多宾斯、斯科特·布拉德纳、肖恩·康弗里和托尼·海恩。
Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer.
一些人自己说服了作者，将网络重新编号作为一个正常或频繁的过程的概念是愚蠢的。他们的评论，如果能改善网络中的地址管理实践，可能是本说明提供的最佳贡献。
Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described the ingress filtering issues. These made their way separately into [RFC3704], which should be read and understood by anyone who will
Christian Huitema、Pekka Savola和Iljitsch van Beijnum描述了入口过滤问题。这些内容分别进入[RFC3704]，任何人都应该阅读并理解这些内容
temporarily or permanently create a multihomed network by renumbering from one provider to another.
通过从一个提供商到另一个提供商重新编号，临时或永久创建多址网络。
In addition, the 6NET consortium, notably Alan Ford, Bernard Tuy, Christian Schild, Graham Holmes, Gunter Van de Velde, Mark Thompson, Nick Lamb, Stig Venaas, Tim Chown, and Tina Strauf, took it upon themselves to test the procedure. Some outcomes of that testing have been documented here, as they seemed of immediate significance to the procedure; 6NET will also be documenting its own "lessons learned".
此外，6NET财团，尤其是艾伦·福特、伯纳德·图伊、克里斯蒂安·席尔德、格雷厄姆·霍姆斯、冈特·范德·维尔德、马克·汤普森、尼克·兰姆、斯蒂格·维纳斯、蒂姆·乔恩和蒂娜·斯特劳夫，自行测试了该程序。此处记录了该测试的一些结果，因为它们似乎对程序具有直接意义；6NET还将记录自己的“经验教训”。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3315] Droms, R., 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.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On War, Chapter VII, 'Friction in War'", June 1989.
[克劳塞维茨]冯·克劳塞维茨，C.，霍华德，M.，帕雷特，P.和D.布罗迪，“关于战争，第七章，“战争中的摩擦”，1989年6月。
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress, October 2004.
[DNSOP]Durand，A.，Ihren，J.和P.Savola，“IPv6 DNS的操作注意事项和问题”，正在进行的工作，2004年10月。
[IDR-RESTART] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.
[IDR-RESTART]Sangli，S.，Rekhter，Y.，Fernando，R.，Scudder，J.和E.Chen，“BGP的优雅重启机制”，正在进行的工作，2004年6月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[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月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177]IAB和IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[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月。
[RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[RFC3871]Jones，G.“大型互联网服务提供商（ISP）IP网络基础设施的运营安全要求”，RFC 3871，2004年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
The procedure in this section can be used to determine and manage the latency in updates to information a DNS resource record (RR).
本节中的过程可用于确定和管理DNS资源记录（RR）信息更新的延迟。
There are several kinds of possible delays that are ignored in these calculations:
在这些计算中，有几种可能的延迟被忽略：
o the time it takes for the administrators to make the changes;
o 管理员进行更改所需的时间；
o the time it may take to wait for the DNS update, if the secondaries are only updated at regular intervals, and not immediately; and
o 等待DNS更新所需的时间，如果仅定期更新辅助设备，而不是立即更新；和
o the time the updating to all the secondaries takes.
o 更新到所有辅助服务器所需的时间。
Assume the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer updated information from the primary DNS server to any secondary servers; this is a very quick update process, and the actual time to update of information is not considered significant.
假设使用NOTIFY[RFC1996]和IXFR[RFC1995]将更新的信息从主DNS服务器传输到任何辅助服务器；这是一个非常快速的更新过程，更新信息的实际时间并不重要。
There is a target time, TC, at which we want to change the contents of a DNS RR. The RR is currently configured with TTL == TTLOLD. Any cached references to the RR will expire no more than TTLOLD in the future.
有一个目标时间TC，我们希望在该时间更改DNS RR的内容。RR当前配置为TTL==TTLOLD。将来，对RR的任何缓存引用的过期时间不会超过TTLOLD。
At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to push the RR to the secondaries. After the update, responses to queries for the RR are returned with TTLNEW. There are still some cached references with TTLOLD.
在时间TC-（TTLOLD+TTLNEW）时，主设备中的RR配置为TTLNEW（TTLNEW<TTLOLD）。启动更新过程以将RR推送到辅助设备。更新后，对RR查询的响应将返回TTLNEW。仍有一些使用TTLOLD的缓存引用。
At time TC - TTLNEW, the RR in the primary is configured with the new address. The update process is initiated to push the RR to the secondaries. After the update, responses to queries for the RR return the new address. All the cached references have TTLNEW. Between this time and TC, responses to queries for the RR may be returned with either the old address or the new address. This ambiguity is acceptable, assuming the host is configured to respond to both addresses.
在TC-TTLNEW时，主设备中的RR配置了新地址。启动更新过程以将RR推送到辅助设备。更新后，对RR查询的响应将返回新地址。所有缓存的引用都有TTLNEW。在这段时间和TC之间，对RR查询的响应可能返回旧地址或新地址。假设主机配置为响应两个地址，则这种模糊性是可以接受的。
At time TC, all the cached references with the old address have expired, and all subsequent queries will return the new address. After TC (corresponding to the final state described in Section 2.8), the TTL on the RR can be set to the initial value TTLOLD.
在TC时，所有具有旧地址的缓存引用都已过期，所有后续查询都将返回新地址。TC（对应于第2.8节中描述的最终状态）后，RR上的TTL可设置为初始值TTLOLD。
The network administrator can choose TTLOLD and TTLNEW to meet local requirements.
网络管理员可以选择TTLOLD和TTLNEW以满足本地要求。
As a concrete example, consider a case where TTLOLD is a week (168 hours) and TTLNEW is an hour. The preparation for the change of addresses begins 169 hours before the address change. After 168 hours have passed and only one hour is left, the TTLNEW has propagated everywhere, and one can change the address record(s). These are propagated within the hour, after which one can restore TTL value to a larger value. This approach minimizes time where it is uncertain what kind of (address) information is returned from the DNS.
作为一个具体的例子，考虑TTLHOLD是一个星期（168小时）的情况，TTLNEW是一个小时。地址变更的准备工作在地址变更前169小时开始。168个小时过去了，只剩下一个小时，TTLNEW就到处传播，人们可以更改地址记录。它们在一小时内传播，之后可以将TTL值恢复为更大的值。这种方法最大限度地减少了不确定从DNS返回何种（地址）信息的时间。
Authors' Addresses
作者地址
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州，美国93117
Phone: 408-526-4257 Fax: 413-473-2403 EMail: fred@cisco.com
电话：408-526-4257传真：413-473-2403电子邮件：fred@cisco.com
Eliot Lear Cisco Systems GmbH Glatt-com 2nd Floor CH-8301 Glattzentrum Switzerland
艾略特·李尔思科系统有限责任公司瑞士格拉茨岑特鲁姆二楼CH-8301
Phone: +41 1 878 9200
EMail: lear@cisco.com
Phone: +41 1 878 9200
EMail: lear@cisco.com
Ralph Droms Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 US
Ralph Droms Cisco Systems美国马萨诸塞州Boxborough市比弗布鲁克路200号01719
Phone: +1 978 936-1674
EMail: rdroms@cisco.com
Phone: +1 978 936-1674
EMail: rdroms@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。