Sean Doran writes:
> 
> NAT, PAT and ALG are easily distributed across multiple computer/gateway
> systems.

"easily" is relative I guess. :-)

> No, there is a single "outside" address for a conversation which
> corresponds to an interface on a NAT/PAT/ALG system; the "outside"
> world drops the traffic directly onto the NAT.  Likewise, there
> can be a single "inside" address for a conversation.   Thus, 
> there is no asymmetry, because effectively the NAT/PAT/ALG gateway 
> is at least the src or dst of the IP header on the "outside".

This is what I just said, you just said it better.  Looking at a single
flow, it _must_ traverse the same NAT device both directions or it
doesn't work.  This is what it will do automatically by virtue of the
specific global and inside addresses.  This provides a nice SPOF for
the network (for this flow, as you mentioned below) removing any
ability to converge on an alternate path. (e.g. connection reset)

> | This can be eliminated by having the switches share the state of
> | these flows.  (which I believe is done by Cisco's MLS)
> 
> This is only necessary if the conversation moves, such as
> when a  NAT crashes.

The problem.

> It is easy to distribute the NAT/PAT/ALG tasks over multiple computer/gateway
> systems.

You are losing your network redundancy here, IMHO.
Imagine the difference, NAT crashes and _thousands_ of connections are
dropped/closed/reset.  A router crashes and a few packets may be lost, but
after the network converges (< 10 seconds with HSRP) routing continues with
no dropped/closed/reset connections. (typically)

> As a trivial example of just one way of doing this, you attract
> outbound traffic for 128.1/16 to NAT/PAT/ALG gateway A and outbound
> traffic for 128.2/16 to NAT/PAT/ALG gateway B.   128.1/16 and 128.2/16
> will see different ranges of addresses for conversations originated
> by the same "inside" host.   Likewise can use DNS A RR selection to 
> direct conversations originating from "outside" to foo.bar.com
> to the outside address of either gateway A or gateway B.

Which loses as I described above.  If 'B' fails I lose a big chunk of
connections and 'A' has to know this so it can start attracting outbound
traffic for '128.2/16' also.  So you need a failover protocol. (like HSRP)
Everything fails over to 'A', then 'B' comes back.  Since the inside
machine "thinks" it is talking to an address in '128.2/16' it starts sending
packets via 'B' again.  Gee, just lost my connection _again_, what the
heck are those network guys doing?

Same problem on inbound, except perhaps the person on the outside is 
trying to access my web servers and decides to just visit my competition.

Sure you can make NAT work (mostly) but are you really building a reliable
network?  I don't really think so.

> IPv6 demands other sacrifices, and the cost-benefit analysis is
> anisotropic.  That is to say, not everyone agrees with you.
> 
> 	Sean.

I was attempting (poorly) to help clarify someone else's point.  It is
not necessarily my opinion. :-)

I do tend to believe NAT (and friends) are evil.  I also tend to think
Windows is evil.  I use both NAT and Windows at work everyday so I
can't say too much.  I also use NetBSD and global addresses everyday, and
definitely prefer them.

Imagine the boss says, "I do not want an equipment failure in the [not access
layer] network to affect anybody. We have hundreds of customers that expect
a 99.9% uptime!"

You think: "Gee, I'll need 1000 NAT boxes so that a single failure should only
affect 0.1% of the connections.  I need a bigger computer room."

And then: "Wait, it only takes 15 seconds to failover to another NAT box, so
at 99.9% uptime I can have 2100 outages a year without a problem, I just
get two boxes and even if people lose their connections 5-6 times a day we
are still well within our 99.9% uptime!  Our customers will love us!"

NAT sucks, but hey you work with what you have. :)


-Andrew