[arin-ppml] Initial IPv4 allocations to ISPs, NRPM section 4.2
Michael Peddemors
michael at linuxmagic.com
Thu Mar 27 11:08:41 EDT 2014
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 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.
>
--
"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.
More information about the ARIN-PPML
mailing list