[lacnog] Diseño IPv6

[JORDI PALET MARTINEZ]

Hola Fernando, 
 

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

    On 14/7/20 15:18, JORDI PALET MARTINEZ wrote:
    > Hola Fernando,
    > 
    > No es tan fácil explicar todos los datos y detalles, pero sigo
    > afirmando que tengo razón en mi argumentación.

    Los argumentos sobre performance y costos, sin ponerle numeros,
    patrones de uso, etc, no tienen mucho sentido.

El problema es que muchos de estos datos son confidenciales, nos guste o no, nadie suele autorizar a revelarlos, porque esos datos hay que calcularlos en cada caso. Cuando tienes muchos casos, ves que son equivalentes entre la mayoría de las redes. Los de performance te los he aclarado en la argumentación, aunque obviamente dependen de que fabricantes usas.

    De hecho, el despliegue de quic baja notablemente los requisitos en
    materia de puertos.

Y soy gran fan de quic, pero desafortunadamente hoy por hoy, el volumen de trafico es bajo.

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

    No entiendo el argumento: si vas a compartir las direcciones IP del lado
    publico, cual seria la preocupacion sobre lo que hay del lado privado?

Estoy explicando dos cosas: 1) cuantas traducciones tienes 2) las direcciones que compartes solo en la parte publica (las IPv4 publicas), no hablo para nada de las direcciones en el lado privado.

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

    Idem arriba.

    Slds,
    -- 
    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.