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
(William Herrin)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Matthew Kaufman)
5. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Matthew Kaufman)
6. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(William Herrin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Apr 2013 14:31:20 -0400
From: William Herrin <[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:
<CAP-guGUiW0oWQ9OeRwWtH9L9kp5Ms=w6dniddpyg1dqx1rw...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 4, 2013 at 1:15 PM, David Farmer <[email protected]> wrote:
> 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.
Hi David,
CIDR blocks or aggregable blocks. 10.0.0.0-10.11.12.13 is a contiguous
block but it doesn't _aggregate_ for routing purposes per NRPM 6.3.4.
> b. Whole blocks are returned to the extent practicable.
I liked the original language in the proposal which was along the
lines of: "the aggregate retained must be either the first (lowest
numbered) subnet or the last (highest numbered) subnet of the original
allocation."
I see Owen's point but when the time eventually arrives that we have
to think about allocating the space in these reserved areas, I'd
rather that space be less fragmented than more. Anyone who doesn't
have a /32 yet can read the policy and figure out what they need to do
if they want to be able to shed cost. And anyone who already has their
/32... thank you. But seriously, show of hands, which of you wants to
return the start and end of your /32 and keep only a chunk in the
middle somewhere?
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 2
Date: Thu, 04 Apr 2013 13:57:37 -0500
From: David Farmer <[email protected]>
To: William Herrin <[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 13:31 , William Herrin wrote:
> On Thu, Apr 4, 2013 at 1:15 PM, David Farmer <[email protected]> wrote:
>> 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.
OK, how about?
a. The end result is not an increase in the number of aggregatable
blocks held by the organization.
> Hi David,
>
> CIDR blocks or aggregable blocks. 10.0.0.0-10.11.12.13 is a contiguous
> block but it doesn't _aggregate_ for routing purposes per NRPM 6.3.4.
>
>
>> b. Whole blocks are returned to the extent practicable.
>
> I liked the original language in the proposal which was along the
> lines of: "the aggregate retained must be either the first (lowest
> numbered) subnet or the last (highest numbered) subnet of the original
> allocation."
>
> I see Owen's point but when the time eventually arrives that we have
> to think about allocating the space in these reserved areas, I'd
> rather that space be less fragmented than more. Anyone who doesn't
> have a /32 yet can read the policy and figure out what they need to do
> if they want to be able to shed cost. And anyone who already has their
> /32... thank you. But seriously, show of hands, which of you wants to
> return the start and end of your /32 and keep only a chunk in the
> middle somewhere?
It all depends where they started using there blocks. The current use
case for this policy is to reduce your holding because of the fee
schedule, but I'd prefer generic rules that allow flexibility for future
conditions. Also, this is the current operational practice we have now,
to allow the LIR to select which /36 to retain. If someone started
using their /32 in the middle why force them to renumber?
How do others feel, I was planning to bring this up as a discussion
point in the Barbados meeting. Unless a number of others chime in, I'll
go with the current language for the Barbados meeting. This policy has
to come back for another consultation so we have plenty of time to
change it to what you are talking about if there is consensus for it.
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: 3
Date: Thu, 4 Apr 2013 12:06:04 -0700
From: Owen DeLong <[email protected]>
To: William Herrin <[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=us-ascii
On Apr 4, 2013, at 11:31 , William Herrin <[email protected]> wrote:
> On Thu, Apr 4, 2013 at 1:15 PM, David Farmer <[email protected]> wrote:
>> 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.
>
> Hi David,
>
> CIDR blocks or aggregable blocks. 10.0.0.0-10.11.12.13 is a contiguous
> block but it doesn't _aggregate_ for routing purposes per NRPM 6.3.4.
Bill,
Since ARIN will be issuing them as aggregable nibble-boundary based
blocks (we are talking IPv6 policy, so your example is specious),
anything which doesn't increase the number of discontiguous blocks
will, by definition, remain aggregable.
>> b. Whole blocks are returned to the extent practicable.
>
> I liked the original language in the proposal which was along the
> lines of: "the aggregate retained must be either the first (lowest
> numbered) subnet or the last (highest numbered) subnet of the original
> allocation."
>
> I see Owen's point but when the time eventually arrives that we have
> to think about allocating the space in these reserved areas, I'd
> rather that space be less fragmented than more. Anyone who doesn't
> have a /32 yet can read the policy and figure out what they need to do
> if they want to be able to shed cost. And anyone who already has their
> /32... thank you. But seriously, show of hands, which of you wants to
> return the start and end of your /32 and keep only a chunk in the
> middle somewhere?
I do not expect that IPv6 will be in use so long as for that time to come.
I think we will be lucky if technology doesn't outpace the capabilities of
IPv6 in the next 100 years. There is probably a few thousand years
worth of IPv6 address space. Especially if we consider the use of
the 6 remaining /3s.
Owen
------------------------------
Message: 4
Date: Thu, 04 Apr 2013 12:42:33 -0700
From: Matthew Kaufman <[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 4/4/2013 11:57 AM, David Farmer wrote:
>
> It all depends where they started using there blocks. The current use
> case for this policy is to reduce your holding because of the fee schedule
Doesn't this just mean that the new fee schedule is broken?
IPv6 addresses are by no means scarce... why are we treating them that
way? If we gave someone a /32 and they aren't using all of it yet, they
should just keep the /32.
> , but I'd prefer generic rules that allow flexibility for future
> conditions.
Agreed. How about "you can't give us back anything but what we gave you"
and "we won't have stupid fee schedules that ever encourage you to want
to do otherwise".
> Also, this is the current operational practice we have now, to allow
> the LIR to select which /36 to retain. If someone started using their
> /32 in the middle why force them to renumber?
>
Why force them to give up the /32 at all? Are we running out of them or
something?
Matthew Kaufman
------------------------------
Message: 5
Date: Thu, 04 Apr 2013 12:46:50 -0700
From: Matthew Kaufman <[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
Totally oppose the below. There's no reason why we should ever be giving
an ISP something smaller than a /32. Fix the silly fee schedule.
If charging $1000 instead of $500 is a disincentive (I certainly think
it is) make the /32 be $500.
Matthew Kaufman
ps. Example as to why I think it is a disincentive: I run a microwave
network linking multiple mountaintops serving the tiny needs of several
different non-profit organizations, all paid for out of my own pocket.
All of it is numbered out of legacy space I hold. Guess how much my wife
thinks I should spend per year on an IPv6 allocation from ARIN so that I
can add IPv6 to this network? I'll give you a hint: $500/year is too much.
On 4/4/2013 10:15 AM, 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.
>
> ---
>
> 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
>
>
------------------------------
Message: 6
Date: Thu, 4 Apr 2013 16:29:03 -0400
From: William Herrin <[email protected]>
To: Matthew Kaufman <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<CAP-guGWHmC0G=wezsv_a0qavye0htnmku_ebaz7b1_n5a5k...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 4, 2013 at 3:46 PM, Matthew Kaufman <[email protected]> wrote:
> Totally oppose the below. There's no reason why we should ever be giving an
> ISP something smaller than a /32. Fix the silly fee schedule.
>
> If charging $1000 instead of $500 is a disincentive (I certainly think it
> is) make the /32 be $500.
>
> Matthew Kaufman
>
> ps. Example as to why I think it is a disincentive: I run a microwave
> network linking multiple mountaintops serving the tiny needs of several
> different non-profit organizations, all paid for out of my own pocket. All
> of it is numbered out of legacy space I hold. Guess how much my wife thinks
> I should spend per year on an IPv6 allocation from ARIN so that I can add
> IPv6 to this network? I'll give you a hint: $500/year is too much.
Hi Matthew,
This is yet another example why the Board should defer any non-trivial
revenue collection on IPv6 until it supersedes IPv4 as the primary
protocol in use on the Internet. They'll figure it out eventually and
when they do they'll quit making choices which needlessly stall IPv6
deployment.
I mean really, there are so many things stalling IPv6 deployment that
we can't do anything about. Why gratuitously stall it even more with
fees that the economics of the situation don't support?
Se la vie. Today, the battle we can win is getting IPv6, *any* IPv6,
into the hands of ISPs who are willing to do it if it doesn't change
their ARIN costs. The board isn't willing to set the IPv6 fees for
every ISP holding an IPv6 /32 at $500, but they'll apparently accept
making a smaller allocation to an ISP for $500. For that reason, I'd
encourage you to support the proposal.
Let's just make sure they can convert to a /32 later without renumbering.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 6
****************************************
