John,
> You are absolutely right. Time should be spent developing "good
> algorithms" which is common "good architecture". What NAT does is just
> another form of the same thing that X.25, ATM, and MPLS do with different
> identifiers. It is not bad algorithm there nor bad architecture.
This is the second time you've said this, the first time I just
cringed.
> I would tend to agree. As I have said elsewhere, NATs in and of themselves
> do nothing wrong. They are doing things within the Internet/Network Layer
> that are perfectly legal. (In essence, they are treating the network
> address in much the same way that X.25, ATM, and MPLS treat their
> addresses.)
I find this assertion to be amazing. It's perfectly legal for a device
to modify any field in the IP header if it so desires? Do you also
agree that it's legal to modify the IP ident field (and potentially
break fragmentation?) What about the length field, or flags field,
etc., etc.??
Also, NATs have to modify the TCP/UDP checksum, i.e., look inside the
upper layer protocol it is carrying and modify the payload. This is
also not "bad architecture"?
> The problem is that applications lacking an "application address
> space" are using the Network address space inappropriately.
IMO, this is a widespread oversimplification of the situation.
If you want to point fingers, TCP is also broken from the perspective
of NAT, because transport layer addresses are formed from both IP
addresses and port numbers. It's not just applications sending
addresses in payloads that "are broken", it's a key aspect of the
basic TCP (and UDP) design.
Sure, there are folks that say "fix TCP". But this is also naive.
There is a good reason why TCP is designed this way. Having transport
addresses be completely independent of the IP address in the IP header
requires having some way of mapping from one name space (e.g., the TCP
transport identifier of a service one wants to communicate with) to
the IP address (so that the TCP header can be put into an IP packet
and sent to the actual destination).
Although folks have talked about doing something like this for years,
it has not been done (i.e., where is a document showing how it can be
done?) and folks have argued endlessly about whether building such a
system is feasible or really solves the problem as opposed to just
creating a new (hard) problem elsewhere that then needs solving.
Thomas
