[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Tue Nov 26 14:20:15 EST 2013

I think the easy fix here is remove the requirement to already be using a
/20, and instead have them provide strong justification about how the
addresses will be used in the next 90 days for ISPs, in the next year for
end sites, and in the next two years for transfers.

I'm thinking something like immediate need, where they have some real data
to show how the addresses will be used, but not necessarily in the next 30
days.

Possibly VC commitment to spend on purchasing 3,000 servers (each booking 1
IP) or 3,000 residential customer pre-orders, or 1,500 residential customer
pre-orders, and a business plan to use revenue booked to deploy a second
equally sized market in the time.

Basically if you have the IP justification to get a /20 from your ISP, then
submit that to ARIN and get a /21 slow start.  Use it and come back.

___Jason

On Fri, Nov 22, 2013 at 5:40 PM, Randy Carpenter <rcarpen at network1.net>wrote:

>
> I have several single-homed clients who are in the position of having a
> /23 or /22 from an upstream, and needing additional space. They are refused.
>
> They have a justified need, and are established networks, but ARIN policy
> prevents them from getting their own space because they don't already have
> a /20. At this point in the game the requirement of having space before you
> can get space seems a little ridiculous, particularly at the current
> minimums. If they were able to get their own space, they could hand back
> most or all of the upstream space, thus providing a benefit to them as well.
>
> I am very in favor of moving the minimums to /22 for single-homed at
> least. I would also be in favor of only requiring an upstream allocation of
> a /24, so long as the ISP can show justified need for a full /22.
>
> For multi-homed, I would be fine with either /23 or /24.
>
>
> thanks,
> -Randy
>
> ----- Original Message -----
> > David,
> >
> > There are going to be lots of reasons why an ISP can't provide space to a
> > downstream post run out, even when on paper they have space.
> >
> > 1) Space dedicated to another region
> > 2) Cost Prohibitive for downstream due to cost recovery.
> > 3) Forward looking project that fits within the 24 month window.
> >
> > I can see the conversation now.
> >
> > Downstream: I need a /24 of IP space
> > Upstream: NO
> > Downstream: Ok, I'm telling on you.
> > Upstream: We didn't sign the contract, find someone else to provide
> service.
> >
> > In a primary market there are going to be "others". In a secondary
> market you
> > will be out of luck.
> >
> > We can't wrap this policy in a complicated beat stick. If a company has a
> > need for an initial allocation
> > They are going to have to go to the transfer market. We should be able to
> > give them the initial allocation without adding complexity.
> >
> > Thanks,
> >
> > Kevin
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of David Farmer
> > Sent: Friday, November 22, 2013 2:26 PM
> > To: Brandon Ross; Jo Rhett
> > Cc: ARIN-PPML List
> > Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
> >
> > On 11/22/13, 08:50 , Brandon Ross wrote:
> > > On Thu, 21 Nov 2013, Jo Rhett wrote:
> > >
> > >> I'd like to see some actual documented issues with this. Almost
> > >> everyone I know is sitting on large amounts of smaller blocks they
> > >> can easily allocate to people. It's the larger (/21 or greater)
> > >> blocks which are becoming scarce.
> > >
> > > What kind of documentation are you looking for?
> >
> > I would think an a copy of an email or a letter from the upstream which
> > confirms the upstream can't/won't provide them address space, for some
> > reason other than they don't think the customer justifies additional
> address
> > space.
> >
> > It is unfair for ARIN to withhold address space because the upstream has
> > address space but won't provide it to the requester for what ever
> reason.  I
> > think it is reasonable to require some confirming documentation that the
> > upstream is not providing address space.  You can't just "say" your ISP
> is
> > not providing it.
> >
> > However, if an ISP is saying you don't justify additional address space,
> then
> > you shouldn't qualify for address space from ARIN under an exception like
> > this.
> >
> > Also, ARIN should be able to refuse if they feel there is collusion
> between
> > an ISP and a requester.
> >
> > 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
> > ================================================
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> Public
> > Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131126/572d127b/attachment.htm>