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
(David Farmer)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Matthew Kaufman)
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
(Owen DeLong)
6. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
7. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Apr 2013 15:52:08 -0500
From: David Farmer <[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: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 4/4/13 14:46 , Matthew Kaufman 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.
Current policy already allows /36s to be handed out, this adds /40s to
that, and allow you to change it to /32 as you see fit.
> If charging $1000 instead of $500 is a disincentive (I certainly think
> it is) make the /32 be $500.
I assume you didn't support the original version of the draft with /48s
either, and your not opposed to the changes to the draft, but the policy
intent overall. Or, is there something about the changes from the
original draft that you oppose.
> 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.
The last paragraph of the comments basically says that it would be
better to have a different solution for the fee schedule, but that is
out of scope of the PDP.
I'd be interested in talking with you about finding a way to meet such
needs.
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: 2
Date: Thu, 04 Apr 2013 16:14:13 -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 15:29 , William Herrin wrote:
> 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.
Actually, to that end I'll change the proposed 6.5.2.1 clause (g) adding
"or renumbering" to the end of the first sentence, resulting in;
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 or renumbering. Such expansions are not considered
subsequent allocations. However, any expansions beyond /32 are
considered subsequent allocations, and must conform to section 6.5.3.
This makes the policy intent abundantly clear without specifying
operational issues like the size of a reservation.
--
================================================
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, 04 Apr 2013 14:28:53 -0700
From: Matthew Kaufman <[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; format=flowed
On 4/4/2013 1:52 PM, David Farmer wrote:
> On 4/4/13 14:46 , Matthew Kaufman 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.
>
> Current policy already allows /36s to be handed out, this adds /40s to
> that, and allow you to change it to /32 as you see fit.
Well, that's a bug too. But certainly I don't think we should be handing
out /40s to ISPs. Probably not /36s either. How about /32s only, and up
to /16 with justification?
>
>> If charging $1000 instead of $500 is a disincentive (I certainly think
>> it is) make the /32 be $500.
>
> I assume you didn't support the original version of the draft with
> /48s either, and your not opposed to the changes to the draft, but the
> policy intent overall. Or, is there something about the changes from
> the original draft that you oppose.
>
Policy proposal as it stands exists only because of a bug in the fee
schedule. No ISP in their right mind would request a /40 instead of a
/36 (say) just because they can, given that initial allocation
justification is identical. Except for the fee schedule of course.
>> 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.
>
> The last paragraph of the comments basically says that it would be
> better to have a different solution for the fee schedule, but that is
> out of scope of the PDP.
>
I know it is. But this whole proposal is about working around the fee
schedule instead of fixing the root problem (that some ISPs think the
price for a /32 is too high and so incorrectly wish to get something
smaller)
> I'd be interested in talking with you about finding a way to meet such
> needs.
>
You know where to find me :)
Matthew Kaufman
------------------------------
Message: 4
Date: Thu, 04 Apr 2013 14:32:12 -0700
From: Matthew Kaufman <[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/2013 1:29 PM, William Herrin wrote:
> 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.
Maybe we should get a different board then?
> 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
Doesn't fix the root problem. ISPs should be getting /32s, and they
should be charged fees which are affordable and reasonable when they do
that. That ARIN wishes to make more money than that would bring in to
fund whatever it does with that is a flaw that needs fixing and the PDP
isn't going to be how that gets fixed.
I'd rather have thousands of angry ISPs who can't afford the price of a
/32 not deploying IPv6 because of that than having thousands of ISPs
getting stupidly small allocations and then doing stupid internal
conservation to keep their fees from rising when the whole point of a
bigger address space was to avoid this altogether.
One could make a good argument that if we made all the space allocated
the way ULA is allocated that the statistical odds of collision are tiny
and thus RIRs aren't even needed.
Matthew Kaufman
------------------------------
Message: 5
Date: Thu, 4 Apr 2013 14:34:00 -0700
From: Owen DeLong <[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: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 4, 2013, at 12:42 PM, Matthew Kaufman <[email protected]> wrote:
> 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?
>
Yes. However, we haven't yet found a good way to fix it, so we're contorting
policy a little further to attempt to address the issue instead.
> 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.
As was discussed earlier (and believe me, I'm no fan of this, but it does seem
the best available outcome at this point), there are too many ISPs in the /32
category to sustain ARIN if /32 falls to $500/year. OTOH, there is a strong
desire to provide support for ISPs that are in this XX-Small category in IPv4
(/22 or less) to be able to add IPv6 without having to pay more than the new
fee structure for their IPv4 holdings.
>> , 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".
>
This is a discussion about the manner in which they can give back part of what
we gave them, so I'm not sure how the first part isn't already addressed. As to
the latter, if you have a better fee structure proposal, I suggest submitting
it to the ACSP and I'm sure the board will consider it.
>> 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?
No, it's all about the politics of money.
Owen
------------------------------
Message: 6
Date: Thu, 4 Apr 2013 14:40:20 -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=us-ascii
I support this change.
Owen
On Apr 4, 2013, at 2:14 PM, David Farmer <[email protected]> wrote:
> On 4/4/13 15:29 , William Herrin wrote:
>> 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.
>
> Actually, to that end I'll change the proposed 6.5.2.1 clause (g) adding "or
> renumbering" to the end of the first sentence, resulting in;
>
> 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 or
> renumbering. Such expansions are not considered subsequent allocations.
> However, any expansions beyond /32 are considered subsequent allocations, and
> must conform to section 6.5.3.
>
> This makes the policy intent abundantly clear without specifying operational
> issues like the size of a reservation.
>
>
> --
> ================================================
> 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: 7
Date: Thu, 4 Apr 2013 14:40:49 -0700
From: Owen DeLong <[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: <[email protected]>
Content-Type: text/plain; charset=us-ascii
+1
On Apr 4, 2013, at 2:28 PM, Matthew Kaufman <[email protected]> wrote:
> On 4/4/2013 1:52 PM, David Farmer wrote:
>> On 4/4/13 14:46 , Matthew Kaufman 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.
>>
>> Current policy already allows /36s to be handed out, this adds /40s to that,
>> and allow you to change it to /32 as you see fit.
>
> Well, that's a bug too. But certainly I don't think we should be handing out
> /40s to ISPs. Probably not /36s either. How about /32s only, and up to /16
> with justification?
>
>>
>>> If charging $1000 instead of $500 is a disincentive (I certainly think
>>> it is) make the /32 be $500.
>>
>> I assume you didn't support the original version of the draft with /48s
>> either, and your not opposed to the changes to the draft, but the policy
>> intent overall. Or, is there something about the changes from the original
>> draft that you oppose.
>>
>
> Policy proposal as it stands exists only because of a bug in the fee
> schedule. No ISP in their right mind would request a /40 instead of a /36
> (say) just because they can, given that initial allocation justification is
> identical. Except for the fee schedule of course.
>
>>> 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.
>>
>> The last paragraph of the comments basically says that it would be better to
>> have a different solution for the fee schedule, but that is out of scope of
>> the PDP.
>>
>
> I know it is. But this whole proposal is about working around the fee
> schedule instead of fixing the root problem (that some ISPs think the price
> for a /32 is too high and so incorrectly wish to get something smaller)
>
>> I'd be interested in talking with you about finding a way to meet such needs.
>>
>
> You know where to find me :)
>
> Matthew Kaufman
>
> _______________________________________________
> 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.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 7
****************************************
