Modify the minimum size of IPv4 assignments to Internet Service Providers - N/D

General information

Español
03/04/2017
Abandoned
0 %.

Edmundo Cazarez-Lopez - Version [1]
In discussion
25/04/2017
Abandoned
10/05/2017

Public comments by LACNIC staff for this version

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Applicability of Section 2.3.3.1.1:
--------------------------------
This section will apply when an ISP requests a /22, a /23, or a /24.

Modifications to the current text and comments by LACNIC staff:
----------------------------------------------------------------
According to the modifications included in policy proposal 2017-3, the Policy Manual would undergo changes in the sections listed below.

• Section 2.3.3.1.2, Requirements for a /21 or shorter prefix (block of 8 /24s or more), would be eliminated.
• Section 2.3.3.1.1, Requirements for a /22 prefix (block of 4/24s), would be renumbered as 2.3.3.1.2.
• New text would be added to Section 2.3.3.1.1, Requirements for a /24 or /23 IPv4 address prefix.

2.3.3.1. Initial allocation to ISPs
The minimum initial allocation size applicable to Internet Service Providers established within LACNIC's service region is a /24. Because the region has now entered the IPv4 Address Exhaustion Phases, the maximum allocation size is a /22 (4 /24s), as noted in Section 11 of the Policy Manual.

2.3.3.1.1 Requirements for a /24 or /23 IPv4 address prefix.
When planning their request, an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption, as they will only receive a one-time assignment and no additional IPv4 space assignments will be allowed.
If the applicant does not already have an IPv6 block assigned by LACNIC, they must simultaneously request an IPv6 block in accordance with the policy in force.

For the assignment of a /24
- Prove utilization or current need for between a /26 and a /25 (64 to 128 IPv4 addresses).
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the assigned space.

For the assignment of a /23
- Prove utilization or current need for between a /25 and a /24 (128 to 256 IPv4 addresses).
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the assigned space.

2.3.3.1.2. Requirements for a /22 prefix (block of 4/24s)
When planning their request, an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption, as they will only receive a one-time assignment and no additional IPv4 space assignments will be allowed.
If the applicant does not already have an IPv6 block assigned by LACNIC, they must simultaneously request an IPv6 block in accordance with the policy in force.

In order to qualify for the allocation of a /22 prefix, the requesting ISP must satisfy the following requirements:
- Prove utilization or immediate need for at least a /24.
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the /22.

LACNIC Staff Comments:
• Section 2.3.3.1.2 currently applies to the transfer of blocks smaller than or equal to a /21. If this section is deleted, there will be no defined procedure for analyzing the justification of this block size.
• The new text calls for a detailed one-year address utilization plan, yet it does not specify how much (what percentage) such plan would need to justify. The Manual currently requires justifying a /23 out of the requested /22.
• How would an organization prove to LACNIC that “part of the assigned IPv4 addresses should be used to support IPv6 adoption”?
• Adding the note in Section 2.3.4 (“This section of the Policy Manual is no longer valid, as the LACNIC region has entered IPv4 Address Exhaustion and it is no longer possible to make additional assignments from this space”) would invalidate this provision, which currently applies to transfers where the receiving organization already holds resources assigned by LACNIC.
• According to the proposal, “an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption.” On the other hand, an organization may already have IPv6 addresses and request only IPv4 addresses from LACNIC because they have never been assigned IPv4 resources before.
• This proposal does not consider requests for 3 /24s.

Implementation of the Proposal
-------------------------------
The proposal can be implemented immediately.

Impact of the policy on the registry system and the addressing pool
--------------------------------------------------------------------
This proposal does not involve any modifications to the registry system.


Summary

This proposal seeks to modify the minimum size of IPv4 address assignments to ISPs from the current /22 to a /24.

Rationale (Describe the problem you intend to solve)

With the exhaustion of the region's available IPv4 address space, some new ISPs are faced with the problem of being unable to meet the minimum address utilization requirements for obtaining a /22 assignment from LACNIC, coupled with the fact that their providers no longer have available addresses to meet their needs.

The proposal suggests changing the minimum assignment size from a /22 to a /24 so that it will be easier for operators currently using very few addresses to meet the requirements for receiving an IPv4 assignment.

It also considers the fact that only one assignment will be allowed, as the region is now in IPv4 Address Exhaustion Phase 3.

Current text

== Modify the text in section 2.3.3.1

Current text:
-------------------
The minimum initial allocation size applicable to Internet Service Providers established within LACNIC's service region is a /22.
-------------------

New text:
-------------------
The minimum initial allocation size applicable to Internet Service Providers established within LACNIC's service region is a /24. Because the region has now entered the IPv4 Address Exhaustion Phases, the maximum allocation size is a /22 (4 /24s), as noted in Section 11 of the Policy Manual.
-------------------

== Modify the text of section 2.3.3.1.1 as follows:

Current text:
-------------------
2.3.3.1.1. Requirements for a /22 prefix (block of 4/24s)

