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
AbstractThis 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. 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. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
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 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 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 Some approaches to virtual server farms require static addressing. 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 Certain software licensing mechanisms are based on IP addresses. o Network elements, such as routers, are usually assigned static addresses, which are also configured into network monitoring and management systems. o Access Control Lists and other security mechanisms are often configured using IP addresses. 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.
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. 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 "10.1.1.10". 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. 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]. 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.
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. 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.
RFC 4192 renumbering procedure, the licenses for the old and new addresses or prefixes would have to overlap. If acceptable to the licensing mechanism, using addresses under an enterprise's ULA prefix for software licensing would avoid this problem. 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.
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. 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. 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. 3. Internal traffic uses a ULA prefix, such that disturbance to such traffic is avoided if the externally used prefix changes. 4. If prefix renumbering is required, the RFC 4192 procedure is followed. Remaining open questions are: 1. Is minor residual loss of extremely long-living transport sessions during renumbering operationally acceptable? 2. Can automatic network element renumbering be performed without interrupting any user sessions? 3. Do any software licensing systems require manual intervention?
[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. [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [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. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 2011. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.