Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations forISPs
(Steven Ryerse)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Matthew Kaufman)
----------------------------------------------------------------------
Message: 1
Date: Sun, 7 Apr 2013 20:06:43 +0000
From: Steven Ryerse <[email protected]>
To: Paul Vixie <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations forISPs
Message-ID:
<5b9e90747fa2974d91a54fcfa1b8ad12012f5cc...@eni-mail.eclipse-networks.com>
Content-Type: text/plain; charset="utf-8"
As I have offered in the recent past. No way should Arin assign me anything
(IPv4) very large ? I used a /8 in a recent extreme example. But, as we are a
small data center, I should be able to get at least whatever this community
deems to be the minimum size. Arin?s current policies aside, I should be able
to get a /22 for sure and maybe a /21 or a /20 ? as that is the right size for
our organization. I?m all for right-sized block allocations probably based on
a combination of current network size (Legacy included) and revenue or funding
size plus things like BGP and so forth factored in. There are bright folks who
can do a better job than me making something like that a policy but a similar
change as currently being considered for RIPE should be made for ARIN as well.
Thank you for your input!
Steven L Ryerse
President
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: Paul Vixie [mailto:[email protected]]
Sent: Sunday, April 07, 2013 3:50 PM
To: Steven Ryerse
Cc: cb.list6; Matthew Kaufman; [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations forISPs
Steven Ryerse wrote:
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.
i know that it's a popular viewpoint -- many folks feel that the time for needs
based allocation is over and that the invisible hand of the market is now
capable of optimizing the holding of address space and the aggregation level of
that space into routing table entries.
so i thought i'd chime in: i consider that case to be extremely unmade as yet.
even though i am in most other ways a free-marketeer. as stewards of a public
resource ARIN has always been guided by RFC 2050 which requires recipients of
these public resources to justify their need, no matter whether these resources
are coming from a central pool or a private transfer.
paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130407/965cfc3b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1473 bytes
Desc: image001.jpg
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130407/965cfc3b/attachment-0001.jpg>
------------------------------
Message: 2
Date: Sun, 7 Apr 2013 13:24:11 -0700
From: Owen DeLong <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 6, 2013, at 19:58 , John Curran <[email protected]> wrote:
> On Apr 5, 2013, at 9:37 AM, Seth Mattinen <[email protected]> wrote:
>
>> I see no reason to have a policy motivated strictly by fees to remain after
>> fee changes that may or may not negate it, and to determine that it should
>> go back through the PDP. Otherwise we're just cluttering the NRPM with
>> irrelevant policy.
>
> Seth -
>
> The ARIN Board has often lowered the fee schedule as the
> financial circumstances allow, and in general this has been
> independent of number resource policy changes.
>
> The Revised Fee schedule is much improved over the existing
> fee schedule with respect to organizations being able to
> cost-effectively make use of IPv6 (as it is lower than the
> existing fee schedule's smallest IPv6 category today.)
Unless you are an end-user in which case adding IPv6 is still
a (potentially significant percentage) increase over your IPv4
fees.
> If the community does not support 2013-3, then smaller ISPs
> will still have the current option of receiving a /36 of IPv6
> (if they wish); this will put them in the x-small fee category
> of $1000 per year.
>
> If the community supports 2013-3, then some very small ISPs will
> gain an option of taking a /40 allocation of IPv6 space, which
> will put them in the xx-small fee category with fees of $500 per
> year.
>
> If very small ISPs receiving /40 of IPv6 space does not make good
> technical sense, then the community should not support the draft
> policy... it's that simple. (These ISPs will still have lower fees
> under the Revised Fee schedule, just not as low as they might have
> had otherwise...)
It's not that simple because we have to balance differing tradeoffs
as a result of the fee structure.
If we don't support the policy, then we create a disincentive to deploy
IPv6 at all among these smaller ISPs.
If we support the policy, then we create an incentive to do things which
do not make good technical sense in order to avoid creating a
disincentive to deploy IPv6.
The current fee structure creates a Sophie's choice in policy. IMHO,
the board seriously erred in creating this situation and should do
whatever is possible to have a correction ready to present prior
to the discussion of 2013-3 in Barbados.
One possible way to distinguish ISP size for IPv6 would be to use
annual gross revenue instead of total address holdings. I don't know
if that would be an improvement or not. I realize it would be more
complex to calculate and enforce. I think it would likely be more fair.
I would like to hear about other creative ideas on ways to measure
size and/or appropriate metrics to be used for fee determination.
We have a lot of smart people in the community. I don't think we
should look at the dysfunction of what we have always used and
simply shrug it off to "but that's how we've always done it."
Owen
------------------------------
Message: 3
Date: Sun, 07 Apr 2013 13:29:29 -0700
From: Matthew Kaufman <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/7/2013 4:21 AM, John Curran wrote:
> Matthew -
>
> The current fee schedule reads as follows:
>
> IPV6 ANNUAL FEES (NOTE: FEE WAIVERS IN EFFECT), EFFECTIVE UNTIL 30 JUNE
> 2013
> Size Category Fee (US Dollars) Block Size
> Small $2,250 /40 to /32
> Medium $4,500 /31 to /30
>
> There is 25% IPv6 fee waiver in effect (this started out at 100% and
> was to be phased out over the last 4 years, although it was extended
> at the 25% discount level for this year to carry us into the Revised
> Fee schedule.)
>
> So, any ISP using IPv6 under _today's_ fee schedule has a minimum annual
> fee of $1687 per year [$2250 * 75%] and that covers an allocation up to
> /32 of IPv6. Unless we continue with the Revised Fee schedule, this is
> effectively a minimum annual cost for any ISP making use of IPv6.
>
> If we want to lower that cost of using IPv6 for smaller organizations,
> we need to find some manner to distinguish these smaller ISPs from all
> ISPs, and this is typically done through the total address block holdings.
I believe that way is not appropriate for the post-IPv4 world. No ISP
should be getting smaller than /32.
If you want to lower the cost of IPv6 for smaller organizations, you're
free to do so, but tying to how much IPv6 space they have is likely to
result in a very large number in the smallest category. And whether or
not that's a problem *isn't a NRPM issue*.
>
> At this point, ARIN can sustain some number of smaller ISPs having lower
> fees, and the Revised Fee schedule supports an ISP with no more than /20
> of IPv4 space and /36 of IPv6 being categorized as "x-small" with annual
> fees of $1000/year. This category makes IPv6 more approachable for these
> ISPs but it is indeed at the downside of a smaller IPv6 allocation.
That shouldn't be happening. No reason an ISP should be getting a /36
instead of a /32, just encourages bad behavior.
> As
> you are aware, /36 of IPv6 space would provide for more than 4000 /48
> and _lots_ of /56 assignments (but there would be less in practice due
> to internal hierarchy in assignment management.)
Yes. So /36 is *barely* what it takes to remind an ISP that they
shouldn't be treating IPv6 like a scarce commodity. Maybe. But /32 would
be a lot safer, and so that's what *numbering policy* should be doing.
>
> Draft Policy ARIN-2013-3, combined with the Revised Fee schedule as
> corrected, would continue this approach of allowing very small ISPs
> with no more than /22 of IPv4 to obtain a corresponding IPv6 allocation
> of /40 and have annual fees of $500 year in the "xx-small" category.
The draft policy is bad numbering policy, and the fee schedule will
provide an incentive for organizations to use the provisions of that bad
numbering policy. Don't support.
> The downside that you assert with Draft Policy ARIN-2013-3 is that
> "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."
>
> Given that any ISP qualifying as xx-small (even with wildly aggressive
> NAT) has no more 1024 customers each with a single IPv4 address, and the
> /40 IPv6 allocation would provide them with the ability to make 65K /56
> assignments to these same customers, it does seem somewhat strange that
> "false conservation" of those 65 thousand potential assignments would
> drive xx-small ISPs to instead make /64 IPv6 customer assignments.
Lets ignore IPv4 entirely for a moment... or pretend that in the near
future people might single-home IPv4 with PA addresses but want their
IPv6 to be PI space... In such a situation, organizations will choose to
pack themselves and their customers into too little IPv6 space just to
save a buck. I don't think that should be happening.
>
> The community can indicate that it does not support ARIN-2013-3 if the
> resulting "false conservation" is a problem, and then there will be no use
> of the xx-small/$500/yr fee category.
The community on *this* mailing list should be debating what is best
numbering policy, and not considering the tempting fruit of this week's
fee schedule (subject to change without community input at any time).
> Under the Revised Fee schedule, these
> ISPs would be paying at least $1000/year based on a /36 IPv6 allocation
> (which is still better than today's fees with IPv6 use as noted above.)
>
> It would be good to hear from ISPs who would qualify for the xx-small
> $500/year category about the resulting temptation that it poses for
> making smaller IPv6 customer assignments (and how they feel safer with
> the /36 IPv6 minimum and corresponding $1000/year annual fee), as they
> are the ones who are most affected by the outcome of this draft policy
> consideration.
It would be good to hear from small ISPs that are deploying IPv6 at all,
but that's a whole separate problem.
Matthew Kaufman
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 19
*****************************************
