Internic address allocation policy
karl at mcs.com
Mon Mar 20 21:10:48 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?)
Got a better idea Bill? I'm all ears. Forcing customers to give back
addresses is not workable in any enterprise of reasonable size. Application
gateways may work out for some applications, but not all.
Forcing people to renumber isn't workable. Portability is the only real
answer to this, and I agree that IPv4 isn't great in that fashion, and CIDR
is a botch and will degenerate over entropy.
But its what we're stuck with right now, Bill, so we make do with what we
have. BTW, coddling vendors with broken architectures in the process isn't
a solution either.
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 mcs.net" for more information
ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
More information about the NANOG