ietf
[Top] [All Lists]

Re: arguments against NAT?

2003-12-02 10:17:25
Zefram,

Our take on why NATs are bad is at:
http://dsonline.computer.org/0207/departments/wp4icon.htm

And our method for undoing what a NAT does, called "TetherNet" is at:
http://www.isi.edu/tethernet and paper about it is at: http://www.isi.edu/touch/pubs/discex03-tethernet/
(Contact me if you want to try one out.)

It's been difficult to understand how the IETF has for several years worked to develop "NAT standards" - notably since NATs themselves break what few standards the Internet has (RFCs 1122 & 1123 - aka STD-3 and RFC 1812 - aka STD-4). As I've said in many WGs, NAT standards are 'laws for the lawless'.

As others have observed, this is hardly community consensus, however.

Joe

Zefram wrote:

A new sysadmin has recently joined the company where I work (I am a
software engineer and part-time sysadmin).  As he's the only full-time
sysadmin here, the network now falls under his purview.  Today he
showed me his plans for reorganisation of the network, and they involve
introducing NAT on a big scale.  His main arguments in favour of NAT
are security (which I debunked), address shortage (which we don't have),
and administrative convenience (which he never explained enough for me
to see).

I've argued strongly against NAT, but he's one of those people who seem
to be willing to accept arbitrary amounts of pain ("we don't need to
use [protocols that put IP addresses in payload]", "timeouts aren't
a problem").  I'm now pointing him at some relevant RFCs.  My question
for the list is is there a web page or other document anywhere that
comprehensively states the case against NAT?

-zefram

_______________________________________________
This message was passed through 
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which is a sublist 
of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed. Decisions on 
what to pass are made solely by IETF_CENSORED ML Administrator 
(ietf_admin(_at_)ngnet(_dot_)it).




<Prev in Thread] Current Thread [Next in Thread>