IPv6 Working Group F. Baker
Internet-Draft Cisco Systems
Expires: October 9, 2003 April 10, 2003
Procedures for Renumbering an IPv6 Network without a Flag Day
draft-baker-ipv6-renumber-procedure-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 9, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document addresses the key procedural issues in renumbering an
IPv6 network. In certain areas, it is necessarily incomplete; it
points out those areas, however. It may be considered an update to
RFC 2072. It presumes the use of IPv6 Autoconfiguration as described
in RFC 2894.
Requirements Language
This document is not intended to be a requirements document, but a
starting point for a plan that a network operator might use to
renumber a network. As such, one could argue that requirements
language is inappropriate. However, a few recommendations in
application design or in procedural execution arise, which suggest
Baker Expires October 9, 2003 [Page 1]
Internet-Draft Renumbering IPv6 Networks April 2003
requirements. In those contexts, requirements language is used.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detailed review of procedure . . . . . . . . . . . . . . . . . 5
2.1 Initial condition: stable using the old prefix . . . . . . . . 5
2.2 Adding the new prefix . . . . . . . . . . . . . . . . . . . . 5
2.3 Stable routing both prefixes . . . . . . . . . . . . . . . . . 5
2.4 Shutting down the use of the old prefix . . . . . . . . . . . 6
2.5 Removing the old prefix . . . . . . . . . . . . . . . . . . . 7
2.6 Final condition: stable using the new prefix . . . . . . . . . 7
3. "Find all the places..." . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Baker Expires October 9, 2003 [Page 2]
Internet-Draft Renumbering IPv6 Networks April 2003
1. Introduction
The Prussian military theorist Carl von Clausewitz [13] wrote,
"Everything is very simple in war, but the simplest thing is
difficult. These difficulties accumulate and produce a friction,
which no man can imagine exactly who has not seen war. ... So in war,
through the influence of an infinity of petty circumstances, which
cannot properly be described on paper, things disappoint us, and we
fall short of the mark." Operating a network is aptly compared to
conducting a war. The difference is that the opponent, who would
sometimes appear to be the customer who pays the bills, is the
futility of the expectation that homo ignoramus will behave
intelligently. A monograph on the subject by Hardin [14] calls this
the "Tragedy of the Commons", it results when a shortcut is taken
because of perceived immediate utility to the perpetrator and a lack
of responsibility for the side effects or latent ramifications of the
shortcut.
This document addresses the key procedural issues in renumbering an
IPv6 network. The procedure is straightforward to describe, but
operationally can be difficult to automate or execute due to issues
of statically configured network state, which one might aptly
describe as "an infinity of petty circumstances". As a result, in
certain areas, this procedure is necessarily incomplete; it points
out those areas, however. It may be considered an update to RFC 2072
[6]. For this reason also, this document contains recommendations for
application design and network management which, if taken seriously,
may avoid or minimize the impact of the issues.
RFC 2072 [6] describes the implications of renumbering in an IPv4
network. A number of issues are raised, not the least of which is
that while IPv4 in no sense precludes the configuration of more than
one prefix on an interface in an equal sense, IPv4 equipment usually
does not provide this capability. The net result is that changing a
subnet's prefix calls for a "flag day" - an epochal point in time,
before which one set of realities apply and after which another
disjoint set of realities apply - on the subnet, and changing a
network's base prefix calls for a flag day for the network. IPv6
intentionally calls for and provides the ability to configure
multiple prefixes on the same interface, and provides facilities for
the direct renumbering of those interfaces; as a result, it is
possible to reconfigure an IPv6 network without a flag day. However,
doing so requires planning and serious attention to detail.
The network, during renumbering, progresses through a series of
states which must be carefully considered from a policy perspective
to ensure that they are consistent at all times with the policies of
the administration. The network may be viewed as being in one of six
Baker Expires October 9, 2003 [Page 3]
Internet-Draft Renumbering IPv6 Networks April 2003
phases:
Stable using the old prefix: Initially, of course, the network is
using a prefix for in its routing, for its servers, and for other
systems in its network. This is a stable configuration.
Adding the new prefix: It is necessary to add the new prefix, but
while the new prefix is being added, it will of necessity not be
working everywhere in the network. Routing to various sub-prefixes
will be configured over a period of time varying from minutes to
hours depending on the size of the network and the degree of
automation used in reconfiguration.
Stable routing two prefixes: Once the network has been configured
with the new prefix and has had sufficient time to stabilize, it
becomes a stable platform with two addresses for every device, one
in the old prefix and one in the new. Sessions are opened with the
addresses in the old prefix; the new is idle.
Shutting down the use of the old prefix: DNS [3][4] is changed to
reflect addresses in the new prefix, and any manual address
configuration that used the old prefix must be modified to use the
new prefix.
Removing the old prefix: Once all sessions are deemed to have
completed, there will be no dependence on the old prefix. It may
be removed from the configuration of the system.
Stable using the new prefix: Equivalent to the initial state, but
using the new prefix.
This procedure identifies the considerations involved in taking the
network from phase to phase.
Baker Expires October 9, 2003 [Page 4]
Internet-Draft Renumbering IPv6 Networks April 2003
2. Detailed review of procedure
In this discussion, we assume that an entire prefix is being replaced
with another entire prefix. It may be that only part of a prefix is
being changed, or that more than one prefix is being changed to a
single joined prefix. In such cases, the principles apply, but will
need to be modified to address the exact situation. This procedure
should be seen as a skeleton of the procedure that would in fact be
applied.
2.1 Initial condition: stable using the old prefix
Initially, the network is using a given prefix for in its routing,
for its servers, and for other systems in its network. This is a
stable configuration.
2.2 Adding the new prefix
It is necessary to add the new prefix, but while the new prefix is
being added, it will of necessity not be working everywhere in the
network, and unless properly protected, it can be used to attack the
network in those places where it is operational. Routing to various
sub-prefixes will be configured over a period of time varying from
minutes to hours depending on the size of the network and the degree
of automation used in reconfiguration.
"Adding the new prefix" involves, at minimum, configuring the
relevant routers to use it and letting hosts autoconfigure new
addresses in the new prefix using IPv6 Autoconfiguration [2].
Practically speaking, networks often have other knowledge of
addresses; they show up in route maps, access lists, access control
files and databases on hosts, and so on. The action here is to "find
all the places that the prefix has to be added, and add it."
Note that, to the extent that it is practicable, it is desirable to
use DNS [3][4] as the source of one's addresses, if only because it
consolidates the places needing change.
Advertisement of the prefix outside its network is the last thing to
be configured during this phase. One wants to have all of one's
defenses in place before advertising the prefix, if only because the
prefix may come under immediate attack.
2.3 Stable routing both prefixes
Once the network has been configured with the new prefix and has had
sufficient time to stabilize, it becomes a stable platform with two
addresses configured on each and every infrastructure component
Baker Expires October 9, 2003 [Page 5]
Internet-Draft Renumbering IPv6 Networks April 2003
interface (apart from serial interfaces that use only the link local
address), and two addresses available for the use of any end system,
one in the old prefix and one in the new. However, due to DNS [3][4]
advertisement and history, sessions are opened with the addresses in
the old prefix; the new is idle. This is a stable configuration.
2.4 Shutting down the use of the old prefix
While in this stable routing state, DNS [3][4] is changed to reflect
addresses in the new prefix, and any manual address configuration
that used the old prefix must be modified to use the new prefix. This
may include direct knowledge of addresses in neighboring networks,
justified perhaps by a belief that the Domain Name Service can be
unreliable at times, or in web pages. A key part of this conversion
process is that the routers are instructed to advertise that the new
prefix is preferred in autoconfiguration [2]; end systems may choose
to form a new address only when the router indicates that the new
prefix is preferred.
The reconfiguration capabilities of network devices, to make this
happen, must be well designed in advance; this is the Achilles Heel
of this operation. Ideally, every address in the network that is not
obtained using DNS (initial boot servers, name servers, call
managers, extranet peers, etc) should be reconfigurable via DHCP [7],
periodic configuration download, or another well defined procedure.
Absent this, renumbering the network can become a very expensive
manual process.
All DNS records have a lifetime, and the process of reconfiguration
takes time, so during this phase one must presume that some systems
are opening connections to the old prefix and some to the new. Even
after such information has aged out of the system, those sessions
have a lifetime; the administrator must decide when sufficient
sessions have completed that remaining sessions are unimportant.
Systems which have been statically configured and whose
reconfiguration has been overlooked will also continue using the old
prefix. During a renumbering event, it would be worthwhile to "sniff"
the network in front of key servers, looking for systems which are
still using the old prefix, in order both to determine when such
access has ceased and to identify unchanged systems. This will not
detect passive use (such as in an access list), but will help
identify active use.
Note that, to the extent that it is practicable, it is desirable to
use DNS as the source of one's addresses, if only because it
consolidates the places needing change.
Baker Expires October 9, 2003 [Page 6]
Internet-Draft Renumbering IPv6 Networks April 2003
2.5 Removing the old prefix
Once all sessions are deemed to have completed, there will be no
dependence on the old prefix. It may be removed from the
configuration of the routing system, and from any static
configurations that depend on it.
2.6 Final condition: stable using the new prefix
This is equivalent to the first state, but using the new prefix.
Baker Expires October 9, 2003 [Page 7]
Internet-Draft Renumbering IPv6 Networks April 2003
3. "Find all the places..."
The difficult operational issues in steps two (Section 2.2), four
(Section 2.4), five (Section 2.5) are in dealing with the
configurations of hosts which are not under the control of the
network administrator or are manually configured. Examples of such
devices include VoIP telephones with static configuration of boot or
name servers, scanning devices used by manufacturing partners in
support of "just in time" purchasing, manufacturing, or shipping
activities, the boot servers of routers and switches, and so on.
Application designers frequently take short-cuts to save memory or
increase responsiveness, and a common short-cut is to use static
configuration of IP addresses rather than DNS translation to obtain
the same. The downside of such behavior should be apparent; such a
poorly designed application cannot even add or replace a server
easily, much less change servers or reorganize its address space. The
short-cut ultimately becomes very expensive to maintain and very hard
to replace.
As a result, in view of the possibility that a network may need to be
renumbered in the future, any application and any platform that runs
on an IP stack, whether IPv4 or IPv6:
o SHOULD obtain its addresses from DNS by translating an appropriate
name,
o MUST obtain a new translation if a new session is opened with the
same service after the address lifetime expires,
o when addresses are configured rather than translated, MUST provide
a convenient programmatic method (such as DHCP [7]) to reconfigure
the addresses that can be executed using a script or its
equivalent
Application designers, equipment vendors, and the Open Source
community should take note. There is an opportunity to serve their
customers well in this area, and network operators should take note
to either develop or purchase appropriate tools.
Baker Expires October 9, 2003 [Page 8]
Internet-Draft Renumbering IPv6 Networks April 2003
4. Security Considerations
The process of renumbering is straightforward in theory but can be
difficult and dangerous in practice. The threats fall into two broad
categories: those arising from misconfiguration and those which are
actual attacks.
Misconfigurations can easily arise if any system in the network
"knows" the old prefix, or an address in it, a priori and is not
configured with the new prefix, or if the new prefix is configured in
a manner which replaces the old instead of being co-equal to it for a
period of time. Simplistic examples include
o You forget to reconfigure a system which is using the old prefix
in some static configuration. In this case, when the old prefix is
removed from the network, whatever feature was so configured
becomes inoperative - it is not configured for the new prefix, and
the old prefix is irrelevant.
o You are configuring a system via SSH to its only IPv6 address. You
change that address, simultaneously removing the old configuration
and replacing it with the new. Clearly, the underlying TCP will
now be unable to deliver segments to the system under
configuration, and configuration will not be able to continue
until it is possible to log into the system using its new address.
o Similarly, imagine that one removes the old configuration before
supplying the new. In this case, it may be necessary to obtain
on-site support or travel to the system and access it via its
console.
Clearly, taking the extra time to add the new prefix to the
configuration, allow the network to settle, and then remove the old
obviates this class of issue. A special consideration applies when a
class of devices are only occasionally used and require this
reconfiguration; the administration must allow suficiently long in
step four (Section 2.4) to ensure that their liklihood of detection
is sufficiently high.
A subtle case of this type can result when the DNS is used to
populate access control lists and similar security or QoS
configurations. DNS names used to translate between system or service
names and corresponding addresses are treated in this procedure as
providing the address in the preferred prefix, which is either the
old or the new prefix but not both. Such DNS names provide a means in
step four (Section 2.4) to cause systems in the network to stop using
the old prefix to access servers or peers and cause them to start
using the new prefix. DNS names used for access control lists,
Baker Expires October 9, 2003 [Page 9]
Internet-Draft Renumbering IPv6 Networks April 2003
however, need to go through the same three step procedure used for
other access control lists, having the new prefix added to them in
step two (Section 2.2) and the old prefix removed in step five
(Section 2.5).
Attacks are also possible. Suppose, for example, that the new prefix
has been presented by a service provider, and the service provider
starts advertising the prefix before the customer network is ready.
The new prefix might be targeted in a distributed denial of service
attack, or a system might be broken into using an application that
would not cross the firewall using the old prefix, before the
network's defenses have been configured. Clearly, one wants to
configure the defenses first and only then accessibility and routing.
RFC 2894 [2] partially automates the renumbering of router interfaces
in IPv6 networks, and the autoconfiguration procedure in RFC 2462 [9]
build on that to renumber the hosts. Dynamic DNS [8][10] provides a
capability for updating DNS accordingly. Managing configuration items
apart from those procedures is most obviously straightforward if all
such configurations are generated from a central configuration
repository or database, or if they can all be read into a temporary
database, changed using appropriate scripts, and applied to the
appropriate systems. Any place where scripted configuration
management is not possible or is not used must be tracked and managed
manually. Here, there be dragons.
Baker Expires October 9, 2003 [Page 10]
Internet-Draft Renumbering IPv6 Networks April 2003
5. Acknowledgements
This document grew out of a discussion on the IETF list. Jeroen
Massar, Eliot Lear, and Michel Participated in that discussion.
Commentary on the initial draft came from Craig Huegen, Peter Elford,
Roland Dobbins, Dan Wing, Harald Tveit Alvestrand, Jeff Wells, John
Schnizlein, Laurent Nicolas, Michael Thomas, Ole Troan, Sean Convery,
Tony Hain, and Scott Bradner. Specifically, the first three named
took it on themselves to convince the author that the concept of
network renumbering as a normal or frequent procedure is daft. Their
comments, if they result in improved address management practices in
networks, may be the best contribution this note has to offer.
Baker Expires October 9, 2003 [Page 11]
Internet-Draft Renumbering IPv6 Networks April 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August
2000.
Baker Expires October 9, 2003 [Page 12]
Internet-Draft Renumbering IPv6 Networks April 2003
Informative References
[3] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[5] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
Why would I want it and what is it anyway?", RFC 2071, January
1997.
[6] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
1997.
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[8] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[11] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
November 2002.
[12] Blanchet, M., "A flexible method for managing the assignment of
bites of an IPv6 address block",
draft-ietf-ipngwg-ipaddressassign-02 (work in progress), March
2001.
[13] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On
War, Chapter VII, 'Friction in War'", June 1989.
[14] Hardin, G., "The Tragedy of the Commons", Science
162(1968):1243-1248, June 1989.
Baker Expires October 9, 2003 [Page 13]
Internet-Draft Renumbering IPv6 Networks April 2003
Author's Address
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: 408-526-4257
Fax: 413-473-2403
EMail: fred@cisco.com
Baker Expires October 9, 2003 [Page 14]
Internet-Draft Renumbering IPv6 Networks April 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Baker Expires October 9, 2003 [Page 15]
Internet-Draft Renumbering IPv6 Networks April 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker Expires October 9, 2003 [Page 16]