<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hola</p>
<div class="moz-cite-prefix">On 8/18/2026 3:23 PM, Herbert Alexander
Faleiros vía LACNOG wrote:<br>
</div>
<blockquote type="cite" cite="mid:aoSjNSfvzXGEfkR8@registro.br">
<pre wrap="" class="moz-quote-pre">Sin embargo, haría una pequeña distinción en la primera opción. Un ROA
válido para el /22 no hace que un /32 contenido en él sea RPKI Valid
si la longitud no está autorizada. El /32 seguirá siendo Invalid desde
el punto de vista de ROV.</pre>
</blockquote>
Sí, es correcto. Lo que sugiero es no realizar la validación RPKI
basándose en el /32. Solo una verificación indirecta: si existe un
ROA para un prefijo más agregado que contenga ese /32, entonces está
bien para aceptarlo.
<blockquote type="cite" cite="mid:aoSjNSfvzXGEfkR8@registro.br">
<pre wrap="" class="moz-quote-pre">
Lo que sí me parece razonable es tratarlo como una excepción explícita
de política: aceptar un /32 o /128 RPKI Invalid únicamente cuando se
recibe de un participante autorizado, lleva la comunidad
BLACKHOLE/RTBH y está contenido dentro de un prefijo que ese
participante está autorizado a originar. Es decir, no cambiar la
semántica de RPKI, sino separar ROV de la política específica de RTBH.</pre>
</blockquote>
Exactamente
<blockquote type="cite" cite="mid:aoSjNSfvzXGEfkR8@registro.br">
<pre wrap="" class="moz-quote-pre">
Además, estas rutas deberían quedar estrictamente limitadas al ámbito
necesario para el blackholing y no convertirse en rutas normales
propagadas por Internet. Esto también es coherente con RFC 7999, que
recomienda limitar la propagación de las rutas BLACKHOLE.</pre>
</blockquote>
No es necesario transmitirlos a Internet toda, pero podrían si
transmitirse a algunos Upstreams que también acepten RTBH para la
amplificación de los efectos.
<blockquote type="cite" cite="mid:aoSjNSfvzXGEfkR8@registro.br">
<pre wrap="" class="moz-quote-pre">
Y coincido bastante con el último punto. No hay una razón técnica para
que RTBH tenga que significar siempre /32 o /128. Permitir también
prefijos agregados puede ser especialmente útil en ataques tipo carpet
bombing: si el objetivo es descartar tráfico hacia una parte completa
de la red, anunciar un /24 o /25 puede ser mucho más eficiente que
introducir cientos de /32. Naturalmente, existe un trade-off de
granularidad y posible impacto colateral, pero debería ser una
decisión del participante y no una limitación artificial del
mecanismo.</pre>
</blockquote>
Mucho más.<br>
<br>
Aquí creo que es más una cuestión de costumbre. "Lo hago así porque
siempre lo he hecho así y nunca aprendí otra manera"<br>
Una razón similar explica por qué muchas personas siguen asignando
prefijos IPv4 públicos /30 en lugar de /31 hasta el día de hoy
después de más de 20 años.
<p>Saludos<br>
Fernando</p>
<blockquote type="cite" cite="mid:aoSjNSfvzXGEfkR8@registro.br">
<pre wrap="" class="moz-quote-pre">
--
Herbert
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Fernando
On 8/8/2026 3:46 PM, Salvador Bertenbreiter wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Hola a todos,
Una consulta para quienes usan RTBH junto con RPKI.
¿Cómo manejan los anuncios /32 en IPv4 o /128 en IPv6 cuando el prefijo
tiene un ROA con maxLength /24 o /48?
Una opción sería ampliar el ROA hasta /32 o /128, pero no me convence
porque también haría válidos otros more-specifics.
La otra sería mantener el ROA como está y anunciar igual el host route
para RTBH, pero en ese caso sería RPKI Invalid. ¿Los upstreams
normalmente hacen alguna excepción para rutas marcadas como blackhole, o
las descartan antes por RPKI?
Crear un ROA específico en el momento tampoco parece muy práctico por
los tiempos de propagación.
¿Cómo lo están manejando ustedes en producción?
Saludos,
Salvador
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion:<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>