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

[Owen DeLong]

Sent from my iPad

On Apr 30, 2011, at 12:20, Matthew Kaufman <matthew at matthew.at> wrote:

> 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.
> 
True. However, as has been pointed out to me on numerous occasions, this does not
mean that ARIN should not consider routing table impact and the stability and
functionality of the internet in making policy decisions.

> 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.
> 
Consider a world where there is no general agreement about whose prefixes of what
size get routed and think about the likely outcomes that would evolve from that.
Do you really want to have to pay EVERY ISP that carries your prefix in order to be
able to reach your customers?

> 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")
> 
Sure, but, that will also have the simultaneous effect of destroying the ability for those organizations that already have /24s and have been using them for years to continue to do so.
Is that really what you are saying is desirable?

> 
>>>> 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".
> 
And if that works for them for the next 6 to 12 months, then, more power to them.

> Requiring them to find a seller with a /22 actually encourages *less* efficient use of the address space, don't you think?
> 
No. I think it encourages them to either get by with a /23 or to go find a /22.

Either scenario is preferable to them disaggregating into 3 or 4 prefixes instead of one
in order to meet their needs for the same period of time.

>>> 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.
> 
I agree we can't make perfect policy here and solve all the problems. However, we should at least express the desired result and encourage address consumers to comply as best we can. Abandoning policy in favor of market chaos just because we can't completely enforce our intent with perfect policy makes no sense whatsoever to me.

> 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'm sure there is some class of consumers that may do this. I don't find that argument to be a compelling reason not to attempt to write good policy for what should happen instead of writing policy to the pathological cases we expect might happen.

> 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.
> 
I'll leave the exercises in reductio ad absurdum to you.

>> 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.
> 
Agreed. In that case, it's an attempt to be more fair about the consumption rate of the final allocations and the community has chosen to accept an aggregation tradeoff in that process.

In the case of NRPM 8.3 it is pretty clear that the community found consensus favoring a single aggregate and I find the pathological interpretation of the policy by the staff rather disheartening.

>> 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.
> 
Time will tell. I think those approaches have their own set of drawbacks.

>> 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.
> 
I'll wait until I've seen yours. Most likely I'll advocate for making appropriate edits to what has already been proposed.

Owen
>