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

Mike Burns mike at iptrading.com
Tue Apr 13 15:50:57 -03 2021 

Hi Fernando,

Thanks for your reply, I have a few clarifications.

"¿Y quién dijo que la velocidad o cantidad de transferencias en el mercado de transferencias es un parámetro bueno o positivo a tener?"

You misunderstand me, likely my fault for my inability to speak Spanish. I never said velocity in the market was an indicator of good or bad. What I should have made more clear is that the time it takes for a seller to find a buyer is much shorter now than it has been. In the past, a block might be for sale for weeks or even months, awaiting an appropriate buyer. But these days blocks are purchased very quickly and I don't see any end to the current inventory shortage except for higher prices. So I think the current "sellers' market" will persist.

Think of it like hot real-estate market, where the seller of a house can quickly receive multiple offers. That is the status of things in the IPv4 market currently. I will be part of a panel discussing this and other topics tomorrow during the virtual ARIN meeting, if you have any interest.

But my point was that in this sort of a market, to return to the real-estate analogy, the home seller has multiple offers, but one of them will delay the closing date and add uncertainty. Why would the home seller choose this buyer instead of other buyers? There is only one real incentive, that is the slow buyer must pay a higher amount than the other buyers. In the transfer market, sellers only receive payment after the transfer completes. When prices rise quickly, as they are now, sellers who have to wait a long time for payment see that they can cancel the slow deal and sell the block at a higher price; this is some of the uncertainty that comes from long transfer durations.  Perhaps now it's easier to understand why this policy would raise prices for LACNIC buyers and provide incentive for LACNIC sellers to choose non-LACNIC buyers.  

" Esto no es una preocupación para quienes venden sino para quienes reciben."

So maybe you can see that this is not just a matter, as you say, for those who receive, but it will be a concern for those who sell as well, and for the brokers who assemble these deals and guide both buyers and sellers. LACNIC buyers and sellers are members of the community as well, and the community decided to enact a transfer policy which this policy places burdens upon. 

" El aumento de la transferencia de bloques no es algo positivo ni para estimular, al contrario, es una mala señal."

The data does not support this. The community wants transfers. Transfers have not happened as expected, despite years having passed. The transfer volume measured by either number of addresses transferred or simply the number of transfers is negligible compared to the other RIRs at the same point in their market development.  Have you provided any backwards-looking analysis of prior transfers in the LACNIC region and counted the recipients who have no IPv6 presence?  It might give us an idea of the scale of the problem.

Regards,
Mike

