[arin-discuss] tweak to proposed fee schedule
farmer at umn.edu
Fri Apr 12 23:51:27 EDT 2013
I've been holding off entering this fray. But I haven't seen any one
raise counter points to this proposal so I will;
On 4/7/13 23:18 , Michael Sinatra wrote:
> Currently there is a discussion going on over on ppml@ regarding policy
> 2013-3, which is largely being driven by an incentive issue with ARIN's
> proposed fee schedule. Specifically, the proposed fee schedule allows
> for very small ISPs to fit in the "XX-small" category. However, the
> current minimum allocation for an ISP is a /36 (with a /32 being the
> "standard" allocation), which does not allow a very small ISP to fit in
> the XX-small category.
> See the tables here for more info:
> Because of this, concern has been expressed that this creates a
> disincentive for small ISPs to adopt IPv6. A policy proposal (2013-3)
> has been developed that allows small ISPs to receive allocations as
> small as /40s, while still reserving indefinitely a /32 for the ISP,
> some or all of which the ISP can request at any time and without
> However, there are some operational issues that arise from this use of
> number policy to patch an issue with the fee schedule; these issues have
> been discussed at length on PPML, and I refer the reader to the archive
> of that discussion. Briefly summarized:
> o It results in a messy addressing plan, where the ISP is forced to fit
> into a small corner of the potential space it has available to it.
> This, in turn leads to two consequences:
> o Customers will receive sub-standard reassignments as the ISP becomes
> increasingly parsimonious with address space.
I think "will" is a little strong, I'd put it at "may" and that same may
exists for any size IPv6 allocation. Some ISP that really needs a /28
may decided to stick with a /32 and give their customers smaller than
we'd like reassignments. We can't dictate the size reassignments ISP
make. Why do you think this is more likely to occur for xx-small or
x-small ISPs than the larger guys?
> o As the allocation grows toward the /32 boundary, it becomes less
> likely that the ISP will be able to have internally aggregable routing,
> and this may make it more likely that the ISP won't re-aggregate its
> space as it increases the size of its allocation over time, *even* if
> that space is from a single aggregable /32.
Why? I'm not sure I see the reasoning here, yes they will likely have
some messiness in their internal routing going from /40 to /36 to /32,
but this is an internal business choice. Why do you think it likely
that they won't aggregate their announcements as they grow? Do you
expect the same thing will happen as other ISPs grow from /32 to /28 or
/28 to /24? If not why not, I don't see why this issue, if it exists,
is unique to the small allocations.
> I'd like to propose a tweak to the proposed fee schedule as follows:
> "ISPs which have IPv4 resources and an IPv6 allocation of exactly /32
> will have their fees calculated from the fee schedule based only on
> their IPv4 allocation. All allocation sizes other than IPv6 /32 will be
> calculated from the fee schedule based on the greater of their IPv4 or
> IPv6 allocation."
> This only affects ISPs whose IPv4 allocations are in the X-small or
> XX-small range *and* who have a /32 allocation. ISPs and end sites with
> allocations/assignments in the small or greater category will still pay
> the greater of their IPv4/IPv6 allocation-category fee.
Your proposal quoted above, doesn't say anything about end users
assignments, I don't understand why you are bringing them up. Do you
expect to effect end user assignments?
> It's revenue-neutral with respect to the pending fee schedule, combined
> with proposal 2013-3 because that proposal calls for the reservation of
> the /32 for that ISP anyway. I believe this tweak still allows for a
> sustainable revenue model for ARIN until such a time as ARIN ceases to
> provide IPv4 services, at which point the fee schedule will likely need
> to be revisited anyway.
I think there is a long-term problem created by this proposal, I agree
it is revenue-neutral currently, and it works pretty good with IPv4
still being the primary driver for ISPs. However, as IPv6 becomes the
primary driver for ISPs overtime, there will need to be a different way
to differentiate these xx-small and x-small ISPs from the just plane
small ISPs when IPv4 is no longer functionally doing that for us. I'll
admit that is probably 5 to 10 years from now, but I believe it will
> I am interested in this community's thought on this tweak. I realize
> the fee schedule is always a contentious issue, and I am reluctant to
> get into a general discussion of fees (for more general discussions,
> please create a separate thread). However, I would like to know if
> there are specific issues or incentive problems with what I am proposing.
As I said, I believe your proposal has a long-term problem. I'm not
sure that disqualifies it. However, it will eventually become a problem
that will likely require another change in the fee schedule. The
bigger issue for me is, I'm not sure what the alternative is to fix that
long-term problem when it inevitably comes to pass. I worried that we
just end up right back with the something like ARIN-2013-3 and the
corrected proposed fee schedule, but 5 or 10 years from now.
In contrast the corrected proposed fee schedule with ARIN-2013-3 allows
ISPs to differentiate themselves, rather than using IPv4 to do that.
They can elect to start with a /32 because they think it is the right
thing to do and believe it is the better long-run business and technical
decision for them. Or, they can choose /36 or /40 if that is a better
business and technical decision for them.
Yes, this could have incentive problems. However, are we really sure
that a /40 is always technically inappropriate, even for the smallest
(xx-small) 0.1%* of the ISPs in the ARIN region? More important, who is
better equipped to make that decision, the mob on ARIN-PPML and
ARIN-Discuss or the individual ISPs that have to live with the business
and technical consequences?
Are we really going to say that a remote rural ISP with a customer base
of 50 to 100 customers couldn't make valid business and technical choice
of using a /40 of IPv6? Or what about a boutique Business IT support
shop that includes ISP services for 20 to 50 of its customers that don't
want be bothered with separate ISP bill. I believe there are several
business models that it would be a valid technical choice to use a /40
* Slides 11-14
> Note also that I have no stake in this issue; this fee tweak would not
> impact myself nor my current or previous employers.
> Michael Sinatra
> Energy Sciences Network
> LBNL/DOE Office of Science
I have no stake in this either.
Finally, I'm not opposed to this proposal. But I'm not convinced that
it is fundamentally creates any better set of trade-offs than the
corrected proposed fee schedule with ARIN-2013-3. Especially when you
consider this proposal dependency on IPv4 to differentiate among
xx-small, x-small, and small ISPs. In the short-run this proposal has
some small advantage, but in the long-run if IPv4 was viable, we
wouldn't need IPv6. So, I think this only punts the problem down the
road, but I will acknowledge sometime that is the right answer.
David Farmer Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
More information about the ARIN-discuss