rfc2072.txt

RFC 的详细文档！

Network Working Group                                       H. Berkowitz
Request for Comments: 2072                             PSC International
Category: Informational                                     January 1997


                        Router Renumbering Guide

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

   IP addresses currently used by organizations are likely to undergo
   changes in the near to moderate term.  Change can become necessary
   for a variety of reasons, including enterprise reorganization,
   physical moves of equipment, new strategic relationships, changes in
   Internet Service Providers (ISP), new applications, and the needs of
   global Internet connectivity.  Good IP address management may in
   general simplify continuing system administration; a good renumbering
   plan is also a good numbering plan.    Most actions taken to ease
   future renumbering will ease routine network administration.

   Routers are the components that interconnect parts of the IP address
   space identified by unique prefixes.  Obviously, they will be
   impacted by renumbering.  Other interconnection devices, such as
   bridges, layer 2 switches (i.e., specialized bridges), and ATM
   switches may be affected by renumbering.  The interactions of these
   lower-layer interconnection devices with routers must be considered
   as part of a renumbering effort.

   Routers interact with numerous network infrastructure servers,
   including DNS and SNMP.  These interactions, not just the pure
   addressing and routing structure, must be considered as part of
   router renumbering.














Berkowitz                    Informational                      [Page 1]

RFC 2072                Router Renumbering Guide            January 1997


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.   Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.   Motivations for Renumbering  . . . . . . . . . . . . . . . .  3
   4.   Numbering and Renumbering. . . . . . . . . . . . . . . . . .  9
   5.   Moving toward a Renumbering-Friendly Enterprise. . . . . . . 13
   6.   Potential Pitfalls in Router Renumbering.  .  .  . . . . . . 20
   7.   Tools and Methods for Renumbering  . .  .  . . . . . . . . . 25
   8.   Router Identifiers . . . . . . . . . . . . . . . . . . . . . 29
   9.   Filtering and Access Control . . . . . . . . . . . . . . . . 35
  10.   Interior Routing . . . . . . . . . . . . . . . . . . . . . . 37
  11.   Exterior Routing . . . . . . . . . . . . . . . . . . . . . . 39
  12.   Network Management . . . . . . . . . . . . . . . . . . . . . 41
  13.   IP and Protocol Encapsulation  . . . . . . . . . . . . . . . 43
  14.   Security Considerations. . . . . . . . . . . . . . . . . . . 44
  15.   Planning and Implementing the Renumbering  . . . . . . . . . 44
  16.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
  17.   References . . . . . . . . . . . . . . . . . . . . . . . . . 47
  18.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 48

1.  Introduction

   Organizations can decide to renumber part or all of their IP address
   space for a variety of reasons.  Overall motivations for renumbering
   are discussed in [RFC2071].  This document deals with the router-
   related aspects of a renumbering effort, once the decision to
   renumber has been made.

   A renumbering effort must be well-planned if it is to be successful.
   This document deals with planning and implementation guidelines for
   the interconnection devices of an enterprise. Of these devices,
   routers have the clearest association with the IP numbering plan.

   Planning begins with understanding the problem to be solved.  Such
   understanding includes both the motivation for renumbering and the
   technical issues involved in renumbering.

      1.  Begin with a short and clear statement of the reason to
          renumber.  Section 3  of this document discusses common
          reasons.

      2.  Understand the principles of numbering in the present and
          planned environments.  Section 4 reviews numbering and
          suggests a method for describing the scope of renumbering.






Berkowitz                    Informational                      [Page 2]

RFC 2072                Router Renumbering Guide            January 1997


      3.  Before the actual renumbering, it can be useful to evolve
          the current environment and current numbering to a more
          "renumbering-friendly" system.  Section 5 discusses ways to
          introduce renumbering friendliness into current systems.

      4.  Be aware of potential pitfalls.  These are discussed in
          Section 6.

      5.  Identify potential requirements for tools, discussed in
          Section 7.

      6.  Evaluate the specific router mechanisms that will be affected
          by renumbering.  See Sections 8 through 13.

      7.  Set up a specific transition plan framework.  Guidelines
          for such planning are in Section 15.

   When trying to understand the interactions of renumbering on routers,
   remember there different aspects to the problem, depending on the
   scope of the renumbering involved.  Remember that even an
   enterprise-wide renumbering probably will not affect all IP addresses
   visible within the enterprise, since some addresses (e.g., Internet
   service providers, external business partners) are outside the
   address space under the control of the enterprise.

2. Disclaimer

   The main part of this document is intended to be vendor-independent.
   Not all features discussed, of course, have been implemented on all
   routers.    This document should not be used as a general comparison
   of the richness of features of  different implementations.
   References here are only to those features affected by renumbering.
   Some illustrative examples may be used that cite vendor-specific
   characteristics.  These examples do not necessarily reflect the
   current status of products.

