Procedures for Renumbering an IPv6 Network without a Flag Day
RFC 4192
Document | Type |
RFC - Informational
(September 2005; No errata)
Updates RFC 2072
|
|
---|---|---|---|
Authors | Eliot Lear , Fred Baker , Ralph Droms | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4192 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | David Kessens | ||
Send notices to | pekkas@netcore.fi, jonne.Soininen@nokia.com |
Network Working Group F. Baker Request for Comments: 4192 Cisco Systems Updates: 2072 E. Lear Category: Informational Cisco Systems GmbH R. Droms Cisco Systems September 2005 Procedures for Renumbering an IPv6 Network without a Flag Day Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 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 continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. Baker, et al. Informational [Page 1] RFC 4192 Renumbering IPv6 Networks September 2005 Table of Contents 1. Introduction ....................................................2 1.1. Summary of the Renumbering Procedure .......................3 1.2. Terminology ................................................4 1.3. Summary of What Must Be Changed ............................4 1.4. Multihoming Issues .........................................5 2. Detailed Review of Procedure ....................................5 2.1. Initial Condition: Stable Using the Old Prefix .............6 2.2. Preparation for the Renumbering Process ....................6 2.2.1. Domain Name Service .................................7 2.2.2. Mechanisms for Address Assignment to Interfaces .....7 2.3. Configuring Network Elements for the New Prefix ............8 2.4. Adding New Host Addresses ..................................9 2.5. Stable Use of Either 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.2. Transition to Use of New Addresses .................10 2.7. Removing the Old Prefix ...................................11 2.8. Final Condition: Stable Using the New Prefix ..............11 3. How to Avoid Shooting Yourself in the Foot .....................12 3.1. Applications Affected by Renumbering ......................12 3.2. Renumbering Switch and Router Interfaces ..................12 3.3. Ingress Filtering .........................................13 3.4. Link Flaps in BGP Routing .................................13 4. Call to Action for the IETF ....................................14 4.1. Dynamic Updates to DNS Across Administrative Domains ......14 4.2. Management of the Reverse Zone ............................14 5. Security Considerations ........................................14 6. Acknowledgements ...............................................16 7. References .....................................................17 7.1. Normative References ......................................17 7.2. Informative References ....................................17 Appendix A. Managing Latency in the DNS ..........................20 1. Introduction The Prussian military theorist Carl von Clausewitz [Clausewitz] wrote, "Everything is very simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war.... So in war, through the influence of an 'infinity of petty circumstances' which cannot properly be described on paper, things disappoint us and 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 expectation that homo ignoramus will behave intelligently. Baker, et al. Informational [Page 2] RFC 4192 Renumbering IPv6 Networks September 2005 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 the network recovers. Avoiding outages requires the network to be modified using what in mobility might be called a "make before break" procedure: the network is enabled to use a new prefix while the oldShow full document text