Date: Thu, 20 Dec 2001 01:59:38 -0700 (MST) From: "Forrest W. Christian" <forrestc@imach.com> To: Krzysztof Adamski <kadamski@netsurf.net> Cc: Jim Flowers <jflowers@ezo.net>, portmaster-users@portmasters.com, freebsd-isp@FreeBSD.ORG Subject: Re: (PM) Infrastructure Design with Portmasters and FreeBSD/Zebra (long) Message-ID: <Pine.BSF.4.21.0112200141350.21127-100000@workhorse.iMach.com> In-Reply-To: <Pine.LNX.4.21.0112192326030.14020-100000@white.netsurf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Dec 2001, Krzysztof Adamski wrote: > > Internet sourced ICMP messages should be routed over the RFC1918 network > > correctly - er, right? :-) Shouldn't this work equally well for the PM3 > > dialups (who all have public addresses) as long as their host/router > > supports pathMTU discovery? > > Exactly. Except with the PM3, if the customers MTU is smaller then 1500, > and a large packet comes, the PM3 will have to fragment it, but if it > can't then the PM3 will send the `ICMP can't fragment' with the PM3s IP > address. Which would be a RFC1918 address in some cases, depending on where the original "can't fragment" packet came from. Let's say a dial user with a low (say 576) mtu is trying to reach a web site on the internet which both has to pass through a network which filters 1918 space (very common), and supports MTU path discovery (also quite common). User connects to web site, web site starts mtu path discovery. To oversimplify, web server sends different sized packets to user with the DF flag set. When they reach the PM3, the pm realizes that it can't send the packet on, and sends back an ICMP can't fragment packet to the web site. If this packet originates from a 1918 address (which would be the case if the PM3's ethernet port is a 1918 address), it will never reach the web site server, as it will be dropped by the filtering isp's filter. Again, to oversimplify, this will screw things up immensely. The most common symptom is small and/or interactive things get through but big things wont. See http://www.worldgate.com/~marcs/mtu/ for another discription of the problem. Filtering ICMP packets in general (not saying don't filter ping packets) will do the same thing. There are some cases where this won't break things. If either endpoint of the flow has a lower mtu than any hop of the path, things will work good. Also, if you can guarantee that the router will either never generate the ICMP from a 1918 address OR if the router will never generate a icmp can't fragment, then things will work. However, if these end up (even unintentially) being not the case, things will break - and not in an intuitive fashon. - Forrest W. Christian (forrestc@imach.com) AC7DE ---------------------------------------------------------------------- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/ Helena, MT 59604 Home of PacketFlux Technogies and BackupDNS.com (406)-442-6648 ---------------------------------------------------------------------- Protect your personal freedoms - visit http://www.lp.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" 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.4.21.0112200141350.21127-100000>