[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1

Thu Jan 30 14:45:33 GMT+3 2020

Fernando,

Muchas gracias por las aclaraciones.
Me refiero a un nuevo miembro también.

Saludos,
Nico

El El jue, ene. 30, 2020 a la(s) 13:06, Fernando Frediani <
fhfrediani at gmail.com> escribió:

> Estimados, algunas aclaraciones.
>
> Uesley - El análisis de la verificación de que IPv6 está operativo será
> realizado por el RIR. Como dice el texto de la propuesta, el staff de lo
> RIR definirá un criterio mínimo para garantizar que IPv6 esté operativo
> en la red y debe llevar a cabo un análisis de la documentación de
> implementación que demuestre los detalles donde se implementa IPv6 en la
> red.
>
> Esto no es muy diferente de lo que ya se hace hoy cuando alguien
> necesita justificar el uso de IPv4 para recibir una nueva asignación (en
> el caso de nuevos participantes) o recibir transferencias de IPv4 de
> otro ASN.
>
> Por lo tanto, no será suficiente simplemente anunciar el prefijo IPv6 a
> DMZ y poder comunicarse a través de Internet, sino demostrar de manera
> efectiva que se está implementando en partes importantes de la red y no
> en una pequeña parte que se hace solo para satisfacer este requisito de
> esta propuesta.
> Como nadie espera tener el 100% operativo para esto, se definirá un
> criterio mínimo razonable.
>
> Nico - Correcto. Como se mencionó en otros mensajes anteriores, esto
> solo se aplica a aquellos que reciben transferencias IPv4 (en la próxima
> versión, el texto se ajustará para hacerlo aún más claro). De la misma
> manera que para recibir los bloques de IPv4 deben demostrar que tienen
> uso para ellos, esta propuesta dice que también tendrán que demostrar
> que tienen IPv6 operativo en la red como una demostración de compromiso
> con los demás, porque si no lo hacen, agravarán aún más la situación del
> problema de escasez
>
> No estoy seguro de si la otra pregunta se refiere a una organización que
> tiene direcciones ASN e IPv4, pero nunca solicitó IPv6. Si es el caso,
> primero tendrá que solicitar los bloques IPv6, realizar la
> implementación para que pueda cumplir con este requisito mínimo. El
> razonamiento para esto es el mismo que en otros casos. No es razonable
> para los demás que en 2020 alguien ni siquiera tenga una asignación de
> IPv6 y quiera transferir más bloques de IPv4.
>
> Saludos Cordiales
> Fernando Frediani
>
> On 30/01/2020 11:23, Nicolas Antoniello wrote:
> > Estimados,
> >
> > Me surgen ahora dos consultas:
> > - Esto aplicaría solo a quien recibe y no a quien entrega?
> > - Que sucede si quien recibe no tiene aún espacio de direccionamiento, no
> > podría recibir una transferencia pues no tendría IPv6 y menos demostrar
> que
> > lo tiene operativo?
> >
> > Saludos,
> > Nico
> >
> >
> >
> > El El jue, ene. 30, 2020 a la(s) 10:41, Uesley Correa <
> > uesleycorrea at gmail.com> escribió:
> >
> >> Hola a todos,
> >>
> >> Me parece muy buena la propuesta. La Internet como la vemos hoy es un
> >> ecosistema de sistemas autónomos. Y todos sabemos que lo que uno hace
> si lo
> >> hace mal, va reflejar de manera negativa en buena parte del ecosistema.
> En
> >> este tema, si un miembro no quiere implementar IPv6, excelente. Es algo
> que
> >> puede no perjudicar a los demás. Pero todavía lo veo sin ningún sentido
> que
> >> este mismo miembro pida y pueda recibir cada vez más y más IPv4 (ahí si
> va
> >> dañar el ecosistema pues organizaciones que realmente lo necesitan
> pueden
> >> comprobarlo por medio de su compromiso con la utilización del IPv6). No
> me
> >> quedó claro cómo será hecha la análisis de implementación y uso del IPv6
> >> (si solamente basado en DFZ o alguna otra técnica) y si eso puede o no
> >> onerar el trabajo del staff de LACNIC. Pero creo que acá en las
> discusiones
> >> podemos crear técnicas y metodologías para hacer eso posible.
> >>
> >> Saludos,
> >>
> >> Uesley Corrêa - Analista de Telecomunicações
> >> CEO Telecom Consultoria, Entrenamiento y Servicios
> >> CEO Telecom Fiber Solutions
> >>
> >>
> >> Em qui., 30 de jan. de 2020 às 10:14, Rafael Ganascim <
> rganascim at gmail.com
> >> escreveu:
> >>
> >>> Olá,
> >>>
> >>> Eu estou de acordo com a proposta, pois creio que é mais uma forma de
> >>> incentivar a implementação e uso do IPv6, ainda mais para as
> organizações
> >>> sedentas por mais e mais IPv4.
> >>> Nos dias de hoje, demonstrar o uso do IPv6 já deveria ser considerado
> uma
> >>> tarefa básica.
> >>>
> >>> Com os comentários ajustados dos colegas Fernando e Jordi, entendo que
> já
> >>> tenha sido restrito o item 2.3.2.18.3 a organizações pertencentes a
> >> LACNIC,
> >>> assim como o caso onde o IPv6 é tecnicamente impossível de funcionar
> >>> através da justificativa do upstream e também sobre a validação
> periódica
> >>> do LACNIC.
> >>>
> >>>
> >>> Em ter., 28 de jan. de 2020 às 12:26, Fernando Frediani <
> >>> fhfrediani at gmail.com> escreveu:
> >>>
> >>>> Hola Nicolas, gracias por tus comentarios.
> >>>>
> >>>> No sé si viniste a ver los detalles de la justificación de la
> >> propuesta,
> >>>> pero intentaré reproducirlos aquí para profundizar en las razones y
> >>>> motivaciones.
> >>>>
> >>>> En mi opinión, cuando un ISP que transfiere más y más bloques de IPv4
> >>>> sin tener IPv6 operativo está agravando aún más el problema de
> escasez,
> >>>> mucho más de lo que parece. Y este no es solo un problema privado que
> >>>> afecta solo a la organización misma, sino a todos los demás que *se
> >>>> interconectan* en ese ecosistema, después de todo en Internet nadie es
> >>>> un Sistema Autónomo solo.
> >>>> Por lo tanto, lo menos que puede hacer cualquiera que haya transferido
> >>>> más bloques de IPv4 es ser justo con los demás y demostrar que tienen
> >>>> IPv6 operativo en un intento por reducir este problema creciente.
> >>>>
> >>>> Todavía tenemos al menos 10 a 20 años de dependencia significativa de
> >>>> IPv4 en el futuro, y si acciones como esta no se llevan a cabo, muchos
> >>>> problemas y conflictos sucederán y empeorarán, y el lugar más probable
> >>>> en el que tendrán que ser tratados es en el RIR, más especialmente en
> >>>> esta lista de políticas. No hacer nada ahora dificultará mas la
> >>>> resolución de este problema y los conflictos que surjan en el futuro
> >>>> cercano.
> >>>>
> >>>> Además, esta propuesta responde a una llamada del Directorio de LACNIC
> >>>> para propuestas que promueven la implementación de IPv6.
> >>>>
> >>>> Finalmente, algo importante a tener en cuenta es que una de las
> >>>> prerrogativas de este foro es establecer las reglas mínimas necesarias
> >>>> para que los registros se realicen en whois y no hay ningún problema
> en
> >>>> agregar este requisito, ya que hay otros como enviar la documentación
> >>>> necesaria para probar necesidad, de lo contrario ni siquiera podríamos
> >>>> exigir que se haga este.
> >>>>
> >>>> Si este foro comprende que la transferencia de más y más IPv4 sin la
> >>>> contrapartida de tener IPv6 operativo perjudica a toda la comunidad,
> no
> >>>> hay impedimento para exigir este requisito para que se ajusten los
> >>>> registros whois.
> >>>>
> >>>> Un saludo
> >>>> Fernando Frediani
> >>>>
> >>>> On 28/01/2020 12:06, Nicolas Antoniello wrote:
> >>>>> Hola Fernando y lista,
> >>>>>
> >>>>> En principio no estoy de acuerdo con generar políticas que obliguen a
> >>>> IPv6
> >>>>> a cambio de poder transferir bloques IPv4.
> >>>>> Me parece que podríamos estar mezclando temas de una forma muy
> >> forzada.
> >>>>> Se me ocurren varios casos en los que se podrían transferir bloques
> >>> IPv4
> >>>>> sin que ello implique siquiera probar ningún tipo de operación
> >>>> particular.
> >>>>> Repito que en principio no me parece razonable. La necesidad de
> >>>> despliegue
> >>>>> de IPv6 es ya un hecho... y el que no lo haga al único que perjudica
> >>> es a
> >>>>> él mismo (sobre todo pequeños ISPs con necesidad o perspectiva de
> >>>>> crecimiento)... entonces para que nuevas obligaciones cruzadas??
> >>>>>
> >>>>> Otro aspecto no menor es que nuevamente creo que las políticas de
> >>>>> transferencias no son para “autorizar” las mismas sino para mantener
> >>>>> coherencia y vigencia en el registro de Lacnic... el hecho de poner
> >>>>> cualquier tipo de impedimento forzado no va a evitar la transferencia
> >>>> sino
> >>>>> que lo que seguramente suceda es que no quede registro de la misma en
> >>>>> Lacnic (que es justamente lo que no queremos que suceda no?).
> >>>>>
> >>>>> Saludo fraterno,
> >>>>> Nico
> >>>>>
> >>>>>
> >>>>>
> >>>>> El vie., 17 de ene. de 2020 a la(s) 13:16, <
> >> info-politicas at lacnic.net>
> >>>>> escribió:
> >>>>>
> >>>>>> [Português abaixo]
> >>>>>> [English below]
> >>>>>>
> >>>>>> Estimados suscriptores de la Lista de Políticas de LACNIC,
> >>>>>>
> >>>>>> Se recibió una nueva propuesta de Política, se le asignó el id
> >>>> LAC-2020-1.
> >>>>>> Título: Add IPv6 operational as a requirement for IPv4 transfers
> >>>>>>
> >>>>>> 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 by LACNIC 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.
> >>>>>> Para ver el detalle ingrese en:
> >>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1
> >>>>>>
> >>>>>> 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 propuesta?
> >>>>>> - ¿Esta propuesta resolvería un problema que usted está
> >>> experimentando?-
> >>>>>> ¿Ve alguna desventaja en esta propuesta?
> >>>>>> - ¿Qué cambios podrían hacerse a esta 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,
> >>>>>>
> >>>>>> Foi recebida uma nova proposta de Política, foi atribuído o id
> >>>> LAC-2020-1.
> >>>>>> Título: Add IPv6 operational as a requirement for IPv4 transfers
> >>>>>>
> >>>>>> 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 by LACNIC 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.
> >>>>>> Para ver o detalhe acesse:
> >>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1
> >>>>>>
> >>>>>>    Os comentários e os pontos de vista aportados pela comunidade são
> >>>> vitais
> >>>>>> para o bom desenvolvimento do processo das propostas
> >>>>>> - ¿Você é a favor ou contra desta proposta?
> >>>>>> - ¿Esta proposta iria resolver um problema que você está
> >>>> experimentando?-
> >>>>>> ¿Vê alguma alguma desvantagem nesta proposta?
> >>>>>> - ¿Que mudanças poderiam ser feitas à proposta para que seja mais
> >>>> eficaz?
> >>>>>>    Por mais informações entre em contato conosco através do seguinte
> >>>> e-mail:
> >>>>>> info-politicas at lacnic.net
> >>>>>> Atenciosamente,
> >>>>>>
> >>>>>>
> >>
> ______________________________________________________________________________________________________
> >>>>>> Dear LACNIC Policy List subscribers,
> >>>>>>
> >>>>>> A new Policy Proposal has been received and assigned the following
> >> ID:
> >>>>>> LAC-2020-1.
> >>>>>>
> >>>>>> 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 by LACNIC 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.
> >>>>>> To read the proposal, please go to
> >>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1
> >>>>>>
> >>>>>> The community's comments and opinions are essential to the proper
> >>>>>> functioning of the policy development process.
> >>>>>> - Do you support this policy or are you against it?
> >>>>>> - Would this proposal solve a problem you are experiencing?- Do you
> >>>> think
> >>>>>> this proposal has any drawbacks?
> >>>>>> - What changes could be made to this proposal to make it more
> >>> effective?
> >>>>>> For further information, please contact info-politicas at lacnic.net
> >>>>>> Kind regards,
> >>>>>>
> >>>>>> 
> >>>>>> --LACNIC - Latin American and Caribbean Internet Addresses Registry
> >>>>>> Rambla Rep. de México 6125, CP 11400
> >>>>>> Montevideo-Uruguay
> >>>>>> Phone number: +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
>