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 for ISPs
(Seth Mattinen)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
3. Weekly posting summary for [email protected] (Thomas Narten)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
5. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Brian Jones)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Apr 2013 15:17:08 -0700
From: Seth Mattinen <[email protected]>
To: [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 3/27/13 11:20 AM, ARIN wrote:
> Draft Policy ARIN-2013-3
> Tiny IPv6 Allocations for ISPs
>
I can't honestly support this in any form because it's directly tied to
the fee structure which is outside the scope of the PDP to influence.
What if the fee structure gets changed in the future?
~Seth
------------------------------
Message: 2
Date: Thu, 04 Apr 2013 17:53:43 -0500
From: David Farmer <[email protected]>
To: Seth Mattinen <[email protected]>
Cc: [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/4/13 17:17 , Seth Mattinen wrote:
> On 3/27/13 11:20 AM, ARIN wrote:
>> Draft Policy ARIN-2013-3
>> Tiny IPv6 Allocations for ISPs
>
> I can't honestly support this in any form because it's directly tied to
> the fee structure which is outside the scope of the PDP to influence.
> What if the fee structure gets changed in the future?
If the lower ones go a way then, as was said no one in their right mind
would choose /36 or /40. I can't imagine anything smaller, I just don't
see room for more changes one the smaller side. At least without
changing the IPv6 architecture and the /64 subnet standard, and that
would be a big enough change that a whole bunch of assumptions need to
change not just this one.
Also, "/40 or smaller" for X-Small works well for end users, 93% are
XX-Small, 5% are X-Small and 2% are Small.*
*Dallas PPM - Policy Implementation & Experience Report, Slide 7
https://www.arin.net/participate/meetings/reports/ARIN_XXX/PDF/thursday/nobile_policy.pdf
--
================================================
David Farmer Email: [email protected]
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
================================================
------------------------------
Message: 3
Date: Fri, 05 Apr 2013 00:53:07 -0400
From: Thomas Narten <[email protected]>
To: [email protected]
Subject: [arin-ppml] Weekly posting summary for [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Total of 93 messages in the last 7 days.
script run at: Fri Apr 5 00:53:07 EDT 2013
Messages | Bytes | Who
--------+------+--------+----------+------------------------
20.43% | 19 | 16.91% | 140509 | [email protected]
16.13% | 15 | 15.80% | 131284 | [email protected]
12.90% | 12 | 13.06% | 108566 | [email protected]
13.98% | 13 | 10.95% | 91036 | [email protected]
6.45% | 6 | 5.37% | 44622 | [email protected]
1.08% | 1 | 10.72% | 89065 | [email protected]
5.38% | 5 | 4.27% | 35470 | [email protected]
2.15% | 2 | 3.71% | 30840 | [email protected]
3.23% | 3 | 2.09% | 17387 | [email protected]
2.15% | 2 | 2.37% | 19686 | [email protected]
2.15% | 2 | 2.17% | 18011 | [email protected]
2.15% | 2 | 1.75% | 14534 | [email protected]
2.15% | 2 | 1.57% | 13070 | [email protected]
2.15% | 2 | 1.55% | 12896 | [email protected]
1.08% | 1 | 1.41% | 11678 | [email protected]
1.08% | 1 | 1.32% | 10935 | [email protected]
1.08% | 1 | 1.28% | 10653 | [email protected]
1.08% | 1 | 1.07% | 8864 | [email protected]
1.08% | 1 | 0.89% | 7359 | [email protected]
1.08% | 1 | 0.88% | 7309 | [email protected]
1.08% | 1 | 0.88% | 7279 | [email protected]
--------+------+--------+----------+------------------------
100.00% | 93 |100.00% | 831053 | Total
------------------------------
Message: 4
Date: Fri, 05 Apr 2013 07:23:29 -0500
From: David Farmer <[email protected]>
To: [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=windows-1252; format=flowed
On 4/4/13 12:15 , David Farmer wrote:
> Here is the update that I propose to submit tomorrow to meet the
> publication deadline for the Barbados meeting. I believe it accurately
> reflects the changes discussed so for. Any comments are appreciated.
>
> Thanks.
Ok, here is another update that includes the changes discussed
yesterday, and few others I found. I've also included a new section
summarizing the community's discussion to this point, including the
primary objection to the policy and how the policy attempts to mitigate it.
Any additional comments are appreciated before I submit it to staff
mid-day for publication in the Barbados meeting materials.
Thanks
--
Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs
Date: 5 April 2013
Problem Statement:
ARIN's fee structure provides a graduated system wherein organizations
pay based on the amount of number resources they consume.
At the very bottom end of the scale, it is presently not possible to be
an XX-Small ISP with an IPv6 allocation because the minimum allocation
size of /36 automatically promotes one into X-Small ISP status,
resulting in a doubling of annual fees.
While tiny in absolute terms, the extra costs incurred represent a
disincentive to IPv6 deployment.
To the author's knowledge, it has never been possible for an LIR/ISP to
get a /40 allocation direct from ARIN; such assignments have been
limited to organizations that qualify as end sites or /48s for critical
infrastructure. It is understood there is an expected correction of the
XX-Small fee category to "/40 or smaller".
Policy statement:
Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at
the end of the first sentence of subsection 6.5.2.1 clause (b), and add
a new clause (g), resulting in;
b. In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36 or /40. In no case shall an ISP receive more
than a /16 initial allocation.
...
g. An LIR that requests a smaller /36 or /40 allocation is entitled to
expand the allocation to /32 or /36 at any time without renumbering or
additional justification. Such expansions are not considered subsequent
allocations. However, any expansions beyond /32 are considered
subsequent allocations, and must conform to section 6.5.3.
Part 2: Add a new subsection to section 6 "IPv6";
6.12 Reduction or Return
ARIN will accept the return of whole or partial block(s) allowing an
organization to reduce their holdings as long as:
a. The end result is not an increase in the number of aggregatable
blocks held by the organization.
b. Whole blocks are returned to the extent practicable.
c. Partial block(s) retained must conform to current applicable
allocation or assignment policies, as to size, alignment, etc?
d. Block(s) retained are within a single reserved space or aggregate set
aside for the organization in the ARIN database to the extent practicable.
e. All returned block(s) must not be in use by the organization or its
customers.
Comments:
The author acknowledges the shortcomings of providing an ISP with an
allocation of a size that is more traditionally associated with end
sites. In order to avoid possible bad effects on the routing table, the
author encourages ARIN staff to adopt the same sparse allocation
practice as currently exists for larger allocations, ideally even
reserving a block as large as the /28 that is reserved for /32s
currently. Note the policy intent of part 1 requires a minimum of a /32
be reserved.
Part 1 brings ARIN's allocation policies in line with the upcoming fee
schedule, with the addition of an expected correction of the XX-Small
fee category to "/40 or smaller". This makes it possible to qualify for
each ISP fee category while holding IPv6 number resources and allows
expansion up to /32 without renumbering or additional justification as a
subsequent allocation. The selection of a /32, /36 or /40 allocation is
only driven by an ISP's own internal business justifications.
Part 2 codifies and expands upon current practice for selective return
in the manner described by John Curran on the arin-discuss mailing list
(7-Mar-2013 in
[email protected] ). It
specifies the generic requirements that should be met for such returns.
A more practical approach might to figure out a way to apply graduated
fees to ISPs at the very small end of the scale using some metric other
than prefix size. Fee schedules are outside of the purview of the Policy
Development Process; such responsibility lies with the Board should they
choose to take it up.
Summary of community discussion:
The fundamental argument against this draft policy is that the primary
problem being solved is a billing or fee structure issue and not a
number resource policy issue in itself. A significant minority of the
community would prefer /32 be the sole minimum allocation size for ISPs
and other LIRs, and they feel there is no need for smaller /36 or /40
allocations. They would prefer to solve the problem with changes in the
fee structure rather than contorting number resource policy to solve the
problem. However, there are to many ISPs that fit into the /32
allocation category for the fee level associated with the XX-Small
category to be fiscally responsible and sustainable for ARIN.
Furthermore, there are no obvious solutions to this problem within the
fee structure domain that are fiscally responsible and sustainable for
ARIN, especially in the long-term.
Everyone agrees making /36 or /40 allocations to ISPs seems less than
ideal from a number resource policy perspective. However, this is
mitigated by ensuring that all ISPs have a /32 available to them without
renumbering or additional justification and from a number resource
policy perspective the selection of /36 or /40 allocations is completely
voluntary. This allows each ISPs to make the decision to select from a
/32, /36 or /40 initial allocation based solely on their own internal
business justifications, and eliminating structural disincentives in the
fee schedule for IPv6 adoption. This seems like the best balance
available at this time of number resource policy, fiscal responsibility
and sustainability for both ARIN and the ISPs that it servers.
Timetable for implementation: Immediate
--
================================================
David Farmer Email: [email protected]
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
================================================
------------------------------
Message: 5
Date: Fri, 5 Apr 2013 09:22:33 -0400
From: Brian Jones <[email protected]>
To: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<CANyqO+E5h6cb1LnpGjORs4aOqES=r7Aj5vTj=j=s+fqho0a...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
I agree that you have summarized group discussion accurately.
--
Brian
On Fri, Apr 5, 2013 at 8:23 AM, David Farmer <[email protected]> wrote:
> On 4/4/13 12:15 , David Farmer wrote:
>
>> Here is the update that I propose to submit tomorrow to meet the
>> publication deadline for the Barbados meeting. I believe it accurately
>> reflects the changes discussed so for. Any comments are appreciated.
>>
>> Thanks.
>>
>
> Ok, here is another update that includes the changes discussed yesterday,
> and few others I found. I've also included a new section summarizing the
> community's discussion to this point, including the primary objection to
> the policy and how the policy attempts to mitigate it.
>
> Any additional comments are appreciated before I submit it to staff
> mid-day for publication in the Barbados meeting materials.
>
> Thanks
>
> --
>
>
> Draft Policy ARIN-2013-3
> Tiny IPv6 Allocations for ISPs
>
> Date: 5 April 2013
>
> Problem Statement:
>
> ARIN's fee structure provides a graduated system wherein organizations pay
> based on the amount of number resources they consume.
>
> At the very bottom end of the scale, it is presently not possible to be an
> XX-Small ISP with an IPv6 allocation because the minimum allocation size of
> /36 automatically promotes one into X-Small ISP status, resulting in a
> doubling of annual fees.
>
>
> While tiny in absolute terms, the extra costs incurred represent a
> disincentive to IPv6 deployment.
>
> To the author's knowledge, it has never been possible for an LIR/ISP to
> get a /40 allocation direct from ARIN; such assignments have been limited
> to organizations that qualify as end sites or /48s for critical
> infrastructure. It is understood there is an expected correction of the
> XX-Small fee category to "/40 or smaller".
>
>
> Policy statement:
>
> Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at
> the end of the first sentence of subsection 6.5.2.1 clause (b), and add a
> new clause (g), resulting in;
>
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40. In no case shall an ISP receive more
> than a /16 initial allocation.
>
> ...
>
> g. An LIR that requests a smaller /36 or /40 allocation is entitled to
> expand the allocation to /32 or /36 at any time without renumbering or
> additional justification. Such expansions are not considered subsequent
> allocations. However, any expansions beyond /32 are considered subsequent
> allocations, and must conform to section 6.5.3.
>
>
> Part 2: Add a new subsection to section 6 "IPv6";
>
> 6.12 Reduction or Return
>
> ARIN will accept the return of whole or partial block(s) allowing an
> organization to reduce their holdings as long as:
>
> a. The end result is not an increase in the number of aggregatable blocks
> held by the organization.
>
>
> b. Whole blocks are returned to the extent practicable.
>
> c. Partial block(s) retained must conform to current applicable allocation
> or assignment policies, as to size, alignment, etc?
>
> d. Block(s) retained are within a single reserved space or aggregate set
> aside for the organization in the ARIN database to the extent practicable.
>
>
> e. All returned block(s) must not be in use by the organization or its
> customers.
>
> Comments:
>
> The author acknowledges the shortcomings of providing an ISP with an
> allocation of a size that is more traditionally associated with end sites.
> In order to avoid possible bad effects on the routing table, the author
> encourages ARIN staff to adopt the same sparse allocation practice as
> currently exists for larger allocations, ideally even reserving a block as
> large as the /28 that is reserved for /32s currently. Note the policy
> intent of part 1 requires a minimum of a /32 be reserved.
>
> Part 1 brings ARIN's allocation policies in line with the upcoming fee
> schedule, with the addition of an expected correction of the XX-Small fee
> category to "/40 or smaller". This makes it possible to qualify for each
> ISP fee category while holding IPv6 number resources and allows expansion
> up to /32 without renumbering or additional justification as a subsequent
> allocation. The selection of a /32, /36 or /40 allocation is only driven
> by an ISP's own internal business justifications.
>
> Part 2 codifies and expands upon current practice for selective return in
> the manner described by John Curran on the arin-discuss mailing list
> (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3**
> [email protected].**net<[email protected]>).
> It specifies the generic requirements that should be met for such
> returns.
>
>
> A more practical approach might to figure out a way to apply graduated
> fees to ISPs at the very small end of the scale using some metric other
> than prefix size. Fee schedules are outside of the purview of the Policy
> Development Process; such responsibility lies with the Board should they
> choose to take it up.
>
> Summary of community discussion:
>
> The fundamental argument against this draft policy is that the primary
> problem being solved is a billing or fee structure issue and not a number
> resource policy issue in itself. A significant minority of the community
> would prefer /32 be the sole minimum allocation size for ISPs and other
> LIRs, and they feel there is no need for smaller /36 or /40 allocations.
> They would prefer to solve the problem with changes in the fee structure
> rather than contorting number resource policy to solve the problem.
> However, there are to many ISPs that fit into the /32 allocation category
> for the fee level associated with the XX-Small category to be fiscally
> responsible and sustainable for ARIN. Furthermore, there are no obvious
> solutions to this problem within the fee structure domain that are fiscally
> responsible and sustainable for ARIN, especially in the long-term.
>
> Everyone agrees making /36 or /40 allocations to ISPs seems less than
> ideal from a number resource policy perspective. However, this is
> mitigated by ensuring that all ISPs have a /32 available to them without
> renumbering or additional justification and from a number resource policy
> perspective the selection of /36 or /40 allocations is completely
> voluntary. This allows each ISPs to make the decision to select from a
> /32, /36 or /40 initial allocation based solely on their own internal
> business justifications, and eliminating structural disincentives in the
> fee schedule for IPv6 adoption. This seems like the best balance available
> at this time of number resource policy, fiscal responsibility and
> sustainability for both ARIN and the ISPs that it servers.
>
> Timetable for implementation: Immediate
>
>
> --
> ==============================**==================
> David Farmer Email: [email protected]
> 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
> ==============================**==================
> ______________________________**_________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/**listinfo/arin-ppml<http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact [email protected] if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130405/65834223/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 8
****************************************
