[lacnog] Diseño IPv6

[JORDI PALET MARTINEZ]

Hola Fernando,

No es tan fácil explicar todos los datos y detalles, pero sigo afirmando que tengo razón en mi argumentación.

1) Usando CGN, los TVs que no soportan IPv6 tienen una traducción en el NAT44 del usuario y otra en el NAT44 del operador. Algunos CDNs pueden (no todos) recibir direcciones privadas, pero solo es eficaz si eres un ISP que tiene sus propias CDNs, porque son direcciones no enrutables, etc. La traducción en el CGN es mas costosa en cuanto a número de direcciones IPv4, y soporte en el helpdesk (número menor de puertos por usuario), así como los propios CGN que cualquier otra traducción. La traducción en el NAT44 del CPE no tiene "coste" para el operador. Esta traducción además implica que servicios como PSP te bloquean las direcciones detectadas en el CGN, es decir, las tienes que ir rotando, hasta que las "agotas todas" (nadie ha conseguido que Sony le libere las IPs de las black-lists, y por tato además de invertir en los CGN, tienes que invertir en mas y mas direcciones IPv4. Y atención que en muchos casos se utiliza CGN para seguir creciendo con IPv4, sin en paralelo dar una solución de dual-stack, porque ello requiere cambiar o actualizar CPEs (igual que en los casos siguientes).

2) Usando 464XLAT, sin optimización, los TVs que no soportan IPv6 tienen una traducción en el CLAT (NAT46) y otra en el NAT64, de nuevo salvo que el operador tenga las CDNs en su red y el CDN admita direcciones NAT64, etc. La traducción en el NAT46, igual que en el caso de NAT44 del CPE, no tiene costo para el operador. La traducción en el NAT64 tiene mucho menor coste para el operador. Se requieren menos direcciones, no hay limitación de puertos, y hay menos coste en el helpdesk. El volumen de tráfico reportado en este caso, por diversos operadores, es de solo el 25% pasando por el NAT64, y con el paso de los años ira mejorando según haya mas TVs con IPv6.

3) Usando 464XLAT, con optimización, los TVs que no soportan IPv6 tienen una traducción en el CLAT (NAT46) y no hay mas. Es parecido al 2, pero mejor, porque utilizas muchísimo menos NAT64. Evidentemente el volumen de tráfico pasando por el NAT64 sería mucho menor que el 25%.

Obviamente si piensas a medio-largo plazo, hay mas y mas TVs con IPv6, y por tanto mas a mi favor hacia el caso 3.

Por otro lado DNSSEC con 464XLAT, si lo deseas, no es un problema. Basta con no usar DNS64, y con ello se incrementa la carga en el CLAT, pero como hemos dicho, el CLAT esta en el CPE del usuario, así que no es un coste para el operador.

Estoy en medio de un despliegue de 25.000.000 de usuarios. Asi que son datos muy contrastados, comparados con despliegues anteriores en los que solo tenia entre 3.000 y 15.000 usuarios en un mismo ISP.

En este despliegue se han hecho pruebas de todos tipo, durante meses, se han hecho estudios economicos de todas las opciones, se ha intentado buscar "la pega" para no optar por 464XLAT, y te aseguro que un departamento del propio cliente que no estaba convencido ha intentado hacer de "malo" para usar CGN en lugar de 464XLAT y no ha podido con ello. Igualmente te puedo decir que varios grandes fabricantes que querían usar o CGN u otras opciones de transición (otros IPv4aaS) tampoco pudieron demostrar lo contrario ni técnica ni económicamente, y por eso nos llevamos el proyecto.

Saludos,
Jordi
@jordipalet
 
 

El 14/7/20 19:57, "Fernando Gont" <fgont en si6networks.com> escribió:

    Holis,

    Acabo de bajar del DeLorean (*). Entre-lineas....

    On 30/5/20 11:35, JORDI PALET MARTINEZ via LACNOG wrote:
    [....]
    > 
    > Pdta: IPv6 no estaría llegando al 75% , porque muchos Televisores no los 
    > soporta. Eso entiendo.
    > 
    > Por eso precisamente no es bueno usar NAT444 (CGN) como tu quieres 
    > hacer. Lo correcto es ir a IPv6-only + IPv4aaS con 464XLAT. Ver RFC8683 
    > y RFC8585.

    Esto no es correcto.

    Usar IPv6-only + IPv4aaS es muchos casos justamente es problematico, ya 
    que debe hacerse NAT dos veces, cuando en ocasiones el ISP puede 
    prescindir de hacer NAT en su red (e.g. cuando puede acceder al cache 
    via direcciones privadas).

    De ahi, entiendo, que al encontrarse con este problema Alejandro 
    D'Egidio (en CC) propuso una "optimizacion" para intentar mitigar este 
    problema: 
    https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization  . -- 
    aunque esto no es tan simple, por ej. por su interferencia con DNSsec.

    (*) https://www.youtube.com/watch?v=DYE3UQ-H0cs

    Besis para todes,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: fgont en si6networks.com
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492







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