[arin-discuss] Status of realigning the IPv6 fee structure?

Thu Mar 15 00:07:07 EDT 2012

While an interesting thought about forecasting...  Even if you are
looking to allocate a /48 to every customer, you do realize this gives
you 65,536 customers (well, ok, subtract a few for your internal
networks) to deal with.

Even if coming off a /21 allocation in IPv4, the same number of
customers would mean that you are giving 3/8 of an IP to each of those
customers you are forecasting!  :)   So coming from 2,048 single IP
addresses to 2^96 (79,228,162,514,264,337,593,543,950,336 or 79
octillion addresses) seems to represent a REALLY aggressive growth factor!

Just my two cents (or apparently $1,000).

Scott

On 3/14/12 11:10 PM, Kevin Blumberg wrote:
> I wanted to chime in on a couple of items.
>
> 1) When selecting the correct allocation size for IPv6 you are looking at forecasting a minimum of 5 years out. The allocation size
> you choose is not what is needed today but what you will need years from now. This is in sharp contrast to IPv4 which at most is
> a 12 month forecast. This to me is one of the key issues that are jumping ISP's from the X-SMALL to SMALL category.
>
> 2) We are missing critical data in being able to see the whole picture. If we go on the premise that ARIN wishes to be revenue neutral
> with IPv6 then we need to know how many ISP's are in the categories. It will take X number of years before IPv4 use lowers and moves
> companies into lower tier category (I really don't see being less than 5-8 years). If that is the case then you could bill people based on there
> IPv4 allocation and at such time as the pendulum swings ARIN could revise the fee schedule to account for the loss.
>
> 3) The initial allocation size for IPv6 and what is suggested as the correct end user assignment have been moving targets. As an example if the 
> fee structure was set to be based on each end user getting a /64 or a /56 then a /32 as small or medium makes sense. If you are reserving a /48 
> for each end user as seems to be the current trend then you are already significantly lowering the number of customers you would fit into that /32.
>  
> I truly believe that /32 should be set to X-Small and that once ARIN see's revenue loss it can adjust accordinly based on the /36 use concept that David
> made earlier. That would put the change out years into the future and has the benefit of only happening at a time when the pendulum swing will have
> occurred and IPv6 will not be an optional endevaour as some of the smaller companies are seeing it as.
>
> Kevin Blumberg
> T 416.214.9473 x31
> F 416.862.9473
> kevinb at thewire.ca
>
>
>
>
>
>
>> -----Original Message-----
>> From: arin-discuss-bounces at arin.net [mailto:arin-discuss-
>> bounces at arin.net] On Behalf Of Josh Coleman
>> Sent: Wednesday, March 14, 2012 10:00 PM
>> To: David Farmer
>> Cc: arin-discuss at arin.net
>> Subject: Re: [arin-discuss] Status of realigning the IPv6 fee structure?
>>
>> I also agree with the below statement. I think it is very clear and precise to
>> the point and not punish ISP's for rolling out IPv6 when the financial incentive
>> is just not there.
>>
>> Josh Coleman
>> Chief Architect
>> Cell +1 510.585.6534
>> Work +1 415.294.2240 X1010
>> Email: jcoleman at centauricom.com
>>
>>
>>
>>>
>>> On 3/14/12 20:11 CDT, Jesse D. Geddis wrote:
>>>> On Mar 14, 2012, at 5:57 PM, "Brent Sweeny"<sweeny at indiana.edu>
>> wrote:
>>>>> I like this suggestion.  it has good combinations of incentives for
>>>>> the right Good Behaviors, what seem like reasonable charges, and a
>>>>> reasonable sunset.
>>>>>     Brent Sweeny, Indiana University
>>>>>
>>>>> On 3/14/2012 7:05 PM, David Farmer wrote:
>>>>>> On 3/14/12 16:26 CDT, Robert Marder wrote:
>>>>>>> I would agree with this.
>>>>>>>
>>>>>>> The smallest allocation available to ISP's under IPv4 (the /22)
>>>>>>> should cost the same as the smallest allocation available to ISP's
>>>>>>> under
>>>>>>> IPv6
>>>>>>> (the /32).
>>>>>>>
>>>>>>> That just seems like common sense to me.
>>>>>>>
>>>>>>> Changing the smallest allocation available under IPv6 isn't very
>>>>>>> fair to those that adopted IPv6 early - early adopters shouldn't
>>>>>>> be stuck with higher fees because the goal posts were moved.
>>>>>> I agree that there shouldn't be an early adopter TAX on X-small
>>>>>> ISPs that moved forward with a /32 before the /36 option was
>>>>>> available, if anything they should get some kind of benefit.
>>>>>> Therefore, I think my preferred solution is a grandfather clause in
>>>>>> the fee structure, or a permanent fee waiver so to speak, for any
>>>>>> ISPs that currently has an X-small IPv4 allocation that receives a
>>>>>> /32 IPv6 allocation before December 31, 2012 can continue to be
>>>>>> eligible for the X-small IPv6 allocation rate as long as they don't
>>>>>> grow their IPv4 allocation beyond X-small, or their IPv6 allocation
>>>>>> beyond /32.
>>>>>>
>>>>>> Then starting January 1, 2013 if you want to remain an X-small ISP
>>>>>> you will have to select a /36 allocation.
>>>> Maybe I'm misreading this wording but this implies to me the
>>>> suggestion is that people who adopted a /32 when that's all that was
>>>> available should be forced to renumber onto a /36. If that's the case
>>>> I don't think that's a reasonable expectation of anyone who took the
>>>> time to get the address space and roll it out. I, for example,
>>>> addressed all my infrastructure on ipv6 to the exclusion of ipv4.
>>>> Saying in order to maintain a specific rate I have to swap out my /32 for a
>> /36.
>>> I think I may not have been as clear as I meant to be, my intent was
>>> that for any new allocations to qualify for X-small fee would need to
>>> select a /36 as of that date.  The idea is that /32s grandfathered as
>>> X-small would remain X-small until they grew beyond /32 or an X-small
>>> IPv4 allocation.
>>>
>>>> I think the /32s issued before the /36's were available should be
>>>> charged at the xsmall rate. I didn't respond to Owen earlier but in
>>>> my case my ipv4 is xsmall but my ipv6 (which was the smallest I could
>>>> get) is "small" so orgs like mine will be getting a defacto rate
>>>> increase as I will be charged for my ipv6 small and not my ipv4 extra
>>>> small. Ipv6 is not monetized by most people but I will be paying an
>>>> extra 1200 for it because the goal posts were moved as someone earlier
>> mentioned.
>>> Yep, we intend the same thing, except I would to extend the ability to
>>> get a /32 at the X-small fee until the end of this year.
>>>
>>>>>> I'm suggesting December 31, 2012 to hopefully create a small
>>>>>> incentive for X-small ISPs that haven't move forward to get their
>>>>>> IPv6 allocation, to do so yet this year.  Basically, for a limited
>>>>>> remaining time, get a
>>>>>> /32 for the price of a /36 deal to get the smaller guys moving.
>>>>>>
>>>>>> Also I would like to remind everyone who grumbles about Legacy
>>>>>> IPv4, that it is equally unfair to create an early adopter TAX for
>>>>>> Legacy IPv4.  However, I equally believe it is time for Legacy IPv4
>>>>>> holders to step up to the plate and at least to start minimally
>>>>>> contributing to the upkeep of the system too.  I think the current
>>>>>> Legacy RSA and its flat Org ID based fee structure is a pretty
>>>>>> reasonable compromise.
>>> --
>>> ===============================================
>>> David Farmer               Email:farmer at umn.edu
>>> Networking & Telecommunication Services Office of Information
>>> Technology University of Minnesota
>>> 2218 University Ave SE	    Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>>> _______________________________________________
>>> ARIN-Discuss
>>> You are receiving this message because you are subscribed to the ARIN
>>> Discussion Mailing List (ARIN-discuss at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>> Please contact info at arin.net if you experience any issues.
>>>
>>> --
>>> This message has been scanned for viruses and dangerous content by
>>> MailScanner, and is believed to be clean.
>>>
>>>
>>
>>
>>
>> ---
>> Centauri Communications
>> Light years ahead of the Internet.
>> http://www.centauricom.com
>>
>>
>> --
>> This message has been scanned for viruses and dangerous content by
>> MailScanner, and is believed to be clean.
>>
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are subscribed to the ARIN
>> Discussion Mailing List (ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
>