Re: [tcpm] PLPMTUD for all protocols

[William Herrin <[e-mail]>]

On Thu, Mar 29, 2018 at 1:49 PM, Toerless Eckert <[e-mail]> wrote:
> So, whats the summary ?

Howdy,

My thoughts run this direction:

1. Recommend that router implementations "SHOULD" provide the option
to generate ICMPv4 type 3 code 4 (fragmentation needed) messages and
ICMPv6 type 2 (packet too big) messages from an address different than
the source interface address. They Dan't today, creating lots of cases
where the operator has to sacrifice PMTUD.

2. Recommend that firewall implementations "SHOULD NOT" filter ICMPv4
type 3 code 4 (fragmentation needed) messages or ICMPv6 type 2 (packet
too big) messages unless explicitly configured to do so. In other
words, the instruction to filter all ICMP will not result in dropping
fragmentation needed messages but the explicit instruction to drop
fragmentation needed messages specifically will. Today's firewall
tools make it too easy to accidentally kill PMTUD.

Let's maximize the chance of PMTUD working as designed and then build
something optimized for the residual cases where it still doesn't.

> Write rfc4821bis with recommendations for an additional,
> simplified procedure dropping to 1280/576 and use most simple upspeeding
> option ?

That is #3. And I'd like to be smart about fallback at the expense of
efficiency in the black hole case. Send the 1280 packet. If it works,
send another full size packet to confirm it still fails before
accepting 1280 as the path mtu. If the 1280 and 576 packets don't work
either, don't try the fallback again: it's not path mtu. Maybe the RFC
is already smart about this; I didn't read closely enough.

4. Go back to the ground truths and reconsider whether we have
satisfactory information at layer 3 to make reliable decisions about
path mtu. Because of the fate sharing issue, I think PMTUD wants to be
a layer 4 problem implemented independently in each layer 4 protocol
with layer 3 offering hints from ICMP when available. Maybe this is
something that should be kicked over to the IRTF for investigation.

Regards,
Bill Herrin


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