[lacnog] 464XLAT ofrece mejores prestaciones que los demás mecanismos de transición

Vie Sep 27 16:41:34 -03 2019

Hola a todos: 
Creo que se armó un muy buen tema de discusión respecto a 464XLAT, o al menos es un tema que a mi me interesa mucho. 
Veo una diferencia muy grande entre el despliegue de 464XLAT en redes fijas y móviles: 

    * Red Móvil : 
        * Celular : Claramente acá tiene un muy buen soporte este mecanismo al funcionar el CLAT directamente en el UE. 
        * WiFi : Hasta donde sé, CLAT en los celulares solo funciona sobre la conexión móvil celular solamente. Sería muy interesante que CLAT funcione sobre la interfaz WiFi de los UE. Adicionalmente el UE tendría que recibir un prefijo en vez de una sola IPv6. En este punto hasta donde sé, BENU ya soporta Unique IPv6 Prefix per Host [RFC 8273] en el xMEG. 
    * Red Fija : 
        * CLAT en el CPE : Como vemos, claramente la funcionalidad de CLAT tiene que estar en el CPE y ahí es donde está el gran desafío. Yo veo vengo viendo solicitando hace tiempo esta funcionalidad en los CableModems y los fabricantes normalmente responden que no lo van a desarrollar por un solo cliente que se los solicite. Hay ISPs que les interesa tenerlo pero como no está soportado en sus CPEs no pueden avanzar. Termina siendo como el cuento del huevo y la gallina. Por otro lado, en nuestro caso, luego de algunos años de insistir, conseguimos tener un CableModem con FW con CLAT incluido. Y acá es donde nos planteamos, "¿entonces ya podemos desplegar 464XLAT en nuestra red? Y acá vamos al siguiente punto. 
        * Tráfico en NAT64 (PLAT) : El CLAT va a enviar todo el tráfico originado en IPv4 privado al PLAT utilizando IPV6 para que lo traduzca a IPv4 público. Si en los domicilios de los abonados sabemos que hay muchos dispositivos que funcionan solo con IPv4 o están en DS pero consumen servicios en IPv4, todo este tráfico va a pasar siempre por el PLAT; este es el caso de la gran mayoría de los Smart TVs y Set-Top-Boxes. Hoy en día existen soluciones de optimización con IPv4 donde CDNs (por ej Google) permiten que los clientes de CGN (IPv4 privada, ej: 100.64.0.0/10) puedan consumir el contenido directamente con la IPv4 privada sin pasar por el CGN. Con esto se logra mejorar el rendimiento, eliminar un punto de falla y no depender del CGN para seguir creciendo. Si se implementa 464XLAT, por ejemplo, los Smart TVs con aplicación de Google van a comenzar a tener tráfico nuevamente por una plataforma de NAT (NAT64) y perderemos la optimización previamente generada. En este caso es donde veo que la solución no escala hasta que no se resuelva esta optimización para 464XLAT; para este caso se planteó el draft [ https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1 | https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1 ] . Otro caso donde puede funcionar es si el ISP no tiene implementada esta Optimización actualmente en IPv4. 

Saludos, 
Alejandro 

De: "Henri Alves de Godoy" <henri.godoy en fca.unicamp.br> 
Para: "Latin America and Caribbean Region Network Operators Group" <lacnog en lacnic.net> 
Enviados: Jueves, 12 de Septiembre 2019 14:08:31 
Asunto: Re: [lacnog] 464XLAT ofrece mejores prestaciones que los demás mecanismos de transición 

Em qua, 11 de set de 2019 às 22:49, JORDI PALET MARTINEZ via LACNOG < [ mailto:lacnog en lacnic.net | lacnog en lacnic.net ] > escreveu: 

Hola Henri, 

Totalmente de acuerdo, yo de hecho, utilizo Jool para los trainings. 

Gracias Jordi por los comentarios. 

BQ_BEGIN

Sin embargo, en un entorno doméstico, creo que no hay un “servidor” para instalar una VM, aunque probablemente en pocos años, todos tendremos algo en nuestro hogar tipo “Raspberry Pi”, aunque no lo sepamos, donde podría correr esa VM o directamente CLAT en el propio OS de dicha máquina … claro para entonces espero que no necesitemos pedirles a los fabricantes de CPEs que incorporen el CLAT. O estoy soñando despierto? ;-) 

BQ_END

Creo que con el tiempo y con un mayor uso de XLAT debería incluir. Pero no solo CPEs sino controladores de red wifi como Aruba, Ruckus, Ubiquiti, etc., pero no he visto este movimiento o interés. 

BQ_BEGIN

