[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Arturo Servin
arturo.servin at gmail.com
Tue Jan 21 07:32:36 -02 2020
En contra de la politica.
- No creo que sea necesaria
- Dado que añade requisitos para una transferencia puede hacer las
politicas de transferencias inter-RIR incompatibles (o mas incompatibles)
con otros RIRs
- No creo que ayude a acelerar la implementacion de IPv6 ya que es trivial
demostrar que se usa IPv6 sin en realidad tener una implementación.
- Añade operación a LACNIC en tener que verificar que IPv6 siga funcionando
en el ISP.
- Al dia de hoy con el despliegue que existe de IPv6, es en realidad una
decision del ISP de riesgo y negocio el seguir en IPv4 y no implementar
IPv6. Es decir, no es necesario que LACNIC persiga ISPs.
Saludos
as
On Mon, Jan 20, 2020 at 11:10 PM JORDI PALET MARTINEZ via Politicas <
politicas at lacnic.net> wrote:
> Hola Fernando,
>
>
>
> El 20/1/20 22:56, "Politicas en nombre de Fernando Frediani" <
> politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com> escribió:
>
> Hola Jordi
>
> Gracias por tus comentarios
> La exención para IPv6 fue colocada pensando en los pocos casos que
> ocurrirán en los que algunas upstreams 'retrasadas' aún no tienen
> soporte para IPv6 y esto no podría dañar a una organización que se
> encuentra en la situación de transferencia debido a una deficiencia de
> un tercero sobre el cual ella no tiene control.
> Sí, es cierto que esto podría tratarse de otras maneras, pero podría
> generar conflictos entre el cliente y el upstream y, a menudo, hay
> contratos vigentes que deben cumplirse (con o sin IPv6). La intención
> de
> la propuesta no es causar conflictos entre organizaciones, sino solo
> tener el compromiso de que aquellos que están transfiriendo cada vez
> más
> IPv4 tendrán el IPv6 asignado por LACNIC operativo en sus
> organizaciones.
> Creo que en la práctica habrá muy pocos casos, así que considero justo
> que en tales casos se pueda renunciar a la obligación.
>
> Si dejas abierta la puerta a la excepción, bajo mi punto de vista, surgen
> mas y mas casos. No quería mencionarlo explícitamente, por aquello de no
> hacer publicidad a nadie, pero dado que al menos hay un proveedor HE, que
> proporciona IPv6 con túneles y con BGP, sin cargo, creo que la excepción es
> innecesaria.
>
> También tenga en cuenta que las organizaciones que declaran por
> escrito
> que no tienen IPv6 si algún día les toca transferir direcciones IPv4,
> pueden ser impedidas debido a este hecho hasta que demuestren que IPv6
> ya está operativo.
>
> No entendí esto. Te refieres como donantes o como receptores? Entiendo que
> el texto solo se refiere a receptores, pero insisto en que, si el problema
> es el upstream provider, ese problema no existe en realidad.
>
> Y que dependerá del staff de LACNIC definir los requisitos mínimos,
> que
> pueden o no ser el caso para escenarios de multihoming.
>
> Creo que no debemos mezclar si hay o no multihoming. Si hay un solo
> proveedor de IPv6, a mi me parece suficiente, haya o no haya varios
> proveedores de IPv4.
>
> Con respecto a la pregunta sobre afectar solo a los ISP y no a los
> usuarios finales, no creo que sea así porque esta parte del manual se
> aplica a cualquier organización que desee transferir direcciones IPv4.
> Dice el texto de la sección 2.3.2.18: "*Se permitirán transferencias
> de
> direcciones IPv4 entre LIRs y/o usuarios finales...*". Con respecto a
> la
> falta de la palabra "assigned", esto se puede dejar mas claro en una
> nueva version. Gracias.
>
> Si mejor, porque en caso contrario puede parecer una contradicción, aunque
> me queda claro que tu intención es que afecte a ambos.
>
> Con respecto a las verificaciones periódicas, no sé si entendí
> correctamente, pero veo que la verificación debe hacerse en el momento
> de la justificación y una vez aprobada, no se realizarán futuras
> verificaciones. Como analogía, tomemos como ejemplo la validación del
> contacto de abuso, que fue una discusión muy extensa sobre cómo se
> podría hacer automatizado. Una validación como la que usted sugiere
> sería aún más compleja y tal vez no sea muy efectiva, quizás poniendo
> una carga de trabajo muy grande en el equipo de LACNIC.
>
> Yo no lo veo así. El texto que propones no busca "promesas de que se va a
> utilizar IPv6", sino que ya esta está usando. Por lo tanto, si esta
> propuesta alcanza consenso y LACNIC ha puesto en marcha (al implementar
> LAC-2019-9), las verificaciones periódicas, ya sabe si ese ISP/usuario esta
> usando realmente IPv6 y por lo tanto no hace falta (en principio) mirar
> documentación adicional (aunque la puede pedir). Es más, se puede ver el
> historial de verificaciones periódicas anteriores. Si el proveedor lo acaba
> de poner en marcha, vasca con que LACNIC haga "click" en la verificación
> automática para que se compruebe cual es el estado en ese momento.
>
> Sin embargo, veo que no es algo totalmente irracional y quién sabe en
> el
> futuro que podría ser algo para evaluar y el resultado de una
> propuesta
> futura cuando, si llega a un consenso, está entrando en vigor.
>
> Saludos cordiales.
> Fernando Frediani
>
> On 19/01/2020 19:23, JORDI PALET MARTINEZ via Politicas wrote:
> > Hola Fernando,
> >
> > Mil gracias por esta propuesta. Me parece muy importante y necesaria.
> >
> > Mis comentarios podrían variar en función de la traducción al
> Castellano, tal y como comenté en otra propuesta anterior, ya que solo el
> texto en Castellano es el oficial para el manual de políticas, pero supongo
> que sería fácil resolverlo (si fuera el caso) cuando tengamos la traducción.
> >
> > Aunque no es texto de la política (y por lo tanto no podría ser
> hecho efectivo), no estoy de acuerdo con "In the case the receiver provides
> a written statement from its upstream that IPv6 connectivity is
> unavailable, the IPv6 requirement may be waived.".
> >
> > NO hay excusas, bajo mi punto de vista, para tener un upstream
> provider que tenga soporte de IPv6, ya que, si es preciso, se puede usar un
> túnel, incluso con soporte BGP. Yo he trabajado en varios casos en los que
> esto ocurría y siempre lo hemos podido resolver, pues los "upstream"
> providers del uptream provider, lo pueden proporcionar, además que hay
> upstream providers que lo ofrecen incluso sin coste.
> >
> > Para el texto de la propuesta, he hecho un diff-online que me ha
> ayudado a revisar las diferencias y supongo que puede ser útil para otros:
> >
> > https://www.diffchecker.com/MaapyXNc
> >
> > Creo que hay algo que debemos considerar, y es que tal y como esta
> redactada la propuesta solo afectaría a los ISPs (allocations), y no a los
> end-users (assignments). Creo que esto no es correcto y debería ser igual
> para ambos.
> >
> > Por lo tanto, sugiero este cambio, que también tiene en cuenta mi
> comentario anterior de los upstream providers así como que en lugar de
> documentación, creo que el staff puede usar la recién aprobado política
> LAC-2019-9 para hacer esas verificaciones de forma automatizada y por tanto
> evitar la necesidad de generar documentación adicional o de revisarla, a
> ambas partes, en los casos en los que sea obvio que hay despliegue real de
> IPv6.
> >
> > 2.3.2.18.3 Receiving organization must have LACNIC
> allocated/assigned IPv6 space and be able to prove it is being used by
> providing LACNIC documented network deployment details to prove IPv6 is
> operational in significant parts of the network.
> >
> > Regular LACNIC periodical verification (7.1) will be used to assess
> that IPv6 is operational, and if necessary, the staff may require further
> information to validate this requirement.
> >
> >
> >
> > Saludos,
> > Jordi
> > @jordipalet
> >
> >
> >
> > El 17/1/20 17:47, "Politicas en nombre de Fernando Frediani"<
> politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com> escribió:
> >
> > Hola a todos.
> >
> > Dos aclaraciones:
> >
> > - El cambio principal en el texto propuesto se encuentra en el
> ítem
> > 2.3.2.18.3. Todos los demás elementos siguientes permanecen sin
> cambios
> > y solo se vuelven a numerar al número siguiente .
> > - La forma en que se analizará esto no es diferente de lo que
> se ha
> > hecho para la justificativas de asignaciones de IPv4 a lo largo
> de los
> > años. El staff de RIR/NIR de la misma manera revisará las
> > justificaciones y también establecerá los criterios mínimos
> para esto.
> >
> > Saludos cordiales
> > Fernando Frediani
> >
> > On 17/01/2020 13:15,info-politicas at lacnic.net wrote:
> > > [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 ainfo-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
> contactinfo-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
> >
> >
> >
> >
> > **********************************************
> > 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
>
More information about the Politicas
mailing list