2. IPv4 ADDRESSES

2.1.SCOPE

This chapter describes the Internet resource management system in the region of Latin America and the Caribbean. In particular, it describes the rules and guidelines that govern the allocation of the IPv4 address blocks assigned to Latin America and the Caribbean. In the case of IP addresses, the rules established in this chapter apply to all IPv4 address blocks allocated or assigned through LACNIC as well as to those previously allocated and assigned by ARIN.

This chapter does not describe private Internet address space or multicast address space. Neither does this chapter describe IPv6 address space management, a topic that is dealt with in the chapter titled "IPv6 Address Allocation and Assignment Policies." A distinction is made in this document between IP address allocation and assignment. IP addresses are allocated to NIRs and ISPs so that they may in turn assign them to their end users.

2.2.IPv4 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM

2.2.1.Types of IPv4 Addresses

For the purpose of this chapter, IPv4 addresses are 32-bit binary numbers that are used as addresses in IPv4 protocols used in the Internet. There are three types of IPv4 addresses.

2.2.1.1.Public IPv4 Addresses

Public IPv4 addresses constitute the Internet address space. These addresses are globally unique and allocated in accordance with the objectives that will later be described herein. The main objective of this address space is to allow communication using IPv4 on the Internet.

A secondary objective is to allow communication between interconnected private networks.

2.2.1.2.Private IPv4 Addresses

Certain IPv4 address ranges have been reserved for the operation of private networks. Any organization may use these IPv4 addresses in their private networks without the need of requesting them from an Internet Registry. The main requirement established for the use of private IPv4 addresses is that the hosts that use these IPv4 addresses do not need to be reached through the Internet.

For a more detailed description of the private IPv4 address space, see RFC 1918.

2.2.1.3.Special and Reserved IPv4 Addresses

These are IPv4 address ranges reserved for applications such as multicasting. These IPv4 addresses are described in RFC 1112 and are beyond the scope of this chapter.

2.3.IPv4 ADDRESS ALLOCATION AND ASSIGNMENT POLICIES

2.3.1.Introduction

This chapter describes how an Internet Registry (for future reference, this concept encompasses Internet Service Providers and National Internet Registries) may obtain an IPv4 address allocation and how that allocated space must be administered.

IPv4 address space is allocated to Internet Registries (IR) using a slow-start model. Allocations are based on justifiable need, not only on the grounds of client prediction. Due to the fact that the number of IPv4 addresses is limited, many factors must be considered for the delegation of IPv4 address space. The idea is to allocate IPv4 address space to Internet Registries in the same proportion as they will assign the IPv4 addresses to their users.

The size of an allocation to a particular IR is based on the rate with which it has previously assigned IPv4 address space to its clients. The aim is to avoid the existence of large blocks that are not assigned to end users. Due to technical restrictions and the possibility of overloading routing tables, certain policies must be implemented in order to ensure that the preservation and routability objectives are fulfilled.

This chapter mentions prefix sizes and block sizes. Standard notation implies that longer prefixes reference blocks of smaller size. For example, when it is said that a certain policy applies to a prefix longer than a /20, this means that a block smaller than 16 /24s is being discussed.

2.3.2.Aspects to Consider in Relation to IPv4 Address Administration

This section describes a number of aspects on which the relationships both between Internet Registries and their clients as well as between Internet Registries and LACNIC must be based.

2.3.2.1.IPv4 Addresses are Delegated

LACNIC shall allocate Internet resources according to a delegation plan. This resource allocation plan shall be valid for one year. This allocation is renewable, and shall be subject to the conditions established at the time of renewal.

2.3.2.2.Slow-Start Policy

IPv4 address blocks are allocated to IRs using a slow-start procedure. Internet Service Providers applying for portable (provider-independent) IPv4 address blocks for the first time shall receive a minimal amount based on immediate requirement, with the exceptions established in Section 2.3.3.3 ("Direct Allocations to Internet Service Providers".)

After this initial allocation, allocated blocks may be increased based on the verification of block utilization according to information provided to LACNIC. Thus, LACNIC shall be responsible for determining initial and subsequent allocations. Initial IPv4 address allocations shall enable IRs to operate for at least twelve months without requiring further allocations.

