draft-ietf-pier-renum-ovrvw-00.txt   draft-ietf-pier-renum-ovrvw-01.txt 
PIER Working Group P. Ferguson PIER Working Group P. Ferguson
Internet Draft cisco Systems, Inc. Internet Draft cisco Systems, Inc.
August 1996 H. Berkowitz
Expires in six months Expires in six months PSC International
Network Renumbering Overview: Network Renumbering Overview:
Why would I want it and what is it anyway? Why would I want it and what is it anyway?
draft-ietf-pier-renum-ovrvw-00.txt draft-ietf-pier-renum-ovrvw-01.txt
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 2, line 11 skipping to change at page 2, line 11
define the concept of network renumbering and discuss some of the define the concept of network renumbering and discuss some of the
more pertinent reasons why an organization would have a need to do more pertinent reasons why an organization would have a need to do
so. so.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Network Renumbering Defined. . . . . . . . . . . . . . . . . 3 3. Network Renumbering Defined. . . . . . . . . . . . . . . . . 3
4. Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3 4. Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3
5. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The popularity of connecting to the global Internet over the course The popularity of connecting to the global Internet over the course
of the past several years has spawned new problems; what most people of the past several years has spawned new problems; what most people
casually refer to as ``growing pains'' can be attributed to more casually refer to as ``growing pains'' can be attributed to more
basic problems in understanding the requirements for Internet basic problems in understanding the requirements for Internet
connectivity. However, the reasons why organizations may need to connectivity. However, the reasons why organizations may need to
renumber their networks can greatly vary. We'll discuss these issues renumber their networks can greatly vary. We'll discuss these issues
in some amount of detail below. It is not within the intended scope in some amount of detail below. It is not within the intended scope
skipping to change at page 2, line 56 skipping to change at page 3, line 5
as well as the ISP's, become more prudent in their address as well as the ISP's, become more prudent in their address
allocation strategies. In that vein, the interNIC has defined allocation strategies. In that vein, the interNIC has defined
address allocation policies [3] wherein the majority of address address allocation policies [3] wherein the majority of address
allocations for end-user networks are accommodated by their allocations for end-user networks are accommodated by their
upstream ISP, except in cases where dual- or multihoming and upstream ISP, except in cases where dual- or multihoming and
very large blocks of addresses are required. With this allocation very large blocks of addresses are required. With this allocation
policy becoming standard current practice, it presents unique policy becoming standard current practice, it presents unique
problems regarding the portability of addresses from one provider problems regarding the portability of addresses from one provider
to another. 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] 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 Also, in many instances, organizations who have never connected to
the Internet, yet have been using arbitrary blocks of addresses since the Internet, yet have been using arbitrary blocks of addresses since
their construction, have different and unique challenges. their construction, have different and unique challenges.
3. Network Renumbering Defined 3. Network Renumbering Defined
In the simplest of definitions, the exercise of renumbering a In the simplest of definitions, the exercise of renumbering a
network consists of changing the IP host addresses, and perhaps network consists of changing the IP host addresses, and perhaps
the network mask, of each device within the network that has an the network mask, of each device within the network that has an
address associated with it. This activity may or may not consist address associated with it. This activity may or may not consist
skipping to change at page 3, line 31 skipping to change at page 3, line 54
Network renumbering need not be sudden activity, either; in most Network renumbering need not be sudden activity, either; in most
instances, an organization's upstream service provider(s) will instances, an organization's upstream service provider(s) will
allow a grace period where both the ``old'' addresses and the ``new'' allow a grace period where both the ``old'' addresses and the ``new''
addresses may be used in parallel. addresses may be used in parallel.
4. Reasons for Renumbering 4. Reasons for Renumbering
The following sections discuss particular reasons which may The following sections discuss particular reasons which may
precipitate network renumbering, and are not presented in any precipitate network renumbering, and are not presented in any
particular order of precedence. 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.
A. Initial connectivity and usage of non-unique addresses 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 As recently as two years ago, many organizations had no intention
of connecting to the Internet, and constructed their corporate or of connecting to the Internet, and constructed their corporate or
organizational network(s) using unregistered, non-unique network organizational network(s) using unregistered, non-unique network
addresses. Obviously, as most problems evolve, these same addresses. Obviously, as most problems evolve, these same
organizations determined that Internet connectivity had become organizations determined that Internet connectivity had become
a valuable asset, and subsequently discovered that they could no a valuable asset, and subsequently discovered that they could no
longer use the same unregistered, non-unique network addresses longer use the same unregistered, non-unique network addresses
that were previously deployed throughout their organization. that were previously deployed throughout their organization.
Thus, the labor of renumbering to valid network addresses is Thus, the labor of renumbering to valid network addresses is
now upon them, as they move to connect to the global Internet. now upon them, as they move to connect to the global Internet.
While obtaining valid, unique addresses are certainly required While obtaining valid, unique addresses are certainly required
to obtain full Internet connectivity in most circumstances, the to obtain full Internet connectivity in most circumstances, the
number of unique addresses required can be significantly reduced number of unique addresses required can be significantly reduced
by the implementation of Network Address Translation (NAT) devices by the implementation of Network Address Translation (NAT) devices
[4] and the use of private address space, as specified in [5]. [7] and the use of private address space, as specified in [8].
NAT reduces not only the number of required unique addresses, but NAT reduces not only the number of required unique addresses, but
also localizes the changes required by renumbering. also localizes the changes required by renumbering.
It should also be noted that NAT technology may not always be It should also be noted that NAT technology may not always be
a viable option, depending upon scale of addressing, performance a viable option, depending upon scale of addressing, performance
or topological constraints. or topological constraints.
B. Change in organizational structure or network topology 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).
Appropriate replacement protocols (e.g., OSPF, EIGRP, IS-IS) will
work best with a structured addressing system that encourages
aggregation.
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.''[9] 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
multiaccess (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.
4.2.1 Change in organizational structure or network topology
As companies grow, through mergers, acquisitions and reorganizations, As companies grow, through mergers, acquisitions and reorganizations,
the need may arise for realignment and modification of the various the need may arise for realignment and modification of the various
organizational network architectures. The connectivity of disparate organizational network architectures. The connectivity of disparate
corporate networks present unique challenges in the realm of corporate networks present unique challenges in the realm of
renumbering, since one or more individual networks may have to be renumbering, since one or more individual networks may have to be
blended into a much larger architecture consisting a different IP blended into a much larger architecture consisting a different IP
address prefix altogether. Also, when a site or company makes major address prefix altogether.
changes in it's internal network topology, for whatever reason,
partial or complete renumbering may be necessary even if the network
prefix does not change.
C. Change of Internet Service Provider 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 As mentioned previously in Section 2, it is increasingly becoming
current practice for organizations to have their IP addresses current practice for organizations to have their IP addresses
allocated by their upstream ISP. Also, with the advent of Classless allocated by their upstream ISP. Also, with the advent of Classless
Inter Domain Routing (CIDR) [6], and the considerable growth in the Inter Domain Routing (CIDR) [10], and the considerable growth in the
size of the global Internet table, Internet Service Providers size of the global Internet table, Internet Service Providers
are becoming more and more reluctant to allow customers to continue are becoming more and more reluctant to allow customers to continue
using addresses which were allocated by the ISP, when the customer using addresses which were allocated by the ISP, when the customer
terminates service and moves to another ISP. The prevailing terminates service and moves to another ISP. The prevailing
reason is that the ISP was previously issued a CIDR block of reason is that the ISP was previously issued a CIDR block of
contiguous address space, which can be announced to the remainder of contiguous address space, which can be announced to the remainder of
the Internet community as a single prefix. (A prefix is what is the Internet community as a single prefix. (A prefix is what is
referred to in classless terms as a contiguous block of IP referred to in classless terms as a contiguous block of IP
addresses.) If a non-customer advertises a specific component addresses.) If a non-customer advertises a specific component
of the CIDR block, then this adds an additional routing entry to of the CIDR block, then this adds an additional routing entry to
skipping to change at page 5, line 9 skipping to change at page 8, line 5
in scope, it becomes an issue to be decided at the discretion of the 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 initial allocating entity, and the ISP's involved; the major deciding
factor being whether or not the change will fragment an existing CIDR factor being whether or not the change will fragment an existing CIDR
block and whether it will significantly contribute to the overall block and whether it will significantly contribute to the overall
growth of the global Internet routing tables. growth of the global Internet routing tables.
It should also be noted that (contrary to opinions sometimes voiced) It should also be noted that (contrary to opinions sometimes voiced)
this form of renumbering is a technically necessary consequence of this form of renumbering is a technically necessary consequence of
changing ISP's, rather than a commercial or political mandate. changing ISP's, rather than a commercial or political mandate.
D. Returning segregate prefixes for an aggregate 4.2.3 Internet Global Routing
It is not unusual for organizational networks to grow sporadically, Even large organizations, now connected to the Internet with
obtaining an address prefix here and there, in a non-contiguous ``portable'' address space, may find their address allocation too
fashion. Depending on the number of prefixes that an organization small. Current registry guidelines require that address space usage
acquires over time, it may become increasingly unmanageable or demand be justified by an engineering plan. Older networks may not have
higher levels of maintenance and administration when individual efficiently utilized existing address space, and may need to make
prefixes are acquired in this way. In many instances, an their existing structures more efficient before new address
organization can return their current, non-contiguous prefix allocations can be made.
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. This is also
a highly encouraged method to help in reducing the size of the global
routing table.
E. Transitioning to IP version 6 4.2.4 Internal Use of LAN Switching
Of course, when IPv6 [7] deployment is set in motion, and as 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 ``color''
VLAN will not cause major changes in addressing. Many overview
presentations 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 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:
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.
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) [11]. 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 segregate 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
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) [12]. 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.
4.3.2 Transitioning to IP version 6
Of course, when IPv6 [13] deployment is set in motion, and as
methodologies are developed to transition to IPv6, renumbering will methodologies are developed to transition to IPv6, renumbering will
also be necessary, but perhaps not immediately mandatory. To aid also be necessary, but perhaps not immediately mandatory. To aid
in the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6 in the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6
stacks on network hosts should also become available. It is also stacks on network hosts should also become available. It is also
envisioned that Network Address Translation (NAT) devices will be envisioned that Network Address Translation (NAT) devices will be
developed to assist in the IPv4 to IPv6 transition, or perhaps developed to assist in the IPv4 to IPv6 transition, or perhaps
supplant the need to renumber the majority of interior networks supplant the need to renumber the majority of interior networks
altogether, but that is beyond the scope of this document. At the altogether, but that is beyond the scope of this document. At the
very least, DNS hosts will need to be reconfigured to resolve new very least, DNS hosts will need to be reconfigured to resolve new
host names and addresses, and routers will need to be reconfigured host names and addresses, and routers will need to be reconfigured
to advertize new prefixes. to advertise new prefixes.
IPv6 address allocation will be managed by the Internet Assigned IPv6 address allocation will be managed by the Internet Assigned
Numbers Authority (IANA) as set forth in [8]. Numbers Authority (IANA) as set forth in [14].
F. 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.
5. Summary 5. Summary
As indicated by the Internet Architecture Board (IAB) in [9], As indicated by the Internet Architecture Board (IAB) in [15],
the task of renumbering networks is becoming more widespread the task of renumbering networks is becoming more widespread
and commonplace. Although there are numerous reasons why an and commonplace. Although there are numerous reasons why an
organization would desire, or be required to renumber, there are organization would desire, or be required to renumber, there are
equally as many reasons why address allocation should be done with equally as many reasons why address allocation should be done with
great care and forethought at the onset, in order to minimize the great care and forethought at the onset, in order to minimize the
impact that renumbering would have on the organization. Even impact that renumbering would have on the organization. Even
with the most forethought and vision, however, an organization with the most forethought and vision, however, an organization
cannot foresee the possibility for renumbering. The best advice, cannot foresee the possibility for renumbering. The best advice,
in this case, is to be prepared, and get ready for renumbering. in this case, is to be prepared, and get ready for renumbering.
skipping to change at page 6, line 36 skipping to change at page 12, line 26
and significant forethought to provide continued functionality and significant forethought to provide continued functionality
and adequate security. and adequate security.
7. Acknowledgments 7. Acknowledgments
Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.], Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.],
Tony Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for Tony Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for
their contributions and editorial critique. their contributions and editorial critique.
8. References 8. References
[3] Work in Progress; ``INTERNET REGISTRY IP ALLOCATION GUIDELINES'', [3] Work in Progress; ``INTERNET REGISTRY IP ALLOCATION GUIDELINES'';
K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg; K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg;
draft-hubbard-registry-guidelines-01.txt August 1996; draft-hubbard-registry-guidelines-05.txt
[4] RFC-1631, ``The IP Network Address Translator (NAT)''; K. Egevang, [4] RFC-1034, ``Domain Names - Concepts and Facilities'';
[5] RFC-1918, ``Address Allocation for Private Internets''; Y. Rekhter, P. Mockapetris, November 1987;
RFC-1035, ``Domain Names - Implementation and Specification'';
P. Mockapetris, November 1987
[5] RFC-1541, ``Dynamic Host Configuration Protocol''; R. Droms,
October 1993
[6] Work in Progress, ``Router Renumbering Guide''; H. Berkowitz;
June 1996; draft-ietf-pier-rr-01.txt
[7] RFC-1631, ``The IP Network Address Translator (NAT)''; K. Egevang,
[8] RFC-1918, ``Address Allocation for Private Internets''; Y. Rekhter,
R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996
[6] RFC-1519, ``Classless Inter-Domain Routing (CIDR): an Address [9] Messages to PIER list on CERN renumbering; Brian Carpenter, CERN.
Available in PIER WG mailing list archives.
[10] RFC-1519, ``Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy''; V. Fuller, T. Li, J. Yu, Assignment and Aggregation Strategy''; V. Fuller, T. Li, J. Yu,
K. Varadhan; October 1993 K. Varadhan; October 1993
[7] RFC-1883, ``Internet Protocol, Version 6 (IPv6) Specification''; [11] RFC-1332, ``The PPP Internet Protocol Control Protocol (IPCP)'';
[12] Work in Progress; ``NBMA Next Hop Resolution Protocol (NHRP)'';
J. Luciani, D. Katz, D. Piscitello, B. Cole; July 1996;
draft-ietf-rolc-nhrp-09.txt
[13] RFC-1883, ``Internet Protocol, Version 6 (IPv6) Specification'';
S. Deering, R. Hinden; December 1995 S. Deering, R. Hinden; December 1995
[8] RFC-1881, ``IPv6 Address Allocation Management''; IAB + IESG;
[14] RFC-1881, ``IPv6 Address Allocation Management''; IAB + IESG;
December 1995 December 1995
[9] RFC-1900, ``Renumbering Needs Work''; B. Carpenter, Y. Rekhter; [15] RFC-1900, ``Renumbering Needs Work''; B. Carpenter, Y. Rekhter;
IAB; February 1996 IAB; February 1996
9. Author's Address 9. Author's Address
Paul Ferguson Paul Ferguson
cisco Systems, Inc. cisco Systems, Inc.
1875 Campus Commons Road 1875 Campus Commons Road
Suite 210 Suite 210
Reston, VA 22091 Reston, VA 22091
Phone: (703) 716-9538 Phone: (703) 716-9538
Fax: (703) 716-9599 Fax: (703) 716-9599
EMail: pferguso@cisco.com 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
 End of changes. 26 change blocks. 
62 lines changed or deleted 359 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/