As per Relevance of the word organization, we have this rfc below:
Network Working Group P.
Request for Comments: 2071 cisco Systems, Inc
Category: Informational H.
PSC
January 1997
Network Renumbering Overview
Why would I want it and what is it anyway
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The PIER [Procedures for Internet/Enterprise Renumbering]
group is compiling a series of documents to assist and
organizations in their efforts to renumber. However, it is
apparent that, with the increasing number of new Internet
Providers (ISP's) and organizations getting connected to the
for the first time, the concept of network renumbering needs to
further defined. This document attempts to clearly define
concept of network renumbering and discuss some of the more
reasons why an organization would have a need to do so
Table of
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.
The popularity of connecting to the global Internet over the
of the past several years has spawned new problems; what most
casually refer to as "growing pains" can be attributed to more
problems in understanding the requirements for Internet connectivity
However, the reasons why organizations may need to renumber
networks can greatly vary. We'll discuss these issues in some
of detail below. It is not within the intended scope of
document to discuss renumbering methodologies, techniques, or tools
2.
The ability for any network or interconnected devices, such
desktop PCs or workstations, to obtain connectivity to any
destination in the global Internet is reliant upon the possession
unique IP host addresses [1]. A duplicate host address that is
used elsewhere in the Internet could best be described
problematic, since the presence of duplicate addresses would
one of the destinations to be unreachable from some origins in
Internet. It should be noted, however, that globally unique
addresses are not always necessary, and is dependent on
connectivity requirements [2].
However, the recent popularity in obtaining Internet connectivity
made these types of connectivity dependencies unpredictable,
conventional wisdom in the Internet community dictates that
various address allocation registries, such as the InterNIC, as
as the ISP's, become more prudent in their address
strategies. In that vein, the InterNIC has defined
allocation policies [3] wherein the majority of address
for end-user networks are accommodated by their upstream ISP,
in cases where dual- or multihoming and very large blocks
addresses are required. With this allocation policy
standard current practice, it presents unique problems regarding
portability of addresses from one provider to another
As a practical matter, end users cannot assume they "own"
allocations, if their intention is to be to have full connectivity
the global Internet. Rather, end users will "borrow" part of
address space of an upstream provider's allocation. The
provider block from which their space is suballocated will have
assigned in a manner consistent with global Internet routing
Not having "permanent" addresses does not mean users will not
unique identifiers. Such identifiers are typically Domain Name
(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,
well as the 'borrowed' addresses required for routing-
connectivity
The PIER Working Group is developing procedures and guidelines
detailed renumbering of specific technologies, such as routers [6].
PIER WG documents are intended to suggest methods both for
existing networks prepared for convenient renumbering, as well as
operational transition to new addressing schemes
Also, in many instances, organizations who have never connected
the Internet, yet have been using arbitrary blocks of addresses
their construction, have different and unique challenges
3. Network Renumbering
In the simplest of definitions, the exercise of renumbering a
consists of changing the IP host addresses, and perhaps the
mask, of each device within the network that has an
associated with it. This activity may or may not consist of
networks within a particular domain, such as FOO.EDU, or
which comprise an entire autonomous system
Devices which may need to be renumbered, for example, are
PC's, workstations, printers, file servers, terminal servers,
routers. Renumbering a network may involve changing host
and configuration files which contain IP addresses, such
configuration files which contain addresses of DNS and other servers
addresses contained in SNMP [7] management stations, and
configured in access control lists. While this is not an all
inclusive list, the PIER working group is making efforts to
documentation to identify these devices in a more detailed fashion
Network renumbering need not be sudden activity, either; in
instances, an organization's upstream service provider(s) will
a grace period where both the "old" addresses and the "new"
may be used in parallel
4. Reasons for
The following sections discuss particular reasons which
precipitate network renumbering, and are not presented in
particular order of precedence. They are grouped into reasons
primarily reflect decisions made in the past,
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'
mission, such as a need to communicate with business partners, or
work efficiently in a global Internet. Other requirements
changes in network technologies
4.1
Many organizations implemented IP-based networks not for
to the Internet, but simply to make use of effective
communications mechanisms. These organizations subsequently
valid reasons to connect to other organizations or the Internet
general, but found the address structures they chose
with overall Internet practice
Other organizations connected early to the Internet, but did so at
time when address space was not scarce. Yet other
still have no requirement to connect to the Internet, but have
addressing structures that do not scale to adequate size
4.1.1 Initial addressing using non-unique
As recently as two years ago, many organizations had no intention
connecting to the Internet, and constructed their corporate
organizational network(s) using unregistered, non-unique
addresses. Obviously, as most problems evolve, these
organizations determined that Internet connectivity had become
valuable asset, and subsequently discovered that they could no
use the same unregistered, non-unique network addresses that
previously deployed throughout their organization. Thus, the
of renumbering to valid network addresses is now upon them, as
move to connect to the global Internet
While obtaining valid, unique addresses is certainly required
obtain full Internet connectivity in most circumstances, the
of unique addresses required can be significantly reduced by
implementation of Network Address Translation (NAT) devices [8]
the use of private address space, as specified in [9]. NAT
not only the number of required unique addresses, but also
the changes required by renumbering
It should also be noted that NAT technology may not always be
viable option, depending upon scale of addressing, performance
topological constraints
Ferguson & Berkowitz Informational [Page 4]
RFC 2071 Network Renumbering Overview January 1997
4.1.2 Legacy address
There are also several instances where organizations were
allocated very large amounts of address space, such as
"Class A" or "Class B" allocations, while the actual
requirements are much less than the total amount of address
originally allocated. In many cases, these organizations
suffice with a smaller CIDR allocation, and utilize the
address space in a more efficient manner. As allocation
become more stringent, mechanisms to review how these
are utilizing their address space could, quite possibly, result in
request to return the original allocation to a particular
and renumber with a more appropriately sized address block
4.1.3 Limitations of Bridged
Bridging has a long and distinguished history in legacy networks.
networks grow, however, traditional bridged networks
performance- and stability-related limits, including (but not
to) broadcast storms
Early routers did not have the speed to handle the needs of
large networks. Some organizations were literally not able to
to routers until router forwarding performance improved to
comparable to bridges. Now that routers are of comparable
superior speed, and offer more robust features, replacing
networks becomes reasonable
IP addresses assigned to pure bridged networks tend not to
subnetted, yet subnetting is a basic approach for router networks
Introducing subnetting is a practical necessity in moving
bridging to routing
Special cases of bridging are realized in workgroup
systems, discussed below
4.1.4 Limitations of Legacy Routing
Other performance problems might come from routing mechanisms
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
aggregation
Ferguson & Berkowitz Informational [Page 5]
RFC 2071 Network Renumbering Overview January 1997
4.1.5 Limitations of System Administration
There can be operational limits to growth based on the difficulty
adds, moves and changes. As enterprise networks grow, it may
necessary to delegate portions of address assignment and maintenance
If address space has been assigned randomly or inefficiently, it
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-
fashion. Depending on the number of prefixes that an
acquires over time, it may become increasingly unmanageable or
higher levels of maintenance and administration when
prefixes are acquired in this way
Reasonable IP address management may in general simplify
system administration; a good numbering plan is also a
renumbering plan. Renumbering may force a discipline into
administration that will reduce long-term support costs
It has been observed "...there is no way to renumber a
without an inventory of the hosts (absent DHCP). On a large
that needs a database, plus tools and staff to maintain
database."[10] It can be argued that a detailed inventory of
configurations is even more essential
4.2
Organizations now face needs to connect to the global Internet, or
a minimum to other organizations through bilateral private links
Certain new transmission technologies have tended to redefine
basic notion of an IP subnet. An IP numbering plan needs to
with these new ideas. Legacy bridged networks and leading-
workgroup switched networks may very well need changes in
subnetting structure. Renumbering needs may also develop due to
characteristics of new WAN technologies, especially
multi-access (NBMA) services such as Frame-Relay and
Transfer Mode (ATM).
Increased use of telecommuting by mobile workers, and in small
home offices, need on-demand WAN connectivity, using modems or ISDN
Effective use of demand media often requires changes in numbering
routing
Ferguson & Berkowitz Informational [Page 6]
RFC 2071 Network Renumbering Overview January 1997
4.2.1 Change in organizational structure or network
As companies grow, through mergers, acquisitions and reorganizations
the need may arise for realignment and modification of the
organizational network architectures. The connectivity of
corporate networks present unique challenges in the realm
renumbering, since one or more individual networks may have to
blended into a much larger architecture consisting a different
address prefix altogether
4.2.2 Inter-Enterprise
Even if they do not connect to the general Internet, enterprises
interconnect to other organizations which have independent
systems. Such connectivity can be as simple as bilateral
circuits. If both enterprises use unregistered or private
space, they run the risk of using duplicate addresses
In such cases, one or both organizations may need to renumber
different parts of the private address space, or obtain
registered addresses
4.2.3 Change of Internet Service
As mentioned previously in Section 2, it is increasingly
current practice for organizations to have their IP
allocated by their upstream ISP. Also, with the advent of
Inter Domain Routing (CIDR) [11], and the considerable growth in
size of the global Internet table, Internet Service Providers
becoming more and more reluctant to allow customers to continue
addresses which were allocated by the ISP, when the
terminates service and moves to another ISP. The prevailing
is that the ISP was previously issued a CIDR block of
address space, which can be announced to the remainder of
Internet community as a single prefix. (A prefix is what is
to in classless terms as a contiguous block of IP addresses.) If
non-customer advertises a specific component of the CIDR block,
this adds an additional routing entry to the global Internet
table. This is what is commonly referred to as "punching holes" in
CIDR block. Consequently, there are usually no routing anomalies
doing this since a specific prefix is always preferred over
aggregate route. However, if this practice were to happen on a
scale, the growth of the global routing table would become
larger, and perhaps too large for current backbone routers
accommodate in an acceptable fashion with regards to performance
recalculating routing information and sheer size of the routing
itself. For obvious reasons, this practice is highly discouraged
ISP's with CIDR blocks, and some ISP's are making this a
Ferguson & Berkowitz Informational [Page 7]
RFC 2071 Network Renumbering Overview January 1997
issue, so that customers understand that addresses allocated by
ISP are non-portable
It is noteworthy to mention that the likelihood of being forced
renumber in this situation is inversely proportional to the size
the customer's address space. For example, an organization with
/16 allocation may be allowed to consider the address
"portable", while an organization with multiple non-contiguous /24
allocations may not. While the scenarios may be vastly different
scope, it becomes an issue to be decided at the discretion of
initial allocating entity, and the ISP's involved; the major
factor being whether or not the change will fragment an existing
block and whether it will significantly contribute to the
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
changing ISP's, rather than a commercial or political mandate
4.2.3 Internet Global
Even large organizations, now connected to the Internet
"portable" address space, may find their address allocation
small. Current registry guidelines require that address space
be justified by an engineering plan. Older networks may not
efficiently utilized existing address space, and may need to
their existing structures more efficient before new
allocations can be made
4.2.4 Internal Use of LAN
Introducing workgroup switches may introduce subtle
needs. Fundamentally, workgroup switches are specialized, high
performance bridges, which make their main forwarding decisions
on Layer 2 (MAC) address information. Even so, they rarely
independent of Layer 3 (IP) address structure. Pure Layer 2
switching has a "flat" address space that will need to be
into a hierarchical, subnetted space consistent with routing
Introducing single switches or stacks of switches may not
significant impact on addressing, as long as it is understood
each system of switches is a single broadcast domain. Each
domain should map to a single IP subnetwork
Virtual LANs (VLANs) further extend the complexity of the role
workgroup switches. It is generally true that moving an end
from one switch port to another within the same VLAN will not
major changes in addressing. Many overview presentations of
Ferguson & Berkowitz Informational [Page 8]
RFC 2071 Network Renumbering Overview January 1997
technology do not make it clear that moving the same end
between different VLANs will move the end station into another
subnet, requiring a significant address change
Switches are commonly managed by SNMP applications. These
management applications communicate with managed devices using IP
Even if the switch does not do IP forwarding, it will itself need
addresses if it is to be managed. Also, if the clients and servers
the workgroup are managed by SNMP, they will also require
addresses. The workgroup, therefore, will need to appear as one
more IP subnetworks
Increasingly, internetworking products are not purely Layer 2
Layer 3 devices. A workgroup switch product often includes a
function, so the numbering plan must support both flat Layer 2
hierarchical Layer 3 addressing
4.2.4 Internal Use of NBMA Cloud
"Cloud" services such as frame relay often are more economical
traditional services. At first glance, when converting
enterprise networks to NBMA, it might appear that the existing
structure should be preserved, but this is often not the case
Many organizations often began by treating the "cloud" as a
subnet, but experience has shown it is often better to treat
individual virtual circuits as separate subnets, which appear
traditional point-to-point circuits. When the individual point-to
point VCs become separate subnets, efficient address
requires the use of long prefixes (i.e., 30 bit) for these subnets
In practice, obtaining 30 bit prefixes means the logical
should support variable length subnet masks (VLSM). VLSMs are
primary method in which an assigned prefix can be
efficiently for different media types. This is accomplished
establishing one or more prefix lengths for LAN media with more
two hosts, and subdividing one or more of these shorter prefixes
longer /30 prefixes that minimize address loss
There are alternative ways to configure routing over NBMA,
special mechanisms to exploit or simulate point-to-multipoint VCs
These often have a significant performance impact, and may be
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
rather than technology
2. Router implementation issues that limit the number of
or interfaces a given router can support
3. An inherently point-to-multipoint application (e.g.,
hosts to a data center). In such cases, some of
limitations are due to the dynamic routing protocol in use
In such "hub-and-spoke" implementations, static routing
be preferable from a performance and flexibility standpoint
since it does not produce routing protocol chatter and
unaffected by split horizon constraints (namely, the
to build an adjacency with a peer within the same
subnetwork).
4.2.5 Expansion of Dialup
Dialup services, especially public Internet access providers,
experiencing explosive growth. This success represents a
drain on the available address space, especially with a commonly
practice of assigning unique addresses to each customer
In this case, individual users announce their address to the
server using PPP's IP control protocol (IPCP) [12]. The server
validate the proposed address against some type of
identification, or simply make the address active in a subnet
which the access server (or set of bridged access servers) belongs
The preferred technique is to allocate dynamic addresses to the
from a pool of addresses available to the access server
4.2.6 Returning non-contiguous prefixes for an
In many instances, an organization can return their current, non
contiguous prefix allocations for a contiguous block of address
of equal or greater size, which can be accommodated with CIDR. Also
many organizations have begun to deploy classless interior
protocols within their domains that make use of route
and other optimized routing features, effectively reducing the
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
address assignment of a given network reflects the topology, and
topology of the network can often be fluid. Given that the network
fluid, even the best planned address assignment scheme, given time
will diverge from the actual topology. While not required,
Ferguson & Berkowitz Informational [Page 10]
RFC 2071 Network Renumbering Overview January 1997
organization may choose to gain the benefit of both technical
administrative scalability of their IGP by periodically
to have address assignments reflect the network topology.
Henry once said "the tree of liberty must from time to time
watered with the blood of patriots." In the Internet, routing
of the best-planned networks need from time to time be watered
at least the sweat of network administrators. Improving
is also highly encouraged to reduce the size of not only the
Internet routing table, but also the size and scalability of
routing within the enterprise
4.3
Emerging new protocols will most definitely affect addressing
and numbering schemes
4.3.1 Internal Use of Switched Virtual Circuit
Services such as ATM virtual circuits, switched frame relay, etc.,
present challenges not considered in the original IP design.
basic IP decision in forwarding a packet is whether the
is local or remote, in relation to the source host's subnet.
resolution mechanisms are used to find the medium address of
destination in the case of local destinations, or to find the
address of the router in the case of remote routers
In these new services, there are cases where it is far more
to "cut-through" a new virtual circuit to the destination. If
destination is on a different subnet than the source, the cut-
typically is to the egress router that serves the destination subnet
The advantage of cut-through in such a case is that it avoids
latency of multiple router hops, and reduces load on "backbone
routers. The cut-through decision is usually made by an entry
that is aware of both the routed and switched environments
This entry router communicates with a address resolution server
the Next Hop Resolution Protocol (NHRP) [13]. This server maps
destination network address to either a next-hop router (where cut
through is not appropriate) or to an egress router reached over
switched service. Obviously, the data base in such a server may
affected by renumbering. Clients may have a hard-coded address of
server, which again may need to change. While the NHRP
specifications are still evolving at the time of this writing
commercial implementations based on drafts of the protocol
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
methodologies are developed to transition to IPv6, renumbering
also be necessary, but perhaps not immediately mandatory. To aid
the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6
on network hosts should also become available. It is also
that Network Address Translation (NAT) devices will be developed
assist in the IPv4 to IPv6 transition, or perhaps supplant the
to renumber the majority of interior networks altogether, but that
beyond the scope of this document. At the very least, DNS hosts
need to be reconfigured to resolve new host names and addresses,
routers will need to be reconfigured to advertise new prefixes
IPv6 address allocation will be managed by the Internet
Numbers Authority (IANA) as set forth in [15].
5.
As indicated by the Internet Architecture Board (IAB) in [16],
task of renumbering networks is becoming more widespread
commonplace. Although there are numerous reasons why an
would desire, or be required to renumber, there are equally as
reasons why address allocation should be done with great care
forethought at the onset, in order to minimize the impact
renumbering would have on the organization. Even with the
forethought and vision, however, an organization cannot foresee
possibility for renumbering. The best advice, in this case, is to
prepared, and get ready for renumbering
6. Security
Although no obvious security issues are discussed in this document
it stands to reason that renumbering certain devices can
security systems designed and based on static IP host addresses
Care should be exercised by the renumbering entity to ensure that
security systems deployed with the network(s) which may need to
renumbered be given special consideration and significant
to provide continued functionality and adequate security
7.
Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.],
Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for
contributions and editorial critique
Ferguson & Berkowitz Informational [Page 12]
RFC 2071 Network Renumbering Overview January 1997
8.
[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
Network Management Protocol (SNMP)", STD 15, RFC 1157,
May 1990.
[8] Egevang,, K., and P. Francis, "The IP Network Address
(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, "
Inter-Domain Routing (CIDR): an Address Assignment
Aggregation Strategy", RFC 1519, October 1993.
[12] McGregor, G., "The PPP Internet Protocol Control
(IPCP)", RFC 1332, May 1992.
[13] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA
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'
Paul
cisco Systems, Inc
1875 Campus Commons
Suite 210
Reston, VA 22091
Phone: (703) 716-9538
Fax: (703) 716-9599
EMail: pferguso@cisco.
Howard C.
PSC
1600 Spring Hill
Vienna, VA 22182
Phone (703) 998-5819
Fax: (703) 998-5058
EMail: hcb@clark.
Ferguson & Berkowitz Informational [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
