From owner-freebsd-hackers  Mon Aug 19 16:52:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA28209
          for hackers-outgoing; Mon, 19 Aug 1996 16:52:39 -0700 (PDT)
Received: from red.jnx.com (ppp-206-170-2-24.sntc01.pacbell.net [206.170.2.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA28202
          for <hackers@freebsd.org>; Mon, 19 Aug 1996 16:52:37 -0700 (PDT)
Received: (from pst@localhost) by red.jnx.com (8.7.5/8.7.3) id QAA23703; Mon, 19 Aug 1996 16:50:55 -0700 (PDT)
To: avalon@coombs.anu.edu.au (Darren Reed)
cc: hackers@freebsd.org
Subject: Re: ipfw/ipfilter - what will it be?
References: <199608170520.WAA17184@freefall.freebsd.org>
From: Paul Traina <pst@jnx.com>
Date: 19 Aug 1996 16:50:55 -0700
In-Reply-To: avalon@coombs.anu.edu.au's message of 17 Aug 96 05:20:20 GMT
Message-ID: <7yrap36ihs.fsf@red.jnx.com>
Lines: 19
X-Mailer: Gnus v5.2.25/XEmacs 19.14
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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