dhc2 at dcrocker.net
Mon Oct 26 07:52:33 PDT 2009
Noel Chiappa wrote:
> For one, NATs became widespread mostly a result of flaws in the original
> engineering (too small an address space) and architecture (too few namespaces,
> leading to difficulty in supporting things like provider independence). NATs
> are not inherently desirable, and would not, I think, have
> evolved/proliferated had TCP/IP avoided those (in hindsight, now obvious)
The name "NAT" certainly justifies the claim that they were created to resolve
an issue with addressing. And given what they do to an address, they certainly
affect end-to-end behaviors.
But there is pretty strong indication that something like them would have been
needed anyhow. For example... Back when CIDR was being deployed -- and repeated
in the Tussles in Cyberspace paper -- it was observed that the way addresses are
structured locks a user into their provider. NATs fix that (if you don't have
any publicly-visible servers inside your net.) In other words, NATs have
important administrative benefits that need to be acknowledged.
The interface between an organization and the outside world needs a potentially
sophisticated boundary device, no matter how wonderful the Net's addressing
Whether the legitimate services of such a boundary device impinges on E2E
principles is a worthy discussion, but we ought to be careful not to dismiss the
topic with the usual, quick wave of the E2E flag over the limited and rotten
corpse of the address-translation-is-bad assertion.
More information about the end2end-interest