[lacnog] Diseño IPv6
JORDI PALET MARTINEZ
jordi.palet en consulintel.es
Sab Jul 18 07:44:27 GMT+3 2020
Algunos CDNs, con CGN (algunos incluso "extra-oficialmente"), admiten que las direcciones fuente sean del prefijo recomendado para CGN (100.64.0.0/10), y por lo tanto ese tráfico si hay peering directo con el CDN, aunque no es enrutable en Internet, si que se hace llegar al CDN (ejemplo con comunidades BGP).
Eso quiere decir que ese tráfico NO pasa por el CGN, y por tanto es un % de tráfico que puede ser muy relevante, si hay aún muchos usuarios usando CDNs desde dispositivos IPv4-only, y eso reduce la carga de los CGN y por tanto la inversión en los mismos. Obviamente implica también un nivel menos de NAT44, y su correspondiente latencia.
Aunque no aporta nada mas de lo que he explicado, puedes verlo en las diapos de 464XLAT del v6ops interim meeting de hace un par de días:
https://datatracker.ietf.org/meeting/interim-2020-v6ops-01/session/v6ops
Saludos,
Jordi
@jordipalet
El 18/7/20 3:23, "LACNOG en nombre de Alejandro Acosta" <lacnog-bounces en lacnic.net en nombre de alejandroacostaalamo en gmail.com> escribió:
Buenas noches Tocayo,
Primero que nada, muy bueno tus comentarios.
Segundo, tengo una duda o mejor dicho pedirte un favor, puedes
elaborar un poco más en esta idea:
"
- Rendimiento: Hay pruebas que demuestran que el tráfico aumenta alrededor de un 15% para los servicios que dejan de pasar por un CGN y pasan a tener conectividad directa. Este tema es algo de lo que ya son conscientes los proveedores de contenido como Google donde ofrecen mecanismos para hacer un "bypass" de su tráfico al CGN.
Después de todo esto es que digo que es un mal necesario, porque hoy no tenemos una implementación de un mecanismo de transición que nos permita tener la eficiencia ganada luego de hacer el bypass de servicios de CDN.
"
¿Por qué aumenta? y/o ¿qué aumenta?, todo el tráfico hacia esa
CDN/solo v6/solo v4?.
Muchas gracias nuevamente,
Saludos,
Alejandro,
On 7/17/20 7:58 PM, Alejandro D'Egidio via LACNOG wrote:
> Estimados:
>
> Buenas noches.
>
> Recién terminé de leer toda la cadena, se hizo extensa y se trataron varios temas!
> Quisiera tratar de comentar mi punto de vista tratando de pasar por los diferentes temas conversados.
> Espero no aburrirlos si se hace largo.
>
> 1- Despliegue de IPv6
> (No digo que sea el caso) Creo que antes de pensar en CGN siempre primero tenemos que analizar la posibilidad de trabajar en el despliegue de IPv6 y hacer todo lo posible para tenerlo.
> Esto es independiente al estado de agotamiento de IPv4 aunque, obviamente, el agotamiento de IPv4 hace pensar en instalar (o agrandar) CGN.
> Normalmente la parte fácil es habilitar IPv6 en el Core e ITX.
> La parte complicada es habilitar IPv6 en el acceso, hay casos donde hay limitaciones en las tecnologías de acceso (ej CPEs viejos) pero una de las razones más comunes también es que no se termina desplegando por falta de conocimiento o tiempo para investigar, diseñar e implementar los cambios necesarios.
> Lo mejor es siempre iniciar el despliegue IPv6 antes que CGN, esto naturalmente va a mover gran parte del tráfico de IPv4 a IPv6 ya que los grandes proveedores de contenido están en Dual-Stack (asumiendo que en Core, ITX y CDNs están en DS).
> Dependiendo de la infraestructura y el tipo de clientes del ISP, hoy en día se puede obtener fácilmente porcentajes por encima del 60-70% de IPv6 sobre el total del tráfico.
> El solo hecho de habilitar IPv6 (que no es un trabajo menor) le resta mucho al CGN ante el agotamiento de IPv4.
>
> 2- CGN
> Luego de que tenemos IPv6 habilitado tenemos que pensar en qué hacemos con el tráfico IPv4 remanente por cuestiones como:
> - Dispositivos que funcionan solo en IPv4.
> - Aplicaciones solo IPv4.
> - Contenido solo IPv4.
> De manera nativa en IPv4, y si no tenemos más direcciones IPv4 Públicas, lo que nos queda es caer en el mal necesario CGN.
> Yo no entraría en una discusión de costos sobre CGN porque podemos llegar a terminar implementando todos CGN de manera interminable.
> Hoy en día hasta lo que está mas al alcance (en el mejor de los casos) es poder hacer un despliegue con Dual-Stack ya que para ir a mecanismos de IPv4aaS comenzamos a depender de funcionalidades diferentes en los CPEs.
> Uno de los problemas con CGN por ejemplo son:
> - Aplicaciones: Por ejemplo sabemos que PSN bannea los bloques de IPv4 que detecten que tiene doble NAT.
> - Conexión remota al CPE: Ejemplo para el caso de cámaras IP.
> - Rendimiento: Hay pruebas que demuestran que el tráfico aumenta alrededor de un 15% para los servicios que dejan de pasar por un CGN y pasan a tener conectividad directa. Este tema es algo de lo que ya son conscientes los proveedores de contenido como Google donde ofrecen mecanismos para hacer un "bypass" de su tráfico al CGN.
> Después de todo esto es que digo que es un mal necesario, porque hoy no tenemos una implementación de un mecanismo de transición que nos permita tener la eficiencia ganada luego de hacer el bypass de servicios de CDN.
>
> 3- Mecanismos de Transición
> Acá es donde se pone más interesante la cosa jaja.
> Como algunos saben vengo investigando y buscando opciones de Mecanismos de Transición a IPv6 especialmente en los orientados a IPv4aaS.
> Dentro de estos mecanismos, en mi caso me parece muy interesante el caso de 464XLAT.
> Este mecanismo originalmente comenzó en las redes móviles pero hay cada vez más intentos por popularizarlo en las redes fijas.
> El problema de esto principalmente surge en que los CPEs tengan la funcionalidad de CLAT (NAT46); solo muy pocos CPEs de algunas tecnologías de acceso y pocos fabricantes lo tienen implementado.
> El año pasado en conjunto con Sagemcom presentamos una versión de FW de Cablemodem funcional con CLAT.
> Pero surgió el problema de que si se implementa, se pierde la "optimización" que en mayor o menor medida los ISPs fueron ganando al "bypassar" el CGN porque fuerzan que todo el tráfico IPv4 pase por un segundo NAT nuevamente (NAT64 en este caso). De ahí es que surgió el draft que estamos impulsando con Jordi (https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/).
> Desde mi apreciación personal, 464XLAT es sumamente interesante pero si no se resuelve este problema de falta de eficiencia los ISPs que ya tengan hecho el bypass con al menos alguna CDN (la mayoría) no van a querer implementarlo porque:
> - Va a bajar la performance.
> - Van a generar un cuello de botella para tráfico que hoy lo pueden tener "directo" (disponibilidad del servicio).
> - Tendrían que salir a hacer inversión interesante en mayor o menor medida de infraestructura (Ej: NAT64) para contemplar todo el tráfico que hoy no pasa por CGN (lo tienen bypasseado, ej CDNs).
> Por otro lado Cablelabs desde hace unos años tiene estandarizado el soporte de MAP-T para nuevos CMs y ya hay frabricantes que están indicando que lo tienen disponible, es solo cuestión de que los ISPs comiencen a exigirlos.
>
>
> Saludos,
> Alejandro
>
> ----- Mensaje original -----
> De: "Latin America and Caribbean Region Network Operators Group" <lacnog en lacnic.net>
> Para: "Latin America and Caribbean Region Network Operators Group" <lacnog en lacnic.net>
> CC: "JORDI PALET MARTINEZ" <jordi.palet en consulintel.es>
> Enviados: Viernes, 17 de Julio 2020 5:24:22
> Asunto: Re: [lacnog] Diseño IPv6
>
> Vaya, por un momento me hice ilusiones y pensé que era yo en Cancún tocando el violín o el piano, pero no ... la música nunca se me dio bien!
>
> Saludos,
> Jordi
> @jordipalet
>
>
>
> El 17/7/20 10:21, "Fernando Gont" <fernando en gont.com.ar> escribió:
>
> On 17/7/20 05:10, JORDI PALET MARTINEZ via LACNOG wrote:
> > Obviamente no recuerdo con precisión (si recuerdo la anécdota) de Cancún. ¡Estamos hablando del año 2012 nada menos!
> >
> > Sin tener todo el contexto, no se si dije eso, o si hay que leer "todo el párrafo" para entender en que circunstancia lo dije. Obviamente cuando uno esta hablando en un micrófono o respondiendo preguntas tras una presentación, etc. (ni siquiera se si era el caso) es fácil confundirse.
>
> https://www.youtube.com/watch?v=Ptk_1Dc2iPY
>
> Slds,
> --
> Fernando Gont
> e-mail: fernando en gont.com.ar || fgont en si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>
>
> **********************************************
> 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.
>
>
>
> _______________________________________________
> 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.
Más información sobre la lista de distribución LACNOG