Re: IP fragmentation problem in the 2.0 kernels ?

Teunis Peters (
Tue, 9 Sep 1997 17:24:17 -0600 (MDT)

On Tue, 9 Sep 1997, Keith Owens wrote:

> On Mon, 8 Sep 1997 13:38:02 -0400 (EDT),
> Michel LESPINASSE <> wrote:
> >- The kernel is getting some big tcp packets from one of these web sites,
> >and he must fragment it because of the MTU option
> >- The kernel thus sends an ICMP packet to the web server, with the
> >information about the desired MTU. Most servers correctly change their
> >MTU, but some like excite dont, because they dont even get the ICMP in the
> >first place (it gets blocked by their router) - BTW is it an rfc compliant
> >behaviour when u dont lower your MTU on an ICMP fragmentation notice ?
> Their action violates RFC 1191. Section 5 (hosts) says things like
> "When a host receives a Datagram Too Big message, it MUST reduce its
> estimate of the PMTU for the relevant path"
> and
> "Hosts using PMTU Discovery MUST detect decreases in Path MTU as fast
> as possible."

I _HAD_ to respond to this (prolly response #bignum)

Ergo - all webservers behind firewalls (to make webservers more secure)
are a violation of RFC 1191 - unless they're running behind an
invisible-masquerade I'd hope? (I don't actually know how Linux's
invisible masquerade handles ICMP forwarding).

FWIW - Firewalls (except Linux when configured) don't allow ICMP packets

He was talking about exactly this case....

> >- The kernel still fucks up and isnt able to fragment the received IP
> >datagram and send all of the fragments to the ppp host - I think IP
> >fragmentation is a must-have for a router ?
> Not the kernel's fault. The packet is marked "do not fragment" so that
> is exactly what the kernel does. Also from RFC 1191
> "When a router is unable to forward a datagram because it exceeds the
> MTU of the next-hop network and its Don't Fragment bit is set, the
> router is required to return an ICMP Destination Unreachable message
> to the source of the datagram, with the Code indicating
> "fragmentation needed and DF set".

What if the kernel never sees the ICMP response?
What if the webserver never sees the ICMP request?

ICMP tends to disappear behind firewalls (to reiterate) - and it's not
likely firewalls are going to disappear anytime soon.

> >Here is what i think *should* happen :
> >- The kernel sends an ICMP fragmentation notify to the sender, bun only
> >once in a while
> >- The packets still go thru, they just get fragmented in the process.
> This would make Linux violate RFC 1191, not a good idea. The fault is
> the sending sites trying to do path MTU discovery but blocking the
> return ICMP packets. Complain to the web sites, don't change the
> kernel. Their incorrect action will affect many users behind low MTU
> links.

Welcome to the real world - the nonstandard one <sigh>.
There should be a way to handle fragmentation requests with firewalls....

There a newer RFC than 1159 for this?
Any solution?

>From this discussion it doesn't sound like one that would pass

And about the only thing that would save face for the ICMP
resize/webserver situation is for the servers to go to Linux. Even though
that would be a nice thing to happen <G> it's prolly not all that likely
at the moment....

Anyone know how IPv6 handles masquerade/forward/et al?
(RFC's?) - I've only read up to 1850 (roughly)

G'day, eh?
- Teunis

... trying to setup a webserver behind an IP masquerade box and wishing it
were easy :) [the IP masquerade is 486-DLC33/8M ram with 2.0.30pre7 - not
yet proxy-enabled AFAIK]