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