[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1 - Versión 4
Mike Burns
mike at iptrading.com
Wed Apr 7 12:07:57 -03 2021
Hi Jordi,
Thanks for your comments.
We brokered the first LACNIC inter-regional transfer last summer, greasing the machinery, but the transfers in the first quarter of this year show the machinery is still sputtering.
I understand your desire to see IPv6 become the dominant standard but there is no evidence that this proposal will accomplish that.
Isn't it more likely to further diminish the transfers which the community intended to happen when 2.3.2.18 was passed?
If this was a thriving market that could handle a minor restriction in support of the IPv6 goal, then this proposal might be more worthy of consideration.
Maybe you should propose this at ARIN or RIPE first.
As it is, it's like putting handcuffs on a baby.
We should use data to decide the balance between IPv6 transition and IPv4 market function.
I have demonstrated some data showing very poor market function in LACNIC compared to other regions.
Likewise I can point to the data in those regions showing a thriving IPv4 transfer market, and in those regions the IPv6 transition hasn't suffered.
I challenge you to demonstrate any data that supports the contention that this policy will further IPv6 transition.
Thanks for your comments regarding the retention of language permitting LACNIC to revoke unused address space in the Registration Agreement.
I understand this thread is not for discussion of this topic and this will be my last comment here.
I hope everybody understands how this language is not compatible with a transfer market, but I will try once more to make it clear.
For a market to succeed, there must be buyers and sellers, and a registry who can authoritatively record the transfer.
Only in LACNIC's case does the authoritative recorder of transfers also have the right to revoke unused addresses under the Registration Agreement.
So sellers are asked to approach LACNIC to sell their unused addresses, but they have to hide this fact from LACNIC during the transfer process.
Everybody realizes that during a transfer, addresses are unused for some duration. They have to be, really for many reasons.
So every LACNIC seller realizes they are putting their valuable asset at risk by engaging LACNIC in the transfer process.
The outcome is poor market performance and a slow transfer process hindered by mistrust.
Nobody can really answer the facts that show the LACNIC transfer market is exceedingly small compared to other registries.
This proposal will certainly add further difficulties for transfer participants and sow more distrust between those participants and LACNIC as fake IPv6 networks are engineered.
In my opinion as a longtime market participant, the outcome will be fewer transfers than otherwise and a less vital Internet ecosystem in the region.
I am opposed to the policy.
Regards,
Mike
-----Original Message-----
From: Politicas <politicas-bounces at lacnic.net> On Behalf Of JORDI PALET MARTINEZ via Politicas
Sent: Wednesday, April 07, 2021 4:42 AM
To: 'Lista para discusion de politicas de la comunidad de LACNIC' <politicas at lacnic.net>
Cc: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
Subject: Re: [LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1 - Versión 4
Hi Mike,
I tried to find the Spanish version of the proposal to make sure about what we are talking about, because in this region, that version is the one that matters, but is not there.
I don't have any doubt that the text in the justification can be improved. At the end the perception of what is an increase, even if you look at your figures, it may be subjective. Remember that we only have inter-RIR transfers for a few months, that all that takes time to "grease" the machinery. Thinks don't happen magically overnight.
The proposal is not impacting those that deploy IPv6 and clearly it helps to that by ensuring "if you want to receive a transfer - in the region - you must really be deploying IPv6".
There is no sense in that the IPv4 addresses available are being used by folks that do not deploy IPv6, because that is contrary to the overall good of the community. To me is clear that IPv4 addresses, being a scarce resource, must be used for the good of the overall community, and that allows the community to set up priorities, about *who* will be getting them.
Exactly *the same* as the community has already defined certain other aspects about who, how and under what conditions, those transfers can be done.
If we allow those transfers, without enforcing IPv6 deployment, then we are encouraging or allowing more CGN, not in the other way around. We are ensuring that who needs IPv4 addresses, need to seriously consider "do I really need them, or all them if I also do my IPv6 deployment which anyway I will need to do?".
I agree with your point about the RSA. I understand that it is a complex topic, being a legal document. May be the staff want to comment on that. Anyway, it may be interpreted, from a legal perspective, that by having a transfer's policy, that the policy supersedes any RSA inconsistencies.
Regards,
Jordi
@jordipalet
El 6/4/21 21:55, "Mike Burns" <mike at iptrading.com> escribió:
"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"
Hi Jordi,
LACNIC transfers by year (rough count):
2017 12
2018 23
2019 53
2020 58
2021Q1 13, or 52 annualized.
These are mostly small blocks. Nothing larger than a /18 in more than four years!
The numbers do not bear out the language in the summary statement. In fact there *is* a problem with LACNIC IPv4 transfers-there are far too few of them. Instead of erecting further barriers to IPv4 transfers, the community should address the dramatic lack of LACNIC transfers compared to the other trading registries. What LACNIC did in 5 years, RIPE does in a month. Every month. The LACNIC market is no longer new, and has had time to mature. And yet it has not, and rather than address that problem[1], this proposal seeks to further stifle the market.
Look again at those numbers. Do they seem like they could be slowing IPv6 progress in the region? A few hundred transfers in five years? That's the whole point of this proposal, that somehow adding further requirements to the limping IPv4 market will magically increase IPv6 in the region. The data does not support the problem stated nor the solution expected.
The community passed a transfer policy because it realized transfers were the best way forward in a near- and post-exhaust world. The failure of LACNIC's transfer policy to result in a reasonable number of transfers is to nobody's benefit. It stifles organic growth of the Internet, it leads to more CGNAT and less efficient use as blocks remain on the shelf. It leads to more opaque Whois information through leasing and non-policy transfers, and it generally slows progress and tends to ossify the region, which to my mind is the opposite of what is required to transition to IPv6. Regions with better IPv6 penetration engage in many more transfers, how does the logic of this proposal answer that?
Regards,
Mike Burns
[1] The language in LACNIC's RSA giving LACNIC the right to revoke for lack of utilization was removed from every other RIR's RSA when they began allowing IPv4 to be sold, because it is plainly incompatible with a market. To relieve sellers of their fear of LACNIC, this language must be removed otherwise every potential seller must reveal to LACNIC that they are not using addresses, and thus they are contractually forfeitable. Would you sell your most valuable asset if it meant exposing it to the entity which has the legal right to take it back if you aren't using it? What is the point of retaining that language at LACNIC and not ARIN, RIPE, or APNIC?
-----Original Message-----
From: Politicas <politicas-bounces at lacnic.net> On Behalf Of JORDI PALET MARTINEZ via Politicas
Sent: Tuesday, April 06, 2021 2:48 PM
To: Lista para discusion de politicas de la comunidad de LACNIC <politicas at lacnic.net>
Cc: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
Subject: Re: [LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1 - Versión 4
Hola a todos,
Una vez mas, de acuerdo con esta propuesta.
Creo que es una iniciativa muy buena e importante, y que espero que pronto llegue al resto de los RIRs.
Cada vez está mas cerca el momento en que sea imprescindible proteger a los ciudadanos, y por tanto a la comunidad y sus recursos, y desde las políticas lo podemos hacer. No sería bueno, lo que sin duda llegará si no actuamos desde las políticas, que sea por intervención de gobiernos.
Esta propuesta va en el camino adecuado. Ya lo estaba la versión anterior, y creo que arbitrariamente se determinó que no había alcanzado consenso sin exponer con claridad objeciones válidas.
Mas pronto que tarde, tenemos que actuar y evitar que se usen los recursos IPv4, y concretamente las transferencias, para evitar el despliegue de IPv6 y prolongar de forma innecesaria y dañina la vida de IPv4. Acaso preferimos, como digo, que sean los gobiernos los que lo impongan, sin conocimiento técnicos como a menudo hacen, sin plazos adecuados, etc.?
Saludos,
Jordi
@jordipalet
El 31/3/21 16:48, "Politicas en nombre de Fernando Frediani" <politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com> escribió:
Hola a todos
Tras la discusión de esta nueva versión de esta propuesta y con
el fin
de llegar a un consenso, a continuación aclaro algunos puntos sobre la
nueva versión y también el último mensaje de los Moderadores sobre las
razones por las que esta propuesta no llegó a un consenso.
- Repito que esta propuesta NO obliga automáticamente a ninguna
organización a desplegar IPv6 si no lo desean, solo y solo si necesitan
transferir bloques de IPv4
- Sin embargo, si existe interés en transferir bloques IPv4 en el
sistema de registro de LACNIC, este ya no es un tema que sea solo
interno de la organización, sino que afecta a todas las demás
organizaciones que forman parte del ecosistema de LACNIC donde se deben
desarrollar políticas con miras al interés y beneficio de la mayoría, no
solo de unos pocos.
- La mayoría de los interesados no pueden seguir indiferentes a algo
que afecta y agrava aún más el problema de escasez de direcciones IPv4,
por lo que la *intención y espíritu* de esta propuesta sigue siendo
tener un requisito obligatorio para demostrar que IPv6 esta operativo
para realizar transferencias IPv4. Este es un requisito muy razonable
para 2021 y, si no se controla, continuará agravando el problema para la
mayoría de las organizaciones que se conectan o desean ser parte del
ecosistema de Internet.
- Respecto al análisis de impacto comentar que este requisito podría ser
un obstáculo para algunas organizaciones, la afirmación es correcta y no
hay nada de malo en querer agregar esta restricción dado el contexto
actual. Algunos "obstáculos" son totalmente razonables para que haya
equilibrio y equidad entre todas las organizaciones. ¿No es razonable
pedirle a cualquier organización que demuestre la necesidad de utilizar
bloques IPv4? ¿Por qué no le pediría también que demuestre su compromiso
con todos los demás con IPv6 operativo cuando es necesario transferir
más bloques de IPv4?
- El argumento de que las organizaciones pueden realizar transferencias
fuera del sistema de registro de LACNIC se utiliza con bastante
frecuencia como motivo para oponerse a una propuesta, pero se mencionó
varias veces durante la discusión que no se puede seguir siendo un
motivo tan general para oponerse a ella porque el registro ha sus
políticas vigentes, contratos previamente aceptados y reconocidos en
el
ordenamiento jurídico y sanciones para quienes incumplan. Ninguna
propuesta de política puede dejar de seguir adelante en función
de la
posibilidad de que se incumpla. Existen mecanismos de corrección para
esto. Lo más importante a tener en cuenta es su necesidad.
- Ninguna parte del PDP obliga a los autores a desarrollar políticas
con
la intención de educar al usuario (organización), por lo que no
creo que
este pueda ser un argumento para ser utilizado como objeción a una
propuesta. Propuesta cuando sea necesario, no depende de las acciones
contenidas o no en el sentido de educación del usuario. Si hay una
necesidad y hay un consenso, la parte de educación se deja a otros
actores involucrados.
Creo que LACNIC y sus RIR ya están realizando un trabajo educativo sobre
la necesidad de implementar IPv6, lo cual es muy elogiado.
Entonces, entiendo que esta justificación parece más un deseo personal
de los moderadores.
- No es cierto que "/según LACNIC sería contraproducente para el
registro de transferencia IPv4/". En ninguna parte del análisis de
impacto se dice nada al respecto. Simplemente dice que puede significar
un obstáculo para algunas organizaciones, como se explicó anteriormente,
que *no hay problema en crear restricciones razonables* a las
justificaciones para el uso de recursos.
Respecto a los cambios en esta versión de la propuesta:
- El staff menciona que entendió que existe una inconsistencia entre
el
resumen y la redacción de la propuesta. Aclaro que puede deberse a algún
error en la traducción porque nunca hubo la intención de limitar las
transferencias a /22.
Solo existe el buen sentido de eliminar este requisito solo para una
nueva organización que *aún no tiene bloques IPv4* y quiere transferir
un bloque inicial hasta el límite de un /22para iniciar sus operaciones.
En el resumen de la propuesta se deja claro que la excepción de una
transferencia hasta a /22 es solo para el caso de *nuevos entrantes*
exactamente en línea con el agotamiento de la fase 3 de LACNIC. Además,
la mención del pool reservado en las condiciones 11.1 está directamente
relacionada solo con los nuevos participantes.
De todos modos, ajusté el texto para que quede aún más claro que solo
aplican aquellos que no tienen asignaciones de IPv4.
-En cuanto al término "significativas" mencionado, aclaro que como la
propuesta define que le corresponde al staff de LACNIC definir los
requisitos mínimos, no es la intención de este autor complicar demasiado
el texto de la propuesta, definiendo de forma detallada lo que es
significativo o no, sino al staff según el contexto que cambia con el
tiempo. Aclaro aquí que desde mi punto de vista en este contexto
"significativas" se relaciona con las partes principales de la red que
serán responsables de entregar conectividad IPv6 al usuario
final/downstream y no solo en equipos de red centrales que no tienen una
relación directa con la entrega de una conexión IPv6 a un usuario
final/downstream, de modo que el tráfico es de fin a fin hasta el
contenido disponible en IPv6.
Se agregó una aclaración en la parte de información adicional
relacionada con este asunto.
- Finalmente, se aclara que las modificaciones para esta versión no
alteran la reciprocidad mencionada en el punto 5 del análisis de impacto
anterior, refiriéndose a la reciprocidad ya confirmada con ARIN.
Saludos cordiales.
Fernando Frediani
On 31/03/2021 11:37, info-politicas at lacnic.net wrote:
> [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 a info-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 contact info-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
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list