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




This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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.


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.


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.


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.


This document analyses these issues in more detail and presents a problem statement. Where obvious alternatives to static addresses exist, they are mentioned.


2. Analysis
2. 分析
2.1. Static Addresses Imply Static Prefixes
2.1. 静态地址意味着静态前缀

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


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.


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.


2.2. Other Hosts Need Literal Address
2.2. 其他主机需要文本地址

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.


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 "". The process will be significantly more error-prone for 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.


2.3. Static Server Addresses
2.3. 静态服务器地址

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 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.


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.


2.4. Static Virtual Machine Addresses
2.4. 静态虚拟机地址

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.


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.


2.5. Asset Management and Security Tracing
2.5. 资产管理和安全追踪

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.


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.


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.


2.6. Primitive Software Licensing
2.6. 原始软件许可

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.


2.7. Network Elements
2.7. 网络元素

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.


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.


2.8. Access Control Lists
2.8. 访问控制列表

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.


2.9. Management Aspects
2.9. 管理方面

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.


3. Summary of Problem Statement
3. 问题陈述摘要

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.


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.


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.


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.


ACLs configured with static addresses must be updated during renumbering.


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. 是否有任何软件授权系统需要手动干预?

4. Security Considerations
4. 安全考虑

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.


5. Acknowledgements
5. 致谢

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工作组的其他参与者发表了宝贵的评论和贡献。

6. Informative References
6. 资料性引用

[GAP-ANALYSIS] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", Work in Progress, December 2012.


[PREFIX] Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small Networks", Work in Progress, March 2012.


[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.


[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.


[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.


[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


Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China