[lacnog] Sobre BGP y anuncios (era Re: IPv6 still 5–10 years away from mainstream use)
Carlos M. Martinez
carlosm3011 en gmail.com
Vie Jul 23 17:06:19 -03 2021
Fernando,
Simplemente voy a decir que sigo creyendo que esa restricción que tu
propones es profundo error. Muy profundo.
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).
Este es un caso al azar que me llevó mas o menos 30 segundos encontrar.
```
❯ 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 http://www.ripe.net/db/support/db-terms-conditions.pdf
% 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 'abuse en akamai.com'
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: abuse en akamai.com
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)
```
S2
Carlos
On 23 Jul 2021, at 14:13, Fernando Frediani wrote:
> Olá Carlos, entendo bem o que quer dizer e faço alguns comentários
> à respeito de alguns pontos da sua mensagem:
>
> - 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
> 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.
> 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.
>
> 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.
> 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.
>
> Obrigado pelo seu aporte à discussão.
> Abraços
> Fernando
>
> On 23/07/2021 13:41, Carlos M. Martinez wrote:
>>
>> Hola
>>
>> On 23 Jul 2021, at 13:01, Fernando Frediani wrote:
>>
>> Hola Carlos
>> 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?
>>
>> 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:
>>
>> * mitigación de DDoS
>> * ciertas modalidades de CDN
>> * sub-asignacion de IPs por parte de carriers que también usan BGP
>> * cloud providers usando las modalidades de “BYOP” (bring your
>> own IP)
>> * asociados que no quieren gestionar su propio BGP y prefieren
>> delegarlo en su carrier
>>
>> 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.
>>
>> 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.
>>
>> 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.
>> No todo lo que es técnicamente posible debe hacerse
>> necesariamente.
>>
>> 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.
>>
>> 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ó.
>>
>> 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.
>>
>> Saludos
>>
>> /Carlos
>>
>> Saludos
>> Fernando
>> On 23/07/2021 12:42, Carlos M. Martinez wrote:
>>
>> Hola
>> 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.
>> 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*.
>> 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.
>> 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”.
>> 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*.
>> Saludos,
>> /Carlos
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> <https://mail.lacnic.net/mailman/listinfo/lacnog>
>> Cancelar suscripcion:
>> https://mail.lacnic.net/mailman/options/lacnog
>> <https://mail.lacnic.net/mailman/options/lacnog>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> <https://mail.lacnic.net/mailman/listinfo/lacnog>
>> Cancelar suscripcion:
>> https://mail.lacnic.net/mailman/options/lacnog
>> <https://mail.lacnic.net/mailman/options/lacnog>
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20210723/47eb2fc1/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG