<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hola Carlos<br>
<br>
No estoy proponiendo una solución única, pero estoy exponiendo un
problema que es real y no podemos simplemente ignorarlo porque
simplemente es bueno seguir haciéndolo desde un punto de vista
técnico.<br>
<br>
Como mencioné en mi correo anterior, existen alternativas y
opciones técnicas y no necesariamente algo *necesita* hacerse
siempre de una manera única. El área técnica también necesita
adaptarse a las políticas y reglas vigentes y a medida que vayan
cambiando, es compromiso de la organización seguir adaptándose,
por lo que aunque eventualmente a algunos en la industria no les
guste, no tendrán más opción que cumplir con algo que es
justificable. .<br>
<br>
Una vez más, cito que, por muy cómodo que sea hacer algo de alguna
manera, no podemos ignorar las posibilidades de fraude que pueden
surgir a medida que cambia el contexto y el problema que mencioné
sigue siendo real y de alguna manera debe abordarse. Esto no
significa también combatir usos que sigan cumpliendo con las
justificaciones dadas a los RIR o que es diferente.</p>
<p>Saludos<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 23/07/2021 17:06, Carlos M. Martinez
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:45F74785-7282-4A1D-B4C1-85883F408CFA@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
<div class="markdown">
<p dir="auto">Fernando,</p>
<p dir="auto">Simplemente voy a decir que sigo creyendo que
esa restricción que tu propones es profundo error. Muy
profundo.</p>
<p dir="auto">Por mi parte creo que no tengo mas para decir.
Solamente compartir un ejemplo del tipo de usos 100%
legítimos que esa restricción que tu propones “invalidaría”
(pongo comillas porque por mas que esa restricción se
aprobara, nadie en la industria la aplicaría).</p>
<p dir="auto">Este es un caso al azar que me llevó mas o menos
30 segundos encontrar.</p>
<pre><code>❯ whois -h whois.lacnic.net 2.19.251.0
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See <a class="moz-txt-link-freetext" href="http://www.ripe.net/db/support/db-terms-conditions.pdf">http://www.ripe.net/db/support/db-terms-conditions.pdf</a>
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '2.19.240.0 - 2.19.255.255'
% Abuse contact for '2.19.240.0 - 2.19.255.255' is '<a class="moz-txt-link-abbreviated" href="mailto:abuse@akamai.com">abuse@akamai.com</a>'
inetnum: 2.19.240.0 - 2.19.255.255
netname: AKAMAI-PA
descr: Akamai Technologies
country: DE
admin-c: NARA1-RIPE
tech-c: NARA1-RIPE
status: ASSIGNED PA
mnt-by: AKAM1-RIPE-MNT
mnt-routes: DTAG-RR
created: 2010-12-11T20:49:44Z
last-modified: 2011-01-12T11:44:11Z
source: RIPE
role: Network Architecture Role Account
address: Akamai Technologies
address: 8 Cambridge Center
address: Cambridge, MA 02142
phone: +1-617-938-3130
abuse-mailbox: <a class="moz-txt-link-abbreviated" href="mailto:abuse@akamai.com">abuse@akamai.com</a>
admin-c: NF1714-RIPE
admin-c: CKAK-RIPE
tech-c: NF1714-RIPE
tech-c: JP1944-RIPE
tech-c: APB15-RIPE
tech-c: CKAK-RIPE
tech-c: TBAK-RIPE
tech-c: NB782-RIPE
tech-c: RM4844-RIPE
tech-c: AKAY-RIPE
nic-hdl: NARA1-RIPE
mnt-by: AKAM1-RIPE-MNT
created: 2002-03-06T09:02:17Z
last-modified: 2019-04-15T17:17:53Z
source: RIPE # Filtered
% Information related to '2.19.251.0/24AS6057'
route: 2.19.251.0/24
descr: Akamai Technologies
origin: AS6057
mnt-by: AKAM1-RIPE-MNT
created: 2020-02-05T21:56:13Z
last-modified: 2020-02-05T21:56:13Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.101 (BLAARKOP)
</code></pre>
<p dir="auto">S2</p>
<p dir="auto">Carlos</p>
<p dir="auto">On 23 Jul 2021, at 14:13, Fernando Frediani
wrote:</p>
</div>
<blockquote class="embedded">
<div id="EE483155-823F-4805-98CF-16849889AB6B">
<p>Olá Carlos, entendo bem o que quer dizer e faço alguns
comentários à respeito de alguns pontos da sua mensagem:</p>
<p>- Cloud Providers usando modalidades de BYOP não
necessariamente precisam anunciar esses endereços com seus
próprios ASN. É possível preservar o ASN de origem sem
quaisquer problemas desde que o produto seja feito
prevendo isso que é algo bastante normal<br>
Sobre associados que não querem gerir seus próprio BGP
ainda sim caso deleguem isso para um terceiro nada impede
de preservar o ASN de origem da organização detentora como
padrão.<br>
Sobre mitigação DDoS, mesmo olhando para os aspectos
técnicos anunciar os endereços com o ASN da empresa de
mitigação é algo bem controverso e desde meu ponto de
vista técnico desnecessário. Também é possível preservar o
ASN e ainda sim conseguir atrair o tráfego do ataque para
si para realizar a mitigação.</p>
<p>O que disse sobre a possibilidade de uma possível
restrição é apenas o preço a se pagar para ter algum tipo
de garantia que os endereços IP continuarão a serem
utilizados conforme a justificativa que foi dada para os
RIRs. Há de existir um equilíbrio entre o que você diz e a
garantia da comunidade de saber que os endereços IPs
entregues continuam sendo justificados.<br>
Mesmo que o período do soft-landing (que concordo contigo
ter sido algo muito responsável da comunidade) e que as
listas de espera sejam algo cada vez mais distante para
novos entrantes serem contemplados não podemos nos
esquecer que os atuais endereços já distribuídos devem
continuar com suas justificativas válidas por muito tempo
e se existem mecanismos que permitem burlar isso alguma
ação é necessária para contra-balancear isso.</p>
<p>Obrigado pelo seu aporte à discussão.<br>
Abraços<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 23/07/2021 13:41, Carlos M.
Martinez wrote:<br>
</div>
<blockquote type="cite"
cite="mid:AAE32A12-25D8-438B-9DF5-9EBDD17590FA@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div>
<div class="markdown">
<p dir="auto">Hola</p>
<p dir="auto">On 23 Jul 2021, at 13:01, Fernando
Frediani wrote:</p>
</div>
<div class="plaintext">
<blockquote>
<p dir="auto">Hola Carlos <br>
Somos conscientes de que esto no es un requisito
hoy en día, pero ¿por qué no podría serlo? No por
razones técnicas, ya que este requisito no existe
realmente para BGP, pero ¿por qué no podría serlo
desde el punto de vista de las políticas? </p>
</blockquote>
</div>
<div class="markdown">
<p dir="auto">Porque es un profundo error. Pondría a
los registros en un curso de colisión con la
industria que no terminaría bien de ninguna forma,
ya que volvería incompatibles con las políticas una
serie de negocios completamente legítimos:</p>
<ul>
<li>mitigación de DDoS</li>
<li>ciertas modalidades de CDN</li>
<li>sub-asignacion de IPs por parte de carriers que
también usan BGP</li>
<li>cloud providers usando las modalidades de “BYOP”
(bring your own IP)</li>
<li>asociados que no quieren gestionar su propio BGP
y prefieren delegarlo en su carrier</li>
</ul>
</div>
<div class="plaintext">
<blockquote>
<p dir="auto">La única implicación es preservar el
AS-Path y esto realmente no es un problema técnico
y termina dando una mayor garantía de que esas
direcciones IP realmente se utilizarán para los
fines para los que se justificaron. Pero para eso
es imperativo que toda organización que tenga
asignadas direcciones IP también tenga un ASN, que
con ASN de 32 bits no supone ningún problema. </p>
</blockquote>
</div>
<div class="markdown">
<p dir="auto">El problema no es la abundancia de
numeros de ASN, el problema es el que describo más
arriba. Esa garantía adicional (relativa a mi
juicio, cuestionable en valor) vendría al costo de
lo que describo mas arriba. En mi opinión, es un
costo completamente inaceptable.</p>
</div>
<div class="plaintext">
<blockquote>
<p dir="auto">Si en el pasado este requisito no era
necesario, pero con el agotamiento de IPv4 y los
crecientes intentos de arrendar o prestadas de
direcciones IP de una organización a otra (lo que
puede violar la justificación inicialmente dada
para el RIR), ahora existe motivación para que
esto se ajuste. Y que no imponga pérdidas
técnicas, solo mayor control para evitar la
posibilidad de mal uso de este bien escaso. <br>
No todo lo que es técnicamente posible debe
hacerse necesariamente. </p>
</blockquote>
</div>
<div class="markdown">
<p dir="auto">No tiene nada que ver con el agotamiento
de IPv4. Esta restricción de ASN-prefijo no va
ayudar en nada al agotamiento de IPv4. IPv4 ya se
agotó, es historia pasada. Las únicas formas hoy de
obtener IPv4 son via transferencias o esperando el
tiempo que haya que esperar en las listas de espera
de los diferentes RIRs.</p>
<p dir="auto">Las empresas solas se van a ir dando
cuenta de esto, a medida que les vaya tocando. No a
todas les va a pasar a la vez, y algunas lo van a
sufrir más que otras. La comunidad actuó
responsablemente en su momento creando políticas de
soft landing que hicieron de este agotamiento una
experiencia menos traumática, pero ese tiempo ya
también pasó.</p>
<p dir="auto">Es hora de dejar partir al IPv4, y sobre
todo, es hora de dejar de tratar de arreglar IPv4
destruyendo las cosas que hacen que Internet sea lo
que es hoy.</p>
<p dir="auto">Saludos</p>
<p dir="auto">/Carlos</p>
</div>
<div class="plaintext">
<blockquote>
<p dir="auto">Saludos <br>
Fernando <br>
On 23/07/2021 12:42, Carlos M. Martinez wrote: </p>
<blockquote>
<p dir="auto">Hola <br>
Hay que des-asociar las funciones de registro
que cumplen los RIRs y NIRs de lo que son los
protocolos en sí. Debemos ser claros con eso. <br>
Para usar BGP hay que usar un sistema autónomo.
Ese sistema autónomo, ¿debe ser el propio,
asignado a la misma organización que tiene la
titularidad de las IPs? Definitivamente *NO*. <br>
Hay muchos escenarios en los que la misma
organización puede anunciar parte de sus IPs
desde un AS propio, otra parte desde otro
sistema autónomo, delegarle IPs a un cliente que
tiene otro sistema autónomo. <br>
Siempre que leo estos hilos veo una tendencia a
ir hacia “cada organización que tiene asignadas
IPs debe usar *únicamente* su propio sistema
autónomo para sus anuncios”. <br>
Esta afirmación no solo es un error desde el
punto de vista técnico (es requisito no existe
en BGP, BGP no sabe lo que es un RIR/NIR/LIR),
pero sobre todo, *desconoce la realidad de la
industria y de la prestación de servicios de
conectividad*. <br>
Saludos, <br>
/Carlos <br>
_______________________________________________
<br>
LACNOG mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:LACNOG@lacnic.net"
moz-do-not-send="true">LACNOG@lacnic.net</a> <br>
<a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
<br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a>
</p>
</blockquote>
</blockquote>
<blockquote>
<p dir="auto">_______________________________________________
<br>
LACNOG mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:LACNOG@lacnic.net"
moz-do-not-send="true">LACNOG@lacnic.net</a> <br>
<a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
<br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a>
</p>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net" moz-do-not-send="true">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</div>
</blockquote>
<div class="markdown">
</div>
<div class="plaintext">
<blockquote>
<p dir="auto">_______________________________________________
<br>
LACNOG mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
<br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a>
</p>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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>