doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc2071.txt b/doc/rfc/rfc2071.txt
new file mode 100644
index 0000000..989e9dd
--- /dev/null
+++ b/doc/rfc/rfc2071.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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.
+
+   Special cases of bridging are realized in workgroup switching
+   systems, discussed below.
+
+4.1.4  Limitations of Legacy Routing Systems
+
+   Other performance problems might come from routing mechanisms that
+   advertise excessive numbers of routing updates (e.g., RIP, IGRP).
+   Likewise, appropriate replacement protocols (e.g., OSPF, EIGRP, S-IS)
+   will work best with a structured addressing system that encourages
+   aggregation.
+
+
+
+
+
+
+
+
+Ferguson & Berkowitz         Informational                      [Page 5]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+4.1.5  Limitations of System Administration Methodologies
+
+   There can be operational limits to growth based on the difficulty of
+   adds, moves and changes.  As enterprise networks grow, it may be
+   necessary to delegate portions of address assignment and maintenance.
+   If address space has been assigned randomly or inefficiently, it may
+   be difficult to delegate portions of the address space.
+
+   It is not unusual for organizational networks to grow sporadically,
+   obtaining an address prefix here and there, in a non-contiguous
+   fashion.  Depending on the number of prefixes that an organization
+   acquires over time, it may become increasingly unmanageable or demand
+   higher levels of maintenance and administration when individual
+   prefixes are acquired in this way.
+
+   Reasonable IP address management may in general simplify continuing
+   system administration; a good numbering plan is also a good
+   renumbering plan.  Renumbering may force a discipline into system
+   administration that will reduce long-term support costs.
+
+   It has been observed "...there is no way to renumber a network
+   without an inventory of the hosts (absent DHCP). On a large network
+   that needs a database, plus tools and staff to maintain the
+   database."[10] It can be argued that a detailed inventory of router
+   configurations is even more essential.
+
+4.2  Present
+
+   Organizations now face needs to connect to the global Internet, or at
+   a minimum to other organizations through bilateral private links.
+
+   Certain new transmission technologies have tended to redefine the
+   basic notion of an IP subnet.  An IP 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 due to the
+   characteristics of new WAN technologies, especially nonbroadcast
+   multi-access (NBMA) services such as Frame-Relay and Asynchronous
+   Transfer Mode (ATM).
+
+   Increased use of telecommuting by mobile workers, and in small and
+   home offices, need on-demand WAN connectivity, using modems or ISDN.
+   Effective use of demand media often requires changes in numbering and
+   routing.
+
+
+
+
+
+
+
+Ferguson & Berkowitz         Informational                      [Page 6]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+4.2.1   Change in organizational structure or network topology
+
+   As companies grow, through mergers, acquisitions and reorganizations,
+   the need may arise for realignment and modification of the various
+   organizational network architectures.  The connectivity of disparate
+   corporate networks present unique challenges in the realm of
+   renumbering, since one or more individual networks may have to be
+   blended into a much larger architecture consisting a different IP
+   address prefix altogether.
+
+4.2.2  Inter-Enterprise Connectivity
+
+   Even if they do not connect to the general Internet, enterprises may
+   interconnect to other organizations which have independent numbering
+   systems. Such connectivity can be as simple as bilateral dedicated
+   circuits. If both enterprises use unregistered or private address
+   space, they run the risk of using duplicate addresses.
+
+   In such cases, one or both organizations may need to renumber into
+   different parts of the private address space, or obtain unique
+   registered addresses.
+
+4.2.3   Change of Internet Service Provider
+
+   As mentioned previously in Section 2, it is increasingly becoming
+   current practice for organizations to have their IP addresses
+   allocated by their upstream ISP.  Also, with the advent of Classless
+   Inter Domain Routing (CIDR) [11], and the considerable growth in the
+   size of the global Internet table, Internet Service Providers are
+   becoming more and more reluctant to allow customers to continue using
+   addresses which were allocated by the ISP, when the customer
+   terminates service and moves to another ISP.  The prevailing reason
+   is that the ISP was previously issued a CIDR block of contiguous
+   address space, which can be announced to the remainder of the
+   Internet community as a single prefix. (A prefix is what is referred
+   to in classless terms as a contiguous block of IP addresses.)  If a
+   non-customer advertises a specific component of the CIDR block, then
+   this adds an additional routing entry to the global Internet routing
+   table.  This is what is commonly referred to as "punching holes" in a
+   CIDR block. Consequently, there are usually no routing anomalies in
+   doing this since a specific prefix is always preferred over an
+   aggregate route.  However, if this practice were to happen on a large
+   scale, the growth of the global routing table would become much
+   larger, and perhaps too large for current backbone routers to
+   accommodate in an acceptable fashion with regards to performance of
+   recalculating routing information and sheer size of the routing table
+   itself.  For obvious reasons, this practice is highly discouraged by
+   ISP's with CIDR blocks, and some ISP's are making this a contractual
+
+
+
+Ferguson & Berkowitz         Informational                      [Page 7]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+   issue, so that customers understand that addresses allocated by the
+   ISP are non-portable.
+
+   It is noteworthy to mention that the likelihood of being forced to
+   renumber in this situation is inversely proportional to the size of
+   the customer's address space.  For example, an organization with a
+   /16 allocation may be allowed to consider the address space
+   "portable", while an organization with multiple non-contiguous /24
+   allocations may not.  While the scenarios may be vastly different in
+   scope, it becomes an issue to be decided at the discretion of the
+   initial allocating entity, and the ISP's involved; the major deciding
+   factor being whether or not the change will fragment an existing CIDR
+   block and whether it will significantly contribute to the overall
+   growth of the global Internet routing tables.
+
+   It should also be noted that (contrary to opinions sometimes voiced)
+   this form of renumbering is a technically necessary consequence of
+   changing ISP's, rather than a commercial or political mandate.
+
+4.2.3  Internet Global Routing
+
+   Even large organizations, now connected to the Internet with
+   "portable" address space, may find their address allocation too
+   small. Current registry guidelines require that address space usage
+   be justified by an engineering plan. Older networks may not have
+   efficiently utilized existing address space, and may need to make
+   their existing structures more efficient before new address
+   allocations can be made.
+
+4.2.4  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.
+
+   Introducing single switches or stacks of switches may not have
+   significant impact on addressing, as long as it is understood that
+   each system of switches is a single broadcast domain. Each broadcast
+   domain should map to a single IP subnetwork.
+
+   Virtual LANs (VLANs) 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 VLAN will not cause
+   major changes in addressing. Many overview presentations of this
+
+
+
+Ferguson & Berkowitz         Informational                      [Page 8]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+   technology do not make it clear that moving the same end station
+   between different VLANs 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 also require IP
+   addresses. The workgroup, therefore, will need to appear as one or
+   more IP subnetworks.
+
+   Increasingly, internetworking products are not purely Layer 2 or
+   Layer 3 devices. A workgroup switch product often includes a routing
+   function, so the numbering plan must support both flat Layer 2 and
+   hierarchical Layer 3 addressing.
+
+4.2.4  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, which appear as
+   traditional point-to-point circuits.  When the individual point-to-
+   point VCs become separate subnets, efficient address utilization
+   requires the use of long prefixes (i.e., 30 bit) for these subnets.
+   In practice, obtaining 30 bit prefixes means the logical network
+   should support variable length subnet masks (VLSM).  VLSMs are the
+   primary method in which an assigned prefix can be subnetted
+   efficiently for different media types. This is accomplished by
+   establishing one or more prefix lengths for LAN media with more than
+   two hosts, and subdividing one or more of these shorter prefixes into
+   longer /30 prefixes that minimize address loss.
+
+   There are alternative ways to configure routing over NBMA, using
+   special mechanisms to exploit or simulate point-to-multipoint VCs.
+   These often have a significant performance impact, and may be less
+   reliable because a single routing point of failure is created.
+   Motivations for such alternatives tend to include:
+
+
+
+
+
+
+
+
+Ferguson & Berkowitz         Informational                      [Page 9]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+      1.  A desire not to use VLSM. This is often founded in fear
+          rather than technology.
+
+      2.  Router implementation issues that limit the number of subnets
+          or interfaces a given router can support.
+
+      3.  An inherently point-to-multipoint application (e.g., remote
+          hosts to a data center). In such cases, some of the
+          limitations are due to the dynamic routing protocol in use.
+          In such "hub-and-spoke" implementations, static routing can
+          be preferable from a performance and flexibility standpoint,
+          since it does not produce routing protocol chatter and is
+          unaffected by split horizon constraints (namely, the inability
+          to build an adjacency with a peer within the same IP
+          subnetwork).
+
+4.2.5  Expansion of Dialup Services
+
+   Dialup services, especially public Internet access providers, are
+   experiencing explosive growth. This success represents a particular
+   drain on the available address space, especially with a commonly used
+   practice of assigning unique addresses to each customer.
+
+   In this case, individual users announce their address to the access
+   server using PPP's IP control protocol (IPCP) [12]. The server may
+   validate the proposed address against some type of user
+   identification, or simply make the address active in a subnet to
+   which the access server (or set of bridged access servers) belongs.
+
+   The preferred technique is to allocate dynamic addresses to the user
+   from a pool of addresses available to the access server.
+
+4.2.6  Returning non-contiguous prefixes for an aggregate
+
+   In many instances, an organization can return their current, non-
+   contiguous prefix allocations for a contiguous block of address space
+   of equal or greater size, which can be accommodated with CIDR.  Also,
+   many organizations have begun to deploy classless interior routing
+   protocols within their domains that make use of route summarization
+   and other optimized routing features, effectively reducing the total
+   number of routes being propagated within their internal network(s),
+   and making it much easier to administer and maintain.
+
+   Hierarchical routing protocols such as OSPF scale best when the
+   address assignment of a given network reflects the topology, and the
+   topology of the network can often be fluid. Given that the network is
+   fluid, even the best planned address assignment scheme, given time,
+   will diverge from the actual topology. While not required, some
+
+
+
+Ferguson & Berkowitz         Informational                     [Page 10]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+   organization may choose to gain the benefit of both technical and
+   administrative scalability of their IGP by periodically renumbering
+   to have address assignments reflect the network topology. Patrick
+   Henry once said "the tree of liberty must from time to time be
+   watered with the blood of patriots." In the Internet, routing trees
+   of the best-planned networks need from time to time be watered with
+   at least the sweat of network administrators.  Improving aggregation
+   is also highly encouraged to reduce the size of not only the global
+   Internet routing table, but also the size and scalability of interior
+   routing within the enterprise.
+
+4.3  Future
+
+   Emerging new protocols will most definitely affect addressing plans
+   and numbering schemes.
+
+4.3.1  Internal Use of Switched Virtual Circuit Services
+
+   Services such as ATM virtual circuits, switched frame relay, etc.,
+   present challenges not considered in the original IP design.  The
+   basic IP decision in forwarding a packet is whether the destination
+   is local or remote, in relation to the source host's subnet. Address
+   resolution mechanisms are used to find the medium address of the
+   destination in the case of local destinations, or to find the medium
+   address of the router in the case of remote routers.
+
+   In these new services, there are cases where it is far more effective
+   to "cut-through" a new virtual circuit to the destination. If the
+   destination is on a different subnet than the source, the cut-through
+   typically is to the egress router that serves the destination subnet.
+   The advantage of cut-through in such a case is that it avoids the
+   latency of multiple router hops, and reduces load on "backbone"
+   routers. The cut-through decision is usually made by an entry router
+   that is aware of both the routed and switched environments.
+
+   This entry router communicates with a address resolution server using
+   the Next Hop Resolution Protocol (NHRP) [13]. This server maps the
+   destination network address to either a next-hop router (where cut-
+   through is not appropriate) or to an egress router reached over the
+   switched service. Obviously, the data base in such a server may be
+   affected by renumbering. Clients may have a hard-coded address of the
+   server, which again may need to change.  While the NHRP protocol
+   specifications are still evolving at the time of this writing,
+   commercial implementations based on drafts of the protocol standard
+   are in use.
+
+
+
+
+
+
+Ferguson & Berkowitz         Informational                     [Page 11]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+4.3.2  Transitioning to IP version 6
+
+   Of course, when IPv6 [14] deployment is set in motion, and as
+   methodologies are developed to transition to IPv6, renumbering will
+   also be necessary, but perhaps not immediately mandatory.  To aid in
+   the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6 stacks
+   on network hosts should also become available. It is also envisioned
+   that Network Address Translation (NAT) devices will be developed to
+   assist in the IPv4 to IPv6 transition, or perhaps supplant the need
+   to renumber the majority of interior networks altogether, but that is
+   beyond the scope of this document. At the very least, DNS hosts will
+   need to be reconfigured to resolve new host names and addresses, and
+   routers will need to be reconfigured to advertise new prefixes.
+
+   IPv6 address allocation will be managed by the Internet Assigned
+   Numbers Authority (IANA) as set forth in [15].
+
+5. Summary
+
+   As indicated by the Internet Architecture Board (IAB) in [16], the
+   task of renumbering networks is becoming more widespread and
+   commonplace.  Although there are numerous reasons why an organization
+   would desire, or be required to renumber, there are equally as many
+   reasons why address allocation should be done with great care and
+   forethought at the onset, in order to minimize the impact that
+   renumbering would have on the organization. Even with the most
+   forethought and vision, however, an organization cannot foresee the
+   possibility for renumbering. The best advice, in this case, is to be
+   prepared, and get ready for renumbering.
+
+6. Security Considerations
+
+   Although no obvious security issues are discussed in this document,
+   it stands to reason that renumbering certain devices can defeat
+   security systems designed and based on static IP host addresses.
+   Care should be exercised by the renumbering entity to ensure that all
+   security systems deployed with the network(s) which may need to be
+   renumbered be given special consideration and significant forethought
+   to provide continued functionality and adequate security.
+
+7. Acknowledgments
+
+   Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.], Tony
+   Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for their
+   contributions and editorial critique.
+
+
+
+
+
+
+Ferguson & Berkowitz         Informational                     [Page 12]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+8. References
+
+ [1] Gerich, E., "Unique Addresses are Good", RFC 1814, IAB, July 1995.
+
+ [2] Crocker, D., "To Be `On' the Internet", RFC 1775, March 1995.
+
+ [3] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J.
+     Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
+     BCP 12, RFC 2050, November 1996.
+
+ [4] Mockapetris, P., "Domain Names - Concepts and Facilities",
+     and  "Domain Names - Implementation and Specification",
+     STD 13, RFCs 1034, 1035, November 1987.
+
+ [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
+     October 1993.
+
+ [6] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
+     January 1997.
+
+ [7] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
+     Network Management Protocol (SNMP)", STD 15, RFC 1157,
+     May 1990.
+
+ [8] Egevang,, K., and P. Francis, "The IP Network Address Translator
+     (NAT)", RFC 1631, May 1994.
+
+ [9] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J., and E.
+     Lear, "Address Allocation for Private Internets", RFC 1918,
+     February 1996.
+
+ [10] Messages to PIER list on CERN renumbering; Brian Carpenter, CERN.
+      Available in PIER WG mailing list archives.
+
+ [11] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
+      Inter-Domain Routing (CIDR): an Address Assignment and
+      Aggregation Strategy", RFC 1519, October 1993.
+
+ [12] McGregor, G., "The PPP Internet Protocol Control Protocol
+      (IPCP)", RFC 1332, May 1992.
+
+ [13] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next
+      Hop Resolution Protocol (NHRP)", Work in Progress.
+
+ [14] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+      Specification", RFC 1883, December 1995.
+
+
+
+
+
+Ferguson & Berkowitz         Informational                     [Page 13]
+
+RFC 2071              Network Renumbering Overview          January 1997
+
+
+ [15] IAB and IESG, "IPv6 Address Allocation Management", RFC 1881,
+      December 1995.
+
+ [16] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900,
+      February 1996.
+
+9. Authors' Addresses
+
+   Paul Ferguson
+   cisco Systems, Inc.
+   1875 Campus Commons Road
+   Suite 210
+   Reston, VA 22091
+
+   Phone: (703) 716-9538
+   Fax: (703) 716-9599
+   EMail: pferguso@cisco.com
+
+
+   Howard C. Berkowitz
+   PSC International
+   1600 Spring Hill Road
+   Vienna, VA 22182
+
+   Phone (703) 998-5819
+   Fax:  (703) 998-5058
+   EMail:  hcb@clark.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ferguson & Berkowitz         Informational                     [Page 14]
+