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

JORDI PALET MARTINEZ jordi.palet en consulintel.es
Mie Abr 1 13:03:10 GMT+3 2020


Hola Arturo,

 

No es así. Hay un pequeño detalle que te pierde.

 

Si un host NO tiene IPv6 (un SmartTV antiguo), con los mecanismos de transición que tenemos, NO es posible que “hable” con host IPv6, y por lo tanto necesitas mantener dual-stack en los CDN.

 

Otra cosa es que el CDN pueda usar direcciones IPv4 privadas y entregue las mismas a los DNS del operador, con algún “apaño”. Se podría hacer, pero no es tan fácil, porque los propios mecanismos de transición excluyen (en principio) esas direcciones privadas.

 

Si conseguimos que draft-ietf-v6ops-464xlat-optimization (de momento ya hemos conseguido que sea un WG ítem, que no es poco), avance, y *que los fabricantes de CPEs* lo incorporen, entonces tenemos el asunto resuelto.

 

Para que avance, necesitamos que la gente lo lea, especialmente gente de CDNs. Hasta ahora, solo lo ha venido apoyando Akamai, y en un momento dado se han vuelto reticentes, bajo mi punto de vista con algo absurdo “si esto falla, tenemos que quitar IPv6 de los CDNs porque es peor”. Mi respuesta es obvia: “en IETF tenemos que hacer lo imposible para que aprobemos algo que no falle, o muy mal lo hacemos. Cualquier cosa que haga el IETF y que falle, *porque se implementa mal*, eso ya no es un problema del IETF, sino del fabricante de CPE, y eso pasa con este documento y con cualquier otro”.

 

Pero como todo, estas cosas requieren tiempo (2 años, siendo optimista?). Quizás en ese tiempo, los fabricantes de SmartTVs y STBs ya tengan IPv6 y no sea “tan necesario” (siempre quedaran modelos antiguos).

 

En cualquier caso, es una mejora, y el documento también permite que las CDNs sean IPv6-only en el futuro.

 

Bueno, con esto (aunque es un off-topic de este hilo) hemos hecho un resumen del estado del documento en v6ops, veamos si alguien se anima a registrarse en v6ops y contribuir!

 

Saludos,

Jordi

@jordipalet

 

 

 

El 1/4/20 17:44, "LACNOG en nombre de Fernando Frediani" <lacnog-bounces en lacnic.net en nombre de fhfrediani en gmail.com> escribió:

 

Correcto Arturo, pero en cualquier escenario, incluso en el más optimista, las sesiones de IPv4 siguen siendo necesarias, incluso si el CDN tiene una implementación de IPv6 al 100% debido al equipo legacy en el hogar del usuario.
Quizás, muy quizás en el futuro, si la propuesta que proponen Jordi y Alejandro se convierta en un RFC aliado al uso exclusivo de 464XLAT (que es otro desafío), esto sería posible. Todavía creo que siempre habrá casos, aunque pocos seguirán comunicándose en IPv4 durante mucho tiempo y pensar en eliminar sesiones en IPv4 es prácticamente imposible durante mucho tiempo.

Saludos
Fernando

On 01/04/2020 12:37, Arturo Servin wrote:

 

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



_______________________________________________
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 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200401/2d5e96e4/attachment.html>


Más información sobre la lista de distribución LACNOG