[arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate

[Larry Ash]

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