IPv4 Evaluation Procedures

Contents

Introduction

Submitting Resource Requests

Closed Requests

Sub-assignments

New LIRS

First Allocation

First PA Request(s)

PA Assignment Approval Request

LIR Infrastructure

Connectivity

Customer Assignments

Direct Assignments

IXP Assignments

Natural Persons

Legal Persons

For the LIR

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) 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, according to section 5.1 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", RIPE NCC members can request a one time /22 allocation if they are planning to use this address space and already have an IPv6 allocation. No new PI space can be assigned.

Submitting Resource Requests

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.

 

By email:

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.

 

Closed requests

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.

Sub-assignments

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

New LIRs need to submit a First Allocation request.

The RIPE NCC is now allocating IPv4 address space from the last /8. This means that, according to section 5.1 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", RIPE NCC members can request a one time /22 allocation if they are planning to use this address space and already have an IPv6 allocation. No new PI space can be assigned.

First Allocation

An IPRA may request additional information so they can complete the documentation of your First Allocation request and confirm the assignments you plan to make from the First Allocation.

The IPRA can also assist with the registration of End User networks or infrastructure assignments and can provide information about transfers of allocations if the LIR will require more IPv4 address space than a /22.

Additional Allocation

An LIR may be eligible to receive a one-time IPv4 /22 allocation from the last /8. An LIR will have to confirm that they will make assignments from that allocation. The IPRA will conduct a small audit on the LIR’s records during the evaluation of an Additional Allocation request. The LIR must fix overlapping registrations[1] in the RIPE Database before a new address block can be allocated.

PA Assignments

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 per service, 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.

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 how to register them in the RIPE Database, please contact lir-help _at_ ripe _dot_ net for more information.

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.

Direct Assignments

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 6.1 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region".

Existing direct assignments must still fall under a valid End User contract with a Sponsoring LIR.

 

IXP Assignments (Also valid for: IPv6 PI, IPv6 Anycast and AS Number assignments)

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

 

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

 

For the LIR

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.

 


 

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