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 =====----- -- --bill