[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
ariel sabiguero yawelak
asabigue at fing.edu.uy
Tue Apr 13 17:11:49 -03 2021
Quizás no sea la lista para esta discusión... pero el problema del
CGNAT y del NAT es la pérdida de conectividad end-to-end.
Pero ya perdimos la conectividad end-to-end cuando todo el correo del
mundo se mueve entre servidores de gmail y yahoo y la nube nos ha
"comido". Ese viejo concepto del P2P donde ofrecemos un puerto donde
atendemos conexiones desde nuestra IP pública se cambió por tener una
conexión establecida contra "el cloud" y nos notifican o comunican
cualquier cosa por dentro de la misma...
Pasamos de un mundo "federado" donde corríamos nuestros propios
servidores de correo y elegíamos nuestro "user agent" a un mundo donde
descargamos la app del servicio específico que usamos (sea whatsapp,
telegram o signal). ¿para qué importa que me den la misma IP que a mi
vecino si no me voy a conectar con él? si el CGNAT logra barajar bien
los puertos, todo va a funcionar. Audio por TCP, video por TCP, Internet
por TCP.
Seamos honestos ¿quién no usa webmail? ¿quién no usa web-todo? Internet
hoy es el puerto 443 de la nube. Preciso ir a la nube para ajustar el
A/C y para apagar la luz...
saludos
ariel
PS: bueno, tal vez lo dramaticé un poco para hacerlo más divertido!
PS2: PRESAGIO: llegará el IPv6 cuando ya no puedan hacer más plata con
la NUBEv4, no antes...
El 13/4/21 a las 16:44, Fernando Frediani escribió:
> Asimismo, IPv6 es el único protocolo capaz de continuar el crecimiento
> ordenado de Internet y reducir y eliminar los problemas y conflictos
> derivados de la escasez de IPv4. A menos que alguien quiera estar en
> desacuerdo y decir que la forma correcta es continuar haciendo CGNAT
> con IPv4.
>
> Fernando
>
> On 13/04/2021 16:40, JORDI PALET MARTINEZ via Politicas wrote:
>> Hola Nico,
>>
>> El ejemplo de BGP, creo que se comprende si se lee esa sección del
>> manual. Tal cual está, puede parecer que hay otros protocolos, etc.
>>
>> El otro no es un ejemplo (lo pusiste tu, yo lo complete) sino una
>> realidad.
>>
>> Respecto del tema del % de tráfico: No se si se trata de revocar o de
>> dejar de hacer descuentos en su contribución a las cuotas de
>> membresía, no he llegado aún a eso.
>>
>> Lo que no es correcto es pensar que, si despliegas IPv6 no vas a
>> poder cumplir con esos tráficos, eso es medible en cualquier
>> despliegue de todos los que hay en el mundo. Si despliegues al 100%
>> de tus residenciales o celulares, si o si tendrás como poco un 75% de
>> tráfico IPv6 respecto del total de tráfico de esos clientes. Insisto,
>> hay que parametrizarlo, porque obviamente no todos los operadores dan
>> servicio mayoritariamente a residenciales, hay casos que solo dan
>> servico a corporativos, etc.
>>
>> Saludos,
>> Jordi
>> @jordipalet
>>
>> El 13/4/21 20:39, "Nicolas Antoniello" <nantoniello at gmail.com>
>> escribió:
>>
>> Jordi,
>>
>> No entremos en discusiones que creo que no tienen sentido en
>> este caso.
>> En primer lugar, se pide BGP para un ASN porque es el único
>> protocolo
>> que se utiliza para eso y porque además un ASN solo tiene
>> sentido en
>> BGP, no hay ningún otro protocolo que lo utilice que no sea BGP o
>> tenga directamente que ver con BGP (antes que me digas que RPKI lo
>> utiliza por ejemplo).
>>
>> Lo otro era un ejemplo y no quiero seguir esa línea de debate.
>>
>> A modo de resumen, no estoy para nada de acuerdo en exigir % de
>> tráfico de los protocolos como condición de asignación de recursos,
>> porque técnicamente además no tiene ningún sentido (el operador
>> debe
>> hacer todo el despliegue y asignar los prefijos según las
>> recomendaciones... pero hasta allí, no me prece que hacerlo
>> responsable de que además de cumplir ciertos niveles de tráfico sea
>> razonable, ni que puedas revocarle recursos porque no llega a
>> ciertos
>> niveles. O acaso le vas a revocar las asignaciones de IPv6 si
>> desplegó
>> todo correctamente, asignó a todos sus clientes pero no llega por X
>> motivo a tener cierto volumen de tráfico... perdona, pero pensé
>> que lo
>> que se buscaba era promover el despliegue de IPv6.
>>
>> Abrazo,
>> Nico
>>
>>
>> El mar, 13 de abr. de 2021 a la(s) 15:09, JORDI PALET MARTINEZ via
>> Politicas (politicas at lacnic.net) escribió:
>> >
>> > Hola Nico,
>> >
>> > No concuerdo contigo y te pongo un par de ejemplos:
>> >
>> > 1) Para tener ASN, pedimos que se use BGP, es decir
>> especificamos un protocolo. Ponemos otros requisitos para otras
>> partes del manual.
>> >
>> > 2) El ayuntamiento de muchas ciudades, igual que los
>> gobiernos, ya están indicando que tu carro debe contaminar menos de %
>> y una tabla de progresión "negativa" a lo largo de x años o no te
>> permite usarlo. Igualmente, ya están indicando la prohibición del uso
>> de vehículos diésel o gasolina en determinadas ciudades, o zonas de
>> la ciudad, y eso se va extendiendo progresivamente a regiones o
>> países en los próximos años. Hay muchas medidas similares, como son
>> que, si se incrementa la polución en una ciudad y área limítrofe,
>> esos días solo acceden vehículos eléctricos, híbridos o con pila de
>> combustible (hidrógeno), o que los contaminantes no puedan aparcar en
>> las zonas publicas/calles y por tanto solo en parkings de pago, etc.,
>> etc.
>> >
>> > Son hechos, no es ficción, igual que he visto en países de LAC
>> otras medidas como "pico y placa" para circulación por días alternos
>> según las placas, etc.
>> >
>> > Al final todo se reduce a decidir si consideramos que IPv4 es
>> un protocolo que esta "agotado" o que debe de agotarse en "x" años y
>> como fomentarlo al principio (reducciones de impuestos para vehículos
>> no contaminantes) y como obligarlo para los rezagados (prohibición de
>> circular con esos carros). Y hablamos aquí de protocolo, de una
>> realidad medible y certera, mientras que, si evaluamos el manual de
>> políticas, podríamos ver muchas "subjetividades" que como comunidad
>> hemos decidido.
>> >
>> > Si quieres conducir por zonas que no "contaminan a nadie" (y
>> todo es relativo), como montes o desiertos, o donde el impacto es
>> "menor", se te puede dar mas plazo.
>> >
>> > Ojo que hay un detalle muy importante, que quizas algunos no
>> aprecian. No obligamos a dejar de usar IPv4 o a no proporcionar
>> servicio con él, sino que cuando despliegas IPv6 a tus clientes, eso
>> "ocurre" de una forma natural, y por eso esos % de tráfico IPv6 se
>> producen sin mayor esfuerzo (una vez hecho el despliegue) y en
>> cambio, tu opex y capex IPv4 se pueden reducir, si lo haces bien
>> (ejemplo IPv6-only + IPv4aaS frente a dual-stack).
>> >
>> >
>> > Saludos,
>> > Jordi
>> > @jordipalet
>> >
>> >
>> >
>> > El 13/4/21 19:50, "Politicas en nombre de Nicolas Antoniello"
>> <politicas-bounces at lacnic.net en nombre de nantoniello at gmail.com>
>> escribió:
>> >
>> > Hola Jordi,
>> >
>> > Tratando únicamente uno de los puntos que mencionaste, una
>> cosa es
>> > pedir que las direcciones que el RIR asigna sean
>> utilizadas, esto es,
>> > asignadas a clientes. Y otra muy diferente (con la que en
>> principio
>> > discrepo completamente) es exigir % de tráfico de un
>> determinado
>> > protocolo... hay un millón de razones (técnicas y no
>> técnicas) por las
>> > cuales eso es sumamente subjetivo y particular de cada
>> operador y de
>> > hecho muchas de esas razones son ajenas al propio operador.
>> >
>> > Es como si el Ayuntamiento en tu ciudad te exigiera que
>> para poder
>> > tener un vehículo tienen que utilizarlo al menos 125 veces
>> al mes...
>> > no, te piden que tengas todo el regla, pero el % de uso es
>> cosa tuya y
>> > solo tuya.
>> >
>> > Saludos,
>> > Nico
>> >
>> >
>> > El mar, 13 de abr. de 2021 a la(s) 14:38, JORDI PALET
>> MARTINEZ via
>> > Politicas (politicas at lacnic.net) escribió:
>> > >
>> > > Respecto de la falta de medidas coercitivas, creo que no
>> es el caso, si existen.
>> > >
>> > > Una vez que tenemos en marcha cualquier política, hay
>> que intentar que se verifiquen de forma periódica, y eso ya lo
>> tenemos reglamentado con la política que consensuamos no hace tanto:
>> > >
>> > > 7. REVOCACIÓN Y DEVOLUCIÓN DE RECURSOS
>> (https://www.lacnic.net/550/1/lacnic/)
>> > >
>> > > Una cosa que podría ayudar, y que considero que no
>> supone mucho trabajo si se hace progresivamente, según la
>> disponibilidad de recursos, ya lo he comentado con el staff, es
>> convertir eso en un "dashboard" para que los que tienen recursos,
>> puedan ver su nivel de cumplimiento de las políticas que se van
>> agregando a ese dashboard, incluso que se les envíen alertas, etc. El
>> esfuerzo adicional es mínimo - una vez que hay un test para una
>> determinada parte del manual, que es automático y repetitivo, solo
>> hay que agregar el "widget" correspondiente en el dashboard. Esta
>> claro que debemos presuponer que todos buscamos el cumplimiento y no
>> la mala fe, así que cualquier ayuda que se proporcione para advertir
>> de posibles incumplimientos, debe ser algo muy positivo, y solo si
>> tras alertas, se mantiene el incumplimiento, entonces el staff debe
>> ser alertado para una verificación manual, etc.
>> > >
>> > > Esto es en AFRINIC una propuesta de política
>> (https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal),
>> porque ellos no tienen algo equivalente a nuestra sección 7 del
>> manual, pero aquí creo que no necesitamos una política, porque puede
>> ser algo operacional (convertir en algo gráfico la sección 7, dentro
>> de mylacnic).
>> > >
>> > > Ahora bien, hay que buscar, en el caso de la propuesta
>> de Fernando, una forma de "medirlo", que sea automatizable.
>> > >
>> > > Por eso en su momento, quizás fue en la primera versión
>> de esta propuesta, a raíz de un comentario de Nico, propuse que
>> quizás había que medir el grado de adopción por niveles de tráfico:
>> > >
>> https://mail.lacnic.net/pipermail/politicas/2020-February/005352.html
>> > >
>> > > Esto cada vez es mas fácil:
>> > >
>> > > 1) Porque esas medidas, las tenemos por ASN disponibles
>> de forma pública y neutral (https://stats.labs.apnic.net/ipv6)
>> > > 2) Porque sabemos que una red que despliega IPv6, en
>> función de si sus clientes son mayoritariamente residenciales o
>> corporativos, los % de tráfico IPv6 sobre la parte donde ha hecho el
>> despliegue, son conocidos, crecientes y muy simétricos de unas a
>> otras redes.
>> > >
>> > > Por ejemplo, una red celular alcanza fácilmente el 90%
>> de tráfico IPv6. Obviamente no tenemos que "pedir" que cumpla el 90%,
>> pero y si nos basta con pedir el 30% al cabo de x meses, 60% un año
>> después, etc.
>> > >
>> > > Igualmente, en una red residencial, sabemos que el
>> tráfico IPv6 pasa a ser como poco el 75%, y fácilmente hasta el 85%,
>> pues pidamos inicialmente el 25%.
>> > >
>> > > En base a esos parámetros, y teniendo en cuenta que en
>> redes corporativas el tráfico es menor, podemos establecer un baremo
>> y no pedir "todo" inicialmente, si no en pasos progresivos.
>> > >
>> > > Y eso puede ser monitorizado de forma periódica y
>> automática, sin un "gran" esfuerzo de desarrollo, con un acuerdo con
>> APNIC para que esos datos sean proporcionados (si no lo están ya) con
>> algún mecanismo tipo JSON, etc.
>> > >
>> > > Parece mas complejo, pero creo que en realidad es
>> *menos* complejo que la forma "documental" en la propuesta actual, y
>> quizas, debe ser otra propuesta, y que aplique a todos los miembros,
>> y que la aplicación de los baremos y plazos, obviamente, dependa de
>> si es para delegaciones iniciales, existentes, o transferencias
>> (donde entraría la propuesta de Fernando). E insisto, la gran ventaja
>> es que esos baremos se pueden 1) monitorizar de forma automatizada y
>> 2) ajustar cada 2-3 años, según avance el despliegue de IPv6.
>> > >
>> > > Saludos,
>> > > Jordi
>> > > @jordipalet
>> > >
>> > >
>> > >
>> > > El 13/4/21 18:51, "Politicas en nombre de Fernando
>> Frediani" <politicas-bounces at lacnic.net en nombre de
>> fhfrediani at gmail.com> escribió:
>> > >
>> > > Hola Oscar. Las transferencias de recursos no
>> registradas son un
>> > > problema permanente y están presentes en *cualquier
>> propuesta*, no solo
>> > > en esta. Existen mecanismos administrativos y
>> legales para mitigar y en
>> > > última instancia sancionar a los malos actores que
>> firmaron un contrato
>> > > de acuerdo con las normas vigentes.
>> > >
>> > > La preocupación planteada por algunos acerca de este
>> "pequeño esfuerzo"
>> > > ya ha sido mencionada algunas veces e incluso
>> modificada en el texto de
>> > > la propuesta para dejar aún más claro que no
>> significa simplemente que
>> > > se anuncie IPv6 para DFZ, sino poder demostrar
>> objetivamente bajo
>> > > criterios a ser definidos por el stafff de LACNIC de
>> la misma forma que
>> > > estos criterios ya existen a la hora de justificar
>> el uso en una nueva
>> > > cesión o transferencia de IPv4. Además, en la
>> versión 4 de
>> > > esta
>> > > propuesta, se hizo aún más claro, sin entrar en
>> detalles técnicos y
>> > > operativos, lo que significa el término "partes
>> significativas de la
>> > >
>> > > red" para que no haya dudas sobre los intentos de
>> inventar esta
>> > > percepción de que IPv6 solo está operativo para
>> pasar por la
>> > > transferencia. En muchos casos, el esfuerzo que
>> tendrán que hacer para
>> > > intentar hacer esto puede invertirse en una
>> implementación de IPv6 real.
>> > > No tengo muchas dudas de que todas estas
>> preocupaciones son una pequeña
>> > > parte de los casos, y cuando lo estén, estarán muy
>> bien justificadas si
>> > > tienen que cumplir con este requisito.
>> > >
>> > > La falta de "reglas coercitivas" como se cita en mi
>> opinión hace aún más
>> > > daño al sistema de control de recursos de numeración
>> que tener algunas
>> > > reglas que puede considerarse coercitivo. El
>> "refuerzo positivo" y la
>> > > esperanza de buena voluntad no han funcionado bien
>> hasta ahora.
>> > > Continuar haciéndolo de la misma manera solo traerá
>> los mismos resultados.
>> > > Vea que esta propuesta no tiene nada que ver con la
>> coacción, no
>> > > obligará automáticamente a colocar a quienes no
>> tienen IPv6. Solo
>> > > aquellos que están creando una pérdida para otros
>> que tienen un
>> > > objetivo
>> > > y una contraparte razonablemente fácil de lograr.
>> > >
>> > > Saludos e gracias por su aporte.
>> > > Fernando
>> > >
>> > > On 13/04/2021 13:24, Oscar A. Robles-Garay wrote:
>> > > >
>> > > > Gracias por el seguimiento Fernando.
>> > > >
>> > > > Como en toda política, debemos ser concientes no
>> solo de las
>> > > > consecuencias deseadas (Happy Path), sino tambén
>> de las consecuencias
>> > > > inesperadas. No estamos intentando resolver una
>> ecuación matemática,
>> > > > sino que estamos intentando regular conductas de
>> actores privados que
>> > > > toman decisiones en función de sus necesidades de
>> negocio.
>> > > >
>> > > > Por lo anterior, de aceptarse esta propuesta,
>> debemos asumir que los
>> > > > operadores encontrarán "otras vías" para atender
>> sus necesidades si
>> > > > los mecanismos actuales no les ayudan a resolverlas:
>> > > >
>> > > > * Transferencias de recursos no registradas
>> > > > * Renta/alquiler de recursos
>> > > > * En el mejor de los casos, realizarán un
>> pequeño esfuerzo para
>> > > > cumplir el requisito de "despliegue de IPv6",
>> mismo que apagarán
>> > > > en cuanto pasen la prueba y encenderán una vez
>> que haga real
>> > > > sentido de negocio (business case).
>> > > >
>> > > > Si logramos que estas consecuencias inesperadas
>> sean la minoría de
>> > >
>> > > > casos, entonces tu propuesta habrá sido un éxito
>> (pues la mayoría
>> > > > siguió el happy path).
>> > > >
>> > > > Sin embargo, debido a las dificultades para
>> determinar con certeza el
>> > > > nivel de transferencias fuera del sistema (a menos
>> que seas un broker)
>> > > > nos quedaremos con la incertidumbre y habremos
>> abonado al
>> > > > establecimmiento de reglas coercitivas que no
>> sabemos si están
>> > > > ayudando al desarrollo de Internet, pero sí lo
>> estan haciendo más
>> > > > complejo y contrario al espíritu de adopción
>> voluntaria de sus protocolos.
>> > > >
>> > > > Saludos,
>> > > >
>> > > > Oscar
>> > > >
>> > > > On 13/4/21 13:05, 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
>> > >
>> > >
>> > >
>> > > **********************************************
>> > > 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
>> > _______________________________________________
>> > 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
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list