[arin-ppml] Opposed to 2010-9 and 2010-12

[Tony Hain]

At the end of the day, ARIN really has to take a hands-off approach and let
the market sort out bad behavior. While I would like to see someone that is
locked into 6rd pay substantially more than someone offering a /48 to every
customer (because I want the space in the home to innovate), that is a
market decision to sort out. If the fee structure gets too wound around
block size in an attempt to drive out 6rd, the unintended consequence will
be that smaller providers will opt for the minimum size block and reduce the
prefix space they allow a customer  to have. This is counterproductive, and
economically punishes a /48 provider for the sins of the lingering 6rd
provider. 

 

Putting in hard dates to try to sunset an address range will just lead to
endless debate. Putting in an explicit cost that is only borne by those who
need the crutch will result in a natural weaning.  As much as I don't want
to see 6rd in a different prefix range, maybe that is the out here. Create a
specific fee schedule for a dedicated use prefix range, which would enable a
path forward in the short term at the same time it motivates providers to
get off of the technology asap. 

 

To avoid blocking small players from getting started, the fee would need to
be fairly low. A fee that is significantly less than a rounding error for a
large provider will not provide incentive to move. Finding the middle ground
... start with a modest fee, then after 3 years double the fee for
allocations within the 6rd prefix every year. Anyone with an IPv4 allocation
can get a 6rd /24 and keep it as long as they are willing to pay the
doubling fee. Any other IPv6 allocation they have would fall under the
current fee structure.

 

Tony

 

 

From: Milton L Mueller [mailto:mueller at syr.edu] 
Sent: Sunday, October 24, 2010 12:07 AM
To: Tony Hain
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] Opposed to 2010-9 and 2010-12

 

 

.financial backpressure will be much more effective than any proscriptive
language that makes it past ppml. 

 

This is definitely true

 

The hardest part of that approach is that the fee for a provider that is
offering dual-stack /48 to each customer should be substantially less than a
6rd deployment offering /60. It is not ARIN's role to define end  product
offerings, so differentiating the fee schedule for 2 ISPs requesting a /28
based on how they plan to use it is probably out of the question.

 

So how do you get your escalating fee structure without doing that? This
sounds like a hard problem, administratively and economically. And you're
right, once the fees are set they will establish parameters around which
implementations are incentivized. I can't tell from all the list noise where
things are going but it does seem to me that policy and fees are becoming
more closely related all the time, which may require another look at ARIN's
separation of the two. 

 

--MM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101025/2115eb65/attachment.htm>