[LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos
Fernando Frediani
fhfrediani at gmail.com
Thu Aug 13 12:34:53 -03 2026
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
More information about the Politicas
mailing list