[lacnog] Diseño IPv6

Alejandro D'Egidio adegidio en telecentro.net.ar
Sab Jul 18 10:44:51 GMT+3 2020 

Hola Jordi:

¿Cómo estás?

Si, está perfecto que haya cosas que no se coincidan o compartan.
Cada cual tiene su experiencia de diferentes puntos de vista y realidades.

No me quiero meter en tema de costos porque eso hace al negocio de cada compañía la cual deberá evaluar si realmente el CGN es más costoso o no que las IPv4 públicas y las oportunidades de negocio según donde brinden servicio y el segmento de clientes que manejen.

No me parece correcto salir a decirle a la gente que 464XLAT es más barato que CGN o viceversa.
Como dijimos muchas veces "El negocio de IPv6 es seguir en el negocio" pero no porque sea más barato económicamente hablando.

Con el despliegue de IPv6 ocurre algo muy similar, cada empresa tiene su realidad:
- Empresas que le sobran por mucho las IPv4 públicas, no tienen necesidad de poner CGN y no les interesa poner IPv6.
- Empresas que no tienen IPv4 públicas, tienen CPEs o tecnologías de acceso viejas (sin soporte o muy malo de IPv6) y terminan poniendo CGN.
- Empresas que no tienen IPv4 públicas, tienen CPEs y tecnologías de acceso que soportan IPv6, despliegan IPv6 y tienen que poner CGN.
- Empresas que no tienen IPv4 públicas, tienen CPEs y tecnologías de acceso que soportan IPv6, no despliegan IPv6 porque no tienen tiempo y/o conocimiento para hacerlo y tienen que poner CGN.
- Etc.

Cada empresa debe evaluar el escenario en el que se encuentra y definir cuál es mejor estrategia a adoptar para desplegar IPv6 dentro de los mecanismos más recomendados obviamente.
Esto no significa que desplegar IPv6 es fácil y bonito.
Todo lo contrario, un despliegue IPv6 requiere mucho trabajo de análisis (vulnerabilidades, perfiles de tráfico, tipo de clientes, dispositivos de cliente y del ISP, infraestructura, etc).
De ese análisis debe salir un plan que les permita definir bien su meta y cuál es el mejor camino que deben hacer, esto termina impactando en un plan estratégico de la empresa y no es algo que nadie desde afuera pueda asegurar sobre qué estrategia de despliegue debe utilizar si no conoce su realidad.

No se pueden dar ejemplos concretos de servicios para no entrar en confidencialidades con proveedores de contenido pero si, por ejemplo, tuviesen algún servicio que se consume mucho a través de los Smart TVs, seguramente ese tráfico sea IPv4. Si ese tráfico IPv4 se entrega desde una CDN dentro de la infraestructura del proveedor y lo están bypasseando al CGN, al pasar a un esquema de 464XLAT, hoy en día, todo ese tráfico volvería a tener que pasar nuevamente por un equipo de traducción (NAT64).

Hay muchas otras cosas que afectan al despliegue de IPv6 en las redes masivas como el sistema de provisioning que suele ser una limitación también.

En mi opinión para la realidad de muchas empresas de la región que conozco, si ya tienen un gran volumen de tráfico bypasseado de CGN dependiente de dispositivos como Smart TVs y STBs, o están por hacerlo, no conviene migrar a un esquema que te fuerce a pasar nuevamente todo ese tráfico por un equipo de NAT (Ej NAT64).

Con esto no digo que es imposible, todo lo contrario, pero requiere mucho trabajo hacerlo bien para que sea transparente al usuario final; "Doña Rosa" (más del 90% de los usuarios residenciales) no tiene por que saber que existe IPv6 y tampoco le interesa, solo quieren consumir servicios.

Así y todo, desde mi lugar y conocimiento, vengo impulsando 464XLAT en todos los lugares que pueda, estoy convencido que es un muy buen camino como mecanismo de transición pero cada empresa debe evaluar si es el momento o no de implementarlo.

Es por aprovecho a pedirle a la gente que está leyendo esta cadena que también se tome unos minutos para leer y opinar sobre el trabajo que estamos siguiendo:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/


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: Sábado, 18 de Julio 2020 8:17:03
Asunto: Re: [lacnog] Diseño IPv6

Olvidé algo muy importante y creo que hay que reseñar.

Teniendo en cuenta que si usas CGN tus direcciones van a ser puestas en el black-list de (al menos) Sony, y que no las sacan de ahí. Es *muchisimo mas barato* comprar mas direcciones IPv4 y ofrecer a los clientes dual-stack con direcciones IPv4 publicas que invertir en CGN, y cuando hayas rotado todos tus pools por los CGN, comprar mas direcciones.

Es cierto que esta posibilidad no existia en LACNIC hasta que hemos aprobado la política de transferencia de direcciones Inter-RIR, porque no habría suficientes direcciones en la propia región disponibles para transferencias. Solo dependemos de cuando estará disponible la implementación de dicha política. Se había hablado de Junio-Julio si no mal recuerdo. Seguramente alguien del staff de LACNIC lo podría confirmar como estamos con esa implementación?

