[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations
tedm at ipinc.net
Mon Nov 9 15:20:48 EST 2009
James Hess wrote:
> I find myself undecided in regards to this proposal at the present
> time, with regards to support/oppose...
We wrote this proposal with an eye to keeping it's effects somewhat
neutral to the Internet in general. If your not of the size that
this change would affect you, then our hope would be that you
would regard this as a neutral proposal and be undecided.
Let's explore the argument that this will increase the
DFZ by letting more small ISPs into it.
You have to ask, why would a small ISP -want- to be in the DFZ
to begin with? Keep in mind that a couple /24's cost large ISP's
practically nothing - to see why, divide out
the cost for larger and larger allocations in the ARIN fee structure
and you will quickly see the more numbering you qualify for, the
cheaper it is.
A large ISP can afford to give a small ISP 2 or 3 /24's for far,
far, cheaper than that small ISP can afford to go to ARIN under
this policy and get them themselves.
So, why don't the large ISP's simply do that for their small ISP
Well, right now, that's exactly what they do.
The problem becomes post-IPv4 runout. You can argue all you want
that a large ISP who wants to be a good Internet community member
will continue to give their small ISP customers those handful of
/24s for the cost that they are paying ARIN for them - basically,
But, what's going to happen when these stockholder activists,
the Warren Buffets of the world, get wind that their large ISPs
that they sit on the boards of, have a lot of low-usage subnets
allocated out to small customers - when those same subnets are
fetching a couple million dollars on the transfer market - and
the Internet community is out there beating the drum that IPv4
is dead and we all need to upgrade to IPv6?
We all know what will happen. They won't hesitate, on the boards of
AT&T, Comcast, Verizon and the like, to order that those companies
consolidate their IPv4 holdings and get them up on the auction block
ASAP, before the other guy does, in order to make the
Johnny-come-latelies who wern't paying attention to IPv4 runout, to pay
and pay and pay again. And if a few small ISP customers get squeezed,
well that's just business, sorry folks.
The fact is that a large increase of IPv4 in the DFZ is coming no matter
what we do about it. The IPv4 end-game post-IPv4 runout will be to
delay IPv6 for as long as possible - because of the simple fact that the
later you migrate, the cheaper it will be. You will be taking advantage
of all of the work done by those who went in front of you - countless
hours of it - and we all know that the people in the front of the
IPv6 migration are all going to be dual-stacked. So, many orgs - and
I'm not talking the really large ones that cannot do this, I'm talking
the medium-sized ones big enough to qualify for additional allocations
but small enough to survive with IPv4-only for a few years past the
large orgs - will be obtaining transfer subnets that will not be
contiguous with their existing ones, and will not be aggregating them.
In a dual-stack Internet, the IPv4-only holders will be able to reach
everyone. Until we see the day that some of the dual-stacker networks
start going to IPv6 only, prices for IPv4 via a transfer policy will
continue to rise. There is going to be a transfer of IPv4 numbering
from larger orgs to smaller orgs, via the transfer mechanism, and this
will increase the DFZ even if those blocks aren't subnetted, since they
will be advertised under different ASs.
Further, the various reclamation efforts - and the POC Cleanup is one -
will generate "un-virgin" IPv4 from within the RIR's existing
assignments from IANA that isn't contiguous to anything, and it will be
handed out in the future. The very Rationale in this policy proposal
contains 3 "un-virgin" IPv4 subnets, for example. Do you think they
WON'T be handed back out, post-IPv4 runout?
What Chris and I are trying to do is divert some of those subnets into
the hands of small ISPs before this turns into a commercial pay-for
IPv4 addressing market. Once the RIR's are out of blocks in the virgin
free pool, and out of "de-flowered" blocks from the "used" pool, then
the opportunity for the smaller ISPs to get initial assignments will be
gone. Most will never be able to afford to pay for the transfer blocks,
and their upstream LIR's will be applying increasing pricing pressure on
them for what they do have from them.
> On Fri, Nov 6, 2009 at 2:58 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>> William Herrin wrote:
>>> On Thu, Nov 5, 2009 at 1:46 PM, Member Services <info at arin.net> wrote:
>> Under this proposal they qualify for what might be termed a
>> "temporary" allocation. If they never grow, they never renumber.
> Then it's not temporary at all.. it's more like a provisional allocation.
It is - until IPv4 runout happens.
Once IPv4 runout happens, any of those provisional allocations that
were handed out will very likely become permanent, they will in essence
become the only portable IPv4 that those smaller ISP's will ever get.
>> If they grow, they renumber into a larger allocation that reduces
>> the burden of carrying their routes - same as the current requirements.
> Under the current requirements, they might choose not to renumber..
Once IPv4 runout happens, they may not even have the option to
get more assignments.
>> Thus they are not really "Initial requesters" However, since
>> they are getting their first allocation, they ARE "Initial
>> requesters" - from a certain point of view.
> Um.. they can't be both "not really 'Initial requestors'" and
> Initial requestors at the same time...
> It's a confusing and contrived thing to suggest "initial allocation"
> is anything other than the very first allocation they get.
>> Your making a claim here that the simple property of
>> being multihomed somehow acts as a deterrent to an org for
>> subnetting, and splitting their advertisements, thus
>> creating new overhead cost for everyone else.
> The cost is not based solely on whether they subnet or not, it's also
> based on whether other providers can effectively filter the
> additional noise out.
> A small ISP gets IPs from upstream providers out of PA blocks from
> which ARIN allocates prefixes no longer than /20.
> Providers who need table size reduction to avoid increased cost may
> have that option of filtering, discarding announcements with prefixes
> longer than /20, rely on the non-customer's ISP's covering route
> to provide connectivity.
> For the blocks ARIN assigns /22s from, for multi-homed users,
> /22s definitely need be accepted or connectivity would be quite
> If ARIN were to allocate smaller blocks such as /23, these could
> not be filtered, since there is no upstream provider announcing an
> overall /20 PA that contains the /23.
> The smaller an allocation ARIN makes from any given block, the
> less effective that an aggressive filtering strategy could be.
> When single-homed ISPs get a /23 from an upstream provider the
> DFZ _MIGHT_ see 1 additional /23 and 2 additional /24s
> being broadcast, for a total of 3 new table entries, but then
> again they might not.. the single-homed ISP may not announce a
> When single-homed ISPs get a /23 from ARIN, you can be assured,
> almost guaranteed an additional /23 appearing, and 2
> additional /24s getting announced cannot be ruled out.
> It seems like a plausible scenario, that the costs to others would
> be much greater, in the scenario where ARIN allocates a
> significant number of /23s to single-homed providers.
> I couldn't think of any plausible scenario where the costs to
> others would be less or the same, if single-homed entities are
> allowed to receive small direct allocations.
OK, try this one.
In the ISP market, the fewer ISPs you have the less competition
among them, and the less choices that consumers have.
If we do nothing, and IPv4 runout forces a decrease in the number of
smaller ISP's, then prices will rise for consumers due to monopoly
actions in markets with a single remaining provider.
More information about the ARIN-PPML