[arin-ppml] IPv6 as justification for IPv4?

[John Springer]

OK, I'll bite.

On Thu, 18 Apr 2013, David Farmer wrote:

> On 4/17/13 12:55 , John Springer wrote:
>> 
>> Paste from arin-discuss, from an exchange between Owen and Randy Carpenter
>> 
>>>> I think the real problem here is requiring pre-existing PA space of
>>>> certain amounts as the initial test. The combination of a customer
>>>> base, need, and efficient utilization of any PA space is probably the
>>>> better test.
>> 
>>> This is something that I believe really needs fixed (and needs to be
>>> fixed very quickly).
>> 
>>> -Randy
>> 
>> This seems to be rather far along to a problem statement. I agree with
>> both statements.
>> 
>> John Springer
>


Thanks to Tim St. Pierre. Any contextual defects are mine.

> While not policy text this is still more about the solution than the problem.

I take it that you refer to this:

>>>> I think the real problem here is requiring pre-existing PA space of
>>>> certain amounts as the initial test.

Do you think that "Current policy requiring pre-existing PA creates
undesirable results such as that cited by OP at: 
http://lists.arin.net/pipermail/arin-discuss/2013-April/002531.html"
is a superior construction?

> There needs to be more about why "requiring pre-existing PA" creates 
> undesirable results for example, or how current policy effects new ISPs 
> businesses in undesirable ways.

Perhaps something along the line of:

OP, in his post on arin-discuss cited above, details the following reasons 
"why "requiring pre-existing PA" creates undesirable results".

1) ...we requested a /32 IPv6 from ARIN.  We had to explain what we were 
doing, and our coverage area, etc.  This seems reasonable and all, and 
eventually we got our /32.  At this point, all we had was a /28 IPv4 
SWIP'd from an upstream, so our fees jumped from $0 to $1800 for the year.

2) Now we have a running network, with real customers, and we need IPv4 
allocations, since running IPv6 only for retail Internet is a bit 
problematic.  We tried to get a /24 out of our upstream, but they are 
essentially out of address space and can't give us any.  They can't get 
any more either, because they just got taken over by a larger carrier that 
has free pools, but on a different AS. We do have another upstream that we 
could connect to, but they can't give us anything more than a /28 either.

3) I applied for a /22 under the immediate need category, but I don't
qualify, since I can really only use about 2/3 of it within 30 days.

4) So now I'm stuck with a customer base that has native IPv6 for 
everyone, but only a /29 IPv4 to share between 12 offices and about 200 or 
so retail WiFi users.  I have to do crazy incoming NAT nonsense to support 
my customers mail servers and VPN devices, and I'm crossing my fingers 
that the wireless users don't do something stupid and get us all 
blacklisted.

Is this enough or do we need more? There _IS_ more from OP and others.

> A problem statement needs to motivate why 
> change is necessary as well as how to solve it.

I don't think this is correct. When we were working with the author of 
3GPP, we left the details of the solution to the AC and concentrated on 
the problem statement. I think the new PDP requires this.

> So, what's wrong with the current policy?

See above and we can sure re-read discuss and ppml for more ammo, if 
needed.

> Not just what should the new policy look like.

Which is cart before the horse right here, correct? Have I eliminated 
that?

> In the above 
> I mostly only see what should the new policy look like and almost nothing 
> about issues created by the current policy.

Have I fixed that now? I tried to restrict myself to "issues created by 
the current policy" and no "what should the new policy look like"? Did I 
succeed?

John Springer

>
> Thanks
>
> -- 
> ================================================
> David Farmer               Email: farmer at umn.edu
> 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
> ================================================
>
>