IPv4 Depletion Phases

This section is intended to inform the Community about the processes and phases involved in the depletion of the IPv4 protocol in the LACNIC region, as well as the changes to existing procedures and expected response times depending on the particular stage of exhaustion we are going through.

IPv4 exhaustion refers to a new phase where assignments are made from reserve pools and are restricted both in terms of their size and their requency.  These restrictions were established by policies presented and discussed by the community at LACNIC's Public Policy Forum.

It is expected that these policies will result in better resource management that will lead to gradual IPv4 exhaustion, while continuing to allow new entrants to the industry. Thus, exhaustion means that LACNIC will no longer have enough address space to satisfy our members' IPv4 addressing needs.

The IPv4 protocol exhaustion process comprises three main stages as described below:

Current Phase

Starting now, until reaching the equivalent of the last /9.

Request Handling:

Applications are processed on a first-come, first-served basis using a ticket system. Both NIC Mexico (NIC.MX) and NIC Brazil (NIC.br) manage their tickets independently from LACNIC. Incomplete applications requiring their applicant to provide additional information are sent to the end of the ticket queue and will only be completed when the corresponding ticket is reached once again after the client provides the required information.

Evaluation Criteria:

  • Applications are processed in accordance with the provisions of Chapter 2 of the Policy Manual and assignments will be granted based on justifiable need.
  • Applications for a /15 or more are assessed jointly by the NIRs and LACNIC.
  • Requests for the equivalent of a /16 are assessed jointly by 2 hostmasters within the same organization.

Assignments:

Once a request is approved, assignments are made directly by each organization's hostmaster.

Important:

These new procedures mean that application processing times may vary significantly.

Once the equivalent of a /9 is reached, including the two /11s reserved for gradual IPv4 exhaustion and new members.

Request Handling:

Applications will be processed on a first-come, first-served basis using a ticket system. Both NIC Mexico (NIC.MX) and NIC Brazil (NIC.br) manage their tickets independently from LACNIC. Incomplete applications requiring their applicant to provide additional information are sent to the end of the ticket queue and will only be completed when the corresponding ticket is reached once again after the client provides the required information.

Once all of the requirements for approval have been met, the hostmaster will enter the application data on a web form with the following information:

  • Ticket number
  • UTC time and date on which the application was entered
  • UTC time and date on which the application was approved
  • Organization and ownerID
  • Pre-approved block

This information will be sent to a pre-approvals management system which will automatically sort them by client ticket creation date, from oldest to newest.

Based on this list, every day at 7:00 UTC, the pre-approvals system will check whether enough free address space is available to satisfy all pre-approved requests.

The following day, if there is enough space available to complete every assignment, the hostmasters will receive an email from the system specifying that they may proceed to complete all pre-approved assignments.

In the case of additional requests, the assignment will be made on the next working day after the pre-approval is granted.

In the case of initial requests or requests triggering a category change and corresponding invoice, the pre-approved block will be reserved for up to 14 days, awaiting payment of the outstanding invoice and the signing of the corresponding service agreement, if required. The assignment will be finalized once such payment and service agreement are received. If payment is not received within 14 days, the block will lose its reserved status and the client will need to submit a new request. The block will be returned to the central pool of available resources and hostmasters will be able to pre-approve it for a new assignment.

This process will be implemented every day until it is no longer possible to satisfy a customer's request. At this time, the pre-approval system will send an email to the hostmasters notifying that there is no longer enough free space available to complete all pre-approved requests and will keep a list of all pre-approved requests, sorted by UTC time. Based on this list, the LACNIC/NIRs Assignments Committee (made up by one representative of each of these organizations) will manually review the order in which the requests were received and the amount of space that was requested. Once this review is complete, the committee will inform all hostmasters which organizations are able to receive regular IPv4 space. Hostmasters will then make all corresponding assignments.

If the last request on the pre-approval queue cannot be satisfied in full, the requesting organization will be offered an amount of regular IPv4 stock that is as close as possible to the requested total. Note that the requesting organization may turn down the assignment offered by LACNIC/NIRs if the disaggregation is deemed too complex. If the requesting organization turns down the assignment, then it will only be able to receive up to a /22 from the 11.2 reserve pool once the regular pool is exhausted. The free space resulting from an assignment that is rejected by a customer who was granted pre-approval will be offered to the requesting organization next in line in the pre-approval queue.

Organizations whose requests cannot be satisfied using regular IPv4 space will receive up to a /22 from the Gradual Exhaustion reserve, thus triggering Phase 2. At the same time, the requesting organization will be informed that the space already falls under section 11.2 of the Policy Manual and, consequently, they will not be able to request additional IPv4 space for a period of 6 months.

In order to increase transparency in the handling of IPv4 resource requests, an iFrame will be added to LACNIC's website where customers will be able to view a sorted list of incoming tickets and their place on the pre-approval queue. Pre-approved requests will be sorted according to their initial reception time.

Evaluation Criteria:

  • Applications will be processed in accordance with the provisions of Chapter 2 of the Policy Manual and assignments will be granted based on justifiable need.
  • Applications for a /15 or more are assessed jointly by the NIRs and LACNIC.
  • Requests for the equivalent of a /16 are assessed jointly by 2 hostmasters within the same organization.

Assignments:

Assignments will be made directly by each organization's hostmaster the next working day after pre-approval is granted.

Important:

Please note that during Phase 1 neither LACNIC nor the NIRs will be able to guarantee that assignments will be aggregated. This means, for example, that an organization requesting a /14 may receive more than one prefix, the combined total of which is equivalent to a /14, thus satisfying the customer's request with multiple IP blocks.

When the available pool is equivalent to the last /10

This phase triggers section 11.2 of the Policy Manual, under which a /11 block is reserved for gradual exhaustion.

During this phase, only assignments from the equivalent of a /24 to a /22 will be made. Requesting organizations may request additional resources every 6 months. This process will be implemented every day until the /11 reserved for gradual exhaustion is finally exhausted.

Request Handling:

Applications are processed on a first-come, first-served basis using a ticket system. Both NIC Mexico (NIC.MX) and NIC Brazil (NIC.br) manage their tickets independently from LACNIC. Incomplete applications requiring their applicant to provide additional information are sent to the end of the ticket queue and will only be completed when the corresponding ticket is reached once again after the client provides the required information.

Once all of the requirements for approval have been met, the hostmaster will enter the application data on a web form with the following information:

  • Ticket number
  • UTC time and date on which the application was entered
  • UTC time and date on which the application was approved
  • Organization and ownerID
  • Pre-approved block

This information will be sent to a pre-approvals management system which will automatically sort them by client ticket creation date, from oldest to newest.

Based on this list, every day at 7:00 UTC, the pre-approvals system will check whether enough space is available in the pool reserved for gradual exhaustion to satisfy all pre-approved requests.

Immediately after the algorithm is processed, if enough space is available to satisfy every assignment, hostmasters will receive an email from the system specifying that they may proceed to complete all pre-approved assignments.

In the case of additional requests, the assignment will be made on the next working day after the pre-approval is granted.

In the case of initial requests or requests triggering a category change and corresponding invoice, the pre-approved block will be reserved for up to 14 days, awaiting payment of the outstanding invoice and the signing of the corresponding service agreement, if required. The assignment will be finalized once such payment and service agreement are received. If payment is not received within 14 days, the block will lose its reserved status and the client will need to submit a new request. The block will be returned to the central pool of available resources and hostmasters will be able to pre-approve it for a new assignment.

This process will be implemented every day until the /11 reserved for gradual exhaustion is finally exhausted. At this time, the pre-approval system will send an email to the hostmasters notifying that there is no longer enough free space available to complete all pre-approved requests and will keep a list of all pre-approved requests, sorted by UTC time. Based on this list, the LACNIC/NIRs Assignments Committee (made up by one representative of each of these organizations) will manually review the order in which the requests were received and the amount of space that was requested, informing all hostmasters which organizations are able to receive IPv4 resources from the pool reserved for gradual exhaustion Hostmasters will then make all corresponding assignments on the next working day.

Organizations whose initial requests cannot be satisfied from the gradual exhaustion reserve will receive a /22 from the pool reserved for New Members, thus triggering Phase 3. These organizations will be notified that the assignment was no longer completed under section 11.1 of the Policy Manual, meaning that this will be the first and last IPv4 request that LACNIC or the NIRs will be able to assign to their organization. Any additional requests opened in the ticket system will be notified that the pool reserved for gradual exhaustion has been exhausted and that LACNIC/the NIRs will not be able to make further IPv4 assignments to their organizations.

In order to increase transparency in the handling of IPv4 resource requests, an iFrame will be added to LACNIC's website where customers will be able to view a sorted list of incoming tickets and their place on the pre-approval queue. Pre-approved requests will be sorted according to their initial reception time.

Evaluation Criteria:

  • Requests will be processed according to the provisions of section 11.2 of the Policy Manual.
  • Requests must comply with the requirements set out in chapter 2 of the Policy Manual for initial or additional requests, as applicable.
  • From this point on, incoming IPv4 requests will no longer be jointly processed by LACNIC and the NIRs.
  • From this point on, requests will no longer be processed jointly by more than one hostmaster within the NIRs or LACNIC.

Assignments:

Assignments will be made directly by the hostmaster on the next working day after pre-approval is granted.

When the /11 block reserved for gradual exhaustion is finally exhausted.

This pool will be LACNIC's last available space and will consist of a /11 block and recovered IPv4 blocks. Only assignments from the equivalent of a /22 to a /24 may be made from this pool. Each new member may only receive one initial assignment from this space.

Request Handling:

Applications are processed on a first-come, first-served basis using a ticket system. Both NIC Mexico (NIC.MX) and NIC Brazil (NIC.br) manage their tickets independently from LACNIC. Incomplete applications requiring their applicant to provide additional information will be sent to the end of the ticket queue and will only be completed when the corresponding ticket is reached once again after the client provides the required information.

Evaluation Criteria:

  • Requests will be processed according to the provisions of section 11.1 of the Policy Manual.
  • Requests must comply with the requirements set out in chapter 2 of the Policy Manual for initial requests.
  • Only initial requests will be accepted.

Assignments:

Assignments will be made directly by each organization's hostmaster.

IPv4 depletion report

IPv4 allocations/assignments and available space

IPv4 Addresses Free:

/8s

Depletion date:

IPv4 Addresses Available for allocation (Reserve last /10):

Introduction

This report shows statistics regarding LACNIC's available IPv4 resources.

Available IPv4 Address Space

Currently LACNIC as RIR is responsible of the registry, allocation and assignment of 11.24 /8s (188,569,088). The utilization of this space is shown in Figure 1.

When the remaining space in the graph shows less than 4,194,304 we will consider the LACNIC stock exhausted and LACNIC will switch to Policies Relating to the Exhaustion of IPv4 Address Space.