Date: Mon, 9 Feb 1998 09:48:11 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ipfw logs ports for fragments Message-ID: <Pine.BSF.3.95.980209094127.18733n-100000@alive.znep.com> In-Reply-To: <199802091603.OAA22008@gaia.coppe.ufrj.br>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980209094127.18733n-100000>