Initial allocations shall not be based on any current or future routing restrictions, but on actual and demonstrated use of IPv4 addresses.

Likewise, the number of IPv4 addresses projected by the applicant is useful for planning future requirements.

2.3.2.3.Allocated Blocks

In order to ensure an efficient implementation and use of classless technologies (CIDR), LACNIC shall allocate IPv4 address blocks based on the limits supported by this technology. In order to facilitate the efficient deployment of CIDR, Internet Service Providers (ISPs) and End Users are encouraged to initially request IP address space from their upstream providers. Upstream providers shall maintain control of the assigned blocks upon termination of their clients' contracts.

2.3.2.4.Avoid Block Fragmentation

Under the CIDR scheme, IP addresses are allocated to IRs in blocks. It is recommended that the publication of these blocks on the routing tables remain intact. More specifically, ISPs shall treat IP address assignments to their clients as a loan for the duration of the connectivity. Upon termination of the Internet connectivity contract, e.g., if a customer moves to another ISP, the client shall return the IPv4 addresses currently in use and renumber its systems using the new IPv4 addresses of the new provider. New requests for IP addresses shall be conditioned to the completion of this task. The IR shall allow sufficient time for the renumbering process to be completed before these IP addresses can be used again by another client.

2.3.2.5.This item has intentionally been left blank.

2.3.2.6.Use of Classless Technology (CIDR)

Due to the requirement to increase the efficiency in the use of IPv4 address space, all allocations and/or assignments are made under the assumption that organizations use variable-length subnet masks (VLSMs) and classless technology (CIDR) within their networks.

The use of classful technologies is generally unacceptable due to the limited availability of free IPv4 address space.

2.3.2.7.Static Addressing

Due to restrictions on the availability of IPv4 addresses, LACNIC shall in no way endorse the use of static IPv4 address assignments for dial-up users (e.g., one address per customer). It is understood that the use of static addressing may simplify certain administrative aspects. However, the current rate of consumption of IPv4 addresses does not allow the assignment of static addresses for administrative reasons. Because of this, organizations that are considering the use of static IPv4 address assignment are encouraged to investigate and implement dynamic assignment technologies.

2.3.2.8.Web Hosting

The development of the HTTP 1.1 protocol has eliminated the need of reserving an IP address for each web domain in case of multiple websites on the same server. LACNIC promotes the development of webpage hosting based on name usage, as opposed to IPv4 addresses.

Therefore, this latter case shall not be accepted as justification for IPv4 address utilization. LACNIC shall consider exceptions where applications require the use of web hosting based on IPv4 addresses, which must be duly described and justified.

2.3.2.9.This item has intentionally been left blank.

2.3.2.10.This item has intentionally been left blank.

2.3.2.11.This item has intentionally been left blank.

2.3.2.12.Supervision of Assignments

2.3.2.12.1.Assignment Window

ISPs may assign to their clients blocks smaller than 16 /24s, i.e. prefixes longer than /20, in accordance with the policy defined by LACNIC in the present document. In some cases, the assignment shall be consulted with LACNIC or with the corresponding NIR in order to ensure optimization of the use of IP address space and the correct application of LACNIC policies.

LACNIC defines an allocation window as the assignment of blocks larger than or equal to 2 /24s, i.e. prefixes shorter than or equal to /23. These assignments shall be consulted with LACNIC or the corresponding NIR. Communication between the ISPs and LACNIC or the corresponding NIR shall include the same information and justifications required in this document for end users.

2.3.2.12.2.Allocations to NIRs

NIRs are exempt from complying with Section 3.2.12.1. Instead, they shall be subject to more severe audit programs in accordance with the provisions of the contracts between LACNIC and the NIRs.

These audits shall be carried out at least once a year and, if necessary, with greater frequency.

2.3.2.13. Registering assignments

All IPv4 address block assignments of a /29 or larger block made by an ISP to customers connected to their network and users of services provided must be registered on LACNIC's WHOIS database no more than 7 days after the assignment.

