| The "Cisco CSS 11xxx" family claims to support wire-speed NAT, but again
| it appears to be for NAT not PAT. (e.g. speeding up server farms or
| cache clusters)

NAT, PAT and ALG are easily distributed across multiple computer/gateway
systems.

| The big problem with dynamic NAT at wire-speed is the fact that the flow
| needs to pass through the same switch _both_ directions or it will not
| work.  

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

| Application fixup just can't be done at wire-speed unless you build ASICs
| that support the specific application.

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

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.

| The point Feico was making is that many ISPs are not going to want to
| make these kind of sacrifices when they could push for IPv6 support.

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

	Sean.