rfc2071.txt

RFC 的详细文档！

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


   can help automate the assignment and maintenance of host names, as
   well as the 'borrowed' addresses required for routing-level
   connectivity.

   The PIER Working Group is developing procedures and guidelines for
   detailed renumbering of specific technologies, such as routers [6].
   PIER WG documents are intended to suggest methods both for making
   existing networks prepared for convenient renumbering, as well as for
   operational transition to new addressing schemes.

   Also, in many instances, organizations who have never connected to
   the Internet, yet have been using arbitrary blocks of addresses since
   their construction, have different and unique challenges.

3. Network Renumbering Defined

   In the simplest of definitions, the exercise of renumbering a network
   consists of changing the IP host addresses, and perhaps the network
   mask, of each device within the network that has an address
   associated with it. This activity may or may not consist of all
   networks within a particular domain, such as FOO.EDU, or networks
   which comprise an entire autonomous system.

   Devices which may need to be renumbered, for example, are networked
   PC's, workstations, printers, file servers, terminal servers, and
   routers. Renumbering a network may involve changing host parameters
   and configuration files which contain IP addresses, such as
   configuration files which contain addresses of DNS and other servers,
   addresses contained in SNMP [7] management stations, and addresses
   configured in access control lists. While this is not an all-
   inclusive list, the PIER working group is making efforts to compile
   documentation to identify these devices in a more detailed fashion.

   Network renumbering need not be sudden activity, either; in most
   instances, an organization's upstream service provider(s) will allow
   a grace period where both the "old" addresses and the "new" addresses
   may be used in parallel.

4. Reasons for Renumbering

   The following sections discuss particular reasons which may
   precipitate network renumbering, and are not presented in any
   particular order of precedence.  They are grouped into reasons that
   primarily reflect decisions made in the past, operational
   requirements of the present, or plans for the future.






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


   Some of these requirements reflect evolution in the organization's
   mission, such as a need to communicate with business partners, or to
   work efficiently in a global Internet.  Other requirements reflect
   changes in network technologies.

4.1  Past

   Many organizations implemented IP-based networks not for connectivity
   to the Internet, but simply to make use of effective data
   communications mechanisms.  These organizations subsequently found
   valid reasons to connect to other organizations or the Internet in
   general, but found the address structures they chose incompatible
   with overall Internet practice.

   Other organizations connected early to the Internet, but did so at a
   time when address space was not scarce.  Yet other organizations
   still have no requirement to connect to the Internet, but have legacy
   addressing structures that do not scale to adequate size.

4.1.1  Initial addressing using non-unique addresses

   As recently as two years ago, many organizations had no intention of
   connecting to the Internet, and constructed their corporate or
   organizational network(s) using unregistered, non-unique network
   addresses.  Obviously, as most problems evolve, these same
   organizations determined that Internet connectivity had become a
   valuable asset, and subsequently discovered that they could no longer
   use the same unregistered, non-unique network addresses that were
   previously deployed throughout their organization.  Thus, the labor
   of renumbering to valid network addresses is now upon them, as they
   move to connect to the global Internet.

   While obtaining valid, unique addresses is certainly required to
   obtain full Internet connectivity in most circumstances, the number
   of unique addresses required can be significantly reduced by the
   implementation of Network Address Translation (NAT) devices [8] and
   the use of private address space, as specified in [9].  NAT reduces
   not only the number of required unique addresses, but also localizes
   the changes required by renumbering.

   It should also be noted that NAT technology may not always be a
   viable option, depending upon scale of addressing, performance or
   topological constraints.








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


4.1.2  Legacy address allocation

   There are also several instances where organizations were originally
   allocated very large amounts of address space, such as traditional
   "Class A" or "Class B" allocations, while the actual address
   requirements are much less than the total amount of address space
   originally allocated.  In many cases, these organizations could
   suffice with a smaller CIDR allocation, and utilize the allocated
   address space in a more efficient manner.  As allocation requirements
   become more stringent, mechanisms to review how these organizations
   are utilizing their address space could, quite possibly, result in a
   request to return the original allocation to a particular registry
   and renumber with a more appropriately sized address block.

4.1.3  Limitations of Bridged Internetworks

   Bridging has a long and distinguished history in legacy networks.  As
   networks grow, however, traditional bridged networks reach
   performance- and stability-related limits, including (but not limited
   to) broadcast storms.

   Early routers did not have the speed to handle the needs of some
   large networks.  Some organizations were literally not able to move
   to routers until router forwarding performance improved to be
   comparable to bridges.  Now that routers are of comparable or
   superior speed, and offer more robust features, replacing bridged
   networks becomes reasonable.

   IP addresses assigned to pure bridged networks tend not to be
   subnetted, yet subnetting is a basic approach for router networks.
   Introducing subnetting is a practical necessity in moving from
   bridging to routing.