[arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers

Wed Dec 16 15:44:51 EST 2020

> On Dec 15, 2020, at 3:49 PM, Mike Burns <mike at iptrading.com> wrote:
> 
> Hi Owen,
> 
> I thought I had replied to this, but maybe not. Answer below your snippet.
> 
> 
> "Playing devils advocate for a moment, how would we prevent either of the following abuse scenarios:
> 
> 1. This allows virtually any ORG to acquire 1.125x their current holdings and use all of the
> addresses (smaller block + original holdings).
> 
> 2. An ORG considering selling some (or all) of its IPv4 holdings decides that a 1.125x
> multiplier on their ROI is appealing and even though they don’t need the space for
> renumbering, chooses to take this option as a way to get a revenue bump."
> 
> 
> 1. Wrong, this would only allow an ORG to acquire a maximum 0.125X their current holdings eligible for transfer, without a needs-test.

By 1.125 I was meaning to state that they would have their original 1x + 0.125X newly acquired = 1.125X.

> 2. That ORG dreaming of a multiplier would have to purchase the 0.125X and then turn around and sell it yielding no revenue bump and no incentive for abuse.

This assumes that IPv4 prices are flat and/or that they don’t locate some sort of low-cost source for an arbitrage opportunity (e.g. waitlist).

> To my mind the issue is that people can purchase 1/8th of their current holdings without a needs test.
> Not much of an issue considering every transfer in RIPE, far more than ARIN in number, was done without a needs-test.
> And those who choose this option are precluded from further needs-free purchases forever until they sell 8 times what they purchased.

Let’s consider (e.g.) a company engaged in leasing which is holding the equivalent of a /10. Under the proposal, without restrictions, they’d be able to acquire an additional /13 and continue to use the /10 + /13 for leasing with the only consequence being that they couldn’t acquire more space through an ARIN transfer until they divested of a /10 equivalent.

> There might be other abuse vectors but I don't think these are worrisome, and what's more you neglected to address the whole issue of how these swap-desirous members are able to justify the small block unless they spin up a new, resource-free ORG. These are colleges with old class B's who need a /24 for the most part. They can't justify the /24 as things stand, making the rest of the policy as written moot.

I know that organizations have been getting smaller blocks for these kinds of transactions. Frankly, if we can cap the small block at /22, I’m a lot less concerned about this as an abuse vector. However, without limitation, the above scenario still concerns me.

I don’t honestly know which section of the NRPM ARIN is using to facilitate these small block transfers currently. It does seem like a place where the policy falls short and I’ll look into adding language to the proposal to support that.

OWen

> 
> Regards,
> Mike
> 
> 
> 
> ---- On Tue, 15 Dec 2020 17:34:41 -0500 Owen DeLong <owen at delong.com> wrote ----
> 
> 
> 
> > On Dec 15, 2020, at 1:32 PM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>> wrote: 
> > 
> > Hi Owen, 
> > 
> > Thanks for spurring conversation on this proposal. 
> > 
> > In my experience those who frequently want to acquire a small block to renumber into are holders of much-larger blocks who can realize higher prices if they sell their much-larger block intact. The market is rewarding larger block sizes with higher unit prices these days. 
> > 
> > But how can they justify the small block they need to renumber into, since they usually have many more addresses than they are currently using? 
> > 
> > The workaround of a second ORG made it easier for the second ORG to acquire space, as it had none. 
> > 
> > But if we just adopt this policy language, the problem of the acquisition of the smaller block remains. 
> > I would likely advise my clients to choose the workaround. 
> > 
> > Actually I think the policy intention is good but it should be implemented in a different way. 
> > Recipients of 8.3 or 8.4 transfers can choose an option which avoids any needs-test in exchange for a promise to transfer out eight times the number received within a year. Only one option can be active at a time. These Recipients would be excluded from current source restrictions. 
> 
> Playing devils advocate for a moment, how would we prevent either of the following abuse scenarios: 
> 
> 1.    This allows virtually any ORG to acquire 1.125x their current holdings and use all of the 
>     addresses (smaller block + original holdings). 
> 
> 2.    An ORG considering selling some (or all) of its IPv4 holdings decides that a 1.125x 
>     multiplier on their ROI is appealing and even though they don’t need the space for 
>     renumbering, chooses to take this option as a way to get a revenue bump. 
> 
> > I think the policy needs to consider the justification problem for recipients of the small block they need to renumber into, in addition to the exclusion of these companies from the source restrictions, or it only provides half the reason to avoid the workaround. 
> 
> 
> > 
> > (Also I think there should be no needs-tests or source-restrictions as conservation is provided by price and address turnover is not a BAD THING. 😉) 
> 
> We agreed to disagree about this a long time ago. Of course, you are free to support a policy proposal to eliminate needs tests and/or source restrictions and try to build consensus around it if you feel that’s the right way to go. Should you need help drafting such, I am available to assist. 
> 
> Owen 
> 
> > 
> > Regards, 
> > Mike 
> > 
> > 
> > 
> > 
> > -----Original Message----- 
> > From: ARIN-PPML <arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>> On Behalf Of Owen DeLong 
> > Sent: Tuesday, December 15, 2020 2:38 PM 
> > To: arin-ppml <arin-ppml at arin.net <mailto:arin-ppml at arin.net>> 
> > Subject: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers 
> > 
> > Dear ARIN community, 
> > 
> > We (the AC, and specifically the proposal shepherds) need to solicit some additional feedback in order to better know the community’s desire with regards to this policy. Specifically, we’d like to ask the following questions: 
> > 
> > 1a.    Do you feel that we should place an upper limit on the size of the smaller block 
> >     received in the process? 
> > 
> > 1b.    If so, what should that upper limit be? 
> > 
> > 2.    Do you support limits on the time period allowed for renumbering? 
> > 
> >     2a. If so, how long? 
> > 
> >     2b. If so, what consequences should there be for exceeding the time limit? 
> > 
> > 3.    Should any additional restrictions or prohibitions be placed on use of waitlist 
> >     space in these transactions? 
> > 
> >     3a. Restrictions on waitlist providing the smaller block? 
> > 
> >     3b. Restrictions on waitlist space being transferred out? 
> > 
> > 4.    Do you support the policy as currently written? 
> > 
> > 5.    If not, would you support it with the changes suggested in your answers above? 
> > 
> > Thanks for your attention to this matter, 
> > 
> > Owen DeLong 
> > ARIN AC 
> > 
> > _______________________________________________ 
> > ARIN-PPML 
> > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>). 
> > Unsubscribe or manage your mailing list subscription at: 
> > https://lists.arin.net/mailman/listinfo/arin-ppml <https://lists.arin.net/mailman/listinfo/arin-ppml> 
> > Please contact info at arin.net <mailto:info at arin.net> if you experience any issues. 
> > 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201216/af536861/attachment.htm>