Date: 19 Aug 1996 16:50:55 -0700 From: Paul Traina <pst@jnx.com> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: hackers@freebsd.org Subject: Re: ipfw/ipfilter - what will it be? Message-ID: <7yrap36ihs.fsf@red.jnx.com> In-Reply-To: avalon@coombs.anu.edu.au's message of 17 Aug 96 05:20:20 GMT References: <199608170520.WAA17184@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
avalon@coombs.anu.edu.au (Darren Reed) writes: > Reading Linux's IP source code, you can see some of the flunky things > they've done (reassembling all packets going through the box on a routing > box, assuming all TCP/IP packets are destined for the host - regardless of > IP#). Flunky features are easy to add if that becomes the priority. The reason for that bit of cruft was to insure that you have enough context to do NAT reasonably. It could be avoided if they would simply store all fragments locally until they have a complete packet (look at ip->ip_id + source & destination) and then perform identical functions on each fragment, however, it does nothing to solve the OTHER part of nat, which is in-stream data modification and/or sniffing (e.g. the PORT commands in the FTP control stream). So, even though the idea was utterly gross and disgusting, it truely simplifies the entire NAT process, so I am not against it. Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7yrap36ihs.fsf>