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

Fernando Frediani fhfrediani at gmail.com
Thu May 27 18:21:28 -03 2021


A continuación del mensaje anterior, siguen las respuestas a todas las 
objeciones que se plantearon en el último FPP.

- ¿Por qué es perjudicial transferir recursos de IPv4 sin tener en 
cuenta la demostración de funcionamiento de IPv6?
R: Es perjudicial porque cada vez que se transfieren más y más recursos 
IPv4 sin contraparte, se genera más tráfico IPv4-only lo que impone a 
todos los demás, incluso aquellos que tienen IPv6 completamente 
operativo, tener costos más altos con técnicas como CGNAT. Además de una 
mayor cantidad de problemas relacionados con CGNAT que el sector de 
soporte necesita abordar, algunos de estos problemas no resueltos o sin 
paliativos. Aún existen serios problemas sociales provocados por la 
incapacidad de las autoridades para poder identificar a los delincuentes 
detrás de CGNAT debido a que muchas empresas aún no registran 
correctamente la información del puerto de origen, hecho que no ocurre 
en IPv6.

- No hay sanciones para aquellos que no deseen implementar IPv6, 
¡ninguna! Lo que surgirá con esta propuesta es una restricción de no 
poder transferir IPv4 hasta que pueda probar IPv6 operativo. Esto NO es 
de ninguna manera una sanción, sino un requisito más, normal y 
justificable a solicitar para que se pueda realizar la transferencia, 
como ya lo es para otros requisitos existentes, que ya solicitan LACNIC 
y sus NIRs como justificación de atribuciones iniciales de IPv4 o 
transferencias. Caso contrário de coherencia tendrían que clasificarse 
como una tanbién como"penalización", que en verdad no lo es.

- Supera lo que debería ser el propósito del Foro de Políticas, no es 
eficiente, no logra los resultados esperados, es ambiguo en cuanto a los 
términos partes significativas de la red.
R: Es prerrogativa de este Foro de Política (de la comunidad y no del 
RIR) estipular los requisitos que sean necesarios para las 
transferencias o cualquier punto relacionado con las reglas que se 
aplican a los recursos de numeración ya que existen otros.
No es posible medir la eficiencia del resultado de la propuesta, por lo 
que el argumento de que no es eficiente es falso. Por otro lado, es 
bastante razonable pensar que la propuesta tiene un potencial positivo 
para lograr su propósito, y aunque se considere pequeña, continua siendo 
positiva para toda la región. Lo mismo ocurre con decir que no logra los 
resultados esperados. No se presentaron argumentos para apoyar esta 
afirmación. Es solo una visión aislada y bastante teórica.
Dado el escenario actual, es razonable poder solicitar y realizar 
transferencias IPv4 solo a organizaciones que ya han demostrado que han 
hecho todo lo que podían hacer con IPv6 para luego recibir más IPv4.
No es cierto que el término "partes significativas de la red" sea 
ambiguo porque en la versión actual fue uno de los principales cambios 
para aclarar de manera muy objetiva el significado del término. Esto, 
junto con los requisitos técnicos que serán definidos por el staff de 
LACNIC, aporta un grado de objetividad que es bastante seguro para dejar 
bien claro lo que significa este término.

- Esta propuesta invade cuestiones operativas que son competencia de 
cada organización.
R: Ciertos problemas operativos son necesarios para poder existir en 
Internet (un ecosistema de interconexión) donde es imperativo seguirlo 
además del hecho de que para existir en IPv4 se han requerido requisitos 
similares durante mucho tiempo. Además, IPv6 no es solo una "buena 
práctica", sino un requisito fundamental para la existencia y el 
crecimiento continuos del ecosistema de Internet. Este requisito que se 
propone colocar no es un mero capricho que uno puede seguir ignorando.
Internet está sobre IPv6. Los nuevos sistemas autónomos solo son 
accesibles en IPv6. Para garantizar la interoperabilidad y la 
intercomunicación entre las redes que componen Internet, debemos 
asegurarnos de que todo el contenido y las personas sean accesibles a 
través de IPv6. Este objetivo no es una injerencia en la cuestión 
operativa interna de cada organización, sino que forma parte del alcance 
de la política de delegación de recursos de numeración que pretendemos 
reformar aquí.

