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

[Arturo Servin]

Si el operador tiene IPv6 en su red y todos sus abonados tienen IPv6 con un
metodo que permita a los host IPv4 only usar IPv6, entonces (al menos los
caches de Google) no es necesario que los caches tengan IPv4.

El requerimiento de /27 o /26 de IPv4 depende de número de hosts que tenga
el nodo de cache. Cada host require una dirección pública publica y
posiblemente varias virtuales para administración y multiplexación de
servicios.

Algunas CDNs requieren menos menos IPs porque requieren menos servidores,
pero tambien quiza son menos flexibles en el trafico minimo porque los
servidores son menos pero mas grandes. Algunas CDNs usan menos IPs porque
tienen menos servicios (solo video), otras son publicas y tienen multiples
servicios (video en demanda, video streaming, juegos, servidores de
archivos, etc.) que hace que requieran en algunos casos mas IPs para hacer
más sencilla y escalable la multiplexión.

Saludos,
as



Saludos,
as




On Tue, Mar 31, 2020 at 7:12 PM Fernando Frediani <fhfrediani en gmail.com>
wrote:

> Queridos colegas
>
> Creo que esta discusión también es siempre interesante, pero el
> propósito inicial de esta thread fue discutir la necesidad de muchas
> direcciones IP solicitadas por algunos CDN para alojar sus servidores en
> muchos escenarios y dada la escasez de direcciones IPv4, especialmente
> por parte de aquellos ISP que hacen un buen trabajo trabajo
> implementando CGNAT + IPv6 y puede seguir su operación con tan solo 1 o
> 2 x /22...
>
> Creo que hay una gran diferencia entre pedir algo como un /26 (Que es
> algo bastante grande en estos días) y un /30 o /31.
> El punto principal es evaluar si realmente necesita todas esas
> direcciones o si simplemente no ha actualizado sus requisitos que se
> definieron en el pasado y no se han actualizado aún teniendo en cuenta
> este nuevo escenario de escasez.
>
> Si esto no se hace, a pesar del buen trabajo de implementación de IPv6
> realizado por varios servicios de CDN, continuar exigiendo grandes
> bloques para infraestructuras de pequeño tamaño (e.g: 1 switch y 2 a 4
> servidores) termina teniendo el efecto secundario de fomentar el mercado
> de transferencia de IPv4. Tenga en cuenta que el mismo ISP tiende a
> tener varios CDN alojados.
>
> En términos generales, las preguntas que se pueden hacer para escenarios
> como este son:
> - ¿Es necesario tener 1 IPv4 público dedicado para gerencia cada uno de
> los equipos instalados o esta parte se puede hacer solo con IPv6?
> - ¿Es realmente necesario que cada servicio diferente esté en un IPv4
> diferente dadas las opciones existentes para compartir la misma
> dirección para diferentes servicios?
> - ¿Es posible en algunos casos, teniendo en cuenta lo que declaró Tomás,
> tener escenarios predefinidos para para darte opciones y facilitar la
> activación de estos servicios utilizando direcciones privadas cuando sea
> posible o conveniente?
>
> Estos son algunos de los puntos que estoy tratando de entender con la
> ayuda de colegas y también en qué partes se ajustan o hacen ajustes.
>
> Saludos cordiales
> Fernando
>
> On 31/03/2020 14:28, Fernando Gont wrote:
> > On 31/3/20 05:12, Arturo Servin wrote:
> >>
> >> 464XLAT fue mi breve respuesta a tu breve comentario que las TVs no
> >> soportan IPv6 y por tanto las CDNs deben de usar IPv4.
> >
> > Pero sis usas 464XLAT, salvo que implementes algo similar a lo
> > propuesto por JOrdi y Alejandro, vas a usar IPv6 solo para transporte
> > en la red del ISP -- es decir, seguis necesitando que el cache tenga
> > direcciones IPv4.
> >
> >
> >
> >> No se si 464XLAT sea la respuesta para que un ISP que tiene IPv6 en
> >> su red sin IPv4 pueda usar la CDN solo con IPv6 y que dispositivos
> >> con solo IPv4 no se vean afectados.
> >
> > Nop. Asi como esta especificado, no lo es.
> >
> > Abrazo,
> _______________________________________________
> 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/20200401/bae00e56/attachment.html>