Enterprise Renumbering: Experience and Information Solicitation
Gathering real-world experiences about changing enterprise network addresses.
Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser, "Enterprise Renumbering: Experience and Information Solicitation", RFC 1916, DOI 10.17487/RFC1916, February 1996, <https://www.rfc-editor.org/info/rfc1916>.
@misc{rfc1916,
series = {Request for Comments},
number = 1916,
howpublished = {RFC 1916},
publisher = {RFC Editor},
doi = {10.17487/RFC1916},
url = {https://www.rfc-editor.org/info/rfc1916},
author = {H. Berkowitz and P. Ferguson and W. Leland and P. Nesser},
title = {{Enterprise Renumbering: Experience and Information Solicitation}},
pagetotal = 8,
year = 1996,
month = feb,
} RFC text
Contents
Network Working Group H. Berkowitz
Request for Comments: 1916 PSC International
Category: Informational P. Ferguson
cisco Systems, Inc.
W. Leland
Bellcore
P. Nesser
Nesser & Nesser Consulting
February 1996
Enterprise Renumbering: Experience and Information Solicitation
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
Because of the urgent need for, and substantial difficulty in,
renumbering IP networks, the PIER working group is compiling a series
of documents to assist sites in their renumbering efforts. The
intent of these documents is to provide both educational and
practical information to the Internet community. To this end the
working group is soliciting information from organizations that
already have gone through, or are in the process of going through,
renumbering efforts. Case studies, tools, and lists of applications
that require special attention are sought.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Renumbering Experience . . . . . . . . . . . . . . . . . . . 4
3. Information on Tools . . . . . . . . . . . . . . . . . . . . 5
4. Application Information . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . 6
6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7
A. Formatting Rules (from RFC 1543) . . . . . . . . . . . . . . 8
1. Introduction
There are immediate and increasingly severe requirements to renumber
both small and large-scale networks. The Procedures for
Internet/Enterprise Renumbering (PIER) working group in the IETF
urgently requests specific input for producing concrete guidance for
the renumbering task as quickly as possible. As part of collecting
such information, the PIER working group therefore is soliciting
input from people and organizations with experience in changing the
IP addresses of enterprise networks or in making major changes in the
subnetting of existing networks. We are especially interested in
actual case studies -- that is, accounts describing what was actually
done to renumber one or more networks. Information is also solicited
on specific tools used in the process, and on areas in which tools
were needed but not available. Because applications that use IP
addresses directly in their configuration or security mechanisms pose
specific difficulties and coordination issues for renumbering, a
catalogue of such applications is being compiled.
All interested parties are invited to submit material in any of these
areas:
A) Accounts of the experience of renumbering networks:
-- Retrospective reports on renumbering efforts.
-- Journals or running accounts of a renumbering effort, written
while the task is underway.
B) Information on tools to help renumbering:
-- Descriptions of tools used, whether commercial, freeware, or ad
hoc (such as perl scripts).
-- Descriptions of specific needs where a tool could clearly have
helped, but none was found.
C) Information on applications using embedded IP addresses:
-- Software applications that use embedded IP addresses for security
keys, authentication, or any other "inappropriate" purposes.
-- Hardware devices whose IP addresses are hardcoded into the
hardware design (and so may require extensive time lags to
retool).
-- Both software and hardware whose vendors are no longer in business
and that may require replacement or specialized solutions.
The focus of this solicitation is on experience with renumbering that
has been done or is now underway in IPv4 networks, and not on future
changes to protocols or environments that may eventually be useful.
We are especially concerned with the most common situation faced
today: single-homed networks that are not transit providers. However,
experience with renumbering more complex environments is also
welcome.
The information provided will be used as an information base from
which at least three documents will be composed: a document
summarizing the processes to follow when renumbering, a document
describing the available tools, and a document containing a list of
known applications requiring special attention when renumbering. The
information will also be available on the PIER home page,
http://www.isi.edu/div7/pier. More specific reports on renumbering
particular environments may also be produced in those cases where
enough information is received from the community.
Although our emphasis is on technical issues and responses, solidly
based advice on smoothing the human problems is also appreciated.
Political and cultural sensitivities, and handling them, are major
issues in the real world.
There is no requirement that a formal document be submitted, although
with the permission of the submitter, selected accounts of experience
in renumbering will be published by PIER as part of their planned
series of case studies. If you wish to have your account released as
a PIER case study, please follow the standard RFC format described in
RFC 1543, "Instructions to RFC Authors". (For convenience, these
formatting rules are given in Appendix A below.)
The people and organization(s) involved and the network(s) renumbered
need not be identified in any document made public by PIER: please
explicitly indicate if a submission should have its anonymity
protected.
The deadline for the submission of your information is May 15, 1996,
though early submission is encouraged. Any information, however
informally written, that can be submitted earlier, would be greatly
appreciated and will help shape the further work of the PIER group.
In particular, if you expect to submit a detailed write-up by May 15,
1996, please let us know as soon as possible.
Please send submissions, questions, or suggestions to the PIER
discussion list, pier@isi.edu.
To subscribe to the PIER discussion list, please send your request to
pier-request@isi.edu. Further information on PIER is available on the
PIER home page, http://www.isi.edu/div7/pier.
Mail may also be sent directly to the editors, without its appearing
on the PIER list, by sending to pier-solicit@bellcore.com.
2. Renumbering Experience
An account of a renumbering effort should provide enough concrete
information, based on actual experience, so that the reader can
understand exactly what was done. Broadly speaking, we anticipate two
styles of account:
i) Retrospective reports
Based on one or more renumbering efforts, recapitulate what was
done and what was learned in the effort. Such a report should
describe:
-- The environment being renumbered.
-- The planning undertaken.
-- What was done.
-- What worked.
-- What didn't (unanticipated issues, problems with planned
approaches).
In addition, the report would be even more useful if it also
addressed:
-- The reasons for taking the approach chosen.
-- Any alternative approaches that were rejected, and why.
-- What could have been done in advance to make the task easier.
-- Lessons learned: how would you do it next time?
It is hoped that individuals and organizations that have already
been through a renumbering effort could quickly look back over
their experiences, and capture their knowledge.
ii) Running accounts
Many people are in the midst of a renumbering effort, or are about
to embark on one in the next few months. If, in the midst of that
hectic task, one could write down a brief account or "diary" of
what actually happens, as it happens, such a report is likely to
capture the glitches and fixes of even the best-planned effort
more accurately than any retrospective.
Of course, these are only rough categories: any record of the
experience of renumbering or of information gained by such experience
can be a valuable contribution to PIER. When submitting accounts of
renumbering efforts, please attempt to be as articulate and concise
as possible.
3. Information on Tools
Information on the tools that were used in renumbering is valuable,
whether provided as a separate note or as part of an account of a
renumbering effort. We welcome comments, however detailed or brief,
on any tools that helped with renumbering, whether or not you intend
to produce an account of the entire renumbering effort.
Some areas in which tools may be used in renumbering include:
-- Identifying what needs to be changed in your network, such as
configuration files, hosts and servers with embedded or cached IP
addresses, DNS, access control lists (ACLs), firewalls, routers,
license servers, and other applications.
-- Identifying external factors (such as remote servers, routers, and
Internet registries) that need to be updated to accommodate your
new numbers.
-- Identifying dependencies between the different places where the
numbers must be updated.
-- Notifying external agents.
-- Generating the new information (such as routing, configuration,
and ACLs) required in order to carry out the updates.
-- Coordinating updates.
-- Making the updates.
-- Verifying the updates.
-- Trouble-shooting and debugging.
-- Maintaining network functionality.
-- Informing your users and other affected human beings (such as NOC
staff) of the changes.
The most useful tools are those that are, or can be, available to
other renumbering efforts. For a given tool, it would be helpful to
describe:
-- How to obtain it (if not a well-known tool).
-- What you used it for.
-- How you used it.
-- What its strengths and limitations are for these specific uses.
If a tool was created as part of the renumbering effort, a
description of exactly what it does should be included. (For example,
a script to check for IP addresses in configuration files on user
machines should be described in terms of just what it did to obtain
the list of machines, what files it looked for, and how it checked
them.)
Although the primary goal of this solicitation is to learn what tools
exist and are useful, we also value specific, experience-based
descriptions of ways in which tools could have helped even though
nothing was available during the renumbering to perform these
functions. Advisories on tools that appear to be useful but in
practice created further problems may also be considered, as
appropriate.
4. Application Information
Information on applications that require special attention when
renumbering are of particular interest, since specialized
applications are among the most difficult aspects of renumbering. It
typically requires special intervention with the vendor to provide
new security keys, new license addresses, new versions of
applications, or perhaps even new hardware or proms to change the
hardcoded IP addresses.
A list of any such applications that required "extra" efforts during
the renumbering process is valuable. Please include as much specific
information as possible, including but not limited to: application
name, version, platform, vendor, operating system, operating system
version, the steps taken to overcome the problem, and lead times
needed.
In particular, any applications that are no longer supported, or
whose vendor has ceased to do business, are extremely important since
these applications will likely be some of the more difficult issues a
renumbering effort will encounter. Any solutions to these types of
problems, including replacement applications and proprietary
solutions, are also sought.
5. Security Considerations
This RFC raises no security issues, although accounts of renumbering
are encouraged to describe any security issues encountered, any tools
that helped identify or resolve the issues, and the actions taken to
address them. Submissions should give serious consideration to the
content and context of issues regarding security.
6. Authors' Addresses
Howard C. Berkowitz
PSC International
8260 Greensboro Drive, Suite 330
McLean, VA 22102
Phone: (703) 998-5819
Fax: (703) 998-5058
EMail: hcb@clark.net
Paul Ferguson
cisco Systems, Inc.
1835 Alexander Bell Drive
Suite 100
Reston, VA 22091
Phone: (703) 716-9538
Fax: (703) 716-9538
EMail: pferguso@cisco.com
Will E. Leland
Room 1A-228B
Bellcore
445 South Street
Morristown, NJ 07960-6438
Phone: (201) 829-4376
Fax: (201) 829-2504
EMail: wel@bellcore.com
Philip J. Nesser II
Nesser & Nesser Consulting
16015 84th Ave. NE
Bothell, WA 98011
Phone: (206) 488-6268
EMail: pjnesser@rocket.com
Appendix A - Formatting Rules (from RFC 1543)
Note: there are a set of NROFF formatting macros for the following
format. Please contact pier-solicit@bellcore.com if you would like
to get a copy.
3a. ASCII Format Rules
The character codes are ASCII.
Each page must be limited to 58 lines followed by a form feed on a
line by itself.
Each line must be limited to 72 characters followed by carriage
return and line feed.
No overstriking (or underlining) is allowed.
These "height" and "width" constraints include any headers, footers,
page numbers, or left side indenting.
Do not fill the text with extra spaces to provide a straight right
margin.
Do not do hyphenation of words at the right margin.
Do not use footnotes. If such notes are necessary, put them at the
end of a section, or at the end of the document.
Use single spaced text within a paragraph, and one blank line between
paragraphs.
Note that the number of pages in a document and the page numbers on
which various sections fall will likely change with reformatting.
Thus cross references in the text by section number usually are
easier to keep consistent than cross references by page number.
AI ELI5
On this page
§1Why Renumbering Happens
As the Internet expanded rapidly in the 1990s, many organizations found themselves needing to change the IP addresses of their entire networks. This might happen because they changed Internet service providers, got allocated different address space by a registry, or needed to restructure their addressing plan. Renumbering is technically challenging and disruptive: every router, server, workstation, and application with an embedded IP address must be updated, usually with careful coordination to avoid service interruption.
The PIER working group (Procedures for Internet/Enterprise Renumbering) of the IETF recognized the urgent need for practical guidance and decided to collect real-world experience from organizations that had already renumbered or were in the process.
When you change address spaces, everything with an old address breaks. Nobody had written down the tricks yet, so the PIER group asked: 'Who's done this? What happened?'
§2What People Needed
Organizations renumbering their networks faced three major challenges. First, identifying what needed to change: not just routers and servers, but configuration files, DNS records, access control lists, license servers, and applications with hardcoded IP addresses. Second, coordinating external updates with ISPs, DNS registries, and other internet registries. Third, managing the human side: notifying staff, handling special cases, and troubleshooting unexpected failures.
The PIER group wanted to collect concrete case studies describing exactly what was done, what worked, what didn't, and what lessons applied to the next renumbering effort.
It's not just changing one thing—it's finding all the hidden places where addresses are locked in, telling everyone about the change, and fixing problems as they happen.
§3Three Types of Information Sought
The group solicited three categories of information. Renumbering experience: accounts of successful or in-progress efforts, including what was planned, what was done, what went wrong, and lessons for next time. Tool information: descriptions of scripts, software, or hardware tools used to discover what needed changing, generate new configurations, coordinate updates, or verify the results. Application information: lists of specific software or hardware that required special handling—products with hardcoded addresses, vendors no longer in business, or applications needing security key updates.
RFC 1916 emphasized that technical advice was welcome, but so was guidance on managing the human and political dimensions of major network changes.
They asked for three things: stories of how people did it, tools that helped, and lists of software that caused trouble.
§4Scope and Focus
The working group focused primarily on IPv4 renumbering, not on future protocol changes. The intended audience was single-homed networks not acting as transit providers—the most common case in the 1990s. Organizations renumbering more complex environments, such as multihomed networks or service providers, were encouraged to submit information too, as were accounts of renumbering that was still underway, written as a 'diary' of the actual experience rather than a retrospective.
Submissions could be anonymous if desired, allowing organizations to share sensitive experiences without public identification. The deadline was May 15, 1996, and results were to be published as a series of documents describing processes, available tools, and known problematic applications.
The focus was on the normal case: offices moving to new addresses. But any real story was welcome, and you could stay anonymous.