Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 5887 Univ. of Auckland
Category: Informational R. Atkinson
ISSN: 2070-1721 Extreme Networks
H. Flinck
Nokia Siemens Networks
May 2010
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 5887 Univ. of Auckland
Category: Informational R. Atkinson
ISSN: 2070-1721 Extreme Networks
H. Flinck
Nokia Siemens Networks
May 2010
Renumbering Still Needs Work
重新编号仍然需要努力
Abstract
摘要
This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work.
本文档回顾了IPv4和IPv6站点重新编号的现有机制，并确定了这些机制的操作问题。它还总结了关于其他机制的当前技术提案。最后，进行差距分析，确定未来工作的可能领域。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5887.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5887.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Existing Host-Related Mechanisms ................................5
2.1. DHCP .......................................................5
2.2. IPv6 Stateless Address Autoconfiguration ...................6
2.3. IPv6 ND Router/Prefix Advertisements .......................7
2.4. PPP ........................................................7
2.5. DNS Configuration ..........................................8
2.6. Dynamic Service Discovery ..................................9
3. Existing Router-Related Mechanisms ..............................9
3.1. Router Renumbering .........................................9
4. Existing Multi-Addressing Mechanism for IPv6 ...................10
5. Operational Issues with Renumbering Today ......................11
5.1. Host-Related Issues .......................................11
5.1.1. Network-Layer Issues ...............................11
5.1.2. Transport-Layer Issues .............................13
5.1.3. DNS Issues .........................................14
5.1.4. Application-Layer Issues ...........................14
5.2. Router-Related Issues .....................................16
5.3. Other Issues ..............................................17
5.3.1. NAT State Issues ...................................17
5.3.2. Mobility Issues ....................................18
5.3.3. Multicast Issues ...................................18
5.3.4. Management Issues ..................................19
5.3.5. Security Issues ....................................21
6. Proposed Mechanisms ............................................22
6.1. SHIM6 .....................................................22
6.2. MANET Proposals ...........................................22
6.3. Other IETF Work ...........................................23
6.4. Other Proposals ...........................................23
7. Gaps ...........................................................24
7.1. Host-Related Gaps .........................................24
7.2. Router-Related Gaps .......................................25
7.3. Operational Gaps ..........................................25
7.4. Other Gaps ................................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. Informative References ........................................27
Appendix A. Embedded IP Addresses ................................34
1. Introduction ....................................................3
2. Existing Host-Related Mechanisms ................................5
2.1. DHCP .......................................................5
2.2. IPv6 Stateless Address Autoconfiguration ...................6
2.3. IPv6 ND Router/Prefix Advertisements .......................7
2.4. PPP ........................................................7
2.5. DNS Configuration ..........................................8
2.6. Dynamic Service Discovery ..................................9
3. Existing Router-Related Mechanisms ..............................9
3.1. Router Renumbering .........................................9
4. Existing Multi-Addressing Mechanism for IPv6 ...................10
5. Operational Issues with Renumbering Today ......................11
5.1. Host-Related Issues .......................................11
5.1.1. Network-Layer Issues ...............................11
5.1.2. Transport-Layer Issues .............................13
5.1.3. DNS Issues .........................................14
5.1.4. Application-Layer Issues ...........................14
5.2. Router-Related Issues .....................................16
5.3. Other Issues ..............................................17
5.3.1. NAT State Issues ...................................17
5.3.2. Mobility Issues ....................................18
5.3.3. Multicast Issues ...................................18
5.3.4. Management Issues ..................................19
5.3.5. Security Issues ....................................21
6. Proposed Mechanisms ............................................22
6.1. SHIM6 .....................................................22
6.2. MANET Proposals ...........................................22
6.3. Other IETF Work ...........................................23
6.4. Other Proposals ...........................................23
7. Gaps ...........................................................24
7.1. Host-Related Gaps .........................................24
7.2. Router-Related Gaps .......................................25
7.3. Operational Gaps ..........................................25
7.4. Other Gaps ................................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. Informative References ........................................27
Appendix A. Embedded IP Addresses ................................34
In early 1996, the IAB published a short RFC entitled "Renumbering Needs Work" [RFC1900], which the reader is urged to review before continuing. Almost ten years later, the IETF published "Procedures for Renumbering an IPv6 Network without a Flag Day" [RFC4192]. A few other RFCs have touched on router or host renumbering: [RFC1916], [RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076].
1996年初，IAB发布了一份简短的RFC，题为“重新编号需求工作”[RFC1900]，敦促读者在继续阅读之前进行审查。将近十年后，IETF发布了“在没有国旗日的情况下对IPv6网络重新编号的程序”[RFC4192]。其他一些RFC已经涉及到路由器或主机重新编号：[RFC1916]、[RFC2071]、[RFC2072]、[RFC2874]、[RFC2894]和[RFC4076]。
In fact, since 1996, a number of individual mechanisms have become available to simplify some aspects of renumbering. The Dynamic Host Configuration Protocol (DHCP) is available for IPv4 [RFC2131] and IPv6 [RFC3315]. IPv6 includes Stateless Address Autoconfiguration (SLAAC) [RFC4862], and this includes Router Advertisements (RAs) that include options listing the set of active prefixes on a link. The Point-to-Point Protocol (PPP) [RFC1661] also allows for automated address assignment for both versions of IP.
事实上，自1996年以来，已有一些单独的机制可用于简化重新编号的某些方面。动态主机配置协议（DHCP）可用于IPv4[RFC2131]和IPv6[RFC3315]。IPv6包括无状态地址自动配置（SLAAC）[RFC4862]，这包括路由器广告（RAs），其中包括列出链路上活动前缀集的选项。点对点协议（PPP）[RFC1661]还允许为两个版本的IP自动分配地址。
Despite these efforts, renumbering, especially for medium to large sites and networks, is widely viewed as an expensive, painful, and error-prone process, and is therefore avoided by network managers as much as possible. Some would argue that the very design of IP addressing and routing makes automatic renumbering intrinsically impossible. In fact, managers have an economic incentive to avoid having to renumber, and many have resorted to private addressing and Network Address Translation (NAT) as a result. This has the highly unfortunate consequence that any mechanisms for managing the scaling problems of wide-area (BGP4) routing that require occasional or frequent site renumbering have been consistently dismissed as unacceptable. But none of this means that we can duck the problem, because as explained below, renumbering is sometimes unavoidable. This document aims to explore the issues behind this problem statement, especially with a view to identifying the gaps and known operational issues.
尽管做出了这些努力，重新编号，特别是对于中大型站点和网络，被广泛认为是一个昂贵、痛苦且容易出错的过程，因此网络管理员尽可能避免重新编号。有人会说，IP地址和路由的设计本身就使得自动重新编号在本质上是不可能的。事实上，管理者有避免重新编号的经济动机，因此许多人求助于私有地址和网络地址转换（NAT）。这造成了非常不幸的后果，即任何管理广域（BGP4）路由的缩放问题的机制，如果需要偶尔或频繁地重新编号，则一直被视为不可接受。但所有这些都不意味着我们可以回避这个问题，因为如下所述，重新编号有时是不可避免的。本文件旨在探讨问题陈述背后的问题，特别是为了找出差距和已知的运营问题。
It is worth noting that for a very large class of users, renumbering is not in fact a problem of any significance. A domestic or small office user whose device operates purely as a client or peer-to-peer node is in practice renumbered at every restart (even if the address assigned is often the same). A user who roams widely with a laptop or pocket device is also renumbered frequently. Such users are not concerned with the survival of very long-term application sessions and are in practice indifferent to renumbering. Thus, this document is mainly concerned with issues affecting medium to large sites.
值得注意的是，对于一大类用户来说，重新编号实际上并不是一个有任何意义的问题。家庭或小型办公室用户的设备纯粹作为客户端或对等节点运行，实际上每次重启时都会重新编号（即使分配的地址通常相同）。带着笔记本电脑或袖珍设备四处漫游的用户也会经常重新编号。这些用户不关心长期应用程序会话的生存，实际上对重新编号漠不关心。因此，本文件主要涉及影响中大型场地的问题。
There are numerous reasons why such sites might need to renumber in a planned fashion, including:
此类网站可能需要按计划方式重新编号的原因有很多，包括：
o Change of service provider, or addition of a new service provider, when provider-independent addressing is not an option.
o 如果无法选择独立于提供商的寻址，则更改服务提供商或添加新的服务提供商。
o A service provider itself has to renumber.
o 服务提供商本身必须重新编号。
o Change of site topology (i.e., subnet reorganisation).
o 更改站点拓扑（即子网重组）。
o Merger of two site networks into one, or split of one network into two or more parts.
o 将两个站点网络合并为一个站点网络，或将一个网络拆分为两个或多个部分。
o During IPv6 deployment, change of IPv6 access method (e.g., from tunneled to native).
o 在IPv6部署期间，更改IPv6访问方法（例如，从隧道到本机）。
The most demanding case would be unplanned automatic renumbering, presumably initiated by a site border router, for reasons connected with wide-area routing. There is already a degree of automatic renumbering for some hosts, e.g., IPv6 "privacy" addresses [RFC4941].
最苛刻的情况是计划外自动重新编号，可能由站点边界路由器发起，原因与广域路由有关。某些主机已经有一定程度的自动重新编号，例如IPv6“隐私”地址[RFC4941]。
It is certainly to be expected that as the pressure on IPv4 address space intensifies in the next few years, there will be many attempts to consolidate usage of addresses so as to avoid wastage, as part of the "end game" for IPv4, which necessarily requires renumbering of the sites involved. However, strategically, it is more important to implement and deploy techniques for IPv6 renumbering, so that as IPv6 becomes universally deployed, renumbering becomes viewed as a relatively routine event. In particular, some mechanisms being considered to allow indefinite scaling of the wide-area routing system might assume site renumbering to be a straightforward matter.
可以肯定的是，随着IPv4地址空间压力在未来几年的加剧，将有许多人试图整合地址的使用，以避免浪费，这是IPv4“最终游戏”的一部分，这必然需要对涉及的站点重新编号。然而，从战略上讲，更重要的是实施和部署IPv6重新编号技术，以便随着IPv6的普遍部署，重新编号被视为一个相对例行的事件。特别是，一些被认为可以无限扩展广域路由系统的机制可能会假定站点重新编号是一个简单的问题。
There is work in progress that, if successful, would eliminate some of the motivations for renumbering. In particular, some types of solutions to the problem of scalable routing for multihomed sites would likely eliminate both multihoming and switching to another ISP as reasons for site renumbering.
正在进行的工作如果成功，将消除重新编号的一些动机。特别是，对于多宿站点的可扩展路由问题，某些类型的解决方案可能会消除多宿和切换到另一个ISP作为站点重新编号的原因。
Several proposed identifier/locator split schemes provide good examples, including at least Identifier Locator Network Protocol [ILNP], Locator/ID Separation Protocol [LISP], and Six/One [SIX-ONE] (in alphabetical order). The recent discussion about IPv6 Network Address Translation (IPv6 NAT) provides a separate example [NAT66]. While remaining highly contentious, this approach, coupled with unique local addresses or a provider-independent address prefix, would appear to eliminate some reasons for renumbering in IPv6. However, even if successful, such solutions will not eliminate all of the reasons for renumbering. This document does not take any
几个提议的标识符/定位器拆分方案提供了很好的示例，至少包括标识符定位器网络协议[ILNP]、定位器/ID分离协议[LISP]和六/一[六-一]（按字母顺序）。最近关于IPv6网络地址转换（IPv6 NAT）的讨论提供了一个单独的示例[NAT66]。尽管这种方法仍有很大争议，但它加上唯一的本地地址或独立于提供商的地址前缀，似乎消除了在IPv6中重新编号的一些原因。然而，即使成功，这些解决方案也不会消除重新编号的所有理由。本文件不包含任何内容
position about development or deployment of protocols or technologies that would make long-term renumbering unnecessary, but rather deals with practical cases where partial or complete renumbering is necessary in today's Internet.
关于协议或技术的开发或部署的立场，这些协议或技术将使长期重新编号成为不必要的，而是处理在当今互联网中需要部分或完全重新编号的实际情况。
IP addresses do not have a built-in lifetime. Even when an address is leased for a finite time by DHCP or SLAAC, or when it is derived from a DNS record with a finite time to live (TTL) value, this information is unavailable to applications once the address has been passed to an upper layer by the socket interface. Thus, a renumbering event is almost certain to be an unpredictable surprise from the point of view of any application software using the address. Many of the issues listed below derive from this fact.
IP地址没有内置的生存期。即使DHCP或SLAAC在有限时间内租用地址，或者从具有有限生存时间（TTL）值的DNS记录派生出地址，一旦地址通过套接字接口传递到上层，应用程序也无法获得此信息。因此，从使用地址的任何应用软件的角度来看，重新编号事件几乎肯定是一个不可预测的惊喜。下面列出的许多问题都源于这一事实。
At a high level, DHCP [RFC2131] [RFC3315] offers similar support for renumbering for both versions of IP. A host requests an address when it starts up, the request might be delivered to a local DHCP server or via a relay to a central server, and if all local policy requirements are met, the server will provide an address with an associated lifetime, and various other network-layer parameters (in particular, the subnet mask and the default router address).
在较高级别上，DHCP[RFC2131][RFC3315]为两个版本的IP提供了类似的重新编号支持。主机在启动时请求一个地址，该请求可能会发送到本地DHCP服务器或通过中继发送到中心服务器，如果满足所有本地策略要求，服务器将提供一个具有相关生存期的地址以及各种其他网络层参数（特别是子网掩码和默认路由器地址）。
From an operational viewpoint, the interesting aspect is the local policy. Some sites require pre-registration of MAC (Media Access Control) addresses as a security measure, while other sites permit any MAC address to obtain an IP address. Similarly, some sites use DHCP to provide the same IP address to a given MAC address each time (this is sometimes called "Static DHCP"), while other sites do not (this is sometimes called "Dynamic DHCP"), and yet other sites use a combination of these two modes where some devices (e.g., servers, Voice over IP (VoIP) handsets) have a relatively static IP address that is provisioned via DHCP while other devices (e.g., portable computers) have a different IP address each time they connect to the network. As an example, many universities in the United States and United Kingdom require MAC address registration of faculty, staff, and student devices (including handheld computers with wireless connections).
从操作角度来看，有趣的方面是当地政策。一些站点要求预先注册MAC（媒体访问控制）地址作为安全措施，而其他站点则允许任何MAC地址获得IP地址。类似地，一些站点每次使用DHCP向给定MAC地址提供相同的IP地址（有时称为“静态DHCP”），而其他站点则不使用DHCP（有时称为“动态DHCP”），而其他站点则使用这两种模式的组合，其中一些设备（例如服务器、IP语音（VoIP）手机）具有通过DHCP提供的相对静态IP地址，而其他设备（例如便携式计算机）在每次连接到网络时具有不同的IP地址。例如，美国和英国的许多大学要求教员、职员和学生设备（包括具有无线连接的手持计算机）的MAC地址注册。
These policy choices interact strongly with whether the site has what might be called "strong" or "weak" asset management. At the strong extreme, a site has a complete database of all equipment allowed to be connected, certainly containing the MAC address(es) for each host, as well as other administrative information of various kinds. Such a database can be used to generate configuration files for DHCP, DNS,
这些政策选择与网站是否拥有所谓的“强势”或“弱势”资产管理密切相关。在极端情况下，一个站点有一个完整的数据库，包含所有允许连接的设备，当然包含每个主机的MAC地址，以及其他各种管理信息。该数据库可用于生成DHCP、DNS、，
and any access control mechanisms that might be in use. For example, only certain MAC addresses might be allowed to get an IP address on certain subnets. At the weak extreme, a site has no asset management, any MAC address may get a first-come first-served IP address on any subnet, and there is no network-layer access control.
以及可能正在使用的任何访问控制机制。例如，可能只允许某些MAC地址在某些子网上获取IP地址。在较弱的极端情况下，站点没有资产管理，任何MAC地址都可能在任何子网上获得先到先得的IP地址，并且没有网络层访问控制。
The IEEE 802.1X standard [IEEE.802-1X] [IEEE.802-1X-REV] specifies a connection mechanism for wired/wireless Ethernet that is often combined with DHCP and other mechanisms to form, in effect, a network login. Using such a network login, the user of a device newly connecting to the network must provide both identity and authentication before being granted access to the network. As part of this process, the network control point will often configure the point of network connection for that specific user with a range of parameters -- such as Virtual LAN (VLAN), Access Control Lists (ACLs), and Quality-of-Service (QoS) profiles. Other forms of network login also exist, often using an initial web page for user identification and authentication. The latter approach is commonly used in hotels or cafes.
IEEE 802.1X标准[IEEE.802-1X][IEEE.802-1X-REV]规定了有线/无线以太网的连接机制，该连接机制通常与DHCP和其他机制相结合，以形成有效的网络登录。使用这种网络登录，新连接到网络的设备的用户必须在被授予访问网络的权限之前提供身份和身份验证。作为此过程的一部分，网络控制点通常会使用一系列参数为特定用户配置网络连接点，例如虚拟LAN（VLAN）、访问控制列表（ACL）和服务质量（QoS）配置文件。还存在其他形式的网络登录，通常使用初始网页进行用户标识和身份验证。后一种方法通常用于酒店或咖啡馆。
In principle, a site that uses DHCP can renumber its hosts by reconfiguring DHCP for the new address range. The issues with this are discussed below.
原则上，使用DHCP的站点可以通过为新地址范围重新配置DHCP来对其主机重新编号。下面将讨论与此相关的问题。
SLAAC, although updated recently [RFC4862], was designed prior to DHCPv6 and was intended for networks where unattended automatic configuration was preferred. Ignoring the case of an isolated network with no router, which will use link-local addresses indefinitely, SLAAC follows a bootstrap process. Each host first gives itself a link-local address, and then needs to receive a link-local multicast Router Advertisement (RA) [RFC4861] that tells it the routeable subnet prefix and the address(es) of the default router(s). A node may either wait for the next regular RA or solicit one by sending a link-local multicast Router Solicitation. Knowing the link prefix from the RA, the node may now configure its own address. There are various methods for this, of which the basic one is to construct a unique 64-bit identifier from the interface's MAC address.
尽管最近更新了[RFC4862]，但SLAAC是在DHCPv6之前设计的，旨在用于首选无人值守自动配置的网络。忽略没有路由器的隔离网络，它将无限期地使用链路本地地址，SLAAC遵循引导过程。每个主机首先给自己一个链路本地地址，然后需要接收链路本地多播路由器通告（RA）[RFC4861]，该通告告诉它可路由子网前缀和默认路由器的地址。节点可以等待下一个常规RA，也可以通过发送链路本地多播路由器请求来请求一个RA。从RA知道链路前缀后，节点现在可以配置自己的地址。有多种方法可用于此，其中最基本的方法是从接口的MAC地址构造唯一的64位标识符。
We will not describe here the IPv6 processes for Duplicate Address Detection (DAD), Neighbour Discovery (ND), and Neighbour Unreachability Discovery (NUD). Suffice it to say that they work, once the initial address assignment based on the RA has taken place.
这里我们将不描述用于重复地址检测（DAD）、邻居发现（ND）和邻居不可访问性发现（NUD）的IPv6过程。只要说，一旦基于RA的初始地址分配发生，它们就可以工作了。
The contents of the RA message are clearly critical to this process and its use during renumbering. An RA can indicate more than one prefix, and more than one router can send RAs on the same link. For each prefix, the RA indicates two lifetimes: "preferred" and "valid". Addresses derived from this prefix must inherit its lifetimes. When the valid lifetime expires, the prefix is dead and the derived address must not be used any more. When the preferred lifetime is expired (or set to zero) the prefix is deprecated, and must not be used for any new sessions. Thus, setting a preferred lifetime that is zero or finite is SLAAC's warning that renumbering will occur. SLAAC assumes that the new prefix will be advertised in parallel with the deprecated one, so that new sessions will use addresses configured under the new prefix.
RA消息的内容显然对该过程及其在重新编号过程中的使用至关重要。RA可以指示多个前缀，并且多个路由器可以在同一链路上发送RAs。对于每个前缀，RA表示两个生存期：“首选”和“有效”。从该前缀派生的地址必须继承其生存期。有效生存期到期时，前缀无效，派生地址不得再使用。当首选生存期过期（或设置为零）时，前缀将被弃用，并且不得用于任何新会话。因此，将首选寿命设置为零或有限是SLAAC的警告，即将发生重新编号。SLAAC假定新前缀将与不推荐的前缀并行发布，因此新会话将使用在新前缀下配置的地址。
With IPv6, a Router Advertisement not only advertises the availability of an upstream router, but also advertises routing prefix(es) valid on that link (subnetwork). Also, the IPv6 RA message contains a flag indicating whether or not the host should use DHCPv6 to configure. If that flag indicates that the host should use DHCPv6, then the host is not supposed to autoconfigure itself as outlined in Section 2.2. However, there are some issues in this area, described in Section 5.1.1.
在IPv6中，路由器通告不仅通告上游路由器的可用性，还通告在该链路（子网）上有效的路由前缀。此外，IPv6 RA消息包含一个标志，指示主机是否应使用DHCPv6进行配置。如果该标志指示主机应使用DHCPv6，则主机不应如第2.2节所述自动配置自身。然而，该领域存在一些问题，如第5.1.1节所述。
In an environment where a site has more than one upstream link to the outside world, the site might have more than one valid routing prefix. In such cases, typically all valid routing prefixes within a site will have the same prefix length. Also, in such cases, it might be desirable for hosts that obtain their addresses using DHCPv6 to learn about the availability of upstream links dynamically, by deducing from periodic IPv6 RA messages which routing prefixes are currently valid. This application seems possible within the IPv6 Neighbour Discovery architecture, but does not appear to be clearly specified anywhere. So, at present, this approach for hosts to learn about availability of new upstream links or loss of prior upstream links is unlikely to work with currently shipping hosts or routers.
在一个站点有多个到外部世界的上游链接的环境中，该站点可能有多个有效的路由前缀。在这种情况下，通常站点内的所有有效路由前缀都具有相同的前缀长度。此外，在这种情况下，使用DHCPv6获取其地址的主机可能需要通过从定期IPv6 RA消息推断哪些路由前缀当前有效来动态了解上游链路的可用性。在IPv6邻居发现体系结构中，此应用程序似乎是可能的，但似乎没有在任何地方明确指定。因此，目前，这种让主机了解新上游链路可用性或先前上游链路丢失的方法不太可能适用于当前正在装运的主机或路由器。
"The Point-to-Point Protocol (PPP)" [RFC1661] includes support for a Network Control Protocol (NCP) for both IPv4 and IPv6.
“点对点协议（PPP）”[RFC1661]包括对IPv4和IPv6的网络控制协议（NCP）的支持。
For IPv4, the NCP is known as IPCP [RFC1332] and allows explicit negotiation of an IP address for each end. PPP endpoints acquire (during IPCP negotiation) both their own address and the address of their peer, which may be assumed to be the default router if no routing protocol is operating. Renumbering events arise when IPCP
对于IPv4，NCP被称为IPCP[RFC1332]，允许为每一端显式协商IP地址。PPP端点（在IPCP协商期间）获取自己的地址和对等方的地址，如果没有路由协议在运行，则可以假定该地址为默认路由器。IPCP时会出现事件重新编号
negotiation is restarted on an existing link, when the PPP connection is terminated and restarted, or when the point-to-point medium is reconnected. Peers may propose either the local or remote address or require the other peer to do so. Negotiation is complete when both peers are in agreement. In practice, if no routing protocol is used, as in a subscriber/provider environment, then the provider proposes both addresses and requires the subscriber either to accept the connection or to abort. Effectively, the subscriber device is renumbered each time it connects for a new session.
当PPP连接终止并重新启动时，或当点对点介质重新连接时，在现有链路上重新启动协商。对等方可以提出本地或远程地址，或者要求其他对等方这样做。当两个对等方达成一致时，协商完成。实际上，如果没有使用路由协议，如在订阅者/提供者环境中，则提供者建议这两个地址，并要求订阅者接受连接或中止连接。实际上，订户设备在每次连接新会话时都会重新编号。
For IPv6, the NCP is IP6CP [RFC5072] and is used to configure an interface identifier for each end, after which link-local addresses may be created in the normal way. In practice, each side can propose its own identifier and renegotiation is only necessary when there is a collision, or when a provider wishes to force a subscriber to use a specific interface identifier. Once link-local addresses are assigned and IP6CP is complete, automatic assignment of global scope addresses is performed by the same methods as with multipoint links, i.e., either SLAAC or DHCPv6. Again, in a subscriber/provider environment, this allows renumbering per PPP session.
对于IPv6，NCP是IP6CP[RFC5072]，用于为每一端配置接口标识符，然后可以正常方式创建链路本地地址。实际上，每一方都可以提出自己的标识符，只有在发生冲突或提供商希望强制订户使用特定接口标识符时，才需要重新协商。一旦分配了链路本地地址且IP6CP完成，全局作用域地址的自动分配将通过与多点链路相同的方法执行，即SLAAC或DHCPv6。同样，在订阅者/提供者环境中，这允许对每个PPP会话重新编号。
A site must provide DNS records for some or all of its hosts, and of course these DNS records must be updated when hosts are renumbered. Most sites will achieve this by maintaining a DNS zone file (or a database from which it can be generated) and loading this file into the site's DNS server(s) whenever it is updated. As a renumbering tool, this is clumsy but effective. Clearly perfect synchronisation between the renumbering of the host and the updating of its A or AAAA record is impossible. An alternative is to use Secure Dynamic DNS Update [RFC3007], in which a host informs its own DNS server when it receives a new address.
站点必须为其部分或所有主机提供DNS记录，当然，这些DNS记录必须在主机重新编号时更新。大多数站点将通过维护DNS区域文件（或从中生成DNS区域文件的数据库）并在更新该文件时将其加载到站点的DNS服务器来实现这一点。作为一个重新编号的工具，这是笨拙但有效的。显然，主机重新编号和更新其A或AAAA记录之间的完美同步是不可能的。另一种方法是使用安全的动态DNS更新[RFC3007]，其中主机在收到新地址时通知其自己的DNS服务器。
There are widespread reports that the freely available BIND DNS software (which is what most UNIX hosts use), Microsoft Windows (XP and later), and Mac OS X all include support for Secure Dynamic DNS Update. So do many home gateways. Further, there are credible reports that these implementations are interoperable when configured properly ([DNSBOOK] p. 228 and p. 506).
有广泛的报道称，免费提供的绑定DNS软件（大多数UNIX主机都使用）、Microsoft Windows（XP及更高版本）和Mac OS X都支持安全的动态DNS更新。许多家庭网关也是如此。此外，有可靠的报告表明，这些实现在正确配置时是可互操作的（[DNSBOOK]第228页和第506页）。
Commonly used commercial DNS and DHCP servers (e.g., Windows Server) often are deployed with Secure Dynamic DNS Update also enabled. In some cases, merely enabling both the DNS server and the DHCP server might enable Secure Dynamic DNS Update as an automatic side effect ([DNSBOOK] p. 506). So in some cases, sites might have deployed
常用的商用DNS和DHCP服务器（例如Windows服务器）通常在部署时还启用了安全动态DNS更新。在某些情况下，仅启用DNS服务器和DHCP服务器可能会自动启用安全的动态DNS更新（[DNSBOOK]第506页）。因此，在某些情况下，站点可能已部署
Secure Dynamic DNS Update already, without realising it. An additional enhancement would be for DHCP clients to implement support for the "Client FQDN" option (Option 81).
安全的动态DNS更新已经存在，但尚未实现。另一个增强是DHCP客户端实现对“客户端FQDN”选项（选项81）的支持。
Since address changes are usually communicated to other sites via the DNS, the latter's security is essential for secure renumbering. The Internet security community believes that the current DNS Security (DNSsec) and Secure Dynamic DNS Update specifications are sufficiently secure and has been encouraging DNSsec deployment ([RFC3007] [RFC4033] [RFC4034] [RFC4035]).
由于地址更改通常通过DNS传递给其他站点，因此DNS的安全性对于安全重新编号至关重要。互联网安全社区认为当前的DNS安全（DNSsec）和安全动态DNS更新规范足够安全，并一直鼓励DNSsec部署（[RFC3007][RFC4033][RFC4034][RFC4035]）。
As of this writing, there appears to be significantly more momentum towards rapid deployment of DNS Security standards in the global public Internet than previously. Several country-code Top-Level Domains (ccTLDs) have already deployed signed TLD root zones (e.g., Sweden's .SE). Several other TLDs are working to deploy signed TLD root zones by published near-term deadlines (e.g., .GOV, .MIL). In fact, it is reported that .GOV has been signed operationally since early February 2009. It appears likely that the DNS-wide root zone will be signed in the very near future. See, for example, <http://www.dnssec-deployment.org/> and <http://www.ntia.doc.gov/DNS/DNSSEC.html>.
在撰写本文时，在全球公共互联网上快速部署DNS安全标准的势头似乎比以前大得多。几个国家代码顶级域（CCTLD）已经部署了签名TLD根区域（例如瑞典的.SE）。其他几个TLD正在努力在公布的近期截止日期（例如，.GOV、.MIL）之前部署签名TLD根区域。事实上，据报道，.GOV已于2009年2月初正式签署。DNS范围的根区域很可能在不久的将来被签署。比如说,<http://www.dnssec-deployment.org/>及<http://www.ntia.doc.gov/DNS/DNSSEC.html>.
The need for hosts to contain pre-configured addresses for servers can be reduced by deploying the Service Location Protocol (SLP). For some common services, such as network printing, SLP can therefore be an important tool for facilitating site renumbering. See [RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832].
通过部署服务位置协议（SLP），可以减少主机包含服务器预配置地址的需要。因此，对于一些常见服务（如网络打印），SLP可以成为促进站点重新编号的重要工具。参见[RFC2608]、[RFC2610]、[RFC3059]、[RFC3224]、[RFC3421]和[RFC3832]。
Multicast DNS (mDNS) and DNS Service Discovery are already widely deployed in BSD, Linux, Mac OS X, UNIX, and Windows systems, and are also widely used for both link-local name resolution and for DNS-based dynamic service discovery [MDNS] [DNSSD]. In many environments, the combination of mDNS and DNS Service Discovery (e.g., using SRV records [RFC3958]) can be important tools for reducing dependency on configured addresses.
多播DNS（mDNS）和DNS服务发现已经广泛部署在BSD、Linux、Mac OS X、UNIX和Windows系统中，并且还广泛用于链路本地名称解析和基于DNS的动态服务发现[mDNS][DNSSD]。在许多环境中，MDN和DNS服务发现的结合（例如，使用SRV记录[RFC3958]）可以成为减少对已配置地址依赖性的重要工具。
Although DHCP was originally conceived for host configuration, it can also be used for some aspects of router configuration. The DHCPv6 Prefix Delegation options [RFC3633] are intended for this. For
虽然DHCP最初用于主机配置，但它也可用于路由器配置的某些方面。DHCPv6前缀委派选项[RFC3633]用于此目的。对于
example, DHCPv6 can be used by an ISP to delegate or withdraw a prefix for a customer's router, and this can be cascaded throughout a site to achieve router renumbering.
例如，ISP可以使用DHCPv6为客户的路由器委派或撤消前缀，这可以级联到整个站点以实现路由器重新编号。
An ICMPv6 extension to allow router renumbering for IPv6 is specified in [RFC2894], but there appears to be little experience with it. It is not mentioned as a useful mechanism by [RFC4192].
[RFC2894]中指定了允许路由器为IPv6重新编号的ICMPv6扩展，但似乎没有多少经验。[RFC4192]没有提到它是一种有用的机制。
[RFC4191] extends IPv6 router advertisements to convey default router preferences and more-specific routes from routers to hosts. This could be used as an additional tool to convey information during renumbering, but does not appear to be used in practice.
[RFC4191]扩展IPv6路由器广告，以传达默认路由器首选项和从路由器到主机的更具体路由。这可以作为在重新编号期间传达信息的附加工具，但在实践中似乎没有使用。
[CPE] requires that a customer premises router use DHCPv6 to obtain an address prefix from its upstream ISP and use IPv6 RA messages to establish a default IPv6 route (when IPv6 is in use).
[CPE]要求客户场所路由器使用DHCPv6从其上游ISP获取地址前缀，并使用IPv6 RA消息建立默认IPv6路由（当使用IPv6时）。
IPv6 was designed to support multiple addresses per interface and multiple prefixes per subnet. As described in [RFC4192], this allows for a phased approach to renumbering (adding the new prefix and addresses before removing the old ones).
IPv6被设计为支持每个接口的多个地址和每个子网的多个前缀。如[RFC4192]所述，这允许分阶段重新编号（在删除旧前缀和地址之前添加新前缀和地址）。
As an additional result of the multi-addressing mechanism, a site might choose to use Unique Local Addressing (ULA) [RFC4193] for all on-site communication, or at least for all communication with on-site servers, while using globally routeable IPv6 addresses for all off-site communications. It would also be possible to use ULAs for all on-site network management purposes, by assigning ULAs to all devices. This would make these on-site activities immune to renumbering of the prefix(es) used for off-site communication. Finally, ULAs can be safely shared with peer sites with which there is a VPN connection, which cannot be done with ambiguous IPv4 addresses [RFC1918]; such VPNs would not be affected by renumbering.
作为多重寻址机制的另一个结果，站点可以选择对所有现场通信使用唯一本地寻址（ULA）[RFC4193]，或者至少对与现场服务器的所有通信使用唯一本地寻址（ULA）]，同时对所有非现场通信使用全局可路由IPv6地址。通过将ULA分配给所有设备，还可以将ULA用于所有现场网络管理目的。这将使这些现场活动不受用于场外通信的前缀重新编号的影响。最后，ULA可以与具有VPN连接的对等站点安全共享，这在IPv4地址不明确的情况下是无法实现的[RFC1918]；这些VPN不会受到重新编号的影响。
The IPv6 model also includes "privacy" addresses that are constructed with pseudo-random interface identifiers to conceal actual MAC addresses [RFC4941]. This means that IPv6 stacks and client applications already need to be agile enough to handle frequent IP address changes (e.g., in the privacy address), since in a privacy-sensitive environment the address lifetime likely will be rather short.
IPv6模型还包括用伪随机接口标识符构造的“隐私”地址，以隐藏实际MAC地址[RFC4941]。这意味着IPv6堆栈和客户端应用程序已经需要足够灵活，以处理频繁的IP地址更改（例如，在隐私地址中），因为在隐私敏感的环境中，地址生存期可能相当短。
For IPv6, a useful description of practical aspects was drafted in [THINK], as a complement to [RFC4192]. As indicated there, a primary requirement is to minimise the disruption caused by renumbering. This applies at two levels: disruption to site operations in general and disruption to individual application sessions in progress at the moment of renumbering. In the IPv6 case, the intrinsic ability to overlap use of the old and new prefixes greatly mitigates disruption to ongoing sessions, as explained in [RFC4192]. This approach is in practice excluded for IPv4, largely because IPv4 lacks a Stateless Address Autoconfiguration (SLAAC) mechanism.
对于IPv6，作为对[RFC4192]的补充，在[THINK]中起草了实用方面的有用说明。如图所示，主要要求是将重新编号造成的中断降至最低。这适用于两个级别：一般情况下对站点操作的中断，以及在重新编号时对正在进行的单个应用程序会话的中断。在IPv6情况下，重叠使用新旧前缀的固有能力大大减少了对正在进行的会话的中断，如[RFC4192]所述。这种方法实际上不适用于IPv4，主要是因为IPv4缺少无状态地址自动配置（SLAAC）机制。
For IPv4, the vast majority of client systems (PCs, workstations, and handheld computers) today use DHCP to obtain their addresses and other network-layer parameters. DHCP provides for lifetimes after which the address lease expires. So it should be possible to devise an operational procedure in which lease expiry coincides with the moment of renumbering (within some margin of error). In the simplest case, the network administrator just lowers all DHCP address lease lifetimes to a very short value (e.g., a few minutes). It does this long enough before a site-wide change that each node will automatically pick up its new IP address within a few minutes of the renumbering event. In this case, it would be the DHCP server itself that automatically accomplishes client renumbering, although this would cause a peak of DHCP traffic and therefore would not be instantaneous. DHCPv6 could accomplish a similar result.
对于IPv4，目前绝大多数客户端系统（PC、工作站和手持计算机）都使用DHCP获取其地址和其他网络层参数。DHCP提供了地址租约到期后的生存期。因此，应该有可能设计出一种操作程序，使租约到期与重新编号的时间一致（在一定的误差范围内）。在最简单的情况下，网络管理员只需将所有DHCP地址租用寿命降低到一个非常短的值（例如，几分钟）。在站点范围内的更改之前，每个节点将在重新编号事件发生后的几分钟内自动获取其新IP地址。在这种情况下，自动完成客户端重新编号的将是DHCP服务器本身，尽管这会导致DHCP流量峰值，因此不会是瞬时的。DHCPv6可以实现类似的结果。
The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203]. This is specifically unicast-only; a DHCP client must discard a multicast FORCERENEW. This could nevertheless be used to trigger the renumbering process, with the DHCP server cycling through all its clients issuing a FORCERENEW to each one. DHCPv6 has a similar feature, i.e., a unicast RECONFIGURE message, that can be sent to each host to inform it to check its DHCPv6 server for an update. These two features do not appear to be widely used for bulk renumbering purposes.
FORCERENEW扩展是为IPv4的DHCP定义的[RFC3203]。这是专门的单播；DHCP客户端必须放弃多播强制续订。尽管如此，这仍然可以用于触发重新编号过程，DHCP服务器在其所有客户端之间循环，并向每个客户端发出FORCERENEW。DHCPv6有一个类似的功能，即单播重新配置消息，可以发送到每个主机，通知它检查其DHCPv6服务器的更新。这两项功能似乎并未广泛用于批量重新编号目的。
Procedures for using a DHCP approach to site renumbering will be very different depending on whether the site uses strong or weak asset management. With strong asset management, and careful operational planning, the subnet addresses and masks will be updated in the database, and a script will be run to regenerate the DHCP MAC-to-IP address tables and the DNS zone file. DHCP and DNS timers will be
使用DHCP方法对站点重新编号的过程将非常不同，这取决于站点使用的是强资产管理还是弱资产管理。通过强大的资产管理和仔细的操作规划，将在数据库中更新子网地址和掩码，并运行脚本以重新生成DHCP MAC到IP地址表和DNS区域文件。将使用DHCP和DNS计时器
set temporarily to small values. The DHCP and DNS servers will be fed the new files, and as soon as the previous DHCP leases and DNS TTLs expire, everything will follow automatically, as far as the host IP layer is concerned. In contrast, with weak asset management, and a casual operational approach, the DHCP table will be reconfigured by hand, the DNS zone file will be edited by hand, and when these configurations are installed, there will be a period of confusion until the old leases and TTLs expire. The DHCP FORCERENEW or RECONFIGURE messages could shorten this confusion to some extent.
暂时设置为较小的值。DHCP和DNS服务器将收到新文件，一旦以前的DHCP租约和DNS TTL过期，就主机IP层而言，一切都将自动进行。相比之下，由于资产管理薄弱，且操作方法随意，DHCP表将手动重新配置，DNS区域文件将手动编辑，并且在安装这些配置时，将有一段时间的混乱，直到旧租约和TTL过期。DHCP FORCERENEW或RECONFIGURE消息可以在一定程度上缩短这种混淆。
DHCP, particularly for IPv4, has acquired a very large number of additional capabilities, with approximately 170 options defined at the time of this writing. Although most of these do not carry IP address information, some do (for example, options 68 through 76 all carry various IP addresses). Thus, renumbering mechanisms involving DHCP have to take into account more than the basic DHCP job of leasing an address to each host.
DHCP，特别是IPv4，已经获得了大量的附加功能，在撰写本文时定义了大约170个选项。尽管大多数选项不包含IP地址信息，但有些选项包含IP地址信息（例如，选项68到76都包含各种IP地址）。因此，涉及DHCP的重新编号机制必须考虑的不仅仅是向每个主机租用地址的基本DHCP工作。
SLAAC is much less overloaded with options than DHCP; in fact, its only extraneous capability is the ability to convey a DNS server address. Using SLAAC to force all hosts on a site to renumber is therefore less complex than DHCP, and the difference between strong and weak asset management is less marked. The principle of synchronising the SLAAC and DNS updates, and of reducing the SLAAC lease time and DNS TTL, does not change.
与DHCP相比，SLAAC的选项负担要轻得多；事实上，它唯一无关的功能是传输DNS服务器地址的能力。因此，使用SLAAC强制站点上的所有主机重新编号没有DHCP复杂，资产管理的强弱差别也不那么明显。同步SLAAC和DNS更新以及缩短SLAAC租用时间和DNS TTL的原则不会改变。
We should note a currently unresolved ambiguity in the interaction between DHCPv6 and SLAAC from the host's point of view. RA messages include a 'Managed Configuration' flag known as the M bit, which is supposed to indicate that DHCPv6 is in use. However, it is unspecified whether hosts must interpret this flag rigidly (i.e., may or must only start DHCPv6 if it is set, or if no RAs are received) or whether hosts are allowed or are recommended to start DHCPv6 by default. An added complexity is that DHCPv6 has a 'stateless' mode [RFC3736] in which SLAAC is used to obtain an address, but DHCPv6 is used to obtain other parameters. Another flag in RA messages, the 'Other configuration' or O bit, indicates this.
我们应该注意到，从主机的角度来看，DHCPv6和SLAAC之间的交互存在一个尚未解决的模糊性。RA消息包括一个名为M位的“托管配置”标志，该标志应表示DHCPv6正在使用中。但是，未指定主机是否必须严格解释此标志（即，如果设置了DHCPv6，则可以或只能启动DHCPv6，或者如果未接收到RAs），或者默认情况下是否允许或建议主机启动DHCPv6。更复杂的是，DHCPv6具有“无状态”模式[RFC3736]，其中SLAAC用于获取地址，而DHCPv6用于获取其他参数。RA消息中的另一个标志“其他配置”或O位表示这一点。
Until this ambiguous behaviour is clearly resolved by the IETF, operational problems are to be expected, since different host operating systems have taken different approaches. This makes it difficult for a site network manager to configure systems in such a way that all hosts boot in a consistent way. Hosts will start SLAAC, if so directed by appropriately configured RA messages. However, if one operating system also starts a DHCPv6 client by default, and another one starts it only when it receives the M bit, systematic address management is impeded.
在IETF明确解决这一模棱两可的行为之前，由于不同的主机操作系统采用了不同的方法，操作问题是可以预料的。这使得站点网络管理器很难配置所有主机以一致方式引导的系统。如果由适当配置的RA消息指示，主机将启动SLAAC。但是，如果一个操作系统在默认情况下也启动DHCPv6客户机，而另一个操作系统仅在接收到M位时启动它，则系统地址管理将受到阻碍。
Also, it should be noted that on an isolated LAN, neither RA nor DHCPv6 responses will be received, and the host will remain with only its self-assigned link-local address. One could also have a situation where a multihomed network uses SLAAC for one address prefix and DHCPv6 for another, which would clearly create a risk of inconsistent host behaviour and operational confusion.
另外，应该注意的是，在一个隔离的LAN上，既不会收到RA也不会收到DHCPv6响应，主机将只保留其自分配的链路本地地址。还有一种情况是，多宿网络使用SLAAC作为一个地址前缀，使用DHCPv6作为另一个地址前缀，这显然会造成主机行为不一致和操作混乱的风险。
Neither the SLAAC approach nor DHCP without pre-registered MAC addresses will work reliably in all cases of systems that are assigned fixed IP addresses for practical reasons. Of course, even systems with static addressing can be configured to use DHCP to obtain their IP address(es). Such use of "Static DHCP" usually will ease site renumbering when it does become necessary. However, in other cases, manual or script-driven procedures, likely to be site-specific and definitely prone to human error, are needed. If a site has even one host with a fixed, manually configured address, completely automatic host renumbering is very likely to be impossible.
无论是SLAAC方法还是没有预先注册MAC地址的DHCP，都不会在出于实际原因而分配固定IP地址的系统的所有情况下可靠地工作。当然，即使是具有静态寻址的系统也可以配置为使用DHCP来获取其IP地址。这种“静态DHCP”的使用通常会在必要时简化站点重新编号。然而，在其他情况下，需要手动或脚本驱动的过程，这些过程可能是特定于站点的，并且肯定容易出现人为错误。如果一个站点甚至有一台主机具有固定的、手动配置的地址，则完全自动重新编号主机很可能是不可能的。
The above assumes the use of typical off-the-shelf hardware and software. There are other environments, often referred to as embedded systems, where DHCP or SLAAC might not be used and even configuration scripts might not be an option; for example, fixed IP addresses might be stored in read-only memory, or even set up using Dual In-Line Package (DIP) switches. Such systems create special problems that no general-purpose solution is likely to address.
以上假设使用典型的现成硬件和软件。还有其他环境，通常被称为嵌入式系统，其中可能不使用DHCP或SLAAC，甚至配置脚本也可能不是选项；例如，固定IP地址可以存储在只读存储器中，甚至可以使用双列直插式封装（DIP）开关进行设置。这样的系统会产生特殊的问题，没有通用的解决方案能够解决这些问题。
TCP connections and UDP flows are rigidly bound to a given pair of IP addresses. These are included in the checksum calculation, and there is no provision at present for the endpoint IP addresses to change. It is therefore fundamentally impossible for the flows to survive a renumbering event at either end. From an operational viewpoint, this means that a site that plans to renumber itself is obliged either to follow the overlapped procedure described in [RFC4192] or to announce a site-wide outage for the renumbering process, during which all user sessions will fail. In the case of IPv4, overlapping of the old and new addresses is unlikely to be an option, and in any case is not commonly supported by software. Therefore, absent enhancements to TCP and UDP to enable dynamic endpoint address changes (for example, [HANDLEY]), interruptions to TCP and UDP sessions seem inevitable if renumbering occurs at either session endpoint. The same appears to be true of Datagram Congestion Control Protocol (DCCP) [RFC4340].
TCP连接和UDP流严格绑定到给定的一对IP地址。这些都包含在校验和计算中，目前没有更改端点IP地址的规定。因此，流根本不可能在两端的重新编号事件中幸存下来。从操作角度来看，这意味着计划重新编号的站点必须遵循[RFC4192]中所述的重叠程序，或者宣布重新编号过程的站点范围中断，在此期间，所有用户会话都将失败。在IPv4的情况下，新旧地址的重叠不太可能是一种选择，而且在任何情况下，软件通常都不支持。因此，如果没有对TCP和UDP进行增强以支持动态端点地址更改（例如，[HANDLEY]），则如果在任一会话端点处发生重新编号，TCP和UDP会话的中断似乎是不可避免的。数据报拥塞控制协议（DCCP）[RFC4340]似乎也是如此。
In contrast, Stream Control Transmission Protocol (SCTP) already supports dynamic multihoming of session endpoints, so SCTP sessions ought not be adversely impacted by renumbering the SCTP session endpoints [RFC4960] [RFC5061].
相比之下，流控制传输协议（SCTP）已经支持会话端点的动态多宿主，因此SCTP会话不应该通过对SCTP会话端点重新编号[RFC4960][RFC5061]而受到不利影响。
The main issue is whether the site in question has a systematic procedure for updating its DNS configuration. If it does, updating the DNS for a renumbering event is essentially a clerical issue that must be coordinated as part of a complete plan, including both forward and reverse mapping. As mentioned in [RFC4192], the DNS TTL will be manipulated to ensure that stale addresses are not cached. However, if the site uses a weak asset management model in which DNS updates are made manually on demand, there will be a substantial period of confusion and errors will be made.
主要问题是该站点是否有更新其DNS配置的系统程序。如果需要，更新重新编号事件的DNS基本上是一个文书问题，必须作为完整计划的一部分进行协调，包括正向和反向映射。如[RFC4192]中所述，将对DNS TTL进行操作，以确保不缓存过时的地址。但是，如果站点使用的是一种薄弱的资产管理模型，在这种模型中，DNS更新是按需手动进行的，那么将会有相当长的一段时间出现混乱，并且会出现错误。
There are anecdotal reports that many small user sites do not even maintain their own DNS configuration, despite running their own web and email servers. They point to their ISP's resolver, request the ISP to install DNS entries for their servers, but operate internally mainly by IP address. Thus, renumbering for such sites will require administrative coordination between the site and its ISP(s), unless the DNS servers in use have Secure Dynamic DNS Update enabled. Some commercial DNS service firms include Secure Dynamic DNS Update as part of their DNS service offering.
有传闻称，许多小用户站点甚至不维护自己的DNS配置，尽管它们运行自己的web和电子邮件服务器。他们指向ISP的解析器，请求ISP为其服务器安装DNS条目，但主要通过IP地址在内部运行。因此，为此类站点重新编号将需要站点与其ISP之间的管理协调，除非使用中的DNS服务器已启用安全动态DNS更新。一些商业DNS服务公司将安全动态DNS更新作为其DNS服务的一部分。
It should be noted that DNS entries commonly have matching Reverse DNS entries. When a site renumbers, these reverse entries will also need to be updated. Depending on a site's operational arrangements for DNS support, it might or might not be possible to combine forward and reverse DNS updates in a single procedure.
应该注意的是，DNS条目通常具有匹配的反向DNS条目。当站点重新编号时，这些反向条目也需要更新。根据站点对DNS支持的操作安排，在单个过程中可能会或可能不会合并正向和反向DNS更新。
Ideally, we would carry out a renumbering analysis for each application protocol. To some extent, this has been done, in [RFC3795]. This found that 34 out of 257 Standards-Track or Experimental application-layer RFCs had explicit address dependencies. Although this study was made in the context of IPv4 to IPv6 transition, it is clear that all these protocols might be sensitive to renumbering. However, the situation is worse, in that there is no way to discover by analyzing specifications whether an actual implementation is sensitive to renumbering. Indeed, such analysis might be quite impossible in the case of proprietary applications.
理想情况下，我们将对每个应用程序协议进行重新编号分析。在某种程度上，这已经在[RFC3795]中完成。这发现257个标准跟踪或实验应用层RFC中有34个具有显式地址依赖性。尽管这项研究是在IPv4向IPv6过渡的背景下进行的，但很明显，所有这些协议都可能对重新编号很敏感。然而，情况更糟，因为无法通过分析规范来发现实际实现是否对重新编号敏感。事实上，在专有应用程序的情况下，这样的分析可能是不可能的。
The sensitivity depends on whether the implementation stores IP addresses in such a way that it might refer back to them later, without allowing for the fact that they might no longer be valid. In general, we can assert that any implementation is at risk from renumbering if it does not check that an address is valid each time it opens a new communications session. This could be done, for example, by knowing and respecting the relevant DNS TTL, or by resolving relevant Fully-Qualified Domain Names (FQDNs) again. A common experience is that even when FQDNs are stored in configuration files, they are resolved only once, when the application starts, and they are cached indefinitely thereafter. This is insufficient. Of course, this does not apply to all application software; for example, several well-known web browsers have short default cache lifetimes.
敏感度取决于实现是否以这样的方式存储IP地址，即在不考虑IP地址可能不再有效的情况下，它以后可能会引用这些地址。通常，我们可以断言，如果每次打开新的通信会话时都没有检查地址是否有效，那么任何实现都有重新编号的风险。例如，可以通过了解并尊重相关的DNS TTL，或者通过再次解析相关的完全限定域名（FQDN）来做到这一点。一个常见的经验是，即使FQDN存储在配置文件中，它们也只在应用程序启动时解析一次，然后无限期地缓存。这是不够的。当然，这并不适用于所有应用软件；例如，一些著名的web浏览器具有较短的默认缓存生存期。
There are even more egregious breaches of this principle, for example, software license systems that depend on the licensed host computer having a particular IP address. Other examples are the use of literal IP addresses in URLs, HTTP cookies, or application proxy configurations. (Also see Appendix A.)
甚至还有更严重的违反这一原则的行为，例如，软件许可证系统依赖于具有特定IP地址的许可主机。其他示例包括在URL、HTTP Cookie或应用程序代理配置中使用文字IP地址。（另见附录A）
In contrast, there are also many application suites that actively deal with connectivity failures by retrying with alternative addresses or by repeating DNS lookups. This places a considerable burden of complexity on application developers.
相比之下，还有许多应用程序套件通过使用替代地址重试或重复DNS查找来主动处理连接故障。这给应用程序开发人员带来了相当大的复杂性负担。
It should be noted that applications are in effect encouraged to be aware of and to store IP addresses by the very nature of the socket API calls gethostbyname() and getaddrinfo(). It is highly unfortunate that many applications use APIs that require the application to see and use lower-layer objects, such as network-layer addresses. However, the BSD Sockets API was designed and deployed before the Domain Name System (DNS) was created, so there were few good options at the time. This issue is made worse by the fact that these functions do not return an address lifetime, so that applications have no way to know when an address is no longer valid. The extension of the same model to cover IPv6 has complicated this problem somewhat. An application using the socket API is obliged to contain explicit logic if it wishes to benefit from the availability of multiple addresses for a given remote host. If a programming model were adopted in which only FQDNs were exposed to applications, and addresses were cached with appropriate lifetimes within the API, most of these problems would disappear. It should be noted that at least the first part of this is already available for some programming environments. A common example is Java, where only FQDNs need to be handled by application code in normal circumstances, and no additional application logic is needed to deal with multiple addresses, which are handled by the run-time system. This is highly beneficial for programmers who are not networking experts, and
应该注意的是，实际上，通过套接字API调用gethostbyname（）和getaddrinfo（）的本质，鼓励应用程序了解并存储IP地址。非常不幸的是，许多应用程序使用的API要求应用程序查看和使用较低层对象，如网络层地址。然而，BSD套接字API是在创建域名系统（DNS）之前设计和部署的，因此当时没有什么好的选择。更糟糕的是，这些函数不返回地址生存期，因此应用程序无法知道地址何时不再有效。同一模型的扩展覆盖了IPv6，这在一定程度上使这个问题复杂化了。如果应用程序希望从给定远程主机的多个地址的可用性中获益，则使用套接字API的应用程序必须包含显式逻辑。如果采用一种编程模型，其中只有FQDN向应用程序公开，并且在API中以适当的生命周期缓存地址，那么这些问题中的大多数都会消失。应该注意的是，至少第一部分已经适用于某些编程环境。一个常见的例子是Java，在正常情况下，应用程序代码只需要处理FQDN，而不需要额外的应用程序逻辑来处理运行时系统处理的多个地址。这对不是网络专家的程序员非常有益，而且
insulates applications software from many aspects of renumbering. It would be helpful to have similarly abstract, DNS-oriented, Networking APIs openly specified and widely available for C and C++.
将应用软件与重新编号的许多方面隔离开来。有了类似的抽象、面向DNS的、网络公开的API，将有助于C和C++的广泛使用。
Some web browsers intentionally violate the DNS TTL with a technique called "DNS Pinning." DNS Pinning limits acceptance of server IP address changes, due to a JavaScript issue where repeated address changes can be used to induce a browser to scan the inside of a firewalled network and report the results to an outside attacker. Pinning can persist as long as the browser is running, in extreme cases perhaps months at a time. Thus, we can see that security considerations may directly damage the ability of applications to deal with renumbering.
一些web浏览器故意使用一种称为“DNS锁定”的技术违反DNS TTL。DNS锁定限制了服务器IP地址更改的接受，因为JavaScript问题可使用重复的地址更改来诱导浏览器扫描防火墙网络的内部，并将结果报告给外部攻击者。只要浏览器在运行，锁定就会持续，在极端情况下，一次锁定可能持续数月。因此，我们可以看到，安全考虑可能会直接损害应用程序处理重新编号的能力。
Server applications might need to be restarted when the host they contain is renumbered, to ensure that they are listening on a port and socket bound to the new address. In an IPv6 multi-addressed host, server applications need to be able to listen on more than one address simultaneously, in order to cover an overlap during renumbering. Not all server applications are written to do this, and a name-based API as just mentioned would have to provide for this case invisibly to the server code.
当服务器应用程序包含的主机重新编号时，可能需要重新启动服务器应用程序，以确保它们正在侦听绑定到新地址的端口和套接字。在IPv6多地址主机中，服务器应用程序需要能够同时侦听多个地址，以便在重新编号期间覆盖重叠。并非所有的服务器应用程序都是这样编写的，而刚才提到的基于名称的API必须在服务器代码中不可见地提供这种情况。
As noted in Section 2.6, the Service Location Protocol (SLP), and multicast DNS with SRV records for service discovery, have been available for some years. For example, many printers deployed in recent years automatically advertise themselves to potential clients via SLP. Many modern client operating systems automatically participate in SLP without requiring users to enable it. These tools appear not to be widely known, although they can be used to reduce the number of places that IP addresses need to be configured.
如第2.6节所述，服务位置协议（SLP）和带有SRV记录的用于服务发现的多播DNS已经存在多年。例如，近年来部署的许多打印机通过SLP自动向潜在客户宣传自己。许多现代客户端操作系统自动参与SLP，而无需用户启用它。这些工具似乎并不广为人知，尽管它们可以用来减少需要配置IP地址的位置数量。
[RFC2072] gives a detailed review of the operational realities in 1997. A number of the issues discussed in that document were the result of the relatively recent adoption of classless addressing; those issues can be assumed to have vanished by now. Also, DHCP was a relative newcomer at that time, and can now be assumed to be generally available. Above all, the document underlines that systematic planning and administrative preparation are needed, and that all forms of configuration file and script must be reviewed and updated. Clearly this includes filtering and routing rules (e.g., when peering with BGP, but also with intradomain routing as well). Two particular issues mentioned in [RFC2072] are:
[RFC2072]详细回顾了1997年的运营现实。该文件中讨论的一些问题是最近采用无类别寻址的结果；可以认为这些问题现在已经消失了。此外，DHCP在当时是一个相对较新的产品，现在可以假定它是普遍可用的。最重要的是，该文件强调需要进行系统规划和行政准备，必须审查和更新所有形式的配置文件和脚本。显然，这包括过滤和路由规则（例如，当使用BGP进行对等时，也包括域内路由）。[RFC2072]中提到的两个特殊问题是：
o Some routers cache IP addresses in some situations. So routers might need to be restarted as a result of site renumbering.
o 某些路由器在某些情况下缓存IP地址。因此，由于站点重新编号，路由器可能需要重新启动。
o Addresses might be used by configured tunnels, including VPN tunnels, although at least the Internet Key Exchange (IKE) supports the use of Fully-Qualified Domain Names instead.
o 虽然至少Internet密钥交换（IKE）支持使用完全限定的域名，但已配置的隧道（包括VPN隧道）可能会使用地址。
On the latter point, the capability to use FQDNs as endpoint names in IPsec VPNs is not new and is standard (see [RFC2407], Section 4.6.2.3 and [RFC4306], Section 3.5). This capability is present in most IPsec VPN implementations. There does seem to be an "educational" or "awareness" issue that many system/network administrators do not realise that it is there and works well as a way to avoid manual modification during renumbering. (Of course, even in this case, a VPN may need to be reconnected after a renumbering event, but most products appear to handle this automatically.)
在后一点上，在IPsec VPN中使用FQDN作为端点名称的功能不是新的，而是标准的（请参见[RFC2407]，第4.6.2.3节和[RFC4306]，第3.5节）。大多数IPsec VPN实现中都具有此功能。似乎确实存在一个“教育”或“意识”问题，许多系统/网络管理员没有意识到这一点，这是一种避免在重新编号过程中手动修改的方法。（当然，即使在这种情况下，VPN也可能需要在重新编号事件后重新连接，但大多数产品似乎会自动处理此问题。）
In IPv6, if a site wanted to be multihomed using multiple provider-aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths.
在IPv6中，如果一个站点希望使用多个提供商聚合（PA）路由前缀（每个上游提供商有一个前缀）进行多宿，那么内部路由器将需要一种机制来了解哪些上游提供商和前缀当前可访问（且有效）。在这种情况下，可以动态更新它们的路由器公告消息，以便只向主机公告当前有效的路由前缀。如果不同的提供者前缀长度不同，或者站点的子网前缀长度不一致，那么这将非常复杂。
When a renumbering event takes place, entries in the state table of any Network Address Translator that happen to contain the affected addresses will become invalid and will eventually time out. Since TCP and UDP sessions are unlikely to survive renumbering anyway, the hosts involved will not be additionally affected. The situation is more complex for multihomed SCTP [SCTPNAT], depending on whether a single or multiple NATs are involved.
发生重新编号事件时，任何网络地址转换器的状态表中碰巧包含受影响地址的条目将变为无效，并最终超时。由于TCP和UDP会话无论如何都不可能继续重新编号，因此所涉及的主机不会受到额外影响。对于多宿SCTP[SCTPNAT]，情况更为复杂，这取决于涉及的是单个NAT还是多个NAT。
A NAT itself might be renumbered and might need a configuration change during a renumbering event. One of the authors has a NAT-enabled home gateway that obtains its exterior address from the residential Internet service provider by acting as a DHCP client. That deployment has not suffered operational problems when the ISP uses DHCP to renumber the gateway's exterior IP address. A critical part of that success has been configuring IKE on the home gateway to use a "mailbox name" for the user's identity type (rather than using the exterior IP address of the home gateway) when creating or managing the IP Security Associations.
NAT本身可能会重新编号，并且在重新编号事件期间可能需要更改配置。其中一位作者拥有一个支持NAT的家庭网关，该网关通过充当DHCP客户端从住宅互联网服务提供商处获取其外部地址。当ISP使用DHCP对网关的外部IP地址重新编号时，该部署没有遇到操作问题。成功的一个关键部分是在家庭网关上配置IKE，以便在创建或管理IP安全关联时使用“邮箱名称”作为用户的身份类型（而不是使用家庭网关的外部IP地址）。
A mobile node using Mobile IP that is not currently in its home network will be adversely affected if either its current care-of address or its home address is renumbered. For IPv6, if the care-of address changes, this will be exactly like moving from one foreign network to another, and Mobile IP will re-bind with its home agent in the normal way. If its home address changes unexpectedly, it can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC3775]. The situation is more tricky if the mobile node is detached at the time of the renumbering event, since it will no longer know a valid subnet anycast address for its home agent, leaving it to deduce a valid address on the basis of DNS information.
使用移动IP的移动节点当前不在其家庭网络中，如果其当前转交地址或其家庭地址被重新编号，则该移动节点将受到不利影响。对于IPv6，如果转交地址发生变化，这将完全类似于从一个外部网络移动到另一个外部网络，移动IP将以正常方式与其归属代理重新绑定。如果其家庭地址意外更改，则可通过移动前缀请求和移动前缀广告ICMPv6消息[RFC3775]通知其家庭站点使用的新全局路由前缀。如果移动节点在重新编号事件时分离，则情况更为棘手，因为它将不再知道其归属代理的有效子网选播地址，而让它根据DNS信息推断有效地址。
In contrast to Mobile IPv6, Mobile IPv4 does not support prefix solicitation and prefix advertisement messages, limiting its renumbering capability to well-scheduled renumbering events when the mobile node is connected to its home agent and managed by the home network administration. Unexpected home network renumbering events when the mobile node is away from its home network and not connected to the home agent are supported only if a relevant Authentication, Authorisation, and Accounting (AAA) system is able to allocate dynamically a home address and home agent for the mobile node.
与移动IPv6相比，移动IPv4不支持前缀请求和前缀广告消息，当移动节点连接到其归属代理并由归属网络管理部门管理时，将其重新编号功能限制为安排良好的重新编号事件。仅当相关认证、授权和计费（AAA）系统能够为移动节点动态分配归属地址和归属代理时，才支持移动节点远离其归属网络且未连接到归属代理时的意外归属网络重新编号事件。
As discussed in [THINK], IPv6 multicast can be used to help rather than hinder renumbering, for example, by using multicast as a discovery protocol (as in IPv6 Neighbour Discovery). On the other hand, the embedding of IPv6 unicast addresses into multicast addresses specified in [RFC3306] and the embedded-RP (Rendezvous Point) in [RFC3956] will cause issues when renumbering.
如[THINK]中所述，IPv6多播可用于帮助而不是阻碍重新编号，例如，通过将多播用作发现协议（如IPv6邻居发现）。另一方面，将IPv6单播地址嵌入[RFC3306]中指定的多播地址和[RFC3956]中嵌入的RP（集合点）将在重新编号时引起问题。
For both IPv4 and IPv6, changing the unicast source address of a multicast sender might also be an issue for receivers, especially for Source-Specific Multicast (SSM). Applications need to learn the new source addresses and new multicast trees need to be built
对于IPv4和IPv6，更改多播发送方的单播源地址对于接收方来说可能也是一个问题，特别是对于源特定多播（SSM）。应用程序需要学习新的源地址，并且需要构建新的多播树
For IPv4 or IPv6 with Any-Source Multicast (ASM), renumbering can be easy. If sources are renumbered, from the routing perspective, things behave just as if there are new sources within the same multicast group. There may be application issues though. Changing the RP address is easy when using Bootstrap Router (BSR) [RFC5059] for dynamic RP discovery. BSR is widely used, but it is also common to use static config of RP addresses on routers. In that case, router configurations must be updated too.
对于具有任何源多播（ASM）的IPv4或IPv6，重新编号可能很容易。如果源被重新编号，从路由的角度来看，事情的行为就像在同一个多播组中有新的源一样。不过，可能存在应用程序问题。使用引导路由器（BSR）[RFC5059]进行动态RP发现时，更改RP地址很容易。BSR被广泛使用，但在路由器上使用RP地址的静态配置也很常见。在这种情况下，路由器配置也必须更新。
If any multicast ACLs are configured, they raise the same issue as unicast ACLs mentioned elsewhere.
如果配置了任何多播ACL，它们会引发与其他地方提到的单播ACL相同的问题。
Today, static IP addresses are routinely embedded in numerous configuration files and network management databases, including MIB modules. Ideally, all of these would be generated from a single central asset management database for a given site, but this is far from being universal practice. It should be noted that for IPv6, where multiple routing prefixes per interface and multiple addresses per interface are standard practice, the database and the configuration files will need to allow for this (rather than for a single address per host, as is normal practice for IPv4).
如今，静态IP地址通常嵌入到许多配置文件和网络管理数据库中，包括MIB模块。理想情况下，所有这些都将从给定站点的单个中央资产管理数据库生成，但这远不是普遍做法。需要注意的是，对于IPv6，每个接口有多个路由前缀，每个接口有多个地址是标准做法，数据库和配置文件需要考虑到这一点（而不是像IPv4的正常做法那样，每个主机有一个地址）。
Furthermore, because of routing policies and VPNs, a site or network might well embed addresses from other sites or networks in its own configuration data. (It is preferable to embed FQDNs instead, of course, whenever possible.) Thus, renumbering will cause a ripple effect of updates for a site and for its neighbours. To the extent that these updates are manual, they will be costly and prone to error. Synchronising updates between independent sites can cause unpredictable delays. Note that Section 4 suggests that IPv6 ULAs can mitigate this problem, but of course only for VPNs and routes that are suitable for ULAs rather than globally routeable addresses. The majority of external addresses to be configured will not be ULAs.
此外，由于路由策略和VPN，站点或网络可能会在其自身的配置数据中嵌入来自其他站点或网络的地址。（当然，只要可能，最好嵌入FQDN。）因此，重新编号将对站点及其邻居的更新产生连锁反应。如果这些更新是手动的，那么它们的成本会很高，并且容易出错。在独立站点之间同步更新可能会导致不可预知的延迟。请注意，第4节建议IPv6 ULA可以缓解此问题，但当然仅适用于适合ULA的VPN和路由，而不是全局可路由地址。要配置的大多数外部地址将不是ULA。
See Appendix A for an extended list of possible static or embedded addresses.
有关可能的静态或嵌入式地址的扩展列表，请参见附录A。
Some address configuration data are relatively easy to find (for example, site firewall rules, ACLs in site border routers, and DNS). Others might be widely dispersed and much harder to find (for example, configurations for building routers, printer addresses configured by individual users, and personal firewall configurations). Some of these will inevitably be found only after the renumbering event, when the users concerned encounter a problem.
一些地址配置数据相对容易找到（例如，站点防火墙规则、站点边界路由器中的ACL和DNS）。其他配置可能分布广泛，更难找到（例如，构建路由器的配置、由单个用户配置的打印机地址以及个人防火墙配置）。只有在重新编号事件之后，当相关用户遇到问题时，才会不可避免地发现其中一些问题。
The overlapped model for IPv6 renumbering, with old and new addresses valid simultaneously, means that planned database and configuration file updates will proceed in two stages -- add the new information some time before the renumbering event, and remove the old information some time after. All policy rules must be configured to behave correctly during this process (e.g., preferring the new address as soon as possible). Similarly, monitoring tools must be set up to monitor both old and new during the overlap.
IPv6重新编号的重叠模型（新旧地址同时有效）意味着计划中的数据库和配置文件更新将分两个阶段进行——在重新编号事件前一段时间添加新信息，在重新编号事件后一段时间删除旧信息。必须将所有策略规则配置为在此过程中正确运行（例如，尽快首选新地址）。同样，必须设置监控工具，以便在重叠期间监控旧的和新的。
However, it should be noted that the notion of simultaneously operating multiple prefixes for the same network, although natural for IPv6, is generally not supported by operational tools such as address management software. It also increases the size of IGP routing tables in proportion to the number of prefixes in use. For these reasons, and due to its unfamiliarity to operational staff, the use of multiple prefixes remains rare. Accordingly, the use of ULAs to provide stable on-site addresses even if the off-site prefix changes is also rare.
但是，应该注意的是，虽然IPv6很自然，但同时为同一网络操作多个前缀的概念通常不受地址管理软件等操作工具的支持。它还根据使用的前缀数量按比例增加IGP路由表的大小。由于这些原因，并且由于操作人员对其不熟悉，使用多个前缀的情况仍然很少。因此，使用ULA提供稳定的现场地址（即使非现场前缀发生变化）也很少见。
If both IPv4 and IPv6 are renumbered simultaneously in a dual-stack network, additional complications could result, especially with configured IP-in-IP tunnels. This scenario should probably be avoided.
如果在双栈网络中同时对IPv4和IPv6重新编号，可能会导致额外的复杂性，尤其是在IP隧道中配置IP时。这种情况可能应该避免。
Use of FQDNs rather than raw IP addresses wherever possible in configuration files and databases will reduce/mitigate the potential issues arising from such configuration files or management databases when renumbering is required or otherwise occurs. This is advocated in [RFC1958] (point 4.1). Just as we noted in Section 5.1.4 for applications, this is insufficient in itself; some devices such as routers are known to only resolve FQDNs once, at start-up, and to continue using the resulting addresses indefinitely. This may require routers to be rebooted, when they should instead be resolving the FQDN again after a given timeout.
在配置文件和数据库中尽可能使用FQDN而不是原始IP地址，这将减少/缓解在需要重新编号或以其他方式发生时由此类配置文件或管理数据库引起的潜在问题。[RFC1958]（第4.1点）中提出了这一点。正如我们在第5.1.4节中提到的应用，这本身是不够的；已知一些设备（如路由器）在启动时只解析FQDN一次，并无限期地继续使用生成的地址。这可能需要重新启动路由器，而路由器应该在给定超时后再次解析FQDN。
By definition, there is at least one place (i.e., the DNS zone file or the database from which it is derived) where address information is nevertheless inevitable.
根据定义，至少有一个位置（即DNS区域文件或从中派生的数据库）的地址信息是不可避免的。
It is also possible that some operators may choose to configure addresses rather than names, precisely to avoid a possible circular dependency and the resulting failure modes. This is arguably even advocated in [RFC1958] (point 3.11).
某些操作员也可能选择配置地址而不是名称，以避免可能的循环依赖和由此产生的故障模式。这在[RFC1958]（第3.11点）中甚至可以说是主张的。
It should be noted that the management and administration issues (i.e., tracking down, recording, and updating all instances where addresses are stored rather than looked up dynamically) form the dominant concern of managers considering the renumbering problem. This has led many sites to continue the pre-CIDR (Classless Inter-Domain Routing) approach of using a provider-independent (PI) prefix. Some sites, including very large corporate networks, combine PI addressing with NAT. Others have adopted private addressing and NAT as a matter of choice rather than obligation. This range of techniques allows for addressing plans that are independent of the ISP(s) in use, and allows a straightforward approach to multihoming. The direct cost of renumbering is perceived to exceed the indirect costs of these alternatives. Additionally, there is a risk element
应该注意的是，管理和行政问题（即跟踪、记录和更新存储地址而不是动态查找地址的所有实例）构成了考虑重新编号问题的管理者的主要关注点。这导致许多站点继续采用CIDR（无类域间路由）之前的方法，即使用独立于提供商（PI）前缀。一些站点，包括非常大的公司网络，将PI寻址与NAT相结合。其他人则将私人寻址和NAT作为一种选择而非义务。这一系列技术允许寻址独立于使用中的ISP的计划，并允许直接的多址方法。重新编号的直接成本被认为超过了这些替代方案的间接成本。此外，还有一个风险因素
stemming from the complex dependencies of renumbering: it is hard to be fully certain that the renumbering will not cause unforeseen service disruptions, leading to unknown additional costs.
源于重新编号的复杂依赖关系：很难完全确定重新编号不会导致无法预见的服务中断，从而导致未知的额外成本。
A relevant example in a corporate context is VPN configuration data held in every employee laptop, for use while on travel and connecting securely from remote locations. Typically, such VPNs are statically configured using numeric IP addresses for endpoints and even with prefix lists for host routing tables. Use of VPN configurations with FQDNs to name fixed endpoints, such as corporate VPN gateways, and with non-address identity types would enable existing IP Security with IKE to avoid address renumbering issues and work well for highly mobile users. This is all possible today with standard IPsec and standard IKE. It just requires VPN software to be configured with names instead of addresses, and thoughtful network administration.
公司环境中的一个相关示例是每个员工笔记本电脑中保存的VPN配置数据，用于出差和远程安全连接。通常，此类VPN静态配置为使用端点的数字IP地址，甚至使用主机路由表的前缀列表。使用带有FQDNs的VPN配置来命名固定端点（如公司VPN网关）和使用非地址标识类型，将使IKE的现有IP安全性能够避免地址重新编号问题，并能很好地适用于高度移动的用户。今天，通过标准IPsec和标准IKE，这一切都是可能的。它只需要VPN软件配置名称而不是地址，以及周到的网络管理。
It should be noted that site and network operations managers are often very conservative, and reluctant to change operational procedures that are working reasonably well and are perceived as reasonably secure. They quite logically argue that any change brings with it an intrinsic risk of perturbation and insecurity. Thus, even if procedural changes are recommended that will ultimately reduce the risks and difficulties of renumbering (such as using FQDNs protected by DNSsec where addresses are used today), these changes might be resisted.
应该注意的是，站点和网络运营经理通常非常保守，不愿意更改运行良好且被认为相当安全的运营程序。他们非常合乎逻辑地认为，任何变化都会带来不安和不安全的内在风险。因此，即使建议进行程序性更改，以最终降低重新编号的风险和困难（例如使用由DNSsec保护的FQDN，其中当前使用的地址），这些更改也可能会受到抵制。
For IPv6, addresses are intended to be protected against forgery during neighbour discovery by SEcure Neighbour Discovery (SEND) [RFC3971]. This appears to be a very useful precaution during dynamic renumbering, to prevent hijacking of the process by an attacker. Any automatic renumbering scheme has a potential exposure to such hijacking at the moment that a new address is announced. However, at present it is unclear whether or when SEND might be widely implemented or widely deployed.
对于IPv6，地址旨在通过安全邻居发现（SEND）[RFC3971]在邻居发现期间防止伪造。这似乎是动态重新编号期间非常有用的预防措施，以防止攻击者劫持进程。在宣布新地址时，任何自动重新编号方案都有可能遭到此类劫持。然而，目前尚不清楚SEND是否或何时会被广泛实施或部署。
Firewall rules will certainly need to be updated, and any other cases where addresses or address prefixes are embedded in security components (access control lists, AAA systems, intrusion detection systems, etc.). If this is not done in advance, legitimate access to resources might be blocked after the renumbering event. If the old rules are not removed promptly, illegitimate access might be possible after the renumbering event. Thus, the security updates will need to be made in two stages (immediately before and immediately after the event).
防火墙规则肯定需要更新，在任何其他情况下，地址或地址前缀嵌入到安全组件中（访问控制列表、AAA系统、入侵检测系统等）。如果事先没有这样做，重新编号事件后可能会阻止对资源的合法访问。如果不及时删除旧规则，则在重新编号事件后可能会出现非法访问。因此，安全更新需要分两个阶段进行（事件之前和之后）。
There will be operational and security issues if an X.509v3 Public Key Infrastructure (PKI) Certificate includes a subjectAltName extension that contains an iPAddress [RFC5280], and if the corresponding node then undergoes an IP address change without a concurrent update to the node's PKI Certificate. For these reasons, use of the dNSName rather than the iPAddress is recommended for the subjectAltName extension. Any other use of IP addresses in cryptographic material is likely to be similarly troublesome.
如果X.509v3公钥基础设施（PKI）证书包含包含iPAddress[RFC5280]的subjectAltName扩展，并且相应节点随后进行IP地址更改而没有对节点的PKI证书进行同步更新，则会出现操作和安全问题。出于这些原因，建议subjectAltName扩展名使用dNSName而不是iPAddress。在加密材料中使用任何其他IP地址都可能会带来类似的麻烦。
If a site is, for some reason, listed by IP address in a white list (such as a spam white list), this will need to be updated. Conversely, a site that is listed in a black list can escape that list by renumbering itself.
如果由于某种原因，某个站点在白名单（如垃圾邮件白名单）中按IP地址列出，则需要进行更新。相反，黑名单中列出的站点可以通过重新编号自身来逃避黑名单。
The use of IP addresses instead of FQDNs in configurations is sometimes driven by a perceived security need. Since the name resolution process has historically lacked authentication, administrators prefer to use raw IP addresses when the application is security sensitive (firewalls and VPN are two typical examples). It might be possible to solve this issue in the next few years with DNSsec (see Section 2.5), now that there is strong DNS Security deployment momentum.
在配置中使用IP地址而不是FQDN有时是由感知到的安全需求驱动的。由于名称解析过程历来缺乏身份验证，当应用程序对安全敏感时，管理员更喜欢使用原始IP地址（防火墙和VPN是两个典型示例）。由于DNS安全部署势头强劲，在未来几年内，使用DNSsec（见第2.5节）可能会解决此问题。
SHIM6, proposed as a host-based multihoming mechanism for IPv6, has the property of dynamically switching the addresses used for forwarding the actual packet stream while presenting a constant address as the upper-layer identifier for the transport layer [RFC5533]. At least in principle, this property could be used during renumbering to alleviate the problem described in Section 5.1.2.
作为IPv6的基于主机的多主机制提出的SHIM6具有动态切换用于转发实际数据包流的地址的特性，同时将恒定地址作为传输层的上层标识符[RFC5533]。至少在原则上，该特性可在重新编号期间使用，以缓解第5.1.2节中描述的问题。
SHIM6 is an example of a class of solutions with this or a similar property; others are Host Identity Protocol (HIP), IKEv2 Mobility and Multihoming (MOBIKE), Mobile IPv6, SCTP, and proposals for multi-path TCP.
SHIM6是一类具有此属性或类似属性的解决方案的示例；其他包括主机身份协议（HIP）、IKEv2移动性和多归属（MOBIKE）、移动IPv6、SCTP和多路径TCP方案。
The IETF working groups dealing with mobile ad hoc networks have been working on a number of mechanisms for mobile routers to discover available border routers dynamically, and for those mobile routers to be able to communicate that information to hosts connected to those mobile routers.
IETF处理移动自组织网络的工作组一直在研究一系列机制，以使移动路由器能够动态发现可用的边界路由器，并使这些移动路由器能够将该信息传达给连接到这些移动路由器的主机。
Recently, some MANET work has appeared on a "Border Router Discovery Protocol (BRDP)" that might be useful work towards a more dynamic mechanism for site interior router renumbering [BRDP].
最近，一些MANET工作出现在“边界路由器发现协议（BRDP）”上，这可能是一项有助于站点内部路由器重新编号[BRDP]的更动态机制的工作。
At present, the IETF AUTOCONF WG (http://www.ietf.org/html.charters/autoconf-charter.html) is working on address autoconfiguration mechanisms for MANET networks that also seem useful for ordinary non-mobile non-MANET networks [AUTOC]. This work is extensively surveyed in [AUTOC2] and [AUTOC3]. Other work in the same area, e.g., [RFC5558], might also be relevant.
目前，IETF AUTOCONF工作组(http://www.ietf.org/html.charters/autoconf-charter.html)正在研究MANET网络的地址自动配置机制，该机制似乎对普通非移动非MANET网络也很有用[AUTOC]。[AUTOC2]和[AUTOC3]对这项工作进行了广泛的调查。同一领域的其他工作，例如[RFC5558]，也可能相关。
MANETs are, of course, unusual in that they must be able to reconfigure themselves at all times and without notice. Hence, the type of hidden static configurations discussed above in Section 5.3.4 are simply intolerable in MANETs. Thus, it is possible that when a consensus is reached on autoconfiguration for MANETs, the selected solution(s) might not be suitable for the more general renumbering problem. However, it is certainly worthwhile to explore applying techniques that work for MANETs to conventional networks also.
当然，移动自组网与众不同之处在于，它们必须能够随时在不事先通知的情况下重新配置自己。因此，上文第5.3.4节中讨论的隐藏静态配置类型在MANET中是不可容忍的。因此，当对移动自组网的自动配置达成一致意见时，所选择的解决方案可能不适用于更一般的重新编号问题。然而，探索将适用于移动自组网的技术应用于传统网络也是值得的。
A DHCPv6 extension has been proposed that could convey alternative routes, in addition to the default router address, to IPv6 hosts [DHRTOPT]. Other DHCP options are also on the table that may offer information about address prefixes and routing to DHCP or DHCPv6 clients, such as [DHSUBNET] and [DHMIFRT]. It is conceivable that these might be extended as a way of informing hosts dynamically of prefix changes.
已经提出了一个DHCPv6扩展，除了默认路由器地址之外，它还可以向IPv6主机[DHRTOPT]传输替代路由。表中还列出了其他DHCP选项，这些选项可能提供有关地址前缀和到DHCP或DHCPv6客户端的路由的信息，例如[DHSUBNET]和[DHMIFRT]。可以想象，这些可以扩展为动态通知主机前缀更改的一种方式。
In the area of management tools, Network Configuration (NETCONF) Protocol [RFC4741] is suitable for the configuration of any network element or server, so could in principle be used to support secure remote address renumbering.
在管理工具领域，网络配置（NETCONF）协议[RFC4741]适用于任何网元或服务器的配置，因此原则上可用于支持安全远程地址重新编号。
The DNSOP WG has considered a Name Server Control Protocol (NSCP) based on NETCONF that provides means for consistent DNS management including potential host renumbering events [DNSCONT].
DNSOP工作组考虑了基于NETCONF的名称服务器控制协议（NSCP），该协议提供了一致DNS管理的方法，包括潜在的主机重新编号事件[DNSCONT]。
A proposal has been made to include an address lifetime as an embedded field in IPv6 addresses, with the idea that all prefixes would automatically expire after a certain period and become unrouteable [CROCKER]. While this might be viewed as provocative, it would force the issue by making renumbering compulsory.
有人提议在IPv6地址中包含一个地址生存期作为嵌入字段，其想法是所有前缀将在一段时间后自动过期并变得不可路由[CROCKER]。虽然这可能被视为挑衅，但它将通过强制重新编号来迫使这一问题。
This section seeks to identify technology gaps between what is available from existing open specifications and what appears to be needed for site renumbering to be tolerable.
本节旨在确定现有开放规范中可用的内容与现场重新编号所需的内容之间的技术差距。
It would be beneficial to expose address lifetimes in the socket API, or any low-level networking API. This would allow applications to avoid using stale addresses.
在套接字API或任何低级网络API中公开地址生存期是有益的。这将允许应用程序避免使用过时的地址。
The various current discussions of a name-based transport layer or a name-based network API also have potential to alleviate the application-layer issues noted in this document. Application development would be enhanced by the addition of a more abstract network API that supports the C and C++ programming languages. For example, it could use FQDNs and Service Names, rather than SockAddr, IP Address, protocol, and port number. This would be equivalent to similar interfaces already extant for Java programmers.
当前关于基于名称的传输层或基于名称的网络API的各种讨论也有可能缓解本文档中提到的应用层问题。通过添加支持C和C++编程语言的更抽象的网络API，可以增强应用程序的开发。例如，它可以使用FQDNs和服务名称，而不是SockAddr、IP地址、协议和端口号。这相当于Java程序员已经存在的类似接口。
Moving to a FQDN-based transport layer might enhance the ability to migrate the IP addresses of endpoints for TCP/UDP without having to interrupt a session, or at least in a way that allows a session to restart gracefully.
迁移到基于FQDN的传输层可能会增强迁移TCP/UDP端点IP地址的能力，而无需中断会话，或者至少以允许会话正常重新启动的方式进行迁移。
Having a single registry per host for all address-based configuration (/etc/hosts, anyone?), with secure access for site network management, might be helpful. Ideally, this would be remotely configurable, for example, leveraging the IETF's current work on networked-device configuration protocols (NetConf). While there are proprietary versions of this approach, sometimes based on Lightweight Directory Access Protocol (LDAP), a fully standardised approach seems desirable.
对于所有基于地址的配置（/etc/hosts，any？），每个主机都有一个注册表，可以安全访问站点网络管理，这可能会有所帮助。理想情况下，这将是远程可配置的，例如，利用IETF目前在网络设备配置协议（NetConf）方面的工作。虽然有这种方法的专有版本，有时基于轻量级目录访问协议（LDAP），但完全标准化的方法似乎是可取的。
Do we really need more than DHCP or SLAAC for regular hosts? Do we need an IPv4 equivalent of SLAAC? How can the use of DHCP FORCERENEW and DHCPv6 RECONFIGURE for bulk renumbering be deployed? FORCERENEW in particular requires DHCP authentication [RFC3118] to be deployed.
我们真的需要比DHCP或SLAAC更多的常规主机吗？我们需要一个与SLAAC相当的IPv4吗？如何使用DHCP FORCERENEW和DHCPv6重新配置以进行批量重新编号？FORCERENEW尤其需要部署DHCP身份验证[RFC3118]。
The IETF should resolve the 'IPv6 ND M/O flag debate' once and for all, with default, mandatory and optional behaviours of hosts being fully specified.
IETF应一劳永逸地解决“IPv6 ND M/O标志争论”，并完全指定主机的默认、强制性和可选行为。
The host behaviour for upstream link learning suggested in Section 2.3 should be documented.
应记录第2.3节中建议的上游链路学习的主机行为。
It would be helpful to have multi-path, survivable, extensions for both UDP and TCP (or institutionalise some aspects of SHIM6).
为UDP和TCP提供多路径、可生存的扩展（或将SHIM6的某些方面制度化）将很有帮助。
A non-proprietary secure mechanism to allow all address-based configuration to be driven by a central repository for site configuration data. NETCONF might be a good starting point.
一种非专有的安全机制，允许所有基于地址的配置由站点配置数据的中央存储库驱动。NETCONF可能是一个很好的起点。
A MANET solution that's solid enough to apply to fully operational small to medium fixed sites for voluntary or involuntary renumbering.
一种MANET解决方案，其坚固性足以应用于完全运行的中小型固定站点，用于自愿或非自愿重新编号。
A MANET-style solution that can be applied convincingly to large or very large sites for voluntary renumbering.
一种MANET风格的解决方案，可以令人信服地应用于大型或非常大型的站点，用于自愿重新编号。
A useful short-term measure would be to ensure that [RFC2894] and [RFC3633] can be used in practice.
一个有用的短期措施是确保[RFC2894]和[RFC3633]可以在实践中使用。
Since address changes are usually communicated via the DNS, the latter's security is essential for secure renumbering. Thus, we should continue existing efforts to deploy DNSsec globally, including not only signing the DNS root, DNS TLDs, and subsidiary DNS zones, but also widely deploying the already available DNSsec-capable DNS resolvers.
由于地址更改通常通过DNS进行通信，因此DNS的安全性对于安全重新编号至关重要。因此，我们应该继续努力在全球范围内部署DNSsec，包括不仅对DNS根、DNS TLD和辅助DNS区域进行签名，而且广泛部署已经可用的支持DNSsec的DNS解析程序。
Similarly, we should document and encourage widespread deployment of Secure Dynamic DNS Update both in DNS servers and also in both client and server operating systems. This capability is already widely implemented and widely available, but it is not widely deployed at present.
同样，我们应该记录并鼓励在DNS服务器以及客户端和服务器操作系统中广泛部署安全的动态DNS更新。这种能力已经得到广泛实施和广泛使用，但目前尚未广泛部署。
Deploy multi-prefix usage of IPv6, including Unique Local Addresses (ULAs) to provide stable internal addresses. In particular, address management tools need to support the multi-prefix model and ULAs.
部署IPv6的多前缀使用，包括唯一本地地址（ULA），以提供稳定的内部地址。特别是，地址管理工具需要支持多前缀模型和ULA。
Ensure that network monitoring systems will function during renumbering, in particular to confirm that renumbering has completed successfully or that some traffic is still using the old prefixes.
确保网络监控系统在重新编号过程中正常工作，特别是确认重新编号已成功完成，或者某些流量仍在使用旧前缀。
Document and encourage systematic site databases and secure configuration protocols for network elements and servers (e.g., NETCONF). The database should store all the information about the network; scripts and tools should derive all configurations from the database. An example of this approach to simplify renumbering is given at [LEROY].
记录并鼓励系统站点数据库和网络元件和服务器的安全配置协议（如NETCONF）。数据库应存储有关网络的所有信息；脚本和工具应该从数据库派生所有配置。[LEROY]中给出了简化重新编号方法的示例。
Document functional requirements for site renumbering tools or toolkits.
记录现场重新编号工具或工具包的功能要求。
Document operational procedures useful for site renumbering.
记录对现场重新编号有用的操作程序。
In general, document renumbering instructions as part of every product manual.
通常，将重新编号说明作为每个产品手册的一部分。
Recommend strongly that all IPv6 deployment plans, for all sizes of site or network, should include provision for future renumbering. Renumbering should be planned from day one when the first lines of the configuration of a network or network service are written. Every IPv6 operator should expect to have to renumber the network one day and should plan for this event.
强烈建议所有规模的站点或网络的所有IPv6部署计划都应包括将来重新编号的规定。重新编号应从写入网络或网络服务配置的第一行开始计划。每个IPv6运营商都应该预计有一天必须重新对网络进行编号，并应为此事件做好计划。
Define a secure mechanism for announcing changes of site prefix to other sites (for example, those that configure routers or VPNs to point to the site in question).
定义一种安全机制，用于向其他站点（例如，那些将路由器或VPN配置为指向相关站点的站点）宣布站点前缀的更改。
For Mobile IP, define a better mechanism to handle change of home agent address while mobile is disconnected.
对于移动IP，定义一种更好的机制，在移动设备断开连接时处理归属代理地址的更改。
Known current issues are discussed in Section 5.3.5. Security issues related to SLAAC are discussed in [RFC3756]. DHCP authentication is defined in [RFC3118].
第5.3.5节讨论了已知的当前问题。[RFC3756]中讨论了与SLAAC相关的安全问题。[RFC3118]中定义了DHCP身份验证。
For future mechanisms to assist and simplify renumbering, care must be taken to ensure that prefix or address changes (especially changes coming from another site or via public sources such as the DNS) are adequately authenticated at all points. Otherwise, misuse of renumbering mechanisms would become an attractive target for those wishing to divert traffic or to cause major disruption. As noted in Section 5.1.4, this may result in defensive techniques such as "DNS pinning", which create difficulty when renumbering.
对于帮助和简化重新编号的未来机制，必须注意确保前缀或地址更改（特别是来自另一个站点或通过DNS等公共来源的更改）在所有点都得到充分验证。否则，对那些希望转移交通或造成重大干扰的人来说，滥用重新编号机制将成为一个有吸引力的目标。如第5.1.4节所述，这可能导致防御技术，如“DNS固定”，这会在重新编号时造成困难。
Whatever authentication method(s) are adopted, key distribution will be an important aspect. Most likely, public key cryptography will be needed to authenticate renumbering announcements passing from one site to another, since one cannot assume a preexisting trust relationship between such sites.
无论采用何种身份验证方法，密钥分发都将是一个重要方面。最有可能的情况是，需要公钥加密来验证从一个站点传递到另一个站点的重新编号公告，因为不能假定这些站点之间存在预先存在的信任关系。
Significant amounts of text have been adapted from [THINK], which reflects work carried out during the 6NET project funded by the Information Society Technologies Programme of the European Commission. The authors of that document have agreed to their text being submitted under the IETF's current copyright provisions. Helpful material about work following on from 6NET was also provided by Olivier Festor of INRIA.
大量文本改编自[THINK]，反映了欧盟委员会信息社会技术计划资助的6NET项目期间开展的工作。该文件的作者已同意根据IETF的现行版权规定提交其文本。INRIA的Olivier Festor还提供了有关6NET后续工作的有用资料。
Useful comments and contributions were made (in alphabetical order) by Jari Arkko, Fred Baker, Olivier Bonaventure, Teco Boot, Stephane Bortzmeyer, Dale Carder, Gert Doering, Ralph Droms, Pasi Eronen, Vijay Gurbani, William Herrin, Cullen Jennings, Eliot Lear, Darrel Lewis, Masataka Ohta, Dan Romascanu, Dave Thaler, Iljitsch van Beijnum, Stig Venaas, Nathan Ward, James Woodyatt, and others.
Jari Arkko、Fred Baker、Olivier Bonaventure、Teco Boot、Stephane Bortzmeyer、Dale Carder、Gert Doering、Ralph Droms、Pasi Eronen、Vijay Gurbani、William Herrin、Cullen Jennings、Eliot Lear、Darrel Lewis、Masataka Ohta、Dan Romascanu、Dave Thaler、Iljitsch van Beijnum、，Stig Venaas、Nathan Ward、James Woodyatt和其他人。
[AUTOC] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network Architecture", Work in Progress, November 2007.
[AUTOC]Chakeres，I.，Macker，J.，和T.Clausen，“移动自组织网络架构”，正在进行的工作，2007年11月。
[AUTOC2] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP address autoconfiguration mechanisms for MANETs", Work in Progress, November 2008.
[AUTOC2]Bernardos，C.，Calderon，M.，和H.Moustafa，“移动自组网IP地址自动配置机制的调查”，正在进行的工作，2008年11月。
[AUTOC3] Bernardos, C., Calderon, M., and H. Moustafa, "Ad-Hoc IP Autoconfiguration Solution Space Analysis", Work in Progress, November 2008.
[AUTOC3]Bernardos，C.，Calderon，M.，和H.Moustafa，“特设IP自动配置解决方案空间分析”，正在进行的工作，2008年11月。
[BRDP] Boot, T. and A. Holtzer, "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Work in Progress, July 2009.
[BRDP]Boot，T.和A.Holtzer，“基于边界路由器发现协议（BRDP）的地址自动配置”，正在进行的工作，2009年7月。
[CPE] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, May 2010.
[CPE]Singh，H.，Beebee，W.，Donley，C.，Stark，B.，和O.Troan，Ed.，“IPv6客户边缘路由器的基本要求”，正在进行的工作，2010年5月。
[CROCKER] Crocker, S., "Renumbering Considered Normal", 2006, <http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF /wednesday/Renumbering_Crocker.pdf>.
[CROCKER]CROCKER，S.，“重新编号视为正常”，2006年<http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF /周三/重新编号\u Crocker.pdf>。
[DHMIFRT] Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces", Work in Progress, March 2009.
[DHMIFT]Sun，T.和H.Deng，“通过DHCPv6选项为具有多个接口的主机进行路由配置”，正在进行的工作，2009年3月。
[DHRTOPT] Dec, W. and R. Johnson, "DHCPv6 Route Option", Work in Progress, March 2010.
[DHRTOPT]Dec，W.和R.Johnson，“DHCPv6路线方案”，正在进行的工作，2010年3月。
[DHSUBNET] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "Subnet Allocation Option", Work in Progress, May 2010.
[DHSUBNET]Johnson，R.，Kumarasamy，J.，Kinnear，K.，和M.Stapp，“子网分配选项”，正在进行的工作，2010年5月。
[DNSBOOK] Albitz, P. and C. Liu, "DNS and BIND", 5th Edition, O'Reilly, 2006.
[DNSBOOK]Albitz，P.和C.Liu，“DNS和绑定”，第五版，O'Reilly，2006年。
[DNSCONT] Dickinson, J., Morris, S., and R. Arends, "Design for a Nameserver Control Protocol", Work in Protocol, October 2008.
[DNSCONT]Dickinson，J.，Morris，S.，和R.Arends，“名称服务器控制协议的设计”，协议工作，2008年10月。
[DNSSD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, March 2010.
[DNSSD]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，正在进行的工作，2010年3月。
[HANDLEY] Handley, M., Wischik, D., and M. Bagnulo, "Multipath Transport, Resource Pooling, and implications for Routing", 2008, <http://www.ietf.org/proceedings/08jul/ slides/RRG-2.pdf>.
[HANDLEY]HANDLEY，M.，Wischik，D.，和M.Bagnulo，“多路径传输，资源池，以及对路由的影响”，2008年<http://www.ietf.org/proceedings/08jul/ 幻灯片/RRG-2.pdf>。
[IEEE.802-1X] Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control: IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004", December 2009.
[IEEE.802-1X]电气和电子工程师协会，“基于端口的网络访问控制：局域网和城域网的IEEE标准802.1X-2004”，2009年12月。
[IEEE.802-1X-REV] Institute of Electrical and Electronics Engineers, "802.1X-REV - Revision of 802.1X-2004 - Port Based Network Access Control: IEEE Standard for Local and Metropolitan Area Networks", 2009.
[IEEE.802-1X-REV]电气和电子工程师协会，“802.1X-REV-802.1X-2004修订版-基于端口的网络访问控制：局域网和城域网的IEEE标准”，2009年。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2010.
[ILNP]阿特金森，R.，“ILNP作战概念”，正在进行的工作，2010年2月。
[LEROY] Leroy, D. and O. Bonaventure, "Preparing network configurations for IPv6 renumbering", International Journal of Network Management, 2009, <http:// inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf>.
[LEROY]LEROY，D.和O.Bonaventure，“为IPv6重新编号准备网络配置”，《国际网络管理杂志》，2009年，<http://inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf>。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, April 2010.
[LISP]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，正在进行的工作，2010年4月。
[MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, March 2010.
[MDNS]Cheshire，S.和M.Krocmal，“多播DNS”，正在进行的工作，2010年3月。
[NAT66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", Work in Progress, March 2009.
[NAT66]Wasserman，M.和F.Baker，“IPv6到IPv6网络地址转换（NAT66）”，正在进行的工作，2009年3月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RFC1900]Carpenter，B.和Y.Rekhter，“重新编号需要工作”，RFC 1900，1996年2月。
[RFC1916] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser, "Enterprise Renumbering: Experience and Information Solicitation", RFC 1916, February 1996.
[RFC1916]Berkowitz，H.，Ferguson，P.，Leland，W.，和P.Nesser，“企业重新编号：经验和信息征集”，RFC 1916，1996年2月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[RFC2071]Ferguson，P.和H.Berkowitz，“网络重新编号概述：我为什么想要它以及它到底是什么？”，RFC 2071，1997年1月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[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月。
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
[RFC2610]Perkins，C.和E.Guttman，“服务位置协议的DHCP选项”，RFC2610，1999年6月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]克劳福德，M.，“IPv6的路由器重新编号”，RFC 28942000年8月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3059] Guttman, E., "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001.
[RFC3059]Guttman，E.“服务位置协议的属性列表扩展”，RFC3059，2001年2月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[RFC3203]T'Joens，Y.，Hublet，C.，和P.De Schrijver，“DHCP重新配置扩展”，RFC32032001年12月。
[RFC3224] Guttman, E., "Vendor Extensions for Service Location Protocol, Version 2", RFC 3224, January 2002.
[RFC3224]Guttman，E.“服务位置协议的供应商扩展，第2版”，RFC 3224，2002年1月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[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月。
[RFC3421] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Select and Sort Extensions for the Service Location Protocol (SLP)", RFC 3421, November 2002.
[RFC3421]Zhao，W.，Schulzrinne，H.，Guttman，E.，Bisdikian，C.，和W.Jerome，“服务位置协议（SLP）的选择和排序扩展”，RFC 34212002年11月。
[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月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents", RFC 3795, June 2004.
[RFC3795]Sofia，R.和P.Nesser，“当前部署的IETF应用领域标准跟踪和实验文件中IPv4地址的调查”，RFC 37952004年6月。
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
[RFC3832]Zhao，W.，Schulzrinne，H.，Guttman，E.，Bisdikian，C.，和W.Jerome，“通过DNS SRV在服务位置协议（SLP）中进行远程服务发现”，RFC 3832，2004年7月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[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月。
[RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[RFC4076]Chown，T.，Venaas，S.，和A.Vijayabhaskar，“IPv6（DHCPv6）无状态动态主机配置协议的重新编号要求”，RFC 4076，2005年5月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年12月。
[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月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[RFC5059]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“用于协议独立多播（PIM）的引导路由器（BSR）机制”，RFC 5059，2008年1月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年9月。
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072]S.Varada，Haskins，D.和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[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月。
[RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[RFC5558]Templin，F.，“虚拟企业遍历（VET）”，RFC55558，2010年2月。
[SCTPNAT] Xie, Q., Stewart, R., Holdrege, M., and M. Tuexen, "SCTP NAT Traversal Considerations", Work in Progress, November 2007.
[SCTPNAT]Xie，Q.，Stewart，R.，Holdrege，M.，和M.Tuexen，“SCTPNAT穿越注意事项”，正在进行的工作，2007年11月。
[SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[SIX-ONE]Vogt，C.，“SIX/ONE：IPv6路由和寻址解决方案”，正在进行的工作，2009年10月。
[THINK] Chown, T., "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
[THINK]Chown，T.，“重新编号IPv6网络时需要考虑的事情”，进展中的工作，2006年9月。
This Appendix lists common places where IP addresses might be embedded. The list was adapted from [THINK].
本附录列出了可能嵌入IP地址的常见位置。这个名单是根据[思考]改编的。
Provider based prefix(es)
基于提供程序的前缀
Names resolved to IP addresses in firewall at startup time
启动时解析为防火墙中IP地址的名称
IP addresses in remote firewalls allowing access to remote services
允许访问远程服务的远程防火墙中的IP地址
IP-based authentication in remote systems allowing access to online bibliographic resources
远程系统中基于IP的身份验证，允许访问在线书目资源
IP address of both tunnel end points for IPv6 in IPv4 tunnel
IPv4隧道中IPv6的两个隧道端点的IP地址
Hard-coded IP subnet configuration information
硬编码IP子网配置信息
IP addresses for static route targets
静态路由目标的IP地址
Blocked SMTP server IP list (spam sources)
阻止的SMTP服务器IP列表（垃圾邮件源）
Web .htaccess and remote access controls
Web.htaccess和远程访问控制
Apache .Listen. directive on given IP address
阿帕奇，听着。关于给定IP地址的指令
Configured multicast rendezvous point
配置的多播集合点
TCP wrapper files
TCP包装文件
Samba configuration files
Samba配置文件
DNS resolv.conf on Unix
Unix上的DNS resolv.conf
Any network traffic monitoring tool
任何网络流量监控工具
NIS/ypbind via the hosts file
通过主机文件绑定NIS/ypbind
Some interface configurations
一些接口配置
Unix portmap security masks
Unix端口映射安全掩码
NIS security masks
NIS安全面具
PIM-SM Rendezvous Point address on multicast routers
多播路由器上的PIM-SM集合点地址
Authors' Addresses
作者地址
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
Randall Atkinson Extreme Networks PO Box 14129 Suite 100, 3306 East NC Highway 54 Research Triangle Park, NC 27709 USA
美国北卡罗来纳州研究三角公园54号北卡罗来纳州东部公路3306号兰德尔·阿特金森极端网络公司邮政信箱14129 100室
EMail: rja@extremenetworks.com
EMail: rja@extremenetworks.com
Hannu Flinck Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
汉努·弗林克诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
EMail: hannu.flinck@nsn.com
EMail: hannu.flinck@nsn.com