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

[Juan Ant. Matos]

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

Cuando hablas de produccion, talvez te estas refiriendo a empresas o ISP, en donde dentro nosotros lo que trabajamos con el tema, delimitamos haciendo uso de diferentes tecnicas y herramientas delimitamos lo que puede o no hacer el usuario.

Pero el usuario final x, tu madre, mi sobrinita, o cualquier otro que este directamente conectada desde el hogar a un ISP deberia tener la oportunidad de comunicarse si asi lo desea con otro usuario x, en el otro extremo, (con el concentimiento de este ultimo) hoy NAT(entre otras cosas) complica este tipo de comunicacion. 

Por mucho tiempo existiran variantes de NAT, para resolver problemas distintos, aun en IPv6, pero talvez, en un futuro ignoro que tan distante, este nuevo protocolo, en tal sentido, reduzca la complejidad de las comunicaciones de Extremo a Extremo, (al menos desde la perspectiva de un usuario final).


Slds.



Juan Ant. Matos

-----Original Message-----
From: Fernando Gont <fgont at si6networks.com>
Sender: <lactf-bounces at lacnic.net>
Date: Wed, 30 Nov 2011 19:18: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

Hola, Christian,

On 11/30/2011 11:15 AM, Christian O'Flaherty wrote:
> > El e2e digamos que yo no existe. Sin llegar al caso particular de
> > firewalls propiamente dichos, lo cierto es que hay miles de filtros y
> > middle-boxes que limitan las cosas que podes usar. Sin ir mas lejos,
> > habia un estudio que mostraba que si enviabas paquetes IPv4 con
> > opciones, en un punto u otro de la red eran descartados.
> 
> 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.

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

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
la red Internet no cuenta con este principio, y es esperable
("esperable", *no* "deseable") que la red IPv6 siga la misma linea.
-- Las implementaciones de protocolos suelen ser tan fragiles que eso
termina siendo una motivacion para filtrar paquetes "raros" o que
transporten protocolos/datos desconocidos....



> Además, si esa idea es útil para muchos, sin mucho esfuerzo se empezará
> a difundir. Pasar por un NAT que uno controla complica un poquito pero
> no mucho... pasar por un NAT que no controlamos nos complicará mucho el
> programa y seguramente nos desalentará.

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
termina siendo anecdotica.



> La innovación y los servicios nuevos generalmente son iniciados por unos
> pocos (muy pocos) que generalmente no tienen recursos especiales sino
> ideas novedosas. Muchas veces son ideas bien simples y fáciles de
> iniciar siempre y cuando no haya que pedir permiso para poder probarlas.

Yo coincido con esto. El tema es que el escenario real no es lo bonito
que nos gustaria que fuera.

Otro ejemplo tonto: Años atrás me habia puesto a "jugar" con opciones IP
y TCP. Fue un parto. -- En particular en el caso de IP, la mayoria de
los paquetes terminaban siendo descartados.

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


> Yo creo que preservar el "extremo a extremo" es algo importante.

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.

Vuelvo a aclarar que no es que tal situacion necesariamente me haga
feliz. Sino que simplemente intento aceptar/describir lo que veo.

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



_______________________________________________
LACTF mailing list
lactf at lac.ipv6tf.org
https://mail.lacnic.net/mailman/listinfo/lactf