Name: Fernando Frediani
Email: fhfrediani@gmail.com
Organization: -
Name: Fernando Frediani
Email: fhfrediani@gmail.com
Organization: -
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 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.
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.”
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.
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.
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 whoich 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.
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. 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.
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 - 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.
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. 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. 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.
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).
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 - 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.
Other 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.
Other 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.
A similar proposal has been presented in ARIN: Work is been done in regards to this proposal in other RIRs to present equivalent proposals there.
• https://www.arin.net/participate/policy/drafts/2019_19/
A 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.