Si te refieres a colocar la VM en el ISP, entonces no tendría sentido, porque de nuevo estarías ofreciendo “dual-stack” en la WAN del cliente, y la idea es “huir” de IPv4 (y de su CapEx y OpEx) cuanto antes mejor, en la infraestructura del ISP. 

BQ_END

Sí, quise decir en el ISP o en un datacenter o core de la Universidad . Si bien existe una IP literal en las URL o aplicaciones, tendremos que tener IPv4 para entregar a un usuario, por ahora, desafortunadamente. 

Continuamos con las pruebas, el aprendizaje y entendemos mejor esta transición necesaria para todos. 

Saludos, 

Henri. 

BQ_BEGIN

Por cierto, OpenWRT tiene su propio CLAT como módulo pero tambien funciona allí Jool que es mucho mas completo y permite muchas mejoras interesantes. 

Saludos, 

Jordi 

@jordipalet 

El 12/9/19 1:32, "LACNOG en nombre de Henri Alves de Godoy" < [ mailto:lacnog-bounces en lacnic.net | lacnog-bounces en lacnic.net ] en nombre de [ mailto:henri.godoy en fca.unicamp.br | henri.godoy en fca.unicamp.br ] > escribió: 

Hola Fernando, 

En caso de que le preocupe, una VM con servicio CLAT podría colocarse a mitad de camino (Jool funciona bien). Por lo tanto, no tiene que confiar en el dispositivo cliente para que sea compatible con CLAT, la versión del sistema operativo, etc., y creo que resolverá la mayoría de sus problemas de los que habló. Cuanto menos interactúe con el cliente, mejor. 

Saludos, 

Att, 

Henri. 

Em qua, 11 de set de 2019 às 12:21, Fernando Frediani < [ mailto:fhfrediani en gmail.com | fhfrediani en gmail.com ] > escreveu: 

BQ_BEGIN

Hola Jordi 

On 11/09/2019 11:55, JORDI PALET MARTINEZ via LACNOG wrote: 
> El soporte de CPEs se resuelve usando OpenWRT donde no haya soporte nativo, pero en lo que todos tenemos que hacer fuerza es en exigir a los proveedores que soporten el RFC8585. De hecho, si miras ese documento, mis dos coautores son empleados de dos fabricantes y obviamente tienen soporte, pero hay otros! 
Entonces este es uno de los problemas. Para mí, usted u otras personas 
técnicas en esta lista como clientes, es muy fácil usar OpenWrt en un 
router, pero a nivel de ISP creo que hay algunas dificultades como: 

- Flash masivo de CPEs antes de entregarlos a los clientes (lo que 
implica tiempo de la personal para hacerlo). 
- Compilación de una imagen personalizada para cada tipo de CPE que 
utiliza el ISP (más tiempo y experiencia del personal). 
- La certificación de que el modelo CPE utilizado tiene soporte 100% 
OpenWrt, porque hay modelos que todavía tienen algún tipo de problema 
con el driver wifi u otro y solo funciona bien en el firmware original 
propietario. 
- Casos en los que el ISP no entrega un router Wifi y depende del 
cliente ir a alguna tienda y comprar cualquier modelo (que en el 
firmware estándar aún no tiene CLAT). 
> Para mas info sugiero la lectura de este documento que esta esperando recibir el número de RFC (esta en la fase de publicación - RFC Editor, donde puede tener algún cambio exclusivamente editorial): 
> 
> [ https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ | https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ ] 

Gracias, lo leeré, parece interesante. 

Fernando 

