[arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs

[Matthew Kaufman]

On 4/6/2013 12:00 PM, Michael Sinatra wrote:
> On 03/27/13 17:45, David Farmer wrote:
>> On 3/27/13 18:00 , Michael Sinatra wrote:
>>
>>> Or, to put more bluntly, if ARIN's fee structure is itself creating
>>> disincentives for proper IPv6 adoption, then let's go back and (re-)fix
>>> that problem.
>>>
>>> Oppose 2013-3.
>> Michael and others opposed,
>>
>> What about modifying the proposal to /40, require a minimum reservation
>> of /32 (or maybe /28) be held for ISPs that elect for /40 or /36
>> allocations, allow subsequent allocations to expansion from /40 to /36
>> and then to /32 without evaluating there current IPv6 usage.  Thereby
>> ensuring they can grow their allocation in place and allowing policy
>> flexibility that enables the fee structure equity that the new xx-small
>> category seems to provided.
> Sorry to be responding to an earlier part of the thread, but I was on
> vacation and lost track of this thread, and you did ask me a direct
> question.  I owe you the courtesy of an answer.
>
> The answer to your question is no.  If I start out with a /40 or /36 and
> then rapidly grow into a /32 (and can justify the fees), then I am going
> to end up with a largely organic addressing plan.  We're giving
> incentives for people to cram all of their addressing into a corner of
> the total space that they should be using and it will create a really
> messy IPv6 deployment.

Worse, we're creating a messy IPv6 situation downstream... as Owen 
points out, 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.

We should be telling ISPs of all sizes "IPv6 is huge... come get a /32 
or bigger... do sensible things when you make your addressing plans... 
do sensible things when you sell service to your customers" and not 
"here's a way to save a buck by pretending IPv6 is like IPv4"

You're right (in the part below that I deleted)... the bug is the fee 
structure and there's absolutely no reason to try to muck with the 
policy, which can't possibly fix the real problem.

Matthew Kaufman