[arin-ppml] Policy Proposal: Depleted IPv4 reserves

Tom Vest tvest at pch.net
Wed Dec 3 10:23:45 EST 2008


On Dec 3, 2008, at 9:14 AM, Kevin Kargel wrote:

>> -----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: Wednesday, December 03, 2008 5:04 AM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Depleted IPv4 reserves
>>
>>> Besides, a "plan" in this context is nothing more than a
>>> promise. Is ARIN in any position to realistically assess the
>>> credibility or appropriateness of an ipv6 migration plan for
>>> hundreds or thousands of small organizations? Is this a good
>>> use of its resources? Is it in any position to enforce such
>>> promises? If not, what is the point of such a requirement?
>>
>> It's like banking. When a small business comes in and asks
>> the banker for a bridging loan, is the bank really in a
>> position to realistically assess the credibility of the plan?
>> Are they in any position to enforce the small business owner's
>> promises? No, and no.
>>
>
> [Kevin says:] I don't understand this argument at all..  The bank
> doesn't care one whit what the customer uses the money for..  the bank
> only cares about whether or not the customer will repay the loan on
> schedule with interest.
>
> The comparisons between an IP registry and financial lending
> institutions just don't fly..

The point is that as long as IPv4 is non-substitutable, then RIRs and  
LIRs need to manage IPv4 allocations/assignments the same way that  
banks manage credit creation (i.e., lending, etc.). There are at least  
two levels of constraint that both have in common.

At the LIR/IP assignment level, the "bank" may not care about anything  
other than the ability of the customer to make monthly payments.  
However, if the revenue that the customer produces is actually related  
to that IPv4 assignment -- i.e., it's coming from some kind of online  
content or service -- then that scarce credit/IPv4 allocation is being  
used "productively," it's contributing to the satisfaction of some  
Internet-related demand, and probably one that either makes money or  
saves money in some way. If this is true, then then IPv4 consumed by  
that assignment for that particular application/service shouldn't have  
to be duplicated in the future; the rest of the IPv4 pool can be saved  
for additional, similarly unique requirements. Sure, that original  
requirement may grow, sure the requirement might have been private/ 
internal-only, but that *specific one* should be satisfied. By  
contrast, If the IPv4 could just be hoarded without consequence, then  
that would not be true.

As you rightly note, most banks don't care (or care as much) about how  
the money gets used  -- and that is why entry and participation in the  
banking industry is regulated. In order to establish a bank, one has  
to satisfy certain capitalization requirements that are functionally  
equivalent to the sorts of things that RIR hostmasters demand proof of  
when someone is seeking an initial IP number resource allocation. In  
both cases, they demonstrate that the aspiring new entrant possesses  
the means to use the power of lending / credit creation -- which is  
the primary function of banks -- "productively." It also demonstrates  
that they have put chips into the *relevant* game, i.e., Internet  
service delivery.

That entry or eligibility requirement is not sufficient in itself to  
guarantee that a bank will, in fact, use this power prudently  
(obviously), which is why two other ongoing requirements are imposed  
on banks: capital reserve requirements, and periodic reporting  
requirements. Credit allocation and IP resource allocation/assignment  
are critical economic functions in the exact same way. If you do just  
the right amount, in the right distribution pattern, then the overall  
economy hums along nicely. Do it too sparingly or too restrictively,  
and some people that might be able to productively participate in the  
economy are excluded, with the result that they have to find other  
ways -- or other economies -- in which to participate. The common word  
for this phenomenon is "deflation." Conversely, allocate it too  
profligately and you begin to tax the carrying capacity of the overall  
system, and thereby reduce the value of everyone else's monetary/IP  
resources, in a process more commonly described as "inflation." In our  
world it takes the form of routing table "bloat."

If too many lenders err too far in either extreme, then the overall  
system may collapse altogether, which is why bank regulators also  
impose capital reserve requirements (to indirectly modulate the rate  
of credit creation), and periodic reporting requirements, so that  
there is some possibility of catching institution-level problems  
before the rise to the level of system-level risks.

Obviously, recent developments make it clear that such indirect  
regulatory mechanisms do not provide an absolute guarantee of safety  
or stability. If some industry participants are hellbent on acting in  
self-destructive ways, and there is insufficient transparency for  
regulatory or "counter-party" scrutiny to deter them, and/or no means  
to do anything about it, then that industry and everyone relying on it  
is absolutely at their mercy. Maybe it'll collapse today, or next  
month, or next year, or maybe not... not the sort of condition that  
most investors, entrepreneurs (other than speculators), or "users"  
find especially attractive...

Needless to say, IPv6 can't and won't solve all the problems of the  
Internet, but it could solve this particular one.

TV


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




More information about the ARIN-PPML mailing list