Procedures for Renumbering an IPv6 Network without a Flag Day
RFC 4192
| Document | Type |
RFC - Informational
(September 2005; No errata)
Updates RFC 2072
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4192 (Informational) | |
| 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
Show full document text