[arin-ppml] IP Address Policy
Jimmy Hess
mysidia at gmail.com
Fri Aug 10 01:47:46 EDT 2012
On 8/9/12, William Herrin <bill at herrin.us> wrote:
> On Thu, Aug 9, 2012 at 6:17 PM, Christoph Blecker <cblecker at gmail.com>
[snip]
> Well, hold on a minute.
> We've long held that BGP multihoming is sufficient justification for
> an ISP to assign a /24 to a customer regardless of the customer's host
> count. Right?
Right, as long as they show the evidence of building a multihomed
network, and have the proper arrangements with the ISP, and get no /24
from anywhere else, the ISP should allocate them a /24 when
requested.
> But so far we've only considered end-users. What about ISP startups?
> Doesn't some form of the same reasoning apply to a *multihomed* ISP
> startup?
It doesn't really help an ISP that already has a legacy /24
and who is taking issue with the Slow Start policy, disqualifying them from
obtaining a /22 based on their 12 month projected / predicted
customer base size, etc, etc.
Although I would say that it would seem reasonable to revise Slow
Start, so that:
Demonstrating proof of multihoming, immediate need for 80% of a
/23, and the normal 3 months justification for a /22, should be
sufficient to obtain an allocation of the minimum ISP allocation unit
size (/22).
I would say that renumbering requirements associated with allocating
/24s are too burdensome for ISPs, because where they are not the end
user assigned the addresses -- that means they have to force customer
networks to renumber.
ISPs should not be granted such small allocations by ARIN in place of
their upstream.. the /22 minimum is appropriate.
I doubt that an ISP startup requiring only a /24 is common. They will
very quickly need more than a /24, or they probably won't be in
business for too long.
Allocation churn or multiple prefixes for the same org issued at the
RIR level in a short period of time is bad, and issuing overly small
IPv4 allocations to startup ISPs could promote that.
I> Regards,
> Bill Herrin
--
-JH
More information about the ARIN-PPML
mailing list