IPv4 Evaluation Procedures

Contents

Introduction

Submitting Resource Requests

Closing Requests

Slow-start Mechanism

Sub-assignments

New LIRS

First Allocation

First PA Request(s)

Additional Allocation

Assignment Window

PA Assignment Approval Request

LIR Infrastructure

Connectivity

Customer Assignments

PI Space

For LIR’s Customers

For LIRs

Sub-assignments

Routing Reasons

Introduction

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) is looking for. This document covers the most common types of resource requests.

Submitting Resource Requests

Resource requests must be submitted by email or through the LIR Portal.

By email:
An IPRA will only evaluate email requests that are sent by an LIR’s registered contact person and free of syntax errors. Please be sure that an email request meets these criteria to avoid delays.

If the request is sent by someone that is not a registered contact person for the LIR, then the IPRA will wait for authorisation from a registered contact person before they proceed.

LIRs can updated their registered contact persons in the LIR Portal.

Please be sure to read the confirmation email that you receive when you submit a request.

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.

Closing requests

If an LIR does not respond to a request for three months for any reason, the request is closed. Resource requests that are closed for this reason cannot be re-opened and have to be submitted again.

Slow-start mechanism

According to RIPE IPv4 Address Policy, any IPv4 address space request must follow the “slow-start mechanism.” This means that if an End User with no verifiable history of address usage growth requests a large amount of addresses for future growth, the RIPE NCC has the mandate to assign a smaller allocation than originally requested.

Sub-assignments

Address space assignments (as opposed to allocations) are to a single End User's infrastructure 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 an LIR or obtain a sub-allocation from an existing LIR.

New LIRs

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.

As the new LIR does not have any history of IP address usage yet, the IPRA will be asking questions about their current infrastructure, plans for the future, the types of services offered, etc.

The new LIR may initially receive less address space than it requests, according to the slow-start mechanism described above.

In summary, a new LIR should send:

• First Allocation request

• At least one PA Assignment request, note that it is not possible to use the LIR Portal's PA Wizard at this stage. The normal PA Assignment Request form in the LIR Portal can be used however.

First 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).

First PA Requests(s)

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.

Assignment Window

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.

Additional Allocation

An LIR may be eligible to receive an additional allocation when the overall usage of their existing allocations reaches 80%. The 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 do a small audit on the LIR’s records during the evaluation of an Additional Allocation request. The LIR must fix invalid or overlapping registrations[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:

  • Equipment invoices

  • Rental contracts for, (e.g. co-location space)

  • Signed agreements with customers

The RIPE NCC may verify any documentation submitted independently.

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.

The RIPE NCC will allocate one or two prefixes, depending on the size that is justified.

1. If one prefix is justified, one prefix will be allocated;

2. Otherwise, the allocation size will be rounded up to the nearest set of two prefixes;

3. If the smaller prefix is half that of the first prefix, the whole will be rounded up and a single, the next largest, prefix will be allocated;

4. Otherwise, the two prefixes will be allocated.

Examples:

The period for which the RIPE NCC will allocate and assign IPv4 address space will progressively get shorter:

As of 1 January 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to six months.

As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three months.

It is possible that an LIR still has over 80% usage after receiving an additional allocation. However, there still has to be a justified need before qualifying for an additional allocation.

PA Assignment Approval 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.

LIR Infrastructure

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 for all of its assignments, possibly with the exception of "connectivity" assignments.

Connectivity

"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:

- xDSL

- Cable Internet

- GSM/GPRS/UMTS/etc

- WiMax

- VOIP

- 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.

Customer Assignments

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.

PI Space

For the LIR’s customer(s)

Most PI requests are for customers of LIRs. End User documentation is required in this case:

• End User Contract

• End User Registration Papers

Natural persons

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 not official identification documents (e.g. UK)

Legal persons

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

• Size and purpose of each and every subnet that will be deployed

• General description of the network and 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

• 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.

For the LIRs

LIRs sometimes need PI space as well, for a variety of reasons. If an LIR decides to request PI space, the reason why PA space cannot be used must be explained in the request.

The End User Contract and company registration papers are not required in this case, as LIRs already have a contract with the RIPE NCC.

Sub-assignments

It is not allowed to make sub-assignments from PI address space. PI address space is assigned to an End User's infrastructure only. Organisations who (sub)assign address space to others operate a Registry and are therefore required to become an LIR.

In the IPv4 Address Policy there is one exception to this rule:

"Addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure".

This means that only the addresses used to connect a customer to the ISP can be counted as the ISP's infrastructure. Any other IP addresses in use by the customer are considered a sub-assignment and are therefore not allowed from PI space.

Routing Reasons

“The IPv4 Address Policy does not permit the assignment of extra addresses for "routing reasons". This means that the RIPE NCC will assign as many addresses as are justified based on the actual need and not more. This may affect the routability of the assignment in case it is smaller than a /24.

[1] 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.