Renumbering - What, Why and How. v.007 05feb96
ftp.isi.edu:/pub/bill/renumbering
Bill Manning
Sent to:
inet-access@earth.com
IAP@VMA.CC.ND.EDU
sun-managers-relay@ra.mcs.anl.gov
pier@isi.edu
nanog@merit.edu
Kudos:
Don Rolph - TI
Piet Beertema -
Brian Carpenter - CERN
Michael Patton - BBN
Jeff Schiller - MIT
Matt Holdridge - DECUS
What:
Renumbering is the action of changing the IP addresses (i.e. the
prefix and/or netmask) for an administrative domain and all the machines in
it. This can be as small as a single lan with a few hosts through an
International Internet Service provider and all its downstream
providers/clients.
Why:
Due to the extensive growth of the publicly visible IP (IPv4)
structure, (the Internet) there has been pressure placed on both the
total number of addresses in use, but also the abilities of the global
routing system to handle them all. Some providers are asking their
clients to help alleviate this situation by utilizing addresses already
delegated to the provider. This reduces the number of prefixes that
are injected into the Internet routing system[1]. Remember that Internet
wide connectivity is something that -NO- provider can guarantee or control.
The registries which delegate address space attempt to make the address
space last as long as possible[2].
To facilitate management of high traffic/mobility environments,
the use of dynamic addressing eases the burden of the support staff. A
reasonable paradigm is that the network should appear flat to the
user but should appear rigidly hierarchical to the network administrator.
Among the tradeoffs between fully manual/static management and
fully dynamic configuration is the concept of traceability or the ability
to retain the identity of an end to end connection. Many network operators
want to know, consistently "who" a machine really is.
So, collecting techniques and tools for supporting renumbering IP
hosts can be a very valuable activity and should be considered as part of
ongoing network design. What follows are some tips and techniques for
renumbering and designing for renumbering support.
How:
- basic philosophy
Deciding to renumber
because you have to, or
because you want to
Use of a "majik" line in through the address space to delineate
who/where renumbering should occur is a function of time and
tools.[5]
The two worst case environments are:
- flat routing of 32bit prefixes.
Good in the hw/sw design cycle.
- periodic, dynamic renumbering across the entire
address space.
Route flaps, name conflicts, etc.
Plan for the worst case and hope for the best.
- developing good designs to facilitate renumbering
- Use Discovery protocols (Router, DHCP, dynamic routing etc)
- Centralized services/services (DHCP Servers & Routers)
- Weigh tradeoffs between full dynamic support and manual
support of a small number of machines/files.
(Note that this is more than just deploying DHCP et.al.
This is changing the range over which DHCP et.al.
will operate!)
- Keep total changes to a minimum
- avoid classful routing protocols (RIP, IGRP, EGP etc.)
- Build robust software distribution methods
- rdist (UNIX)
- sms (MicroSoft)
- Catalog all files that require hardcoded addresses
- DNS zone files
- NNTP configurations
- NTP configurations
- AFS servers
- static host lists
/etc/hosts
- ROUTER configurations
- NMS databases
- Firewalls and Access control lists
- Use names instead of numbers where ever possible.
It is possible to reorganize procedures to generate
most/all configuration files that require hardcoded
addresses from the files that map names to addresses.
(Use a network managment database)
- Channels to update external databases (DNS, IRR, NNTP etc)
- techniques to renumber legacy infrastructure/hosts
Convince Managment with good cost/benefit arguments
Give yourself plenty of time. A year or more may be
required.
In some situations, it may be required to renumber
fairly large sections of a network in 3-6 months!!
Evaluate the trade offs of incremental vs flag-day migration
Decide on a new numbering policy
bigger or smaller or differnet media layers
changing subnet masks
consider broadcast and multicast scope
Consider re-architechting the topology
security implications
Deploy DHCP/Bootp and other dynamic discovery protocols
Use routers and secondary addresses
Run two subnets on the same media layer
Use DNS as a migration tool
Notify your secondaries
Change timeouts to facilitate rapid updates
Update local zone generation scripts
Get the Dynamic DNS code deployed
Prepare recipies for chaning each type of end-user system
Can you isolate "misbehaved" hosts with ancient code?
Identify software that may use IP addresses for use licenses.
- ways to avoid renumbering [3],[4]
- Public Relations
- as viewed inside an organization
- Identify which organizations you must work with
- Clear and realistic timetables must be set
- Publication of the changes to the user community
- User community feedback and buyin
- Managment acceptance
- viewed outside an organization
- Coordination with offsite support services
(DNS Secondaries, NNTP Feeds, NTP servers etc.)
Legacy tools
Some predictions indicate a planned 20-30yr life expectancy for IPv4
Thats a -long- legacy.
How to change to a DHCP/bootp environment.
The DHCP FAQ is a really good place to start.
http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
Router secondary addresses
Ensure your routers have the new prefixes as secondary
or primary addresses. You may find that deletion of a primary
address will delete the secondary.
How to turn back addresses
Generally, Email to Hostmaster@InterNIC.net, indicating
a desire to return address space is enough. There is
an appeal document that may come out of the CIDRd working
group which has more to say on this topic.
Virtual interfaces
Use of virtual interfaces can provide a migration aid.
http://inet.nttam.com/HMP/PAPER/131/
ugle.unit.no:/pub/unix/network/vif-1.0.tar.gz for SunOS4.1.4
Ensure route advertisements are done
Serious Problems:
Security
- watch your access lists when addresses change.
Managability
- SNMP configurations
- Passive DHCP vs Dynamic DHCP
Index:
[1] CIDR FAQ - anonymous FTP: ftp.ibm.net.il/pub/docs/cidr.faq
[2] RFC 1466
[3] RFC 1597 & RFC 1627
[4] RFC 1631
[5] draft-ietf-cidrd-ownership-01.txt
RFC 1631 - Network Address Translators
RFC 1715 - "H" ratio
RFC 1775 - To be on the Internet
RFC 1812 - IPv4 router requirements
RFC 1817 - Classful routing
------====== EOF =====-----