> From: Fred Baker [mailto:fred@xxxxxxxxx] > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf