[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The argument for writing a general purpose NAT for IPv6



Le mercredi 18 avril 2007 22:36, james woodyatt a écrit :
> I'm not limiting my discussion to just SIP.  I'm speaking of ALG's in
> the abstract sense.  If you have SPI, then you will need ALG's for
> some subset of all possible applications.  If you have ALG's then
> some subset of them will only be feasible with transport-layer
> proxies.  If you have transport layer proxies then you will need IPv6
> NAT to redirect flows into them.

> However, I suppose I should admit that the unified IPv6 global
> addressing scope means that many (if not all) ALG's will be
> unnecessary once applications are all upgraded to traverse stateful
> packet filters using STUN/ICE-like mechanisms.  In the BEHAVE group,
> the evolving discussion is convincing me that IETF expects future
> IPv6 applications to depend on the deployment of a global rendezvous
> infrastructure of some yet-to-be-specified design.

An applications that does not support hole punching à la STUN/ICE may 
need an ALG to traverse a stateful firewall. But so long as you have 
enough addresses for every hosts, there is NO NEED to NAT or otherwise 
modify the packets at all; you only need to keep automagically open 
pinholes for connections that are "related" (borrowing Linux-NetFilter 
naming hree) to some existing connections... e.g. open a hole for an 
FTP data connection if you see the need according to the FTP control 
session, or for the RTP and RTCP flows of an RTSP media.

I don't see the need for a NAT there.


IMHO, it would of course be much better for the unmanaged networks 
scenarios to not have stateful firewalls by default at all. In fact, 
restored connectivity is the only incentive for "end-user" ISPs to 
deploy IPv6 at the moment, as far as I can tell. Why would they invest 
if it brings just about nothing? In that sense, it seems to me that 
Apple Airport decision and v6ops NAP is on a collision course with 
ISPs. But I should rather let ISPs speak for themselves.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Attachment: pgp05EObLZM44.pgp
Description: PGP signature