The Chicken or the Egg.

Wed Mar 14 12:35:21 UTC 2007

http://www.arin.net/policy/nrpm.html#four222

4.2.2 is the allocation to ISPs section; therefore 4.2.2.2 would be a part
of that.  It states under that multihomed section that if you can
demonstrate efficient usage of a /23, you can receive a /22 from ARIN.

--Mike

  _____  

From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of list
account
Sent: Tuesday, March 13, 2007 12:03 PM
To: nanog at merit.edu
Subject: The Chicken or the Egg.

Well the subject describes my frustration.

We are a small ISP that currently has 6 /24s.  Over the last year we have
inked some deals for some hotels and apartment complexes that would push us
over the required /20 to get our own allocation.  Many of these locations
are new sites nearing their completion so with in 90 to 120 days.   The
first 6 locations complete over the next 2 to 6 weeks and the vendor that
handle the hospitality networks want their addresses now.  The road block
has been that ARIN wants us to get the remaining /24s from our upstream,
assign them to our customers then get our /20, then renumber out network.
Many of these hotels are big chains and they don't seem to want deal with
this not to mention it makes us look even smaller. 

In my limited experience ARIN seems to not want to work with the small
operator.  Maybe I got someone on a bad day or maybe I am using the wrong
verbage.  Would the 4.2.1.4 <http://4.2.1.4/>  Slow Start apply in my case?
What about the 4.2.6 for Cable Operators?   It seems kind of unfair, if I
read this correctly, that they gain IPs biased on the number of homes that
could purchase service.   We have a WiSP network with a very large foot
print where I am using most of my address space.  I wan't to minimize
renumbering my customers.   

To add to this I want to be portable.  Since AT&T has bought BellSouth my
upstream provider is now declaring war on me.    But this is a rant for
another time. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070314/d49f3230/attachment.html>