North American Network Operators Group

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

Re: Internic address allocation policy

  • From: Matthew Petach
  • Date: Tue Nov 19 13:54:33 1996

Since people seem interested in personal stories and
anecdotes about the struggle for IP allocations, I'll
leap in headfirst and mention our struggles from back
in February of this year...

(I'm leaving Chris and Kim's remarks included at the end
 of this, as further emphasis, and as a restating of what
 I found out in attending the Feb. NANOG meeting--Kim 
 really is a real person, not a huge, pale-skinned vampire
 attempting to suck the life out of quivering little ISP's.  :-)

We went through the same problems at the beginning of the
year; our growth rate was ramping up exponentially, our
customer base was doubling twice as fast as we had
expected, we were running low on address space in our
existing blocks, and we begged for more.  We had been
lax in the recent use of SWIP entries for many of our
blocks, because we issue /32's for ISDN terminal
adapters, and figured "we don't need to mark those,
because there's no way to indicate ownership of the
/24 properly."

When our requests were turned down time and time again,
we blew up--I mailed Mark, Kim, and anyone else I could
think of, I called, I moaned, I wept, and finally I
bit the bullet, and downloaded a very early, barely
supported beta version of rwhois, and wept and cried
and pulled my hair out some more.  It seemed ridiculous
to try to put all the data in, but as it turned out,
three weeks of putting our records straight, looking
information up, and then finally sending a long list
of referral records to the NIC, pointing to our newly
installed rwhois server paid off, they agreed we had
met the requirements, and allocated our next block
to us.

(I'm skipping the intervening pain and suffering I
went through in getting 6000+ records into the early
version of rwhois--those of you on the rwhois mailing
list can read through the archives and relive the
experience yourself.  At the Feb. NANOG, I met not
only Kim herself, sans fangs, but also Mark, who I
gave several pieces of my mind to, for the state 
and condition of the rwhois code.  I will congratulate
him, and the rest of his team, on getting the code
into a far more usable state, but it's still not
yet to the point of being trivial to implement
at an ISP.  At least they're listening, and working
on improving it now.  :-)  Anyhow, in meeting Kim
down in San Diego, I realized she's actually got
one of those jobs that must make you hate to
answer the phone--you know what you're doing is
necessary, but it doesn't make it any easier to
face the poor network engineers who are ready
to blow a gasket at the beaurocracy being thrust
upon them.  :-(  Let's not drag her through the
muck too harshly about this--after all, we're
the ones staying locked into the limited IPv4
space like this. 'nuff said, back to the story--)

We found out in the process that we had multiple
blocks that we thought were allocated that no
longer had customer records associated with them,
we had blocks that were doubly allocated (?!), and
we had FAR too many blocks that we just didn't have
customer info on altogether.  It actually helped
our accouting group immensely having to comb through
all of our address space, and account for as much
of it as possible, because it forced us to confront
all the random "back door deals" and legacy allocations
that nobody had every really bothered to keep track of
because "you could always just get more IP blocks."

We also sent copies of the Hubbard draft to all
corporate customers that were currently in the
pipe awaiting /24's, and explained that they would
instead be given /28's for fractional T1 frame relay
service, /27's for full T1's, and /24's for T3
service, by default, unless justification for
larger allocation was received in writing, with a
complete network diagram showing current utilization
and future growth.  We highlighted and underscored
the section that indicated that "administrative ease"
was NOT considered sufficient reason for a larger
allocation, and we've held to that restriction
very well since then.  Yes, customers have grumbled.
Yes, some customers left, or cancelled pending
orders when they found out the restrictions. Our
only hope is that as more and more ISP's go back
for new allocations, and find out that these rules
apply to everyone, the unruly companies that are
shopping around for and ISP that will hand them
IP blocks carte blanche will realize that there
ain't no such thing as a free IP block--if everyone
follows the rules, customers will fall into line
as well.

We have also taken the step of charging a nominal
fee for additional IP blocks, to prevent companies
from simply fabricating supporting documentation.
The one lone person in a garage tends to be much
less casual about requesting larger and larger
blocks when the find out that each additional
block comes with a recurring monthly fee.  It
also lets us keep track of usage much more
closely, because if a customer stops paying
the monthly fee for an IP block, we give them
notice, in the usual way, and eventually we
KNOW we can reclaim the block.  Previously,
it was much harder to tell if a customer was
still using a block, albeit infrequently, or
had totally forgotten they requested it.  :-)

Anyhow, enough rambling, this is turning out to
be a far longer missive than intended, and the
wet towel is getting REALLY cold, so I'll wrap
up by simply saying "This is life in IPv4 space--get
used to it, or move on to IPv6."  I don't mean
that in a harsh way, and I don't intend it as a
snub to anyone.  We have a scarce resource that
needs to be rationed.  We have an alternative
resource that is much less scarce, and needs far
less rationing.  If you wish to continue working
with the scarce resource, you need to accept that
rationing is part and parcel of utilizing that
scarce resource, and as such, documenting your
usage of the resource has a much higher priority.

The only thing I WOULD reccomend is having the NIC
sign an NDA for your company.  This way, if information
provided to you that you pass on to the InterNIC leaks
out, or is used in a mass mailing, you DO then have
a leg to stand on in taking the NIC to task for
releasing confidential documentation.  But that's
standard business practice, so it hardly bears

Again, 'nuff said, just wanted to throw in our
personal testimony into the grist mill, and say
"we were there, we went through the suffering,
it CAN be conquered, and it will probably help
your organizational record keeping in the process.
Yes, it's painful, but so is juggling MED's at
4 am."  
We're not in a hedonistic business, and
this isn't the Elysian Fields.  Once you've got
the software and processes in place, changing
entries, and adding new ones isn't NEARLY as
bad as having 3 /24's left, and taking your
FIRST look at rwhois.  I wish you the best
of luck in getting everything straight with
them, but as far as we've seen, don't expect
to get around the requirements--they're here
to stay, as long as IPv4 is around.

Thanks for putting up with my ramblings,

Matt Petach
Network Engineer

> >
> Matthew,
> The InterNIC bases additional allocation blocks on efficient utilization.
> We can only see the utilization from your SWIPs and RWHOIS info.  If
> you refuse to supply contact information on your assignments, how can we
> tell what your utilization is?
> And as for the routing table overload, although the initial allocation
> may be relatively small, it is almost always reserved from a larger block.
> Bottom line, to receive additional address space all you have to do is
> the same thing everyone else does - submit reassignment information.  You
> don't have to fly out here, you don't have to be nice to me, just follow
> the basic policies.
> Regards,
> Kim Hubbard
> InterNIC Registry
> > Original message <[email protected]>
> > From: "Chris A. Icide" <[email protected]>
> > Date: Nov 18, 22:49
> > Subject: Re: Internic address allocation policy
> > > 
> > ...
> > > Imagine my amazement when I met Kim in person and found out she
> > > didn't have fangs, horns, and a string with dried Network Engineers' ears
> > > 'round her neck.  In fact, she is a very nice person doing a very difficult
> > > job.  She has a set of rules she must live by.  she has to be impartial,
> > > and show no preferences.  
> > 
> > In fact, though, I have stories piling up via private email that shows
> > that this "impartial and show no preferences" is in fact ignored on a
> > fairly regular basis. 
> > 
> > Thanks to everyone who has given me stuff via private email, and keep
> > the stories coming in. 
> > 
> > The allocation policies do in fact have fatal flaws. For instance,
> > conservation of addresses which results in not filling an allocated block
> > within 3 months is penalized, not rewarded. The penalty for using up
> > addresses too slowly is to have future allocations blocked entirely,
> > not simply limited to /19.
> > 
> > You are better off allocating /24's quickly than carefully analyzing customer
> > needs and allocating smaller subnets. However, wasting addresses too quickly
> > can get your subnet-size policy brought into question.
> > 
> > But, bigger providers are given much more slack with regard to their allocation 
> > policies, and their own public SWIP and rwhois information bears this out. 
> > There are dozens of examples of /24 subnets being handed out to people
> > with very low numbers of actual hosts by Sprint, for instance, from their
> > block, and clearly they were able to receive their 
> > block in spite of this. (I hate to pick on Sprint here, but that's the
> > first set of data I pulled for examination).
> > 
> > It goes on and on. 
> > 
> > Yes, by bringing this out into the public I've potentially made someone(s)
> > at the Internic unhappy. Sorry. I've also received dozens of private emails
> > thanking me for making this more widely known, and several other providers
> > have contacted me because they're in the same situation... comply with
> > the policy, and get screwed.
> > 
> > The fact is, I *don't* ever have to post stuff like this about my other
> > "suppliers". For starters, I've never had a real supplier try to jerk me
> > around so much, and secondly, there really aren't any other suppliers who
> > are sole (monopolistic) sources.
> > 
> > If Cisco's tech support people were as hard to deal with as the Internic
> > representatives, I'd go buy someone else's routers. I don't have this
> > choice for IP addresses, and my complaints are going to be public as long
> > as there's people who want to hear them.
> > 
> > -matthew kaufman
> >  [email protected]
> > 

- - - - - - - - - - - - - - - - -