[LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos
jordi.palet at consulintel.es
jordi.palet at consulintel.es
Thu Aug 13 15:17:47 -03 2026
Hola a todos,
Estoy de acuerdo con la propuesta y concuerdo con Fernando.
Podemos medir el “buen hacer” y no solo de forma instantánea (de hecho, diría que no debemos hacerlo así), tanto de RPKI como de IPv6 como de resolución inversa, como de lo que queramos. De hecho hace años que concretamos esto en una propuesta (https://politicas.lacnic.net/politicas/detail/id/LAC-2019-9/language/sp) que modificaba la sección 7.1 del manual de políticas (https://www.lacnic.net/550/1/lacnic/). Se acordó que LACNIC progresivamente iría automatizando los procesos de verificación.
(no se cuales de ellos están ya automatizados, sería bueno que LACNIC lo confirmara, y si por ejemplo esta previsto verificar RPKI/ROAs, IPv6, etc.).
Considero que hoy en día, determinadas buenas prácticas, que afectan a toda la comunidad, deben incorporarse al manual de políticas de forma progresiva. Esta propuesta lo hace, ya que no obliga, si se alcanza consenso, a hacerlo de forma inmediata, sino que el plazo es el que cada uno pueda (indirectamente pensando que en el futuro puedas necesitar mas direcciones), y solo se obliga cuando se quiere una asignación/distribución adicional.
Igualmente, independientemente de que esta propuesta alcance o no consenso, creo que debemos re-pensar si el uso de IPv6, debe ser un requisito no solo para nuevas asignaciones/distribuciones, sino incluso para mantener las existentes en un plazo de x años. No quiero abrir el debate ahora, pero si alguien quiere entrar, que por favor habrá un nuevo hilo para no confundir ambas discusiones.
Saludos,
Jordi
@jordipalet
> El 13 ago 2026, a las 17:34, Fernando Frediani via Politicas <politicas at lacnic.net> escribió:
>
> Bom dia Fischer
> Ótimos pontos levantados.
>
> Acredito que existem algumas nuances técnicas para discussão e outras mais de administrativas digamos, como perceber e gerir isso no longo prazo.
>
> 1 - A questão de mensurar ROA ou IPv6 entendo as diferenças, mas ainda sim é igualmente possível. Desde que se estabeleçam métricas simples de mensurar é sempre possível.
> Quando da discussão da minha proposta falei que precisamos ter essa coragem e que não necessariamente precisa ser complexo para existir como requerimento, mas o espírito é que a organização se esforce em demonstrar que está fazendo o certo e não apenas de qualquer jeito. Nem o amor é 100% e as vezes falha, então não precisamos tratar a ferro e fogo.
>
> 2 - A questão sobre "estar em conformidade" e não ser "point-in-time" achei bem interessantemente de se olhar e é verdadeira. O argumento - válido - que alguns podem ter é como quem analisar isso (a equipe de LACNIC ou dos NIRs) irá fazer para acompanhar se depois de se transferir/receber recursos eles seguirão em conformidade.
> De novo, não é necessário tratar a ferro e fogo. Não é necessário ter ferramentas sofisticadas e custosas para monitorar isso. Mas se existir algum caso eventual onde foi constatado que a organização deixou de cumprir, faz-se óbvio e coloca-se sobre processo de recuperação para que ela ajuste e volte a cumprir. A ideia não é de ser um caça as bruxas, mas sim de quem operar um Sistema Autônomo tenha um mínimo de disciplina e responsabilidade conhecendo bem suas obrigações.
>
> 3 - Existe uma diferença entre ter IPv6 operacional e ter ROA.
> Não ter ROA é algo que pode prejudicar mais o próprio Sistema Autônomo e deixará os recursos sob sua responsabilidade desprotegidos contra hijack intencional ou não.
> Já optar por não implantar IPv6 causa prejuízo e aumento de custos para todo o ecosistema de internet, principalmente daqueles que fizeram sua parte e implantaram.
> De qualquer maneira sigo enxergando essas possibilidades mais boas como que ruins no resultado final.
>
> Fernando Frediani
>
> On 8/13/2026 11:25 AM, Douglas Fischer wrote:
>> Olá Sergio, Fernando, Oscar, e demais membros da lista.
>>
>> Tomo a liberdade de responder em portugês, porque creio que conversas multilinguais esse seja um hábito que devemos incentivar em nossa comunidade.
>> E também porque me sinto mais à vontade para me expressar.
>> Caso qualquer membro tenha alguma dificuldade de interpretação nas minhas falas em português, peço que solicitem esclarecimentos na conversa via lista de e-mail mesmo, ou privadamente.
>>
>> O que vou falar a seguir pode parecer confuso...
>> Mas para resumir
>> 1- Creio que eu concordo parcialmente com os 3 entes envolvidos.
>> 2- Creio que falta uma "peça" no nosso conjunto de engrenagens para que a coisa toda faça sentido.
>>
>> 1-a-
>> Eu acho que o espírito da proposta do Sérgio é EXCELENTE!
>> Sim! Antes de que qualquer organização se manifeste querendo se tornar responsável por mais recursos, deve demonstrar que é capaz de manter em ordem aquilo que já está sob sua responsabilidade.
>>
>> 1-b-
>> Eu concordo com o Frediani de que fazendo referência a esse tipo de status (ROA no caso) abre-se precedente para milhares de outros tipos de status de diversos tipos.
>> Mas não concordo que "já que vamos fazer isso, façamos aquilo também...".
>>
>> 1-c-
>> Eu concordo com o Oscar de que status de ROA é algo muito mais objetivo que um nível de adoção de IPv6.
>> Mas eu discordo de que o status de ROA seja algo que possa ser diretamente referenciado dentro do manual de políticas.
>>
>> 2-
>> Para exemplificar a peça que falta em nosso ecossistema, vou usar justamente o caso de um ASN e o status de ROA de seus recursos numéricos.
>> 2-1-
>> Primeiro exemplo é para demonstrar que o status não pode ser um conveniente snapshot point-in-time.
>> Imaginemos um ASN que passa o ano inteiro(ou vários anos) fazendo bagunça com as ROAs...
>> Deixando expirar, fazendo prefixos ficarem inválidos... Que bota rota mais específica sem estar coberta pelas ROAs. Ou que bota ROA "toda aberta" e nunca tem nada no mais específico.
>> Ou então, imaginemos que nunca teve nada de RPKI ROA em feito em sua vida, e apenas 1 dia antes de solicitar novos recursos, resolve ajustar as ROAs para refletirem como as suas rotas na DFZ estão agora.
>> Mas que 2 dias depois de receber o recurso solicitado, abandona completamente o cuidado com as ROAs.
>>
>> A ideia dessa exemplificação é demonstrar que "estar em conformidade" não é "point-in-time" é constância.
>>
>> 2-2-
>> O segundo exemplo é justamente para demonstrar o contrário.
>> Imaginemos um ASN que tenha seus recursos numéricos. Que tenha um histórico de anos sem nenhuma demonstraçaõ de abandono.
>> Mas justamente por estar precisando reordenar as coisas em casa, fazendo alterações, acaba por vazar uma rota fora do mais específico que estava previsto na ROA existente... E deixa isso lá por 17m39s, e logo corrige. E nunca mais volta a cometer "dedo-gordo".
>>
>> Essa exemplificação é para trazer para a mesa o fato de que um evento isolado não deve desabonar todo o histórico operacional de um ASN.
>>
>> 2-3-
>> Eu poderia criar dezenas ou centenas de exemplos para demonstrar pontos...
>> Mas entendo que esse thread não é para isso.
>> E acredito que já consegui demonstrar meu ponto para aqueles que realmente se dispuserem a entender o proponho aqui.
>>
>>
>> Diante do que tentei expor(e espero que tenha conseguido)...
>> Trago à mesa a hipótese de considerarmos a hipótese de ter-se um conjunto de melhores práticas operacionais do LACNIC, bem como mecanismos de medição recorrente de implementação de tais melhores práticas.
>>
>> Sei que propor uma mudança de rumo é quase uma Pivotada de Startupeiro sem noção de realidade.
>> E não quero sequestrar o thread dessa proposta de alteração do manual de políticas(sorry Sergio).
>>
>> Mas uso esse espaço para iniciar "semi-oficialmente" a discussão sobre criação de BCOPs oficiais ratificados pelo LACNIC.
>> Sobre medição recorrente dos cumprimentos desse BCOPs.
>> E sobre como, no futuro, esses BCOPs e mecanismos de medições possam ser a peça abstrata que falta em nosso manual de políticas.
>>
>> Desde já agradeço vossa atenção.
>>
>>
>> Em qua., 12 de ago. de 2026 às 14:11, Oscar Robles via Politicas <politicas at lacnic.net> escreveu:
>>
>> Fernando,
>>
>> Entiendo que parecen similares las propuestas. Quizá estoy equivocado
>> pues ustedes tienen más experiencia operativa, pero me parece que la
>> propuesta de Sergio es más parecida al requisito actual de tener la
>> resolución inversa prolija.
>>
>> A diferencia de tu propuesta (IPv6 operativo), este requisito es
>> facilmente medible, con menos ambiguedades y dificilmente se puede
>> "encender" para cumplir el requisito y "apagar" una vez obtenido los
>> recursos.
>>
>> Y coincido contigo que en un escenario ideal donde IPv6 operativo no
>> tuviera las dificultades previas, sería un buen requisito.
>>
>> Saludos,
>>
>> Oscar
>>
>>
>> On 12/08/26 8:27, Fernando Frediani via Politicas wrote:
>> > Hola
>> >
>> > El objetivo de la propuesta es noble y felicito al autor por ella.
>> > Sin embargo, si consideramos la aprobación de dicha propuesta,
>> > deberíamos retomar mi propuesta de hace algunos años, que
>> establecía
>> > como condición para recibir o transferir recursos de numeración
>> IPv4
>> > la comprobación de tener IPv6 operativo.
>> >
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
>> >
>> > En aquel tiempo entonces, algunos, temiendo no poder transferir
>> > recursos (quizás porque no habían implementado IPv6), la
>> rechazaron,
>> > argumentando que se trataba de una cuestión operativa.
>> >
>> > Sigo creyendo que es legítimo establecer políticas como esta
>> para ROA
>> > y como la que propuse para IPv6, ya que el Foro de Políticas puede
>> > editar la propuesta según lo considere oportuno para ajustar las
>> > reglas de Whois dello RIR si lo considera apropiado para una mejor
>> > gestión de los recursos de numeración.
>> >
>> > Fernando Frediani
>> >
>> > On 8/12/2026 10:38 AM, info-politicas--- via Politicas 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-2026-3.
>> >>
>> >> Título: Cobertura de ROAs válidas para la solicitud de recursos
>> >> adicionales
>> >>
>> >> Título abreviado: ROA para solicitud de recursos
>> >>
>> >> Resumen: Esta propuesta establece que toda organización que
>> solicite
>> >> recursos adicionales de numeración IPv4 o IPv6 a LACNIC deberá
>> >> demostrar una cobertura del 80% de Autorizaciones de Origen de
>> Ruta
>> >> (ROA) válidas para los recursos IPv4 e IPv6 registrados a su
>> nombre y
>> >> distribuidos o asignados por LACNIC. El objetivo de la
>> propuesta es
>> >> incentivar la adopción de RPKI y fortalecer la seguridad del
>> sistema
>> >> de enrutamiento de la región. La creación y mantenimiento de ROAs
>> >> constituye una práctica ampliamente reconocida para mitigar el
>> riesgo
>> >> de secuestros de rutas, anuncios no autorizados y errores de
>> >> configuración en BGP.
>> >>
>> >> La propuesta incorpora la adopción de ROAs como un criterio
>> adicional
>> >> para la evaluación de solicitudes de recursos subsiguientes,
>> >> complementando los criterios ya establecidos en el Manual de
>> Políticas.
>> >>
>> >> Propuesta completa:
>> >> Adicionar al final del inciso 1 de la sección “2.3.4. Políticas
>> para
>> >> la distribución de espacio adicional de direcciones IPv4” el
>> >> siguiente texto:
>> >> Adicionalmente, la organización deberá contar con una cobertura
>> del
>> >> 80% de Autorizaciones de Origen de Ruta (ROAs) válidas para los
>> >> recursos IPv4 e IPv6 que tenga asignados o distribuidos por
>> LACNIC.
>> >> LACNIC verificará el cumplimiento de este requisito mediante los
>> >> mecanismos operativos que determine para tal fin. El
>> cumplimiento de
>> >> este requisito constituirá una condición necesaria para aprobar la
>> >> distribución subsiguiente de recursos.
>> >>
>> >> Adicionar al final de la sección “4.4.2.1 Criterio de distribución
>> >> subsiguiente”:
>> >> Adicionalmente, la organización deberá contar con una cobertura
>> del
>> >> 80% de Autorizaciones de Origen de Ruta (ROAs) válidas para los
>> >> recursos IPv4 e IPv6 que tenga asignados o distribuidos por
>> LACNIC.
>> >> LACNIC verificará el cumplimiento de este requisito mediante los
>> >> mecanismos operativos que determine para tal fin. El
>> cumplimiento de
>> >> este requisito constituirá una condición necesaria para aprobar la
>> >> distribución subsiguiente de recursos.
>> >>
>> >> Para ver el detalle ingrese en:
>> >>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2026-3/language/sp
>> >>
>> >> Los comentarios y los puntos de vista aportados por la
>> comunidad son
>> >> vitales para el correcto desarrollo del proceso de la propuestas
>> >> - ¿Apoya usted o se opone a esta 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-2026-3.
>> >>
>> >> Título: Cobertura de ROAs válidas para la solicitud de recursos
>> >> adicionales
>> >>
>> >> Título abreviado: ROA para solicitud de recursos
>> >>
>> >> Resumo: Esta propuesta establece que toda organización que
>> solicite
>> >> recursos adicionales de numeración IPv4 o IPv6 a LACNIC deberá
>> >> demostrar una cobertura del 80% de Autorizaciones de Origen de
>> Ruta
>> >> (ROA) válidas para los recursos IPv4 e IPv6 registrados a su
>> nombre y
>> >> distribuidos o asignados por LACNIC. El objetivo de la
>> propuesta es
>> >> incentivar la adopción de RPKI y fortalecer la seguridad del
>> sistema
>> >> de enrutamiento de la región. La creación y mantenimiento de ROAs
>> >> constituye una práctica ampliamente reconocida para mitigar el
>> riesgo
>> >> de secuestros de rutas, anuncios no autorizados y errores de
>> >> configuración en BGP.
>> >>
>> >> La propuesta incorpora la adopción de ROAs como un criterio
>> adicional
>> >> para la evaluación de solicitudes de recursos subsiguientes,
>> >> complementando los criterios ya establecidos en el Manual de
>> Políticas.
>> >>
>> >> Para ver o detalhe acesse:
>> >>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2026-3/language/pt
>> >>
>> >> Os comentários e os pontos de vista aportados pela comunidade são
>> >> vitais para o bom desenvolvimento do processo das propostas
>> >> - ¿Você é 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
>> <mailto:e-mail%3Ainfo-politicas at lacnic.net> Atenciosamente,
>> >> ----------------------------------------
>> >>
>> >> Dear LACNIC Policy List subscribers,
>> >>
>> >> A new Policy Proposal has been received and assigned the following
>> >> ID: LAC-2026-3.
>> >>
>> >> Title: Cobertura de ROAs válidas para la solicitud de recursos
>> >> adicionales
>> >>
>> >> Abbreviated title: ROA para solicitud de recursos
>> >>
>> >> Summary: Esta propuesta establece que toda organización que
>> solicite
>> >> recursos adicionales de numeración IPv4 o IPv6 a LACNIC deberá
>> >> demostrar una cobertura del 80% de Autorizaciones de Origen de
>> Ruta
>> >> (ROA) válidas para los recursos IPv4 e IPv6 registrados a su
>> nombre y
>> >> distribuidos o asignados por LACNIC. El objetivo de la
>> propuesta es
>> >> incentivar la adopción de RPKI y fortalecer la seguridad del
>> sistema
>> >> de enrutamiento de la región. La creación y mantenimiento de ROAs
>> >> constituye una práctica ampliamente reconocida para mitigar el
>> riesgo
>> >> de secuestros de rutas, anuncios no autorizados y errores de
>> >> configuración en BGP.
>> >>
>> >> La propuesta incorpora la adopción de ROAs como un criterio
>> adicional
>> >> para la evaluación de solicitudes de recursos subsiguientes,
>> >> complementando los criterios ya establecidos en el Manual de
>> Políticas.
>> >>
>> >> To read the proposal, please go to
>> >>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2026-3/language/en
>> >>
>> >> 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 - Registro de Direcciones de Internet para América Latina y
>> >> Caribe
>> >> Rambla Rep. de México 6125, CP 11400
>> >>
>> >> Montevideo-Uruguay
>> >>
>> >> Teléfono: +598 2604 22 22
>> >> www.lacnic.net <http://www.lacnic.net>
>> >> _______________________________________________
>> >> Politicas mailing list
>> >> Politicas at lacnic.net
>> >> https://mail.lacnic.net/mailman/listinfo/politicas
>> >>
>> Desuscribirse/Descadastre-se/Unsubscribe:https://mail.lacnic.net/mailman/options/politicas
>>
>> >>
>> >>
>> >> El Codigo de Conducta de la Comunidad de LACNIC
>> >> (https://rir.la/codigoconducta-SP) aplica a las listas de
>> discusion
>> >> de LACNIC.
>> >> O Codigo de Conduta da Comunidade do LACNIC
>> >> (https://rir.la/codigoconducta-PT) se aplica as listas de
>> discussao
>> >> do LACNIC.
>> >> LACNIC's Community Code of Conduct
>> (https://rir.la/codigoconducta-EN)
>> >> applies to LACNIC's discussion lists.
>> >>
>> > _______________________________________________
>> > Politicas mailing list
>> > Politicas at lacnic.net
>> > https://mail.lacnic.net/mailman/listinfo/politicas
>> > Desuscribirse/Descadastre-se/Unsubscribe:
>> > https://mail.lacnic.net/mailman/options/politicas
>> >
>> > El Codigo de Conducta de la Comunidad de LACNIC
>> > (https://rir.la/codigoconducta-SP) aplica a las listas de
>> discusion de
>> > LACNIC.
>> > O Codigo de Conduta da Comunidade do LACNIC
>> > (https://rir.la/codigoconducta-PT) se aplica as listas de
>> discussao do
>> > LACNIC.
>> > LACNIC's Community Code of Conduct
>> (https://rir.la/codigoconducta-EN)
>> > applies to LACNIC's discussion lists.
>> >
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>> Desuscribirse/Descadastre-se/Unsubscribe
>> <https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe>:
>> https://mail.lacnic.net/mailman/options/politicas
>>
>> El Codigo de Conducta de la Comunidad de LACNIC
>> (https://rir.la/codigoconducta-SP) aplica a las listas de
>> discusion de LACNIC.
>> O Codigo de Conduta da Comunidade do LACNIC
>> (https://rir.la/codigoconducta-PT) se aplica as listas de
>> discussao do LACNIC.
>> LACNIC's Community Code of Conduct
>> (https://rir.la/codigoconducta-EN) applies to LACNIC's discussion
>> lists.
>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> Desuscribirse/Descadastre-se/Unsubscribe: https://mail.lacnic.net/mailman/options/politicas
>
> El Codigo de Conducta de la Comunidad de LACNIC (https://rir.la/codigoconducta-SP) aplica a las listas de discusion de LACNIC.
> O Codigo de Conduta da Comunidade do LACNIC (https://rir.la/codigoconducta-PT) se aplica as listas de discussao do LACNIC.
> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN) applies to LACNIC's discussion lists.
>
**********************************************
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