[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Jan 21 11:36:45 GMT+3 2020
Hola Fernando,
El 21/1/20 15:11, "Politicas en nombre de Fernando Frediani" <politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com> escribió:
Hola Jordi
Algunos comentarios en línea.
On 20/01/2020 19:09, JORDI PALET MARTINEZ via Politicas wrote:
> 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.
Al principio, creo que esta no es una excepción que es tan fácil de
eludir o de usar genéricamente. La mayoría de las empresas medianas y
grandes no podrán proporcionar una carta como esta "solo para ayudar al
cliente", ya que es bien sabido que ya tienen IPv6 en funcionamiento en
la red.
Quizás entonces la redacción tiene que ser mas explicita para casos realmente extremos y justificados ... sigue leyendo ...
Con respecto a la posibilidad de usar túneles, sabemos que puede haber
limitaciones técnicas críticas para esto.
Un ejemplo es la fragmentación de paquetes debido a MTU.
El otro, hablando específicamente de HE, es que no tiene tunel
end-points en América Latina (con la excepción de Colombia lo más
cercano é en Miami), y esto podría implicar un aumento demasiado en la
latencia para la operación de un ISP.
HE no es la única opción. He trabajado en muchos otros casos con muchos otros proveedores que si su cliente no tiene IPv6, proporcionan un túnel a los clientes "de su cliente". Con lo cual aquí no hay afección de retardo adicional (y posiblemente tampoco de MTU).
Los túneles entre operadores no necesariamente están limitando la MTU, porque puedes configurar la MTU en ambos extremos para que sea en lugar de 1.500, 1520 y arreglas el problema.
Igualmente, el retardo adicional creo que no es un problema, porque habitualmente, ya es común que las redes de LAC tengan sus upstreams "colgando" de Miami. Lo único que hay que hacer es configurar el túnel para el tránsito/s, pero al mismo tiempo mantener dual-stack (sin túnel) para los IXs.
Quizás, hay que expresar con mas claridad esas excepciones para llegar a un punto de acuerdo.
"In the case the receiver provides a written statement from its upstream(s) that IPv6 connectivity is unavailable, and justification that other means aren't technically acceptable, the IPv6 requirement may be waived."
>
> 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.
Si un upstream declara por escrito que no tiene IPv6 operativo,
automáticamente se le impide realizar transferencias de IPv4 hasta que
lo tenga. Además, como se menciona en muchos casos, es público y notorio
que el muchos ISPs tiene IPv6 operativo.
Tenga en cuenta que el requisito es tener IPv6 operacional y eso no
significa 100% de IPv6 en la red, por lo que si tiene IPv6 en
funcionamiento, sin embargo, no puede proporcionar una conexión con
soporte de IPv6 para ese cliente en este caso, en mi lectura, no
encajaría. Tendremos que esperar para ver los requisitos mínimos que se
aplicarán.
Totalmente de acuerdo.
Sin embargo, después de sus comentarios, estoy evaluando mejor qué
situaciones mas serían posibles para 'eludir' la justificación y caer en
esta excepción. Si puedo pensar en más escenarios, volveré a comentar aquí.
Me gustaría saber más comentarios de colegas sobre este punto. De hecho,
es importante que si la comunidad entiende que esta excepción se
mantiene, no hay posibilidad de ser abusada en el futuro y aplicarse
solo en casos realmente justos.
Creo que el texto que he puesto antes, puede ser suficiente y evita el abuso, porque no solo se justifica la falta de IPv6 en los upstreams, no es suficiente, salvo que también haya una justificación técnica acerca de que otras opciones no son aceptables, para ese caso.
> 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.
Es mi lectura también.
> 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.
Pero todavía aun no entiendo tu intención aquí. Si está sugiriendo que
alguien que ha demostrado tener IPv6 operativo en el pasado y deja de
tener, tiene que pasar por un proceso de recuperación, creo que esto
debería ser parte de otra propuesta dirigida a situaciones de
recuperación como se acaba de hacer en LAC-2019-9. Es una discusión
válida, pero no estoy seguro de si podría o debería abordarse en esta
misma propuesta.
No, en absoluto quiero decir, eso. Lo que quiero decir, es que en lugar de pedir documentación "siempre", si la verificación periódica que realizará la implementación de LAC-2019-9 es suficiente no debería ser necesario pedir mas documentación y por lo tanto solo se debería pedir documentación adicional, cuando haya dudas. A nadie le gusta preparar documentos cuando no es necesario (LACNIC ya ha validado la operatividad de IPv6).
Este es el texto que propongo para ello:
"Further documentation may be requested by the staff, in case the LACNIC periodical verifications aren't sufficient to assess that IPv6 is operational."
Por otro lado, creo que una organización que puede pasar por la
justificación de demostrar que tiene IPv6 operacional para poder
realizar transferencias es poco probable que elimine IPv6 de la red
Totalmente de acuerdo, creo que no se entendió lo que indique en el email anterior.
después y ya no lo tenga porque el texto dice "partes significativas de
la red" más allá de los requisitos mínimos que seran definidos y esto
significa que no será fácil o tan simple habilitar IPv6 solo para pasar
la justificación.
Precisamente! Si tienes que pasar una justificación o hacer una validación cuando necesitas una transferencia, es "fácil" hacer trampas o presentar documentos que no sean reflejo de la situación real. Si en cambio permites a LACNIC que se base, en las verificaciones anteriores (que nadie sabe cuando tienen lugar, porque es un proceso periódico), es más difícil hacer trampas.
Saludos
Fernando Frediani
> 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 contacteainfo-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 seguintee-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, pleasecontactinfo-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
**********************************************
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.
More information about the Politicas
mailing list