[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>
> 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

> 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

More information about the ARIN-PPML mailing list