Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6866 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd.
February 2013
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6866 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd.
February 2013
Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
企业网络中使用静态地址重新编号IPv6主机的问题陈述
Abstract
摘要
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.
本文档分析了由于操作原因需要静态地址的企业网络中主机的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/rfc6866.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6866.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Analysis ........................................................3
2.1. Static Addresses Imply Static Prefixes .....................3
2.2. Other Hosts Need Literal Address ...........................4
2.3. Static Server Addresses ....................................5
2.4. Static Virtual Machine Addresses ...........................6
2.5. Asset Management and Security Tracing ......................6
2.6. Primitive Software Licensing ...............................7
2.7. Network Elements ...........................................7
2.8. Access Control Lists .......................................7
2.9. Management Aspects .........................................8
3. Summary of Problem Statement ....................................8
4. Security Considerations .........................................9
5. Acknowledgements ...............................................10
6. Informative References .........................................10
1. Introduction ....................................................2
2. Analysis ........................................................3
2.1. Static Addresses Imply Static Prefixes .....................3
2.2. Other Hosts Need Literal Address ...........................4
2.3. Static Server Addresses ....................................5
2.4. Static Virtual Machine Addresses ...........................6
2.5. Asset Management and Security Tracing ......................6
2.6. Primitive Software Licensing ...............................7
2.7. Network Elements ...........................................7
2.8. Access Control Lists .......................................7
2.9. Management Aspects .........................................8
3. Summary of Problem Statement ....................................8
4. Security Considerations .........................................9
5. Acknowledgements ...............................................10
6. Informative References .........................................10
A problem that is frequently mentioned in discussions of renumbering enterprise networks [RFC5887] [RFC6879] [GAP-ANALYSIS] is that of statically assigned addresses. The scope of the present document is to analyse the problems caused for enterprise networks during renumbering by static addresses and to identify related gaps in existing technology. Some aspects also apply to small office and home networks, but these are not the intended scope of the document.
在对企业网络重新编号的讨论[RFC5887][RFC6879][GAP-ANALYSIS]中经常提到的一个问题是静态分配地址的问题。本文件的范围是分析企业网络在按静态地址重新编号过程中出现的问题，并找出现有技术中的相关差距。一些方面也适用于小型办公室和家庭网络，但这些不是本文档的预期范围。
A static address can be defined as an IP address that is intended by the network manager to remain constant over a long period of time, possibly many years, regardless of system restarts or any other unpredictable events. Static addressing often implies manual address assignment, including manual preparation of configuration scripts. An implication of hosts having static addresses is that subnets must have static prefixes, which also requires analysis.
静态地址可以定义为IP地址，网络管理器希望该IP地址在很长一段时间（可能是多年）内保持不变，而不管系统重新启动或任何其他不可预测的事件。静态寻址通常意味着手动地址分配，包括手动准备配置脚本。主机具有静态地址意味着子网必须具有静态前缀，这也需要分析。
In a sense, the issue of static addresses is a result of history. As discussed in Section 3.2 of [RFC6250], various properties of IP addresses that have long been assumed by programmers and operators are no longer true today, although they were true when almost all addresses were manually assigned. In some cases, the resulting operational difficulties are avoided by static addressing.
从某种意义上说，静态地址问题是历史的产物。如[RFC6250]第3.2节所述，编程人员和操作员长期以来假定的IP地址的各种属性在今天不再成立，尽管在几乎所有地址都是手动分配的情况下，这些属性成立。在某些情况下，通过静态寻址可以避免由此产生的操作困难。
Although static addressing is, in general, problematic for renumbering, hosts inside an enterprise may have static addresses for a number of operational reasons:
虽然静态寻址通常在重新编号时会有问题，但企业内部的主机可能由于一些操作原因而具有静态地址：
o For some reason, other hosts need to be configured with a literal numeric address for the host in question, so its address must be static.
o 出于某种原因，其他主机需要为相关主机配置一个文本数字地址，因此其地址必须是静态的。
o Even if a site has local DNS support and this is normally used to locate servers, some operators wish their servers to have static addresses so that issues of address lifetime and DNS Time to Live (TTL) cannot affect connectivity.
o 即使站点具有本地DNS支持，并且这通常用于定位服务器，一些运营商希望其服务器具有静态地址，以便地址生存期和DNS生存时间（TTL）问题不会影响连接。
o Some approaches to virtual server farms require static addressing.
o 虚拟服务器场的某些方法需要静态寻址。
o On some sites, the network operations staff require hosts to have static addresses for asset management purposes and for address-based backtracking of security incidents.
o 在某些站点上，网络运营人员要求主机具有静态地址，以便进行资产管理和基于地址的安全事件回溯。
o Certain software licensing mechanisms are based on IP addresses.
o 某些软件许可机制基于IP地址。
o Network elements, such as routers, are usually assigned static addresses, which are also configured into network monitoring and management systems.
o 诸如路由器之类的网元通常被分配静态地址，这些地址也被配置到网络监控和管理系统中。
o Access Control Lists and other security mechanisms are often configured using IP addresses.
o 访问控制列表和其他安全机制通常使用IP地址进行配置。
Static addressing is not the same thing as manual addressing. Static addresses may be configured automatically, for example, by stateful DHCPv6. In that case, the database from which the static address is derived may itself have been created automatically in some fashion, or configured manually. If a host's address is configured manually by the host's administrator, it is by definition static.
静态寻址与手动寻址不同。静态地址可以自动配置，例如，通过有状态DHCPv6。在这种情况下，从中派生静态地址的数据库本身可能已经以某种方式自动创建，或者手动配置。如果主机的地址是由主机的管理员手动配置的，则根据定义它是静态的。
This document analyses these issues in more detail and presents a problem statement. Where obvious alternatives to static addresses exist, they are mentioned.
本文档更详细地分析了这些问题，并给出了问题陈述。如果存在静态地址的明显替代方案，则会提到它们。
Host addresses can only be static if subnet prefixes are also static. Static prefixes are such a long-established practice in enterprise networks that it is hard to discern the reason for them. Originally, before DHCP became available, there was simply no alternative. Thus it became accepted practice to assign subnet prefixes manually and build them into static router configurations. Today, the static nature of subnet prefixes has become a diagnostic tool in itself, at
只有在子网前缀也是静态的情况下，主机地址才能是静态的。在企业网络中，静态前缀是一种由来已久的做法，因此很难找出使用它们的原因。最初，在DHCP可用之前，根本没有其他选择。因此，手动分配子网前缀并将其构建到静态路由器配置中已成为公认的做法。如今，子网前缀的静态特性本身至少已成为一种诊断工具
least in the case of IPv4 where prefixes can easily be memorised. If several users sharing a subnet prefix report problems, the fault can readily be localised.
至少在IPv4的情况下，前缀很容易记忆。如果共享子网前缀的多个用户报告问题，则可以很容易地定位故障。
This model is being challenged for the case of unmanaged home IPv6 networks, in which it is possible to assign subnet prefixes automatically, at least in a cold start scenario [PREFIX]. For an enterprise network, the question arises whether automatic subnet prefix assignment can be made using the "without a flag day" approach to renumbering. [RFC4192] specifies that "the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix". Any method for automatic prefix assignment needs to support this.
这种模式在非托管家庭IPv6网络的情况下受到挑战，在这种情况下，至少在冷启动场景中，可以自动分配子网前缀[前缀]。对于企业网络，问题在于是否可以使用“无卖旗日”方法重新编号来自动分配子网前缀。[RFC4192]指定“新前缀与旧前缀并行（且不干扰）添加到网络基础设施”。自动前缀分配的任何方法都需要支持这一点。
This issue commonly arises in small networks without local DNS support, for devices such as printers, that all other hosts need to reach. In this case, not only does the host in question have a static address but that address is also configured in the other hosts. It is a long-established practice in small IPv4 enterprise networks that printers, in particular, are manually assigned a fixed address (typically, an [RFC1918] address) and that users are told to manually configure printer access using that fixed address. For a small network, the work involved in doing this is much less than the work involved in doing it "properly" by setting up DNS service, whether local or hosted by an ISP, to give the printer a name. Also, although the Service Location Protocol (SLP) [RFC2608] is widely available for tasks such as printer discovery, it is not widely used in enterprise networks. In consequence, if the printer is renumbered for any reason, the manual configuration of all users' hosts must be updated in many enterprises.
此问题通常出现在没有本地DNS支持的小型网络中，对于所有其他主机都需要访问的设备（如打印机）。在这种情况下，所讨论的主机不仅具有静态地址，而且该地址也在其他主机中配置。在小型IPv4企业网络中，一种长期存在的做法是手动为打印机分配固定地址（通常为[RFC1918]地址），并告知用户使用该固定地址手动配置打印机访问。对于一个小型网络，这样做所涉及的工作远少于通过设置DNS服务（无论是本地的还是由ISP托管的）来“正确地”为打印机命名所涉及的工作。此外，尽管服务位置协议（SLP）[RFC2608]广泛用于打印机发现等任务，但在企业网络中并未广泛使用。因此，如果出于任何原因对打印机重新编号，许多企业都必须更新所有用户主机的手动配置。
In the case of IPv6, exactly the same situation would be created by numbering the printer statically under the site's Unique Local Address (ULA) prefix [RFC4193]. Although this address would not change if the site's globally routable prefix is changed, internal renumbering for any other reason would be troublesome. Additionally, the disadvantage compared to IPv4 is that an IPv6 address is harder to communicate reliably, compared to something as simple as "10.1.1.10". The process will be significantly more error-prone for IPv6.
在IPv6的情况下，通过在站点的唯一本地地址（ULA）前缀[RFC4193]下对打印机进行静态编号，将产生完全相同的情况。虽然如果站点的全局可路由前缀更改，此地址不会更改，但由于任何其他原因，内部重新编号都会很麻烦。此外，与IPv4相比，IPv6地址的缺点是，与“10.1.1.10”这样简单的东西相比，IPv6地址更难可靠地通信。对于IPv6，该过程将更容易出错。
If such a host is numbered out of a globally routable prefix that is potentially subject to renumbering, then a renumbering event will require a configuration change in all hosts using the device in question, and such configuration data are by no means stored in the network layer.
如果此类主机的编号超出了可能需要重新编号的全局可路由前缀，则重新编号事件将要求使用所述设备的所有主机中的配置更改，并且此类配置数据决不会存储在网络层中。
At least two simple alternatives exist to avoid static numbering of simple devices, such as printers, by giving them local names. One is the use of Multicast DNS (mDNS) [RFC6762] in combination with DNS Service Discovery [RFC6763]. The other is the Service Location Protocol [RFC2608]. Both of these solutions are widely implemented, but seemingly not widely deployed in enterprise networks.
至少存在两种简单的替代方法，通过给简单设备（如打印机）指定本地名称来避免它们的静态编号。一种是将多播DNS（MDN）[RFC6762]与DNS服务发现[RFC6763]结合使用。另一个是服务定位协议[RFC2608]。这两种解决方案都得到了广泛的实施，但在企业网络中似乎没有得到广泛的部署。
On larger sites, it is safe to assume that servers of all kinds, including printers, are identified in user configurations and applications by DNS names. However, it is very widespread operational practice that servers have static IP addresses. If they did not, whenever an address assigned by stateless address autoconfiguration [RFC4862] or DHCPv6 [RFC3315] expired, and if the address actually changed for some extraneous reason, sessions in progress might fail (depending on whether the address deprecation period was long enough).
在较大的站点上，可以安全地假设所有类型的服务器（包括打印机）都是通过DNS名称在用户配置和应用程序中标识的。然而，服务器具有静态IP地址是非常普遍的操作实践。如果没有，则无论何时无状态地址自动配置[RFC4862]或DHCPv6[RFC3315]分配的地址过期，并且如果该地址因某种无关原因实际更改，正在进行的会话可能会失败（取决于地址弃用期是否足够长）。
DNS aspects of renumbering are discussed in more detail in [RFC6879]. Here, we note that one reason for widespread use of static server addresses is the lack of deployment of Secure Dynamic DNS update [RFC3007], or some other method of prompt DNS updates, in enterprise networks. A separate issue is that even with such updates in place, remote users of a server would attempt to use the wrong address until the DNS TTL expired, as discussed in [RFC4192].
[RFC6879]中详细讨论了重新编号的DNS方面。在这里，我们注意到，广泛使用静态服务器地址的一个原因是缺乏在企业网络中部署安全的动态DNS更新[RFC3007]或其他一些提示DNS更新的方法。另一个问题是，即使有这样的更新，服务器的远程用户也会试图使用错误的地址，直到DNS TTL过期，如[RFC4192]中所述。
Server addresses can be managed centrally, even if they are static, by using DHCPv6 in stateful mode to ensure that the same address is always assigned to a given server. Consistency with DNS can be ensured by generating both DHCPv6 data and DNS data from a common configuration database using a suitable configuration tool. This does normally carry the implication that the database also contains the hardware (Media Access Control (MAC)) addresses of the relevant LAN interfaces on the servers, so that the correct IPv6 address can be delivered whenever a server requests an address. Not every operator wishes to maintain such a costly database, however, and some sites are therefore likely today to fall back on manual configuration of server addresses as a result.
通过在有状态模式下使用DHCPv6，可以集中管理服务器地址，即使它们是静态的，以确保始终将相同的地址分配给给定的服务器。通过使用合适的配置工具从公共配置数据库生成DHCPv6数据和DNS数据，可以确保与DNS的一致性。这通常意味着数据库还包含服务器上相关LAN接口的硬件（媒体访问控制（MAC））地址，以便在服务器请求地址时可以提供正确的IPv6地址。然而，并不是每个运营商都希望维护如此昂贵的数据库，因此，今天有些站点可能会因此而依赖于手动配置服务器地址。
In the event of renumbering the prefix covering such servers, the situation should be manageable if there is a common configuration database; the "without a flag day" procedure [RFC4192] could be followed. However, if there is no such database, a manual procedure would have to be adopted.
在对覆盖此类服务器的前缀重新编号的情况下，如果有一个通用配置数据库，情况应该是可管理的；可以遵循“无卖旗日”程序[RFC4192]。但是，如果没有这样的数据库，就必须采用手动程序。
According to [PROBLEM], the placement and live migration of Virtual Machines (VMs) in a physical network requires that their IP addresses be fixed and static. Otherwise, when a VM is migrated to a different physical server, its IP address would change and transport sessions in progress would be lost. In effect, this is a special case of the previous one.
根据[问题]，物理网络中虚拟机（VM）的放置和实时迁移要求其IP地址是固定的和静态的。否则，当VM迁移到不同的物理服务器时，其IP地址将发生更改，正在进行的传输会话将丢失。实际上，这是前一种情况的特例。
If VMs are numbered out of a prefix that is subject to renumbering, there is a direct conflict with application session continuity, unless a procedure similar to [RFC4192] is followed.
如果VM的编号超出了需要重新编号的前缀，则与应用程序会话连续性存在直接冲突，除非遵循类似于[RFC4192]的过程。
There are some large (campus-sized) sites that not only capture the MAC addresses of servers in a configuration system, but also do so for desktop client machines with wired connections that are then given static IP addresses. Such hosts are not normally servers, so the two preceding cases do not apply. One motivation for this approach is straightforward asset management (Who has which computer?, Connected to which cable?). Another, more compelling, reason is security incident handling. If, as occurs with reasonable frequency on any large network, a particular host is found to be generating some form of unwanted traffic, it is urgent to be able to track back from its IP address to its physical location so that an appropriate intervention can be made. A static binding between the MAC address and the IPv6 address might be preferred for this purpose.
有一些大型（校园大小）站点不仅可以捕获配置系统中服务器的MAC地址，还可以捕获具有有线连接的桌面客户端计算机的MAC地址，然后为这些计算机提供静态IP地址。此类主机通常不是服务器，因此前面两种情况不适用。这种方法的一个动机是直接的资产管理（谁有哪台计算机？连接到哪根电缆？）。另一个更令人信服的原因是安全事件处理。如果在任何大型网络上以合理的频率发生，发现某个特定主机正在生成某种形式的不需要的通信量，则迫切需要能够从其IP地址回溯到其物理位置，以便进行适当的干预。为此，MAC地址和IPv6地址之间的静态绑定可能是首选。
Such users will not, in most circumstances, be significantly inconvenienced by prefix renumbering, as long as it follows the [RFC4192] procedure. The address deprecation mechanism would allow for clean termination of current sessions, including those in which their machine was actually operating as a server, e.g., for a peer-to-peer application. The only users who would be seriously affected would be those running extremely long transport sessions that might outlive the address deprecation period.
在大多数情况下，只要遵循[RFC4192]过程，前缀重新编号不会给这些用户带来很大不便。地址弃用机制允许干净地终止当前会话，包括其机器实际作为服务器运行的会话，例如，对于对等应用程序。唯一会受到严重影响的用户是那些运行可能超过地址弃用期的极长传输会话的用户。
Note that such large campus sites generally allocate addresses dynamically to wireless hosts, since (in an IPv4 world) addresses are scarce and allocating static addresses to intermittent users is not acceptable. Also, a wireless user may appear on different subnets at different times, so it cannot be given a single static address. These users will, in most circumstances, only be slightly inconvenienced, if at all, by prefix renumbering.
请注意，这样的大型校园站点通常会将地址动态分配给无线主机，因为（在IPv4世界中）地址很少，并且不允许将静态地址分配给间歇用户。此外，无线用户可能在不同的时间出现在不同的子网上，因此无法为其提供单一的静态地址。在大多数情况下，前缀重新编号只会给这些用户带来些许不便。
Although it has many disadvantages and cannot be recommended as a solution, software licensing based on IP addresses or prefixes is still quite widely used in various forms. It is to be expected that this practice will continue for IPv6. If so, there is no alternative to informing the licensing party of the new address(es) by whatever administrative process is required. In an RFC 4192 renumbering procedure, the licenses for the old and new addresses or prefixes would have to overlap.
尽管它有许多缺点，不能推荐作为解决方案，但基于IP地址或前缀的软件许可仍然以各种形式广泛使用。预计这种做法将继续适用于IPv6。如果是这样，除了通过任何必要的行政程序通知许可方新地址外，别无选择。在RFC 4192重新编号过程中，新旧地址或前缀的许可证必须重叠。
If acceptable to the licensing mechanism, using addresses under an enterprise's ULA prefix for software licensing would avoid this problem.
如果许可机制可以接受，使用企业的ULA前缀下的地址进行软件许可将避免此问题。
Each interface of a router needs an IP address, and so do other network elements, such as firewalls, proxies, and load balancers. Since these are critical infrastructures, they must be monitored and in some cases controlled by a network management system. A conventional approach to this is to assign the necessary IP addresses statically, and to configure those addresses in the monitoring and management systems. It is common practice that some such addresses will have no corresponding DNS entry. If these addresses need to be changed, there will be considerable ramifications. A restart of the network element might be needed, interrupting all user sessions in progress. Simultaneously, the monitoring and management system configurations must be updated, and in the case of a default router, its clients must be informed. To avoid such disruption, network elements must be renumbered according to an [RFC4192] procedure, like any other host.
路由器的每个接口都需要一个IP地址，其他网络元素（如防火墙、代理和负载平衡器）也需要一个IP地址。由于这些是关键的基础设施，因此必须对其进行监控，在某些情况下还必须由网络管理系统进行控制。传统的方法是静态分配必要的IP地址，并在监控和管理系统中配置这些地址。通常情况下，一些这样的地址将没有相应的DNS条目。如果这些地址需要更改，将会产生相当大的影响。可能需要重新启动网元，从而中断所有正在进行的用户会话。同时，必须更新监控和管理系统配置，对于默认路由器，必须通知其客户端。为了避免这种中断，必须按照[RFC4192]程序对网络元素重新编号，就像任何其他主机一样。
There is a school of thought that to minimise renumbering problems for network elements and to keep the simplicity of static addressing for them, network elements should all have static ULA addresses for management and monitoring purposes, regardless of what other global addresses they may have.
有一个学派认为，为了最大限度地减少网络元素的重新编号问题，并保持静态寻址的简单性，网络元素都应该具有用于管理和监控目的的静态ULA地址，而不管它们可能具有哪些其他全局地址。
Access Control Lists (ACLs) and other security mechanisms are often configured using static IP addresses. This may occur in network elements or hosts. If they are not updated promptly during a renumbering event, the result may be the opening of security loopholes, the blocking of legitimate traffic, or both. Such security loopholes may never be detected until they are successfully exploited.
访问控制列表（ACL）和其他安全机制通常使用静态IP地址进行配置。这可能发生在网络元素或主机中。如果在重新编号事件中没有及时更新，其结果可能是打开安全漏洞、阻止合法流量，或者两者兼而有之。这些安全漏洞在被成功利用之前可能永远不会被发现。
As noted in the Introduction, static addressing and manual address configuration are not the same thing. In terms of managing a renumbering event, static addressing derived automatically from a central database, e.g., by stateful DHCPv6, is clearly better than manual configuration by an administrator. This remains true even if the database itself requires manual changes, since, otherwise, an administrator would have to log in to every host concerned, a time-consuming and error-prone task. In cases where static addresses cannot be avoided, they could be assigned automatically from a central database using a suitable protocol, such as stateful DHCPv6. Clearly, the database needs to be supported by a suitable configuration tool, to minimise manual updates and to eliminate manual configuration of individual hosts.
正如引言中所指出的，静态寻址和手动地址配置不是一回事。就管理重新编号事件而言，从中央数据库（例如，通过有状态DHCPv6）自动派生的静态寻址明显优于管理员手动配置。即使数据库本身需要手动更改，这也是正确的，因为否则，管理员将不得不登录到每个相关主机，这是一项耗时且容易出错的任务。在无法避免静态地址的情况下，可以使用合适的协议（如有状态DHCPv6）从中央数据库自动分配静态地址。显然，数据库需要适当的配置工具支持，以最大限度地减少手动更新并消除单个主机的手动配置。
If subnet prefixes are statically assigned, various network elements and the network management system must be updated when they are renumbered. To avoid loss of existing user sessions, the old prefixes need to be removed only after a period of overlap.
如果子网前缀是静态分配的，则重新编号时必须更新各种网络元素和网络管理系统。为了避免丢失现有的用户会话，只有在重叠一段时间后才需要删除旧的前缀。
If a printer or similar local server is statically addressed, and has no DNS or mDNS name and no discovery protocol, renumbering will require configuration changes in all hosts using that server. Most likely, these changes will be manual; therefore, this type of configuration should be avoided except for very small networks. Even if the server is under a ULA prefix, any subnet rearrangement that causes it to be renumbered will have the same effect.
如果打印机或类似的本地服务器是静态寻址的，并且没有DNS或mDNS名称，也没有发现协议，则重新编号将需要在使用该服务器的所有主机中更改配置。最有可能的是，这些更改将是手动的；因此，除了非常小的网络外，应避免这种类型的配置。即使服务器处于ULA前缀下，任何导致其重新编号的子网重新排列也会产生相同的效果。
If a server with a DNS name is statically addressed via a common configuration database that supports both DHCPv6 and DNS, then it can be renumbered "without a flag day" by following RFC 4192. However, if there is no common configuration database, then present technology requires manual intervention. Similar considerations apply to virtual servers with static addresses.
如果使用DNS名称的服务器通过同时支持DHCPv6和DNS的公共配置数据库静态寻址，则可以按照RFC 4192对其重新编号“无标志日”。然而，若并没有公共配置数据库，那个么当前的技术需要人工干预。类似的注意事项也适用于具有静态地址的虚拟服务器。
If client computers, such as desktops, are statically addressed via a common configuration database and stateful DHCPv6, they can also be renumbered "without a flag day." But other statically addressed clients will need manual intervention, so DHCPv6 should be used if possible.
如果客户端计算机（如台式机）通过公共配置数据库和有状态DHCPv6进行静态寻址，也可以将其重新编号为“无国旗日”。但其他静态寻址的客户端将需要手动干预，因此如果可能，应使用DHCPv6。
If address-based software licensing is unavoidable, requiring static addresses, and ULAs cannot be used for this case, an administrative procedure during renumbering seems unavoidable.
如果基于地址的软件许可不可避免，需要静态地址，并且在这种情况下无法使用ULA，则重新编号期间的管理过程似乎不可避免。
If network elements have static addresses, the network management system and affected client hosts must be informed when they are renumbered. Even if a network element is under a ULA prefix, any subnet rearrangement that causes it to be renumbered will have the same effect.
如果网元具有静态地址，则必须在重新编号时通知网络管理系统和受影响的客户端主机。即使网络元素位于ULA前缀下，任何导致其重新编号的子网重新排列也会产生相同的效果。
ACLs configured with static addresses must be updated during renumbering.
在重新编号期间，必须更新配置了静态地址的ACL。
It appears that the majority of the above problems can be largely mitigated if the following measures are taken:
如果采取以下措施，上述大多数问题似乎可以得到很大程度的缓解：
1. The site uses a general configuration management database and an associated tool that manage all prefixes and all DHCPv6, DNS, and router and security configurations in a consistent and integrated way. Even if static addresses are used, they are always configured with this tool, and never manually. Specification of such a tool is out of scope for the present document.
1. 该站点使用通用配置管理数据库和相关工具，以一致和集成的方式管理所有前缀和所有DHCPv6、DNS以及路由器和安全配置。即使使用静态地址，也始终使用此工具对其进行配置，从不手动配置。这种工具的规格超出了本文件的范围。
2. All printers and other local servers are always accessed via a DNS or mDNS name, or via a discovery protocol. User computers are configured only with names for such servers and never with their addresses.
2. 所有打印机和其他本地服务器始终通过DNS或mDNS名称或发现协议进行访问。用户计算机仅配置此类服务器的名称，而从不配置其地址。
3. Internal traffic uses a ULA prefix, such that disturbance to such traffic is avoided if the externally used prefix changes.
3. 内部通信使用ULA前缀，因此，如果外部使用的前缀发生变化，则可以避免对此类通信的干扰。
4. If prefix renumbering is required, the RFC 4192 procedure is followed.
4. 如果需要前缀重新编号，则遵循RFC 4192程序。
Remaining open questions are:
剩下的未决问题是：
1. Is minor residual loss of extremely long-living transport sessions during renumbering operationally acceptable?
1. 在重新编号过程中，极长寿命运输会话的微小剩余损失在操作上是否可以接受？
2. Can automatic network element renumbering be performed without interrupting any user sessions?
2. 是否可以在不中断任何用户会话的情况下执行自动网元重新编号？
3. Do any software licensing systems require manual intervention?
3. 是否有任何软件授权系统需要手动干预？
This document does not define a protocol, so it does not introduce any new security exposures. However, security configurations, such as ACLs, are affected by the renumbering of static addresses.
本文档未定义协议，因此未引入任何新的安全风险。但是，安全配置（如ACL）会受到静态地址重新编号的影响。
Valuable comments and contributions were made by Ran Atkinson, Ralph Droms, Adrian Farrel, Wes George, Brian Haberman, Bing Liu, Pete Resnick, and other participants in the 6renum WG.
Ran Atkinson、Ralph Droms、Adrian Farrel、Wes George、Brian Haberman、Bing Liu、Pete Resnick和6renum工作组的其他参与者发表了宝贵的评论和贡献。
[GAP-ANALYSIS] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", Work in Progress, December 2012.
[差距分析]Liu，B.，Jiang，S.，Carpenter，B.，Venaas，S.，和W.George，“IPv6站点重新编号差距分析”，正在进行的工作，2012年12月。
[PREFIX] Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small Networks", Work in Progress, March 2012.
[前缀]Baker，F.和R.Droms，“小型网络中的IPv6前缀分配”，正在进行的工作，2012年3月。
[PROBLEM] Narten, T., Ed., Gray, E., Ed., Black, D., Dutt, D., Fang, L., Kreeger, L., Napierala, M., and M. Sridharan, "Problem Statement: Overlays for Network Virtualization", Work in Progress, October 2012.
[问题]Narten，T.，Ed.，Gray，E.，Ed.，Black，D.，Dutt，D.，Fang，L.，Kreeger，L.，Napierala，M.，和M.Sridharan，“问题陈述：网络虚拟化覆盖”，正在进行的工作，2012年10月。
[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月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3315] Droms, R., 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月。
[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月。
[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月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]Carpenter，B.，Atkinson，R.，和H.Flinck，“重新编号仍然需要工作”，RFC 5887，2010年5月。
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 2011.
[RFC6250]Thaler，D.“知识产权模型的演变”，RFC6250，2011年5月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 67622013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879]Jiang，S.，Liu，B.和B.Carpenter，“IPv6企业网络重新编号方案、注意事项和方法”，RFC 6879，2013年2月。
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
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
盛江华为技术有限公司中国北京市海淀区北青路156号华为校区Q14，邮编100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com