[arin-ppml] IPv4 Transfer Policy Change to Keep WhoisAccurate

[Mike Burns]

Hi Larry,

A quick point:

1. No, you can't do that many addresses (65555 /20's), as I wrote the 
proposal it's a /12 equivalent max transfer without needs.

I was unclear in my introductory post about the /12, sorry for that.

Regards,
Mike

----- Original Message ----- 
From: "Larry Ash" <lar at mwtcorp.net>
To: "Mike Burns" <mike at nationwideinc.com>; "Sweeting, John" 
<john.sweeting at twcable.com>; <arin-ppml at arin.net>
Sent: Wednesday, May 18, 2011 1:12 PM
Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep WhoisAccurate


>
>>
>> The objections I have noted seem to fall in three categories:
>>
>> 1. That's not the way we have historically dealt with addresses.
>> 2. It could lead to disaggregation
>> 3. Hoarders and speculators will appear and will unfairly manipulate 
>> price.
>>
>> As far as 1, my argument is that the historical method was appropriate 
>> for free pool allocations, as it provided the necessary constraint for 
>> doling out valuable resources without a price. The economic concept of 
>> the Tragedy of the Commons holds that without any constraint, that the 
>> resources would be overconsumed. In our world, this would mean that 
>> people would grab more addresses than they could use, unless we 
>> constrained them by demonstrated need. In a post-exhaust world, price 
>> would impose that constraint. Our job as stewards is to make policy to 
>> ensure accurate Whois, and to end policies which provide disincentives 
>> for under-utilized addresses to enter the market, driving up price. Needs 
>> requirements designed to constrain the delivery of free pool addresses 
>> are no longer required for stewardship, and maintaining them for 
>> transfers threatens Whois accuracy, whose stewardship we maintain.
>
> This is a "toothpaste tube" moment. If we let you squeeze the toothpaste 
> out
> of the tube we can't put it back. Most of your arguments seem more 
> philosophical
> than anything. I don't care a whit about how we used to do it BUT the long 
> standing
> goal of good stewardship still apply. Free pool run-out has nothing to do 
> with that.
>>
>> As far as 2, this danger seems to be manageable, and there haven't been 
>> too many objections related to this lately. I have argued that the 
>> stewards of the APNIC region, led by Geoff Huston, considered this 
>> problem when deciding whether to have needs requirements on transfers, 
>> and decided the benefits to Whois accuracy outweighed the potential 
>> disaggregation problems. This cost is borne most by network operators, 
>> who presumably can make decisions on minimum block size which will allow 
>> them to run profitably. Those decisions will likely shape the transfer 
>> market, so nobody expects there to be much value in a /32 netblock, 
>> because network operators find this size unprofitable to route today. 
>> This ability of network operators provides a constraint on disaggregation 
>> in the transfer market.
>
> I think not!! Disaggregation is a table top issue that only becomes a big 
> issue
> when we go over the edge. It has been raised and argued on this list 
> almost
> as much as the benefit/disadvantage of NAT and whether a supply demand 
> curve really
> works for ip addresses.
>
> Whois accuracy is a straw man argument. The Whois database will remain 
> fairly accurate
> in both scenarios because most of us want it to. Those that have something 
> to hide do
> and will avoid or obfuscate the entries.
> Hiding number utilization probably won't be high on the list of why they 
> do it either.
> I have no idea why APNIC made the decisions they did. To be honest I don't 
> care
> but so far my experience of tracing problems coming from there have not 
> been
> productive. The problem networks don't seem to be listed in whois? Go 
> figure.
>>
>> And as far as 3, I have argued that speculators provide a value to free 
>> markets, that most attempts to corner markets fail, that supply 
>> uncertainty and IPv6 deployment provide a poor environment for 
>> speculators. But inasmuch as this forum is populated by technical types 
>> who are making decisions here based on their understanding of, and 
>> philosophy of, economics, I have decided to take David Farmer's advice 
>> and add an anti-speculator, anti-hoarder protection in the form of a 
>> limit of a /12 equivalent for needs-free transfers per 12 month period. 
>> If more transfers than that are desired, the recipient will have to 
>> demonstrate need.
>>
>
> It seems to me that the whole issue comes down to the proposition that by 
> having
> a monetary value for ip addresses (either the addresses or license
> to use) you philosophically believe that the supply will be increased.
>
> Classical supply/demand theory argues that price is an efficient allocator 
> because
> as price for widgets goes up, some suppliers of bonkos will divert 
> resources used
> to manufacture bonkos to building widgets and the supply will go up 
> relieving the
> price pressure and establishing equilibrium at the most efficient mix of 
> bonkos vs widgets.
>
> When supply is fixed the whole issue becomes much more cloudy and the 
> market behaves
> in a much more complex and less predictable manner.
>
> I encourage each person to think carefully and ask themselves what 
> addresses could
> he/she part with if the price was high enough and what would that price 
> be.
>
> Even if I had a bunch of extra space it would have been cut up into small 
> pieces and I'd
> have to renumber some customers to liberate it. I have renumbered 4 times. 
> Three in
> PA on once into PI. It would not be worth it at 10 times what MS paid for 
> the Nortel
> addresses per IP. Other than liquidating a failing business or shedding an 
> orphan /23
> or /24 I don't see price shaking loose many addresses. During liquidation 
> addresses
> will come available and when a large block is involved there will be 
> publicity but
> I see that as the exception rather than the rule.
>
> What I do see is as the price goes up a group of individuals will try and 
> find and reclaim
> abandoned or lost blocks that have fallen between the cracks. The more 
> unscrupulous will
> move in and try to reclaim blocks that are not announced even if they are 
> in use. ARIN
> could find themselves spending more time trying to figure our who has the 
> rights to a block
> that they did assigning numbers in the past. Personally I'd rather task 
> ARIN to try and
> reclaim them rather than every hustler that thinks he can make a million 
> reclaiming unused IP addresses.
>
>
>
>
>
>> As a whole, then, my policy seeks to recognize that there are transfer 
>> transactions which provide incentives for buyers and sellers of addresses 
>> but which transactions may not meed the needs requirements which ARIN 
>> mandates for transfers. Additionally, I pointed out that network 
>> operators, in my experience, will route addresses whose Whois record does 
>> not reflect that the network operator's customer is the registrant. The 
>> network operator, in my experience, will normally check to make sure that 
>> nobody else is advertising the addresses, and will solicit from the 
>> customer some documentary evidence that the customer has the right to the 
>> route the addresses, and then the network operator will route the 
>> addresses.
>>
>> The net effect of these types of transactions is a lack of trust in the 
>> Whois table as an accurate source to check for authoritative routing 
>> rights. My proposal seeks to reduce the harm to Whois accuracy by 
>> extending the range of allowable transactions, providing additional 
>> incentive to have transfers reflected accurately by ARIN's updating of 
>> Whois to reflect the transfer.
>>
>> As we move into a trading world, which will happen whether or not my 
>> proposal passes, conflicts over address control are likely to increase, 
>> and the value of trust in Whois as the routing authority will also 
>> increase. Rather than sit back and watch Whois decay, I urge ARIN 
>> stewards to consider making these changes to foster accuracy in Whois.
>>
>> Regards,
>> Mike
>>
>> PS I will change the name to Removing the needs requirement for IPv4 
>> transfers smaller than a /12 and send it in today.
>>
>
> So I don't have to tell why I want 65535 /20's just as long as I don't go 
> after a /12?
>
> Before we squeeze all of the toothpaste out of the tube, it seems we could 
> lower the bar
> and see if anything bad happens.
> Changing the horizon for transfers to 12 month instead of 3 months is a 
> step that way.
> Maybe the 80% rule could be lowered to 70% when evaluating past 
> utilization?
>
>
>
>
>
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: "Sweeting, John" 
>> <john.sweeting at twcable.com>
>> To: "Mike Burns" <mike at nationwideinc.com>; <arin-ppml at arin.net>
>> Sent: Wednesday, May 18, 2011 10:32 AM
>> Subject: Re: [arin-ppml] IPv4 Transfer Policy Change to Keep Whois 
>> Accurate
>>
>>
>> Hello PPML,
>>
>> I wanted to take a second to provide some clarity on this particular 
>> email thread to ensure that everyone's expectations are the same. ARIN 
>> Staff touched base with the Proposal Originator (Mike Burns) and it was 
>> confirmed by Mike that his intent on sending this to PPML was not to 
>> formally submit it but to get feedback from the community prior to 
>> formally submitting. With that in mind, this proposal has not been 
>> assigned a Policy Proposal number as yet and AC shepherds have not been 
>> assigned.
>>
>> Thanks,
>> John
>> AC Chair
>>
>>
>> On 5/11/11 2:03 PM, "Mike Burns" <mike at nationwideinc.com> wrote:
>>
>> 1. Policy Proposal Name: IPv4 Transfer Policy Change to Keep Whois 
>> Accurate
>>
>> 2. Proposal Originator:
>>      a. Name: Mike Burns
>>      b. Email: mike at sum.net <mailto:mike at sum.net>
>>     c. Phone: 1-863-494-7692 x105
>>      d. Organization: Nationwide Computer Systems
>>
>> 3. Proposal Version: 1
>>
>> 4. Date: May 11th, 2011
>>
>> 5. Proposal type: modify
>>
>> 6. Policy term: permanent
>>
>> 7. Policy statement:
>>
>> Replace Section 8.3 with
>>
>> 8.3 ARIN will process and record IPv4 address transfer requests.
>>
>> Conditions on the IPv4 address block:
>>
>>    - The minimum transfer size is a /24
>>
>>    - The address block must be in the range of addresses administered
>>      by ARIN
>>
>> Conditions on source of the transfer:
>>
>>    - The source entity must be the current rights holder of the
>>      IPv4 address resources, and not be involved in any dispute as to
>>      the status of those resources.
>>
>>    - The source entity will be ineligible to receive any further IPv4
>>      address allocations or assignments from ARIN for a period of 12
>>      months after the transfer, or until the exhaustion of ARIN's
>>      IPv4 space, whichever occurs first.
>>
>>      - The source entity must not have received an allocation from ARIN 
>> for the 12 months prior to the transfer.
>>
>>
>>  Conditions on recipient of the transfer:
>>
>>    - The recipient entity must be a current ARIN account holder.
>>
>>    - The recipient must sign an RSA with ARIN.
>>
>>    - The recipient entity of the transferred resources will be subject
>>      to current ARIN policies. In particular, in any subsequent ARIN
>>      IPv4 address allocation request, the recipient will be required
>>      to account for the efficient utilization of all IPv4 address
>>      space held, including all transferred resources.
>>
>> and request the AC to modify section 8 of the current RSA to remove 
>> references to "intended purposes."
>>
>> Replace
>> ARIN may review, at any time, Applicant's use of previously allocated or 
>> assigned number resources or Services received from ARIN to determine if 
>> Applicant is complying with this Agreement and the Policies and is using 
>> the Services for their intended purposes.  Without limiting the 
>> foregoing, if Applicant is a holder of a direct allocation or assignment 
>> from ARIN, Applicant agrees that it will use the number resources solely 
>> for uses consistent with its application and this Agreement, including, 
>> for example, its internal infrastructure or to provide Internet access to 
>> its customer base. If ARIN determines that the number resources or any 
>> other Services are not being used in compliance with this Agreement, the 
>> Policies, or the purposes for which they are intended, ARIN may: (i) 
>> revoke the number resources; (ii) cease providing the Services to 
>> Applicant; and/or (iii) terminate this Agreement.
>>
>> with
>>
>> ARIN may review, at any time, any Applicant's use of previously allocated 
>> or assigned number resources or Services received from ARIN to determine 
>> if Applicant is complying with this Agreement and the Policies.  Without 
>> limiting the foregoing, if Applicant is a holder of a direct allocation 
>> or direct assignment from ARIN, Applicant agrees that it will use the 
>> number resources solely for uses consistent with this Agreement, 
>> including, for example, its internal infrastructure or to provide 
>> Internet access to its customer base. If ARIN determines that the number 
>> resources or any other Services are not being used in compliance with 
>> this Agreement or the Policies, ARIN may: (i) revoke the number 
>> resources; (ii) cease providing the Services to Applicant; and/or (iii) 
>> terminate this Agreement.
>>
>> and add to the NRPM Section 12:
>>
>> 10.    ARIN will not use utilization as a measure of policy compliance 
>> for addresses transferred under 8.3.
>>
>>
>> 8. Rationale:
>>
>>
>> Current ARIN policies relating to the registration of transfer of
>> address holdings limit the eligibility of registration of transfers to
>> those relating to mergers and acquisitions of entities that are
>> administering an operational network, or to those who agree to
>> sign either an RSA or LRSA with ARIN and subject the buyer
>> to needs analysis and the seller to a potential ARIN review under RSA 
>> section 8.
>>
>> It is currently anticipated that the IPv4 unallocated address pool
>> will be exhausted within a couple of years at ARIN, and earlier
>> than that in other regions, and the  transition to IPv6-based service 
>> delivery
>> is likely to take longer than the remaining period of unallocated
>> address availability. Accordingly, it is likely that demand for IPv4
>> addresses will continue beyond the time of unallocated address pool
>> exhaustion, leading to a period of movement of IPv4 address blocks
>> between address holders to meet such continuing demand for IPv4
>> address blocks.
>>
>> The underlying proposition behind this policy proposal is that the
>> registry of IPv4 addresses operated by ARIN is of general utility and
>> value only while it accurately describes the current state of address
>> distribution. If a class of address movement transactions are excluded
>> from being entered in the registry, then the registry will have
>> decreasing value to the broader community, and the integrity of the
>> network itself is thereby compromised.  This proposal's central aim is
>> to ensure the continuing utility and value of the ARIN address
>> registry by allowing the registry to record transactions where IPv4
>> addresses are transfered between ARIN account holders.
>>
>> It proposes that ARIN will recognise and register a transfer of
>> addresses where the parties to the transfer are 'known' to ARIN and
>> that the address block being transferred is part of ARIN's current 
>> address set.
>>
>> The proposal does not prescribe how such transfers may occur, nor
>> impose any further constraints on the transfer or on the parties
>> involved other than those described in this proposal.
>>
>> 9. Timetable for implementation: immediate.
>>
>>
>>
>> ________________________________
>> This E-mail and any of its attachments may contain Time Warner Cable 
>> proprietary information, which is privileged, confidential, or subject to 
>> copyright belonging to Time Warner Cable. This E-mail is intended solely 
>> for the use of the individual or entity to which it is addressed. If you 
>> are not the intended recipient of this E-mail, you are hereby notified 
>> that any dissemination, distribution, copying, or action taken in 
>> relation to the contents of and attachments to this E-mail is strictly 
>> prohibited and may be unlawful. If you have received this E-mail in 
>> error, please notify the sender immediately and permanently delete the 
>> original and any copy of this E-mail and any printout. 
>> _______________________________________________
>> 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.
>
> Larry Ash
> Network Administrator
> Mountain West Telephone
> 123 W 1st St.
> Casper, WY 82601
> Office 307 233-8387