> 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
