draft-ietf-v6ops-renumbering-procedure-00.txt   draft-ietf-v6ops-renumbering-procedure-01.txt 
IPv6 Operations Working Group F. Baker IPv6 Operations Working Group F. Baker
Internet-Draft E. Lear Internet-Draft E. Lear
Expires: August 5, 2004 R. Droms Expires: January 6, 2005 R. Droms
Cisco Systems Cisco Systems
February 5, 2004 July 8, 2004
Procedures for Renumbering an IPv6 Network without a Flag Day Procedures for Renumbering an IPv6 Network without a Flag Day
draft-ietf-v6ops-renumbering-procedure-00 draft-ietf-v6ops-renumbering-procedure-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2004. This Internet-Draft will expire on January 6, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the steps in a procedure that can be used to This document describes the steps in a procedure that can be used to
transition from the use of an existing prefix to a new prefix in a transition from the use of an existing prefix to a new prefix in a
network. It uses IPv6's intrinsic ability to assign multiple network. It uses IPv6's intrinsic ability to assign multiple
addresses to a network interface to provide continuity of network addresses to a network interface to provide continuity of network
service through a "make-before-break" transition, as well as service through a "make-before-break" transition, as well as
addressing naming and configuration management issues. It also uses addressing naming and configuration management issues. It also uses
other IPv6 features to minimize the effort and time required to other IPv6 features to minimize the effort and time required to
complete the transition from the old prefix to the new prefix. complete the transition from the old prefix to the new prefix.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Summary of the renumbering procedure . . . . . . . . . . . . 3 1.1 Summary of the renumbering procedure . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Summary of what must be changed . . . . . . . . . . . . . . 4 1.3 Summary of what must be changed . . . . . . . . . . . . . 4
2. Detailed review of procedure . . . . . . . . . . . . . . . . 5 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 5
2.1 Initial condition: stable using the old prefix . . . . . . . 6
2.2 Preparation for the renumbering process . . . . . . . . . . 6 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 6
2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . . . . 6 2.1 Initial condition: stable using the old prefix . . . . . . 6
2.2.2 Mechanisms for address assignment to interfaces . . . . . . 7 2.2 Preparation for the renumbering process . . . . . . . . . 6
2.3 Configuring network elements for the new prefix . . . . . . 7 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 7
2.4 Adding new host addresses . . . . . . . . . . . . . . . . . 9 2.2.2 Mechanisms for address assignment to interfaces . . . 8
2.5 Stable use of either prefix . . . . . . . . . . . . . . . . 9 2.3 Configuring network elements for the new prefix . . . . . 8
2.6 Transition from use of the old prefix to the new prefix . . 9 2.4 Adding new host addresses . . . . . . . . . . . . . . . . 9
2.6.1 Transition of DNS service to the new prefix . . . . . . . . 10 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 10
2.6.2 Transition to the use of new addresses . . . . . . . . . . . 10 2.6 Transition from use of the old prefix to the new prefix . 10
2.7 Removing the old prefix . . . . . . . . . . . . . . . . . . 11 2.6.1 Transition of DNS service to the new prefix . . . . . 10
2.8 Final condition: stable using the new prefix . . . . . . . . 11 2.6.2 Transition to the use of new addresses . . . . . . . . 10
3. How to avoid shooting yourself in the foot . . . . . . . . . 11 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11
3.1 "Find all the places..." . . . . . . . . . . . . . . . . . . 11 2.8 Final condition: stable using the new prefix . . . . . . . 12
3.2 Renumbering network elements . . . . . . . . . . . . . . . . 12
3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 13 3. How to avoid shooting yourself in the foot . . . . . . . . . . 13
4. Call to Action for the IETF . . . . . . . . . . . . . . . . 13 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13
4.1 Dynamic updates to DNS across administrative domains . . . . 13 3.2 Renumbering network elements . . . . . . . . . . . . . . . 13
4.2 Management of the inverse zone . . . . . . . . . . . . . . . 13 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 4.1 Dynamic updates to DNS across administrative domains . . . 15
Informative References . . . . . . . . . . . . . . . . . . . 16 4.2 Management of the inverse zone . . . . . . . . . . . . . . 15
A. Managing Latency in the DNS . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
The Prussian military theorist Carl von Clausewitz [20] wrote, The Prussian military theorist Carl von Clausewitz [Clausewitz]
"Everything is very simple in war, but the simplest thing is wrote, "Everything is very simple in war, but the simplest thing is
difficult. These difficulties accumulate and produce a friction, difficult. These difficulties accumulate and produce a friction,
which no man can imagine exactly who has not seen war. ... So in war, which no man can imagine exactly who has not seen war. ... So in
through the influence of an "infinity of petty circumstances" which war, through the influence of an "infinity of petty circumstances"
cannot properly be described on paper, things disappoint us and we which cannot properly be described on paper, things disappoint us and
fall short of the mark." Operating a network is aptly compared to 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 conducting a war. The difference is that the opponent has the futile
expectation that homo ignoramus will behave intelligently. expectation that homo ignoramus will behave intelligently.
A "flag day" is a procedure in which the network, or a part of it, is 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 changed during a planned outage, or suddenly, causing an outage while
the network recovers. Avoiding outages requires the network to be the network recovers. Avoiding outages requires the network to be
modified using what in mobility might be called a "make before break" 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 procedure: the network is enabled to use a new prefix while the old
one is still operational, operation is switched to that prefix, and one is still operational, operation is switched to that prefix, and
then the old one is taken down. then the old one is taken down.
This document addresses the key procedural issues in renumbering an This document addresses the key procedural issues in renumbering an
IPv6 [8] network without a "flag day". The procedure is IPv6 [RFC2460] network without a "flag day". The procedure is
straightforward to describe, but operationally can be difficult to straightforward to describe, but operationally can be difficult to
automate or execute due to issues of statically configured network automate or execute due to issues of statically configured network
state, which one might aptly describe as "an infinity of petty state, which one might aptly describe as "an infinity of petty
circumstances". As a result, in certain areas, this procedure is circumstances". As a result, in certain areas, this procedure is
necessarily incomplete, as network environments vary widely and no necessarily incomplete, as network environments vary widely and no
one solution fits all. It points out a few of many areas where there one solution fits all. It points out a few of many areas where there
are multiple approaches. It may be considered an update to RFC 2072 are multiple approaches. It may be considered an update to RFC 2072
[6]. This document also contains recommendations for application [RFC2072]. This document also contains recommendations for
design and network management which, if taken seriously, may avoid or application design and network management which, if taken seriously,
minimize the impact of the issues. may avoid or minimize the impact of the issues.
1.1 Summary of the renumbering procedure 1.1 Summary of the renumbering procedure
By "renumbering a network" we mean replacing the use of an existing By "renumbering a network" we mean replacing the use of an existing
(or "old") prefix throughout a network with a new prefix. Usually, (or "old") prefix throughout a network with a new prefix. Usually,
both prefixes will be the same length. The procedures described in both prefixes will be the same length. The procedures described in
this document are, for the most part, equally applicable if the two this document are, for the most part, equally applicable if the two
prefixes are not the same length. During renumbering, sub-prefixes prefixes are not the same length. During renumbering, sub-prefixes
(or "link prefixes") from the old prefix, which have been assigned to (or "link prefixes") from the old prefix, which have been assigned to
links throughout the network, will be replaced by link prefixes from links throughout the network, will be replaced by link prefixes from
the new prefix. Interfaces on network elements and hosts throughout the new prefix. Interfaces on network elements and hosts throughout
the network will be configured with IPv6 addresses from the link the network will be configured with IPv6 addresses from the link
prefixes of the new prefix, and any addresses from the old prefix in prefixes of the new prefix, and any addresses from the old prefix in
services like DNS [1][2] or configured into network elements and services like DNS [RFC1034][RFC1035] or configured into network
applications will be replaced by the appropriate addresses from the elements and applications will be replaced by the appropriate
new prefix. addresses from the new prefix.
The renumbering procedure described in this document can be applied The renumbering procedure described in this document can be applied
to part of a network as well as an organization's entire network. In to part of a network as well as an organization's entire network. In
the case of a large organization, it may be advantageous to treat the the case of a large organization, it may be advantageous to treat the
network as a collection of smaller networks. Renumbering each of the network as a collection of smaller networks. Renumbering each of the
smaller networks separately will make the process more manageable. smaller networks separately will make the process more manageable.
The process described in this document is generally applicable to any The process described in this document is generally applicable to any
network, whether it is an entire organization network or part of a network, whether it is an entire organization network or part of a
larger network. larger network.
1.2 Terminology 1.2 Terminology
DDNS: Dynamic DNS [7][14]; DDNS updates can be secured through DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through
the use of SIG(0)[11][13] and TSIG [12] the use of SIG(0)[RFC2535][RFC2931] and TSIG [RFC2845]
DHCP prefix delegation: An extension to DHCP [16] to automate the DHCP prefix delegation: An extension to DHCP [RFC3315] to automate
assignment of a prefix; for example from an ISP to a customer[17] the assignment of a prefix; for example from an ISP to a
customer[RFC3633]
flag day: A transition which involves a planned service outage flag day: A transition which involves a planned service outage
ingress/egress filters: Filters applied to a router interface ingress/egress filters: Filters applied to a router interface
connected to an external organization, such as an ISP, to exclude connected to an external organization, such as an ISP, to exclude
traffic with inappropriate IPv6 addresses traffic with inappropriate IPv6 addresses
link prefix: A prefix, usually a /64 [15], assigned to a link link prefix: A prefix, usually a /64 [RFC3177], assigned to a link
Network element: Any network device, such as a router, switch or Network element: Any network device, such as a router, switch or
firewall firewall
SLAC: StateLess Address autoConfiguration [10] SLAC: StateLess Address AutoConfiguration [RFC2462]
1.3 Summary of what must be changed 1.3 Summary of what must be changed
Addresses from the old prefix that are affected by renumbering will Addresses from the old prefix that are affected by renumbering will
appear in a wide variety of places in the components in the appear in a wide variety of places in the components in the
renumbered network. The following list gives some of the places which renumbered network. The following list gives some of the places
may include prefixes or addresses that are affected by renumbering, which may include prefixes or addresses that are affected by
and gives some guidance about how the work required during renumbering, and gives some guidance about how the work required
renumbering might be minimized: during renumbering might be minimized:
Link prefixes assigned to links: Each link in the network must be Link prefixes assigned to links: Each link in the network must be
assigned a link prefix from the new prefix. assigned a link prefix from the new prefix.
IPv6 addresses assigned to interfaces on network elements: These IPv6 addresses assigned to interfaces on network elements: These
addresses are typically assigned manually, as part of configuring addresses are typically assigned manually, as part of configuring
network elements. network elements.
Routing information propagated by network elements Routing information propagated by network elements
Link prefixes advertised by network elements [9] Link prefixes advertised by network elements [RFC2461]
Ingress/egress filters Ingress/egress filters
ACLs and other embedded addresses on network elements ACLs and other embedded addresses on network elements
IPv6 addresses assigned to interfaces on hosts: Use of StateLess IPv6 addresses assigned to interfaces on hosts: Use of StateLess
Address Configuration [10] (SLAC) or DHCP [16] can mitigate the Address Configuration [RFC2462] (SLAC) or DHCP [RFC3315] can
impact of renumbering the interfaces on hosts. mitigate the impact of renumbering the interfaces on hosts.
DNS entries: New AAAA and PTR records are added and old ones removed DNS entries: New AAAA and PTR records are added and old ones removed
in several phases to reflect the change of prefix. Caching times in several phases to reflect the change of prefix. Caching times
are adjusted accordingly during these phases. are adjusted accordingly during these phases.
IPv6 addresses and other configuration information provided by DHCP IPv6 addresses and other configuration information provided by DHCP
IPv6 addresses embedded in configuration files, applications and IPv6 addresses embedded in configuration files, applications and
elsewhere: Finding everything that must be updated and automating the elsewhere: Finding everything that must be updated and automating the
process may require significant effort, which is discussed in more process may require significant effort, which is discussed in more
detail in Section 3. This process must be tailored to the needs detail in Section 3. This process must be tailored to the needs
of each network. 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. While
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 need also 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 2. Detailed review of procedure
During the renumbering process, the network transitions through eight During the renumbering process, the network transitions through eight
states. In the initial state, the network uses just the prefix which states. In the initial state, the network uses just the prefix which
is to be replaced during the renumbering process. At the end of the 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, 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 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 transition, the new prefix is deployed first and the network reaches
an intermediate state in which either prefix can be used. In this an intermediate state in which either prefix can be used. In this
state, individual hosts can make the transition to using the new state, individual hosts can make the transition to using the new
skipping to change at page 7, line 22 skipping to change at page 7, line 45
addresses applies when the DNS service can be given prior notice addresses applies when the DNS service can be given prior notice
about a renumbering event. However, the DNS service for a host may about a renumbering event. However, the DNS service for a host may
be in a different administrative domain than the network to which the be in a different administrative domain than the network to which the
host is attached. For example, a device from organization A that host is attached. For example, a device from organization A that
roams to a network belonging to organization B, the device's DNS A roams to a network belonging to organization B, the device's DNS A
record is still managed by organization A, where the DNS service record is still managed by organization A, where the DNS service
won't be given advance notice of a renumbering event in organization won't be given advance notice of a renumbering event in organization
B. B.
One strategy for updating the DNS is to allow each network device to One strategy for updating the DNS is to allow each network device to
manage its own DNS information through Dynamic DNS (DDNS) [7][14]. manage its own DNS information through Dynamic DNS (DDNS)
Authentication of these DDNS updates is strongly recommended, and can [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly
be accomplished through the use of either TSIG, and SIG(0). Both TSIG recommended, and can be accomplished through the use of either TSIG,
and SIG(0) require configuration and distribution of keys to end and SIG(0). Both TSIG and SIG(0) require configuration and
hosts and name servers in advance of the renumbering event. distribution of keys to end hosts and name servers in advance of the
renumbering event.
2.2.2 Mechanisms for address assignment to interfaces 2.2.2 Mechanisms for address assignment to interfaces
IPv6 addresses may be assigned through SLAC, DHCP, and manual IPv6 addresses may be assigned through SLAC, DHCP, and manual
processes. If DHCP is used for IPv6 address assignment, there may be processes. If DHCP is used for IPv6 address assignment, there may be
some delay in the assignment of IPv6 addresses from the new prefix some delay in the assignment of IPv6 addresses from the new prefix
because hosts using DHCP only contact the server periodically to because hosts using DHCP only contact the server periodically to
extend the lifetimes on assigned addresses. This delay can be reduced extend the lifetimes on assigned addresses. This delay can be
in two ways: reduced in two ways:
o Prior to the renumbering event, the T1 parameter (which controls o Prior to the renumbering event, the T1 parameter (which controls
the time at which a host using DHCP contacts the server) can be the time at which a host using DHCP contacts the server) can be
reduced. reduced.
o The DHCP Reconfigure message can be sent from the server to the o The DHCP Reconfigure message can be sent from the server to the
hosts to cause the hosts to contact the server. immediately hosts to cause the hosts to contact the server. immediately
2.3 Configuring network elements for the new prefix 2.3 Configuring network elements for the new prefix
skipping to change at page 8, line 15 skipping to change at page 8, line 40
infrastructure for the new prefix are added in parallel with the old infrastructure for the new prefix are added in parallel with the old
prefix so that forwarding for both prefixes operates in parallel. At 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 the end of this step, the network is still running on the old prefix
but is ready to begin using the new prefix. but is ready to begin using the new prefix.
The new prefix is added to the routing infrastructure, firewall The new prefix is added to the routing infrastructure, firewall
filters, ingress/egress filters and other forwarding and filtering filters, ingress/egress filters and other forwarding and filtering
functions. The new link prefixes may be advertised by the network functions. The new link prefixes may be advertised by the network
elements, but the router advertisements should not cause hosts to elements, but the router advertisements should not cause hosts to
perform SLAC on the new link prefixes; in particular the "autonomous perform SLAC on the new link prefixes; in particular the "autonomous
address-configuration" flag [9] should not be set in the address-configuration" flag [RFC2461] should not be set in the
advertisements for the new link prefixes. Network elements may have advertisements for the new link prefixes. Network elements may have
IPv6 addresses from the new link prefixes assigned to interfaces, IPv6 addresses from the new link prefixes assigned to interfaces,
taking care that this assignment does not interfere with the use of taking care that this assignment does not interfere with the use of
IPv6 addresses from the old prefix and does not cause the new link IPv6 addresses from the old prefix and does not cause the new link
prefix to be advertised to hosts. prefix to be advertised to hosts.
The details of this step will depend on the specific architecture of The details of this step will depend on the specific architecture of
the network being renumbered and the capabilities of the components the network being renumbered and the capabilities of the components
that make up the network infrastructure. The effort required to that make up the network infrastructure. The effort required to
complete this step may be mitigated by the use of DNS, DHCP prefix complete this step may be mitigated by the use of DNS, DHCP prefix
delegation [17] and other automated configuration tools. delegation [RFC3633] and other automated configuration tools.
While the new prefix is being added, it will of necessity not be While the new prefix is being added, it will of necessity not be
working everywhere in the network, and unless properly protected by working everywhere in the network, and unless properly protected by
some means such as ingress and egress access lists, the network may some means such as ingress and egress access lists, the network may
be attacked through the new prefix in those places where it is be attacked through the new prefix in those places where it is
operational. operational.
Once the new prefix has been added to the network infrastructure, Once the new prefix has been added to the network infrastructure,
access-lists, route-maps and other network configuration options that access-lists, route-maps and other network configuration options that
use IP addresses should be checked to ensure that hosts and services use IP addresses should be checked to ensure that hosts and services
skipping to change at page 10, line 45 skipping to change at page 11, line 19
resolve the name of an NTP server when the device is initialized will 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 not obtain the address from the new prefix for that server at this
point in the renumbering process. point in the renumbering process.
This last point warrants repeating (in a slightly different form). This last point warrants repeating (in a slightly different form).
Applications may cache addressing information in different ways, for Applications may cache addressing information in different ways, for
varying lengths of time. They may cache this information in memory, varying lengths of time. They may cache this information in memory,
on a file system, or in a database. Only after careful observation on a file system, or in a database. Only after careful observation
and consideration of one"s environment should one conclude that a and consideration of one"s environment should one conclude that a
prefix is no longer in use. For more information on this issue, prefix is no longer in use. For more information on this issue,
please see [18]. please see [I-D.ietf-dnsop-ipv6-dns-issues].
The transition of critical services, such as DNS, DHCP, NTP [3] and The transition of critical services, such as DNS, DHCP, NTP [RFC1305]
important business services should be managed and tested carefully to and important business services should be managed and tested
avoid service outages. Each host should take reasonable precautions carefully to avoid service outages. Each host should take reasonable
prior to changing to the use of the new prefix to minimize the chance precautions prior to changing to the use of the new prefix to
of broken connections. For example, utilities such as netstat and minimize the chance of broken connections. For example, utilities
network analyzers can be used to determine if any existing such as netstat and network analyzers can be used to determine if any
connections to the host are still using the address from the old existing connections to the host are still using the address from the
prefix for that host. old prefix for that host.
Link prefixes from the old prefix in router advertisements and Link prefixes from the old prefix in router advertisements and
addresses from the old prefix provided through DHCP should have their addresses from the old prefix provided through DHCP should have their
preferred lifetimes set to zero at this point, so that hosts will not preferred lifetimes set to zero at this point, so that hosts will not
use the old prefixes for new communications. use the old prefixes for new communications.
2.7 Removing the old prefix 2.7 Removing the old prefix
Once all sessions are deemed to have completed, there will be no Once all sessions are deemed to have completed, there will be no
dependence on the old prefix. It may be removed from the dependence on the old prefix. It may be removed from the
skipping to change at page 12, line 6 skipping to change at page 13, line 23
with the IP addresses for specific services, the boot servers of with the IP addresses for specific services, the boot servers of
routers and switches, etc. routers and switches, etc.
3.1 "Find all the places..." 3.1 "Find all the places..."
Application designers frequently take short-cuts to save memory or Application designers frequently take short-cuts to save memory or
increase responsiveness, and a common short-cut is to use static increase responsiveness, and a common short-cut is to use static
configuration of IP addresses rather than DNS translation to obtain configuration of IP addresses rather than DNS translation to obtain
the same. The downside of such behavior should be apparent; such a the same. The downside of such behavior should be apparent; such a
poorly designed application cannot even add or replace a server poorly designed application cannot even add or replace a server
easily, much less change servers or reorganize its address space. The easily, much less change servers or reorganize its address space.
short-cut ultimately becomes expensive to maintain and hard to change The short-cut ultimately becomes expensive to maintain and hard to
or replace. change or replace.
As a result, in view of the possibility that a network may need to be As a result, in view of the possibility that a network may need to be
renumbered in the future, any application: renumbered in the future, any application:
o should obtain addresses of other systems or services from the DNS, o should obtain addresses of other systems or services from the DNS,
rather then having those addresses manually configured, rather then having those addresses manually configured,
o must obtain a new translation if a new session is opened with the o must obtain a new translation if a new session is opened with the
same service after the lifetime of the DNS RR expires, same service after the lifetime of the DNS RR expires,
skipping to change at page 13, line 19 skipping to change at page 14, line 35
3.3 Ingress Filtering 3.3 Ingress Filtering
An important consideration in Section 2.3, in the case where the An important consideration in Section 2.3, in the case where the
network being renumbered is connected to an external provider, the network being renumbered is connected to an external provider, the
network's ingress filtering policy and its provider's ingress network's ingress filtering policy and its provider's ingress
filtering policy. Both the network firewall's ingress filter and the filtering policy. Both the network firewall's ingress filter and the
provider's ingress filter on the access link to the network should be provider's ingress filter on the access link to the network should be
configured to prevent attacks that use source address spoofing. configured to prevent attacks that use source address spoofing.
Ingress filtering is considered in detail in "Ingress Filtering for Ingress filtering is considered in detail in "Ingress Filtering for
Multihomed Networks" [19]. Multihomed Networks" [RFC3704].
4. Call to Action for the IETF 4. Call to Action for the IETF
The more automated one can make the renumbering process, the better The more automated one can make the renumbering process, the better
for everyone. Sadly, there are several mechanisms that either have for everyone. Sadly, there are several mechanisms that either have
not been automated, or have not been automated consistently across not been automated, or have not been automated consistently across
platforms. platforms.
4.1 Dynamic updates to DNS across administrative domains 4.1 Dynamic updates to DNS across administrative domains
skipping to change at page 13, line 43 skipping to change at page 15, line 27
update of these addresses, as the updates require both complex trust update of these addresses, as the updates require both complex trust
relationships and automation to verify them. For instance, a reverse relationships and automation to verify them. For instance, a reverse
zone is delegated by an upstream ISP, but there is currently no zone is delegated by an upstream ISP, but there is currently no
mechanism to note additional delegations. mechanism to note additional delegations.
4.2 Management of the inverse zone 4.2 Management of the inverse zone
In networks where hosts obtain IPv6 addresses through SLAC, updates In networks where hosts obtain IPv6 addresses through SLAC, updates
of reverse zone are problematic because of lack of trust relationship of reverse zone are problematic because of lack of trust relationship
between administrative domain owning the prefix and the host between administrative domain owning the prefix and the host
assigning the low 64 bits using SLAC. For example, suppose a host, H, assigning the low 64 bits using SLAC. For example, suppose a host,
from organization A is connected to a network owned by organization H, from organization A is connected to a network owned by
B. When H obtains a new address during a renumbering event through organization B. When H obtains a new address during a renumbering
SLAC, H will need to update its reverse entry in the DNS through a event through SLAC, H will need to update its reverse entry in the
DNS server from B that owns the reverse zone for the new address. For DNS through a DNS server from B that owns the reverse zone for the
H to update its reverse entry, the DNS server from B must accept a new address. For H to update its reverse entry, the DNS server from
DDNS request from H, requiring that an inter-administrative domain B must accept a DDNS request from H, requiring that an
trust relationship exist between H and B. The IETF should develop a inter-administrative domain trust relationship exist between H and B.
BCP recommendation for addressing this problem. The IETF should develop a BCP recommendation for addressing this
problem.
5. Security Considerations 5. Security Considerations
The process of renumbering is straightforward in theory but can be The process of renumbering is straightforward in theory but can be
difficult and dangerous in practice. The threats fall into two broad difficult and dangerous in practice. The threats fall into two broad
categories: those arising from misconfiguration and those which are categories: those arising from misconfiguration and those which are
actual attacks. actual attacks.
Misconfigurations can easily arise if any system in the network Misconfigurations can easily arise if any system in the network
"knows" the old prefix, or an address in it, a priori and is not "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 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 a manner which replaces the old instead of being co-equal to it for a
period of time. Simplistic examples include: period of time. Simplistic examples include:
Neglecting to reconfigure a system that is using the old prefix in Neglecting to reconfigure a system that is using the old prefix in
some static configuration: In this case, when the old prefix is some static configuration: In this case, when the old prefix is
removed from the network, whatever feature was so configured removed from the network, whatever feature was so configured
becomes inoperative - it is not configured for the new prefix, and becomes inoperative - it is not configured for the new prefix, and
the old prefix is irrelevant. the old prefix is irrelevant.
Configuring a system via SSH to its only IPv6 address, and replacing Configuring a system via an IPv6 address, and replacing that old
the old address with the new address: Because the TCP connection used address with a new address: Because the TCP connection is using the
by SSH is using the old, no longer valid IPv6 address, the SSH old and now invalid IPv6 address, the SSH session will be
session will be terminated and you will have to use SSH through terminated and you will have to use SSH through the new address
the new address for additional configuration changes. for additional configuration changes.
Removing the old configuration before supplying the new: In this Removing the old configuration before supplying the new: In this
case, it may be necessary to obtain on-site support or travel to case, it may be necessary to obtain on-site support or travel to
the system and access it via its console. the system and access it via its console.
Clearly, taking the extra time to add the new prefix to the Clearly, taking the extra time to add the new prefix to the
configuration, allow the network to settle, and then remove the old configuration, allow the network to settle, and then remove the old
obviates this class of issue. A special consideration applies when obviates this class of issue. A special consideration applies when
some devices are only occasionally used; the administration must some devices are only occasionally used; the administration must
allow sufficiently long in Section 2.6 to ensure that their allow sufficiently long in Section 2.6 to ensure that their
likelihood of detection is sufficiently high. likelihood of detection is sufficiently high.
A subtle case of this type can result when the DNS is used to A subtle case of this type can result when the DNS is used to
populate access control lists and similar security or QoS populate access control lists and similar security or QoS
configurations. DNS names used to translate between system or service configurations. DNS names used to translate between system or
names and corresponding addresses are treated in this procedure as service names and corresponding addresses are treated in this
providing the address in the preferred prefix, which is either the procedure as providing the address in the preferred prefix, which is
old or the new prefix but not both. Such DNS names provide a means in either the old or the new prefix but not both. Such DNS names
Section 2.6 to cause systems in the network to stop using the old provide a means in Section 2.6 to cause systems in the network to
prefix to access servers or peers and cause them to start using the stop using the old prefix to access servers or peers and cause them
new prefix. DNS names used for access control lists, however, need to to start using the new prefix. DNS names used for access control
go through the same three step procedure used for other access lists, however, need to go through the same three step procedure used
control lists, having the new prefix added to them in Section 2.3 and for other access control lists, having the new prefix added to them
the old prefix removed in Section 2.7. in Section 2.3 and the old prefix removed in Section 2.7.
Attacks are also possible. Suppose, for example, that the new prefix Attacks are also possible. Suppose, for example, that the new prefix
has been presented by a service provider, and the service provider has been presented by a service provider, and the service provider
starts advertising the prefix before the customer network is ready. starts advertising the prefix before the customer network is ready.
The new prefix might be targeted in a distributed denial of service The new prefix might be targeted in a distributed denial of service
attack, or a system might be broken into using an application that attack, or a system might be broken into using an application that
would not cross the firewall using the old prefix, before the would not cross the firewall using the old prefix, before the
network's defenses have been configured. Clearly, one wants to network's defenses have been configured. Clearly, one wants to
configure the defenses first and only then accessibility and routing, configure the defenses first and only then accessibility and routing,
as described in Section 2.3 and Section 3.3. as described in Section 2.3 and Section 3.3.
The SLAC procedure described in [10] renumbers hosts. Dynamic DNS The SLAC procedure described in [RFC2462] renumbers hosts. Dynamic
provides a capability for updating DNS accordingly. Managing DNS provides a capability for updating DNS accordingly. Managing
configuration items apart from those procedures is most obviously configuration items apart from those procedures is most obviously
straightforward if all such configurations are generated from a straightforward if all such configurations are generated from a
central configuration repository or database, or if they can all be central configuration repository or database, or if they can all be
read into a temporary database, changed using appropriate scripts, read into a temporary database, changed using appropriate scripts,
and applied to the appropriate systems. Any place where scripted and applied to the appropriate systems. Any place where scripted
configuration management is not possible or is not used must be configuration management is not possible or is not used must be
tracked and managed manually. Here, there be dragons. tracked and managed manually. Here, there be dragons.
In ingress filtering of a multihomed network, an easy solution to the In ingress filtering of a multihomed network, an easy solution to the
issues raised in Section 3.3 might recommend that ingress filtering issues raised in Section 3.3 might recommend that ingress filtering
skipping to change at page 15, line 42 skipping to change at page 18, line 8
prevent attacks using spoofed source addresses. Another problem prevent attacks using spoofed source addresses. Another problem
becomes from the fact that if ingress filtering is made too difficult becomes from the fact that if ingress filtering is made too difficult
(e.g. by requiring special casing in every ISP doing it), it might (e.g. by requiring special casing in every ISP doing it), it might
not be done at an ISP at all. Therefore, any mechanism depending on not be done at an ISP at all. Therefore, any mechanism depending on
relaxing ingress filtering checks should be dealt with an extreme relaxing ingress filtering checks should be dealt with an extreme
care. care.
6. Acknowledgments 6. Acknowledgments
This document grew out of a discussion on the IETF list. Commentary This document grew out of a discussion on the IETF list. Commentary
on the document came from Scott Bradner, Sean Convery, Roland on the document came from Bill Fenner, Christian Huitema, Craig
Dobbins, Peter Elford, Bill Fenner, Tony Hain, Craig Huegen, Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand,
Christian Huitema, Hans Kruse, Laurent Nicolas, Michel Py, Pekka Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas,
Savola, John Schnizlein, Fred Templin, Michael Thomas, Ole Troan, Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford,
Harald Tveit Alvestrand, Jeff Wells and Dan Wing. Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain.
Some took it on themselves to convince the author that the concept of Some took it on themselves to convince the author that the concept of
network renumbering as a normal or frequent procedure is daft. Their network renumbering as a normal or frequent procedure is daft. Their
comments, if they result in improved address management practices in comments, if they result in improved address management practices in
networks, may be the best contribution this note has to offer. networks, may be the best contribution this note has to offer.
Christian Huitema and Pekka Savola described the ingress filtering Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described
issues. the ingress filtering issues.
Informative References 7. References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 7.1 Normative References
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Mills, D., "Network Time Protocol (Version 3) Specification, [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
Implementation", RFC 1305, March 1992. January 1997.
[4] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1996. (IPv6) Specification", RFC 2460, December 1998.
[5] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
(DNS NOTIFY)", RFC 1996, August 1996. Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[6] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
1997. Autoconfiguration", RFC 2462, December 1998.
[7] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, M. Carney, "Dynamic Host Configuration Protocol for IPv6
April 1997. (DHCPv6)", RFC 3315, July 2003.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Specification", RFC 2460, December 1998. Networks", BCP 84, RFC 3704, March 2004.
[9] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 7.2 Informative References
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[10] Thomson, S. and T. Narten, "IPv6 Stateless Address [Clausewitz]
Autoconfiguration", RFC 2462, December 1998. von Clausewitz, C., Howard, M., Paret, P. and D. Brodie,
"On War, Chapter VII, 'Friction in War'", June 1989.
[11] Eastlake, D., "Domain Name System Security Extensions", RFC [I-D.ietf-dnsop-ipv6-dns-issues]
2535, March 1999. Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS",
draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress),
May 2004.
[12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [RFC1305] Mills, D., "Network Time Protocol (Version 3)
"Secret Key Transaction Authentication for DNS (TSIG)", RFC Specification, Implementation", RFC 1305, March 1992.
2845, May 2000.
[13] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
SIG(0)s)", RFC 2931, September 2000. August 1996.
[14] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Update", RFC 3007, November 2000. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[15] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
3177, September 2001. Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
Carney, "Dynamic Host Configuration Protocol for IPv6 RFC 2535, March 1999.
(DHCPv6)", RFC 3315, July 2003.
[17] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in Defeating Denial of Service Attacks which employ IP Source
progress), October 2003. Address Spoofing", BCP 38, RFC 2827, May 2000.
[18] Durand, A. and J. Ihren, "Operational Considerations and Issues [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-03 (work in Wellington, "Secret Key Transaction Authentication for DNS
progress), December 2003. (TSIG)", RFC 2845, May 2000.
[19] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
Networks", draft-savola-bcp38-multihoming-update-03 (work in SIG(0)s)", RFC 2931, September 2000.
progress), December 2003.
[20] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
War, Chapter VII, 'Friction in War'", June 1989. Update", RFC 3007, November 2000.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, CA 93117 Santa Barbara, CA 93117
US US
Phone: 408-526-4257 Phone: 408-526-4257
skipping to change at page 18, line 29 skipping to change at page 22, line 21
calculations: calculations:
o the time it takes for the administrators to make the changes, o the time it takes for the administrators to make the changes,
o the time it may take to wait for the DNS update, if the o the time it may take to wait for the DNS update, if the
secondaries are only updated at regular intervals, and not secondaries are only updated at regular intervals, and not
immediately, and immediately, and
o the time the updating to all the secondaries takes. o the time the updating to all the secondaries takes.
Assume the use of NOTIFY [5] and IXFR [4] to transfer updated Assume the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer
information from the primary DNS server to any secondary servers; updated information from the primary DNS server to any secondary
this is a very quick update process, and the actual time to update of servers; this is a very quick update process, and the actual time to
information is not considered significant. update of information is not considered significant.
There's a target time, TC, at which we want to change the contents of There's a target time, TC, at which we want to change the contents of
a DNS RR. The RR is currently configured with TTL == TTLOLD. Any a DNS RR. The RR is currently configured with TTL == TTLOLD. Any
cached references to the RR will expire no more than TTLOLD in the cached references to the RR will expire no more than TTLOLD in the
future. future.
At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured
with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to
push the RR to the secondaries. After the update, responses to push the RR to the secondaries. After the update, responses to
queries for the RR are returned with TTLNEW. There are still some queries for the RR are returned with TTLNEW. There are still some
skipping to change at page 20, line 8 skipping to change at page 24, line 8
hours have passed and only one hour is left, the TTLNEW has hours have passed and only one hour is left, the TTLNEW has
propagated everywhere, and one can change the address record(s). propagated everywhere, and one can change the address record(s).
These are propagated within the hour, after which one can restore TTL These are propagated within the hour, after which one can restore TTL
value to a larger value. This approach minimizes time where it's value to a larger value. This approach minimizes time where it's
uncertain what kind of (address) information is returned from the uncertain what kind of (address) information is returned from the
DNS. DNS.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/