One document matched: draft-ietf-ipngwg-renum-process-00.txt

Network Working Group                                             R. Elz
Internet Draft                                   University of Melbourne
Expiration Date: September 1999
                                                              March 1999


                       The Process of Renumbering


                 draft-ietf-ipngwg-renum-process-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   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.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   Note that the first paragraph of this section is a meaningless
   bureaucratic requirement of the IESG.  It is provided so as to
   satisfy those bureaucratic requirements, and serves no other purpose
   whatever.  Information as to any intellectual property rights, beyond
   the right to redistribute this document and make use of it for the
   purposes of an internet draft, should be sought in other parts of
   this document.

   This entire section has been prepended to this document automatically
   during formatting without any direct involvement by the author(s) of
   this draft.  No assumption should be made that the authors have
   assented to any of it.







Elz                     [Expires September 1999]                [Page 1]

Internet Draft   draft-ietf-ipngwg-renum-process-00.txt       March 1999


Abstract

   This document discusses the process of renumbering an Internet Node.
   While it is not protocol specific, as such, it is expected that some
   of the mechanisms proposed will never be defined, or deployed, for
   IPv4.  Hence this may serve mostly as a template mechanism for the
   process of renumbering an IPv6 site.

1. Introduction

   Much has been written [...] on the subject of renumbering a site, and
   its difficulties.  This document does not consider that issue, and
   assumes that the results of the lessons learned from those
   experiences, and the benefits of IPv6 including stateless
   autoconfiguration via neighbour discovery [] and router renumbering
   [] will make the task of renumbering a site, internally, a tractable
   problem.

   However, of itself, this is insufficient to fully complete a
   renumbering task.  Aside from the site itself, there is the problem
   of others, typically unknown to the site itself, who have knowledge
   of its old address, and need to be informed of any address changes
   and then make the necessary updates.

   This document describes the a series of steps which, if followed,
   will permit all parties on the internet with a need to know of
   address changes to detect the change, and update their knowledge, in
   such a way that the address change can be made gracefully.

2. The Steps

   The overall process of renumbering can be described by the following
   sequence of events:

        [1]   Someone/something determines that a new set of addresses
              will be needed for some set of hosts/nets.  The details of
              how, and by whom, this decision is made are beyond the
              scope of this document.

        [2]   That info is communicated to the owner of (the net admin,
              human or otherwise, of) the set of hosts involved.
              Whether this is automated via some protocol or other, or
              is done via more mundane method, is not important here.

        [3]   Some kind of DNS (or some kind of database) entry is
              updated showing the new set of addresses as additional
              addresses for the entity involved.  This dadatase does not
              yet exists.  Its creation seems to be necesary for orderly



Elz                     [Expires September 1999]                [Page 2]

Internet Draft   draft-ietf-ipngwg-renum-process-00.txt       March 1999


              renumbering.

        [4]   Routers and other filter lists (etc) are updated to make
              the new addresses equivalent to the old ones (all around
              the internet, not just at the entity being renumbered.)
              This presumes that the routers, or the manager or
              configuration system that configures the routers, use keys
              into the database postulated in the previous step when
              configuring references to address spaces, and translate
              those to the corresponding numeric values as needed, along
              with "time to live" values to cause regular retranslation
              of the keys to address values.

        [5]   The new addresses are distributed to the hosts/routers
              that are being renumbered.  The precise mechanism by which
              this is accomplished is unimportant here, however it seems
              likely that [Router-renum] might be used to distribute the
              new addresses to routers, followed by appropriate Router
              Advertisments [RFCmmm] to distribute the new addresses to
              the hosts.  The old addresses should be marked as
              deprecated at the same time.  This will cause those hosts
              to start originating connections from the new addresses
              one assumes.

        [6]   The DNS is updated with the new addresses for the things
              that have been renumbered.  This will gradually cause
              incoming connections to start using the new addresses as
              new translations of names to addresses are done, and the
              old cached address values gradually disappear.

        [7]   The old addresses are removed from the DNS so no new
              connections will be initiated to the old addresses.

        [8]   The old addresses are withdrawn from RA adverts, so the
              renumbered hosts stop accepting and using them.

        [9]   The database mentioned in 3 is updated to remove the old
              addresses from the list of addresses belonging to the
              entity that has been renumbered.

       [10]   Step 4 naturally repeats as time to lives expire, with the
              translation of keys to addresses now using only the new
              addreses.

       [11]   The address block that is no longer in use is returned to
              the free pool and is thus now available for assignment
              elsewhere.




Elz                     [Expires September 1999]                [Page 3]

Internet Draft   draft-ietf-ipngwg-renum-process-00.txt       March 1999


3. Time Lines

   The steps of the previous section must be completed in order.
   However, some require delays to allow proper propogation of changed
   information around the internet.

   The database mentioned in step 3 needs to associate a time to live
   with each value.  Then steps 4 and 10 need to be given at least that
   time to complete.  Note that if the DNS implements the database, the
   relevant time for steps 4 and 10 is the sum of the TTL field of the
   DNS for the resource records used, and the zone propogation time from
   primary server to secondary servers, as set in the Start of Authority
   resource record.  Typically an implementation of this scheme would
   allow twice the expected necessary delay.

   The delay required at step 5 will depend upon the size of the part of
   the network being renumbered.  As this is entirely confined to the
   site being renumbered, it can determine when it has finished.

   Step 6 can proceed concurrently with step 5, to the extent that as
   each node gains its new addreses it can immediately enter them in the
   DNS.  This permits the use of techniques like [DynDNS] to allow DNS
   updates to be performed by the renumbered hosts.

   Similarly, step 7 can proceed concurrently with step 6, in that old
   addresses can be deleted from the DNS as the new ones are added, if
   desired.  After the last DNS update of step 7 is made, that is, the
   last of the old addresses is deleted from the DNS, the minimum delay
   before step 8 is the DNS zone propogation and cache TTL delay.
   Typically a much longer delay will occur at this point to allow
   connections already established to remain operational.  Until the
   connection identifiers are separated frin the addresses, or a
   mechanism is created to allow the connection identifiers to be
   altered during the life of a connection, a considerable delay is
   likely to be required here.  In gthe worst cases this delay could
   amount to months, or even years.  Of course, it will be bounded by
   the period during which the old addresses will be permitted to
   remain.  When that time expires, and assuming the additional
   mechanism does not exist, old connections will simply have to be
   broken.

   Step 8 is essentially a repeat of step 4, and should take an
   equivalent period.  Similarly, step 9 uses the same procedures as
   step 5.

   As soon as step 11 is completed, the whole procedure has finished.





Elz                     [Expires September 1999]                [Page 4]

Internet Draft   draft-ietf-ipngwg-renum-process-00.txt       March 1999


4. Requirements

5. Security Considerations

6. Example

7. References

Authors' Addresses










































Elz                     [Expires September 1999]                [Page 5]