[arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers
owen at delong.com
Wed May 2 21:43:24 EDT 2012
On Apr 30, 2012, at 7:22 PM, William Herrin wrote:
> On 4/30/12, Bill Darte <billdarte at gmail.com> wrote:
>> May I ask for the record if you believe that the circumstances have changed
>> as we approach run out of free pools throughout the world and the
>> expectation may be that smaller blocks will need to be routed in order to
>> enable new entrants into the Internet.
> Hi Bill,
> The circumstances continue to evolve and frankly I'd be interested to
> learn what the ground game at APNIC looks like now that they've been
> cruising without a free pool for a while. For the moment, though, I
> thought it was a superb idea to lower the minimum assignment to /24
> with a renumbering requirement for assignments smaller than the prior
> minimum and I continue to think it's a great idea.
Actually, APNIC is not cruising without a free pool even now. They are
cruising with a rationed free pool which is limited to a single /22 per ORG
>> Why would allowing the recipients under 22.214.171.124 to keep the /24 and justify
>> another block be bad? Would it be an option to simply request that they
>> renumber into a larger block but accept some exceptions? Under what
>> circumstances would those exceptions be acceptable to you?
> I could probably be talked into the idea that an org may only hold a
> single assignment smaller than /22 but is not required to renumber out
> of that assignment when requesting a /22 or larger. In other words,
> you can't just request another /24 and grow by costly little nibbles
> at the RIB.
The number of /24s remaining in the ARIN free pool is dwarfed by the number of /24s already in the routing table.
ARIN has ~6.8 /8s remaining in all of its freepool space (reservations included if I understand correctly) which if fully expanded to /24s would represent 447,007 /24s.
Given that most of the ARIN run rate is in larger blocks and that /22s even at 1:1 allocation rates would consume 3/4 of that space, I can't see how you would make a case for the impact of this policy having any potential beyond 111,752 additional routing table entries.
OTOH, anyone can now buy as many /24s on the transfer market as they can justify, even one /24 at a time (we got rid of the single aggregate provision in the transfer policy), so, if you want to worry about nibbling away at the routing table, let's focus on the potential for problems there, rather than in this piddling little policy.
More information about the ARIN-PPML