draft-ietf-v6ops-renumbering-procedure-02.txt   draft-ietf-v6ops-renumbering-procedure-03.txt 
IPv6 Operations Working Group F. Baker IPv6 Operations Working Group F. Baker
Internet-Draft E. Lear Internet-Draft E. Lear
Expires: May 20, 2005 R. Droms Expires: May 23, 2005 R. Droms
Cisco Systems Cisco Systems
November 19, 2004 November 22, 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-02 draft-ietf-v6ops-renumbering-procedure-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 May 20, 2005. This Internet-Draft will expire on May 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document describes a procedure that can be used to renumber a This document describes a procedure that can be used to renumber a
network from one prefix to another. It uses IPv6's intrinsic ability network from one prefix to another. It uses IPv6's intrinsic ability
to assign multiple addresses to a network interface to provide to assign multiple addresses to a network interface to provide
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 switch and router interfaces . . . . . . . . . 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 reverse zone . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 7, line 44 skipping to change at page 7, line 44
The suggestions for reducing the delay in the transition to new IPv6 The suggestions for reducing the delay in the transition to new IPv6
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 system to manage
manage its own DNS information through Dynamic DNS (DDNS) its own DNS information through Dynamic DNS (DDNS)
[RFC2136][RFC3007]. Authentication of these DDNS updates is strongly [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly
recommended, and can be accomplished through the use of either TSIG, recommended, and can be accomplished through TSIG and SIG(0). Both
and SIG(0). Both TSIG and SIG(0) require configuration and TSIG and SIG(0) require configuration and distribution of keys to
distribution of keys to end hosts and name servers in advance of the hosts and name servers in advance of the renumbering event.
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 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) may be the time at which a host using DHCP contacts the server) may be
reduced. reduced.
o The DHCP Reconfigure message may also be sent from the server to o The DHCP Reconfigure message may also be sent from the server to
the hosts to trigger the hosts to immediately contact the server. the hosts to trigger the hosts to contact the server immediately.
2.3 Configuring switches and routers for the new prefix 2.3 Configuring switches and routers for the new prefix
In this step, switches and routers and services are prepared for the In this step, switches and routers and services are prepared for the
new prefix but the new prefix is not used for any datagram new prefix but the new prefix is not used for any datagram
forwarding. Throughout this step, the new prefix is added to the forwarding. Throughout this step, the new prefix is added to the
network infrastructure in parallel with (and without interfering network infrastructure in parallel with (and without interfering
with) the old prefix. For example, addresses assigned from the new with) the old prefix. For example, addresses assigned from the new
prefix are configured in addition to any addresses from the old prefix are configured in addition to any addresses from the old
prefix assigned to interfaces on the switches and routers. Changes prefix assigned to interfaces on the switches and routers. Changes
skipping to change at page 11, line 45 skipping to change at page 11, line 45
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 old prefix may be reclaimed by the provider or During this phase the old prefix may be reclaimed by the provider or
RIR that granted it, and addresses within that prefix are removed Regional Internet Registry that granted it, and addresses within that
DNS. prefix are removed DNS.
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 15, line 22 skipping to change at page 15, line 22
4.1 Dynamic updates to DNS across administrative domains 4.1 Dynamic updates to DNS across administrative domains
The configuration files for a DNS server (such as named.conf) will The configuration files for a DNS server (such as named.conf) will
contain addresses that must be reconfigured manually during a contain addresses that must be reconfigured manually during a
renumbering event. There is currently no easy way to automate the renumbering event. There is currently no easy way to automate the
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 reverse 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, assigning the low 64 bits using SLAC. For example, suppose a host,
H, from organization A is connected to a network owned by H, from organization A is connected to a network owned by
organization B. When H obtains a new address during a renumbering organization B. When H obtains a new address during a renumbering
event through SLAC, H will need to update its reverse entry in the event through SLAC, H will need to update its reverse entry in the
DNS through a DNS server from B that owns the reverse zone for the DNS through a DNS server from B that owns the reverse zone for the
new address. For H to update its reverse entry, the DNS server from new address. For H to update its reverse entry, the DNS server from
 End of changes. 

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