Eric, I agree with most of your post but there is something that you have not grasped IMHO. It is true that "dissimulating" the private (RFC1918?) address does not achieve much in terms of security: in order to access: http://arneill-py.sacramento.ca.us/ipv6mh/ you do not need to know nor care that the IP address of the web server is 192.168.1.4. Knowing it might provide limited help way farther down the hacking process though and is likely to be leaked in things such as SMTP headers anyway. However, if you are correct in saying that NAT != firewall, you are mostly _not_ correct in saying that a NATs are not firewalls, as most NAT boxes indeed are NAT+PAT boxes and {NAT != firewall} applies to non-PAT things such as one-to-one static NAT (not overloaded) or subnet natting. Refrigerator = Frigidaire Copy machine = Xerox NAT box = Linksys > Eric Tomson wrote: > 2.circuit level gateways (work mainly at session layer, by > identifying flows of data and established connections), > A more advanced device, able to identify "conversations", > "sessions", is a bit more advanced firewall of type 2. By your own definition a NAT+PAT box is a type 2 firewall or circuit level gateway. A pure NAT device (rare) does not care about flows but a NAT+PAT box (very common) does and maintains hard state about them as show below: cisco3640#sh ip nat tr Pro Inside global Inside local Outside local Outside global udp 209.233.126.65:1060 192.168.1.4:1060 206.13.31.12:53 206.13.31.12:53 tcp 209.233.126.65:1263 192.168.1.7:1263 198.133.219.25:80 198.133.219.25:80 tcp 209.233.126.65:25 192.168.1.4:25 --- --- tcp 209.233.126.65:80 192.168.1.4:80 --- --- Linksys/Netgear/misc home/soho NAT boxes have similar mechanisms. The first two are originated-from-inside dynamic flows, the last two are statically punched holes. Note that TCP flows are torn down as soon as the TCP connection is terminated where UDP flows are torn down with a timeout; on a Cisco 'show ip nat trans verbose' will show the timeouts. This hard state is why NAT+PAT boxes have often been compared to firewalls because _one_ of the features of firewalls is to build this hard state that allows only return traffic related to traffic originated from the inside (unless a hole is punched). The security brought by the NAT+PAT process comes from this hard state; no entry in the translation table, no traffic. A firewall (or a reflective access-list for Cisco geeks) builds hard state the same way except that of course it does not change the address. > NATs [...] won't control the traffic This is incorrect for most NAT boxes. Although it is true that the main two purposes of NAT are saving IPs (one-to-many NAT) and ease renumbering, it is equally true that if there is no open flow originated from the inside (or hole punched administratively), a NAT+PAT _DOES_ by default block traffic originated from the outside, which is a significant part of why people buy firewalls in the first place: Allow users to surf but don't open anything except a few ports to a few IPs in the other direction. In other words, a NAT+PAT device blocks by default all traffic except statically punched holes and transient return traffic related to a flow opened from the inside (specific to a pair of IP addresses and a pair of ports). This circuit-level gateway feature is not enough security and must be complemented with access-lists and stateful inspection but it's one of the third major building blocks of a firewall. But that's for network geeks; the sad truth is that when the network admin is lame (grandma or Joe's Pizza) a windoze 9x PC is safer behind a Linksys than connected directly to the cable modem. As of myself I would not call a firewall any device that does not have stateful packet inspection (free hint to IPv6 vendors ;-) But by your own definition a NAT+PAT box is a firewall of type 2. Add to this that when combined with RFC1918 they bring very easy renumbering as only the outside address has to be changed and you'll understand why there are so many of them around. For the record, and since this thread started with IPv6, I am totally against IPv6 NAT. With IPv4, all we have left at this time are lemons so there's nothing wrong in making lemonade with them even if we prefer beer. Although it is part of the job, IPv4 NAT is a royal pain in the butt that I would gladly live without. But for IPv6 it is not too late. If the end-to-end principle is a dogma it's not only because IETFers like dogmas but mostly because NAT plain stinks. Michel.