From owner-freebsd-hackers Thu Jun 8 2:53: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id D45B137BB21 for ; Thu, 8 Jun 2000 02:52:58 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id TAA48192; Thu, 8 Jun 2000 19:21:36 +0930 (CST) (envelope-from newton) Date: Thu, 8 Jun 2000 19:21:36 +0930 From: Mark Newton To: Dave Preece Cc: "Kenneth D. Merry" , freebsd-hackers@FreeBSD.ORG Subject: Re: Path MTU discovery. Message-ID: <20000608192136.A48159@internode.com.au> References: <67B808B0DD93D211ABEE0000B498356B02BC71@internet.kbgroup.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <67B808B0DD93D211ABEE0000B498356B02BC71@internet.kbgroup.co.nz> X-PGP-Key: http://www.on.net/~newton/pgpkey.txt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 08, 2000 at 07:21:57PM +1200, Dave Preece wrote: > So... thinking about what this means for firewalls and natd. If we block all > incoming ICMP's across the firewall, it is quite possible that a server > behind the firewall could completely fail to send packets to a client on a > smaller MTU (modem user with MTU set to 576, for instance). Yes, that's correct -- The idea that ICMP is a separate and optional part of TCP/IP is fundamentally wrong. Blocking it unconditionally is a recipe for all kinds of hard-to-debug lossage around your firewall. Just Say No. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message