In order to qualify for the allocation of a /22 prefix, the requesting ISP must satisfy the following requirements:
- Prove utilization or immediate necessity of a /24.
- Submit a detailed one-year utilization plan for a /23.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the /22.
- If the applicant does not already have an IPv6 block assigned by LACNIC, simultaneously request an IPv6 block in accordance with the applicable policy.
-------------------

New text:
-------------------
2.3.3.1.1. Requirements for a /22 prefix (block of 4/24s)

When planning their request, an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption, as they will only receive a one-time assignment and no additional IPv4 space assignments will be allowed.

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

- In order to qualify for the allocation of a /22 prefix, the requesting ISP must satisfy the following requirements:
- Prove utilization or immediate need of at least a /24.
- Submit a detailed one-year address utilization.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the /22.
-------------------

== Eliminate section 2.3.3.1.2.

== Renumber section 2.3.3.1.1 as 2.3.3.1.2.

== Create a new section 2.3.3.1.1 with the following text:

New text:
-------------------
2.3.3.1.1 Requirements for a /24 or /23 IPv4 address prefix

When planning their request, an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption, as they will only receive a one-time assignment and no additional IPv4 space assignments will be allowed.

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

For the assignment of a /24:
- Prove utilization or current need of between a /26 and a /25 (64 to 128 IPv4 addresses).
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the assigned space.

For the assignment of a /23:
- Prove utilization or current need of between a /25 and a /24 (128 to 256 IPv4 addresses).
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the assigned space.
-------------------

== Add the following note under section 2.3.4 - Policies for the Distribution of Additional IPv4 Address Space

New text:
-------------------
NOTE: This section of the Policy Manual is no longer valid, as the LACNIC region has entered IPv4 Address Exhaustion and it is no longer possible to make additional assignments from this space.

New text
Analyze diff

== Modify the text in section 2.3.3.1

Current text:
-------------------
The minimum initial allocation size applicable to Internet Service Providers established within LACNIC's service region is a /22.
-------------------

New text:
-------------------
The minimum initial allocation size applicable to Internet Service Providers established within LACNIC's service region is a /24. Because the region has now entered the IPv4 Address Exhaustion Phases, the maximum allocation size is a /22 (4 /24s), as noted in Section 11 of the Policy Manual.
-------------------

== Modify the text of section 2.3.3.1.1 as follows:

Current text:
-------------------
2.3.3.1.1. Requirements for a /22 prefix (block of 4/24s)

In order to qualify for the allocation of a /22 prefix, the requesting ISP must satisfy the following requirements:
- Prove utilization or immediate necessity of a /24.
- Submit a detailed one-year utilization plan for a /23.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the /22.
- If the applicant does not already have an IPv6 block assigned by LACNIC, simultaneously request an IPv6 block in accordance with the applicable policy.
-------------------

New text:
-------------------
2.3.3.1.1. Requirements for a /22 prefix (block of 4/24s)

When planning their request, an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption, as they will only receive a one-time assignment and no additional IPv4 space assignments will be allowed.

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

- In order to qualify for the allocation of a /22 prefix, the requesting ISP must satisfy the following requirements:
- Prove utilization or immediate need of at least a /24.
- Submit a detailed one-year address utilization.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the /22.
-------------------

== Eliminate section 2.3.3.1.2.

== Renumber section 2.3.3.1.1 as 2.3.3.1.2.

== Create a new section 2.3.3.1.1 with the following text:

New text:
-------------------
2.3.3.1.1 Requirements for a /24 or /23 IPv4 address prefix

When planning their request, an organization must consider that part of the assigned IPv4 addresses should be used to support IPv6 adoption, as they will only receive a one-time assignment and no additional IPv4 space assignments will be allowed.

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

For the assignment of a /24:
- Prove utilization or current need of between a /26 and a /25 (64 to 128 IPv4 addresses).
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the assigned space.

For the assignment of a /23:
- Prove utilization or current need of between a /25 and a /24 (128 to 256 IPv4 addresses).
- Submit a detailed one-year address utilization plan.
- Agree to renumber out of the previously assigned block and return those IPv4 addresses to their ISPs no later than 12 months after the allocation of the assigned space.
-------------------

== Add the following note under section 2.3.4 - Policies for the Distribution of Additional IPv4 Address Space

New text:
-------------------
NOTE: This section of the Policy Manual is no longer valid, as the LACNIC region has entered IPv4 Address Exhaustion and it is no longer possible to make additional assignments from this space.

Additional information

Requests from organizations that have sub-assigned IPv4 address space but do not meet the utilization requirements for obtaining a /22 are becoming increasingly common. The growing use of IPv4 and IPv4 exhaustion make it very unlikely that such organizations will be able to obtain further addresses from their providers.

Timetable

Immediate implementation once the proposal reaches consensus and is ratified by the Board, subject to any modifications which LACNIC or NIR staff need to implement in their analysis process.

References

LACNIC Policy Manual, sections 4 and 11.

Presented at:

-

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