LAC-2020-1: Add IPv6 operational as a requirement for IPv4 transfers

General Information

English
05/08/2020
Under discussion
29 %. The next step will depend on moderator's decision.

Fernando Frediani - Version [1, 2, 3]
Initial discussion
06/08/2020 - 01/10/2020
First consensus
01/10/2020 - 15/10/2020

Public Comments by LACNIC Staff for this version

Interpretación de la propuesta por el staff de LACNIC

Aplicación de la propuesta
Esta propuesta se aplicaría en las transferencias 2.3.2.18 de direcciones IPv4.

Modificación del texto actual
La propuesta agrega un nuevo requisito al proceso de transferencias de bloques IPv4, tal como se describe en el punto: “2.3.2.18. Transferencias de direcciones IPv4”

Los destinatarios en la región de LACNIC deberán tener espacio IPv6 distribuido/asignado por LACNIC o por un proveedor y deberán poder probar que este espacio está en uso, para lo cual deberán proporcionarle a LACNIC los detalles documentados del despliegue de la red para demostrar que IPv6 está operativo en partes significativas de la red.

El personal de LACNIC definirá un criterio mínimo para garantizar que la información proporcionada demuestre que IPv6 está operativo. De ser necesario, el personal puede requerir más información para validar este requisito.

En el caso de que el receptor proporcione una declaración por escrito de su(s) proveedor(es) de tránsito IP que confirme que no hay conectividad IPv6 disponible, se podrá obviar el requisito sobre IPv6.

Si LACNIC no puede atender una solicitud utilizando la reserva de direcciones de acuerdo con la Sección 11.1, la organización solicitante podrá transferir un espacio IPv4 equivalente, como máximo, a un /22 y se podrá obviar el requisito sobre IPv6.

Comentarios del staff:
(Los comentarios son observaciones para ayudar a diferenciar los cambios que presenta la propuesta con respecto al texto actual del Manual de Políticas)

1. Identificamos una inconsistencia entre la justificación incluida en el resumen y la redacción de la propuesta. De la propuesta se interpreta que a partir de ahora todas las transferencias se van a limitar a un máximo de /22 y será para éstas que se podrá obviar el requisito de IPv6 operativo en el receptor. Creemos que es un error de traducción de estas dos sentencias (ver recomendaciones)
Por lo tanto, en caso de que la redacción actual sea aprobada por la comunidad, LACNIC interpreta que no vamos a limitar las transferencias INTRA-RIR e INTER-RIR a un /22 inclusive. Adicionalmente para transferencias de hasta un /22 inclusive no exigiriamos cumplir el requisito de IPv6 operativo para el receptor cuando éste pertenezca a la región de LACNIC.
2. La propuesta agrega un requisito para realizar una transferencia IPv4, que el receptor del recurso tenga espacio IPv6 asignado por LACNIC o por el proveedor y demostrar que ese espacio está operativo.

3. Este requisito podría significar un obstáculo para algunas organizaciones que quieran realizar transferencias, ocasionando que las realicen de todas formas por fuera del registro de LACNIC. Cualquier requisito que establezca una carga adicional a las transferencias tiene el potencial riesgo de impactar en la calidad de la información en LACNIC como registro.
4. LACNIC definirá los criterios para la justificación de operabilidad de los recursos IPv6
5. Tanto nosotros como el staff de ARIN entendemos que esta propuesta no afectará las transferencias salientes de LACNIC hacia ARIN, es decir no se exigirá al receptor en ARIN que cumpla con este requisito.
6. Esta propuesta genera un desequilibrio en los requisitos que se deben atender por las entidades de la región para transferencias de recursos IPv4.
Se establece una carga adicional al receptor dentro de la región al exigirle IPv6 operativo para poder recibir la transferencia. Este obstáculo afecta las transferencias incluso entre organizaciones de nuestra misma región.
7. La propuesta modifica respecto a la versión anterior:
a. Se dirige a la organización que recibe la transferencia de direcciones IPv4 como “receptor”, en vez de “destinatario”.
b. Considera que la organización receptora puede tener más de un proveedor de tránsito IP, en cuyo caso la propuesta exige que el requisito de la declaración de no disponibilidad de IPv6 sea para todos los proveedores de tránsito de la organización que solicita la transferencia.
c. Quita lo referido a la lista de espera de direcciones IPv4: Si la organización se encuentra en cualquiera de las listas de espera de LACNIC para recursos IPv4, una vez que se realice con éxito la transferencia la organización será eliminada de dicha dicha lista.

Recomendaciones

1. Recomendamos que el autor modifique el último párrafo de la propuesta para que refleje lo que dice en el resumen.
2. Para que esa política tenga efecto en la comunidad global tendría que presentarse como una propuesta de política global de tal manera que no genere desequilibrios a las regiones que sí quieren adoptarla.
3. Aclarar el término “significativas” en el texto: “partes significativas de la red”.
4. En caso de existir una nueva versión de esta propuesta, asegurarse que la redacción no genere un desequilibrio en relación a la bidireccionalidad de los recursos debido a la condición mencionada en el punto 5 de los comentarios.

Fuentes oficiales de referencias
----------------------------------------------
Otros RIRs
AFRINIC
Actualmente discutiendo las siguientes políticas similares:
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 tiene una política similar.

ARIN
Se presentó una propuesta similar y fue abandonada.
https://www.arin.net/participate/policy/drafts/2019_19

RIPE
No tiene una política similar.

Impacto en el sistema de registro
--------------------------------------------
Esta propuesta tiene un impacto significativo en el proceso de análisis de transferencias.


Summary

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

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 Text

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.

New Text
Analyze Diff

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 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 Information

Other 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

-

References

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.


Summary

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

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 Text

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.

New Text
Analyze Diff

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, 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 Information

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.

Timetable

-

References

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.


Summary

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

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 Text

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.

New Text
Analyze Diff

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 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 Information

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.

Timetable

-

References

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.