North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

number seven

  • From: bmanning
  • Date: Mon Feb 05 11:55:52 1996
  • Posted-date: Mon, 5 Feb 1996 06:55:48 -0800 (PST)

Renumbering - What, Why and How.  	v.007  05feb96 
					ftp.isi.edu:/pub/bill/renumbering
					Bill Manning

Sent to:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

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 [email protected], 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