Re: [9fans] nat

[lucio@proxima.alt.za]

> perhaps you forgot to read the part where i said
> i don't think this would require anything from the
> kernel; the ip would not need modification.

OK, I read it and promptly forgot it because none of the "canonical"
implementations of NAT I am familiar with seem to be able to operate
without kernel help.  Such canonical implementations tend to hook onto
the routing code (I'm not an authority, but I used to pay a lot of
attention to these details in a previous life) and are often carefully
micro-optimised because NAT (and IP filtering) tends to be quite
resource-intensive.

Running NAT at user level would, assuming I'm not totally off base, be
quite expensive and the hardware on which it runs would have to be
pretty powerful.

To crown it all, NAT still interferes very negatively with some of the
more modern protocols (VoIP comes to mind, but I have only a
superficial understanding, so please take this with a pinch of salt)
and special arrangements have to be made to deal with the problem.

Eris raised that question for FTP, a well-known example of NAT's
shortcomings, no matter where it is shoehorned.  In my opinion, in
Unix proxies are better solutions and in Plan 9 we all know what to
look for.  For the traditional workstation configurations, there is no
easy answer.

What do you (Coraid?) use NAT for, exactly?

++L