Re: [tcpm] PLPMTUD for all protocols

[William Herrin <[e-mail]>]

On Thu, Mar 29, 2018 at 9:32 AM, Joe Touch <[e-mail]> wrote:
>> On Mar 28, 2018, at 8:51 AM, Mikael Abrahamsson <[e-mail]> wrote:
>> So I have no idea how to come to a best conclusion regarding the tradeoff between "doesn't work at all" and "doesn't work optimally in some cases".
>
> If making things more optimal in some cases causes some things to fail, you have chosen poorly.

Hi Joe,

Status quo is "doesn't work at all," the PMTUD black hole problem.
PMTUD is arguably a design defect in IP: one of few cases in which the
end to end principle is abandoned, requiring the intermediate router
to communicate with an endpoint or else end to end communication
fails. It's also arguable that every instance of a PMTUD black hole is
a consequence of an operator configuration error.

PLPMTUD is proposed as "doesn't work optimally in some cases." More to
the point: suffers in common packet loss scenarios. Everybody takes a
performance penalty to overcome common operator configuration errors.

Alternatives to PLPMTUD include configuring the local TCP stack's MSS
to the IPv6 minimum MTU (1280 bytes). This pretty much eliminates the
PMTUD black hole problem by eliminating the need for detection.
There's a negligible performance hit but a slightly increased
consumption of bandwidth in the normal case. I've used this on my
servers for years and the bottom line is that it works.

It's also fair to wonder why router and firewall vendors don't offer
configurations designed to mitigate the PMTUD black hole problem.
Firewall vendors could warn on attempts to block ICMP or require
explicit overrides to block ICMP destination unreachable messages.
Router vendors could offer a configuration option to issue ICMP
destination unreachables from the a configured public IP address
rather than from the interface's (sometimes private) IP address. They
don't do these things.

In principle the IETF could even designate a standard public IP
address to be used when routers that have no public IP addresses need
to issue a a fragmentation needed message. After a couple equipment
cycles the PMTUD black hole problem would presumably fall back to
1990s levels which weren't so bad.


On Wed, Mar 28, 2018 at 11:51 AM, Mikael Abrahamsson <[e-mail]> wrote:
> 1. IPv6 doesn't have a DF bit that can be on or off, it's always implicitly
> on.

Thanks Mikael, I didn't realize that.

> 2. Fragmentation doesn't usually happen if there is PMTUD blackhole.

Do we have data on this? Is it a general case issue where routers
refuse to fragment packets even if the DF bit is clear? We expect the
router to forward a small enough unfragmented packet onward. I can't
think of a reason that the PMTUD black holes and routers failing to
fragment IPv4 packets where DF is clear would be linked issues.

Regards,
Bill Herrin


-- 
William Herrin ................ [e-mail]  [e-mail]
Dirtside Systems ......... Web: <http://www.dirtside.com/>