[lacnog] Diseño IPv6

JORDI PALET MARTINEZ jordi.palet en consulintel.es
Sab Jul 18 08:00:06 GMT+3 2020 

Hola Alejandro,

Hay algo que no comparto contigo y creo que es importante, porque quien no conozca bien 464XLAT, podría llevarse a engaño.

Me refiero a que, según tu punto de vista, si no hay optimización en 464XLAT haya quien no lo implemente. Obviamente hay casos y casos, pero la realidad es que la optimización la hemos planteado hace un año y medio aproximadamente, y sin embargo, 464XLAT es el mecanismo de transición que tiene mayor despliegue (por número de usuarios) incluso si lo comparas con la suma de todos los demás en el otro lado de la balanza. Creo que es algo muy significativo.

Yo tengo ya mas de una docena de despliegues de 464XLAT en clientes de banda ancha, y en todos los casos les ha salido a cuenta, tanto económicamente como en prestaciones. Es cierto que son casos "pequeños", desde unos 3.500 hasta unos 10-12.000 suscriptores, pero precisamente en esos casos, un CGN puede ser menos costoso.

En el caso mayor en el que estoy trabajando ahora (25.000.000 de suscriptores), los números son abrumadores. Insisto que estas cifras siempre dependen del caso de cada uno, pero incluso el ahorro en CGN les paga el coste de reemplazar los CPEs, que no es poca cosa.

Y todo ello, *sin* la optimización.

También creo que debe quedar claro que los datos de grandes operadores, hechos públicos en v6ops y contrastados con otros proveedores que usan 464XLAT, hace dos años ya indicaban que su tráfico que pasaba por el NAT64 era inferior al 25%. Insisto que son datos de hace dos años. Ahora mismo tengo casos en los que esto se reduce al 10-15% (según horas del día y si es laborable o festivo).

Que conste que entiendo que es una forma de hablar el como lo dices, pero creo que es importante la apreciación, porque puede llevar a algunos a "ni siquiera plantearse" estudiar la opción, lo que implica que hay menos presión para tener mas CPEs con el RFC8585, menos presión para conseguir estandarizar la optimización y que también la implementen los fabricantes de CPEs, etc.

Además, para aquellos que no hayan leído el draft, MAP-T tiene el mismo problema, y nuestro documento también permite resolverlo en ese caso.

MAP-E y MAP-T se vendieron como la solución perfecta, por parte de Cisco (a pesar de que 464XLAT ya estaba teniendo gran éxito, pero claro no había sido propuesto por ellos ...), y sin embargo, apenas han tenido éxito en el mercado. Sólo conozco un caso "mediano" desplegado de MAP-T en US, y otro en Europa, concretamente en Italia que se lo esta planteando. Ninguno de MAP-E. En India se empezó un despliegue y el operador lo detuvo, porque no permitía logging de 5-tuple para cumplir con la ley, y se está moviendo a 464XLAT.

El contrato de los 25.000.000 de usuarios lo hemos ganado con 464XLAT frente a *muy grandes fabricantes* de US y China, que ofrecían MAP-T y CGN.

Saludos,
Jordi
@jordipalet
 
 

El 18/7/20 1:58, "Alejandro D'Egidio" <adegidio en telecentro.net.ar> escribió:

    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



**********************************************
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