Hi Dino,
|Well for one, you have to do a 5-tuple lookup because most NATs have
|both ports as part of the lookup key.
Ok, but a 5-tuple lookup is not conceptually 'harder' than an address
lookup. In fact, if you simply treat the 5-tuple as a big
concatenated key,
you can easily to a tree lookup algorithm. Or, if you like, since
there's
no longest match requirement, you can do other things...
|And for two, it's usually
|another data structure that has the translation table. And typically
|in hardware implementations that is not the same DRAM. So there is an
|extra cost there.
Fair, but this hardly a big deal. For reasonably sized sites, the
translation table can be quite small. Look at the NAT table in a
Linksys
cable router today.
|Third, you have to fix the pseudo-header checksum.
Trivial, since it can be precomputed (didn't we discuss exactly this
in
2000? ;-).
|Fourth, you have to fix payload like the all important ICMP
|unreachable so traceroute works.
Again, not rocket science.
|This is all very hard to do in an ASIC. In a programmable forwarding
|engine it is simpler if you can do packet writes. But that is rarely
|the case.
Ummm.... Please take another look around at the current generation of
forwarding engines. Writes are now common.
|> Intrinsically, they seem to be roughly on the same order of
|> magnitude of
|> difficulty.
|
|Disagree. Encapsulation is prepending a header, just like you would
|when an IP router forwards a packet from one Ethernet to another
|Ethernet. Ditto for the decap side.
Ok, let's agree to disagree then.
|Very different. I have implemented both and my experience says
|translation is much harder.
Please note that I'm not talking about difficulty of
implementation. In
some real sense, that's almost irrelevant. I'm thinking of the actual
computational load to forward one packet.
Given a flexible packet processor today, could you write code to do
encapsulation, write code to do translation, optimize both, and have
the
encapsulation run 10X faster? Somehow, I'm just not seeing it.
Tony