rfc 2923, suggestion "How to fix" to problem of section 2.1 (ICMP Type 3, Code 4)

Hello dear fellow networkers,

following question:
The "How to Fix" section basically suggests that host
that is placed behind mis-configured firewall (firewall
that does not forwards ICMP Type 3, Code 4 packets (i.e.
Fragmentation needed but DF set)) should behave in following
fashion:
" TCP should notice that the connection is timing out. After
several timeouts, TCP should attempt to send smaller packets,
perhaps turning off the DF flag for each packet. If this
succeeds, it should continue to turn off PMTUD for the connection
for some reasonable period of time, after which it should probe
again to try to determine if the path has changed."

As of kernel 2.4 I by myself do not see this suggestion implemented, so
two questions:
1) Is anyone aware of any patch that brings the suggested behaviour in the network
stack?
2) What is the behaviour of 2.6?


With Best Regards
Ariel Burbaickij

Ariel Burbaickij wrote:
> Hello dear fellow networkers,
>
> following question:
> The "How to Fix" section basically suggests that host
> that is placed behind mis-configured firewall (firewall
> that does not forwards ICMP Type 3, Code 4 packets (i.e.
> Fragmentation needed but DF set)) should behave in following
> fashion:
> " TCP should notice that the connection is timing out. After
> several timeouts, TCP should attempt to send smaller packets,
> perhaps turning off the DF flag for each packet. If this
> succeeds, it should continue to turn off PMTUD for the
connection
> for some reasonable period of time, after which it should probe
> again to try to determine if the path has changed."
>
> As of kernel 2.4 I by myself do not see this suggestion implemented,
so
> two questions:
> 1) Is anyone aware of any patch that brings the suggested behaviour
in the network
> stack?
> 2) What is the behaviour of 2.6?

Not aware of a "patch" that automagically turns off PMTU _and_ reduces
the transmitted segment size.

If you continue with that section you will read:
[q]
If hosts start to implement black hole detection, it may be that
these problems will go unnoticed and unfixed. This is especially
unfortunate, since detection can take several seconds each time,
and these delays could result in a significant, hidden degradation
of performance. Hosts that implement black hole detection should
probably log detected black holes, so that they can be fixed.
[eq]

Ie., the "fix" is not obvious, does not correct a misconfugured router
anyway, and still requires manual notification/correction. We do that
today by adjusting the size of ping packets, noting the PMTU, then
emailing the organization responsible for the router. Host based
solutions may, in fact, do more to obscure the presence of the problem
than to fix it.

IPv6 does not have a DF bit, this rfc is not standards track yet
(ever?), and would (IMO) do more to _lessen_ the pressure to correct
misconfigured routers rather than to "fix" their symptoms as you would
have yet another source of mixed results. I do not expect any "fix"
along these lines. It will be difficult enough getting ipv6 running as
the standard.

my2c's,
prg

"prg" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed) oups.com>...
> Ariel Burbaickij wrote:
> > Hello dear fellow networkers,
> >
> > following question:
> > The "How to Fix" section basically suggests that host
> > that is placed behind mis-configured firewall (firewall
> > that does not forwards ICMP Type 3, Code 4 packets (i.e.
> > Fragmentation needed but DF set)) should behave in following
> > fashion:
> > " TCP should notice that the connection is timing out. After
> > several timeouts, TCP should attempt to send smaller packets,
> > perhaps turning off the DF flag for each packet. If this
> > succeeds, it should continue to turn off PMTUD for the
> connection
> > for some reasonable period of time, after which it should probe
> > again to try to determine if the path has changed."
> >
> > As of kernel 2.4 I by myself do not see this suggestion implemented,
> so
> > two questions:
> > 1) Is anyone aware of any patch that brings the suggested behaviour
> in the network
> > stack?
> > 2) What is the behaviour of 2.6?
>
> Not aware of a "patch" that automagically turns off PMTU _and_ reduces
> the transmitted segment size.
>
> If you continue with that section you will read:
> [q]
> If hosts start to implement black hole detection, it may be that
> these problems will go unnoticed and unfixed. This is especially
> unfortunate, since detection can take several seconds each time,
> and these delays could result in a significant, hidden degradation
> of performance. Hosts that implement black hole detection should
> probably log detected black holes, so that they can be fixed.
> [eq]
>

> Ie., the "fix" is not obvious, does not correct a misconfugured router
> anyway, and still requires manual notification/correction.
We do that
> today by adjusting the size of ping packets, noting the PMTU, then
> emailing the organization responsible for the router. Host based
> solutions may, in fact, do more to obscure the presence of the problem
> than to fix it.
>
Well, the question is what do you want to prioritize:
Would you like to have system that in this relation
just works maybe with some penalties in perfomance
or do you want to find it and then fix it, so that
solution is truly "handmade". For practical reasons
I will opt for the first option, as you might guess.
> IPv6 does not have a DF bit, this rfc is not standards track yet
> (ever?),
It is announced as informational, so most probably not.
Once again, for sure, it falls under nice to have category,
I am fine when I am in minority on it.
and would (IMO) do more to _lessen_ the pressure to correct
> misconfigured routers rather than to "fix" their symptoms as you would
> have yet another source of mixed results. I do not expect any "fix"
> along these lines. It will be difficult enough getting ipv6 running as
> the standard.
>
> my2c's,
> prg