[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
Fernando Frediani
fhfrediani at gmail.com
Fri Apr 9 10:56:15 -03 2021
Gracias Gondim y Jordi por los mensajes. Creo que fueron lo
suficientemente didácticos y con analogías muy ricas sobre cómo no
adoptar una propuesta política inofensiva como esta puede afectarnos
aún
más severamente más adelante.
En un entorno que requiere la cooperación entre varias organizaciones,
las acciones (o la falta de ellas) que pueden afectar significativamente
la vida de todos los demás no deben fomentarse y si en última instancia
son necesarias, debe si *haber una contraparte* para el equilibrio justo.
Edmundo - respondiendo a sus preguntas, trato de responder a los puntos
principales a continuación:
- Este problema está ocurriendo ahora. Ya es posible ver en cantidad
creciente:
1) Las organizaciones que aunque tienen IPv6 operativo, aún necesitan
una cantidad creciente de IPv4 para comunicarse con aquellas que no le
dan ninguna importancia y que quieren seguir transfiriendo más y más IPv4,
2) Necesitan invertir grandes cantidades en equipos CGNAT debido al
fracaso de estas otras organizaciones,
3) Principalmente organizaciones nuevas que están obligadas a pagar
montos crecientes para realizar una transferencia de un bloque IPv4
inicial debido a la inflación impuesta en el mercado de transferencias
debido a la falta de compromiso de estas organizaciones.
- En su ejemplo, la Organización B, aunque tiene un compromiso total
con
IPv6, debería ajustar su red y operación porque la Organización A como
resultado de otra transferencia de IPv4 sin la contraparte de tener IPv6
generará más tráfico IPv4-only (mantenimiento de la dependencia de IPv4)
lo que impone a la Organización B mayores gastos con equipos CGNAT,
mayores costos con equipos de soporte para tratar de solucionar
problemas ocasionados por CGNAT, complejidades operativas y finalmente
cuando esa cantidad de IPv4 que tiene la Organización B ya no sea
suficiente (debido a la falta de acción de la Organización A) se
necesitará recurrir un mercado de transferencias aún más inflado debido
a las acciones de la Organización A.
- No dije que no es un problema la cantidad de dinero que pagó una
organización para realizar una transferencia. Dije que si una
organización que hace bien su trabajo tener IPv6 operativo en la red
y
aún necesita recurrir al mercado de transferencias es algo más
comprensible. De la misma manera, una nueva organización que recibe solo
ASN + IPv6 y también lo necesita es bastante razonable, pero con el
mercado inflado hará cada vez más difícil que surjan estas
nuevas
organizaciones.
Saludos cordiales
Fernando Frediani
On 09/04/2021 06:02, JORDI PALET MARTINEZ via Politicas wrote:
> Hola,
>
> Me parece un comentario muy acertado, muchas gracias por desarrollarlo con tanto detalle.
>
> Quiero aportar algo mas, que tiene que ver con lo comentado por Edmundo
acerca de lo que es "justo", para ahorrar correos, que siempre luego hay quejas si escribo muchos ...
>
> Cuantas mas transferencias se hagan de IPv4, y de bloques mas desagregados, hay mas coste para el resto de la comunidad, porque incrementamos la
tabla de routing the IPv4, y por lo tanto, los que despliegan IPv6, no solo invierten en ese despliegue, sino que "pagan" parte del coste de los que no despliegan IPv6.
>
> Creo que eso es injusto para la comunidad visto de forma global.
>
> Si nos aseguramos, como hace la propuesta, que quien necesite IPv4 lo haga teniendo en cuenta que tambien tiene que desplegar IPv6, estamos en un camino "mas justo".
>
> Hay que comprender, que en algunos casos, quien quiere desplegar IPv6, puede necesitar nuevos bloques de IPv4 para, por ejemplo IPv6-only con IPv4aaS, pero al menos, si esas direcciones las necesita para desplegar IPv6, y no para extender artificialmente IPv4, lo hace mirando hacia el futuro y no quedandose anclado en el pasado.
>
> Si permitimos que obtengan direcciones IPv4 quienes no desplieguen IPv6, se genera un perjuicio para los que necesitan esos bloques IPv4 para desplegar IPv6+IPv4aaS, incluso pueden incrementarse los precios. Esta claro que eso es "menos justo".
>
> Por último, cuanto mas despliegue de IPv6 y mas rápido podamos afianzar, menor será la necesidad de mantener esos bloques IPv4, y
podremos empezar a reducir las tablas de routing de IPv4.
>
> Internet es global, es un bien comun de la humanidad. Es mas justo *para todos*, no sólo los operadores, que sea más facil, competitivo y asequible, y eso se logra moviéndonos a IPv6-only lo antes posible, inicialmente con IPv4aaS, que de forma natural "deja de usarse" según crece el despliegue de IPv6 SIN que los operadores tengan que invertir de nuevo, pero en cambio, recuperando recursos ya que pueden transferir las direcciones IPv4 que les sobra a los que están mas atrasados en el despliegue de IPv6 y aún las necesitan.
>
> Pensemos en el cambio climático. Lo que propone Fernando es, en cierto modo, acercarnos al modelo de compensación de emisiones de carbono. Si necesitas IPv4 (si necesitas contaminar), debes contribuir al cambio a IPv6 (contribuir a la reducción de emisiones de carbono), pagando un peaje por ello (desplegando IPv6), y ese peaje es beneficioso para
todas las partes (los que ya tienen IPv6 y los que necesitan direcciones IPv4 para llegar a IPv6).
>
> Si creemos que es justo y un buen balance el permitir la emision de carbono a quien no pueda de la noche a la mañana eliminarlo por completo (como es el caso de IPv4), entonces es justo también pedir que pagues ese peaje en lugar de ocasionar costes a todos (incluso tu mismo).
>
> Saludos,
> Jordi
> @jordipalet
>
>
>
> El 9/4/21 4:34, "Politicas en nombre de Gondim" <politicas-bounces at lacnic.net en nombre de gondim at gmail.com> escribió:
>
> Prezados,
>
> Eu concordo e apoio a proposta LAC-2020-1. Afinal qual é o grande
> objetivo em se implantar o IPv6? Não é permitir que a Internet continue
> crescendo e oferecendo as melhores experiências de acesso a todos? Fazer
> com que serviços cheguem corretamente a todos?
>
> Para que o IPv6 realmente resolva os problemas que temos hoje, é
> necessário que todos tenham um comprometimento. Não adianta nada a minha
> rede, por exemplo, ter o IPv6 implantado, se a outra ponta da
> comunicação ainda usar IPv4 e isso porque o AS simplesmente não quer
> usar o IPv6.
>
> O sistema autônomo que pensa dessa forma de nada vai agregar à nossa
> comunidade e pior, vai contribuir para gerar cada vez mais problemas
> para outros sistemas autônomos que estão com IPv6 operacional. É justo
> alguns se esforçarem para implantar IPv6 enquanto que outros apenas
> querem mais IPv4? Enquanto for pensado dessa forma cada vez mais veremos
> situações onde a necessidade de uso do IPv6 é desacreditada por
> profissionais e empresas. Sistemas básicos corporativos que não possuem
> suporte a IPv6 e não o fazem porque não acreditam que IPv4 acabou e isso
> está impactando e engessando o mercado mundial. Deixar essas pessoas
> adquirirem mais prefixos IPv4 sem o comprometimento do IPv6 vai só
> confirmar o que, erroneamente, essas pessoas já acreditam, que IPv4 não
> acabou.
>
> Hoje vejo que estamos na era do CGNAT e muitos veem isso como uma
> solução para a falta de IPv4. Eu vejo CGNAT como uma muleta, apoiando
> uma Internet cada vez mais deficiente. Empresas gastando enormes
> quantidades de dinheiro em caixas caríssimas de CGNAT, quando
sabemos
> que o uso do IPv6 faz diminuir essa necessidade e com isso investir em
> coisas que realmente são importantes. Sinceramente não consigo entender
> a lógica em se protelar ou de não se adicionar essa exigência que parece
> bastante adequada para o momento atual pois isso somente irá acelerar
> chegar em um determinado momento que não haverá IPv4 nem
mesmo para se
> colocar no CGNAT. Aí sim vamos ter uma correria desordenada para se
> implantar o IPv6. Hoje nenhum AS deveria esperar acabar o IPv4 para
> implantar o IPv6. Nosso AS53135 distribui IPv6 para os nossos assinantes
> desde 2013.
>
> Se deixarmos essa proposta de lado, vamos sim é contribuir para uma
> Internet cada vez mais deficiente, debilitada e cheia de remendos.
Eu me
> orgulho de chegar em casa, ligar meu notebook, colocar o tcpdump
> escutando a minha interface de rede e ver que todo o meu Netflix está
> acessando via IPv6. Outra coisa que se grandes empresas como Google,
> Facebook e Netflix, que tem uma enorme estrutura de rede, muito mais
> complexa e gigantesca que de muitos aqui, fizeram seu dever de casa e
> hoje suportam IPv6. Por que devemos facilitar o recurso IPv4, tão
> escasso, para empresas que não querem usar IPv6?
>
> Então baseado nisso acredito sim que é mais do que justo
que se alguém
> necessitar de IPv4 que este, pelo menos, já esteja com IPv6 sendo
> implantado em sua rede e distribuindo para seus assinantes. Somente
> assim vamos fomentar o uso do IPv6 e contribuir para a nossa Internet
> continuar crescendo como deveria ser.
>
> Em 07/04/2021 21:38, Fernando Frediani escreveu:
> > 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
> _______________________________________________
> 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