[arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
SRyerse at eclipse-networks.com
Sun Apr 7 15:33:26 EDT 2013
I agree with Mathew and CB. We do need to move away from conservation at the RIR level as a goal for both ipv4 and ipv6. Ripe is definitely on the right track with http://www.ripe.net/ripe/policies/proposals/2013-03 and I strongly support that. The same changes should happen for the Arin RIR.
The IPv6 pricing issue is a difficult one in a world that is still IPv4 oriented. We purchased an IPv6 block in the Small category (/32) from Arin last year for $2250 less the 25% discount of $562.50 for a total of $1687.50. At the time I felt that was expensive since less than 5% of Internet traffic runs on IPv6 - but that was the cost so I made a business decision to pay it. We run BGP with IPv4 and we wanted to also run BGP with IPv6 which is why we purchased the block. To my surprise – only one of my upstream providers has implemented IPv6 and of course we are in a 3 year agreement with them for their Metro-E line. They are a CLEC and they tell me that they have only had about 6 inquires about running IPv6.
So now just today I received my renewal bill for our IPv6 block and it is again for $1687.50. Now I have to make a business decision on whether to pay it and hope I can twist our CLEC’s arm to support IPv6 - or let it lapse and wait until the end of our contract and switch upstream providers - and pay for another IPv6 allocation at that time.
My preference would be to renew but not using an assigned IPv6 block for two years will costs me $3375 (even in the Small category) and if I can’t use it then I get no benefit for it. This is the real world of IPv6 and I am definitely for less expensive blocks for IPv6 and for allocations of extra small blocks of the Tiny size to further Arin’s Mission.
I am for a Tiny IPv6 option for small ISP’s - but at an attractive price - because that is in line with Arin’s mission of allocating resources. I think even with the 25% discount all of the current IPv6 prices are too high for the current value being received from them. The price should be at least somewhat in line with the value that can be derived from the IPv6 resource. Adoption of IPv6 needs to be a high priority and the best way to make that happen is to allocate IPv6 of all sizes at a maybe 50% or more discount until the adoption is at a higher percentage – maybe 15%-20% or more. I do think the entire fee Arin fee schedule needs to be enough for Arin to pay its bills.
P.S. The email I just received says at the bottom of it that the Board approved a new fee schedule in January effective July. Maybe I missed something but I didn’t see any discussion of a totally new fee schedule discussed in this forum. While I acknowledge that Arin’s Board has the right and responsibility to set fees independent of this forum – as there are a number of smart experienced folks participating in this forum – this community’s input might have helped develop a better outcome for all. I’m guessing there would have been a lot of constructive feedback provided – just like there has been on the fees portion of the Tiny IPv6 policy.
Steven L Ryerse
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax
[Description: Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of cb.list6
Sent: Sunday, April 07, 2013 1:31 PM
To: Matthew Kaufman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations forISPs
On Apr 6, 2013 10:14 PM, "Matthew Kaufman" <matthew at matthew.at<mailto:matthew at matthew.at>> wrote:
> On 4/6/2013 12:00 PM, Michael Sinatra wrote:
>> On 03/27/13 17:45, David Farmer wrote:
>>> On 3/27/13 18:00 , Michael Sinatra wrote:
>>>> Or, to put more bluntly, if ARIN's fee structure is itself creating
>>>> disincentives for proper IPv6 adoption, then let's go back and (re-)fix
>>>> that problem.
>>>> Oppose 2013-3.
>>> Michael and others opposed,
>>> What about modifying the proposal to /40, require a minimum reservation
>>> of /32 (or maybe /28) be held for ISPs that elect for /40 or /36
>>> allocations, allow subsequent allocations to expansion from /40 to /36
>>> and then to /32 without evaluating there current IPv6 usage. Thereby
>>> ensuring they can grow their allocation in place and allowing policy
>>> flexibility that enables the fee structure equity that the new xx-small
>>> category seems to provided.
>> Sorry to be responding to an earlier part of the thread, but I was on
>> vacation and lost track of this thread, and you did ask me a direct
>> question. I owe you the courtesy of an answer.
>> The answer to your question is no. If I start out with a /40 or /36 and
>> then rapidly grow into a /32 (and can justify the fees), then I am going
>> to end up with a largely organic addressing plan. We're giving
>> incentives for people to cram all of their addressing into a corner of
>> the total space that they should be using and it will create a really
>> messy IPv6 deployment.
> Worse, we're creating a messy IPv6 situation downstream... as Owen points out, this type of financial pressure towards false conservation is going to give us things like /64-per-household instead of something sensible that lets the thermostat be on a different subnet than the Xbox.
> We should be telling ISPs of all sizes "IPv6 is huge... come get a /32 or bigger... do sensible things when you make your addressing plans... do sensible things when you sell service to your customers" and not "here's a way to save a buck by pretending IPv6 is like IPv4"
> You're right (in the part below that I deleted)... the bug is the fee structure and there's absolutely no reason to try to muck with the policy, which can't possibly fix the real problem.
> Matthew Kaufman
Generally speaking we need to move away from conservation as goal for both ipv4 and ipv6
Structurally there is no need in v6 and the market will force it in v4
conservation at the rir level creates costly externalities in routing and other areas such as system design.
Ripe is on the right track http://www.ripe.net/ripe/policies/proposals/2013-03
> 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:
> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1473 bytes
More information about the ARIN-PPML