-----Original Message-----
From: Politicas <politicas-bounces at lacnic.net> On Behalf Of Fernando Frediani
Sent: Tuesday, April 13, 2021 12:31 PM
To: politicas at lacnic.net
Subject: Re: [LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1

On 13/04/2021 12:35, Mike Burns wrote:
> I would like to add to Jorge Villa's comments regarding the need for buyers to move quickly to secure blocks that become available.
>
> If this policy is passed, as a broker I would have to tell my clients that they would be better off selling to buyers in a different RIR due to this uncertain IPv6 test requirement. Things already move much more slowly at LACNIC than at other RIRs in transfer processing time, and implementation of this policy can only slow things further.
Esto no es una preocupación para quienes venden sino para quienes reciben. ¿Y quién dijo que la velocidad o cantidad de transferencias en el mercado de transferencias es un parámetro bueno o positivo a tener? 
Puede ser positivo para su tipo de negocio en particular, pero no para la comunidad involucrada y las empresas que operan en el sector.
>
> Adding this requirement will make it much harder for buyers in LACNIC to find blocks because as Jorge mentions, the velocity of the market has increased and blocks get snapped up quickly when they come to market.  Even sellers in LACNIC will find it easier to send their blocks to other RIRs who don't have this additional test to contend with.
Si considera que a la mayoría de las empresas no les importará el despliegue de IPv6, esta propuesta se vuelve aún más necesaria. 
El
aumento de la transferencia de bloques no es algo positivo ni para estimular, al contrario, es una mala señal.
Si esta "prueba" tiene una justificación razonable (y hay varias), esto es lo más importante a tener en cuenta.
>
> Currently it is a seller's market and sellers can be selective about the buyers they pick. From my perspective, this is unlikely to change, as blocks become ever more scarce. Why would any seller choose to sell to a LACNIC buyer if this policy is implemented? Only if the LACNIC buyers pay more than buyers in other RIRs.
No veo ningún sentido en considerar que un destinatario tendrá que pagar más en una transferencia si no tiene el requisito mínimo necesario para realizarla simplemente porque no será aprobada. Para quienes venden el valor de mercado es lo mismo si el receptor es capaz de hacer las justificaciones necesarias.
>
> This policy will result in higher prices charged to LACNIC buyers than to buyers at any other registry.
Esto no es cierto y no tiene sentido lógico decirlo.
> Instead of harnessing the IPv4 market to further IPv6 deployment as intended, this policy, like an unsuccessful parasite, will kill its frail host and yield no IPv6 progress.

Puede ser para el mercado de transferencias que ciertamente no sea la prioridad de la mayoría de las organizaciones que necesitan continuar existiendo y haciendo negocios en Internet.
Por tanto, los efectos que esta política puede tener en el mercado de transferencias es una reducción de la demanda, lo que es positivo para todas las organizaciones excepto para las propias empresas que se benefician de la transferencia de recursos y ese es un problema del que no debemos preocuparnos.

Fernando

>
> Regards,
> Mike
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Politicas <politicas-bounces at lacnic.net> On Behalf Of Fernando 
> Frediani
> Sent: Monday, April 12, 2021 11:27 PM
> To: politicas at lacnic.net
> Subject: Re: [LACNIC/Politicas] Nueva versión de la propuesta 
> LAC-2020-1
>
> El problema es que avanzar "en el tiempo" ya no es mas aceptable 
> porque
está causando problemas y pérdidas crecientes a muchas organizaciones y consecuentemente a los usuarios finales, y solo empeora.
> Si es legítimo tener un mecanismo más (ver uno más, no el único) a 
> través de políticas que favorezcan este desarrollo de manera justa sin 
> hacer inviables las transferencias, porque evitar
hacerla ? Lo que tenemos hasta aquí como resultado práctico es una mala historia que solo prueba que continuar a hacer las cosas de la misma manera solo devolverá el mismo resultado que tuvimos en esta más de casi dos décadas y eso no parece nada positivo.
>
> Fernando Frediani
>
> On 12/04/2021 15:34, Raúl Echeberría wrote:
>> Gracias Fernando,
>>
>> Sin duda una muy buena discusión.
>> El ejemplo de MANRS o IXPs lo puse como ejemplos de experiencias 
>> exitosas que se basan en la naturaleza de colaboración voluntaria
de Internet. Es el ADN de Internet.
>>
>> Hay que apostar a lo mismo en este tema. Tu y yo estamos de acuerdo 
>> en lo importante de un despliegue más rápido de IPv6. Yo creo que hay 
>> que seguir trabajando y cuanto más operadores lo hagan, más presión 
>> hará el mercado sobre el resto. Es un proceso que avanza a su tiempo. La forma que tenemos de incidir, desde mi punto de vista, no es a través de las políticas de transferencia de recursos, sino con más trabajo de coordinación, capacitación, promoción, etc.
>>
>> No apoyo esta política porque no me parece el camino adecuado, pero 
>> me quedo con el medio vaso lleno que son las grandes coincidencias 
>> que
tenemos de fondo.
>>
>>
>> Saludos,
>>
>>
>> Raúl
>>
>>
>>
>>
>>
>>> El 12 abr. 2021, a las 15:23, Fernando 
>>> Frediani<fhfrediani at gmail.com>
 escribió:
>>>
>>> Hola Raul
>>> Gracias por tu contribución.
>>>
>>> No podemos confundir IPv4 y IPv6, que son recursos de numeración, el
>>>
>>> tema principal de nuestra discusión, con MANRS y participación en 
>>> IXPs. Si bien MANRS es una buena práctica y la participación en IXP es positiva, el uso de *recursos de numeración* y el impacto de cómo el mal uso (o no uso) puede poner en duda la continuidad de la evolución de un sistema que depende de diferentes actores.
>>>
>>> Sí, estas restricciones ciertamente están relacionadas con el uso 
>>> óptimo de los recursos. Si una organización necesita recursos para 
>>> seguir desarrollando y conectando a más personas y ya no puede 
>>> acceder a estos recursos y existe una solución (IPv6) que, de ser 
>>> operativa, elimina estas restricciones, es necesario que esta sea la 
>>> solución y que sea
>>>
>>> estimulado.
>>> Es importante tener en cuenta que *IPv6 es el protocolo de Internet estándar* desde 2017, no solo una buena práctica. No soy yo quien lo dice, sino el IETF.
>>>
>>> Con respecto a lo trade-off es lo que he estado tratando de decir 
>>> que
es muy, muy aceptable. No existe nada difícil, complejo o imposible de tener, al contrario, es algo bastante obvio para cualquier poseedor de recursos de numeración. Los efectos de no hacer nada son mucho peores que hacer en este ejemplo.
>>>
>>> Saludos
>>> Fernando Frediani
>>>
>>> On 12/04/2021 13:28, Raúl Echeberría wrote:
>>>> Fernando,
>>>>
>>>> Por supuesto leí la propuesta completa y los cambios de la última versión. No leí el título solamente. En ese caso no me hubiera atrevido a hacer comentarios.
>>>>
>>>> Es cierto que todas las políticas de alguna forma fuerzan el cumplimiento de ciertos requisitos y afectan de forma más o menos artificial el mercado. El punto es donde está el “trade off”.
>>>>
>>>> Se supone que esas restricciones tienen que estar vinculadas al uso óptimo de los recursos de numeración, no de Internet en si misma.
>>>>
>>>> Esta propuesta, si bien muy bien intencionada, está desde mi punto
>>> de vista, más allá
>>> del "trade off" aceptable.
>>>> Internet es una construcción colaborativa donde la base de la 
>>>> colaboración y la coordinación es voluntaria. Hacerlo diferente 
>>>> cambia la naturaleza de Internet y por lo menos a mi con todo 
>>>> respeto, no me
>>> parece lo correcto. Por supuesto es muy respetable que tengas una opinión diferente.
>>>> Si hoy aprobamos esta política, mañana la propuesta será
>>> hacer que la adopción
>>> de MANRS sea obligatoria y luego será la conexión a un IXP y luego 
>>> otra cosa. Siempre hay prácticas que nos parecen buenas y que 
>>> quisiéramos que sean adoptadas masivamente, pero pare eso está el
trabajo colaborativo que, entre otros, hacen los NOGs y los trabajos de extensión y difusión de organizaciones como ISOC o los RIRs.
>>>> No querramos forzar la implementación de buenas prácticas operativas a través de las políticas.
>>>>
>>>>
>>>>
>>>> Saludos,
>>>>
>>>> Raúl
>>>>
>>>>
>>>>
>>>>
>>>>> El 12 abr. 2021, a las
>>>>> 11:57, Fernando Frediani<fhfrediani at gmail.com>
>>> escribió:
>>>>> Hola de nuevo Raul
>>>>>
>>>>> Mira, cambiar las políticas como propone esta propuesta no está 
>>>>> obligando a nadie a poner IPv6 o a convertir a LACNIC en una 
>>>>> "policía IPv6". Solo afecta a quienes desean transferir IPv4 y en 
>>>>> este caso no hay nada de malo. Y la empresa que quiere actualizar 
>>>>> la base de datos whois que funciona bajo reglas que se actualizan 
>>>>> según el tiempo y
según la necesidad de cada momento. Lo que se está considerando como contraparte no es nada que imposibilite el traspaso si la empresa tiene *un compromiso mínimo* con todos los demás, dado el momento que estamos atravesando.
>>>>>
>>>>> Otro punto que quiero destacar mucho es que parece que esta 
>>>>> propuesta tiene como objetivo solucionar todos los problemas del 
>>>>> despliegue de IPv6
>>> y no es nada de eso. Es solo una iniciativa más, pequeña por cierto, para incentivar el despliegue de IPv6 y sobre todo para evitar que quienes necesitan seguir transfiriendo IPv4 sigan causando más problemas a todos los que están cumpliendo con sus obligaciones.
>>>>> Dado el contexto actual, ya no tiene sentido cerrar los ojos y permitirse seguir registrando transferencias IPv4 sin tener en cuenta el desarrollo continuo y saludable del ecosistema del que todos dependemos a diario.
>>>>>
>>>>> El tema de las políticas que obligan al mercado es un tema complejo de discutir, pero para decirlo en pocas palabras si fuera tan indiferente, ni siquiera sería necesario justificar la necesidad de IPv4 en el momento de una asignación inicial o una transferencia. . Hay otros RIR que son mucho más permisivos que LACNIC, pero aquí felizmente tomamos la decisión correcta en este contexto.
>>>>>
>>>>> Fernando
>>>>>
>>>>> On 12/04/2021 11:11, Raúl Echeberría wrote:
>>>>>> Olá Gondim
>>>>>>
>>>>>> Concordamos em tudo, exceto em um elemento importante. 
>>>>>> Compartilho sua preocupação e acho que algo precisa ser feito. 
>>>>>> Onde discordamos
>>>>> é que Eu não
>>>>> acredito que forçar o comportamento do mercado de esse jeito,
 seja
>>>>> o papel das políticas, .
>>>>>> É necessário redobrar os esforços na promoção do IPv6 fornecendo 
>>>>>> evidências que mostram os danos que você mencionou. É
preciso ter
>>>>>> bons estudos, boas métricas e trabalhar
>>> para disseminá-los, capacitar, gerar capacidades técnicas,
contatar os operadores e trabalhar com eles.
>>>>>> Mas acredito que não é papel da política forçar o
>>> mercado, nem acredito que essa política será eficiente para
atingir o objetivo que se propõe.
>>>>>> É por isso Gondim, que embora concorde com você no seu raciocínio e nas suas preocupações, NÃO apoio esta proposta.
>>>>>>
>>>>>>
>>>>>> Saudações
>>>>>>
>>>>>> Raúl
>>>>>>
>>>>>>
>>>>>>
>>>>>>> El 12 abr. 2021, a
>>>>>>> las 10:46, Gondim<gondim at gmail.com>  escribió:
>>>>>>>
>>>>>>> Bom dia Raúl,
>>>>>>>
>>>>>>> O problema é que enquanto não tivermos uma política que
>>>>> alavanque o IPv6, está não irá crescer como deveria. 
É a famosa questão do: "Cão correndo atrás do rabo".
>>>>>>> As empresas não querem modificar seus sistemas para terem 
>>>>>>> suporte
>>>>> à IPv6 porque as Operadoras que lhes fornecem Internet, e aos seus 
>>>>> clientes, não possuem IPv6 implementado. Em contra partida; as
Operadoras não implementam IPv6, porque não veem conteúdo e nem a necessidade de IPv6, enquanto tiverem IPv4. Se ninguém sair da inércia vamos continuar a passos de caroça na implementação de IPv6.
>>>>>>> Diariamente, aqui na minha operação, eu vejo assinantes
meus
>>>>> com problemas para acessarem sistemas externos e o mesmo ocorre em 
>>>>> sentido contrário, de acessos externos aos nossos assinantes.
>>>>> Quando tento explicar, ao meu assinante, sobre a necessidade do 
>>>>> uso do IPv6, este me diz que sua equipe de TI afirma não existir 
>>>>> esse problema de falta de IPv4 e que é obrigação do Provedor dar 
>>>>> IPv4 público para ele. Porque este é "universal". O que vejo é uma 
>>>>> total
>>> desinformação do
>>> meu cliente mas também um reflexo de como o mercado está vendo esse problema.
>>>>>>> Conteúdos informativos e sociais já existem em IPv6 e isso
>>> é bom. Ter Google, Facebook, Netflix, Instagram, Linkedin, Youtube e 
>>> outros de conteúdo, ajudam em muito nossa causa mas estamos 
>>> esquecendo
>>>>> de outros sistemas que
>>>>> usamos no dia a dia. Sistemas empresariais, ERPs, empresas que 
>>>>> desenvolvem software básico para diversas áreas
>>> e que não sentem a menor vontade de suportar IPv6. Porque muitas
das vezes não conseguem acesso em IPv6 de seus provedores de Internet. Acredito que isso desmotive tecnicamente o esforço deles.
>>>>>>> Cada vez mais estamos investindo em CGNAT. Comprando 
>>>>>>> equipamentos caríssimos para continuar usando uma rede remendada, debilitada.
>>>>>>> Porque o conteúdo em IPv4 continua crescendo e outros Sistemas 
>>>>>>> Autônomos
>>>>> não querem implementar IPv6.
>>>>>>> Nós tivemos a
>>>>>>> época do esclarecimento sobre o IPv6, do incentivo, diversas 
>>>>>>> organizações ministraram gratuitamente cursos de
>>>>> IPv6, palestras, fóruns especializados com materiais técnicos riquíssimos. Conteúdo informativo e educacional foram produzidos e experiências foram compartilhadas com todos, durante anos. Nesse momento; uma política permissiva só vai agravar mais a situação e que sabemos que futuramente será mais difícil resolver os problemas que aparecerão diante de nós.
>>>>>>> Estamos falando aqui da sobrevivência da Internet como um eco sistema que conhecemos. Se não for do RIR essa incumbência, então que seja de outro mas tenho convicção que sem isso, não iremos muito longe.
>>>>>>>
>>>>>>> O que me parece é que a ideia colocada nessa proposta é
boa mas
>>>>>>> ninguém quer assumir o papel de "carrasco" e fazer valer algo que só vai beneficiar a todos e a Internet. Quantos anos mais serão necessários para percebermos isso?
>>>>>>>
>>>>>>> Saudações,
>>>>>>>
>>>>>>> Gondim
>>>>>>>
>>>>>>> Em 11/04/2021 19:00, Raúl Echeberría escreveu:
>>>>>>>> Estimados colegas.
>>>>>>>>
>>>>>>>> He seguido con atención la discusión sobre esta propuesta
>>> que me parece muy interesante.
>>>>>>>> Debo decir que comparto el espíritu que fundamenta la propuesta 
>>>>>>>> pero NO la apoyo porque creo que excede el rol que debe tener LACNIC y las políticas de manejo de recursos de numeración.
>>>>>>>>
>>>>>>>> Si bien soy totalmente empático con la idea de que los 
>>>>>>>> operadores deberían contribuir activametne con el despliegue de
>>>>>>>> IPv6 creo que
>>>>> es algo que hay que trabajarlo a través de la promoción de IPv6 y no haciéndolo mandatorio en la política de transferencia.
>>>>>>>> Además de pensar, como decía, que esta propuesta excede lo que desde mi punto de vista, deben ser las políticas de los RIRs, tampoco creo que sea eficiente en lograr el objetivo que se propone.
>>>>>>>>
>>>>>>>> No es claro que es que “IPv6 está operativo en partes 
>>>>>>>> SIGNIFICATIVAS de la red” y tampoco está claro que sucede
si, una vez definido este criterio, la situación cambia luego de ser aprobada la transferencia.
>>>>>>>>
>>>>>>>> Muchos operadores tienen IPv6 operativo en el core de la red 
>>>>>>>> sin
dar servicios a usuarios finales, y no hay dudas que el core es una parte más que significativa de la red.
>>>>>>>>
>>>>>>>> Creo por supuesto que es y seguirá siendo un tema fundamental 
>>>>>>>> seguir trabajando por el incremento del despliegue de IPv6 de 
>>>>>>>> forma integral en Internet y eso es lo que ya hacen los RIRs y 
>>>>>>>> muchas otras
organizaciones.
>>>>>>>> Me parece que hay que continuar trabajando estos temas también
>>>>> en los grupos de operadores pero no apoyo que este requerimiento 
>>>>> se incluya en la política de transferencia tal como se propone.
>>>>>>>> Saludos al autor
>>>>>>>> de la propuesta por traer a discusión un tema
>>> super relevante. La discusión en si misma contribuye a la concientización sobre la necesidad de la aceleración del despliegue de IPv6.
>>>>>>>> Saludos,
>>>>>>>>
>>>>>>>>
>>>>>>>> Raúl
>>>>>>>>
>>>>>>>>
>>>>>>>> 2.3.2.18.3 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.
>>>>>>>>> El 31 mar. 2021, a las 11:37,info-politicas at lacnic.net  escribió:
>>>>>>>>>
>>>>>>>>> [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/la
>>>>>>>>> n
>>>>>>>>> guage/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/la
>>>>>>>>> n
>>>>>>>>> guage/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/la
>>>>>>>>> n
>>>>>>>>> guage/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
>>>>> _______________________________________________
>>>>> 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
> _______________________________________________
> 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

More information about the Politicas mailing list