>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.??
Cmon, surely you can come up with a better counterargument than that! ;-))
I certainly could. If it is architecturally acceptable for those protocols
to rewrite the address field at every hop, why shouldn't it be for IP? How
does it differ? Basically a NAT is doing what an ATM switch does. How does
an MPLS tag differ?
The answer of course is that MPLS tags, etc. have a much smaller scope and
rely on the layer above to provide an address of broader scope "to bind the
tags together." The problem for NATs is that IP doesn't have a name space
of broader scope "to bind the tags together."
>
>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"?
That is more questionable given the architecture that has been put forward.
If IP and TCP are supposed to be in different layers then the pseudo-header
is also bad architecture. If they aren't in different layers, then it
isn't and neither is modifying the checksum.
>
>> 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.
Only partly, But it would be a big step to solving the problem. However,
there are so many special cases now of people doing strange things with IP
addresses that they shouldn't be doing that there may not be anyway out of
the problem.
>
>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.
This can be dealt with in the NAT.
>
>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).
Not really. I recently heard Dave Clark say (and in a rare case I actually
agree with him based on my own investigations into protocol design
principles) that it would probably have been better if socket ids were part
of the IP address and there was no addressing in TCP at all.
>
>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.
>
Yes, I am aware of this. In the very early days, it was assumed that it
would have to be done. Then there was a long hiatus where the only
applications were telnet and ftp and by the time it was really needed it
would seem that reticence to change had set in and lots of people continued
to do ad hoc things that made change difficult.
I am well aware of the issues, but I did want to push back on people who
see no problem with applications exchanging IP-addresses. The longer we
keep putting this off the messier the problem gets. Frankly, I have heard
these arguments for years that to fix anything will only create problem
elsewhere and so far I have seen no examples that were not either "bad
architecture" or should be accomplished in a different way. Where the
"desired" approach was an artifact of not having the right tools to solve
the problem.
Take care,
John
