[LAC-TF] Aplicaciones y/o servicios solo para IPv6

[Fernando Gont]

Hola, Arturo,

On 05/18/2012 08:39 AM, Arturo Servin wrote:
>>> No es lo mismo atravesar un NAT que un FW.
>> 
>> Lo unico que cambia es que si el protocolo de aplicacion
>> transfiere direcciones IP, tenés que implementar un ALG, para
>> sobreeescribirlas. Pero el resto es muy similar.
> 
> Claro, lo "unico", pero resulta que es lo mas dificil. Y es
> precisamente donde los NAT patinan, en los ALGs.

Bueno, en lo que respecta al ALG, la cuestion, desde el punto de vista
de la aplicacion, es simple: o el NAT implementa un ALG para tu
protocolo, o el mismo no funciona ;-) -- En general, dado que uno no
controla la implementacion de ALGs, la "solucion" es no incluir
direcciones IP en el protocolo de aplicacion, y listo (de hecho, eso
nunca habria que ahberlo hecho, ya que es mal diseño).

Sin embeargo, queda todavia la cuestion referida al firewall (ya sea
porque el dispositivo *es* un firewall, o bien porque es un NAT, y como
efecto marginal actua como tal).

El problema basico es que tales dispositivos solo permiten conexiones
salientes. Y si vos queres recibir conexiones entrantes (como en una app
p2p), basicamente tenes que hacerle creer al dispositivo que la futura
conexion "entrante" es resultado de algo que vos previamente enviaste
(es decir, que no se trata de una conexion entrante, sino que en
realidad es una conexion saliente).

Y esta complejidad esta presente ya sea que en el medio haya un fw, o un
nat.


>> Sin ir mas lejos, fijate por ejemplo que una buena parte de la 
>> complejidad de tecnologias como Teredo tiene que ver con la 
>> característica de "firewall stateful" de los NAT, mas que con el
>> hecho de que las direcciones son traducidas.
> 
> Si, posiblemente, pero los trucos que tiene que hacer Teredo son por
> el NAT y resulta que el FW al hacer su trabajo no lo deja funcionar.
> Aunque las fallas finales sean de un FW, creo que el origen del
> problema es la complejidad del protocolo gracias al NAT.

la pregnta crucia es: el orginen es respecto al nat como dispositivo, o
al nat como funcionalidad? :-)

(porque el nat, como dispositivo, trae aparejado un firewall como
funcionalidad)


> Al tener IPv4 o IPv6 (con FW o sin ellos pero) sin ningun tipo de NAT
> creo que la vida de los desarrolladores de aplicaciones se facilita
> enormemente.

Personalmente creo que IPv6 es necesario para que no estemos forzados a
poner nats en todos lados, y para que que, en muchos casos, no tengamos
que incluso poner varias capas de nat.

Sin embargo, creo que buena parte de la complejidad de las aplicaciones
tiene que ver con que las app quieren/necesitan "evadir" firewalls. Es
decir, necesitan hacer trucos para poder traspasar cosas que se supone
que no deberian traspasar.



>> Si queres hacer P2P, y tenes un firewall stateful en el borde,
>> tenes que empezar a hacer "magia" para "punchear" agujeros en el
>> fw...
> 
> Magia? Ademas del estado, no solo son las reglas de salida y
> entrada?

Me refiero a que la *app* debe hacer magia (no el firewall). Por
ejemplo, si yo estoy en mi red interna, y quiero que vos te conectes
conmigo, te envio un paquete *primero* para abrir un agujero en el fw,
para que luego tu intento de conexion funcione.

Es decir, tanto para un nat como para un fw stateful que "solo permite
conexiones salientes", todo tiene que verse como que "las conexiones
fueron iniciadas desde el interior de la red", ya que sino no funciona.

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