Atención que no solo es el ahorro de CGNs, sino tambien de sistemas de logging, el OpEx asociado, etc. Además, si luego decides pasarte a IPv6-only con IPv4aaS, lo que estoy seguro que haran la gran mayoria de los operadores al menos para los usuarios residenciales, aunque con diferentes ritmos, te empiezan a sobrar direcciones IPv4, que puedes transferir a quien está tarde en hacer su transición, con lo cual recuperas la inversión. En cambio los CGN no te los va a comprar nadie, o al menos su valor, por la depreciación no será el mismo.

Es obvio que el valor de las direcciones seguirá subiendo por un tiempo, y luego bajará, asi que también hay que tener en cuenta esto.

Otro aspecto importante es que los clientes corporativos que quieran alojar servicios en su propia red, siguen siendo mucho mas facil tener dual-stack "de verdad" (con IPv4 públicas, no con CGN), y ello pagan por el uso mensual de esas direcciones, asi que también recuperas por ahí esa inversión.

Insisto, las cuentas dependen de cada caso, pero si no las haces bien, te vas a equivocar.

Respondiendo a Fernando ... CGN no es un viejo conocido. Son *dos* niveles de NAT44, y no todas las aplicaciones funcionan igual, no puedes gestionar (al menos no todos los operadores que ofrecen CGN lo hacen) puertos de entrada para los usuarios que lo requieren, etc. En NAT44, Sony no te bloquea, en CGN si.

464XLAT es la única tecnología de transición que, en mas de 20 años que llevamos trabajando en transición, ha tenido un éxito tan importante. De hecho, ha alcanzado ese éxito en apenas 3-4 años desde su publicación que fue en el 2013. Estamos hablando de cerca del billón de usuarios con 464XLAT (muy probablemente ya hemos sobrepasado esa cifra, son calculos aproximados teniendo en cuenta solo los operadores mas grandes que conozco que usan 464XLAT, y varios de ellos tienen mas de 100 millones de usuarios).

Saludos,
Jordi
@jordipalet


El 18/7/20 7:33, "LACNOG en nombre de Fernando Gont" <lacnog-bounces en lacnic.net en nombre de fgont en si6networks.com> escribió:

    On 17/7/20 20:58, Alejandro D'Egidio via LACNOG wrote:
    [....]
    > 
    > 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.

    YO creo que la cuestion pricipal es reconocer el problema, y entender 
    que la situación no es bonita.

    Y no hay ninguna opción que esté para destapar una botella de champagne. 
    Hace mas de 20 años que se publico el primer estandar de IPv6, y 25 años 
    mas tarde todavia estamos con la misma problematica.

    Quien hace el esfuerzo de desplegar IPv6 (cosa que *debe* hacer), así y 
    todo tiene que poner dinero para lidiar con IPv4. Y...
    Por cuanto va a tener que lidiar con IPv4? -- imposible saberlo.

    Obviamente, la idea es que, en la medida de lo posible, la mayor 
    cantidad de trafico posible se manee en IPv6 nativo (menos estado en la 
    red, etc.) Luego, uno puede evaluar distintas cosas, tales como intentar 
    tener un solo protocolo en el acceso, Hacer CGN que, asi no sea lo mas 
    bonito es un "viejo conocido", u otras cosas. En ambos casos, ya sea que 
    del lado interno tengamos IPv6 o IPv4, no dejamos de hacer NAT.

    Sin ir mas lejos hace algo asi como 10-15 años atras, hasta el propio Teredo

    Y por todos lados hay cosas que experimentar, suboptimas y demás. CPEes 
    en IPv4 sin soporte UPnP, cosa que ironicamente lleva a que la 
    conectividad e2e er peor en IPv6 que en IPv4, y otras sorpresas variadas.

    Sin ir mas lejos: Hace dias pase varios tunles IPv6 que tengo (aparte de 
    tener IPv6 nativo), de IP4 a IPv6 (O sea, de encapsular IPv6 en IPv4, a 
    encapsular IPv6 en IPv6). ALgunos tuneles, pese a todos tener similar 
    configuracion, no anduvieron. Finalmente teermine capturando trafico, y 
    veo que los paquetes IPv6 contienen encabezado de opciones de destino 
    (DOH) -- para insetar la "tunel encapsulation limit" option, que Linux 
    metia por defecto. Finalmente, deshabilite la opcion, y todo comenzó a 
    funcionar sin problemas. -- Que pasaba? -- RFC7872.

    Nada de estas cosas son "terribles". Simplemente que no es un contexto 
    muy para festejo de nada.

    P.S.: 464xlat no es ni la primera ni la ultima tecnologia de transicion 
    que tuvo un mini momento de gloria. Sin ir mas lejos, hace 10-15 años 
    algunos algunos se habian enamorado hasta de Teredo...

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




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



_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

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