[arin-ppml] IPv6 as justification for IPv4?

Mon Apr 15 17:37:15 EDT 2013

Would you be interested in submitting a policy proposal to address the
issue?  If so, just fill out the short template at
https://www.arin.net/policy/pdp_appendix_b.html and submit it to
policy at arin.net (and Cc: arin-ppml at arin.net if you want it posted here).  I
(and likely several other AC members) would also be happy to help if you're
unsure about anything.

Once you propose a policy change, the AC assigns shepherds to work directly
with you, verifies that the topic is in scope and has a clearly defined
problem statement / rationale (or works with you to clarify it), and then
if it meets those requirements, accepts it as a draft policy to be
discussed at an upcoming policy meeting.

Thanks for participating in improving ARIN's policies.  I'm looking forward
to hopefully working with you more in the near future.

-Scott

On Mon, Apr 15, 2013 at 1:27 PM, Tim St. Pierre
<tim at communicatefreely.net>wrote:

>  Hi Scott,
>
> Yes, if that clause were added, I would have my allocation by the end of
> the week.  In fact, in my immediate need application attempt, I was able to
> document that I was actively providing connectivity to over 500 devices.
>
> The silly thing about requiring the /23 first, is that I have to somehow
> find a /23, assign it, then get my /22 and give back the /23.  A lot of
> nuisance for customers with static assignments and more work than it ought
> to be, since I can meet the spirit of the policy, just not the letter of it.
>
> Thanks!
>
> -Tim
>
>
> On 13-04-15 04:17 PM, Scott Leibrand wrote:
>
> Tim,
>
>  I think this is an issue that is only going to get worse as IPv4
> exhaustion makes upstream ISPs less willing to allocate large blocks of
> addresses to downstream customers.  In such a situation, I think it is
> entirely appropriate to allow a downstream ISP, which has a customer base
> large enough to justify a /23 (and is allocating those customers
> ARIN-assigned IPv6 space) to also get approved for an IPv4 /22, and be
> eligible to acquire it on the transfer market if the ARIN free pool is
> exhausted.  I would personally rather not liberalize 4.2.1.6. Immediate
> need, as that is supposed to be for "exceptional" cases, but perhaps adding
> a clause to the first bullet point of 4.2.2.2. Multihomed would be
> appropriate.  Maybe something like "or demonstrate the assignment of IPv6
> addresses to more than 500 devices"?
>
>  Would that kind of policy help for a situation like yours?
>
>  -Scott
>
>
> On Mon, Apr 15, 2013 at 9:01 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>
>> Tim,
>>
>> Thanks for bringing this up. It sounds like a real issue, which could use
>> some policy work. Cross-posting to PPML, where such policy discussions
>> occur.
>>
>> Scott
>>
>> On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" <tim at communicatefreely.net>
>> wrote:
>>
>> > Hello,
>> >
>> > We are a new ISP, and we have had some interesting dilemma's getting
>> > started.  I'm curious to know if this is something that has affected
>> > others, or if I'm just in a strange situation.
>> >
>> > We are building out an access network to reach business customers in a
>> > small town.  We will probably never be very big, but we like are town
>> > and are hoping to eventually extend our reach to most business in town.
>> > When we started, 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > Should there be an additional policy to deal with initial allocations
>> > where efficient utilization of X number of IPv6 /64s would serve as
>> > justification for a /22 IPv4, or perhaps some other scheme that makes it
>> > a little easier for new ISPs.  I understand that IPv4 is constrained,
>> > but we aren't out of them yet, and a small ISP still needs an allocation
>> > to function.
>> >
>> > Another alternative would be a new entrant policy similar to the
>> > immediate need clause, but with the following changes:
>> > -Only 50% must be used within 30 days
>> > -ISP must demonstrate that IPv6 has been deployed to end users
>> > -The same documentation of customer contracts and purchased equipment
>> > would still apply.
>> >
>> > I look around and see the big incumbents with no IPv6 to speak of, yet
>> > they have IPv4 for every customer.  Here I am as the little startup
>> > trying to make a go of it, but I'm at a serious disadvantage because I
>> > can't get any address resources.
>> >
>> > Am I just terribly unlucky, or is this becoming a problem for others as
>> > well?  I think the main issue is that upstream providers aren't able to
>> > hand out /24s like they used to, so showing a /23 equivalent from an
>> > upstream is next to impossible now.
>> >
>> > Thanks!
>> > -Tim
>> >
>> > --
>> > --
>> > Tim St. Pierre
>> > System Operator
>> > Communicate Freely
>> > 289 225 1220 x5101
>> > tim at communicatefreely.net
>> > www.communicatefreely.net
>> >
>> > _______________________________________________
>> > ARIN-Discuss
>> > You are receiving this message because you are subscribed to
>> > the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-discuss
>> > Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> --
> Tim St. Pierre
> System Operator
> Communicate Freely289 225 1220 x5101tim at communicatefreely.netwww.communicatefreely.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130415/9eb3d320/attachment.htm>