Yes, I would like to see a new draft in this area, just from personal
experience..
We currently use three Class C's from upstream providers, about 70%
used, and we would like a /22 simply for the flexibility to move between
providers, but the rules want us to be multi-homed for that.
And we can easily story board a use case for a /20 based on our
'growth', but we don't REALLY need it.. WANT to have, Good to have..
allows us to expand in the future..
But understanding the IPv4 shortage, we could easily do with the /22 for
now, and add later if need be.
Smaller ranges do allow for more mobility between upstream providers,
changing IP(s) in this day and age has lots of hidden costs in
reputation etc..
On 14-03-27 06:54 AM, CJ Aronson wrote:
I have been having a discussion with a member of the community about the
initial allocations to ISPs, NRPM section 4.2. I thought quite a bit
about this last night and I would love your input. It seems to me that
we might want to revamp this in light of IPv4 run out. Does it make
sense when the ARIN free pool is exhausted? I am sure some think that
it does/doesn't make sense now but since we're so close to run out let's
look at whether it still makes sense when the ARIN free pool is exhausted.
Thanks for your input! If anyone wants to work with me to draft a new
version please let me know.
Thanks!
-----Cathy
Here is the text from the NRPM
https://www.arin.net/policy/nrpm.html#four2
4.2. Allocations to ISPs (Requirements for Requesting Initial
Address Space)
4.2.1. Principles
4.2.1.1. Purpose
ARIN allocates blocks of IP addresses to ISPs for the purpose of
reassigning that space to their customers.
4.2.1.2. Annual Renewal
An annual fee for registered space is due by the anniversary date of the
ISP's first allocation from ARIN. ISPs should take care to ensure that
their annual renewal payment is made by their anniversary due date in
accordance with the Registration Services Agreement. If not paid by the
anniversary date, the address space may be revoked. Please review the
Annual Renewal/Maintenance Fees Page for more details.
4.2.1.3. Utilization rate
Utilization rate of address space is a key factor, among others, in
determining address allocation.
4.2.1.4. Slow start
Because the number of available IP addresses on the Internet is limited,
many factors must be considered in the determination of address space
allocations. Therefore, IP address space is allocated to ISPs using a
slow-start model. Allocations are based on justified need, not solely on
a predicted customer base.
4.2.1.5. Minimum allocation
In general, ARIN allocates /20 and larger IP address prefixes to ISPs.
If allocations smaller than /20 are needed, ISPs should request address
space from their upstream provider. For multihomed ISPs, ARIN allocates
/22 and larger IP address prefixes. If allocations smaller than /22 are
needed, multihomed ISPs should request address space from their upstream
provider.
4.2.1.6. Immediate need
If an ISP has an immediate need for address space, and can provide
justification to show that the address space will be utilized within 30
days of the request, ARIN may issue a block of address space, not larger
than a /16 nor smaller than ARIN's customary minimum allocation, to that
organization. These cases are exceptional.
4.2.2. Initial allocation to ISPs
4.2.2.1. Standard or non-multihomed
Organizations that do not meet the requirements described in the
multihomed section below (Section 4.2.2.2) must satisfy the following
requirements:
4.2.2.1.1. Use of /20
The efficient utilization of an entire previously allocated /20 from
their upstream ISP. This /20 allocation may have been provided by an
ISP's upstream provider(s), and does not have to be contiguous address
space. The organization must meet the requirement of efficient use of 16
/24s. For example, if an organization holds a smaller allocation, such
as 12 /24s, from its upstream provider, the organization would not meet
the minimum utilization requirements of a /20.
4.2.2.1.2. Efficient utilization
Demonstrate efficient use of IP address space allocations by providing
appropriate documentation, including assignment histories, showing their
efficient use. ISPs must provide reassignment information on the entire
previously allocated block(s) via SWIP or RWhois server for /29 or
larger blocks. For blocks smaller than /29 and for internal space, ISPs
should provide utilization data either via SWIP or RWhois server or by
providing detailed utilization information.
4.2.2.1.3. Three months
Provide detailed information showing specifically how a /20 will be
utilized within three months.
4.2.2.1.4. Renumber and return
ISPs receiving a new /20 may wish to renumber out of their previously
allocated space. In this case, an ISP must use the new /20 to renumber
out of that previously allocated block of address space and must return
the space to its upstream provider.
4.2.2.2. Multihomed
When prefixes are allocated which are smaller than /20, they will be
from a block reserved for that purpose. In order to receive an initial
allocation from ARIN, organizations applying under the multihomed policy
must:
* When requesting a /22, demonstrate the efficient utilization of a
minimum contiguous or noncontiguous /23 (two /24s) from an upstream.
* When requesting a /21, demonstrate the efficient utilization of a
minimum contiguous or noncontiguous /22 (four /24s) from an upstream.
* When requesting a /20, demonstrate the efficient utilization of a
minimum contiguous or noncontiguous /21 (eight /24s) from an upstream.
4.2.2.2.1. Efficient utilization
Provide reassignment information for /29 and larger blocks using the
Shared Whois Project (SWIP) or by providing the same information fields
in an RWhois server. If additional address space is later requested,
this information must be available at the time of the request.
Utilization for blocks smaller than /29 can be documented via SWIP or
RWhois server or by providing detailed utilization information.
4.2.2.2.2. Three months
Provide information showing that the requested IP address space will be
utilized within three months and demonstrating an intent to announce the
requested space in a multihomed fashion.
4.2.2.2.3. Renumber and return
Agree that the newly requested IP address space will be used to renumber
out of the current addresses which will be returned to their upstream
provider(s).
4.2.2.2.4. Additional requests following the initial allocation
To receive additional address space following the initial allocation,
multihomed organizations must have returned the original IP address
space to its provider in its entirety and must provide justification for
a new allocation as described above in the section titled Requirements
for Requesting Initial Address Space.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
