[arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization

[tvest at eyeconomics.com]

Hi Milton,

I'll grant that some of the recent exchanges could be loosely  
construed to support the claim that a "complete breakdown of the needs- 
based allocation principle" has occurred -- especially if one had  
already decided a priori that that NBA principle was false or  
illegitimate or inferior to some preferred arrangement. However, your  
claim is false -- and even your premises are false.

First of all, the logic that you use here would have also implied that  
the shift from classful allocation to CIDR, and the establishment of  
the RIRs themselves also counted as clear evidence of a "complete  
breakdown." Things change, alas, and any entrepreneur that doesn't  
recognize and prepare in advance for changes in the primary  
constraints that shape their environment is probably going to be  
frequently "shocked, terribly shocked" by all sorts of complete  
breakdowns. In the real world, their redemption would require a lot  
more than just the ossification of address management policies.

More fundamentally, your attempts to reduce the relevance of needs- 
based allocation to "scarcity management" is wrong-headed on multiple  
counts. The basic goal/rationale for coordinated management of IP  
number resources is to *mitigate* the risks and reduce/postpone the  
likely impacts of a range of systemic imbalances in the Internet's  
decentralized routing system -- including the opposing problems of  
*underuse* and *overuse* of both shared and/or collectively produced  
resources, i.e., of both IP addresses and routing system carrying  
capacity.

As many recently established industry members can tell you (and I'd  
bet the vast majority of members of recently established RIRs can tell  
you from personal experience), risks of underuse of both kinds of  
resources are reduced by the presence of the RIRs as an "IP address  
distributor of last resort." And, as you have noted, the existing  
system is also well-suited to managing the risks of IP address  
overuse, and hence premature exhaustion. What you clearly fail to  
recognize, however, is that the coordinated management system is also  
uniquely well-adapted to reducing the risks of overuse of that other  
"shared" resource, i.e., routing system capacity. In this sense, the  
"needs assessments" that you fixate on are nothing more than proof of  
the "capitalization" of the ISPs that are seeking to obtain IP number  
resources. The required evidence of investment and beneficial control  
(in some form) of, e.g., hardware, a home for the hardware, people to  
look after the hardware, raw network elements to connect the hardware  
to the rest of the Internet, serves as proof that the aspiring address  
and routing capacity consumer has skin in *this* game. Proof that they  
have a nontrivial private stake in the shared system that they will  
henceforth be a free, large self-determining autonomous agent -- a  
stake that would be at risk if the shared system is damaged or fails  
altogether -- tends to align private incentives and behavior in ways  
that are consistent with the preservation and continued functioning of  
that shared system over time. *This* assurance, and the resulting  
alignment of incentives represents, IMO, the single most important  
factor that has enabled the decentralized, self-governing Internet to  
continue working so well over time.

Granted, this arrangement is far from perfect perfect -- and the  
looming discontinuity in addressing formats is going to test the  
system like nothing before in Internet history -- but from where I sit  
this arrangement looks like the most freedom-preserving option  
available to all direct and indirect Internet stakeholders everywhere.  
In other words, if and when it changes, I wouldn't bet on that change  
leading to greater access to or freedom of anything good (addressing,  
routing, privacy, openness, individual empowerment, competition,  
commercial strategy, cross-border transparency, etc., etc.).

(Close observers of the recent/ongoing financial crisis may have noted  
that the primary mechanism through which the perverse synergies of  
CDOs and CDSs contributed the current unpleasantness was by enabling  
financial institutions to fabricate their own capital reserves  
virtually at will, which effectively negated the formal "skin in this  
game" regulations that had previously incentivized them to act  
prudently -- but that too is a story for another time/place).

This failure to appreciate the subtleties of how this industry works,  
and how the IP number resource coordination mechanisms help it to keep  
working is not entirely surprising, but I would strongly recommend  
that you consider doing a bit more research before you submit another  
routing and addressing system proposal to the ITU or any other  
institution. For example, in the "transferable address block lease"  
plan that you recently recommended to the ITU [1], you propose  
creating auctions which could grant any private commercial entity the  
means to resell up to (4 x /32) or about one-quarter million /48 IPv6  
prefixes -- i.e., to effectively charter as many as one-quarter  
million new, fully autonomous participants in the shared routing  
system. Your plan would relieve those hundreds of thousands ~ millions  
of new participants of any/all requirements to demonstrate technical  
need or anything else that might attest to any material interest in  
the continued survival of the routing system (presumably -- unless of  
course you imagine that each of those PI /48s would cost as much or  
more that the hardware and other inputs required to make them  
useful?). And yet you claim that this change "would not make the  
current system any worse or any better with respect to routing table  
growth"...? I guess that assertion alone speaks for itself.

If this understanding of how needs-based allocation actually works is  
still unclear, perhaps it would be easier to think of it in more  
familiar terms, e.g., as IP address allocation through a process of  
"vibrant (but very slow) facilities-based competition" -- albeit in  
this case with facilities that are freely available to anyone at  
competitive open market prices.

Enough for now -- I'll leave list members to learn more on their own  
about your unique views on what constitutes legitimate "registry  
functions" and "rules of good conduct," and how these would be  
translated/implemented through your routing, addressing, and registry  
proposal.

Regards all,

TV

[1] Section 3.3., "The Transferable Address Block Lease (TABL)," in  
Mueller, "Economic Factors in the Allocation of IP Addresses."
http://www.itu.int/net/ITU-T/ipv6/
http://www.itu.int/dms_pub/itu-t/.../T3B020000020003PDFE.pdf

On Oct 10, 2009, at 8:19 PM, Milton L Mueller wrote:

> I haven't intervened in this debate even though it is a highly  
> interesting one. One element seems to be lacking from the  
> discussion. To me, it is an incredibly clear demonstration of the  
> complete breakdown of the needs-based allocation principle as soon  
> as scarcity arises.
>
> What Michael Dillon has been saying, in effect, is that  
> organizations that can demonstrate a perfectly viable technical  
> "need" for IPv4 addresses shouldn't get them.
>
> Maybe this is so obvious to all of you that it's going unstated, or  
> maybe its an unstated assumption and it will clarify debates going  
> forward if this is more openly acknowledged.
>
> If you abandon "demonstrated need" and are _not_ willing to use  
> prices or some other neutral, market-based rationing principle, then  
> all that is left is finer and finer classification and  
> prioritization of specific uses. And down that road lies a form of  
> ever more intrusive central planning. I.e., the RIR has to step in  
> and decide for organizations whether it is better for them to base  
> their plans on IPv4 or to re-engineer their plans based on a  
> migration to IPv6.
>
> However you resolve such a debate, let's at least openly recognize  
> and acknowledge that "need" is gone as a rationing principle.
>
> --MM
>
>> -----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: Saturday, October 10, 2009 12:34 PM
>> To: ppml at arin.net
>> Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to
>> somecategoryof organization
>>
>>> In terms of policy  "embedded device"   seems like a good point to
>>> identify in policy for denying massive V4 allocations.  We
>>> certainly don't need need to be writing another policy in 6
>>> months when
>>> technology X   in industry B  is in a similar position.
>>
>> There seems to be some level of support for a policy which
>> restricts the amount of IPv4 addresses that can be
>> allocated for the purpose of embedded system devices that
>> are not conventional PCs or servers.
>>
>> Since one might expect that there would be no issues with
>> giving these devices globally registered IPv4 addresses
>> *AFTER* the transition to IPv6, it seems wiser to phrase
>> this as a limited time moratorium rather than an outright
>> ban. The immediate effect is the same, but we can make sure
>> that it expires automatically when people's attention is
>> placed on more pressing IPv6 related issues in the future.
>>
>> Does anyone have ideas on how to word such a policy, where
>> to put it in the NRPM, etc.?
>>
>> --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.