Internic address allocation policy

Karl Denninger karl at
Mon Mar 20 21:19:09 UTC 1995

> > In THEORY, once an address range is delegated to you it is YOURS.  CIDR
> > permits "holes", that is, more-specific routes.
> > 
> > Some providers try to force you to "give back" the address(es) when you
> > leave.  MCSNet, and most others, do not.  My view on this is that once you
> > receive an address consisting of at least a Class "C" block (ie: the last
> > octet is yours) then it is yours to keep -- period.
> > 
> > For sub-C allocations there is no good way to delegate those, and as such
> > at present we view sub-C allocations as belonging to us, and I suspect most
> > other providers who are as aggressive as we are in delegating small pieces
> > of address space also view things in this fashion.
> > 
> Looks like a double standard to me...  The same argument could be placed
> for any subnet not on an 8,16, or 24 bit bound.
> Remember that consistant policy is a "Good Thing"(tm?) and something that 
> works, -across the board- will last us longer than some simple haq that deals
> w/ current, broken hardware/software.  (Will this policy work in 24 months?)
> -- 
> --bill

Sure, Bill, as soon we all fix and the other botches which are
required to route these things, then we're happy to maintain that for a
customer and allow them to take a sub-C allocation with them.  What was that
about core routers running out of memory again?

Until then such a policy imposes indefinite costs on an organization which
is no longer deriving revenue from that customer who is imposing the costs.

That's unworkable, and you and the rest of the community know it, which is
why we draw the line where we do.

Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
Modem: [+1 312 248-0900]     | (shell, PPP, SLIP, leased) in Chicagoland
Voice: [+1 312 248-8649]     | 6 POPs online through Chicago, all 28.8
Fax: [+1 312 248-9865]       | Email to "info at" for more information
ISDN: Surf at Smokin' Speed  | WWW:, gopher:

More information about the NANOG mailing list