> 
> De hecho realizaré una breve presentación del mismo en el próximo LACNOG. 
> 
> Saludos, 
> Jordi 
> @jordipalet 
> 
> 
> 
> El 11/9/19 21:43, "LACNOG en nombre de Fernando Frediani" < [ mailto:lacnog-bounces en lacnic.net | lacnog-bounces en lacnic.net ] en nombre de [ mailto:fhfrediani en gmail.com | fhfrediani en gmail.com ] > escribió: 
> 
> Hola Jordi 
> Gracias por compartir 
> 
> Estoy muy interesado en 464XLAT y, sin duda, es uno de los mecanismos 
> más interesantes para adoptar en las redes móviles, como lo ha sido en 
> muchos casos exitosos en todo el mundo. 
> No tengo dudas sobre el mejor performance y también es interesante no 
> tener que hacer direccionamiento IPv4 para varios segmentos de la red. 
> 
> Pero creo que hay 2 puntos principales que dificultan un poco la banda 
> ancha fija, tales como: 1) asegurarse de que cada CPE tenga soporte CLAT 
> (la mayoría de los firmwares estándar no lo tienen) y 2) el problema con 
> el uso de IPv4 literal. 
> 
> ¿Tiene algún comentario sobre estos dos puntos? 
> 
> Saludos 
> Fernando Frediani 
> 
> On 11/09/2019 08:14, JORDI PALET MARTINEZ via LACNOG wrote: 
> > Hola a todos, 
> > 
> > En una presentación (IPv6 Performance) de Geoff Huston, esta mañana en el APNIC en Chiang Mai, confirma que sus ultimas mediciones indican que el mecanismo de transición que menos problemas da, y que ofrece mejor "performance" es 464XLAT. 
> > 
> > En este enlace está el vídeo, donde es mucho mas claro a este respecto que incluso en las diapositivas, así como las propias diapositivas: 
> > 
> > [ https://conference.apnic.net/48/program/schedule/#/day/7/ipv6-deployment2 | https://conference.apnic.net/48/program/schedule/#/day/7/ipv6-deployment2 ] 
> > 
> > Igualmente aparecen datos importantes para operadores de Colombia y Guatemala (en nuestra región, en la de AP son casos como Nueva Zelanda, China, Vietnam), pues ha descubierto importantes fallos, posiblemente debidos precisamente a los mecanismos de transición que están usando, aunque puede haber otras causas. 
> > 
> > En el mapa de la diapositiva "The big picture" se ven otros paises con problemas (en rojo), ejemplo Paraguay, Nicaragua, Costa Rica, Ecuador y Perú. 
> > 
> > Saludos, 
> > Jordi 
> > @jordipalet 
> > 
> > 
> > 
> > 
> > 
> > ********************************************** 
> > IPv4 is over 
> > Are you ready for the new Internet ? 
> > [ http://www.theipv6company.com/ | 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 
> > [ mailto:LACNOG en lacnic.net | LACNOG en lacnic.net ] 
> > [ https://mail.lacnic.net/mailman/listinfo/lacnog | https://mail.lacnic.net/mailman/listinfo/lacnog ] 
> > Cancelar suscripcion: [ https://mail.lacnic.net/mailman/options/lacnog | https://mail.lacnic.net/mailman/options/lacnog ] 
> _______________________________________________ 
> LACNOG mailing list 
> [ mailto:LACNOG en lacnic.net | LACNOG en lacnic.net ] 
> [ https://mail.lacnic.net/mailman/listinfo/lacnog | https://mail.lacnic.net/mailman/listinfo/lacnog ] 
> Cancelar suscripcion: [ https://mail.lacnic.net/mailman/options/lacnog | https://mail.lacnic.net/mailman/options/lacnog ] 
> 
> 
> 
> 
> ********************************************** 
> IPv4 is over 
> Are you ready for the new Internet ? 
> [ http://www.theipv6company.com/ | 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 
> [ mailto:LACNOG en lacnic.net | LACNOG en lacnic.net ] 
> [ https://mail.lacnic.net/mailman/listinfo/lacnog | https://mail.lacnic.net/mailman/listinfo/lacnog ] 
> Cancelar suscripcion: [ https://mail.lacnic.net/mailman/options/lacnog | https://mail.lacnic.net/mailman/options/lacnog ] 
_______________________________________________ 
LACNOG mailing list 
[ mailto:LACNOG en lacnic.net | LACNOG en lacnic.net ] 
[ https://mail.lacnic.net/mailman/listinfo/lacnog | https://mail.lacnic.net/mailman/listinfo/lacnog ] 
Cancelar suscripcion: [ https://mail.lacnic.net/mailman/options/lacnog | https://mail.lacnic.net/mailman/options/lacnog ] 
BQ_END

-- 

-- 

Henri Alves Godoy 

Tecnologia da Informação e Comunicação 

Faculdade de Ciências Aplicadas - FCA 

Universidade Estadual de Campinas - UNICAMP 

Fone: (19) 3701-6682 

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

********************************************** 
IPv4 is over 
Are you ready for the new Internet ? 
[ http://www.theipv6company.com/ | 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 
[ mailto:LACNOG en lacnic.net | LACNOG en lacnic.net ] 
[ https://mail.lacnic.net/mailman/listinfo/lacnog | https://mail.lacnic.net/mailman/listinfo/lacnog ] 
Cancelar suscripcion: [ https://mail.lacnic.net/mailman/options/lacnog | https://mail.lacnic.net/mailman/options/lacnog ] 

BQ_END

-- 
-- 
Henri Alves Godoy 
Tecnologia da Informação e Comunicação 
Faculdade de Ciências Aplicadas - FCA 
Universidade Estadual de Campinas - UNICAMP 
Fone: (19) 3701-6682 

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

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190927/2054f009/attachment-0001.html>