Eliminate the requirement for applicants to return the addresses they have been assigned by their providers once they receive a direct assignment - N/D

General information

Español
28/10/2019
Abandoned
0 %.

Edmundo Cazarez-Lopez - Version [1]
In discussion
28/10/2019 - 20/08/2020
First consensus
20/08/2020 - 03/09/2020
Abandoned
21/09/2020

Public comments by LACNIC staff for this version

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------

Applicability
-------------
This proposal would apply in the case of initial IPv4 allocations to ISPs and end users.

Modifications to the current text
--------------------------------
The proposal seeks to modify the following sections of the Policy Manual: 2.3.3.1.1, 2.3.3.1.2 and 2.3.3.4.3, eliminating the following text:
“- If a block has already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over[1] (changing the resource holder in LACNIC’s whois database) provided that both parties agree.

- If additional address space has been justified and its distribution is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and therefore proceed to renumber their network. Should they choose to renumber, the block that had previously been assigned must be returned within 12 months. Exceptionally, this period may be extended by an additional 6 months if it can be justified that there was not enough time to obtain the required resources and complete the renumbering process.

LACNIC Staff's Comments:
--------------------------
(Comments are observations intended to help distinguish the changes presented in the proposal from the current text of the Policy Manual.)

1. The proposal eliminates the requirement for an ISP or end user to return the IPv4 block assigned by their provider when they receive a block assigned directly by LACNIC.

Impact of the policy on the registry system
--------------------------------------------
This proposal would not require any changes to LACNIC's registry system.

Oficial sources
---------------
Contexto in other RIRs

AFRINIC, APNIC, ARIN and RIPE
There is no requirement for applicants to return the addresses they have been assigned by their providers once they receive a direct assignment.

APNIC
The policies in force in the APNIC region require justifying the need at the time of requesting the resources. However, once the space has been delegated, there are no policies specifying how the resources should be used in their own networks.

ARIN
The requirement to renumber existed but has now been eliminated.

RIPE
The general position of the RIPE Community is that the registry should not be involved in decisions on how to operate a network.


Summary

This proposal seeks to eliminate the requirement for applicants to return the resources they have already been assigned by their providers once they obtain a direct assignment, as the work involved in fulfilling the requirement requires interrupting the operation of their networks and their services to their customers, even more so when the number of addresses directly assigned is smaller than the number of addresses they are already using and must return to their providers.

Rationale (Describe the problem you intend to solve)

There are documented cases of applicants for whom this requirement does not make sense, given the amount of work involved in re-creating their networks with the new numbering and the number of addresses they are currently using. In certain cases, the number of addresses an applicant is already using is greater than the maximum allowed assignment, which is a /22. This requirement often leads applicants to desist and abandon their application.

Current text

2.3.3.1.1. - Requirements for a /24 to /22 prefix

In order to qualify for the allocation of a /24 to a /22 prefix, the requesting ISP must satisfy the following requirements:

1. Prove utilization or immediate necessity of at least 25% of the requested prefix.

2. Submit a detailed one-year utilization plan for at least 50% of the requested prefix.

- If a block has already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over[1] (changing the resource holder in LACNIC’s whois database) provided that both parties agree.

If additional address space has been justified and its distribution is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and therefore proceed to renumber their network. Should they choose to renumber, the block that had previously been assigned must be returned within 12 months. Exceptionally, this period may be extended by an additional 6 months if it can be justified that there was not enough time to obtain the required resources and complete the renumbering process.

If the applicant does not already have an IPv6 block assigned by LACNIC, simultaneously request an IPv6 block in accordance with the applicable policy.

2.3.3.1.2. - Requirements for a /21 or shorter prefix (block of 8 /24s or more)

Should the requesting ISP require an initial IPv4 address allocation of a /21 prefix or larger space, the following requirements must be satisfied:

- Provide information on assignments with prefixes equal to or shorter than /29 (more than 8 IPv4 addresses) on LACNIC's WHOIS database.

- Provide documentation that justifies the initial address space allocation. (Completion of the IPv4 address application template for ISPs). This must include detailed information showing how this resource will be used within a period of three, six and twelve months.

- If a block has already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over[2] (changing the resource holder in LACNIC’s whois database) provided that both parties agree.

If additional address space has been justified and its allocation is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and therefore proceed to renumber their network. Should they choose to renumber, the block that had previously been assigned must be returned within 12 months. Exceptionally, this period may be extended by an additional 6 months if it can be justified that there was not enough time to obtain the required resources and complete the renumbering process.

If the applicant does not already have an IPv6 block assigned by LACNIC, simultaneously request an IPv6 block in accordance with the applicable policy.

...

2.3.3.4.3 - Assignment size and procedure

The applicant must justify that the assigned space will be announced from the applicant’s own autonomous system to at least one other autonomous system.

The minimum size of an IPv4 assignment to an end user is a /24; the maximum size is a /20, which must be justified according to the utilization rate (section 2.3.3.4.2).

If a block has already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be transferred (making the corresponding changes in the whois database) provided that both parties agree on such transfer. If additional address space has been justified and its assignment is possible, the recipient may decide whether they prefer to receive the block that is handed over plus an additional block to complete the total required space, or whether they prefer to receive a single block for the total space and therefore proceed to renumber. Should they choose to renumber, the block that had previously been assigned must be returned within 6 months. Exceptionally, this period may be extended by an additional 6 months if it can be justified that there was not enough time to obtain the required resources and complete the renumbering process.

Additional assignments shall follow the policies set forth in Section 2.3.4 applicable to end users.

New text
Analyze diff

(Modifications to sections 2.3.3.1.1, 2.3.3.1.2 and 2.3.3.4.3)

2.3.3.1.1. - Requirements for a /24 to /22 prefix

In order to qualify for the allocation of a /24 to a /22 prefix, the requesting ISP must satisfy the following requirements:

1. Prove utilization of, or immediate need for, at least 25% of the requested prefix.

2. Submit a detailed one-year utilization plan for at least 50% of the requested prefix.

If the applicant does not already have an IPv6 block assigned by LACNIC, they must simultaneously request an IPv6 block in accordance with the applicable policy in force.

2.3.3.1.2. - Requirements for a /21 or shorter prefix (block of 8 /24s or more)

Should the requesting ISP require an initial IPv4 address allocation of a /21 prefix or larger space, the following requirements must be satisfied:

- Provide information on assignments with prefixes equal to or shorter than /29 (more than eight IPv4 addresses) on LACNIC's WHOIS database.

- Provide documentation that justifies the initial address space allocation. (Complete the IPv4 address application template for ISPs). This must include detailed information showing how this resource will be used within a period of three, six and twelve months.

If the applicant does not already have an IPv6 block assigned by LACNIC, they must simultaneously request an IPv6 block in accordance with the applicable policy in force.

...

2.3.3.4.3 - Assignment size

The applicant must justify that the assigned space will be announced from the applicant’s own autonomous system to at least one other autonomous system.

The minimum size of an IPv4 assignment to an end user is a /24; the maximum size is a /20, which must be justified based on utilization rate (section 2.3.3.4.2).

Additional assignments shall follow the policies set forth in Section 2.3.4 for end users.

Additional information

-

Timetable

Immediate implementation once the proposal reaches consensus and is ratified by the Board.

References

-

Presented at:

LACNIC 33 y 1/3 (20/08/2020)

--> --> --> --> --> -->