Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space

[Jack Bates <jbates () brightok net>]

Ricky Beam wrote:
> On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <stephen () sprunk org> 
> wrote:
> > Non-NAT firewalls do have some appeal, because they don't need to mangle
> > the packets, just passively observe them and open pinholes when
> > appropriate.
>
> This is exactly the same with NAT and non-NAT -- making any anti-NAT 
> arguments null.

Actually, it's worlds different.

> In the case of a stateful firewalling ("non-NAT"), the "helper" has to 
> understand the protocol to know what traffic to allow.

This is not completely true. Technologies such as uPNP can quickly open 
up a pinhole for traffic which needs to be initiated from the far end, 
but no address rewriting is necessary by the software (embedded in the 
protocol) or the firewall. For non-UDP/TCP packets, ports have no 
meaning, which is the biggest failing of NAT (since we are talking about 
overloading on one IP here, and not 1 to 1 translations). Firewall rules 
for packets that are not UDP/TCP usually allow the return traffic based 
on source and destination IP and IP protocol number. NAT, on the other 
hand can't do it. We have to make udp/tcp tunnels to carry the traffic 
through NAT instead.

> Subtle difference, but in the end, the same thing... if your gateway 
> doesn't know what you are doing, odds are it will interfere with it.  In 
> all cases, end-to-end transparency doesn't exist. (as has been the case 
> for well over a decade.)

End-to-end addressing does exist, though. There are cases that are 
straight forward that NAT breaks without adding extra tunneling layers, 
or without either NAT or the software having to rewrite an embedded IP 
address in a packet to the public address. Sure, stateful firewalls can 
still block traffic and break certain scenarios without the assistance 
of uPNP(or application layer analysis). They will be simpler, and break 
less (we'd hope simpler means less). It's one thing to communicate with 
your firewall to dynamically open up ports for your address. It's 
another to start rewriting packets, analyzing specific protocols so that 
you can alter them.

Feel free to disagree with me on all except non-TCP/UDP breakage. I've 
had too many support calls on that one, and NAT-T isn't always 
available, and even when available, it's not necessarily configurable.


Jack