[arin-discuss] IPv6 as justification for IPv4?

[Owen DeLong]

> Here is current schema, and historical data for reference (5 fee bands):
> http://www.ripe.net/ripe/docs/ripe-566
> 
> So, RIPE members voted for flat fee structure, where each member pays exactly same amount of money, plus fixed fee per each PI object.
> AS numbers are excluded from fee calculation.  So, one obtains addresses on need, and money is not a concern at all.
> 

IMHO, the current RIPE fee structure only looks good when placed next to the previous one.

> Right now, ARIN members vote the same but pay depending on their allocations.  New RIPE approach essentially aligns vote and payment.

I would certainly not favor a scheme where increased fees created increased voting rights because we already have an issue with the perception that large players dominate the ARIN process(es). Currently, it's a perception issue. Such a scheme would move it from perception problem to reality.

>> It's extremely important because there is a macroeconomic impact of the current nibble policy as well as the fee structure. ARIN policy effectively created Matthew's position in the same way as Sarbanes Oxley (policy) created an entire cottage industry of document retention. Matthew is my example because he held his organisation up as one. 
> 
> So, speaking of nibble policy (I am not exactly sure what is it) - which bad effects does it have, in your opinion?

ARIN policy calls for issuing IPv6 allocations and assignments on nibble boundaries. The next step up from a /48 is a /44, then /40, /36, etc. A nibble is 4 bits (half a "byte" so to speak, or a single hex digit). It also provides for ISPs to do nibble-boundary round-ups at one aggregation layer within their networks.

This lends itself to reducing human factors errors, simplifies the registry and DNS, and allows providers to do better aggregation planning and simplify their network deployments, if desired.

I suggest you review NRPM section 6 for more details.

>>> What you are talking about here is a serious issue. I agree wholeheartedly that ARIN needs to fix the chicken/egg problem that currently exists with new entities. However, that has absolutely nothing to do with your argument above. If a organization is being denied IPs from their upstream provider, it means that the upstream provider is dumb. They either are not properly managing their IP space, or are simply refusing because they feel like it. Do you think that changing the upstream providers fees from $32,000/year to $1,000,000/year is going to change that?
>> 
>> If that cost per pegged to something linear for the provider that is a fixed cost and would more likely become one for their end users. Right now for a provider like AT&T that cost is totally arbitrary. They have multiple /8's but they charge over $1,000 a year for a few static IPs that they aren't even paying a penny for. And like many providers their size they are a decade behind many of us on this list in IPv6 deployment. 
> 
> So, if we make everybody to pay same amount of $ for IP address regardless size of allocation, it would discourage address resale
> and hoarding, at a cost of increasing fees of "big, bad" ISPs by factor of thousands.  Is that a good way to solve a problem? (Methinks, no.)

Applying linear fee escalation to something which is clearly not a linear cost escalation (in fact, quite far from it) is absurd. In spite of Mr. Carpenter's claim to the contrary, ARIN has released the data he claims they do not have and the current fee structure is based on that data.

> My suggestion would be to make it easier to obtain initial allocation (and perhaps make it smaller - say, /23 - and perhaps remove restriction on
> multihoming - allowing new ISPs with no immediate need of /22 to get started on their own IP space.

I don't think it makes sense to issue ISP allocations smaller than /22 in most cases. 

> Tying IPv4 requests to existing customer base of IPv6 users is interesting idea, but it may be different to quantify in policy.

I think there are better ways to fix the immediate needs (and more importantly, the general IPv4 policy).

I think the real problem here is requiring pre-existing PA space of certain amounts as the initial test. The combination of a customer base, need,  and efficient utilization of any PA space is probably the better test.

Owen