Adapting the allocation / assignment policy for IPv4 exhaustion.

LAC-2013-3-v1 LAC-2013-3-v2 Vs
References:
New
Deleted
Modified
Authors

Name: Juan Alejo
Email: jpeirano@lacnic.net
Organization: LACNIC

Name: Carlos Plasencia
Email: carlos.plasencia@outlook.com
Organization: BT

Summary

This policy seeks to increase the size of the reserves created considering IPv4 exhaustion, increasing the IPv4 pool res
erved for new members from a /12 to a /11 (policy 11.1) and increasing the pool reserved for gradual exhaustion (policy
11.2) from a /12 to a /11. In addition, repeat requests for address space for critical infrastructure, if justified, sho
uld be allowed.

This policy seeks to increase the size of the reserves created considering IPv4 exhaustion, increasing the IPv4 pool res
erved for new members from a /12 to a /11 (policy 11.1) and increasing the pool reserved for gradual exhaustion (policy
11.2) from a /12 to a /11. In addition, repeat requests for address space for critical infrastructure, if justified, sho
uld be allowed. The proposal also seeks to use the term "gradual" instead of "suave" and "gradativo" instead of "tranqui
lo" in the Spanish and Portuguese versions of the text, respectively, in order to harmonize the terminology used in the
various languages spoken in our region.

Rationale (Describe the problem you intend to solve)

Based on the size of IPv4 reserves, the number of requests considering LACNIC's current membership, and how other RIRs h
ave managed IPv4 exhaustion in their respective regions, we propose increasing the size of the existing reserve.
By mid-2013, LACNIC had more than 3000 members. In addition, according to the trends observed in LACNIC membership growt
h charts, 600 new members have joined the organization each year for the past two years.
As each /12 block contains 1024 /22 blocks, current reserves do not appear to be large enough to allow a smooth transiti
on to IPv6 in our region.
Another important aspect that needs to be considered is addressing for critical infrastructure, as current exhaustion-re
lated policies do not include any specific provisions in this sense.
Given the importance of this type of organizations, we believe they should be able to request resources when needed. As
policies currently stand, once policy 11.2 comes into force, these organizations will only be allowed to request resourc
es once every 6 months; furthermore, when policy 11.1 comes into force, they will be unable to request any further resou
rces unless they qualify as a new member, and even in this case, they will only be able to submit one request. This poli
cy proposes that organizations qualifying as critical infrastructure should be able to request up to a /22 when needed,
until they finally complete their transition to IPv6.

Based on the size of IPv4 reserves, the number of requests considering LACNIC's current membership, and how other RIRs h
ave managed IPv4 exhaustion in their respective regions, we propose increasing the size of the existing reserve.
By mid-2013, LACNIC had more than 3000 members. In addition, according to the trends observed in LACNIC membership growt
h charts, 600 new members have joined the organization each year for the past two years.
As each /12 block contains 1024 /22 blocks, current reserves do not appear to be large enough to allow a smooth transiti
on to IPv6 in our region
Another important aspect that needs to be considered is addressing for critical infrastructure, as current exhaustion-re
lated policies do not include any specific provisions for repeat assignments to critical infrastructure.
Given the importance of this type of organizations, we believe they should be able to request resources when needed. As
policies currently stand, once policy 11.2 comes into force, these organizations will only be allowed to
request resources once every 6 months; furthermore, when policy 11.1 comes into force, they will be unable to request an
y further resources unless they qualify as a new member and, even in this case, they will only be able to submit one req
uest. This policy proposes that organizations qualifying as critical infrastructure should be able to request up to a /2
2 when needed, both from the reserve described in 11.1 as well as from the reserve described in 11.2, until they finally
complete their transition to IPv6.
Because the manual must be translated into three different languages (Spanish, Portuguese and English), we propose modif
ying the terminology used in section 11.2 in order to harmonize the meaning in all three languages, using the term gradu
al instead of suave in Spanish and gradativo instead of tranquilo in Portuguese.

Current text

This proposal only affects section 11 of the Policy Manual as described below.
Should the size of the pool reserved for new members be modified, the Policies Relating to the Exhaustion of IPv4 Addres
s Space included in chapter 11.1 shall continue to be used as set forth below:
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for new LACNIC members.
2. No IPv4 allocations or assignments will be made to organizations that have already been assigned or allocated IPv4
resources by LACNIC or by the organizations that preceded LACNIC in the region currently serviced by LACNIC.
3. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to /
22 from this reserve pool.
4. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied using the reserve created under section 11.2.
5. Requests for IPv4 address blocks larger than a /22 pending approval may only receive a /22 from this reserve.
6. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
from LACNIC additional IPv4 resources from this reserve.
7. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
future IPv4 resource allocations or assignments from LACNIC for a period of 6 months, with the exception of resources fo
r critical infrastructure when adequately justified.
8. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the Policy Manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
9. Recurring requests for critical infrastructure must follow the conditions previously set forth under item 2.3.3.2
of the Policy Manual. In addition, an action plan showing how IPv6 will be implemented must be submitted.
10. In order for the resources to be assigned, the requesting organization must also submit evidence of efficient ut
ilization of at least 80% of their resources.
11. This policy does not replace section 11.2 of the Policy Manual. The reserve pool created under 11.2 is independe
nt from the reserve created under the following policy.
12. If the applicant has not already been assigned an IPv6 address block by LACNIC, it must also request an IPv6 add
ress block in accordance with the corresponding applicable policy.
As to allocations/assignments for gradual IPv4 resource exhaustion, the policy manual shall be modified as follows:
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for the purpose of achieving gradual exha
ustion of IPv4 resources within the LACNIC region.
2. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to a
/22 from this reserve pool.
3. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied in full due to lack of IPv4 resources in the LACNIC region.
4. Once this policy comes into force, IPv4 resource applications smaller than a /22 that are pending approval may onl
y receive a /22.
5. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
future IPv4 resource allocations or assignments from LACNIC for a period of 6 months, with the exception of resources fo
r critical infrastructure when adequately justified.
6. Organizations receiving IPv4 resources under the terms set forth in the following policy may receive additional IP
v4 resources from LACNIC six months later, provided that they generate a new request that justifies the need for additio
nal IPv4 resources according to the IPv4 address allocation or assignment policies in force. Organizations requesting ad
dress blocks for critical infrastructure may request up to a /22 at any time.
7. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the Policy Manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
8. This proposal does not replace Section 11.1 of the Policy Manual. The reserve created under section 11.1 is indepe
ndent from the reserve created under this proposal.
9. Recurring requests for critical infrastructure must follow the conditions previously set forth under item 2.3.3.2
of the Policy Manual. In addition, an action plan showing how IPv6 will be implemented must be submitted.
10. In order for the resources to be assigned, the requesting organization must also submit evidence of efficient ut
ilization of at least 80% of their resources.

This proposal only affects section 11 of the Policy Manual as described below.
11.1 Special IPv4 Allocations/Assignments Reserved for New Members
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for new LACNIC members.
2. No IPv4 allocations or assignments will be made to organizations that have already been assigned or allocated IPv4
resources by LACNIC or by the organizations that preceded LACNIC in the region currently serviced by LACNIC.
3. Under this policy, IPv4 address requests classified as critical infrastructure according to the LACNIC policies in
force may receive addresses, even if they have already been assigned IPv4 resources by LACNIC.
4. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to a
/22 from this reserve pool.
5. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied in full due to lack of IPv4 resources in the LACNIC region.
6. Once this policy comes into force, IPv4 resource applications smaller than a /22 that are pending approval may onl
y receive a /22
7. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
from LACNIC additional IPv4 resources that are part of this reserve, with the exception of requests for critical infrast
ructure.
8. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the policy manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
9. This policy does not replace section 11.1 of the Policy Manual. The reserve created under section 11.2 is independ
ent from the reserve created under the following policy.
10. If the applicant has not already been assigned an IPv6 address block by LACNIC, it must also request an IPv6 addr
ess block in accordance with the applicable policy.
As to allocations/assignments for gradual IPv4 resource exhaustion, the policy manual shall be modified as follows.
11.2. Allocations/Assignments for Gradual IPv4 Resource Exhaustion
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for the purpose of achieving gradual exha
ustion of IPv4 resources within the LACNIC region.
2. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to a
/22 from this reserve pool.
3. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied in full due to lack of IPv4 resources in the LACNIC region.
4. Once this policy comes into force, IPv4 resource applications smaller than a /22 that are pending approval may onl
y receive a /22.
5. Organizations receiving IPv4 resources under the terms set forth in the following policy may receive additional IP
v4 resources from LACNIC after a period of six months, provided that they generate a new request that justifies the need
for additional IPv4 resources according to the IPv4 address allocation or assignment policies in force. Organizations r
equesting address blocks for critical infrastructure may request up to a /22 at any time.
6. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the policy manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
7. This proposal does not replace section 11.1 of the Policy Manual. The reserve created under section 11.1 is indepe
ndent from the reserve created under this proposal.

New text

This proposal only affects section 11 of the Policy Manual as described below.
Should the size of the pool reserved for new members be modified, the Policies Relating to the Exhaustion of IPv4 Addres
s Space included in chapter 11.1 shall continue to be used as set forth below:
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for new LACNIC members.
2. No IPv4 allocations or assignments will be made to organizations that have already been assigned or allocated IPv4
resources by LACNIC or by the organizations that preceded LACNIC in the region currently serviced by LACNIC.
3. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to /
22 from this reserve pool.
4. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied using the reserve created under section 11.2.
5. Requests for IPv4 address blocks larger than a /22 pending approval may only receive a /22 from this reserve.
6. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
from LACNIC additional IPv4 resources from this reserve.
7. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
future IPv4 resource allocations or assignments from LACNIC for a period of 6 months, with the exception of resources fo
r critical infrastructure when adequately justified.
8. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the Policy Manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
9. Recurring requests for critical infrastructure must follow the conditions previously set forth under item 2.3.3.2
of the Policy Manual. In addition, an action plan showing how IPv6 will be implemented must be submitted.
10. In order for the resources to be assigned, the requesting organization must also submit evidence of efficient ut
ilization of at least 80% of their resources.
11. This policy does not replace section 11.2 of the Policy Manual. The reserve pool created under 11.2 is independe
nt from the reserve created under the following policy.
12. If the applicant has not already been assigned an IPv6 address block by LACNIC, it must also request an IPv6 add
ress block in accordance with the corresponding applicable policy.
As to allocations/assignments for gradual IPv4 resource exhaustion, the policy manual shall be modified as follows:
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for the purpose of achieving gradual exha
ustion of IPv4 resources within the LACNIC region.
2. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to a
/22 from this reserve pool.
3. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied in full due to lack of IPv4 resources in the LACNIC region.
4. Once this policy comes into force, IPv4 resource applications smaller than a /22 that are pending approval may onl
y receive a /22.
5. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
future IPv4 resource allocations or assignments from LACNIC for a period of 6 months, with the exception of resources fo
r critical infrastructure when adequately justified.
6. Organizations receiving IPv4 resources under the terms set forth in the following policy may receive additional IP
v4 resources from LACNIC six months later, provided that they generate a new request that justifies the need for additio
nal IPv4 resources according to the IPv4 address allocation or assignment policies in force. Organizations requesting ad
dress blocks for critical infrastructure may request up to a /22 at any time.
7. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the Policy Manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
8. This proposal does not replace Section 11.1 of the Policy Manual. The reserve created under section 11.1 is indepe
ndent from the reserve created under this proposal.
9. Recurring requests for critical infrastructure must follow the conditions previously set forth under item 2.3.3.2
of the Policy Manual. In addition, an action plan showing how IPv6 will be implemented must be submitted.
10. In order for the resources to be assigned, the requesting organization must also submit evidence of efficient ut
ilization of at least 80% of their resources.

This proposal only affects section 11 of the Policy Manual as described below.
11.1 Special IPv4 Allocations/Assignments Reserved for New Members
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for new LACNIC members.
2. No IPv4 allocations or assignments will be made to organizations that have already been assigned or allocated IPv4
resources by LACNIC or by the organizations that preceded LACNIC in the region currently serviced by LACNIC.
3. Under this policy, IPv4 address requests classified as critical infrastructure according to the LACNIC policies in
force may receive addresses, even if they have already been assigned IPv4 resources by LACNIC.
4. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to a
/22 from this reserve pool.
5. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied in full due to lack of IPv4 resources in the LACNIC region.
6. Once this policy comes into force, IPv4 resource applications smaller than a /22 that are pending approval may onl
y receive a /22
7. Those organizations that receive IPv4 resources under the terms set forth in the following policy may not receive
from LACNIC additional IPv4 resources that are part of this reserve, with the exception of requests for critical infrast
ructure.
8. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the policy manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
9. This policy does not replace section 11.1 of the Policy Manual. The reserve created under section 11.2 is independ
ent from the reserve created under the following policy.
10. If the applicant has not already been assigned an IPv6 address block by LACNIC, it must also request an IPv6 addr
ess block in accordance with the applicable policy.
As to allocations/assignments for gradual IPv4 resource exhaustion, the policy manual shall be modified as follows.
11.2. Allocations/Assignments for Gradual IPv4 Resource Exhaustion
1. LACNIC will create a reserve equivalent to a /11 block of IPv4 addresses for the purpose of achieving gradual exha
ustion of IPv4 resources within the LACNIC region.
2. LACNIC may only make IPv4 allocations or assignments greater than or equal to a /24 and smaller than or equal to a
/22 from this reserve pool.
3. LACNIC will only allocate or assign resources from this reserve after approval of the first IPv4 address request t
hat cannot be satisfied in full due to lack of IPv4 resources in the LACNIC region.
4. Once this policy comes into force, IPv4 resource applications smaller than a /22 that are pending approval may onl
y receive a /22.
5. Organizations receiving IPv4 resources under the terms set forth in the following policy may receive additional IP
v4 resources from LACNIC after a period of six months, provided that they generate a new request that justifies the need
for additional IPv4 resources according to the IPv4 address allocation or assignment policies in force. Organizations r
equesting address blocks for critical infrastructure may request up to a /22 at any time.
6. Blocks received under this policy may not be transferred as specified in paragraph 2.3.2.18 of the policy manual f
or a period of one year. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses c
ontained in the block.
7. This proposal does not replace section 11.1 of the Policy Manual. The reserve created under section 11.1 is indepe
ndent from the reserve created under this proposal.

Additional information

NO

In Section 11.1, this version simplifies the adaptation and removes the need for the requesting organization to submit e
vidence of efficient utilization of at least 80% of its resources and an action plan showing how IPv6 will be implemente
d.
In Section 11.2, this version replaces the terms "suave" and "tranquilo" with "gradual" and "gradativo" in Spanish and P
ortuguese, respectively, simplifies the adaptation and removes the need for the requesting organization to submit eviden
ce of efficient utilization of at least 80% of its resources and an action plan showing how IPv6 will be implemented. In
addition, paragraph 6 is also eliminated, as it created a redundancy in terms of the amount of time an organization mus
t wait before making a new application (6 months).

References

NO

NO