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
(David Farmer)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(BANGO)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
5. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Apr 2013 12:15:43 -0500
From: David Farmer <[email protected]>
To: ARIN <[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=windows-1252; format=flowed
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.
---
Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs
Date: 4 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 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; assignments of /40s have been
limited to organizations that qualify as end sites or 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 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 non-contiguous
blocks held by the organization.
b. Whole blocks are returned to the extent practicable.
c. Partial block(s) retained must conform to applicable policies, as to
size, alignment, etc?
d. Partial 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, perhaps even
reserving a block as large as the /28 that is reserved for /32s. 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 justification as a subsequent allocation as
driven by an ISP's business demands.
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 meet 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.
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: 2
Date: Thu, 4 Apr 2013 13:34:28 -0400
From: "BANGO" <[email protected]>
To: "David Farmer" <[email protected]>, "ARIN" <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <2DA96EA9254548F7A6671DAF4B04585D@BANGOPC2>
Content-Type: text/plain; format=flowed; charset="Windows-1252";
reply-type=response
When is the Barbados meeting?
ROK
-----Original Message-----
From: David Farmer
Sent: Thursday, April 04, 2013 1:15 PM
To: ARIN
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for
ISPs
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.
---
Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs
Date: 4 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 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; assignments of /40s have been
limited to organizations that qualify as end sites or 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 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 non-contiguous
blocks held by the organization.
b. Whole blocks are returned to the extent practicable.
c. Partial block(s) retained must conform to applicable policies, as to
size, alignment, etc?
d. Partial 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, perhaps even
reserving a block as large as the /28 that is reserved for /32s. 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 justification as a subsequent allocation as
driven by an ISP's business demands.
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 meet 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.
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
Please contact [email protected] if you experience any issues.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 2641/6224 - Release Date: 04/04/13
------------------------------
Message: 3
Date: Thu, 04 Apr 2013 12:39:59 -0500
From: David Farmer <[email protected]>
To: BANGO <[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=windows-1252; format=flowed
On 4/4/13 12:34 , BANGO wrote:
> When is the Barbados meeting?
>
> ROK
April 21st - 24th, see;
http://www.arin.net/ARIN-31/
> -----Original Message----- From: David Farmer
> Sent: Thursday, April 04, 2013 1:15 PM
> To: ARIN
> Cc: [email protected]
> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations
> for ISPs
>
> 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.
>
--
================================================
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: 4
Date: Thu, 4 Apr 2013 11:27:51 -0700
From: Owen DeLong <[email protected]>
To: David Farmer <[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=windows-1252
I would remove the word Parital from 6.12(d).
I would remove "perhaps" from ...perhaps even reserving a block as large as..."
and replace it with "ideally".
Explanation of part 2 s/meet/met/ in "...generic requirements that should be
meet [sic] for such..."
Owen
On Apr 4, 2013, at 10:15 , David Farmer <[email protected]> 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.
>
> ---
>
> Draft Policy ARIN-2013-3
> Tiny IPv6 Allocations for ISPs
>
> Date: 4 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 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; assignments of /40s have been limited to
> organizations that qualify as end sites or 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 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 non-contiguous blocks
> held by the organization.
>
> b. Whole blocks are returned to the extent practicable.
>
> c. Partial block(s) retained must conform to applicable policies, as to size,
> alignment, etc?
>
> d. Partial 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, perhaps even reserving a block as
> large as the /28 that is reserved for /32s. 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 justification as a subsequent allocation as driven by an ISP's
> business demands.
>
> 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 meet 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.
>
> 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
> Please contact [email protected] if you experience any issues.
------------------------------
Message: 5
Date: Thu, 04 Apr 2013 13:41:53 -0500
From: David Farmer <[email protected]>
To: Owen DeLong <[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=windows-1252; format=flowed
On 4/4/13 13:27 , Owen DeLong wrote:
> I would remove the word Parital from 6.12(d).
>
> I would remove "perhaps" from ...perhaps even reserving a block as large
> as..." and replace it with "ideally".
>
> Explanation of part 2 s/meet/met/ in "...generic requirements that should be
> meet [sic] for such..."
>
> Owen
OK I'll incorporate those.
Thanks
--
================================================
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
================================================
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 5
****************************************
