[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1

Mon Apr 12 13:28:20 -03 2021

Hola a todos, 

He seguido esta discusión desde hace varios días, y aun me queda una duda, quizá porque no ha sido abordada a fondo:

Cómo exactamente la transferencia de numeración IPv4 ya existente podría requerir que las organizaciones tengan que hacer inversiones significativas (CGNAT) para tener que acceder a estos recursos, que se están moviendo de un lado a otro? 

Creo (y por favor corrígeme si estoy equivocado) que el uso creciente de CGNAT no responde directamente, o al menos no en la misma proporción, a la aparición de nuevos servicios en IPv4, sino que al crecimiento de los usuarios de cada uno de los AS y la reutilización de los bloques IPv4 que tienen asignados.

Creo que en el futuro la formula que hará que el vaso rebalse será el aumento de usuarios + mantener vivo IPv4, pero no visualizo como el ingrediente de las transferencias IPv4 haga que este problema se agudice.

Entiendo perfectamente los beneficios de la adopción de IPv6, los problemas que involucra mantener "vivo" IPv4, pero creo que hay una barrera que debo no se debiese cruzar que es la ceder parte de la autonomía que tienen los AS de continuar un camino u otro.

Apoyo totalmente las iniciativas del tipo promoción, workshops técnicos, y colaboración en general para alcanzar la meta, pero estoy totalmente en contra de medidas que coarten las deciciones internas de un AS.

Ya que @Jordi mencionó el ejemplo de los autos y las emisiones de Co2, tengan en cuenta que las medidas han sido graduales, buscando desincentivar el uso de vehiculos contaminantes, pero no prohibiendo que pueda comprar un auto a gasolina usado...

Basado en la idea que mencionó @Gondim, quizá esto podría derivar en una propuesta con incentivos para quienes necesiten transferir un nuevo bloque IPv4 y que estén operando con IPv6; Quizá quienes tengan IPv6 operativo puedan optar a transferir un bloque más grande que quienes no, o definir una periodo de espera entre transferencia de bloques, o medidas de ese tipo, donde por un lado se incentiva a quienes tiene IPv6 y estén solicindo IPv4 para traduccion, y por otro lado desincentivar el uso de IPv4 de forma mas gradual. (Pero sin llegar a negarlo por no tener IPv6!)

Saludos!

Miguel Brante

----- Mensaje original -----
De: "Fernando Frediani" <fhfrediani at gmail.com>
Para: "Lista para discusion de politicas de la comunidad de LACNIC" <politicas at lacnic.net>
Enviados: Miércoles, 7 de Abril 2021 20:38:46
Asunto: Re: [LACNIC/Politicas]  Nueva versión de la propuesta LAC-2020-1

Hola

Como se mencionó muchas veces durante esta discusión, el temor de que 
alguien realice una transferencia fuera del sistema es una violación 
de 
las reglas y debe ser sancionado de acuerdo con las mismas reglas, a 
menos que alguien argumente que no se debe sancionar a alguien que hace 
una transferencia fuera del sistema. El sistema RIR y las reglas que la 
propia organización acordó seguir. Una propuesta cuando sea necesaria es 
necesaria independientemente de los miedos que puedan existir. Lo 
importante para solucionar este punto es que existen herramientas 
legales y administrativas para resolver los casos de quienes quieren 
luchar contra el sistema y las reglas que ellos mismos acordaron.

Esto no es una "presión artificial", sino un **requisito* *justo** para 
todos los demás que se vean afectados por esa transferencia de IPv4 
**sin la contraparte para con todos los demás*.*

Es normal tener un requisito para la justificación y recepción de 
direcciones IPv4, IPv6 y ASN, así como para transferencias. Este extra 
que se propone no es demasiado o algo que imposibilita las transferencias.
Al final, el punto a tener en cuenta es que si alguien no puede 
demostrar el funcionamiento de IPv6, no le conviene a la comunidad 
afectada permitir que se realice una transferencia de IPv4 hasta que 
pueda comprometerse con todos los involucrados. Reforzando una vez más: 
este es el espíritu de la propuesta.

Como dijo Henri en su respuesta, *no hay más excusas para no poder 
probar IPv6 operativo*. Si alguien a mediados de 2021 no puede, entonces 
hay algo muy mal y si hay algo mal hay que corregirlo y esta propuesta 
viene para ayudar eso.

Fernando Frediani

On 07/04/2021 10:50, Miguel A. Brante wrote:
> Hola a todos,
>
>
> Entiendo y hasta apoyo el fondo de esta propuesta, sin embargo no comparto en lo absoluto la forma.
>
> El poner una presión artificial para la adopción de IPv6 para 
quienes tengan la urgencia de recibir recursos IPv4, tendrá como resultado que se hagan transacciones en el mercado externo y quizá fuera
> de los marcos regulatorios del RIR.
> En el mejor de los casos podría provocar implementaciones apuradas, pobres o disfuncionales con el fin de cumplir un mero requisito. Al final
> del día, LACNIC no va a tener ni la capacidad ni la potestad de auditar la implementación que he puesto en el papel.
>
> Veo mucho más positivo fomentar la adopción de IPv6 mediante argumentos y no mediante barreras y/u obligaciones que a mi parecer no harán un cambio significativo.
>
> Saludos
>
> Miguel Brante
>
>
> ----- Mensaje original -----
> De:info-politicas at lacnic.net
> Para: "Lista para discusion de politicas de la comunidad de LACNIC"<politicas at lacnic.net>
> Enviados: Miércoles, 31 de Marzo 2021 11:37:37
> Asunto: [LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
>
> [Português abaixo]
> [English below]
>
> Estimados suscriptores de la lista de políticas de LACNIC,
>
> La propuesta LAC-2020-1 ha pasado de la versión 3 a la versión 4
>
> Título: Agregar IPv6 operativo como requisito para las transferencias de IPv4
>
> Resumen: 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.
>
> Para ver el detalle ingrese en:
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
>
> Los cambios respecto a la versión anterior se pueden visualizar aquí:
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=SP
>
> Los comentarios y los puntos de vista aportados por la comunidad son vitales para el correcto desarrollo del proceso de la propuestas
> - ¿Apoya usted o se opone a esta nueva versión de la propuesta?
> - ¿Ve alguna desventaja en esta nueva versión de la propuesta?
> - ¿Qué cambios podrían hacerse a esta nueva versión 
de la propuesta para que sea más eficaz?
>
>
> Por más información contacte ainfo-politicas at lacnic.net
> Saludos cordiales,
> ______________________________________________________________________________________________________
> Prezados assinantes da lista de políticas de LACNIC,
>
> A proposta LAC-2020-1 tem passado da versão 3 para a versão 4
>
> Título: Adicionar IPv6 operacional como requisito para as transferências do IPv4
>
> Resumo: 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.
>
> Para ver o detalhe acesse:
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/pt
>
> As alterações da versão anterior podem ser vistas aqui:
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=PT
>
>   Os comentários e os pontos de vista aportados pela comunidade são
> vitais para o bom desenvolvimento do processo das propostas
> - Você está a favor ou em contra desta nova versão
>   da proposta?- Vê alguma desvantagem nesta nova versão
>   da proposta?
>
> - Que mudanças poderiam ser feitas à esta nova versão
>   da proposta para que seja mais eficaz?
>
> Por mais informações entre em contato conosco através do 
e-mail:
> info-politicas at lacnic.net.
>
> Atenciosamente,
> ______________________________________________________________________________________________________
>
> Dear LACNIC Policy List subscribers,
>
> Proposal LAC-2020-1 has been updated from version 3 to version 4
>
> Title: Add IPv6 operational as a requirement for IPv4 transfers
>
> 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, or the organization does not hold any IPv4 space the IPv6 requirement
> may be waived for a transfer up to a /22.
>
> To see the details, please click on:
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/en
>
> The changes from the previous version can be seen here:
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=EN
>
> The community's comments and opinions are essential to the proper functioning of the policy development process.
> - Do you support this new version of the proposal or are you against it?
> - Do you think this new version of the proposal has any drawbacks?
> - What changes could be made to this new version of the proposal to make it more effective?
>
> For further information, please contactinfo-politicas at lacnic.net
> Kind regards,
> --
> LACNIC - Registro de Direcciones de Internet para América Latina y 
Caribe
> Rambla Rep. de México 6125, CP 11400
>
> Montevideo-Uruguay
>
> Teléfono: +598 2604 22 22
> www.lacnic.net
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas