draft-ietf-v6ops-renumbering-procedure-01.txt   draft-ietf-v6ops-renumbering-procedure-02.txt 
IPv6 Operations Working Group F. Baker IPv6 Operations Working Group F. Baker
Internet-Draft E. Lear Internet-Draft E. Lear
Expires: January 6, 2005 R. Droms Expires: May 20, 2005 R. Droms
Cisco Systems Cisco Systems
July 8, 2004 November 19, 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-01 draft-ietf-v6ops-renumbering-procedure-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at
http://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 January 6, 2005. This Internet-Draft will expire on May 20, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document describes the steps in a procedure that can be used to This document describes a procedure that can be used to renumber a
transition from the use of an existing prefix to a new prefix in a network from one prefix to another. It uses IPv6's intrinsic ability
network. It uses IPv6's intrinsic ability to assign multiple to assign multiple addresses to a network interface to provide
addresses to a network interface to provide continuity of network continuity of network service through a "make-before-break"
service through a "make-before-break" transition, as well as transition, as well as addressing naming and configuration management
addressing naming and configuration management issues. It also uses issues. It also uses other IPv6 features to minimize the effort and
other IPv6 features to minimize the effort and time required to time required to complete the transition from the old prefix to the
complete the transition from the old prefix to the new prefix. 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
1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 5 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 5
2. Detailed review of procedure . . . . . . . . . . . . . . . . . 6 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 6
2.1 Initial condition: stable using the old prefix . . . . . . 6 2.1 Initial condition: stable using the old prefix . . . . . . 6
2.2 Preparation for the renumbering process . . . . . . . . . 6 2.2 Preparation for the renumbering process . . . . . . . . . 6
2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 7 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 7
2.2.2 Mechanisms for address assignment to interfaces . . . 8 2.2.2 Mechanisms for address assignment to interfaces . . . 8
2.3 Configuring network elements for the new prefix . . . . . 8 2.3 Configuring switches and routers for the new prefix . . . 8
2.4 Adding new host addresses . . . . . . . . . . . . . . . . 9 2.4 Adding new host addresses . . . . . . . . . . . . . . . . 9
2.5 Stable use of either prefix . . . . . . . . . . . . . . . 10 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 10
2.6 Transition from use of the old prefix to the new 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.1 Transition of DNS service to the new prefix . . . . . 10
2.6.2 Transition to the use of new addresses . . . . . . . . 10 2.6.2 Transition to the use of new addresses . . . . . . . . 10
2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11
2.8 Final condition: stable using the new prefix . . . . . . . 12 2.8 Final condition: stable using the new prefix . . . . . . . 12
3. How to avoid shooting yourself in the foot . . . . . . . . . . 13 3. How to avoid shooting yourself in the foot . . . . . . . . . . 13
3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13 3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13
3.2 Renumbering network elements . . . . . . . . . . . . . . . 13 3.2 Renumbering switch and router interfaces . . . . . . . . . 13
3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14 3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14
4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15
4.1 Dynamic updates to DNS across administrative domains . . . 15 4.1 Dynamic updates to DNS across administrative domains . . . 15
4.2 Management of the inverse zone . . . . . . . . . . . . . . 15 4.2 Management of the inverse zone . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 47 skipping to change at page 3, line 47
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 systems throughout the network will be
the network will be configured with IPv6 addresses from the link configured with IPv6 addresses from the link prefixes of the new
prefixes of the new prefix, and any addresses from the old prefix in prefix, and any addresses from the old prefix in services like DNS
services like DNS [RFC1034][RFC1035] or configured into network [RFC1034][RFC1035] or configured into switches and routers and
elements and applications will be replaced by the appropriate applications will be replaced by the appropriate addresses from the
addresses from the new prefix. 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.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
customer[RFC3633] 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 [RFC3177], 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
firewall
SLAC: StateLess Address AutoConfiguration [RFC2462] 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 renumbered network. The following list gives some of the places
which may include prefixes or addresses that are affected by which may include prefixes or addresses that are affected by
renumbering, and gives some guidance about how the work required renumbering, and gives some guidance about how the work required
during renumbering might be minimized: during renumbering might be minimized:
Link prefixes assigned to links: Each link in the network must be o 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 o IPv6 addresses assigned to interfaces on switches and routers.
addresses are typically assigned manually, as part of configuring These addresses are typically assigned manually, as part of
network elements. configuring switches and routers.
Routing information propagated by network elements
Link prefixes advertised by network elements [RFC2461] o Routing information propagated by switches and routers
Ingress/egress filters o Link prefixes advertised by switches and routers. [RFC2461]
o Ingress/egress filters.
ACLs and other embedded addresses on network elements o ACLs and other embedded addresses on switches and routers.
IPv6 addresses assigned to interfaces on hosts: Use of StateLess o IPv6 addresses assigned to interfaces on hosts. Use of StateLess
Address Configuration [RFC2462] (SLAC) or DHCP [RFC3315] can Address Configuration [RFC2462] (SLAC) or DHCP [RFC3315] can
mitigate the 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 o DNS entries. New AAAA and PTR records are added and old ones
in several phases to reflect the change of prefix. Caching times removed in several phases to reflect the change of prefix.
are adjusted accordingly during these phases. Caching times are adjusted accordingly during these phases.
IPv6 addresses and other configuration information provided by DHCP o IPv6 addresses and other configuration information provided by
DHCP.
IPv6 addresses embedded in configuration files, applications and o 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
process may require significant effort, which is discussed in more the process may require significant effort, which is discussed in
detail in Section 3. This process must be tailored to the needs more detail in Section 3. This process must be tailored to the
of each network. needs of each network.
1.4 Multihoming Issues 1.4 Multihoming Issues
In addition to the considerations presented, the operational matters In addition to the considerations presented, the operational matters
of multihoming may need to be addressed. Networks are generally of multihoming may need to be addressed. Networks are generally
renumbered for one of three reasons: the network itself is changing renumbered for one of three reasons: the network itself is changing
its addressing policy and must renumber to implement the new policy its addressing policy and must renumber to implement the new policy
(for example, a company has been acquired and is changing addresses (for example, a company has been acquired and is changing addresses
to those used by its new owner), an upstream provider has changed its 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 prefixes and its customers are forced to do so at the same time, or a
skipping to change at page 6, line 45 skipping to change at page 6, line 45
2.2 Preparation for the renumbering process 2.2 Preparation for the renumbering process
The first step is to obtain the new prefix and new reverse zone from The first step is to obtain the new prefix and new reverse zone from
the delegating authority. These delegations are performed using the delegating authority. These delegations are performed using
established procedures, from either an internal or external established procedures, from either an internal or external
delegating authority. delegating authority.
Before any devices are reconfigured as a result of the renumbering Before any devices are reconfigured as a result of the renumbering
event, each link in the network must be assigned a sub-prefix from event, each link in the network must be assigned a sub-prefix from
the new prefix. While this assigned link prefix doesn't explicitly the new prefix. While this assigned link prefix doesn't explicitly
appear in the configuration of any specific network element or host, appear in the configuration of any specific switch, router, or host,
the network administrator performing the renumbering procedure must the network administrator performing the renumbering procedure must
make these link prefix assignments prior to beginning the procedure make these link prefix assignments prior to beginning the procedure
to guide the configuration of network elements, assignment of to guide the configuration of switches and routers, assignment of
addresses to interfaces and modifications to network services such as addresses to interfaces and modifications to network services such as
DNS and DHCP. DNS and DHCP.
Prior to renumbering, various processes will need to be reconfigured Prior to renumbering, various processes will need to be reconfigured
to confirm bindings between names and addresses more frequently. In to confirm bindings between names and addresses more frequently. In
normal operation, DNS name translations and DHCP bindings are often normal operation, DNS name translations and DHCP bindings are often
given relatively long lifetimes to limit server load. In order to 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 transition time from old to new prefix it may be necessary to
reduce the time to live (TTL) associated with DNS records and reduce the time to live (TTL) associated with DNS records and
increase the frequency with which DHCP clients contact the DHCP increase the frequency with which DHCP clients contact the DHCP
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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 extend the lifetimes on assigned addresses. This delay can be
reduced 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) may be
reduced. reduced.
o The DHCP Reconfigure message can be sent from the server to the o The DHCP Reconfigure message may also be sent from the server to
hosts to cause the hosts to contact the server. immediately the hosts to trigger the hosts to immediately contact the server.
2.3 Configuring network elements for the new prefix 2.3 Configuring switches and routers for the new prefix
In this step, network elements and services are prepared for the new In this step, switches and routers and services are prepared for the
prefix but the new prefix is not used for any datagram forwarding. new prefix but the new prefix is not used for any datagram
Throughout this step, the new prefix is added to the network forwarding. Throughout this step, the new prefix is added to the
infrastructure in parallel with (and without interfering with) the network infrastructure in parallel with (and without interfering
old prefix. For example, addresses assigned from the new prefix are with) the old prefix. For example, addresses assigned from the new
configured in addition to any addresses from the old prefix assigned prefix are configured in addition to any addresses from the old
to interfaces on the network elements. Changes to the routing prefix assigned to interfaces on the switches and routers. Changes
infrastructure for the new prefix are added in parallel with the old to the routing infrastructure for the new prefix are added in
prefix so that forwarding for both prefixes operates in parallel. At parallel with the old prefix so that forwarding for both prefixes
the end of this step, the network is still running on the old prefix operates in parallel. At the end of this step, the network is still
but is ready to begin using the new prefix. running on the old 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. Routes for the new link prefixes may be injected by
elements, but the router advertisements should not cause hosts to routing protocols into the routing subsystem, but the router
perform SLAC on the new link prefixes; in particular the "autonomous advertisements should not cause hosts to perform SLAC on the new link
address-configuration" flag [RFC2461] should not be set in the prefixes; in particular the "autonomous address-configuration" flag
advertisements for the new link prefixes. Network elements may have [RFC2461] should not be set in the advertisements for the new link
IPv6 addresses from the new link prefixes assigned to interfaces, prefixes. The reason hosts should not be forming addresses at this
taking care that this assignment does not interfere with the use of point is that routing to the new addresses may not yet be stable.
IPv6 addresses from the old prefix and does not cause the new link
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 [RFC3633] 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
skipping to change at page 9, line 29 skipping to change at page 9, line 27
Develop a mapping from each network and address derived from the Develop a mapping from each network and address derived from the
old prefix to each network and address derived from the new old prefix to each network and address derived from the new
prefix. Tools such as the UNIX "sed" or "perl" utilities are prefix. Tools such as the UNIX "sed" or "perl" utilities are
useful to then find and augment access-lists, route-maps, and the useful to then find and augment access-lists, route-maps, and the
like. like.
A similar approach involves the use of such mechanisms as DHCP A similar approach involves the use of such mechanisms as DHCP
prefix delegation to abstract networks and addresses. prefix delegation to abstract networks and addresses.
Network elements or manually configured hosts that have IPv6 Switches and routers or manually configured hosts that have IPv6
addresses assigned from the new prefix may be used at this point to addresses assigned from the new prefix may be used at this point to
test the network infrastructure. test the network infrastructure.
Advertisement of the prefix outside its network is the last thing to 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 be configured during this phase. One wants to have all of one's
defenses in place before advertising the prefix, if only because the defenses in place before advertising the prefix, if only because the
prefix may come under immediate attack. prefix may come under immediate attack.
At the end of this phase routing, access control, and other network At the end of this phase routing, access control, and other network
services should work interchangeably for both old and new prefixes. services should work interchangeably for both old and new prefixes.
2.4 Adding new host addresses 2.4 Adding new host addresses
Once the network infrastructure for the new prefix are in place and Once the network infrastructure for the new prefix are in place and
tested, IPv6 addresses from the new prefix may be assigned to host tested, IPv6 addresses from the new prefix may be assigned to host
interfaces. These IPv6 addresses may be assigned through SLAC, DHCP, interfaces. These IPv6 addresses may be assigned through SLAC, DHCP,
and manual processes. If SLAC is used in the network, the network and manual processes. If SLAC is used in the network, the switches
elements are configured to indicate that hosts should use SLAC to 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 assign IPv6 addresses from the new prefix. If DHCP is used for IPv6
address assignment, the DHCP service is configured to assign IPv6 address assignment, the DHCP service is configured to assign IPv6
addresses to hosts. addresses to hosts.
Once the new IPv6 addresses have been assigned to the host Once the new IPv6 addresses have been assigned to the host
interfaces, both the forward and reverse maps within DNS should be interfaces, both the forward and reverse maps within DNS should be
updated for the new addresses, either through automated or manual updated for the new addresses, either through automated or manual
means. In particular, some clients may be able to update their means. In particular, some clients may be able to update their
forward maps through DDNS, while automating the update of the reverse forward maps through DDNS, while automating the update of the reverse
zone may be more difficult as discussed in Section 4.2. zone may be more difficult as discussed in Section 4.2.
skipping to change at page 10, line 24 skipping to change at page 10, line 23
addresses configured on each and every infrastructure component addresses configured on each and every infrastructure component
interface (apart from interfaces that use only the link-local interface (apart from interfaces that use only the link-local
address), and two non-link-local addresses are available for the use 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 of any host, one in the old prefix and one in the new. This is a
stable configuration. stable configuration.
2.6 Transition from use of the old prefix to the new prefix 2.6 Transition from use of the old prefix to the new prefix
When the new prefix has been fully integrated into the network When the new prefix has been fully integrated into the network
infrastructure and has been tested for stable operation, hosts and infrastructure and has been tested for stable operation, hosts and
network elements can begin using the new prefix. Once the transition switches and routers can begin using the new prefix. Once the
has completed the old prefix will not be in use in the network. 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 2.6.1 Transition of DNS service to the new prefix
The DNS service is configured to use the new prefix by removing any The DNS service is configured to use the new prefix by removing any
IPv6 addresses from the old prefix from the DNS server configuration. IPv6 addresses from the old prefix from the DNS server configuration.
External references to the DNS servers, such as in the DNS service 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 from which this DNS domain was delegated, are updated to use the IPv6
addresses from the new prefix. addresses from the new prefix.
2.6.2 Transition to the use of new addresses 2.6.2 Transition to the use of new addresses
skipping to change at page 11, line 44 skipping to change at page 11, line 44
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
configuration of the routing system, and from any static configuration of the routing system, and from any static
configurations that depend on it.If any configuration has been configurations that depend on it.If any configuration has been
created based on DNS information, the configuration should be created based on DNS information, the configuration should be
refreshed after the old prefixes have been removed from the DNS. refreshed after the old prefixes have been removed from the DNS.
During this phase the registries are informed that the old prefix is During this phase the old prefix may be reclaimed by the provider or
no longer in use, and addresses within that prefix are removed from A RIR that granted it, and addresses within that prefix are removed
records associated with name servers and the corresponding name DNS.
server configurations.
In addition, DNS reverse maps for the old prefix may be removed from In addition, DNS reverse maps for the old prefix may be removed from
the primary name server and the zone delegation may be removed from the primary name server and the zone delegation may be removed from
the parent zone. Any DNS, DHCP, or SLAC timers that were changed the parent zone. Any DNS, DHCP, or SLAC timers that were changed
should be reset to their original values (most notably the DNS should be reset to their original values (most notably the DNS
forward map TTL). forward map TTL).
2.8 Final condition: stable using the new prefix 2.8 Final condition: stable using the new prefix
This is equivalent to the first state, but using the new prefix. This is equivalent to the first state, but using the new prefix.
skipping to change at page 13, line 18 skipping to change at page 13, line 18
Section 2.7 are in dealing with the configurations of routers and Section 2.7 are in dealing with the configurations of routers and
hosts which are not under the control of the network administrator or hosts which are not under the control of the network administrator or
are manually configured. Examples of such devices include voice over are manually configured. Examples of such devices include voice over
IP (VoIP) telephones with static configuration of boot or name IP (VoIP) telephones with static configuration of boot or name
servers, dedicated devices used in manufacturing that are configured servers, dedicated devices used in manufacturing that are configured
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 Long-lived communications present a problem to any application,
increase responsiveness, and a common short-cut is to use static regardless of whether a network is renumbered. However, such events
configuration of IP addresses rather than DNS translation to obtain test the resilience of the code used to survive disruptions. Many
the same. The downside of such behavior should be apparent; such a existing applications make use of standard POSIX functions such as
poorly designed application cannot even add or replace a server gethostbyname() and getipnodebyname(), both of which use the common
easily, much less change servers or reorganize its address space. "hostent" structure. If the application caches the response or for
The short-cut ultimately becomes expensive to maintain and hard to whatever reason actually records the response on disk, recovery from
change or replace. such events may prove difficult. It should be pointed out that the
above basic functions do not preserve DNS caching semantics. Any
As a result, in view of the possibility that a network may need to be application that requires repeated use of an IP address should either
renumbered in the future, any application: not cache the result or make use of an appropriate function such as
the POSIX res_query().
o should obtain addresses of other systems or services from the DNS,
rather then having those addresses manually configured,
o must obtain a new translation if a new session is opened with the In some cases, applications make use of manually configured IP
same service after the lifetime of the DNS RR expires, addresses. For instance, database servers and web servers are often
configured to LISTEN to a specific TCP port on a specific interface.
Applications should be configured with names that are translated at
startup, and then again when the interface address itself is changed.
o when addresses are configured rather than translated, should In the case of infrastructure applications such as name servers and
provide a convenient programmatic method to reconfigure the route processes, a convenient programmatic method that abstracts
addresses that can be executed using a script or its equivalent. prefixes to a single point would be ideal.
Application designers, equipment vendors, and the Open Source Application designers, equipment vendors, and the Open Source
community should take note. There is an opportunity to serve their community should take note. There is an opportunity to serve their
customers well in this area, and network operators should take note customers well in this area, and network operators should take note
to either develop or purchase appropriate tools. to either develop or purchase appropriate tools.
3.2 Renumbering network elements 3.2 Renumbering switch and router interfaces
The configuration and operation of network elements may be designed The configuration and operation of switches and routers are often
to use static configuration with IP addresses or resolve domain names designed to use static configuration with IP addresses or to resolve
only once and use the resulting IP addresses until the element is domain names only once and use the resulting IP addresses until the
restarted. These static configurations complicate the process of element is restarted. These static configurations complicate the
renumbering, requiring administration of all of the static process of renumbering, requiring administration of all of the static
information and manual configuration during a renumbering event. information and manual configuration during a renumbering event.
Because network elements are usually single-purpose devices, the user Because switches and routers are usually single-purpose devices, the
interface and operating functions (software and hardware) are often user interface and operating functions (software and hardware) are
better integrated than independent services running on a server often better integrated than independent services running on a server
platform. Thus, it is likely that network element vendors can design platform. Thus, it is likely that switch vendors and router vendors
and implement consistent support for renumbering across all of the can design and implement consistent support for renumbering across
functions of network elements. all of the functions of switches and routers.
To better support renumbering, network elements can:
o use domain names for configuration wherever possible, and should
resolve those names using the DNS when the lifetime on the name
expires
o provide uniform support for renumbering in all user interface and
configuration mechanisms, such as replacement of one prefix with
another through a single command
o reconfigure services provided by the network element, such as To better support renumbering, switches and routers should use domain
router advertisements and DHCP, for a new prefix with a single names for configuration wherever appropriate, and should resolve
command those names using the DNS when the lifetime on the name expires.
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
skipping to change at page 17, line 5 skipping to change at page 17, line 5
service names and corresponding addresses are treated in this service names and corresponding addresses are treated in this
procedure as providing the address in the preferred prefix, which is procedure as providing the address in the preferred prefix, which is
either the old or the new prefix but not both. Such DNS names either the old or the new prefix but not both. Such DNS names
provide a means in Section 2.6 to cause systems in the network to provide a means in Section 2.6 to cause systems in the network to
stop using the old prefix to access servers or peers and cause them 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 to start using the new prefix. DNS names used for access control
lists, however, need to go through the same three step procedure used lists, however, need to go through the same three step procedure used
for other access control lists, having the new prefix added to them for other access control lists, having the new prefix added to them
in Section 2.3 and the old prefix removed in Section 2.7. in Section 2.3 and the old prefix removed in Section 2.7.
It should be noted that the use of DNS names in this way is not
universally accepted as a solution to this problem; [RFC3871]
especially notes cases where static IP addresses are preferred over
DNS names, in order to avoid a name lookup when the naming system is
inaccessible or when the result of the lookup may be one of several
interfaces or systems. In such cases, extra care must be taken to
manage renumbering properly.
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.
skipping to change at page 18, line 14 skipping to change at page 18, line 14
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 Bill Fenner, Christian Huitema, Craig on the document came from Bill Fenner, Christian Huitema, Craig
Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand, Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand,
Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas,
Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford, Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford,
Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain. 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 authors that the concept
network renumbering as a normal or frequent procedure is daft. Their of network renumbering as a normal or frequent procedure is daft.
comments, if they result in improved address management practices in Their comments, if they result in improved address management
networks, may be the best contribution this note has to offer. practices in networks, may be the best contribution this note has to
offer.
Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described
the ingress filtering issues. the ingress filtering issues. These made their way separately into
[RFC3704], which should be read and understood by anyone that will
temporarily or permanently create a multihomed network by renumbering
from one provider to another.
7. References 7. References
7.1 Normative References 7.1 Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 19, line 44 skipping to change at page 19, line 44
7.2 Informative References 7.2 Informative References
[Clausewitz] [Clausewitz]
von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, von Clausewitz, C., Howard, M., Paret, P. and D. Brodie,
"On War, Chapter VII, 'Friction in War'", June 1989. "On War, Chapter VII, 'Friction in War'", June 1989.
[I-D.ietf-dnsop-ipv6-dns-issues] [I-D.ietf-dnsop-ipv6-dns-issues]
Durand, A., Ihren, J. and P. Savola, "Operational Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Considerations and Issues with IPv6 DNS",
draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress), draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress),
May 2004. October 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
skipping to change at page 20, line 35 skipping to change at page 20, line 35
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001. Allocations to Sites", RFC 3177, September 2001.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004.
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
 End of changes. 

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