3.  Motivations for Renumbering

   Reasons to renumber can be technological, organizational, or both.
   Technological reasons fall into several broad categories discussed
   below.  Just as there can be both technological and organizational
   motivations for renumbering [RFC2071], there can be multiple
   technological reasons.

   There may not be a clear line between organizational and technical
   reasons for renumbering.  While networks have a charm and beauty all
   their own, the organizational reasons should be defined first in
   order to justify the budget for the technical renumbering.  There



Berkowitz                    Informational                      [Page 3]

RFC 2072                Router Renumbering Guide            January 1997


   also may be pure technnical reasons to renumber, such as changes in
   technology (e.g., from bridging to routing).

   While this document is titled "Router Renumbering Guide," it
   recognizes that renumbering may be required due to the initial
   installation of routers in a bridged legacy network. Organizations
   may have had an adequate bridging solution that did not scale with
   growth.  Some organizations could not able to move to routers until
   router forwarding performance improved [Carpenter] to be comparable
   to bridges.

   Other considerations include compliance with routing outside the
   organization.  Routing issues here are primarily those of the global
   Internet, but may also involve bilateral private links to other
   enterprises.

   Certain new transmission technologies have tended to redefine the
   basic notion of an IP subnet.  The numbering plan needs to work with
   these new ideas.  Legacy bridged networks and leading-edge workgroup
   switched networks may very well need changes in the subnetting
   structure.  Renumbering needs may also develop with the introduction
   of new WAN technologies, especially nonbroadcast multiaccess (NBMA)
   services such as frame relay.  Other WAN technologies, dialup media
   using modems or ISDN, also may have new routing and numbering
   requirements.  Switched virtual circuit services such as ATM, X.25,
   or switched frame relay also interact with routing and addressing.

3.1  Internet Global Routing

   Many discussions of renumbering emphasize interactions among
   organizations' numbering plans and those of the global Internet
   [RFC1900].  There can be equally strong motivations for renumbering
   in organizations that never connect to the global Internet.

   According to RFC1900, "Unless and until viable alternatives are
   developed, extended deployment of Classless Inter-Domain Routing
   (CIDR) is vital to keep the Internet routing system alive and to
   maintain continuous uninterrupted growth of the Internet....To
   contain the growth of routing information, whenever such an
   organization changes to a new service provider, the organization's
   addresses will have to change.

   Occasionally, service providers themselves may have to change to a
   new and larger block of address space. In either of these cases, to
   contain the growth of routing information, the organizations
   concerned would need to renumber.... If the organization does not
   renumber, then some of the potential consequences may include (a)
   limited (less than Internet-wide) IP connectivity, or (b) extra cost



Berkowitz                    Informational                      [Page 4]

RFC 2072                Router Renumbering Guide            January 1997


   to offset the overhead associated with the organization's routing
   information that Internet Service Providers have to maintain, or
   both."

3.2  Bridge Limitations; Internal Use of LAN Switching

   Introducing workgroup switches may introduce subtle renumbering
   needs. Fundamentally, workgroup switches are specialized, high-
   performance bridges, which make their main forwarding decisions
   based on Layer 2 (MAC) address information.   Even so, they rarely
   are independent of Layer 3 (IP) address structure.  Pure Layer 2
   switching has a "flat" address space that will need to be renumbered
   into a hierarchical, subnetted space consistent with routing.
   Traditional bridged networks share many of the problems of workgroup
   switches,  but have additional performance problems when bridged
   connectivity extends across slow WAN links.

   Introducting single switches or stacks of switches may not have
   significant impact on addressing, as long as it is remembered that
   each system of switches is a single broadcast domain.  Each broadcast
   domain should map to a single IP subnet.

   Virtual LANs (VLAN) further extend the complexity of the role of
   workgroup switches.  It is generally true that moving an end station
   from one switch port to another within the same "color" VLAN will not
   cause major changes in addressing. Many discussions of this
   technology do not make it clear that moving the same end station
   between different colors will move the end station into another IP
   subnet, requiring a significant address change.

   Switches are commonly managed by SNMP applications.  These network
   management applications communicate with managed devices using IP.
   Even if the switch does not do IP forwarding, it will itself need IP
   addresses if it is to be managed.  Also, if the clients and servers
   in the workgroup are managed by SNMP, they will need IP addresses.
   The workgroup, therefore, will need to appear as one or more IP
   subnets.

   Increasingly, internetworking products are not purely Layer 2 or
   Layer 3 devices.  A workgroup switch product often includes a router
   function, so the numbering plan must support both flat Layer 2 and
   hierarchical Layer 3 addresses.









Berkowitz                    Informational                      [Page 5]

RFC 2072                Router Renumbering Guide            January 1997


3.3  Internal Use of NBMA Cloud Services

   "Cloud" services such as frame relay often are more economical than
   traditional services.  At first glance, when converting existing
   enterprise networks to NBMA, it might appear that the existing subnet
   structure should be preserved, but this is often not the case.

   Many organizations  often  began by treating the "cloud" as a single
   subnet, but experience has shown it is often better to treat the
   individual virtual circuits as separate subnets.  When the individual
   point-to-point VCs become separate subnets, efficient address
   utilization requires the use of /30 prefixes for these subnets.  This
   typically means the addressing and routing plan must support multiple