<div dir="ltr">Paul,<div><br></div><div>Lets assume that you are using a <span style="font-size:12.8px">/22 and a /23 from your upstream provider, and they now want it back.</span></div><div><span style="font-size:12.8px">Lets also assume that you have good documentation to show how you are using that Provider Aggregatable IP space, and 80+% is in use.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">You could then (if you don't already have an ARIN OrgID) use your US or Canadian, or Caribbean Government issued business tax ID number to establish an OrgID. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">You could then get ARIN pre-approval for transfer of a /22 and a /23. (You may be able to justify more based on two year growth projections). Once approved to can complete as many transfers of IPv4 space up to the amount approved within a two years from when the approval is granted. Each discrete transfer will cost you $500 (in addition to whatever the IP space costs you).</span></div><div><br></div><div><span style="font-size:12.8px">At any point in the process you can show all of your currently held resources are above 80% and get a new pre-approval for a two year supply.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">E.g. you are using a /22 and a /23 which you plan to return. You can show you used you most recent /23 over the last two years, and you expect future continued growth. You can likely get a /21. Then in six months time you can show 80+% utilization of the /21. That means the new /23 was used up in 6 months. If future growth is anticipated at the same rate a two year supply would be a /21. You could likely get pre-approval for a /21 and have up to two years to complete one or more transfer equalling up to a /21. If it takes longer than two years, your pre-approval expires, and you have to once again show 80% utilization and a new two year growth projection.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The OrgID has to be with your legal entity. ARIN does sometime fix OrgIDs when it is a simple change as in we are "Company, Inc." not "Company Incorporated"... this was clearly a mistake when we made the org, or if you can show M&A activity (typically legal paperwork of public record filed with the secretary of the state where the entity</span><span style="font-size:12.8px"> was created or the surviving legal entity from the M&A) and the direct ARIN issued resources are used at 80+% then they will update transfer the resources to the newly formed (correct) OrgID</span><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 12:20 AM, Paul <span dir="ltr"><<a href="mailto:pmcnary@cameron.net" target="_blank">pmcnary@cameron.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
I have a question. Our small ISP company is losing a /22 and a /23
we were reallocated years<br>
ago. The company sold and now is requiring us to give these back.
This was <br>
unexpected. We did not see that coming and by the time we got the
news and started<br>
the process to directly acquire IPv4 ARIN was out.<br>
<br>
My question is: if we justify a certain IP Block maybe a /21 or /22.
Is it true if we acquire<br>
them a /24 at a time we have to wait 12 months before we can get the
next transfer<br>
approved? and have to pay another $500 for each /24 we get
transferred in. So if we are lucky to find a legacy owner, I have
been told by ARIN that they need proof of the company<br>
from the secretary of state. Back in the 80's and 90's fictitious
names did not have to<br>
be registered by most states especially in the case of a sole
proprietorship or a<br>
small corporation using an unregistered DBA. This seems to be the
case of acquiring<br>
and trying to transfer legacy IP Blocks in to ARIN. We were required
to get a new ORG-ID<br>
because the dba we were using at the time of the re-allocation
wasn't registered with the state.<br>
It was perfectly legal at the time the ORG-ID was issued. This is
the biggest obstacle<br>
I have had. I am scared to acquire Legacy Resources because ARIN
threatens to<br>
claw them back if I try to transfer and register them. The big
companies have lawyers that<br>
can fight the ARIN policies and win, we do not. <br>
<br>
If I am misunderstanding the transfer system please clue me in. This
is extremely<br>
expensive for a small ISP like us. I see both sides of the proposal
as detrimental <br>
to small ISP's. We are currently having to re-IP 8 /24's to a /27.
Very hard to do!<br>
<br>
I want what ever it takes to transfer in resources up to the
justification amount.<br>
It might take 1 year maybe 10 years and not be charged on every /24
up to<br>
our justification.. <br>
<br>
IPv6 direct allocations were supposed to get a $500 direct
allocation by now.<br>
A $500 direct allocation of IPv6 would help but we have to find
enough IPv4<br>
to stay in business. Currently our fiber provider can provide IPv6
to our<br>
rural area.<br>
<br>
Please help me understand the bureaucracy that ARIN is?<br>
<br>
Thanks<br>
Paul McNary<br>
McNary Computer Services<div><div class="h5"><br>
<br>
<br>
<div>On 2/18/2016 10:50 PM, Randy Carpenter
wrote:<br>
</div>
<blockquote type="cite">
<pre>So, you are saying that you need addresses, but can't justify it? I keep hearing the argument and it makes no sense.
I manage the IP networks of a bunch of small ISPs. I have never had an issue with justifying their needs. There certainly are instances where it would be nice to have some more space to have more flexibility and for future needs. But, we can't justify the actual need, so we shouldn't get the space. Others have a need and can justify it, therefore they should be able to get it.
Making it trivial to get space would lead to those who do *not* need it getting it because they can, which will reduce the amount of space available to those who actually need it.
I oppose vehemently.
thanks,
-Randy
----- On Feb 18, 2016, at 11:07 PM, Steven Ryerse <a href="mailto:SRyerse@eclipse-networks.com" target="_blank">SRyerse@eclipse-networks.com</a> wrote:
</pre>
<blockquote type="cite">
<pre>Milton is right! We are one of those small ISPs and the deck is stacked against
us on purpose by larger organizations. It is time to move on and stop arranging
the deck chairs on the IPv4 Titanic like other regions have. It’s 2016 not
2001. I support this policy!
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
<a href="http://www.eclipse-networks.com" target="_blank">www.eclipse-networks.com</a>
<a href="tel:770.656.1460" value="+17706561460" target="_blank">770.656.1460</a> - Cell
<a href="tel:770.399.9099" value="+17703999099" target="_blank">770.399.9099</a>- Office
℠ Eclipse Networks, Inc.
Conquering Complex Networks ℠
From: <a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a> [<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">mailto:arin-ppml-bounces@arin.net</a>] On Behalf
Of Mueller, Milton L
Sent: Thursday, February 18, 2016 10:47 PM
To: Jason Schiller <a href="mailto:jschiller@google.com" target="_blank"><jschiller@google.com></a>
Cc: ARIN PPML <a href="mailto:arin-ppml@arin.net" target="_blank"><arin-ppml@arin.net></a>
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based
evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks
Really. Am I going to have to be the first to point out the irony of Google
employees complaining that companies with "deep pockets" and "the most
profitable services" will dominate the address market if we make minor
relaxations of need assessments?
What's wrong with this picture? Think, folks.
Isn't it obvious that companies like Google are in a very good position to get
the addresses they want - via less than transparent market mechanisms such as
options contracts and acquisitions? And isn't it possible that they might be
trying to prevent smaller companies from participating in the market by
throwing up artificial barriers?
All this talk of "fairness" overlooks the fact that it's more fair to have
simple, transparent bidding and less bureaucracy. Smaller bidders can easily
afford smaller chunks of numbers, and they benefit from the reduced
administrative burden and delays associated with pointless and restrictive
needs assessments. When I hear smaller ISPs who need addresses making Jason's
arguments, I might take them seriously. Until then, no.
--MM
From: <a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a> < <a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a> > on behalf of
Jason Schiller < <a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a> >
Sent: Thursday, February 18, 2016 3:11 PM
To: Vaughn Thurman - Swift Systems
Cc: ARIN PPML
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based
evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks
+1 to what MCTim, Owen, and Vaughn said.
In general I oppose transfers with no need.
If there are "networks in need of additional IPv4 addresses", surely they should
be able to show this, in accord with long standing practice.
I'd rather us not move to a situation which enables/encourages speculation and
profit taking (or rent-seeking if you will) in re: IP resource distribution.
I'd also rather not encourage one competitor in a business segment to be able to
better stockpile addresses and for that to become a competitive advantage
against other providers in the space. Additionally if this is done in a wide
enough scale it can sufficiently lengthen wide spread IPv6 adoption.
This policy would also allow for companies with the deepest pockets and the most
profitable services to concentrate IPv4 space. I'm not sure that is more "fair"
than the pre-existing framework for "fair".
__Jason
On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman - Swift Systems <
<a href="mailto:vaughn@swiftsystems.com" target="_blank">vaughn@swiftsystems.com</a> > wrote:
+1
Sent from my mobile device, please forgive brevity and typos.
On Feb 18, 2016, at 2:16 PM, Owen DeLong < <a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a> > wrote:
+1 — McTim said it very well.
Owen
On Feb 18, 2016, at 10:34 , McTim < <a href="mailto:dogwallah@gmail.com" target="_blank">dogwallah@gmail.com</a> > wrote:
I am opposed.
If there are " networks in need of additional IPv4 addresses", surely they
should be able to show this, in accord with long standing practice.
I'd rather us not move to a situation which enables/encourages speculation and
profit taking (or rent-seeking if you will) in re: IP resource distribution.
Regards,
McTim
On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer < <a href="mailto:lsawyer@gci.com" target="_blank">lsawyer@gci.com</a> > wrote:
Good afternoon -
Based on feedback from Montreal as well as internal discussions, I've reworked
this policy.
AC members and ARIN staff are looking for additional feedback, as well as your
position in terms
of supporting or opposing this draft policy.
We'll be discussing this policy, as well as any feedback provided on this week's
AC teleconference,
so I'm very appreciative of your input.
Thanks,
Leif Sawyer
Shepherd - ARIN-2015-9
NRPM section 8: <a href="https://www.arin.net/policy/nrpm.html#eight" target="_blank">https://www.arin.net/policy/nrpm.html#eight</a>
Most current draft policy text follows:
--
Draft Policy ARIN-2015-9
Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4
netblocks
Original Date: 23 September 2015
Updated: 16 February, 2016
Problem statement:
The current needs-based evaluation language in NRPM sections 8.2 and 8.3,
regarding transfer of IPv4
netblocks from one organization to another, may cause a recipient organization
to bypass the ARIN
registry entirely in order to secure the needed IPv4 netblocks in a more timely
fashion directly from the
current holder. The result is that the data visible in ARIN registry may become
more inaccurate over
time.
Policy statement:
This proposal eliminates all needs-based evaluation language for sections 8.2
and 8.3, allowing
transfers to be reflected in the database as they occur following an agreement
of transfer from the
resource provider to the recipient.
Section 8.1 Principles:
- Strike the fragment from the 3rd paragraph which reads
", based on justified need, "
so the resulting text reads
"Number resources are issued to organizations, not to individuals representing
those organizations."
Section 8.2 Mergers and Acquisitions:
- Change the 4th bullet from:
"The resources to be transferred will be subject to ARIN policies."
to:
"The resources to be transferred will be subject to ARIN policies, excluding any
policies related to needs-based justification."
- Strike the final paragraph which begins "In the event that number resources of
the combined organizations are no longer justified under ARIN policy ..."
Section 8.3 Transfers between Specified Recipients within the ARIN Region:
- Change the first bullet under "Conditions on recipient of the transfer" from:
"The recipient must demonstrate the need for up to a 24-month supply of IP
address resources under current ARIN policies and sign an RSA."
to:
"The recipient must sign an RSA."
- Change the 2nd bullet under "Conditions on recipient of the transfer" from:
"The resources to be transferred will be subject to ARIN policies."
to:
"The resources to be transferred will be subject to ARIN policies, excluding any
policies related to needs-based justification."
Comments:
a. Timetable for implementation: Immediate
b. Anything else
As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and ARIN)
have now been
exhausted, networks in need of additional IPv4 addresses have shifted away from
the practice of
receiving them from the RIR's resource pool. Instead, networks in need are
seeking out current holders
of IPv4 resources who are willing to transfer them in order to fulfill that
need. Accordingly, the RIR's
primary responsibility vis-à-vis IPv4 netblock governance has shifted from
"allocation" to ensuring an
accurate registry database.
The RIPE registry can be used as a reference of one which has evolved over the
past couple years to
shift their focus away from conservation/allocation and towards database
accuracy. IPv4 netblock
transfers within that RIR consist merely of validating authenticity of the
parties requesting a transfer.
Provided the organizations meet the basic requirement of RIR membership, and
that the transferring
organization has the valid authority to request the transfer, the transaction
completes without any
"needs-based" review.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a> ).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
--
Cheers,
McTim
"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there." Jon Postel
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a> ).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a> ).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a> ).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
--
_______________________________________________________
Jason Schiller|NetOps| <a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a> |<a href="tel:571-266-0006" value="+15712660006" target="_blank">571-266-0006</a>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
</pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</pre>
</blockquote>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>