[arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised

Kevin Kargel kkargel at polartel.com
Thu Jan 15 12:44:46 EST 2009


I am vigorously opposed to ANY incentive based on artificial fees for the
sole purpose of controlling behavior.  This is nothing more than a punitive
fine for good behavior.  If you have enough money in your budget to
incentivize yourself this way go ahead, you can send it to me and I will
happily relieve you of the burden of excess wealth, but please do not try to
destroy my business to solve the problem.

Work with carrots, quit hitting me with sticks..  if you hit folks with
sticks enough they will start hitting back.

There is nothing making ARIN an authority other than cooperation.  If you
de-incent people enough they will stop cooperating and any authority will
evaporate.  There is nothing stopping any large (or even small) group of
ISP's from forming ARIN2 and setting up their own authority and routing.  It
will screw the internet for a while but if the folks are screwed because
they can't afford IP's anyway then they won't care.  If you leave folks
without a choice they may find a choice you don't like.

To illustrate this, if I have a working IP of 66.231.1.1 and my peer ISP had
a working IP of 66.231.2.1 and that's all we had, and we needed a class c
block to route between us, we *could* pick any class C block we didn't need
to talk to and set each other as the next hop address for that block and it
would route just fine regardless of what was in the public routing tables.

Then if another ISP saw what we were doing and wanted to join in they could
put in their own static routes and also talk to the class C block and maybe
abscond with a block of their own.  

The only downside is that none of the organizations involved would be able
to talk to the legitimate class C blocks without some serious router tricks.
In fact nobody would even notice unless the legitimate block tried to
communicate with the consortium.  

I realize this is not a perfect example, but it would work and it could grow
fractally.  It would be a very bad thing to do, I am advocating against
anything like this, but it is possible if cooperation breaks down.  





> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Wettling, Fred
> Sent: Thursday, January 15, 2009 8:47 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: IPv4 Recovery Fund - Revised
> 
> Bechtel Internal / Non-Record//
> 
> 
> I'm generally opposed to this ARIN Policy Proposal.  Here's why...
> 
> RIR policies should be structured, in part, to influence the desired
> long-term behavior of the supported community within the charter and
> jurisdiction of the RIR.  The desired behavior that is being addresses is
> returning unused IPv4 blocks to the ARIN pool for reallocation.
> 
> The IPv4 Recovery Fund Policy Proposal is attempting to establish a
> market-based mechanism that will, in effect, pay organizations to return
> IPv4 addresses to ARIN.  This approach will add additional administrative
> burden to ARIN and not result in the desired behavior.
> 
> Rationale:
> Organizations sitting on large blocks of unused IPv4 addresses will be
> incented to HOLD ON to the addresses until the IPv4 address scarcity
> increases and the market price if IPv4 addresses correspondingly
> skyrocket.
> This would be a one-time benefit to the "selling" organization.
> 
> An alternative would be a very substantial increase on the annual fee for
> IPv4 address holders in the large and X-Large categories (greater than
> /16).
> Consider a 5X, 10X, or larger increase to these groups, raising the Large
> annual IPv4 fee to $45-90K and the X-Large fee to $90K-180K.
> 
> Rationale:
> Organizations will be incented to released unused IPv4 blocks to avoid
> large
> RECURRING costs.  No additional administrative burden to ARIN.
> 
> Regards - Fred
> 
> Bechtel Internal / Non-Record//

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090115/c96986db/attachment-0001.bin>


More information about the ARIN-PPML mailing list