Request for Comments: 4192 Cisco Systems
Updates: 2072 E. Lear
Category: Informational Cisco Systems GmbH
R. Droms
Cisco Systems
September 2005
Procedures for Renumbering an IPv6 Network without a Flag Day
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a procedure that can be used to renumber a
network from one prefix to another. It uses IPv6’s intrinsic ability
to assign multiple addresses to a network interface to provide
continuity of network service through a "make-before-break"
transition, as well as addresses naming and configuration management
issues. It also uses other IPv6 features to minimize the effort and
time required to complete the transition from the old prefix to the
new prefix.
Table of Contents
1. Introduction ....................................................2
1.1. Summary of the Renumbering Procedure .......................3
1.2. Terminology ................................................4
1.3. Summary of What Must Be Changed ............................4
1.4. Multihoming Issues .........................................5
2. Detailed Review of Procedure ....................................5
2.1. Initial Condition: Stable Using the Old Prefix .............6
2.2. Preparation for the Renumbering Process ....................6
2.2.1. Domain Name Service .................................7
2.2.2. Mechanisms for Address Assignment to Interfaces .....7
2.3. Configuring Network Elements for the New Prefix ............8
2.4. Adding New Host Addresses ..................................9
2.5. Stable Use of Either Prefix ...............................10
2.6. Transition from Use of the Old Prefix to the New Prefix ...10
2.6.1. Transition of DNS Service to the New Prefix ........10
2.6.2. Transition to Use of New Addresses .................10
2.7. Removing the Old Prefix ...................................11
2.8. Final Condition: Stable Using the New Prefix ..............11
3. How to Avoid Shooting Yourself in the Foot .....................12
3.1. Applications Affected by Renumbering ......................12
3.2. Renumbering Switch and Router Interfaces ..................12
3.3. Ingress Filtering .........................................13
3.4. Link Flaps in BGP Routing .................................13
4. Call to Action for the IETF ....................................14
4.1. Dynamic Updates to DNS Across Administrative Domains ......14
4.2. Management of the Reverse Zone ............................14
5. Security Considerations ........................................14
6. Acknowledgements ...............................................16
7. References .....................................................17
7.1. Normative References ......................................17
7.2. Informative References ....................................17
Appendix A. Managing Latency in the DNS ..........................20
1. Introduction
The Prussian military theorist Carl von Clausewitz [Clausewitz]
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 has the futile
expectation that homo ignoramus will behave intelligently.
A "flag day" is a procedure in which the network, or a part of it, is
changed during a planned outage, or suddenly, causing an outage while
the network recovers. Avoiding outages requires the network to be
modified using what in mobility might be called a "make before break"
procedure: the network is enabled to use a new prefix while the old
one is still operational, operation is switched to that prefix, and
then the old one is taken down.
This document addresses the key procedural issues in renumbering an
IPv6 [RFC2460] network without a "flag day". 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, as network environments vary widely and no
one solution fits all. It points out a few of many areas where there
are multiple approaches. This document updates [RFC2072]. This
document also contains recommendations for application design and
network management, which, if taken seriously, may avoid or minimize
the impact of the issues.
1.1. Summary of the Renumbering Procedure
By "renumbering a network", we mean replacing the use of an existing
(or "old") prefix throughout a network with a new prefix. Usually,
both prefixes will be the same length. The procedures described in
this document are, for the most part, equally applicable if the two
prefixes are not the same length. During renumbering, sub-prefixes
(or "link prefixes") from the old prefix, which have been assigned to
links throughout the network, will be replaced by link prefixes from
the new prefix. Interfaces on systems throughout the network will be
configured with IPv6 addresses from the link prefixes of the new
prefix, and any addresses from the old prefix in services like DNS
[RFC1034][RFC1035] or configured into switches and routers and
applications will be replaced by the appropriate addresses from the
new prefix.
The renumbering procedure described in this document can be applied
to part of a network as well as to an organization’s entire network.
In the case of a large organization, it may be advantageous to treat
the network as a collection of smaller networks. Renumbering each of
the smaller networks separately will make the process more
manageable. The process described in this document is generally
applicable to any network, whether it is an entire organization
network or part of a larger network.
1.2. Terminology
DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through
the use of SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG
[RFC2845].
DHCP prefix delegation: An extension to DHCP [RFC3315] to automate
the assignment of a prefix, for example, from an ISP to a customer
[RFC3633].
flag day: A transition that involves a planned service outage.
ingress/egress filters: Filters applied to a router interface
connected to an external organization, such as an ISP, to exclude
traffic with inappropriate IPv6 addresses.
link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
SLAC: StateLess Address AutoConfiguration [RFC2462].
1.3. Summary of What Must Be Changed
Addresses from the old prefix that are affected by renumbering will
appear in a wide variety of places in the components in the
renumbered network. The following list gives some of the places that
may include prefixes or addresses that are affected by renumbering,
and gives some guidance about how the work required during
renumbering might be minimized:
o Link prefixes assigned to links. Each link in the network must be
assigned a link prefix from the new prefix.
o IPv6 addresses assigned to interfaces on switches and routers.
These addresses are typically assigned manually, as part of
configuring switches and routers.
o Routing information propagated by switches and routers.
o Link prefixes advertised by switches and routers [RFC2461].
o Ingress/egress filters.
o ACLs and other embedded addresses on switches and routers.
o IPv6 addresses assigned to interfaces on hosts. Use of StateLess
Address Autoconfiguration (SLAC) [RFC2462] or DHCP [RFC3315] can
mitigate the impact of renumbering the interfaces on hosts.
o DNS entries. New AAAA and PTR records are added and old ones
removed in several phases to reflect the change of prefix.
Caching times are adjusted accordingly during these phases.
o IPv6 addresses and other configuration information provided by
DHCP.
o IPv6 addresses embedded in configuration files, applications, and
elsewhere. Finding everything that must be updated and automating
the process may require significant effort, which is discussed in
more detail in Section 3. This process must be tailored to the
needs of each network.
1.4. Multihoming Issues
In addition to the considerations presented, the operational matters
of multihoming may need to be addressed. Networks are generally
renumbered for one of three reasons: the network itself is changing
its addressing policy and must renumber to implement the new policy
(for example, a company has been acquired and is changing addresses
to those used by its new owner), an upstream provider has changed its
prefixes and its customers are forced to do so at the same time, or a
company is changing providers and must perforce use addresses
assigned by the new provider. The third case is common.
When a company changes providers, it is common to institute an
overlap period, during which it is served by both providers. By
definition, the company is multihomed during such a period. Although
this document is not about multihoming per se, problems can arise as
a result of ingress filtering policies applied by the upstream
provider or one of its upstream providers, so the user of this
document also needs to be cognizant of these issues. This is
discussed in detail, and approaches to dealing with it are described,
in [RFC2827] and [RFC3704].
2. Detailed Review of Procedure
During the renumbering process, the network transitions through eight
states. In the initial state, the network uses just the prefix that
is to be replaced during the renumbering process. At the end of the
process, the old prefix has been entirely replaced by the new prefix,
and the network is using just the new prefix. To avoid a flag day
transition, the new prefix is deployed first and the network reaches
an intermediate state in which either prefix can be used. In this
state, individual hosts can make the transition to using the new
prefix as appropriate to avoid disruption of applications. Once all
of the hosts have made the transition to the new prefix, the network
is reconfigured so that the old prefix is no longer used in the
network.
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 basic principles apply, but
will need to be modified to address the exact situation. This
procedure should be seen as a skeleton of a more detailed procedure
that has been tailored to a specific environment. Put simply, season
to taste.
2.1. Initial Condition: Stable Using the Old Prefix
Initially, the network is using an old prefix in routing, device
interface addresses, filtering, firewalls, and other systems. This
is a stable configuration.
2.2. Preparation for the Renumbering Process
The first step is to obtain the new prefix and new reverse zone from
the delegating authority. These delegations are performed using
established procedures, from either an internal or external
delegating authority.
Before any devices are reconfigured as a result of the renumbering
event, each link in the network must be assigned a sub-prefix from
the new prefix. While this assigned link prefix does not explicitly
appear in the configuration of any specific switch, router, or host,
the network administrator performing the renumbering procedure must
make these link prefix assignments prior to beginning the procedure
to guide the configuration of switches and routers, assignment of
addresses to interfaces, and modifications to network services such
as DNS and DHCP.
Prior to renumbering, various processes will need to be reconfigured
to confirm bindings between names and addresses more frequently. In
normal operation, DNS name translations and DHCP bindings are often
given relatively long lifetimes to limit server load. In order to
reduce transition time from old to new prefix, it may be necessary to
reduce the time to live (TTL) associated with DNS records and
increase the frequency with which DHCP clients contact the DHCP
server. At the same time, a procedure must be developed through
which other configuration parameters will be updated during the
transition period when both prefixes are available.
2.2.1. Domain Name Service
During the renumbering process, the DNS database must be updated to
add information about addresses assigned to interfaces from the new
prefix and to remove addresses assigned to interfaces from the old
prefix. The changes to the DNS must be coordinated with the changes
to the addresses assigned to interfaces.
Changes to the information in the DNS have to propagate from the
server at which the change was made to the resolvers where the
information is used. The speed of this propagation is controlled by
the TTL for DNS records and the frequency of updates from primary to
secondary servers.
The latency in propagating changes in the DNS can be managed through
the TTL assigned to individual DNS records and through the timing of
updates from primary to secondary servers. Appendix A gives an
analysis of the factors controlling the propagation delays in the
DNS.
The suggestions for reducing the delay in the transition to new IPv6
addresses applies when the DNS service can be given prior notice
about a renumbering event. However, the DNS service for a host may
be in a different administrative domain than the network to which the
host is attached. For example, a device from organization A that
roams to a network belonging to organization B, but the device’s DNS
A record is still managed by organization A, where the DNS service
won’t be given advance notice of a renumbering event in organization
B.
One strategy for updating the DNS is to allow each system to manage
its own DNS information through Dynamic DNS (DDNS)
[RFC2136][RFC3007]. Authentication of these DDNS updates is strongly
recommended and can be accomplished through TSIG and SIG(0). Both
TSIG and SIG(0) require configuration and distribution of keys to
hosts and name servers in advance of the renumbering event.
2.2.2. Mechanisms for Address Assignment to Interfaces
IPv6 addresses may be assigned through SLAC, DHCP, and manual
processes. If DHCP is used for IPv6 address assignment, there may be
some delay in the assignment of IPv6 addresses from the new prefix
because hosts using DHCP only contact the server periodically to
extend the lifetimes on assigned addresses. This delay can be
reduced in two ways:
o Prior to the renumbering event, the T1 parameter (which controls
the time at which a host using DHCP contacts the server) may be
reduced.
o The DHCP Reconfigure message may also be sent from the server to
the hosts to trigger the hosts to contact the server immediately.
2.3. Configuring Network Elements for the New Prefix
In this step, switches and routers and services are prepared for the
new prefix but the new prefix is not used for any datagram
forwarding. Throughout this step, the new prefix is added to the
network infrastructure in parallel with (and without interfering
with) the old prefix. For example, addresses assigned from the new
prefix are configured in addition to any addresses from the old
prefix assigned to interfaces on the switches and routers. Changes
to the routing infrastructure for the new prefix are added in
parallel with the old prefix so that forwarding for both prefixes
operates in parallel. At the end of this step, the network is still
running on the old prefix but is ready to begin using the new prefix.
The new prefix is added to the routing infrastructure, firewall
filters, ingress/egress filters, and other forwarding and filtering
functions. Routes for the new link prefixes may be injected by
routing protocols into the routing subsystem, but the router
advertisements should not cause hosts to perform SLAC on the new link
prefixes; in particular the "autonomous address-configuration" flag
[RFC2461] should not be set in the advertisements for the new link
prefixes. The reason hosts should not be forming addresses at this
point is that routing to the new addresses may not yet be stable.
The details of this step will depend on the specific architecture of
the network being renumbered and the capabilities of the components
that make up the network infrastructure. The effort required to
complete this step may be mitigated by the use of DNS, DHCP prefix
delegation [RFC3633], and other automated configuration tools.
While the new prefix is being added, it will of necessity not be
working everywhere in the network, and unless properly protected by
some means such as ingress and egress access lists, the network may
be attacked through the new prefix in those places where it is
operational.
Once the new prefix has been added to the network infrastructure,
access-lists, route-maps, and other network configuration options
that use IP addresses should be checked to ensure that hosts and
services that use the new prefix will behave as they did with the old
one. Name services other than DNS and other services that provide
information that will be affected by renumbering must be updated in
such a way as to avoid responding with stale information. There are
several useful approaches to identify and augment configurations:
o Develop a mapping from each network and address derived from the
old prefix to each network and address derived from the new
prefix. Tools such as the UNIX "sed" or "perl" utilities are
useful to then find and augment access-lists, route-maps, and the
like.
o A similar approach involves the use of such mechanisms as DHCP
prefix delegation to abstract networks and addresses.
Switches and routers or manually configured hosts that have IPv6
addresses assigned from the new prefix may be used at this point to
test the network infrastructure.
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.
At the end of this phase, routing, access control, and other network
services should work interchangeably for both old and new prefixes.
2.4. Adding New Host Addresses
Once the network infrastructure for the new prefix is in place and
tested, IPv6 addresses from the new prefix may be assigned to host
interfaces while the addresses from the old prefix are retained on
those interfaces. The new IPv6 addresses may be assigned through
SLAC, DHCP, and manual processes. If SLAC is used in the network,
the switches and routers are configured to indicate that hosts should
use SLAC to assign IPv6 addresses from the new prefix. If DHCP is
used for IPv6 address assignment, the DHCP service is configured to
assign addresses from both prefixes to hosts. The addresses from the
new prefixes will not be used until they are inserted into the DNS.
Once the new IPv6 addresses have been assigned to the host
interfaces, both the forward and reverse maps within DNS should be
updated for the new addresses, either through automated or manual
means. In particular, some clients may be able to update their
forward maps through DDNS, but automating the update of the reverse
zone may be more difficult as discussed in Section 4.2.
2.5. Stable Use of Either Prefix
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
interface (apart from interfaces that use only the link-local
address), and two non-link-local addresses are available for the use
of any host, one in the old prefix and one in the new. This is a
stable configuration.
2.6. Transition from Use of the Old Prefix to the New Prefix
When the new prefix has been fully integrated into the network
infrastructure and has been tested for stable operation, hosts,
switches, and routers can begin using the new prefix. Once the
transition has completed, the old prefix will not be in use in the
network.
2.6.1. Transition of DNS Service to the New Prefix
The DNS service is configured to use the new prefix by removing any
IPv6 addresses from the old prefix from the DNS server configuration.
External references to the DNS servers, such as in the DNS service
from which this DNS domain was delegated, are updated to use the IPv6
addresses from the new prefix.
2.6.2. Transition to Use of New Addresses
When both prefixes are usable in the network, each host can make the
transition from using the old prefix to the new prefix at a time that
is appropriate for the applications on the host. If the host
transitions are randomized, DNS dynamic update mechanisms can better
scale to accommodate the changes to the DNS.
As services become available through addresses from the new prefix,
references to the hosts providing those services are updated to use
the new prefix. Addresses obtained through DNS will be automatically
updated when the DNS names are resolved. Addresses may also be
obtained through DHCP and will be updated as hosts contact DHCP
servers. Addresses that are otherwise configured must be updated
appropriately.
It may be necessary to provide users with tools or other explicit
procedures to complete the transition from the use of the old prefix
to the new prefix, because some applications and operating system
functions may be configured in ways that do not use DNS at all or
will not use DNS to resolve a domain name to a new address once the
new prefix is available. For example, a device that only uses DNS to
resolve the name of an NTP server when the device is initialized will
not obtain the address from the new prefix for that server at this
point in the renumbering process.
This last point warrants repeating (in a slightly different form).
Applications may cache addressing information in different ways, for
varying lengths of time. They may cache this information in memory,
on a file system, or in a database. Only after careful observation
and consideration of one’s environment should one conclude that a
prefix is no longer in use. For more information on this issue, see
[DNSOP].
The transition of critical services such as DNS, DHCP, NTP [RFC1305],
and important business services should be managed and tested
carefully to avoid service outages. Each host should take reasonable