[LAC-TF] Netfilter developers working on NAT for ip6tables

Thu Dec 1 21:40:30 BRST 2011

On 12/01/2011 05:56 PM, Juan Ant. Matos wrote:
> Coincido con Jordi, Christian, y en parte con Fernando.
Me gustaria que NAT no sobreviviera la transicion a IPv6, pero al parecer muchos *creen* que lo necesitaran en el futuro.

http://lists.si6networks.com/pipermail/ipv6hackers/2011-December/000334.html
http://lists.si6networks.com/pipermail/ipv6hackers/2011-December/000335.html


> Lo ideal sería, desde mi perspectiva que el usuario tuviera la libertad de comunicarse de e2e sin tener que recurrir a artilugios tecnicos magicos para lograr esto.
>
> Que mi sobrina Stephanie de 9 años (Que talvez pasa mas horas en Internet que yo mismo), pueda utilizar un Juego con otra de sus amigas del colegio, o que pueda utilizar un software que permita SIP-to-SIP para comunicarse con las amigas del colegio, sin tener la necesidad de configurar aspectos complejos para permitir esto.
>
> No se trata de vender IPv6, sencillamente en este nuevo protocolo muchos vemos la oportunidad de vivir otro Internet, menos complejo, desde la perspectiva del usuario final. Aunque al usuario no le importaria si la comunicacion de e2e es posible gracias a IPv6, o CLNP, o IPv7(si este llegara a existir). Pero los usuarios agradecerian en su subconsciente, el hecho de poder usar aplicaciones sobre Internet de una manera transparente y sin necesidad de ser un "Ingeniero de la NASA", para ponerlas a andar.
>
> Saludos,  
>
>
>
> Juan Ant. Matos
>
> -----Original Message-----
> From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> Sender: <lactf-bounces at lacnic.net>
> Date: Thu, 1 Dec 2011 16:14:59 
> To: <lactf at lac.ipv6tf.org>
> Reply-To: <lactf at lac.ipv6tf.org>
> Subject: Re: [LAC-TF] Netfilter developers working on NAT for ip6tables
>
> Coincido con Christian, el core no esta filtrado y si lo esta, suele ser
> un error (prefiero pensar eso a mala fe). Y exactamente lo mismo pasa con
> la red de agregación, etc.
>
> Yo he viso en varias ocasiones filtros que han sido reportados y se han
> retirado, creo que eso confirma que no suele ser a propósito.
>
> Solo desde el CPE (da igual que sea residencial que corporativo que un
> proveedor de contenidos) hacia el interior de las redes que conectan,
> pueden presentar filtros.
>
> De hecho, lo contrario en Europa ha ocasionado ya sanciones a ISPs y el
> cese de sus malas practicas, pues las autoridades han de defender a los
> consumidores y por tanto la Neutralidad de la Red, y la Comision Europea
> se lo esta tomando muy pero que muy en serio. De hecho, hay una discusión
> en marcha, según la cual, el uso de CGN seria contrario a la neutralidad
> de la red, y quizás solo se llegue a autorizar siempre y cuando al mismo
> tiempo se despliegue IPv6 y con una limitación temporal. Es obvio que CGN
> al compartir puertos y direcciones rompe el protocolo, mucho mas allá de
> un simple NAT, pero ademas, el NAT estaba en la red del usuario y era "su
> problema", con CGN deja de serlo.
>
> Interesante perspectiva la que se presenta.
>
> Saludos,
> Jordi
>
>
>
>
>
>
> -----Mensaje original-----
> De: Christian O'Flaherty <christian.oflaherty at gmail.com>
> Responder a: <lactf at lac.ipv6tf.org>
> Fecha: Thu, 1 Dec 2011 15:07:00 -0600
> Para: Fernando Gont <fgont at si6networks.com>
> CC: <lactf at lac.ipv6tf.org>
> Asunto: Re: [LAC-TF] Netfilter developers working on NAT for ip6tables
>
>>>> Sin embargo si vos y yo desarrollamos algo simple y nuevo, y lo
>>>> comenzamos a probar cada uno desde su casa, funcionará sin problema
>>>> mientras no tengamos cosas raras en el medio que meta el proveedor.
>>> En la mayoria de los casos, esto se vuelve virtualmente imposible.
>>> Firewalls y NAT (en los bordes) son el principal problema. Pero en el
>>> core, por ejemplo, muchos routers tambien filtran paquetes con opciones
>>> IP.
>> Esa no es mi experiencia. Como cliente de 3 ISPs en Argentina, como
>> administrador en una red regional y otra global y como usuario en
>> Uruguay, no he visto filtros en la red. El CORE es absolutamente bobo.
>>
>>> A modo de un simple ejemplo, *uno* de los argumentos para "deprecatear"
>>> (http://www.gont.com.ar/rfcs/rfc6093.pdf) el mecanismo de "datos
>>> urgentes" en TCP fue justamente que Cisco PIX filtraba, por default,
>>> paquetes que hacen uso de este mecanismo. Dado lo ampliamente desplegado
>>> que está este producto, el mecanismo ya no es confiabvle (reliable).
>> En el core de las redes no hay PIX u otros firewalls... no creo que
>> existan firewalls con puertos de 10G. Incluso las versiones de
>> software de los routers que usamos en el core son de las mas básicas
>> (y estables) y muchas veces bien antiguas.
>>
>>> Hay varios estudios publicados sobre cuan dificil es hacer "funcionar"
>>> trafico con opciones TCP o IP... lo cual muestra quemas allá del
>>> direccionamiento o conectividad extremo a extremo, en lineas generales
>> Justamente esa es la prueba que el core es bobo... Esos routers solo
>> miran la IP destino y disminuyen el TTL. Pedirles que procesen el
>> campo options es demasiado :-)
>>
>>> El problema es que, a la práctica, los usuarios no controlan un NAT. Vos
>>> controlarás el tuyo, yo controlaré el mio, etc. Pero "Doña Rosa"
>>> simplemente "enchufo el router inalambrico que compro en el
>>> supermercado, apra usar Internet". -- lease, no se va a poner a
>>> configurar el dispositivo, y en todos esos casos, la posicion del NAT
>> No esperamos aportes innovadores de "Doña Rosa". Estoy pensando en
>> chicos de 15 años que saben mucho mas que eso.
>>
>> Cuanto mas simple sea para ellos desarrollar y probar sus cosas mejor
>> será Internet.
>>
>>> Por otro lado (y mal que me pese), aquellos avances que han tenido un
>>> impacto concreto creo que han sido en la capa de aplicacion, y no en las
>>> capaz de transporte o internet. (Digo "mal que me pese", ya que dado que
>>> en gral. trabajo en capas de transporte hacia abajo.)
>> Justamente es a las aplicaciones que debemos simplificarle la tarea.
>> El que desarrolla la aplicación (que no sea sobre la web) tendrá que
>> dedicar mas tiempo a atravesar cajas "manipuladoras de paquetes" que a
>> su propia idea.
>>
>>> El "problema" con el principio e2e es que, entre otras cosas, apunta a
>>> tener una red con al que todo el mundo puede jugar. Pero en ambientes de
>>> produccion, la filosofia aplicada usualmente es la opuesta: solo podés
>>> jugar con aquellas cosas que *necesitas* poder jugar.
>> Eso es correcto... La gente de IT de las empresas debe hacer eso,
>> dejando pasar solo lo "autorizado". Pero es decisión del cliente
>> final. En nuestras casas decidimos nosotros.
>>
>> Christian
>> _______________________________________________
>> LACTF mailing list
>> lactf at lac.ipv6tf.org
>> https://mail.lacnic.net/mailman/listinfo/lactf
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf
>
>
> --------------------------------