[arin-ppml] "Leasing" of space via non-connectivity providers

Ted Mittelstaedt tedm at ipinc.net
Thu Feb 3 16:02:34 EST 2011

I concur 100%.  If your in favor of reclamation or other stretching out
of IPv4 usage then leasing arrangements allow unused IPv4 to go into
use.  If your opposed to reclamation and just want IPv6 to go on as
soon as possible, then leasing arrangements help to drive up the cost of 
IPv4 much more rapidly as they allow orgs to monetize IPv4.

The real losers in any IPv4 leasing arrangement are the ISP's that
are the actual lessors.  The problem is that those ISP's don't believe
that they are losing when they are able to get additional IPv4.  They
are convinced that their future is rolling out more IPv4 so they sink
a lot of capital into leasing IPv4 from others - instead of sinking it
into building out their IPv6 presence.

So then what will happen is that when the day comes that IPv6 becomes
de rigueur, those leasing ISP's will be so invested in an obsolete
infrastructure that they will quickly go out of business.  That will
then take choice away from customers who will then be forced into IPv6.
Once those customers make the transition they will never go back and
will just increase pressure for everyone to go to IPv6.

So what's not to like about such arrangements?


PS  Historical instruction can be obtained by examining the VHS vs 
Betamax wars.  For a while both formats had equal market share - but 
when the customers in the market all SENSED the inevitability of VHS, 
then within a very short time Betamax disappeared  - much to the 
consternation of betamax users who had invested significantly in it.

On 2/3/2011 12:19 PM, Scott Leibrand wrote:
> I would be very reluctant to make any rules around this, at least until
> we have real-world examples of leasing behavior causing significant
> issues that can't be dealt with through normal processes.  As long as
> number resources are being put to productive use, and the whois database
> is kept up-to-date with regards to who's actually using the space, I'd
> be hesitant to try to micromanage the arrangements between consenting
> parties...
> -Scott
> On Thu, Feb 3, 2011 at 10:49 AM, William Herrin <bill at herrin.us
> <mailto:bill at herrin.us>> wrote:
>     Note: moved this to the ARIN PPML list from NANOG.
>     On Thu, Feb 3, 2011 at 11:54 AM, John Curran <jcurran at arin.net
>     <mailto:jcurran at arin.net>> wrote:
>      > For the ARIN region, it would be nice to know how you'd like ARIN
>     perform
>      > in the presence of such activity ("leasing" IP addresses by ISP
>     not providing
>      > connectivity).  It's possible that such is perfectly reasonable
>     and to simply
>      > be ignored, it's also possible that such should be considered a
>     fraudulent
>      > transfer and the resources reclaimed.  At the end of the day, the
>     policy is
>      > set by this community, and clarity over ambiguity is very helpful.
>     Options:
>     1. Whatever arrangements work out in the market are fine, including
>     leasing.
>     Pros: Noninterference. Let's the market do its thing.
>     Cons: Contrary to the needs basis we've adhered to for the last 20
>     years. The the end user needs the addresses enough to pay the price
>     and the lessor can spare them then obviously the end user needs those
>     addresses, not the lessor.
>     2. Address leasing is not allowed. Must get your addresses from a
>     primary or at least major bandwidth provider. Addresses found to be
>     leased or provided in with a paper-tiger transit arrangement are
>     subject to reclamation by ARIN.
>     Pros: Keeps the market more or less honest. IP addresses are a public
>     resource; they don't belong to you. As incentive to put your uneeded
>     addresses back into the supply, you're allowed to sell them at
>     market... but you don't get to be like the landlords of Europe that
>     prompted the 19th century emigration to the Americas, refusing to sell
>     to the folks living on the land at any price.
>     Cons: Unenforceable.
>     3. Any multihomed registrant using an ARIN AS number and SWIPed for at
>     least one year with a /24 or larger is entitled to convert the
>     registration to an ARIN direct assignment upon filing the proper
>     paperwork. Refusing SWIP or assigning addresses out of region is
>     grounds for reclamation.
>     Pros: Lets the original registrant earn his money but guarantees that
>     address assignments will move towards the multihomed end users.
>     Cons: Fragmentation. No way to ever move growing entities from
>     individual /24's to aggregable address blocks. Have to hope the IPv6
>     migration solves this problem before it can get serious. Also, it
>     implies a change in ISP's internal routing management. These new
>     registrations are functionally different from older direct
>     registrations - they'll likely still be subject to some ISP's covering
>     route, even though they're no longer used with that ISP.
>     Any other sensible ways to slice and dice the issue?
>     Regards,
>     Bill Herrin
>     --
>     William D. Herrin ................ herrin at dirtside.com
>     <mailto:herrin at dirtside.com> bill at herrin.us <mailto:bill at herrin.us>
>     3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>     Falls Church, VA 22042-3004
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto: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 <mailto:info at arin.net> if you
>     experience any issues.
> _______________________________________________
> 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