Re: Manual PMTUD [was ...rfc2460bis-08]

[Mark Smith <[e-mail]>]

On 18 March 2017 at 12:10, Brian E Carpenter
<[e-mail]> wrote:
>> I can use
>> today SRv6 features in my data centers where I consistently know that all
>> interfaces are set for jumbo frames and where hopefully I do not need to
>> worry about MTU since hosts have much lower max MTU configured.
>
> Exactly. That's not the Internet. Internet Standards are for the Internet,
> hence I believe that the AD's decision is the correct one.
>
> (How would you feel about an extension header that MAY be deleted
> by an intermediate node, and MUST be deleted if the next hop's link
> MTU is too small? That's the sort of complexity that allowing header
> insertion would require in order to be acceptable across the Internet
> with broken PMTUD that we have. Also PTB semantics would have to change
> from "PMTU is N bytes" to "Packet exceeded link MTU by X bytes", since
> the source has no idea how much has been added by intermediate systems.
> Or perhaps the intermediate systems would have to send back a new
> ICMPv6 message saying "I extended your packet by Y bytes." This is
> not straightforward.)


And that may not work anyway, because some security people believe all
ICMP is evil.

The Linux kernel has had an implementation of PLPMTUD since 2006, so
it is now literally in billions of devices, however it is switched off
by default. I've commonly switched it on over the years* and never
encountered a noticeable issue when I have (i.e., I've never had an
issue that has made me suspect a PMTUD problem and caused me to
investigate, and I've always been on a dumbell MTU PPPoE setup since
getting broadband 15 years ago.)

Would a BCP saying to implement it or enable it if already be
implemented in hosts be a better approach to encourage its adoption,
rather than just continuing to accept the status quo of hosts that
can't perform PMTUD successfully because of broken networks?

Regards,
Mark.


*
# net.ipv4.tcp_mtu_probing sysctl
#tcp_mtu_probing - INTEGER
# Controls TCP Packetization-Layer Path MTU Discovery.  Takes three
# values:
#  0 - Disabled
#  1 - Disabled by default, enabled when an ICMP black hole detected
#  2 - Always enabled, use initial MSS of tcp_base_mss.