| You are losing your network redundancy here, IMHO.

Well, I was thinking of a simple non-redundant topology
    
   host---|           |
          |           |
inside-   |---NAT-A---|  outside-DMZ-LAN           line-to-ISP
DMZ-LAN   |---NAT-B---|
          |---NAT-C---|-------------------router-------------
   host---|---NAT-D---|
   router-|           |
   ...    |           |

You can add more routers, which take care of redundancy
for the connection between the outside world and the 
"outside-DMZ-LAN" NAT/PAT/ALG addresses.

You then want to recover from, for example, NAT-A failing
and taking down all the connections passing through it.
PAT/NAT can be recovered-from, since the state is small and
sticky.  ALG conversations that have the property of having
small, sticky state can also be migrated cheaply, otherwise
alot of state-sharing needs doing.  I think it would be a 
cheaper policy just to lose whatever was being ALGed, but
remember I just don't like non-NAT-friendly protocols that
need ALGs in the first place. -:)

For NAT/PAT to survive gateway crashes, you have to have deterministic
mappings and play e.g. ARP or routing games to deal with NAT failures
in the sense of having packets not simply blackhole.

Deterministic mappings need not be statically configured; one can
lease a deterministic mapping from a DHCP-like server, for example.

Something I don't have a statically-configured mapping for arrives
on me (a gateway).  Possible pseudo-protocol conversations:  dear
DHCP server, kindly give me an outside port/address corresponding
to inside port/address X/Y.  Dear DHCP server, kindly give me an
outside address corresponding to inside address X.

If NAT-A collapses, and NAT-B gets part of a conversation it's
never had state about, it asks the DHCP-like server, which maintains
the leases.  

(Of course that begs the question of how to deal with DHCP-like
server crashes, which suggests potentially multiple DHCP-like
servers and an aggressive-or-lazy-as-you-like synchronization
between the "working" and "protect" DHCP-like servers.)

There are lots of other ways of skinning this cat, some of which
are proprietary and/or supported commercially, as someone else noted.

| 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)

A NAT/PAT crashes and thousands of connections see the DHCP-like
query-response delay as conversations migrate to the surviving
NAT/PAT gateways.

The connections that are using protocols which are NAT-unfriendly,
and whose ALGs need to have some conversational-history, simply fail.

| 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.

You may choose to have a statically configured 1:1 mapping for your
web server to allow for easy renumbering (change the outside-DMZ-LAN
numbers, and you don't have to touch the web server).  Or you can
have your web server use an outside address.  Or you can hope your
user hits the "reload button".  -:)

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

It can be done reliably or not.  Just like "NAT-free" IP connectivity.

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

Fair enough; I often elucidate views which are not mine. -:)

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

What sucks is the fact that you cannot distinguish what from where
in either IPv4 or IPv6.

But see http://www.irtf.org/charters/namespace.html
which is a better solution than either NAT etc. or IPv6.

	Sean.