[arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses

[Tom Vest]

On Sep 29, 2008, at 3:56 PM, Scott Leibrand wrote:

> Kevin,
>
> Can you outline a proposal of how you think ARIN should effectuate  
> such
> transfers?
>
> Thanks,
> Scott

I can. In fact I did on September 4. Summarizing again below:


> ...Imagine that at the end of the free pool, annual renewal fees  
> start incrementing per /32, but that ARIN offers a "bounty" equal to  
> 100% of the new fees to any signatory that agrees to voluntarily  
> return some scale-sensitive quantity of IPv4.* For the sake of  
> "simplicity" I'll illustrate using $1 per IP, rounded up to the  
> nearest classful bit boundary for the renewal fee, and define the  
> address return required to earn the "bounty" as equal to the next  
> smallest classful address block, but many numbers/ratios would  
> probably work equally well.
>
> So, for example, the mechanism I'm imagining would oblige a /8  
> holder to return one /16 per year in order to qualify for the  
> bounty, which would also effectively make this approach revenue  
> neutral. ARIN would never have to handle one penny more than it does  
> today. To make the effects consistent across the smaller end of the  
> address distribution spectrum, maybe additional fees and bounties  
> are phased out for members that retain a /20 or less, until all  
> members are down to roughly equivalent sized IPv4 endowments.
>
> *less any added administrative costs, which should be modest.
>
> What would this approach accomplish?
>
> 1. Incremental, inevitable, but (more) predictable effects: No  
> matter what, everyone is facing the same reality of doing more with  
> less IPv4, or much much more expensive IPv4, and/or perhaps with  
> some IPv6. No one should be imagining that making a windfall on the  
> transition, or pushing most or all of the costs of transition onto  
> future new entrants are sustainable options; they aren't. By the  
> same logic, no one should be significantly harmed by parting with  
> 1/256 of their existing IPv4 reserves every year, especially if  
> everyone is facing the exact same constraint. Given the mechanism's  
> scale-sensitive uniform effects, even operators who grudgingly  
> support the idea while still hoping/expecting to NEVER make a full  
> transition to IPv6 could find comfort in the knowledge that they  
> might have hundreds of years to be proven right.
>
> 2. Recover liquid legacy IPv4 address space: Nothing in this  
> approach requires or assumes that ARIN members will return address  
> space that they received directly from ARIN, and everyone is already  
> assuming the emergence of some kind of gray market (at least) under  
> any/all future scenarios. If quietly purchasing IPv4 in a gray  
> market looks like a better deal than returning RSA-covered addresses  
> and perhaps adopting some IPv6 on the margin, then nothing would  
> explicitly prevent people from doing that. Thus legacy/surplus  
> address space holders are not absolutely precluded from capitalizing  
> on their early efforts / good fortune, but sales do not have to be  
> formally condoned, and the whole system does not have to be  
> jeopardized in order for that option to be preserved.
>
> 3. Minimize speculative pricing: Nothing short of militarization of  
> the process is likely to eliminate all speculation/profiteering, but  
> this approach would define an implicit "official price" for IPv4  
> that could help to establish a firm ceiling on speculative pricing.
>
> 4. Avoid wholesale privatization: By leaving ARIN in place as the  
> sole official mediator for IPv4 "recirculation" -- not transfers --  
> the risk of full privatization (intentional or unintentional) is  
> reduced to zero.
>
> 5. Back out IPv4 now, or later, or never: IPv4 recovered by ARIN  
> could be warehoused permanently, e.g., to assure an eventual return  
> to address space homogeneity somewhere down the line, and to send a  
> signal to non-participants that IPv4 *will* be obsolete sooner or  
> later (reinforcing 3, above). Alternately, the address space could  
> be put to other uses (e.g., made available for subsequent  
> allocations to those willing to pay the same $1 per acquisition and  
> renewal fees, with the proceeds returned as dividends to the entire  
> community, or selectively and proportionately, e.g., for accelerated  
> IPv4 returns).
>
> 6. Preserve of industry openness: Regardless of how the majority of  
> recovered IPv4 is disposed of, enough will always remain available  
> -- ideally through 2008-5 style transitional allocations -- to  
> clearly demonstrate to all internal and external stakeholders that  
> all segments of the industry will remain open to new entry in  
> perpetuity.
>
> 7. Mitigate antitrust risks: In the absence of (6, above) large IPv4- 
> based service providers will be perpetually at some risk of  
> antitrust action. The proposed policy might conceivable redirect  
> some of that risk in the RIR's direction, but it seems to me that  
> given the pro-open access orientation, a community consensus- 
> supported approach like this would probably provide the strongest  
> possible defense against any/all antitrust concerns.
>
> 8. Enable IPv6 integration/migration: This approach should help to  
> squelch any bets/competitive strategies that an IPv6 transition will  
> never happen. Once people get over the psychological hurdle that  
> IPv6 really *is* coming, and understand that the transition is not  
> going to be complicated by radical uncertainties,  high risk second  
> guessing, or any other new competitive traps, expectations about the  
> future will be aligned in ways that might accelerate the pace and  
> reduce everyone's pain of migration.
>
> 9. Minimize routing table expansion: This approach would assure that  
> at, over time, progressively more growth will be accommodated by  
> IPv6 rather than through de-aggregation. Doesn't solve the IPv6  
> routing scalability issue, but it does preserve the RIR as a  
> potentially self-sustaining administrator for any ongoing/future  
> number resource-related needs verification, as maintainer of the  
> registration database, provider of whois, and a potential anchor for  
> resource certification, et al. -- and as a viable mechanism for  
> continuing policy deliberation in the event that future routing  
> scalability requirements require the same kind of coordinated action  
> that helped to mitigate the last such crisis.
>
> 10. Clean, easiest possible reversability: Unlike the 2008-2 and  
> 2008-6, if this approach turns out to have perverse unanticipated  
> consequences, it could be terminated or even reversed with a  
> (relative) minimum of disruption.
>
> Potential Downside: if IPv4 is permanently warehoused, then any  
> potential revenue arising from IPv4 sales would be foregone. If IPv4  
> prices are expected to be modest (e.g., modest enough to avoid  
> antitrust scrutiny), then perhaps any loss would be equally modest.  
> Alternately, the foregone one-time sales revenues could be thought  
> of as investments toward a better, NAT free (or NAT-vonlutary-only)  
> future. If those future payoffs are deemed to be insufficient,  
> returned address space along with cash proceeds from ongoing IPv4  
> "recirculation" could be redistributed to community members, but  
> this would probably impose substantial new administrative burdens  
> and risks on ARIN. However, the second option is neither required  
> nor recommended.


TV


> Kevin Kargel wrote:
>>
>> Thank you Micheal for your common sense explanations.  I certainly  
>> agree
>> that the only legitimate way to transfer IP addresses is through the
>> services of the RIR.  Anything else would breed chaos.
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net
>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
>>> Sent: Monday, September 29, 2008 2:25 PM
>>> To: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy
>>> for IPv4 Addresses
>>>
>>>> This is nonsense. Literally. IP address transfer markets are not
>>>> derivative markets,
>>> A derivative is essentially a contract. It is used to buy or
>>> sell something, that normally cannot be bought or sold. Yes,
>>> it is true that the most common types of derivative contracts
>>> are options and futures, but there are many others.
>>>
>>>> IP
>>>> address transfers as proposed by various RIR policy changes
>>> directly
>>>> transfer a valuable but intangible asset from one party to another.
>>>> There is no redistribution of risk.
>>> Given that the RIR policies and registration
>>> agreements(contracts) all state clearly that IP addresses are
>>> not property, I don't see how you can buy or sell the right
>>> to use them other than through a derivative contract. So far,
>>> I have seen no policy proposals to change IP addresses into
>>> property, and if they are not property, then they cannot be
>>> an asset and cannot be bought or sold.
>>>
>>> As for redistribution of risk, that is insurance (or
>>> reinsurance) and is not an essential component of a
>>> derivative contract.
>>>
>>>> Let's keep in mind that transfers of IP addresses already
>>> happen. Are
>>>> you suggesting that they all be stopped?
>>> Yes, they should all be stopped. The only legitimate way to
>>> acquire the right to use an IP adress block is to show
>>> technical justification to an RIR. The only legitimate
>>> transfer of right to use an address is one that transfers
>>> network assets, or one that has an RIR as one of the two parties.
>>>
>>> --Michael Dillon
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.