[lacnog] Consulta Delegacion prefijos a abonados

[Eduardo Cota]

Que tal, buenas.

Interesante política.... sobre todo si tu sitio es accedido por clientes 
desde sus celulares, recomiendo leer el punto 4.2.4 de la propia ripe 690. 
"Considerations for Cellular Operators".

Para quienes no vayan a leerlo,
"There is a clear exception to the rule described above when assigning 
prefixes in a cellular network. In this case, a /64 will need to be 
provided for each PDP context for cellular phones, ...."

Aclaro que esto no es para los servicios broadband sobre red de celular, 
sino para los teléfonos, pero dependiendo de tu red claramente este 
filtrado puede afectar una porción posiblemente importante de quienes 
acceden a tus servicios.

Saludos,
         Eduardo.


On Mon, 26 Nov 2018, Ariel Weher wrote:

> Que tal buenas noches.
>
> Una consulta:
>
> Todo esto es por el día del inocente, ¿no?.
>
> Por otro lado:
>
> Cuando en mis redes encuentro ataques y cosas non-sanctas desde redes
> externas, en primera instancia para IPv4 se bloquea /32 y en IPv6 el
> /48.
> En el caso de los "disidentes del ripe-690" van a verse afectados
> varios clientes.
>
> El que avisa no traiciona.
>
> Saludos!
>
>
> On Fri, Nov 23, 2018 at 10:40 PM Fernando Gont <fgont en si6networks.com> wrote:
>>
>> On 23/11/18 12:15, JORDI PALET MARTINEZ wrote:
>>> Totalmente de acuerdo contigo que las aplicaciones deben trabajar con nombres, pero si no tienes direcciones estables, es difícil que los nombres hagan referencia a direcciones, y si usas DNS dinámico, los caches no sirven, y por tanto lo que ganas en RTT (como tu decías antes), lo pierdes en consultas a DNS ...
>>
>> Me parece que estas haciendo un analisis equivocado.
>>
>> 1) Respecto de las direcciones/prefijos estables, es usual que cuando
>> los mismos no son estables, cambien a lo sumo una o dos veces al dia, o
>> bien cuando reinicias el CPE. *No* estan cambiando ni siquiera una vez
>> por hora.
>>
>> 2) El TTL del DNS uno lo configura de manera acorde. Inclusive eligiendo
>> algo estilo "30 segundos" uno tiene un nivel de responsivenes mas que
>> aceptable. Y el unico "glitch" puede ocurrir justamente para ese momento
>> en el cual la IP/prefijo cambia, y asumiendo que la aplicaciòn *justo*
>> haga un query al DNS un instante antes de dicho cambio.
>>
>> 3) Comparar el RTT en un query DNS con el RTT de un tunel es equivocado.
>> El RTT que tenes en un query DNS es una ùnica penalizaciòn que, de
>> maximo, puede afectarte en el tiempo de respuesta para el caso de
>> aplicaciones interactivas (y ni eso, ya que en casos como el de la web,
>> muchos browsers (e.g. Chrome) hacen prefetch de los dominios). El RTT de
>> un tunel te afecta de manera permanente, ya que tiene una implicancia
>> directa, por ejemplo, en el "tamaño del pipe" (bandwidth-delay product)
>> que afecta entre otras cosas a la performance de protocolos como TCP,
>> buffer overbloat, y otros.
>>
>>
>> Saludos,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont en si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> _______________________________________________
>> 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
>