--- 1/draft-ietf-v6ops-renumbering-procedure-04.txt 2006-02-05 02:08:22.000000000 +0100 +++ 2/draft-ietf-v6ops-renumbering-procedure-05.txt 2006-02-05 02:08:22.000000000 +0100 @@ -1,19 +1,19 @@ IPv6 Operations Working Group F. Baker Internet-Draft E. Lear -Expires: August 12, 2005 R. Droms +Expires: September 9, 2005 R. Droms Cisco Systems - February 8, 2005 + March 8, 2005 Procedures for Renumbering an IPv6 Network without a Flag Day - draft-ietf-v6ops-renumbering-procedure-04 + draft-ietf-v6ops-renumbering-procedure-05 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each 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. @@ -26,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 12, 2005. + This Internet-Draft will expire on September 9, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide @@ -56,21 +56,21 @@ 1.1 Summary of the renumbering procedure . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Summary of what must be changed . . . . . . . . . . . . . 5 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 6 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 7 2.1 Initial condition: stable using the old prefix . . . . . . 7 2.2 Preparation for the renumbering process . . . . . . . . . 7 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 8 2.2.2 Mechanisms for address assignment to interfaces . . . 9 - 2.3 Configuring switches and routers for the new prefix . . . 9 + 2.3 Configuring network elements for the new prefix . . . . . 9 2.4 Adding new host addresses . . . . . . . . . . . . . . . . 10 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 11 2.6 Transition from use of the old prefix to the new prefix . 11 2.6.1 Transition of DNS service to the new prefix . . . . . 11 2.6.2 Transition to the use of new addresses . . . . . . . . 11 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 12 2.8 Final condition: stable using the new prefix . . . . . . . 13 3. How to avoid shooting yourself in the foot . . . . . . . . . . 14 3.1 Applications affected by renumbering . . . . . . . . . . . 14 @@ -338,21 +338,21 @@ extend the lifetimes on assigned addresses. This delay can be reduced in two ways: o Prior to the renumbering event, the T1 parameter (which controls the time at which a host using DHCP contacts the server) may be reduced. o The DHCP Reconfigure message may also be sent from the server to the hosts to trigger the hosts to contact the server immediately. -2.3 Configuring switches and routers for the new prefix +2.3 Configuring network elements for the new prefix In this step, switches and routers and services are prepared for the new prefix but the new prefix is not used for any datagram forwarding. Throughout this step, the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix. For example, addresses assigned from the new prefix are configured in addition to any addresses from the old prefix assigned to interfaces on the switches and routers. Changes to the routing infrastructure for the new prefix are added in parallel with the old prefix so that forwarding for both prefixes @@ -408,26 +408,28 @@ defenses in place before advertising the prefix, if only because the prefix may come under immediate attack. At the end of this phase routing, access control, and other network services should work interchangeably for both old and new prefixes. 2.4 Adding new host addresses Once the network infrastructure for the new prefix are in place and tested, IPv6 addresses from the new prefix may be assigned to host - interfaces. These IPv6 addresses may be assigned through SLAC, DHCP, - and manual processes. If SLAC is used in the network, the switches - and routers are configured to indicate that hosts should use SLAC to - assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 - address assignment, the DHCP service is configured to assign IPv6 - addresses to hosts. + interfaces while the addresses from the old prefix are retained on + those interfaces. The new IPv6 addresses may be assigned through + SLAC, DHCP, and manual processes. If SLAC is used in the network, + the switches and routers are configured to indicate that hosts should + use SLAC to assign IPv6 addresses from the new prefix. If DHCP is + used for IPv6 address assignment, the DHCP service is configured to + assign addresses from both prefixes to hosts. The addresses from the + new prefixes will not be used until they are inserted into the DNS. Once the new IPv6 addresses have been assigned to the host interfaces, both the forward and reverse maps within DNS should be updated for the new addresses, either through automated or manual means. In particular, some clients may be able to update their forward maps through DDNS, while automating the update of the reverse zone may be more difficult as discussed in Section 4.2. 2.5 Stable use of either prefix