From owner-freebsd-hackers Mon Feb 9 08:49:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02836 for hackers-outgoing; Mon, 9 Feb 1998 08:49:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02823 for ; Mon, 9 Feb 1998 08:49:39 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id JAA27836; Mon, 9 Feb 1998 09:49:31 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id JAA26289; Mon, 9 Feb 1998 09:48:12 -0700 (MST) Date: Mon, 9 Feb 1998 09:48:11 -0700 (MST) From: Marc Slemko To: Joao Carlos Mendes Luis cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ipfw logs ports for fragments In-Reply-To: <199802091603.OAA22008@gaia.coppe.ufrj.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 9 Feb 1998, Joao Carlos Mendes Luis wrote: > I like the idea of packet reassembly at firewalling points. If it's easy, > I'd like to see a sysctl to force reassembly at ip_input.c. > > I can't remember anything in the IP protocol that would disallow reassembly > in the routers, other than performance. Could you please give examples ? It is simply a bad idea. First, you have multiple paths. Second, you need to worry about headaches with timeouts and not having bad interactions between timeouts at the receiver and timeouts at the destination. If you want a "thou shalt not" in the RFCs, cf. section 5.2.1.1 of rfc1812: (2) The router validates the IP header, as described in Section [5.2.2]. Note that IP reassembly is not done, except on IP fragments to be queued for local delivery in step (4). [...] since reassembly is performed on locally delivered packets but not on forwarded packets. One simple scheme is to associate a flag [...] 5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2 As was discussed in Section [4.2.2.7], a router MUST support IP fragmentation. A router MUST NOT reassemble any datagram before forwarding it. DISCUSSION A few people have suggested that there might be some topologies where reassembly of transit datagrams by routers might improve performance. The fact that fragments may take different paths to the destination precludes safe use of such a feature. Nothing in this section should be construed to control or limit fragmentation or reassembly performed as a link layer function by the router. Similarly, if an IP datagram is encapsulated in another IP datagram (e.g., it is tunnelled), that datagram is in turn fragmented, the fragments must be reassembled in order to forward the original datagram. This section does not preclude this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message