draft-ietf-v6ops-renumbering-procedure-04.txt | draft-ietf-v6ops-renumbering-procedure-05.txt | |||
---|---|---|---|---|
IPv6 Operations Working Group F. Baker | IPv6 Operations Working Group F. Baker | |||
Internet-Draft E. Lear | Internet-Draft E. Lear | |||
Expires: August 12, 2005 R. Droms | Expires: September 9, 2005 R. Droms | |||
Cisco Systems | Cisco Systems | |||
February 8, 2005 | March 8, 2005 | |||
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-04 | draft-ietf-v6ops-renumbering-procedure-05 | |||
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 37 | skipping to change at page 1, line 37 | |||
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 August 12, 2005. | This Internet-Draft will expire on September 9, 2005. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
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 21 | skipping to change at page 2, line 21 | |||
1.1 Summary of the renumbering procedure . . . . . . . . . . . 4 | 1.1 Summary of the renumbering procedure . . . . . . . . . . . 4 | |||
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.3 Summary of what must be changed . . . . . . . . . . . . . 5 | 1.3 Summary of what must be changed . . . . . . . . . . . . . 5 | |||
1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 6 | 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Detailed review of procedure . . . . . . . . . . . . . . . . . 7 | 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 7 | |||
2.1 Initial condition: stable using the old prefix . . . . . . 7 | 2.1 Initial condition: stable using the old prefix . . . . . . 7 | |||
2.2 Preparation for the renumbering process . . . . . . . . . 7 | 2.2 Preparation for the renumbering process . . . . . . . . . 7 | |||
2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 8 | 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 8 | |||
2.2.2 Mechanisms for address assignment to interfaces . . . 9 | 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.4 Adding new host addresses . . . . . . . . . . . . . . . . 10 | |||
2.5 Stable use of either prefix . . . . . . . . . . . . . . . 11 | 2.5 Stable use of either prefix . . . . . . . . . . . . . . . 11 | |||
2.6 Transition from use of the old prefix to the new 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.1 Transition of DNS service to the new prefix . . . . . 11 | |||
2.6.2 Transition to the use of new addresses . . . . . . . . 11 | 2.6.2 Transition to the use of new addresses . . . . . . . . 11 | |||
2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 12 | 2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 12 | |||
2.8 Final condition: stable using the new prefix . . . . . . . 13 | 2.8 Final condition: stable using the new prefix . . . . . . . 13 | |||
3. How to avoid shooting yourself in the foot . . . . . . . . . . 14 | 3. How to avoid shooting yourself in the foot . . . . . . . . . . 14 | |||
3.1 Applications affected by renumbering . . . . . . . . . . . 14 | 3.1 Applications affected by renumbering . . . . . . . . . . . 14 | |||
skipping to change at page 9, line 21 | skipping to change at page 9, line 21 | |||
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 contact the server immediately. | 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 | 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 | |||
to the routing infrastructure for the new prefix are added in | to the routing infrastructure for the new prefix are added in | |||
parallel with the old prefix so that forwarding for both prefixes | parallel with the old prefix so that forwarding for both prefixes | |||
skipping to change at page 10, line 43 | skipping to change at page 10, line 43 | |||
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 while the addresses from the old prefix are retained on | |||
and manual processes. If SLAC is used in the network, the switches | those interfaces. The new IPv6 addresses may be assigned through | |||
and routers are configured to indicate that hosts should use SLAC to | SLAC, DHCP, and manual processes. If SLAC is used in the network, | |||
assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 | the switches and routers are configured to indicate that hosts should | |||
address assignment, the DHCP service is configured to assign IPv6 | use SLAC to assign IPv6 addresses from the new prefix. If DHCP is | |||
addresses to hosts. | 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 | 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. | |||
2.5 Stable use of either prefix | 2.5 Stable use of either prefix | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |