Internet DRAFT - draft-ietf-6renum-static-problem
draft-ietf-6renum-static-problem
6RENUM B. Carpenter
Internet-Draft Univ. of Auckland
Intended status: Informational S. Jiang
Expires: June 27, 2013 Huawei Technologies Co., Ltd
December 24, 2012
Problem Statement for Renumbering IPv6 Hosts with Static Addresses in
Enterprise Networks
draft-ietf-6renum-static-problem-03
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 June 27, 2013.
Copyright Notice
Copyright (c) 2012 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.
Carpenter & Jiang Expires June 27, 2013 [Page 1]
Internet-Draft Renumbering Static Addresses December 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Static Addresses Imply Static Prefixes . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 8
2.9. Management Aspects . . . . . . . . . . . . . . . . . . . . 8
3. Summary of Problem Statement . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Carpenter & Jiang Expires June 27, 2013 [Page 2]
Internet-Draft Renumbering Static Addresses December 2012
1. Introduction
A problem that is frequently mentioned in discussions of renumbering
enterprise networks [RFC5887] [I-D.ietf-6renum-enterprise]
[I-D.ietf-6renum-gap-analysis] is that of statically assigned
addresses. The scope of the present document is to analyse the
problems caused to 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 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.
Carpenter & Jiang Expires June 27, 2013 [Page 3]
Internet-Draft Renumbering Static Addresses December 2012
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.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 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
Carpenter & Jiang Expires June 27, 2013 [Page 4]
Internet-Draft Renumbering Static Addresses December 2012
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) [I-D.cheshire-dnsext-multicastdns] in
combination with DNS Service Discovery [I-D.cheshire-dnsext-dns-sd].
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
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).
DNS aspects of renumbering are discussed in more detail in
[I-D.ietf-6renum-enterprise]. Here, we note that one reason for
widespread use of static server addresses is the lack of deployment
Carpenter & Jiang Expires June 27, 2013 [Page 5]
Internet-Draft Renumbering Static Addresses December 2012
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 time-to-live 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 (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 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.ietf-nvo3-overlay-problem-statement], the placement
and live migration of virtual machines (VMs) in a physical network
requires that their IP addresses are 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
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
Carpenter & Jiang Expires June 27, 2013 [Page 6]
Internet-Draft Renumbering Static Addresses December 2012
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 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
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.
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
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 common practice that some such
addresses will have no corresponding DNS entry. If these addresses
Carpenter & Jiang Expires June 27, 2013 [Page 7]
Internet-Draft Renumbering Static Addresses December 2012
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
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, or the blocking of legitimate traffic, or both. Such
security loopholes may never be detected until they are successfully
exploited.
2.9. Management Aspects
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
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.
Carpenter & Jiang Expires June 27, 2013 [Page 8]
Internet-Draft Renumbering Static Addresses December 2012
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.
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, DHCPv6, DNS, router and
security configuration 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.
Carpenter & Jiang Expires June 27, 2013 [Page 9]
Internet-Draft Renumbering Static Addresses December 2012
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 can be performed
without interrupting any user sessions?
3. Do any software licensing systems require manual intervention?
4. Security Considerations
This document defines no protocol, so does not introduce any new
security exposures. However, security configurations such as ACLs
are affected by the renumbering of static addresses.
5. IANA Considerations
This document requests no action by IANA.
6. Acknowledgements
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.
This document was produced using the xml2rfc tool [RFC2629].
7. Change log [RFC Editor: Please remove]
draft-ietf-6renum-static-problem-03: IETF LC and IESG comments, 2012-
12-24.
draft-ietf-6renum-static-problem-02: WGLC comments, clarified
discussion of SLP and mDNS, expanded discussion of configuration
tool, 2012-09-30.
draft-ietf-6renum-static-problem-01: WG comments, 2012-08-31.
draft-ietf-6renum-static-problem-00: adopted by WG and as milestone,
2012-07-30.
Carpenter & Jiang Expires June 27, 2013 [Page 10]
Internet-Draft Renumbering Static Addresses December 2012
draft-carpenter-6renum-static-problem-02: more feedback from WG,
2012-02-28.
draft-carpenter-6renum-static-problem-01: feedback from WG, new text
on software licensing, 2011-12-06.
draft-carpenter-6renum-static-problem-00: original version,
2011-10-18.
8. Informative References
[I-D.baker-homenet-prefix-assignment]
Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small
Networks", draft-baker-homenet-prefix-assignment-01 (work
in progress), March 2012.
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
[I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-15 (work in progress),
December 2011.
[I-D.ietf-6renum-enterprise]
Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations and
Methods", draft-ietf-6renum-enterprise-05 (work in
progress), December 2012.
[I-D.ietf-6renum-gap-analysis]
Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis",
draft-ietf-6renum-gap-analysis-05 (work in progress),
December 2012.
[I-D.ietf-nvo3-overlay-problem-statement]
Narten, T., Gray, E., Dutt, D., Fang, L., Kreeger, L.,
Napierala, M., and M. Sridharan, "Problem Statement:
Overlays for Network Virtualization",
draft-ietf-nvo3-overlay-problem-statement-01 (work in
progress), October 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
Carpenter & Jiang Expires June 27, 2013 [Page 11]
Internet-Draft Renumbering Static Addresses December 2012
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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
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.
Authors' Addresses
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Carpenter & Jiang Expires June 27, 2013 [Page 12]
Internet-Draft Renumbering Static Addresses December 2012
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Carpenter & Jiang Expires June 27, 2013 [Page 13]