The information available in the WHOIS database will also be used by LACNIC when analyzing additional IPv4 address block requests made by the ISP.

As long as the prefixes are registered in the WHOIS database, the recipient will have the right to create and manage the RPKI Route Origin Authorizations (ROAs) for said resources.

Assignment registration is also necessary for the following reasons:

. To ensure that the IR has completed or is close to completing address space allocation such that the allocation of additional space is justified.

. To inform the Internet community which organization is using the IPv4 address space, including the point of contact in case of operation problems, security issues, etc.

. To assist in the study of IPv4 address allocation within the region.

. To facilitate the geolocation of sub-assignments made by members in our region.

2.3.2.13.1.Required Information

Assignments registered on LACNIC's WHOIS database must include the following information regarding the assignee: organization name; address; administrative contact, technical contact, and contact in case of abuse, with their updated telephone numbers and email addresses.

2.3.2.13.1.1. Residential Customers

ISPs that provide services to residential customers may register on LACNIC's WHOIS database address blocks that are being used by equipment or customer service areas, by service.

Registered information must specify the service area, address of the ISP's main offices, its administrative contact, technical contact, and contact in case of abuse, including their updated telephone numbers and email addresses.

Assignments must be made in address blocks totalizing the number of customers served in the area or by the equipment.

2.3.2.13.1.2. Residential Customer Privacy

Residential customers receiving /29 and larger IPv4 block assignments do not need to have their data registered on LACNIC's WHOIS database.

The ISP whose residential customer receives an IPv4 assignment of a /29 or larger block may choose to register the assignment on LACNIC's WHOIS database by entering its own data or a code used as internal reference. The administrative contact, technical contact, and contact in case of abuse must be those of the ISP.

2.3.2.13.2.This item has intentionally been left blank.

2.3.2.14.This item has intentionally been left blank.

2.3.2.15.This item has intentionally been left blank.

2.3.2.16.Micro-Assignments

LACNIC shall make micro-assignments of prefixes longer than the standard (smaller blocks) in the special cases listed in Section 2.3.3 - "Initial IPv4 Address Space Allocation Policies."

2.3.2.17.Mergers, Acquisitions, Reorganizations or Relocations

Because LACNIC's policies do not recognize the non-authorized sale or transfer of assigned or allocated resources, such transfers will be considered invalid, with the exception of those subject to the provisions of section 2.3.2.18.

Nevertheless, LACNIC will process and register any IPv4 resource transfer that occurs as a result of a partial or complete merger, acquisition, business reorganization or relocation, regardless of whether the resources are held by an ISP or an end-user.

To initiate this change and proceed with the registration, legal documentation must be submitted which, at the discretion of LACNIC, supports the operation. Examples of such documentation include:

• A copy of the legal document validating the transfer of assets.
• A detailed inventory of all the assets used by the applicant for maintaining the resources in use.
• A list of the applicant's clients using the resources.

In addition, the need to maintain all the resources must also be justified, forcing the return of the surplus resources if applicable or, alternatively, the transfer of such surplus resources to third parties under the policies in force (2.3.3 and 2.3.4.). When resources are to be returned, LACNIC will determine the corresponding conditions and deadline.

2.3.2.18.IPv4 address transfers

IPv4 block transfers shall be allowed between LIRs and/or End Users (hereinafter organizations) in accordance with the conditions set forth in this section.

This policy applies both to transfers where one of the organizations involved is part of another region (inter-RIR transfers) as well as to transfers within the LACNIC region (intra-RIR transfers).

2.3.2.18.1. The minimum block size that may be transferred is a /24.

2.3.2.18.2. In order for an organization within the LACNIC region to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resources before LACNIC.

That is to say, the organization must justify before LACNIC the initial/additional allocation/assignment, as applicable, according to the policies in force.

If the receiving organization is part of another region, it will be subject to the criteria, verifications and requirements of the corresponding RIR.

2.3.2.18.3. LACNIC or the corresponding RIR (depending on whether the transfer is inbound or outbound) will verify the holder of the resources to be transferred and check that they are not involved in any dispute.

In the case of intra-RIR transfers, both organizations must submit to LACNIC a signed copy of the legal document supporting the transfer.

In the case of inter-RIR transfers, the documentation supporting the operation will be agreed between the two RIRs.

2.3.2.18.4. LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. This log will be used to record the date on which the transaction took place, the organization that originated the transfer, the receiving organization, the transferred addresses and, in the case of inter-RIR transfers, the source and destination RIRs.

2.3.2.18.5. The organization that originated the transfer shall automatically be ineligible to receive IPv4 resource allocations and/or assignments from LACNIC for a period of one year as of the transaction date registered in the transfer log.

2.3.2.18.6. Addresses that have previously been transferred may not subsequently be transferred again (in full or in part) for a period of one year as of the transaction date specified in the transfer log.

2.3.2.18.7. Once the transfer is complete, LACNIC shall modify the information on the transferred resource in order to reflect the change of holder.

2.3.2.18.8. Both the transferring and the receiving organizations will be subject to the policies and membership terms and conditions of the corresponding RIR.

2.3.2.18.9. Addresses from allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of three years as of the allocation or assignment date.

2.3.2.18.10. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.

2.3.3.Initial IPv4 Address Allocation and Assignment

LACNIC shall allocate IPv4 addresses to organizations covered by the following cases:

• Allocations to Internet Service Providers.
• Micro-assignments to Critical Infrastructure.
• Direct allocations to Internet Service Providers.
• End user Assignments.

This section contains a detailed description of the policies LACNIC shall apply for the initial allocation of portable (provider-independent) IPv4 addresses in each of the cases listed above.

Due to the fact that the number of IPv4 addresses available on the Internet is limited, many factors must be considered for determining IPv4 address space allocation. Therefore, IPv4 address space is allocated to ISPs based on a slow-start model. Allocations are based on current justifiable need, not on prediction of number of clients, market research, etc.

2.3.3.1.Initial Allocations to ISPs

The minimum initial allocation size applicable to Internet Service Providers established within LACNIC’s service region is a /24.

2.3.3.1.1.Requirements for a /24 to /22 prefix

In order to qualify for the allocation of a /24 to /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.
3. 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 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.
4. 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:

