From: Fred Baker [mailto:fred(_at_)cisco(_dot_)com]
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad
thing so lets
get rid of NAT rather than trying to make NAT work.
...
The only protocol which really cares about the source and
destination
IP addresses is IPSEC and we have discovered that is a design error.
I guess you haven't been around the applications that have
trouble with this very much.
As I explained to you in private, you missed the point here. My statement was
carefully chosen and the language very precise. You missed it.
IPSEC is as far as I am aware the only application where the actual value of
the sending and receiving address is critical. This is because they are
cryptographically signed with a MAC address.
No other protocol has this specific dependency.
Any client-server application
works fine across a NAT, as long as it is the client that
initiates the connection.
This fits into a category I call 'not making NAT work properly' which is a
separate case.
We could make NAT work effectively but to do so would require us to change the
way we look at network administration. We would have to move away from the
model of well known ports and start using the DNS as the exclusive mechanism
for service discovery.
If I start a Webcam on my box it would have to send a message to my NAT box to
say 'I am offering WebCam service on this address and port' the NAT box would
in turn have to assign an external port for the service and advertise this on
the external DNS.
Yes we can make these things work, but it does take a determination to do so.
IPSEC is the one protocol that would still stick out. But even that is fixable
if you introduce an additional field that the sender fills with a static nonce
value that is invariant for the connection.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf