LACNIC Staff's Interpretation of the Proposal
Scope:
This proposal would apply to IPv4 transfers under section 2.3.2.18 of the Policy Manual.
Modifications to the current text
The proposal adds a new requirement to the IPv4 address transfer process, as described in section “2.3.2.18. IPv4 Address Transfers.”
Receiving organization in LACNIC must have LACNIC or provider allocated/assigned IPv6 space and be able to prove it is being used by providing LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network.
LACNIC staff will define a minimal criterion to guarantee the information provided proves IPv6 is operational. If necessary staff may require further information to validate this requirement.
In the case the receiver provides a written statement from its upstream(s) that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
If LACNIC is not able to meet a request using the reserved pool under 11.1 conditions, or the organization does not hold any IPv4 space, the requesting organization will be permitted to transfer an IPv4 space equivalent of maximum of /22 and the IPv6 requirement may be waived.
LACNIC Staff Comments:
(Comments are observations intended to highlight the changes introduced by the proposal with regard to the current text of the Policy Manual.)
1. We maintain our comment from the impact analysis we prepared for the previous version of this proposal as, in our opinion, the change proposed in the new version does not provide a solution to this comment:
“We identified an inconsistency between the rationale included in the summary and the wording of the proposal. The proposal leads us to interpret that, from now on, all transfers will be limited to a maximum of a /22 and that the operational IPv6 requirement may be waived for the receiver. We believe that this is due to a translation error in these two sentences (see recommendations).
Therefore, if the current wording were to be approved by the community, LACNIC interprets that we would not limit INTRA-RIR and INTER-RIR transfers up to and including a /22. In addition, for transfers of up to and including a /22, we would not require meeting the operational IPv6 requirement for the receiving organization when it is part of the LACNIC region.”
2. This requirement might represent an obstacle for certain organizations wishing to participate in transfers and lead them to do so anyway, bypassing the LACNIC registry. Any requirement that imposes an additional burden on transfers has the potential risk of affecting the quality of the information available at LACNIC as a registry.
3. LACNIC will define the criteria that will be used to justify that the IPv6 resources are operational, doing our best to ensure that these requirements prove that IPv6 is operational in significant parts of the network.
4. In interpreting the policies currently in force at other RIRs, we understand that this proposal would not affect LACNIC's outgoing transfers; in other words, the receiving organization in other regions would not be required to comply with this requirement.
5. This proposal creates an imbalance in the requirements that must be met by the organizations in our region in order to transfer IPv4 resources.
It places an additional burden on the receiving organization in our region by requiring operational IPv6 to be able to receive a transfer. This obstacle would even affect transfers between organizations in our own region. This obstacle affecting transfers to organizations within the LACNIC region might generate a flow of IPv4 addresses to other regions.
As you may recall, this was one of the main concerns when discussing the possibility of approving INTER-RIR transfers. With this policy, we would be unintentionally creating this scenario.
6. If this proposal is approved, LACNIC will not revoke IPv6 assignments for being unable to meet our definition of operational IPv6.
Recommendations
1. For reasons of consistency, we recommend that the author modify the final paragraph of the proposal to reflect the wording used in the summary, as follows:
Text of the proposal: “If LACNIC is not able to meet a request using the reserved pool under 11.1 conditions, or the organization does not hold any IPv4 space, the requesting organization will be permitted to transfer an IPv4 space equivalent of maximum of /22 and the IPv6 requirement may be waived.”
Wording used in the summary: “In the case LACNIC is not able to meet a new entrant request for IPv4 space, or the organization does not hold any IPv4 space the IPv6 requirement may be waived for a transfer up to a /22.”
Likewise, we recommend clarifying the text above according to our interpretation: “If the organization does not hold any IPv4 space, then the operational IPv6 requirement for performing a transfer of up to a /22 will be waived.”
2. In order for this policy to have an effect on the global community, it should be submitted as a global policy proposal such that it would not generate any imbalances between the regions that wish to adopt it.
a. We are aware that the policy has already been abandoned in one of the other regions, so it is unlikely that the proposal will be uniformly adopted across all regions.
3. If a new version of this proposal is submitted, make sure that the wording does not create an imbalance in relation to the bidirectionality of the resources due to the condition mentioned in item #5 of the comments above.
Official References:
----------------------------------------------
Other RIRs
AFRINIC
The following policies are currently under discussion:
- Resource Transfer Policy - https://www.afrinic.net/policy/proposals/2019-v4-003-d2
- AFRINIC Number Resource transfer policy -https://www.afrinic.net/policy/proposals/2019-gen-002-d2
- IPv4 Inter RIR Resource transfers (comprehensive scope) - https://www.afrinic.net/policy/proposals/2019-ipv4-002-d4
APNIC
No similar policy
ARIN
A similar policy was presented and later abandoned.
https://www.arin.net/participate/policy/drafts/2019_19
RIPE
No similar policy
Impact of the policy on the registry system
--------------------------------------------
This proposal would have a significant impact on the transfer analysis process (both in terms of time and resources).
On 15th February 2017 LACNIC started IPv4 Exhaustion Phase 3 meaning only new entrants can receive up to a single /22 of IPv4 space. Since then the amount of IPv4 Transfers between organizations has increased reasonably as shown by the official LACNIC reports. With the implementation of LAC-2019-1 and possibility of Inter-RIR transfers these numbers have the potential to grow substantially.
The objective of this proposal is to add as a requirement for organizations in process of receiving transferred IPv4 space under 2.3.2.18 to show they have an IPv6 allocation by LACNIC operational on their networks. Such organization must be able to prove this IPv6 space is being used by providing LACNIC the documented network deployment details to prove IPv6 is operational in significant parts of the network.
On 28th November 2019 LACNIC Board issued a statement (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment) reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space will be exhausted by mid-2020 and calling the community to promote IPv6 deployment.
In its statement LACNIC Board “invite the community to work on promoting the development of policies that will accelerate the effective deployment of IPv6 above other policies that may be discussed at a later date.”
In the case the receiver provides a written statement from its upstream that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
Rationale (Describe the problem you intend to solve)While it is completely understandable the need of organizations for more IPv4 space in order to cope with customers needs for reaching IPv4-only content or to make content available to IPv4-only end-users and despite the IPv4 exhaustion phase, there is a policy in place to allow them to receive more IPv4 space from other organizations who don’t have a need for it anymore, it is necessary that these organizations show commitment to all others by having IPv6 operational on their networks.
The lack of this commitment from those who are receiving more and more IPv4 space aggravates the problem of interconnecting with others which are all part of the same RIR community and ecosystem, therefore it is not just a private situation.
Interoperability has always been a key factor for smooth operation of all Internet ecosystem so having IPv6 operational for growing organizations is a natural move to keep this interoperability in a fast growing Internet scenario.
This proposal does not impose any measures to organizations who do not wish to have IPv6 operational in the case they don’t require receive further IPv4 space respecting their autonomy.
This proposal also meets LACNIC Board call for promoting policies that will accelerate the effective deployment of IPv6.
It’s important to note that the RIR community has the right to establish policies and administer the registry in accordance to these consensual policies. What this proposal does is to add an extra requirement for organizations receiving transferred IPv4 space.
Therefore it has come the time for LACNIC to require organizations receiving transferred IPv4 space to have an IPv6 operational network.
Current text2.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 ofthe 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 one year 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.
New text2.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 Receiving organization must have LACNIC allocated IPv6 space and be able to prove it is being used by providing LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network.
LACNIC staff will define a minimal criteria to guarantee the information provided proves IPv6 is operational. If necessary staff may require further information to validate this requirement.
In the case the receiver provides a written statement from its upstream that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
2.3.2.18.4. 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.5. 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.6. 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.7. Addresses that have previously been transferred may not subsequently be transferred again (in full or in part) for a period of one year as ofthe transaction date specified in the transfer log.
2.3.2.18.8. 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.9. 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.10. Addresses from allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of one year as of the allocation or assignment date.
2.3.2.18.11. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
Additional informationOther than showing it has LACNIC allocated IPv6 space operational, the organization must provide LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network which will be analysed by LACNIC staff as a prove of justification.
Timetable-
ReferencesA similar proposal has been presented in ARIN:
• https://www.arin.net/participate/policy/drafts/2019_19/
Work is been done in regards to this proposal in other RIRs to present equivalent proposals there.
Presented at:-
On 15th February 2017 LACNIC started IPv4 Exhaustion Phase 3 meaning only new entrants can receive up to a single /22 of IPv4 space. Since then the amount of IPv4 Transfers between organizations has increased reasonably as shown by the official LACNIC reports. With the implementation of LAC-2019-1 and possibility of Inter-RIR transfers these numbers have the potential to grow substantially.
The objective of this proposal is to add as a requirement for organizations in process of receiving transferred IPv4 space under 2.3.2.18 to show they have an IPv6 allocation/assignment by LACNIC or a provider and that is operational on their networks. Such organization must be able to prove this IPv6 space is being used by providing LACNIC the documented network deployment details to prove IPv6 is operational in significant parts of the network.
On 28th November 2019 LACNIC Board issued a statement (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment) reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space will be exhausted by mid-2020 and calling the community to promote IPv6 deployment.
In its statement LACNIC Board “invite the community to work on promoting the development of policies that will accelerate the effective deployment of IPv6 above other policies that may be discussed at a later date.”
In the case the receiver provides a written statement from its upstream that IPv6 connectivity is unavailable, the IPv6 requirement may be waived. In the case LACNIC is not able to meet a new entrant request for IPv4 space the IPv6 requirement may be waived for a transfer up to a /22.
Rationale (Describe the problem you intend to solve)While it is completely understandable the need of organizations for more IPv4 space in order to cope with customers needs for reaching IPv4-only services or to make services available to IPv4-only end-users and despite the IPv4 exhaustion phase, there is a policy in place to allow them to receive more IPv4 space from other organizations who don’t have a need for it anymore, it is necessary that these organizations show commitment to all others by having IPv6 operational on their networks.
The lack of this commitment from those who are receiving more and more IPv4 space aggravates the problem of interconnecting with others which are all part of the same RIR community and ecosystem, therefore it is not just a private situation.
Interoperability has always been a key factor for smooth operation of all Internet ecosystem so having IPv6 operational for growing organizations is a natural move to keep this interoperability in a fast growing Internet scenario.
This proposal does not impose any measures to organizations who do not wish to have IPv6 operational in the case they don’t require receive further IPv4 space respecting their autonomy.
This proposal also meets LACNIC Board call for promoting policies that will accelerate the effective deployment of IPv6.
It’s important to note that the RIR community has the right to establish policies and administer the registry in accordance to these consensual policies. What this proposal does is to add an extra requirement for organizations receiving transferred IPv4 space.
Therefore, it has come the time for LACNIC to require organizations receiving transferred IPv4 space to have an IPv6 operational network.
Current text2.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 ofthe 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 one year 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.
New text2.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 Receiving organization in LACNIC must have LACNIC or provider allocated/assigned IPv6 space and be able to prove it is being used by providing LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network.
LACNIC staff will define a minimal criterion to guarantee the information provided proves IPv6 is operational. If necessary staff may require further information to validate this requirement.
In the case the receiver provides a written statement from its upstream(s) that IPv6 connectivity is unavailable, and justification that other means aren't technically acceptable, the IPv6 requirement may be waived.
If LACNIC is not able to meet a request using the reserved pool under 11.1 conditions the requesting organization will be permitted to transfer an IPv4 space equivalent of maximum of /22 and the IPv6 requirement may be waived. In the case the organization is on any LACNIC waiting list for IPv4 resources it shall be removed from it upon successful transfer.
2.3.2.18.4. 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.5. 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.6. 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.7. Addresses that have previously been transferred may not subsequently be transferred again (in full or in part) for a period of one year as ofthe transaction date specified in the transfer log.
2.3.2.18.8. 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.9. 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.10. Addresses from allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of one year as of the allocation or assignment date.
2.3.2.18.11. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
Additional informationOther than showing it has LACNIC or provider allocated/assigned IPv6 space operational, the organization must provide LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network which will be analysed by LACNIC staff as a prove of justification.
Timetable-
ReferencesA similar proposal has been presented in ARIN:
• https://www.arin.net/participate/policy/drafts/2019_19/
Work is been done in regards to this proposal in other RIRs to present equivalent proposals there.
Presented at:-
On 15th February 2017 LACNIC started IPv4 Exhaustion Phase 3 meaning only new entrants can receive up to a single /22 of IPv4 space. Since then the amount of IPv4 Transfers between organizations has increased reasonably as shown by the official LACNIC reports. With the implementation of LAC-2019-1 and possibility of Inter-RIR transfers these numbers have the potential to grow substantially.
The objective of this proposal is to add as a requirement for organizations in process of receiving transferred IPv4 space under 2.3.2.18 to show they have an IPv6 allocation/assignment by LACNIC or a provider and that is operational on their networks. Such organization must be able to prove this IPv6 space is being used by providing LACNIC the documented network deployment details to prove IPv6 is operational in significant parts of the network.
On 28th November 2019 LACNIC Board issued a statement (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment) reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space will be exhausted by mid-2020 and calling the community to promote IPv6 deployment.
In its statement LACNIC Board “invite the community to work on promoting the development of policies that will accelerate the effective deployment of IPv6 above other policies that may be discussed at a later date.”
In the case the receiver provides a written statement from its upstream that IPv6 connectivity is unavailable, the IPv6 requirement may be waived. In the case LACNIC is not able to meet a new entrant request for IPv4 space the IPv6 requirement may be waived for a transfer up to a /22.
Rationale (Describe the problem you intend to solve)While it is completely understandable the need of organizations for more IPv4 space in order to cope with customers needs for reaching IPv4-only services or to make services available to IPv4-only end-users and despite the IPv4 exhaustion phase, there is a policy in place to allow them to receive more IPv4 space from other organizations who don’t have a need for it anymore, it is necessary that these organizations show commitment to all others by having IPv6 operational on their networks.
The lack of this commitment from those who are receiving more and more IPv4 space aggravates the problem of interconnecting with others which are all part of the same RIR community and ecosystem, therefore it is not just a private situation.
Interoperability has always been a key factor for smooth operation of all Internet ecosystem so having IPv6 operational for growing organizations is a natural move to keep this interoperability in a fast growing Internet scenario.
This proposal does not impose any measures to organizations who do not wish to have IPv6 operational in the case they don’t require receive further IPv4 space respecting their autonomy.
This proposal also meets LACNIC Board call for promoting policies that will accelerate the effective deployment of IPv6.
It’s important to note that the RIR community has the right to establish policies and administer the registry in accordance to these consensual policies. What this proposal does is to add an extra requirement for organizations receiving transferred IPv4 space.
Therefore, it has come the time for LACNIC to require organizations receiving transferred IPv4 space to have an IPv6 operational network.
Current text2.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 ofthe 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 one year 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.
New text2.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 Receiving organization in LACNIC must have LACNIC or provider allocated/assigned IPv6 space and be able to prove it is being used by providing LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network.
LACNIC staff will define a minimal criterion to guarantee the information provided proves IPv6 is operational. If necessary staff may require further information to validate this requirement.
In the case the receiver provides a written statement from its upstream(s) that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
If LACNIC is not able to meet a request using the reserved pool under 11.1 conditions the requesting organization will be permitted to transfer an IPv4 space equivalent of maximum of /22 and the IPv6 requirement may be waived.
2.3.2.18.4. 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.5. 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.6. 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.7. Addresses that have previously been transferred may not subsequently be transferred again (in full or in part) for a period of one year as ofthe transaction date specified in the transfer log.
2.3.2.18.8. 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.9. 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.10. Addresses from allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of one year as of the allocation or assignment date.
2.3.2.18.11. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
Additional informationOther than showing it has LACNIC or provider allocated/assigned IPv6 space operational, the organization must provide LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network which will be analysed by LACNIC staff as a prove of justification.
Timetable-
ReferencesA similar proposal has been presented in ARIN:
• https://www.arin.net/participate/policy/drafts/2019_19/
Work is been done in regards to this proposal in other RIRs to present equivalent proposals there.
Presented at:LACNIC 33 y 1/3 (20/08/2020)
On 15th February 2017 LACNIC started IPv4 Exhaustion Phase 3 meaning only new entrants can receive up to a single /22 of IPv4 space. Since then the amount of IPv4 Transfers between organizations has increased reasonably as shown by the official LACNIC reports. With the implementation of LAC-2019-1 and possibility of Inter-RIR transfers these numbers have the potential to grow substantially.
The objective of this proposal is to add as a requirement for organizations in process of receiving transferred IPv4 space under 2.3.2.18 to show they have an IPv6 allocation/assignment by LACNIC or a provider and that is operational on their networks. Such organization must be able to prove this IPv6 space is being used by providing LACNIC the documented network deployment details to prove IPv6 is operational in significant parts of the network.
On 28th November 2019 LACNIC Board issued a statement (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment) reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space will be exhausted by mid-2020 and calling the community to promote IPv6 deployment.
In its statement LACNIC Board “invite the community to work on promoting the development of policies that will accelerate the effective deployment of IPv6 above other policies that may be discussed at a later date.”
In the case the receiver provides a written statement from its upstream that IPv6 connectivity is unavailable, the IPv6 requirement may be waived. In the case LACNIC is not able to meet a new entrant request for IPv4 space, or the organization does not hold any IPv4 space the IPv6 requirement may be waived for a transfer up to a /22.
Rationale (Describe the problem you intend to solve)While it is completely understandable the need of organizations for more IPv4 space in order to cope with customers' needs for reaching IPv4-only services or to make services available to IPv4-only end-users and despite the IPv4 exhaustion phase, there is a policy in place to allow them to receive more IPv4 space from other organizations which don’t have a need for it anymore, it is necessary that these organizations show commitment to all others by having IPv6 operational on their networks.
The lack of this commitment from those who are receiving more and more IPv4 space aggravates the problem of interconnecting with others which are all part of the same RIR community and ecosystem, therefore it is not just a private situation.
Interoperability has always been a key factor for smooth operation of all Internet ecosystem so having IPv6 operational for growing organizations is a natural move to keep this interoperability in a fast growing Internet scenario.
This proposal does not impose any measures to organizations who do not wish to have IPv6 operational in the case they don’t require receive further IPv4 space respecting their autonomy.
This proposal also meets LACNIC Board call for promoting policies that will accelerate the effective deployment of IPv6.
It’s important to note that the RIR community has the right to establish policies and administer the registry in accordance to these consensual policies. What this proposal does is to add an extra requirement for organizations receiving transferred IPv4 space.
Therefore, it has come the time for LACNIC to require organizations receiving transferred IPv4 space to have an IPv6 operational network.
Current text2.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 ofthe 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 one year 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.
New text2.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 Receiving organization in LACNIC must have LACNIC or provider allocated/assigned IPv6 space and be able to prove it is being used by providing LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network.
LACNIC staff will define a minimal criterion to guarantee the information provided proves IPv6 is operational. If necessary staff may require further information to validate this requirement.
In the case the receiver provides a written statement from its upstream(s) that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
If LACNIC is not able to meet a request using the reserved pool under 11.1 conditions, or the organization does not hold any IPv4 space the requesting organization will be permitted to transfer an IPv4 space equivalent of maximum of /22 and the IPv6 requirement may be waived.
2.3.2.18.4. 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.5. 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.6. 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.7. Addresses that have previously been transferred may not subsequently be transferred again (in full or in part) for a period of one year as ofthe transaction date specified in the transfer log.
2.3.2.18.8. 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.9. 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.10. Addresses from allocations or assignments from LACNIC, whether initial or additional, may not be transferred (in full or in part) for a period of one year as of the allocation or assignment date.
2.3.2.18.11. Legacy resources transferred into the LACNIC region will no longer be considered legacy resources.
Additional informationOther than showing it has LACNIC or provider allocated/assigned IPv6 space operational, the organization must provide LACNIC documented network deployment details to prove IPv6 is operational in significant parts of the network which will be analysed by LACNIC staff as a prove of justification.
The term “significant parts of the network” refers to the segments of the network which are responsible for delivering IPv6 connectivity to the end-user or a downstream and not only to core or border equipment which do not have a direct relationship in providing IPv6 connectivity to end-user or downstream.
Timetable-
ReferencesA similar proposal has been presented in ARIN:
• https://www.arin.net/participate/policy/drafts/2019_19/
Work is been done in regards to this proposal in other RIRs to present equivalent proposals there.
Presented at:LACNIC35 (11/05/2021)