Problem Statement for Renumbering IPv6 Hosts with Static Addresses
draft-carpenter-6renum-static-problem-00

Abstract

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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 19, 2012.

Copyright Notice

Copyright (c) 2011 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.

Table of Contents

• 1. Introduction
• 2. Analysis
• 2.1. Static Addresses Imply Static Prefixes
• 2.2. Other Hosts Need Literal Address
• 2.3. Static Server Addresses
• 2.4. Static Virtual Machine Addresses
• 2.5. Asset Management and Security Tracing
• 2.6. Primitive Software Licensing
• 2.7. Network Elements
• 3. Summary of Problem Statement
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. Change log [RFC Editor: Please remove]
• 8. References
• Authors' Addresses

1. Introduction

A problem that is frequently mentioned in discussions of renumbering enterprise networks [RFC5887] [I-D.jiang-6renum-enterprise] [I-D.liu-6renum-gap-analysis] is that of statically assigned addresses. 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.

Although static addressing is in general problematic for renumbering, hosts inside an enterprise may have static addresses for a number of operational reasons:

• 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.
• 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 TTL cannot affect connectivity.
• Some approaches to virtual server farms require static addressing.
• 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.
• Certain software licensing mechanisms have existed which are based on IP addresses. [Question: Is this still relevant for IPv6 addresses?]
• Network elements such as routers are usually assigned static addresses, which are also configured into network monitoring and management systems.

This document analyses these issues in more detail and presents a problem statement.

2. Analysis

2.1. Static Addresses Imply Static Prefixes

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 [I-D.baker-homenet-prefix-assignment]. 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

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 long established practice in small IPv4 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. It is also unusual to enable the Service Location Protocol [RFC2608] for the same purpose. In consequence, if the printer is renumbered for any reason, the manual configuration of all users' hosts must be updated.

In the case of IPv6, exactly the same situation would be created by numbering the printer statically under the site's ULA prefix [RFC4193]. 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 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 the configuration data are by no means stored in the network layer.

2.3. Static Server Addresses

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 auto-configuration [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). Also, since a dynamic DNS update [RFC3007] would be required, remote users would attempt to use the wrong address until the DNS time-to-live expired.

Such server addresses can be managed centrally even if they are static, by using DHCPv6 in stateful mode, and by generating both DHCPv6 data and DNS data from a common configuration database. This does normally carry the implication that the database also contains the hardware (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 very likely today to fall back on manual configuration of server addresses as a result.

In the event of renumbering of 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

According to [I-D.narten-nvo3-overlay-problem-statement], "Placement and movement of VMs in a network effectively requires that VM 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 transport session continuity, unless a procedure similar to [RFC4192] is followed.

2.5. Asset Management and Security Tracing

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.

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

TBD if relevant.

2.7. Network Elements

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 infrastructure, 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 also to configure those addresses in the monitoring and management systems. It is quite 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.

3. Summary of Problem Statement

If subnet prefixes are statically assigned, various network elements and the network management system must be informed when they are renumbered. Alternatively, can automatic subnet prefix assignment be performed without interruption to user sessions?

If a printer or similar local server is statically addressed out of a non-ULA prefix, and has no DNS name, prefix renumbering will require configuration changes in all hosts using that server. Most likely, these changes will be manual. 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.

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.

If network elements have static addresses, the network management system and affected client hosts must be informed when they are renumbered. Alternatively, can automatic network element renumbering be performed without interruption to user sessions?

4. Security Considerations

This document defines no protocol, so does not introduce any new security exposures.

5. IANA Considerations

This document requests no action by IANA.

6. Acknowledgements

Valuable comments and contributions were made by ...

This document was produced using the xml2rfc tool [RFC2629].

7. Change log [RFC Editor: Please remove]

draft-carpenter-6renum-static-problem-00: original version, 2011-10-18.

8. References

Authors' Addresses