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

[Jimmy Hess]

On Sat, Apr 30, 2011 at 11:20 AM, Matthew Kaufman <matthew at matthew.at> wrote:

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

Technically, ARIN is not in that business.
De Facto,  if ARIN allocates something,  the ISP will be expected to
route it for them.

And various market pressures may ensure other providers carry those routes.

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

Only if they are able to negotiate contracts that allow them to impose
the needed policies.
It is very possible that they will gradually be forced into territory
they do not wish to be in.

Due to forces outside the providers' control that ARIN does have a hand in.

> 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")

You may accept that answer.
Or you may find another ISP that will give you a different answer.

Chances are high that there will be more /24s floating around, due to transfers.
Chances are high that ISPs will have to accept more /24s.

256 /24s from one customer would be an extreme example that is easy to refuse.
What about   9 or 10   /24s from a customer?

Not so clean cut.   Multiply that 1000 fold,  spread it across the
world, and you
have a major issue.

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

+1.
That's exactly what the text of the policy says...


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

The buyer needs to either find a /22  or stick to their story.
And not change it later to go say "Oh, by the way I need another /24"

ARIN needs to demand a rational explanation of what unforseen
circumstance caused the amount they can justify changed in a way
that differed from their planned future use in  3/6/12 months time.

And possibly either refuse the additional /24,
or demand they renumber into the /22  and  surrender the /23.

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

Routing table disaggregation is a consideration.
Efficient use is important,  that's   why they need to get the number
of IP addresses
they can justify.

If they get that /22 and turn out they will never actually need a /24, their
need for IPv4 stopped expanding,   then at a later date,  this is in their
benefit, as they can  8.3  transfer  or return the unneeded /24.


>>> 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 also disagree, that you should be able to receive "anything smaller"
than what you need, via 8.3 transfer.

That encourages organizations to attempt to size their addresses for faster
transfer, or to reduce their capital expenses, rather than to maximize efficient
use, minimize routing table fragmentation,  and  costs to the community.

> 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

Under 8.3; they aren't allowed to fulfill their /22 need by receiving two
/23s, and I don't believe policy should be revised to allow that.

> failing to tell ARIN about the second /23, or any number of other methods.

ARIN policy should be revised, to require a representation by the recipient
that this is the only address space transfer request they are involved with
as recipient,  and a signed document to the effect all
transfers have been reported to ARIN.


>> This is one of the reasons I didn't like the abandonment of 2008-2 which
>> had minimum times between
>>  transfers.
+1



--
-JH