[LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en Segmento Empresas

Tue Jun 21 13:49:30 BRT 2016

Un detalle mas, que olvide antes.

Estas seguro que NAT444 es una solución aceptable?

Con eso no resuelves el problema de despliegue de IPv6, solo “prolongas” artificialmente la vida de IPv4, pero a costa de romper aplicaciones, reducir la capacidad de la intercepción legal, dar peor servicio a los usuarios, evitar que funcionen aplicaciones que hasta ahora lo hacían. En definitiva pagas por un CGN, resuelves a corto plazo la escasez de IPv4, pero te gasta mas, cada dia que pasa, en resolver problemas en tu red, incrementar el coste de la gestión, implementar ALGs, etc.

Saludos,
Jordi

-----Mensaje original-----
De: Jordi Palet Martinez <jordi.palet at consulintel.es>
Fecha: martes, 21 de junio de 2016, 11:43
Para: <lactf at lac.ipv6tf.org>
Asunto: Re: [LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en Segmento Empresas

Tanto 464XLAT como MAP-T o MAP-E tienen sus pros y contras, como todas las tecnologías, pero en absoluto estoy deacuerdo (y lo digo por experiencia en despliegues con clientes), que 464XLAT solo aplica al segmento mobile, sino que aplica a todo tipo de redes de acceso.

Todos los fabricantes de CPEs están trabajando en varias tecnologías, solo los propios clientes (los ISPs) hacen presión para incorporar una u otra. Precisamente 464XLAT en un CPE (CLAT) es mucho mas fácil (el código fuente es muy sencillo y esta diponible como open source) de implementar que MAP, y además es mas eficaz y no tiene impacto en planes de direccionamiento. Ademas tiene la ventaja de que MAP NO esta implementado en redes mobiles, asi que por “numero de posibles” equipos en los que aplica, ganaría por goleada 464XLAT.

Hasta donde yo se, no hay ningún fabricante de CPEs que haya aplicado de momento soporte de transición basado en SDN.

Te recomiendo que veas mi ultima presentación del FLIP-6 que explica pros y contras de cada tecnología y no es algo teorico, sino basado en experiencia en campo, con clientes por todo el mundo.

Saludos,
Jordi

-----Mensaje original-----
De: LACTF <lactf-bounces at lacnic.net> en nombre de Juan Carlos Guardapuclla <jguardapuclla at hotmail.com>
Responder a: <lactf at lac.ipv6tf.org>
Fecha: lunes, 20 de junio de 2016, 19:19
Para: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>
Asunto: Re: [LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en Segmento Empresas

Alejandro, Jaris
Gracias por el feedback.
De lo revisado veo que X464LAT aplicaría mas al segmento mobile, ya que ya existe el soporte a nivel de los smartphones.
A nivel del acceso fijo, para residencial como mencionan NAT444 es una solución aceptable, pero a nivel de clientes Enterprise veo que MAP T/E es una opción que Cisco comenzo a impulsar, pero esta amarrado al soporte a nivel de CPE y saber cuan maduro
 es la solucion.

Esto me hizo investigar de una solucion a nivel de CPE agnostico a la solucion y encontre este slide de vCPE SDN IPv6, que me parece muy interesante.
https://www.ietf.org/proceedings/88/slides/slides-88-sdnrg-0.pdf

A Software Defined Approach to Unified IPv6 Transition <https://www.ietf.org/proceedings/88/slides/slides-88-sdnrg-0.pdf>
www.ietf.org
Motivation & Rationale • Design a low-cost, unified approach to IPv6 transition • Low-cost: a virtual CPEs(e.g. vRGW) or a SDN enabled

Igual seguiré investigando para tener mas claro estas tecnologías... 
Saludos

Juan Carlos G.

________________________________________
De: LACTF <lactf-bounces at lacnic.net> en nombre de Alejandro D'Egidio <adegidio at telecentro.net.ar>
Enviado: jueves, 16 de junio de 2016 19:07
Para: lactf at lac.ipv6tf.org
Asunto: Re: [LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en Segmento Empresas 

Tal como aclaran creo que, no es para nada recomendado utilizar una solución de CGN para un corporativo. Si podría aplicar un CGN para los residenciales.
Específicamente con NAT64 seguramente vas a tener muchos problemas por diferentes aplicaciones que no utilicen DNS.
Como aclara Jordi, algo mucho mas recomendado es 464XLAT, tomalo como una evolución del NAT64. El problema de 464XLAT es que está muy atado a la tecnología de acceso. Por ejemplo, para el caso particular de las redes de Cable, solo hay un fabricante de
 CableModems que están comenzando a implementar CLAT para los nuevos CMs. El resto de los fabricantes no quiere invertir en esto y su solución es DS-Lite.

Saludos,
Alejandro D'Egidio
Jefe de Ingeniería de Backbone
adegidio at telecentro.net.ar
Lavardén 155 | Tel: 54 11 3977 1025
C1437FBC | CABA | Argentina
TELECENTRO S.A.

ESTE MENSAJE ES CONFIDENCIAL. Puede contener información amparada por el secreto profesional. Si usted ha recibido este e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y tenga la amabilidad de eliminarlo de su sistema; no deberá copiar
 el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.

THIS MESSAGE IS CONFIDENTIAL. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; should also not copy the
 message nor disclose its contents to anyone. Many thanks.

________________________________________
De: "Jaris Aizprua" <jarisaizprua at gmail.com>
Para: lactf at lac.ipv6tf.org
Enviados: Miércoles, 15 de Junio 2016 23:15:15
Asunto: Re: [LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en        Segmento Empresas

Los corporativos es muy complicado que no les entregues una pública, por algo pagan un precio elevado y también dependiendo de los tipos de servicios que soliciten y que tengan en su red interna.
En mi experiencia, con el uso de CGN a nivel residencial, se liberaron muchos recursos IPv4 públicos los cuales fueron destinados a clientes corporativos e incluso al mismo ISP para usarlos en nuevas plataformas y/o servicios.
Saludos!!!
On Jun 15, 2016 5:57 PM, "Juan Carlos Guardapuclla" <jguardapuclla at hotmail.com> wrote:

Gracias Jordi por la respuesta.
Si le di una revisada rápida a tu presentación, creo que eran 02 vídeos.. Lo vuelvo a revisar con mas detenimiento y te fastidio si tengo alguna duda.

Nuevamente muchas gracias.

Saludos
Juan Carlos G.

> Date: Wed, 15 Jun 2016 17:24:35 -0500
> From: jordi.palet at consulintel.es
> To: lactf at lac.ipv6tf.org
> Subject: Re: [LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en Segmento Empresas
> 
> Hola Juan Carlos,
> 
> No te recomiendo en ningún caso NAT64, sino 464XLAT, de hecho es lo que usa T-Mobile y los otros 3 operadores de US, y muchos otros operadores en todo el mundo.
> 
> Para los casos empresariales hay que diferenciar si el cliente empresarial solo necesita la conexión a Internet para navegación, recepción de correo, uso de servicios, etc., en cuyo caso aplicaría igualmente 464XLAT (o alternativamente MAP T o E) o bien si
 necesita “exponer” servicios a través de esa red. Si así fuera, yo SOLO recomendaría doble-pila para esos clientes y que por supuesto no pasen por ningún tipo de CGN.
> 
> No se si viste mi ultima presentación en el FLIP-6 en el evento de La Habana?
> 
> Si se trata de un datacenter, las consideraciones son muy diferentes.
> 
> Si necesitas información mas detallada de algún caso/ejemplo que no sea genérico, escríbeme en privado e intento ayudarte.
> 
> Saludos,
> Jordi
> 
> 
> -----Mensaje original-----
> De: LACTF <lactf-bounces at lacnic.net> en nombre de Juan Carlos Guardapuclla <jguardapuclla at hotmail.com>
> Responder a: <lactf at lac.ipv6tf.org>
> Fecha: miércoles, 15 de junio de 2016, 16:57
> Para: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>
> Asunto: [LAC-TF] Experiencias de despliegue de NAT444 y NAT64 en Segmento Empresas
> 
> >Estimados buenas,Unas consultas:
> >Se entiende que a nivel de la región, muchos ISP tienen implementado el uso de NAT444 para el segmento residencial, y como que esta ayudando con todos los pro/crons de la solucion.
> >
> >Pero a nivel del segmento empresarial donde tipicamente se ofrecen un rango de IPv4 publicas por cliente , y donde también se tiene el problema de agotamiento de IPv4 publicas, el hecho de aplicar NAT444 para ese segmento, como que no lo veo sentido.
> >
> >Revisando este link de deployments only IPv6, hay experiencia en T-Mobile con NAT64, pero esta orientado a usuarios móviles.
> >https://www.youtube.com/watch?v=EfjdOc41g0s
> >
> >
> >Conocen de algún despliegue en la región donde se este aplicando NAT64 a nivel ISP para cliente empresariales ??
> >Como se esta atacando el problema donde existe la necesidad de ofrecer un servicio de Internet Empresarial pero no se cuenta con pooles de IPv4 publicos disponibles.
> >
> >Es NAT64 una solución a este problema o existe algún otro esquema de despliegue que cubra mejor esta necesidad.
> >Como que comercialmente ya no es una opción valida seguir ofreciendo nuevos pooles de IPv4 publicas, así que adicional al tema técnico, creo que debería ir acompañado de la mano, la definición de un nuevo servicio a nivel comercial.
> >
> >Gracias por su apoyo....!!!
> >Saludos
> >Juan Carlos G.
> >
> > 
> >_______________________________________________
> >LACTF mailing list
> >LACTF at lacnic.net
> >https://mail.lacnic.net/mailman/listinfo/lactf
> >Cancelar suscripcion: 
lactf-unsubscribe at lacnic.net <mailto:lactf-unsubscribe at lacnic.net>
> 
> 
> 
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: 
lactf-unsubscribe at lacnic.net <mailto:lactf-unsubscribe at lacnic.net>

_______________________________________________
LACTF mailing list
LACTF at lacnic.net
https://mail.lacnic.net/mailman/listinfo/lactf
Cancelar suscripcion: 
lactf-unsubscribe at lacnic.net <mailto:lactf-unsubscribe at lacnic.net>

_______________________________________________
LACTF mailing list
LACTF at lacnic.net
https://mail.lacnic.net/mailman/listinfo/lactf
Cancelar suscripcion: lactf-unsubscribe at lacnic.net

_______________________________________________
LACTF mailing list
LACTF at lacnic.net
https://mail.lacnic.net/mailman/listinfo/lactf
Cancelar suscripcion: lactf-unsubscribe at lacnic.net