[lacnog] IP Privadas en sesiones PNI y número de IP para CDN

Lun Mar 30 23:46:02 GMT+3 2020

En nuestro caso estamos conectados a la red de IXP, y tomamos tráfico de
las CDN más importantes, y nuestra red es dualstack.
El inconveniente que podemos observar sobre la entrega de tráfico en IPv6
más que nada está en los dispositivos finales de los usuarios.
Se puede apreciar que dispositivos smartphone de los usuarios muchos poseen
doble pila, pero smartv muy pocos, y eso se nota en el uso de redes
sociales o video streaming.

[image: imagen.png]
De todas maneras el apagón de IPv4 no va a suceder, siempre vamos a tener
que convivir con él, pero si esperamos que IPv6 siga creciendo.
Respecto a lo que solicitan las CDN siempre es bueno reservar bloques para
servidores del DC y no tiene que ser exclusivo de las CDN podemos
compartirlos.

*Lic. Darío FernándezResearch SRL*

*Coord. Técnico IXP Posadas - CABASE(0376) 154619600 (Personal)(0376)
154254938 (Claro) Av. Tomas Guido 4435 - Posadas - Misiones*

El lun., 30 de mar. de 2020 a la(s) 22:35, Hernan Moguilevsky (
noc.hernan en gmail.com) escribió:

> Algunas CDNs de utilizan bloques públicos propios (/24).
> Otras solicitan  del ISP (>/24).
> Pero no veo desperdicio de IPs. Todas las IPs son utilizadas para atender
> tráfico.
>
> En este caso estoy con las CDNs. Ellas ya desplegaron IPv6. Y los ISPs?
>
> Saludos.
>
>
> El El lun, 30 mar. 2020 a la(s) 19:11, Alejandro Guzman <
> alejoguzg en gmail.com> escribió:
>
>> Además de lo que menciona Arturo, creo que es importante anotar que la
>> cantidad de IPs no depende de lo "conservador" que sea el proveedor de
>> caches. Depende de la cantidad de máquinas que forma el nodo y de la
>> multiplexación máxima de requests que se pueden manejar por IP según la
>> cantidad, el tipo de servicios y aplicaciones y contenidos que se sirven de
>> los caches. Si no se ha reducido más el requerimiento no es por falta de
>> que se anime a los CDNs a hacerlo, ya se ha reducido al mínimo actualmente
>> posible.
>>
>> Saludos
>>
>>
>> Alejandro
>>
>> El lun., 30 mar. 2020 a las 12:59, Arturo Servin (<
>> arturo.servin en gmail.com>) escribió:
>>
>>>
>>> IPv6 y el bloque de IPv4 necesario pasa de un /26 a cero.
>>>
>>>
>>> Saludos
>>>
>>> On Mon, 30 Mar 2020, 19:05 Fernando Frediani, <fhfrediani en gmail.com>
>>> wrote:
>>>
>>>> Gracias Tomas.
>>>> Tienes razón en la forma en que lo expresas. Posible es que no hay
>>>> problemas técnicos, pero puede haber un problema operativo y de retraso.
>>>> También he visto casos de uso para otros prefijos fuera de RFC1918,
>>>> pero creo que en este caso el problema de encontrar uno que no entre en
>>>> conflicto es el mismo.
>>>>
>>>> Creo que el mayor problema sigue siendo los bloques muy grandes que
>>>> algunos CDN solicitan al ISP. En tiempos de escasez, necesitan ajustar sus
>>>> políticas para adaptarse a esta realidad y hacer un mejor uso de estos
>>>> recursos y trabajar con /30 y /31 tanto como sea posible.
>>>>
>>>> Saludos
>>>> Fernando
>>>> On 30/03/2020 11:35, Tomas Lynch wrote:
>>>>
>>>> On Sat, Mar 28, 2020 at 3:29 PM Fernando Frediani <fhfrediani en gmail.com>
>>>> wrote:
>>>>
>>>>> Estimados colegas
>>>>>
>>>>> Me gustaría consultar a todos para conocer el punto de vista sobre un
>>>>> tema que parece estar cada vez más en discusión debido a la escasez de
>>>>> direcciones IPv4.
>>>>>
>>>>>
>>>> <snip>
>>>>
>>>> La otra pregunta que me gustaría hacer es sobre los PNI. ¿Alguien ve,
>>>>> desde un punto de vista técnico, algún impedimento para usar
>>>>> direcciones
>>>>> privadas en estos P2P?
>>>>>
>>>>>
>>>> El viejo problema de unir dos redes que utilizan direccionamiento
>>>> RFC1918. Peer A utiliza 10.1.0.0/16 para peerings, Peer B utiliza ese
>>>> mismo bloque para la red de monitoreo out-of-bound de sus equipos. Peer B
>>>> no puede usar ese bloque para peering, Peer A le pide entonces otro bloque,
>>>> Peer B le dice que usen 192.168.0.0/16 pero Peer A ya lo utiliza para
>>>> sus peerings en Europa, etc.
>>>>
>>>> En algún momento se van a poner de acuerdo pero va a retrasar el
>>>> peering, cada PNI sería un caso único, la documentación sería única, etc.
>>>> Ni hablar si hay scripts auditando configuraciones, estos deberían
>>>> contemplar estas excepciones también. Es decir, se puede, pero hay que
>>>> tener otras consideraciones.
>>>>
>>>>
>>>>
>>>>> Se puede decir que estamos hablando de unos pocos /30, pero creo que
>>>>> incluso para un ISP de tamaño mediano, varios PNI y CDN terminan
>>>>> consumiendo IPv4 públicos que podría utilizarse mejor para otros usos
>>>>> sin ninguna pérdida de calidad en la conexión, si solo cuente con la
>>>>> comprensión de ambos lados.
>>>>>
>>>>> Que piensas ?
>>>>>
>>>>> Fernando
>>>>>
>>>>> _______________________________________________
>>>>> 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 listLACNOG en lacnic.nethttps://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
>>>>
>>> _______________________________________________
>>> 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
>>
> --
> HM
> _______________________________________________
> 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/20200330/f7c5591b/attachment-0001.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: imagen.png
Type: image/png
Size: 33878 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200330/f7c5591b/attachment-0001.png>