datatracker.ietf.org
Sign in
Version 5.8.1, 2014-12-18
Report a bug

Procedures for Renumbering an IPv6 Network without a Flag Day
RFC 4192

Document type: RFC - Informational (September 2005; No errata)
Updates RFC 2072
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4192 (Informational)
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

[include full document text]