Network Renumbering Overview: Why would I want it and what is it anyway?
RFC 2071

Document Type RFC - Informational (January 1997; No errata)
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 2071 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        P. Ferguson
Request for Comments: 2071                           cisco Systems, Inc.
Category: Informational                                     H. Berkowitz
                                                       PSC International
                                                            January 1997

                     Network Renumbering Overview:
               Why would I want it and what is it anyway?

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   The PIER [Procedures for Internet/Enterprise Renumbering] working
   group is compiling a series of documents to assist and instruct
   organizations in their efforts to renumber.  However, it is becoming
   apparent that, with the increasing number of new Internet Service
   Providers (ISP's) and organizations getting connected to the Internet
   for the first time, the concept of network renumbering needs to be
   further defined.  This document attempts to clearly define the
   concept of network renumbering and discuss some of the more pertinent
   reasons why an organization would have a need to do so.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.   Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.   Network Renumbering Defined. . . . . . . . . . . . . . . . .  3
   4.   Reasons for Renumbering. . . . . . . . . . . . . . . . . . .  3
   5.   Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.   Security Considerations  . . . . . . . . . . . . . . . . . . 12
   7.   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 12
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14

Ferguson & Berkowitz         Informational                      [Page 1]
RFC 2071              Network Renumbering Overview          January 1997

1. Introduction

   The popularity of connecting to the global Internet over the course
   of the past several years has spawned new problems; what most people
   casually refer to as "growing pains" can be attributed to more basic
   problems in understanding the requirements for Internet connectivity.
   However, the reasons why organizations may need to renumber their
   networks can greatly vary. We'll discuss these issues in some amount
   of detail below.  It is not within the intended scope of this
   document to discuss renumbering methodologies, techniques, or tools.

2. Background

   The ability for any network or interconnected devices, such as
   desktop PCs or workstations, to obtain connectivity to any potential
   destination in the global Internet is reliant upon the possession of
   unique IP host addresses [1].  A duplicate host address that is being
   used elsewhere in the Internet could best be described as
   problematic, since the presence of duplicate addresses would cause
   one of the destinations to be unreachable from some origins in the
   Internet.  It should be noted, however, that globally unique IP
   addresses are not always necessary, and is dependent on the
   connectivity requirements [2].

   However, the recent popularity in obtaining Internet connectivity has
   made these types of connectivity dependencies unpredictable, and
   conventional wisdom in the Internet community dictates that the
   various address allocation registries, such as the InterNIC, as well
   as the ISP's, become more prudent in their address allocation
   strategies.  In that vein, the InterNIC has defined address
   allocation policies [3] wherein the majority of address allocations
   for end-user networks are accommodated by their upstream ISP, except
   in cases where dual- or multihoming and very large blocks of
   addresses are required.  With this allocation policy becoming
   standard current practice, it presents unique problems regarding the
   portability of addresses from one provider to another.

   As a practical matter, end users cannot assume they "own" address
   allocations, if their intention is to be to have full connectivity to
   the global Internet. Rather, end users will "borrow" part of the
   address space of an upstream provider's allocation. The larger
   provider block from which their space is suballocated will have been
   assigned in a manner consistent with global Internet routing.

   Not having "permanent" addresses does not mean users will not have
   unique identifiers. Such identifiers are typically Domain Name System
   (DNS) [4] names for endpoints such as servers and workstations.
   Mechanisms such as the Dynamic Host Configuration Protocol (DHCP) [5]

Ferguson & Berkowitz         Informational                      [Page 2]
RFC 2071              Network Renumbering Overview          January 1997
Show full document text