steve uurtamo wrote:
when you write a protocol, regardless of the application, that tries to make requirements _in the data portion_ about how the remote side should write its _header portion_, you really are asking for trouble.
Explain how to build a protocol for the following: A -| |-Nat-<>-C B -| A wants to tell C how to contact B for a multi-party app. A 'knows' the address of B, so why should it require C to take several seconds to look it up by name? Even if C were to look up the name, it would map back to A as far as C is concerned, so C might not go into multi-party mode because it has one name and single matching locator.
NAT != evil, so let's try to be a little bit more evenhanded about this.
NAT is just a technology, so your statement is arguably true. As long as the end user has elected NAT as the tool for solving the current problem, he accepts the associated drawbacks. The evilness appears when humans get involved and NAT is forced on the end user. This could either explicitly, or (to be truly evil) unannounced by the service provider, while at the same time claiming that they are selling Internet service. (This is the point that started the original thread)
and the understanding that if there are such restrictions, it might be a little while (i.e. until all NAT implementations everywhere plug in a handler for the new protocol in question) before all networks in the world are going to be able to pass their packets around with ease and zen-like harmony. is that really so much to ask?
Actually it is. It is equivalent to insisting that my PI prefix be distributed globally. From an end user perspective there is no reason a little pain on the ISPs part should prevent me from having continuous connectivity through full prefix announcement multi-homing. Yet ISPs are fat-&-happy pointing out that developers should never require a protocol to carry locator information in the data stream. There are reasons to do it, so it is incumbent on the service providers that enforce NAT to be straight with their customers about the fact the service is not full capability transparent Internet access. Tony