Allocation of IP Addresses

Michael Dillon michael at
Thu Mar 14 00:43:02 UTC 1996

On Wed, 13 Mar 1996, Jim Browning wrote:

> A.	a single allocation capable of supporting planned growth, or
> B.	incremental allocations of *contiguous* blocks
> InterNIC's current CIDR allocation practice does not support either of 
> these options.

Here's an idea. Let new ISP's reserve large blocks (say /16's) in 65/8,
66/8, .... but don't let them actually use these addresses on the global 
Internet. Then, the ISP can run a Network Address Translation gateway and
give their customers 65/8 addresses while still using a chunk from their 
provider's block. And they can switch providers without forcing their 
customers to renumber. Then, after they have demonstrated that they 
should be given a /16, open up the block they were given in 65/8 for use 
without the NAT.

Of course, there is one little problem with this....

bash$ whois 65
Air Force Logistics Command (ASN-LOGNET) LOGNET-AS                         65
IANA (RESERVED-7)               Reserved         -

bash$ whois 96
Army Finance and Accounting Office (ASN-JTELS) JTELS-BEN1-AS               96
IANA (RESERVED-8)               Reserved        -
How did these guys get such big chunks of address space reserved?

> The day to day implementation of policy by the InterNIC has increasingly 
> critical impact on our industry, to the point of controlling who has the 
> opportunity to succeed and who does not.  IMHO, it is imperative that:
> 1.	this function be performed in an understandable manner,
> 2.	objective criteria be consistently applied
> 3.	the criteria in use be publicly available, and
> 4.	there be defined mechanisms for the 'appeal' of decisions made in the 
> processing of allocation requests.
> Recent experience and observation leads me to conclude that these 
> imperatives are perhaps not being met.  Am I all wet????

I think that the fundamental problem here is that the Internic is 
fundamentally clueless about important issues such as global routing and 
*BUSINESS* issues. They are behaving a lot like a government bureaucracy 
or a regulatory agency. 

I don't really see how this can be fixed with the current system of 
having a US government agency writing a contract with a private US 
company to provide a fundamental international infrastructure service!

Michael Dillon                                    Voice: +1-604-546-8022
Memra Software Inc.                                 Fax: +1-604-546-3049                             E-mail: michael at

More information about the NANOG mailing list