Muchas gracias y saludos a todos

Fernando Frediani


Em 4/21/2021 3:54 PM, Fernando Frediani escreveu:
>
> Hello Albert
> Thanks for sharing these very good points about the need of this proposal.
>
> Unfortunately there is still people with the fear of the unknown to 
> oppose raising points which I believe are invalid like that the RIR 
> doesn't have the power to make this requirement while there are 
> several others in place already for a long time.
>
> But the main point I believe is the sustainability and continuous 
> development of this very same Internet ecosystem we are all in. The 
> lack of keep requiring nothing and keep us in the same situation we 
> have been for a couple of years, with the aggravating that this is 
> causing this is causing damage to a growing number of organizations 
> that either have to spend a lot of more resources in order to cope 
> with the problems caused by others who keep flying the flag of "my 
> network, my rules" ignoring the fact that in order to live in a 
> interconnected environment you must abide to certain rules, standards 
> and usage of protocols.
>
> One last thing is that this proposal is NOT against the transfer of 
> the IPv4. It completely understandable that organization still need to 
> keep going, but rather it just request a counterpart from those in 
> such situations.
>
> Regards
> Fernando
>
> On 21/04/2021 13:04, hostmaster at uneedus.com wrote:
>> I have a harder time keeping up with this discussion, since I am not 
>> a native speaker of Spanish, and rely on translation tools. Nearly 
>> all discussion up to this point has been in Spanish.
>>
>> I speak in favor of the proposal and move its adoption.
>>
>> I proposed a similar proposal in the ARIN region, and do believe that 
>> the time has long since arrived for parties that receive transferred 
>> IPv4 addresses be able to use what will clearly become the protocol 
>> of the future, which is IPv6.  Ten years ago in Miami is when the 
>> last /8's of IPv4 were given out to the 5 RIR's, so this issue is 
>> clearly timely.
>>
>> A lot of incumbent network operators have a "my network, my rules" 
>> policy, and they are perfectly happy to keep running only IPv4 
>> forever. However that hand dragging on IPv6 adoption, causes a 
>> worldwide issue for all the networks that have adopted IPv6 because 
>> of its lack of address space, and the many whose networks are now 
>> mostly IPv6.
>>
>> These operators would like the day of finally being able to sunset 
>> our IPv4 networks and get back to running only one protocol.  Many 
>> major networks have already adopted IPv6 internally, and ONLY run 
>> IPv4 at the edge.  Devices like CGnat are expensive to run and 
>> require logging to meet CALEA requirements.  High IPv6 adoption will 
>> bring the day of that sunset closer, and policies that drag that date 
>> further into the future are wrong.
>>
>> RIR's clearly have the power to set reasonable conditions on 
>> transfers. Some things that we require that are not contested are 
>> paying your fees and keeping up proper contact information.
>>
>> I see being able to communicate using IPv6, which is rapidly becoming 
>> the majority of traffic at many exchange points is not an 
>> unreasonable requirement.  Of course, there does exist parts of the 
>> world where IPv6 is not available and thus the exception which is 
>> provided in the proposal.
>>
>> I say it is about time, and see no issue in saying to someone that if 
>> you want to get more IPv6 address space via transfer, that it is 
>> about time that you step up to the future, which is IPv6.
>>
>> There has also been a discussion regarding copyrighted ideas being 
>> part of this proposal.  In every nation I am aware of, ideas cannot 
>> be copyrighted, but only a specfic expression of ideas.  Clearly the 
>> idea that RIR's should adopt a policy to require use of IPv6 before 
>> authorizing transfer of more IPv4 to that entity is not a protected 
>> idea.
>>
>> I am the author of what I think was the first proposal to do this in 
>> the ARIN region, and by no means do I consider this proposal a 
>> copyright violation of that idea.  Only expression is protected, not 
>> the underlying idea, and I see this proposal as needed as a stick to 
>> get those IPv4 operators to make the right choice for everyone on the 
>> internet.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>> On Tue, 13 Apr 2021, Fernando Frediani wrote:
>>
>>> Hola
>>>
>>> Jorge - No hay problema en agregar este requisito para que sea 
>>> posible permitir la transferencia dadas las justificaciones que ya 
>>> se han presentado en varios mensajes anteriores.
>>> En cuanto al argumento de que las transferencias se realizan "fuera 
>>> del registro", ya se ha explicado muchas veces en los mensajes 
>>> anteriores cómo esta no puede considerarse una objeción válida ya 
>>> que existen suficientes garantías para mitigar este temor que está 
>>> presente en cualquier otra propuesta.
>>>
>>> Hernán - No sé qué datos está buscando, pero ya se han presentado 
>>> varios escenarios de la vida real y ejemplos prácticos técnicos y 
>>> económicos, comenzando con aumentos significativos en el costo de 
>>> aumentar las operaciones con CGNAT y la creciente necesidad de 
>>> utilizar el mercado de transferencia. Cualquiera que gestione un 
>>> negocio en Internet o una gestión técnica es consciente de todos los 
>>> problemas y costes que conllevan estos problemas.
>>> Con respecto al posible loop, es posible que no hayas podido leer la 
>>> propuesta en su totalidad, pero predice que las nuevas 
>>> organizaciones que no tengan ningún bloque de IPv4 podrán realizar 
>>> una transferencia inicial hasta el límite de un /22 sin la necesidad 
>>> para demostrar IPv6 operativo.
>>> No entiendo por qué se considera extraño que esta política 
>>> "obstaculice" si logra realizar una transferencia IPv4 sin la 
>>> contraparte de IPv6. Desde mi punto de vista es normal que alguien 
>>> que a mediados de 2021 no tenga IPv6 operativo tenga otros problemas 
>>> que están afectando a todos los demás a resolver antes de seguir 
>>> transfiriendo más IPv4.
>>>
>>> Oscar - hablando simplemente sí. Una empresa que se enfrenta a la 
>>> necesidad de transferir más IPv4 para incrementar su operación (y en 
>>> consecuencia su tráfico) y sin embargo, hasta ahora no ha hecho 
>>> ningún despliegue de IPv6 está causando daño a todos los demás, 
>>> incluidos los que hicieron sus obligaciones, por eso ya no se 
>>> debería permitir que se realicen transferencias IPv4 sin la 
>>> consideración de demostrar IPv6 y reducir la tasa de crecimiento de 
>>> un problema mucho más serio de lo que les ha parecido a algunas 
>>> personas que desean que estos actores se sientan muy cómodos para 
>>> continuar causando estos problemas en ecosistema Internet. A menudo 
>>> he dicho que este requisito no es tan grande ni tan difícil de 
>>> lograr. Quizás algunos estén sobrestimando este requisito como algo 
>>> que hará que las transferencias IPv4 sean totalmente inviables y 
>>> este no es ni nunca fue el propósito de esta propuesta.
>>>
>>> Saludos
>>> Fernando
>>>
>>> On 13/04/2021 10:28, Oscar A. Robles-Garay wrote:
>>>> Fernando,
>>>>
>>>> Si estoy entendiendo bien, con tu propuesta esperas que tenga como 
>>>> consecuencia "deseable" que aquellos ISP's que necesitan IPv4 y 
>>>> hayan decidido ir al mercado de IPs por transferencias, se tomen un 
>>>> tiempo para desplegar "algo" de IPv6, es así?
>>>>
>>>> Saludos,
>>>>
>>>> Oscar
>>>>
>>>>
>>>> On 12/4/21 15:23, Fernando Frediani wrote:
>>>>> 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/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
>>>>>>>>> _______________________________________________
>>>>>>>>> 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