1. Provide information on assignments with prefixes equal to or shorter than /29 (more than 8 IPv4 addresses) on LACNIC's WHOIS database.
2. 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.
3. 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 over1 (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 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.

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

In addition, depending of the multihomed or non-multihomed status of the applying ISP, the following requirements shall be considered:

If the applicant is a multihomed ISP, is planning to become one, or has interconnection needs:

Efficient utilization of at least 25% of the requested address space (contiguous or not).

If the applicant is multihomed, specify the names and autonomous system numbers of its providers.

If the applicant is planning to become multihomed or needs to interconnect with other autonomous systems, describe in detail the corresponding plan and timeline (presenting signed contracts or letters of intent is recommended).

If the applicant is a non-multihomed ISP:

Efficient utilization of at least 50% of the requested address space (contiguous or not).

2.3.3.2.Micro-Assignments to Critical Infrastructure

Micro-assignment is the name given to those assignments that involve prefixes longer or equal than /22 but shorter than or equal to /24.

LACNIC may grant this type of assignment in case of projects and network infrastructure that are key or critical for the region, such as IXPs (Internet Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among others.

In the case of IXPs or NAPs, in order to be eligible for this type of assignment, the organization must meet the following requirements:

1. Duly document the following aspects:
   1. Prove by means of their bylaws their IXP or NAP capacity. The organization shall have at least three members and an open policy for the association of new members.
   2. Submit a diagram of the organization’s network structure.
   3. Document the numbering plan to be implemented.
2. Provide a utilization plan for the following three and six months.

The rest of the applications shall be studied based on the analysis of the documentation justifying the critical and/or key aspects of the project.

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

Organizations receiving micro-assignments shall not sub-assign these IPv4 addresses.

2.3.3.3.Direct Allocations to Internet Service Providers

LACNIC acknowledges that there may exist circumstances under which there is justifiable need for an initial allocation of a /20 or smaller prefix.

LACNIC may grant this type of allocation to those organizations that meet the following requirements:

• The organization is multi-homed or an Internet Service Provider and demonstrates the possibility of interconnecting with other providers or network access points (NAP/IXP).

• Submit a detailed description of their network topology.

• Submit a portfolio with a detailed description of the services the organization will offer.

• Submit a detailed plan of the deployment of address space utilization for three, six, and twelve months.

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

For these allocations LACNIC may, at any time, request additional information to help justify a minimal allocation.

2.3.3.4. Assignments to End Users

LACNIC shall assign IPv4 address blocks to end users requiring IPv4 address space for internal use, for the operation of their networks.

Typically, end users receive IPv4 address space from their upstream providers, not directly from LACNIC. Portable (provider-independent) IPv4 addresses obtained directly from LACNIC or other Regional Registries are not guaranteed to be globally routable.

For this reason, end users should contact their Internet Service Providers to ensure their connectivity within the network.

End users not connected to an ISP and/or not planning to be connected to the Internet are advised to use private IPv4 addresses. The description of these IP addresses may be found in RFC 1918.

2.3.3.4.1.Required Information

LACNIC shall request the following information from all end users requesting IPv4 address blocks:

1. Provide detailed information showing how the requested block will be used within the following three, six and twelve months.
2. Submit subnetting plans for a period not shorter than one year, including subnet masks and host numbers on each subnet. Use of VLSM is required.
3. Submit a detailed description of the network topology.
4. Prepare a detailed description of the network routing plans, including the routing protocols to be used as well as any existing limitations.
5. If the applicant does not already have an IPv6 block assigned by LACNIC, simultaneously request an IPv6 block in accordance with the corresponding applicable policy.

2.3.3.4.2.Utilization Rate

Utilization rate is a key factor that must be justified in order to dimension the size of the assignment. Utilization rate is the percentage of IPv4 addresses that the organization will use within a specified period of time. The rate adopted by LACNIC is:

25% immediate utilization rate of the requested block.

50% utilization rate of the requested block within one year.

A higher utilization rate may be required based on individual requirements. Should the organization presenting the application fail to comply with these parameters, addresses may be withdrawn and a reasonable period negotiated for their renumbering.

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 block; the maximum size is a /20, which must be justified according to the utilization rate (section 2.3.3.4.2).

If a block had already been assigned by a provider and the user wishes to keep this block to avoid renumbering, such block may be handed over (changing the resource holder in Lacnic’s whois database) provided that both parties agree. 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 proceed to renumber. Should they choose to renumber, the block that had been previously assigned must be returned within 6 months.

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

2.3.4. Policies for the Distribution of Additional IPv4 Address Space

This policy is presented with the aim of assisting Internet Registries in the process of applying for additional IPv4 address space. The most important factor in the evaluation of additional IPv4 address space applications is the revision of the current IPv4 address space of the organization presenting an application.

In order to receive additional space, the organization presenting an application must have used at least 80% of the IPv4 address space previously assigned by the corresponding RIR or NIR. This includes the space assigned to its clients. Therefore, it is important that IRs demand that their clients follow the efficient utilization practices described in these policies.

The steps that must be completed for the allocation of new IPv4 address blocks are the following:

1. The first step of the process is to verify the utilization of at least 80% of previous allocations. This utilization percentage shall be based solely on announced networks with IPv4 addresses connected to the Internet. For IRs that have assigned IPv4 addresses to their clients, the method available to prove this utilization is through the records kept in LACNIC's WHOIS database. Consideration of the application shall not continue until utilization of at least 80% of the previously allocated block is verified. Use of 80% of previously allocated IP addresses also covers those addresses dedicated to internal use and dial-up clients of the company. In this latter case, utilization may be justified through the report included in Appendix 3 [Additional Report for IPv4 Address Space Allocation]. Organization making static assignments, may justify utilization through the report included in Appendix 4 [IPv4 Resources Distribution Report].

The application process for additional space shall continue once the utilization of at least 80% of the previously assigned space has been verified.

2. Organizations shall prove they are using LACNIC policies in assigning space to their clients, particularly in relation to:

• Issuing prefixes longer than /24, wherever possible.
• Verifying that the assignment of blocks within the allocation window were previously submitted to LACNIC for approval.

3. Organizations shall demand that their clients adhere to the following criteria:

• The information on assignments smaller than a /29 must be available through WHOIS and they must comply with the 80% space utilization requirement before assigning additional space to their clients.
• LACNIC policies for the Internet community in general are communicated to and followed by their clients.

4. When reviewing applications for additional IPv4 addresses, LACNIC shall also review whether the space designated for its return was actually returned in due time as described in this document.
5. Maintain the reverse resolution registry of the administered IPv4 address space up-to-date. The reverse resolution registry shall also comply with 80% utilization.
6. For the allocation of additional blocks, LACNIC shall verify that the organization presenting the application is in compliance with its contractual obligations.
7. The applicant must already have at least one IPv6 block assigned by LACNIC or, if not, must simultaneously request an initial IPv6 block in accordance with the corresponding applicable policy. If an applicant has already been assigned an IPv6 block, they shall submit to LACNIC a brief document describing their progress in the implementation of IPv6.
8. The final step is to determine the appropriate allocation. In order to determine the size of the allocation, detailed information must be provided showing how the IPv4 address space will be used within the following three, six and twelve-month periods. The policy for determining the size of additional allocations is based on the efficient utilization of space within a time frame of 12 months.

2.3.5. Special IPv4 reserve pool for critical Internet infrastructure in the region.

1. This reserve will be used once the address space for Phase 3 of the regional IPv4 Exhaustion Plan runs out.
2. LACNIC will create an IPv4 reserve equivalent to a /15 to facilitate the deployment of infrastructure considered to be critical or essential for the operation of the Internet in the region, where critical infrastructure has the meaning defined in section 2.3.3.2 of the Policy Manual.
3. Address requests for critical infrastructure may be submitted at any time.
4. Assignments from this reserve will be limited to the following sizes:
   minimum assignment size: /24
   maximum assignment size: /22
5. The size of these assignments will be subject to verification of use and an analysis by LACNIC or by the corresponding NIR.
6. Once they are no longer needed for the purpose for which they were originally requested, the addresses assigned under this section must be returned to LACNIC or to the corresponding NIR.
7. Addresses assigned from this reserve may not be used for a purpose other than that which generated the request. Failure to comply with the above will result in revocation of the assignment and the subsequent return of the addresses to LACNIC or to the corresponding NIR.
8. In the event that IP addresses assigned from this reserve are recovered or returned, such IP addresses must be reincorporated into this reserve. Recovered or returned addresses that are reincorporated into the reserve must go through the corresponding quarantine period before they can be assigned once again.

2.3.6. Permission to Transfer and Non-Return of Resources

While address allocation and assignment policies are initially based on the justification of need, the implementation of transfers eliminates the need to maintain this justification. Therefore, returning the resources to LACNIC will no longer be required in case of failed transfers or mergers and acquisitions.

[1] For the purpose of LACNIC operations, “hand over” (ceder in the Spanish original) is equivalent to a simplification of the transfer process, under which section 2.3.2.18.5 does not apply. In any case, it would not be possible to apply this section as LACNIC has no resources available for organizations other than new-entrants. 

• Menú Policy Manual
  • Policy development
  • Policy Manual (PDF version)
  • LACNIC POLICY MANUAL (v2.19 - 22/08/2023)
  • 0. DEFINITIONS
  • 1. GENERAL RULES
  • 2. IPv4 ADDRESSES
  • 3. ALLOCATION OF AUTONOMOUS SYSTEM NUMBERS (ASN)
  • 4. IPv6 ADDRESS ALLOCATION AND ASSIGNMENT POLICIES
  • 5. DELEGATION OF REVERSE RESOLUTION
  • 6. LAME DELEGATION POLICY
  • 7. RESOURCE REVOCATION AND RETURN[2]
  • 8. Request for BULK WHOIS
  • 9. Global Policies
  • 10. Policy for the Allocation of Internet Resources for Research and Experimental Needs
  • 11. Policies Relating to the Exhaustion of IPv4 Address Space
  • 12. Registration and validation of "abuse-c" and "abuse-mailbox"
  • Appendixes