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

Original Language Español Date Published 29/10/2019 Last Modified 28/10/2019
Last Call for Comments Period Does not apply Date Ratified Does not apply Implementation Date Does not apply
Status Under discussion Download TXT PDF XML DOCX
See other versions 1.0 (compare)

Authors

Name: Edmundo Cazarez-Lopez
Email: edmundo.cazarez@nic.mx
Organization: NIC Mexico

Proposal Data

Policy Type: LACNIC
Id: LAC-2019-10
Last version: 1

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

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.

Text

Modifications to sections 2.3.3.1.1, 2.3.3.1.2 and 2.3.3.4.3.:

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

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

-

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2019-10 - versión 1

Interpretación de la propuesta por el staff de LACNIC
----------------------------------------------------

Aplicación de la propuesta
--------------------------
Esta propuesta se aplicaría a los casos de distribución inicial IPv4 a ISPs y a usuarios finales.

Modificación del texto actual
---------------------------
Se modifican las secciones del manual de políticas: 2.3.3.1.1, 2.3.3.1.2 y 2.3.3.4.3, donde se elimina el texto:
“- Si previamente había un bloque asignado por un proveedor, y se desea mantener el mismo para evitar la renumeración, y hay acuerdo entre ambas partes, se podrá ceder[1] dicho bloque (con el cambio de titularidad en el whois, a través de LACNIC).

- Si se ha justificado espacio adicional y es posible su distribución, el receptor podrá decidir si la cesión le es conveniente y recibe un bloque por el espacio adicional o prefiere un único bloque por el total y, por lo tanto, renumera. En caso de renumeración, el bloque previamente asignado deberá ser retornado en un plazo máximo de 12 meses. Excepcionalmente, este plazo podrá ser extendido en 6 meses adicionales si se justifica que no ha habido tiempo para la consecución de los recursos que precisa y la renumeración correspondiente.”

Comentarios del staff
---------------------
(Los comentarios son observaciones para ayudar a diferenciar los cambios que presenta la propuesta con respecto al texto actual del Manual de Políticas)

1. La propuesta elimina el requerimiento de devolver el bloque IPv4 perteneciente al proveedor cuando reciba un bloque asignado directamente de LACNIC, tanto para ISPs como para usuarios finales.

Impacto en el sistema de registro
----------------------------------
Esta propuesta no implicaría cambios en los sistemas de LACNIC.

Fuentes oficiales de referencias
--------------------------------
Contexto: situación en otros RIRs

- AFRINIC, APNIC, ARIN y RIPE
No tienen un requisito de devolver las direcciones que tengan asignadas por sus proveedores una vez que obtienen una asignación directa.

- APNIC
En la región APNIC, las políticas requieren justificar la necesidad al momento de solicitar los recursos. Sin embargo, una vez delegado el espacio no hay políticas que especifiquen cómo utilizan sus recursos en su propia red.

- ARIN
El requisito de renumeración existía previamente, pero se ha eliminado.

- RIPE
La posición general de la Comunidad RIPE es que el registro de recursos no debe mezclarse con las decisiones sobre cómo operar una red.

Privacy Policy