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

Kevin Blumberg kevinb at thewire.ca
Wed Mar 14 23:10:36 EDT 2012


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.



More information about the ARIN-discuss mailing list