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: IPv6 as justification for IPv4? (David Farmer)
2. Re: IPv6 as justification for IPv4? ([email protected])
3. Re: Justifying an ISP /22 (Otis L. Surratt, Jr.)
4. Re: IPv6 as justification for IPv4? (John Springer)
5. ARIN 31 travel (Mark Elkins)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Apr 2013 13:58:06 -0500
From: David Farmer <[email protected]>
To: John Springer <[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] IPv6 as justification for IPv4?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
While not policy text this is still more about the solution than the
problem. 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. A problem statement needs to
motivate why change is necessary as well as how to solve it. So, what's
wrong with the current policy? Not just what should the new policy look
like. In the above I mostly only see what should the new policy look
like and almost nothing about issues created by the current policy.
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, 18 Apr 2013 14:29:19 -0600
From: <[email protected]>
To: "David Farmer" <[email protected]>, "John Springer"
<[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] IPv6 as justification for IPv4?
Message-ID: <[email protected]>
Content-Type: text/plain;charset=iso-8859-1; format="flowed"
On Thu, 18 Apr 2013 13:58:06 -0500
David Farmer <[email protected]> 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
>
> While not policy text this is still more about the solution than the
>problem. 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. A problem statement needs to motivate
>why change is necessary as well as how to solve it. So, what's wrong with
>the current policy? Not just what should the new policy look like. In the
>above I mostly only see what should the new policy look like and almost
>nothing about issues created by the current policy.
The current problem is that the amount of PA space a "new" ISP has is becoming
more a function of the amount of available PI space the upstream provider has
at his disposal, than it is the need or size of the ISP.
In rural settings switching providers or multi-homing may not be economically
possible because of distance or access to needed infrastructure.
I have seen this first hand as a small upstream. I cannot qualify for more PI
space
because I don't meet the 80% rule, (It's quite difficult if all you have is a
/20)
and due to restructuring and careful use of IP I have been able to do without
additional
IP for a number of years. From ARIN's perspective my 3-month usage rate is 0.
I am also an upstream for two WISP's each with aprox 1000-1500 customers. They
can easily
justify a /22. Each one would be 25% of my total PI space. I can't do it and
they can't qualify
for their own PI space because I could only squeeze out /24 to each.
>
> 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
> ================================================
> _______________________________________________
> 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.
Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
------------------------------
Message: 3
Date: Thu, 18 Apr 2013 16:21:19 -0500
From: "Otis L. Surratt, Jr." <[email protected]>
To: "Owen DeLong" <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Justifying an ISP /22
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
-----Original Message-----
From: Owen DeLong [mailto:[email protected]]
Sent: Wednesday, April 17, 2013 10:38 PM
To: Otis L. Surratt, Jr.
Cc: [email protected]
Subject: Re: [arin-ppml] Justifying an ISP /22
On Apr 17, 2013, at 3:41 PM, "Otis L. Surratt, Jr." <[email protected]>
wrote:
> Jumping on ppml late..
>
> Randy,
>
>> 1. Be an ISP with *any* amount of space from an upstream
>
> I'm not so sure this would be advisable? Wouldn't it be better to have
> at least a /24? Or is this what you had in mind?
>
>>In at least one case, part of the problem is he can't even get a /24
from his upstreams. This will become a more and more prevalent problem
as runout continues to progress.
I see your point and that is a concern as well. So, as runout continues
do you think it would be advisable to accept any PA space as Randy
suggested?
>> 4. Be forced to take an automatic IPv6 allocation (at whatever
> NRPM-supported size is appropriate (preferably /32 min.))
>>I'm not sure I buy this, either. As much as I support IPv6 and favor
increased
>>IPv6 rollout (the sooner we're off v4 the better we will all be), I
don't believe that inflicting IPv6 allocations on people that aren't
ready to ask for them does anything other than skew statistics.
I see the point here also. I think most that take an IPv6 allocation
don't immediately deploy so the statistics could be skewed anyway?
New networks should have the mind set of IPv6 anyway but I agree forcing
doesn't seem like the best way but then again...
Otis
------------------------------
Message: 4
Date: Thu, 18 Apr 2013 14:38:40 -0700 (PDT)
From: John Springer <[email protected]>
To: David Farmer <[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] IPv6 as justification for IPv4?
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: [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: 5
Date: Fri, 19 Apr 2013 01:22:03 +0200
From: Mark Elkins <[email protected]>
To: ARIN-PPML List <[email protected]>
Subject: [arin-ppml] ARIN 31 travel
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Not sure how appropriate this is but...
Just arrived at the Hilton Barbados. Taxi fare is US$21.00 and there
will be a Hotel Rep with sign board with your name on a list just as
you are about to exit the Airport. They'll write out a receipt and
should find a Taxi for you.
--
. . ___. .__ Posix Systems - (South) Africa
/| /| / /__ [email protected] - Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6147 bytes
Desc: not available
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130419/10496f95/attachment.bin>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 39
*****************************************