IPv4 Evaluation Procedures
This document describes the RIPE NCC's procedures and criteria for the evaluation of IPv4 resource requests. The aim is to inform LIRs about what is expected from them during an evaluation and what kind of information the IP Resource Analyst (IPRA) needs. This document covers the most common types of resource requests.
The RIPE NCC is now allocating IPv4 address space from the last /8. This means that section 5.6 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is now in effect. RIPE NCC members can request a one time /22 allocation if they can justify the need for it and already have an IPv6 allocation. No new PI space can be assigned.
Resource requests can be submitted by email or through the LIR Portal.
Through the LIR Portal:
Requests sent through the LIR Portal always have the correct syntax and are sent to the request queue regardless of LIR contact status.
An RIPE NCC IP Resource Analyst (IPRA) can only evaluate email requests that are sent from the email address of one of the LIR’s registered contact persons and are free of syntax errors. Please be sure that an email request meets these criteria to avoid delays.
If the request is sent from an email address that is not a registered contact for the LIR, then the IPRA will wait for authorisation from a registered contact person before they proceed.
LIRs can update the list of registered contact persons in the LIR Portal.
Please be sure to read the confirmation email that you receive when you submit a request.
If an LIR does not respond to a request within three months, the request is closed. Resource requests that are closed for this reason cannot be re-opened and have to be submitted again.
Address space assignments are made to a single End User's infrastructure (network) only. It is not allowed to make sub-assignments from any type of address space. Organisations who (sub-)assign address space to others operate a registry and are therefore required to become a RIPE NCC member (LIR) or obtain a sub-allocation from an existing LIR.
New LIRs need to submit both a First Allocation request and at least one PA Assignment request at the same time, but with separate tickets.
The RIPE NCC has started to allocate IPv4 address space from the last /8. This means that section 5.6 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is now in effect. RIPE NCC members can request a one time /22 allocation if they can justify the need for it and already have an IPv6 allocation
Typical types of information that the IPRA will look for during the evaluation of a First Allocation request are:
The address space that the LIR is currently using. Include any space that will be renumbered and returned. The Address Policy offers a three months renumbering period as a guideline.
LIR’s business or services offered (DSL provider, web hosting, academic institution, etc).
Type of customers (web hosting, co-location, cable/DSL, leased line, etc).
Future plans (new services, expansion of existing services, etc).
A First Allocation request must be accompanied by at least one PA Assignment Approval request. If there is no assignment to make to a customer or any infrastructure then there is no need for an allocation. Usually this first PA Assignment request is for the LIR's own infrastructure, but it might also be for a customer.
Since assignments are registered in the name of the End User, it is important not to combine assignments for a customer with assignments for the LIR’s infrastructure. Send one request for LIR infrastructure and one request each per customer, unless they fall under the "connectivity" clause described below. If a new LIR has more than five PA Assignment requests to send right away, please inform the RIPE NCC of this in the First PA Allocation request form before sending all PA Assignment requests.
The Assignment Window (AW) allows an LIR to make small assignments without sending a PA Assignment request first. Normally, an LIR in good standing receives its AW after six months.
When using the AW, please note that one assignment can be multiple inetnum objects in the RIPE Database. For instance, when an assignment of a /20 needs to be made and the AW is a /22, simply registering the /20 as four /22s in the RIPE Database does not make a valid assignment. The total is a /20 which is larger than the /22 AW, so a PA Assignment request has to be sent.
If the LIR has an AW and has made assignments using it, the IPRA will ask for information about some of these requests. The information being asked for corresponds to the End User Information, the Addressing Plan and Network Description sections in the PA Assignment request form.
An LIR may be eligible to receive a one-time IPv4 /22 allocation from the last /8 when the overall usage of their existing allocations reaches 80%. An LIR will still have to demonstrate a need to make assignments in the near future. An LIR may also be eligible if a single assignment or sub-allocation requires a larger set of addresses than can be satisfied with the address space currently held by the LIR. The IPRA will conduct a small audit on the LIR’s records during the evaluation of an Additional Allocation request. The LIR must fix 1] in the RIPE Database before a new address block can be allocated.[
All resource allocations made by the RIPE NCC are based on the principle of justified need. The IPRA will verify that there is a need for resources before allocating the new block by looking at data such as:
Past allocation and assignment history of the LIR
Realistic future plans, these can be supported by:
Rental contracts for, (e.g. co-location space)
Signed agreements with customers
The RIPE NCC may verify any documentation that is submitted.
Experience has shown that the real address usage often does not follow business and/or marketing plans. Therefore, additional documentation that shows the technical need may be requested.
LIRs who have significant parts of their allocation assigned to any kind for broadband, VOIP, VPN or other such services, may be asked to provide historic usage data of their address pools during the evaluation of their additional allocation request.
LIRs make a variety of PA assignments, making it impossible to give a complete overview. The general and most common cases will be discussed below.
LIRs operate many different types of infrastructures. All IP addresses used must be registered as ASSIGNED PA in the RIPE Database. The RIPE NCC recommends that an LIR use a single netname per service, possibly with the exception of "connectivity" assignments.
"Connectivity" is defined as any kind of service where customers get their address assigned from a central address pool and the addresses are only used to connect the customers to the ISP's infrastructure. These addresses may be registered for use in the LIR’s Infrastructure, instead of in the name of the End User, provided that the address(es) is/are strictly used to connect the user to the LIR’s infrastructure.
LIRs are required to keep detailed history of the usage of their address pools when more than a /20 (4,096 addresses) are used for such services. "Usage" in this context is defined as "the number of customers who are online".
Types of services that fall under this section are:
- Cable Internet
- Triple Play
In some cases, VPN Services and (Virtual) Server Hosting can also fall under this rule, for example when no subnets are assigned to the End User and the addresses for all End Users are assigned from a single pool.
If you are uncertain if you need to set up monitoring of your address pools or how to register them in the RIPE Database, please contact lir-help _at_ ripe _dot_ net for more information.
The RIPE NCC will look for a minimum usage of 70% when approving a new assignment for these services. The IPv4 Address Policy requires the RIPE NCC to check that an address pool is used efficiently before we can approve another assignment for it. Experience has shown that 70% utilisation is a level that is attainable for nearly all ISPs while still ensuring good efficiency.
When the request is for public IP address space for a service that was previously behind NAT, the RIPE NCC may ask for dumps of ARP or NAT tables as well.
Information that should be included with the request:
IP ranges used for the existing address pools
Number of users using the service
The address-to-user ratio
Relevant technical details about the service, such as the type of technology used to connect the users
Address pool usage verification data, see IPv4 Verification.
This information is required for both static and dynamic address pools.
When making assignments to customers that don't fall under the “connectivity” rules, the assignment must be registered separately and in the name of that customer. If the assignment can be made using the LIR's Assignment Window, a request does not have to be sent to the RIPE NCC.
Requests should include:
End User’s full legal name and their website (if applicable)
Size and purpose of each and every subnet that will be deployed
General description of the network and the its services
Description of the equipment that will use the requested IP addresses
List of the address space that this End User has already deployed
If the customer is a reseller and isn’t making assignments to its customers, these must be registered in the name of the actual End User, such as the customer's customer.
Direct assignments are resources that are assigned directly by the RIPE NCC to an End User, such as ASSIGNED PI, ASSIGNED ANYCAST, IXP assignments and AS Numbers.
Since reaching the last /8, the RIPE NCC only makes direct IPv4 assignments to Internet Exchange Points (IXPs) as described in section 5.6 of the IPv4 Address Policy.
Existing direct assignments must still fall under a valid End User contract with a Sponsoring LIR.
Most direct assignment requests are for customers of LIRs. End User documentation is required in this case:
- End User Contract
- End User Registration Papers
If the End User is a natural person, we have to be sure of their identity before we conclude an agreement with them. Proof of identification could be:Valid ID
- Valid passport
- Valid driving license, recent electricity bill, etc. in case of countries with no official identification documents (e.g., UK)
If the End User is a legal person, proof of registration with the national authorities must be submitted with the request. Normally this takes the form of company registration documents.
The RIPE NCC reserves the right to control the validity of this documentation by requesting support or information from third parties.
Include the following information in the request:
- End User documentation: company registration documents (or equivalent) and the End User contract
- Full legal name and website of the End User
- A description of how the resources will be used
- The Database template should contain:
- Organisation object for the End User
- End User’s contact information, such as admin-c, valid maintainer (End User or LIR), full legal name in “descr:” attribute.
LIRs sometimes request direct resources as well, for a variety of reasons.
The End User contract and company registration papers are not required in this case because LIRs already have a contract with the RIPE NCC.
 Overlapping assignments
Overlapping assignments are ranges with the status ASSIGNED PA that overlap with each other. For example:
inetnum: 192.0.2.0 - 192.0.2.255
inetnum: 192.0.2.0 - 192.0.2.128
These two inetnum objects overlap. Overlaps are fixed by removing one of the overlapping objects.
An invalid assignment is an assignment that was made and registered in the RIPE Database for which there is no corresponding PA Approval record and is outside the LIR's Assignment Window (AW). These are often caused because:
The RIPE NCC hasn’t approved the assignment
An approved netname has been changed without informing the RIPE NCC
The inetnum object has been entered in the RIPE Database before the assignment has been approved, or the date at the changed line is prior to the approval date.
A netname has been assigned using your AW but the assignment is larger than your approved AW size.