[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date

[Matthew Kaufman]

Owen writes:
> It is. It will become an obvious problem when it adds another
> 200,000 or so prefixes to the routing table (note, disaggregating
> 3 /8s into /24s will be enough to have this effect).

See section 4.1.1 of the NRPM. ARIN is not in the business of 
determining whether or not address blocks will be globally routable.

Networks are free to impose whatever customer policies and peering 
policies and filters necessary to ensure that their routers keep 
working, no matter what ARIN address registrations look like.

And thus market forces will favor keeping reasonable aggregation. (In 
other words, your ISP will tell you "if you buy 256 /24s those won't be 
nearly as useful to you as buying a single /16")


>>> The intent of the policy was that you could receive a /22. No more
>>> or no less. That is considered the exact amount justified as a
>>> single aggregate.
>> And so if the seller has a /23 and you can justify 980 addresses you're simply out of luck? Or need to lie and claim you can only justify 450 today in order to get the /23?
>>
> Uh, no, the buyer needs to go find a seller that has a /22.

That makes no sense at all. Clearly they can turn around and say "oh, 
I'm sorry, we did the math wrong and/or we figured out how to use these 
a bit more efficiently... a /23 really is going to be good enough for us 
after all".

Requiring them to find a seller with a /22 actually encourages *less* 
efficient use of the address space, don't you think?

>> Clearly *that* would make no sense. You should be able to receive a /22 *or anything smaller* if you justify 980 addresses.
>>
> I disagree.
>
> I have no problem with the idea of accepting something smaller, so long as it doesn't result in a revolving door
> use of the transfer policy where you subsequently get the rest through additional acquisitions.

Ah. So the "revolving door" is a separate problem, but clearly (as I 
stated above) they should be able to accept something smaller.

The only solution to the revolving door is timers... and I believe 
John's analysis (plus the half-dozen workarounds I can think of) on this 
point.

If people really find that the only way to fulfill a /22 need is with 
two /23s, that's what they'll do... either by creating subsidiaries, or 
simply failing to tell ARIN about the second /23, or any number of other 
methods.

I'll point out here that if you *really* want people consuming the 
largest blocks they can in order to reduce deaggregation, you should 
eliminate the "needs based" requirement altogether... that way people 
who can afford a /16 but only need a /22 right now would be able to buy 
the /16 and then not need to transfer another /22 in 9 months because 
they could only get a 1-year supply.

> This is one of the reasons I didn't like the abandonment of 2008-2 which had minimum times between
>   transfers.
>
>> And then once you've justified 980 addresses to ARIN, you should clearly be able to use 8.3 transfers twice in a row, for two separate /23s... it wouldn't make much sense for ARIN to require you to resubmit all the justification paperwork you just sent them a few hours ago, would it?
>>
> Again, I disagree. The intent of this phrase was to reduce the amount of disaggregation of the routing
> table that will be caused by transfers. Allowing this revolving door use of the transfer policy will
> increase disaggregation.

So does the new policy of only allowing 3 months of need to be fulfilled 
through the ARIN allocation process.

> Even without it, I expect transfers to have a devastating affect on our continued ability to route IPv4
> in the relatively near future, but, perhaps I shouldn't object as I think the only natural outcome of that
> will be a sudden and dramatic shift to IPv6 which I guess is good for me. However, I try to keep the
> best interests of the community in mind and I think that would be traumatic on the community level.
>
>
>> And then once that's going on, why make the transfers happen as two separate transfers? That's just more paperwork for everyone.
>>
> Again, the goal and intent is to prevent the double transfer and resulting disaggregation.
>
>> The only other way to "fix" this is to only allow a recipient to use 8.3 once every N months... but there are any number of good reasons to not do this *and* several easy workarounds for the recipient as well.
>>
> I'd be interested in identifying (and perhaps eliminating) the workarounds.

Can't be done. And even if it could be done, the final workaround is to 
do the transfers and just not tell ARIN and/or do them as leasing 
arrangements and just not tell ARIN.

> I do favor a 6 month transfer moratorium given that transfers allow the transfer
> of up to 12 months of need. Sure, your projected need might be off, but, if
> it's off by more than 50%, I don't have so much sympathy.
>
>

Write a policy propsal and we can repeat the debate there.

Matthew Kaufman