[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Arturo Servin
arturo.servin at gmail.com
Mon Feb 3 13:19:38 GMT+3 2020
Pregunta sencilla a los autores. Qué problema intentan resolver con esta
política?
Y por favor no digan que el despliegue de IPv6 porque eso sería una falacia
total.
Saludos
as
On Mon, Feb 3, 2020 at 4:59 PM Mike Burns <mike at iptrading.com> wrote:
> Hi Jordi,
>
> Inter-RIR or not, the number of transfers intra-regionally is really
> shockingly low by other regions' intra-regional transfer counts.
>
> I have perspective. I have brokered close to 1000 transfers in more than
> 80 countries.
> There is something really wrong with the LACNIC transfer market, and it's
> not simply the lack of Inter-RIR.
>
> If every recipient of an IPv4 transfer in LACNIC demonstrated the ability
> to route an IPv6 block, would that have made any dent in IPv6 penetration?
>
> Highly doubtful. Do you think it's appropriate to add this regulation on
> top of an anemic market before waiting to see if the Inter-RIR policy will
> accelerate transfers? Only with more transfers could this policy make any
> sense at all, unless the intent is to simply strangle the LACNIC IPv4
> market in its crib.
>
> Regards,
> Mike
>
>
> -----Original Message-----
> From: Politicas <politicas-bounces at lacnic.net> On Behalf Of JORDI PALET
> MARTINEZ via Politicas
> Sent: Monday, February 03, 2020 10:43 AM
> To: Lista para discusion de politicas de la comunidad de LACNIC <
> politicas at lacnic.net>
> Cc: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> Subject: Re: [LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta
> LAC-2020-1 / New proposal LAC-2020-1
>
> Hi Mike,
>
> With all the respect, as I explained in a previous email, we can't "at
> this time" compare the number of transfers in LACNIC vs other regions
> (unless you compare them with AFRINIC only), because the inter-RIR
> transfers have not been yet implemented.
>
> May be by this time, next year, when the inter-RIR transfers have been
> running for a few months (if I recall correctly, they are expected to be
> implemented around July 2020), we can do that comparison in similar terms.
>
> I also see that Carlos is right here. Let's see if the staff can provide
> some stats about how many of the resource holders involve in the 77
> transfers, are already doing IPv6.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 3/2/20 16:30, "Politicas en nombre de Mike Burns" <
> politicas-bounces at lacnic.net en nombre de mike at iptrading.com> escribió:
>
>
>
> Hola/Olá/Hi Mike, Jordi, Fernando, ...,
>
> Parece que el comercio de direcciones no es una gran cosa dentro de la
> región de LACNIC!
>
>
> Hi Carlos,
>
> That seems to be uncontested. Thank you for noticing my post. Despite
> proponents of this policy scaring the community, the market in LACNIC is
> the "sick man" of the IPv4 world. Nobody is acquiring much IPv4 via
> transfer in LACNIC, but the proponents would indicate that without adding
> an additional burden, some entities would acquire "more and more" IPv4
> without deploying IPv6.
>
> This policy will do nothing to increase IPv4 because the population of
> transferrers in this community is so small. So why make it smaller still
> through worthless burdens for participants and for LACNIC staff?
>
> There is something wrong with a group of number stewards aggrandizing
> other roles for themselves by leveraging their legitimate number
> registration role. So we have the right to register numbers, why not use
> that to demand things from those over whom we have some power? Why not
> mandate any IPv4 market participant must have a diverse workforce or
> boardroom? Why not mandate that they should only run hardware newer than
> five years old? Why not mandate anything we think is a good thing?
>
> Because that is not our role, and doing these things work directly
> against our role.
> Our primary role is to keep an accurate Whois database. If you want
> un-recorded transfers, you are providing additional incentive with this
> policy.
>
> The market is adaptable and will provide a workaround, like
> out-of-region registrations and leasing, neither of which this community
> has much control over.
> Should this proposal pass, it will begin a cat-and-mouse game with
> network providers offering a cheap IPv6-announcement service to jump
> through this hoop, and LACNIC staff trying to move the hoop and make it
> smaller.
> Pointless in terms of moving the needle on IPv6, which will only
> respond to more rational inputs.
>
>
> Regards,
> Mike
>
>
>
>
>
>
>
> Sería bueno saber cuántas organizaciones estaban en el extremo
> receptor de esas 77 transferencias.
>
> Entonces, sería bueno comprobar cuántos de ellos NO están haciendo
> ningún IPv6.
>
> No entiendo este posible nuevo requisito como una carga.
>
> Por lo tanto deseo expresar pleno apoyo para 2020-1!
>
> Saludos/Cumprimentos/Regards,
> Carlos
>
>
>
> On Tue, 21 Jan 2020, Mike Burns wrote:
>
> > Hi Jordi,
> >
> > I hope you are well.
> >
> > LACNIC has only had 77 successful transfers in its history.
> > Take a moment to think about that.
> > In the same time period ARIN and RIPE did over 20,000.
> > And you want to impose more burdens?
> >
> > Opposed.
> >
> > Regards,
> > Mike
> >
> >
> > -----Original Message-----
> > From: Politicas <politicas-bounces at lacnic.net> On Behalf Of JORDI
> > PALET MARTINEZ via Politicas
> > Sent: Tuesday, January 21, 2020 9:50 AM
> > To: Lista para discusion de politicas de la comunidad de LACNIC
> > <politicas at lacnic.net>
> > Cc: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> > Subject: Re: [LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova
> > proposta LAC-2020-1 / New proposal LAC-2020-1
> >
> > Hola Fernando, Arturo,
> >
> > El 21/1/20 15:13, "Politicas en nombre de Fernando Frediani" <
> politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com> escribió:
> >
> > Hola Arturo
> >
> > Estoy convencido de que los requisitos de transferencia NO los
> hacen
> > incompatibles. Cada RIR puede tener sus requisitos de
> transferencia. Es
> > precisamente por esta razón que el texto dice en 2.3.2.18.2: "If
> the
> > receiving organization is part of another region, it will be
> subject to
> > the criteria, verifications and requirements of the corresponding
> RIR.".
> > De lo contrario, esto texto no sería necesario y todas las
> políticas y
> > requisitos en los 5 RIR tendrían que ser idénticas.
> >
> > Aunque Fernando puede tener razón, creo que se presta a
> interpretación, ya que el punto 2.3.2.18.2 se refiere a la justificación de
> la necesidad, o al menos se lee como tal. Por ese motivo, en la propuesta
> de transferencias redactamos el punto 2.3.2.18.10. como "Legacy resources
> transferred into the LACNIC region will no longer be considered legacy
> resources.".
> >
> > Creo que es mejor evitar la duda o posibilidades de interpretación
> para no perder la reciprocidad con ARIN (creo que sería el único caso,
> salvo que la propuesta de AFRINIC que se apruebe en el futuro, haga algo
> parecido a lo que hace ARIN).
> >
> > Es diferente, por ejemplo, de otras propuestas que solo preveían
> > transferencias unidireccionales, estos sí no tendrían
> reciprocidad. Esta
> > continúa permitiendo transferencias en ambas direcciones y no
> cambia
> > nada en los requisitos de organizaciones en otros RIR.
> >
> > No solo, ARIN según me consta, pide que no haya otros aspectos que
> les limiten a ellos. Si se interpreta (aunque no sea tu intención, que creo
> que no lo es), que en transferencias de LACNIC a ARIN también el (receptor)
> tiene que justificar que tiene IPv6 operativo, no sería reciproco y además
> es absurdo que una política de LACNIC pretenda imponer reglas en otra
> región.
> >
> > Creo que está claro que esta propuesta solo agrega un requisito
> para las
> > transferencias IPv4 Intra o Inter RIR de las organizaciones
> *receptoras
> > dentro de LACNIC*, sin embargo, si es necesario, podemos ajustar
> el
> > texto de la propuesta a: "2.3.2.18.3 Receiving organization in
> LACNIC
> > 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."
> >
> > Perfecto! Así no hay dudas!
> >
> > Observe también que la demostración de tener IPv6 operativo no
> presupone
> > simplemente subir una red IPv6 pequeña y poder comunicarse a
> través de
> > ella. Como dice el texto, la organización debe demostrar detalles
> de la
> > implementación y demostrar que IPv6 está operativo *en partes
> > significativas* de la red. Además, el staff de LACNIC definirá los
> > criterios mínimos para llevar a cabo estos controles. Por lo
> tanto, de
> > ninguna manera es un proceso trivial.
> >
> > Exacto y de acuerdo con ello! Evitamos entrar en aspectos
> operacionales de la implementación de la propuesta, si lo podemos evitar.
> >
> > Siempre se ha hecho un proceso muy similar y sigue siendo para
> IPv4.
> > Quien recibe IPv4 por primera vez o quien transfiere IPv4 ya
> tiene que
> > demostrar, mediante documentación y otros métodos, que tienen la
> > necesidad de ese espacio. No hay mucha diferencia en hacer lo
> mismo para
> > IPv6.
> >
> > Con respecto al comentario de añadir operaciones a LACNIC en
> tener que
> > verificar que IPv6 continúa funcionando *no es el objeto de esta
> > propuesta*, por lo que no se aplica.
> >
> > Así es, eso ya lo hace la propuesta que permite recibir IPv6. Dice
> bien claro que es para usarlo, no para acumularlo sin mas.
> >
> > La decisión de tener operacional o no IPv6 sigue siendo una
> decisión del
> > ISP. Esta propuesta no obliga a ninguna organización a
> implementar el
> > IPv6 tan pronto como se ratifique esta propuesta. Si lo desea,
> puede
> > continuar otros 20 años sin IPv6.
> >
> > Estaría loco, pero es correcto.
> >
> > Lo único que hace es establecer una condición que, en el caso de
> que la
> > organización desee transferir más y más bloques de IPv4, debe
> demostrar
> > tener IPv6 operativo como una forma de compromiso con los demás
> porque
> > no es solo algo privado y eso afecta solo a esa organización,
> sino que
> > todos los demás que se interconectan con él en este ecosistema.
> > LACNIC no perseguirá a nadie porque esta propuesta no dice que
> debería
> > ir de una organización a otra y les ordena implementar IPv6 en
> ningún
> > momento.
> >
> > Y me parece lo lógico. Si pides IPv6 es para utilizarlo, sino no lo
> pidas. Si pides IPv4 es para utilizarlo, sino no lo pidas. Ahora bien, como
> no hay mas IPv4, no pretendas recibir mas, aunque sea con transferencias,
> si no haces un esfuerzo con IPv6, porque entonces, estas evitando que otros
> que, si que lo harán, puedan obtener IPv4.
> >
> > Alguien podría aprovecharse de las transferencias para acumular
> IPv4, quizás haciendo trampas en las solicitudes, para luego alquilarlo o
> volver a transferirlo, y con esta propuesta evitamos ese abuso.
> >
> > Saludos
> > Fernando Frediani
> >
> > On 21/01/2020 06:32, Arturo Servin wrote:
> > > 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
> > >>
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> 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
>
More information about the Politicas
mailing list