I don't buy your argument at all. There's *lots* of places where internet standards prevent Linux from doing various things. Trying to prevent users from shooting themselves in the foot, or trying to be a good netizen.
If users require their computers to be broken, they can patch and build their own kernels. Indeed, the entire point of internet standards is interoperability and specifying things that must or must not be done. To quote from https://tools.ietf.org/html/rfc8201 Nodes not implementing Path MTU Discovery must use the IPv6 minimum link MTU defined in [RFC8200] as the maximum packet size. (my comment: ie. 1280) ... Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself, as it might have a PMTU lower than the link MTU. In a situation such as when a neighboring router acts as proxy [ND] for some destination, the destination can appear to be directly connected, but it is in fact more than one hop away. ... When a node receives a Packet Too Big message, it must reduce its estimate of the PMTU for the relevant path, based on the value of the MTU field in the message. ... After receiving a Packet Too Big message, a node must attempt to avoid eliciting more such messages in the near future. The node must reduce the size of the packets it is sending along the path ... Because each of these messages (and the dropped packets they respond to) consume network resources, nodes using Path MTU Discovery must detect decreases in PMTU as fast as possible. -- Furthermore, as we're finally upgrading to 4.9+ kernels, we now have customers complaining about broken ipv6 pmtud. This is a userspace visible regression in previously correct behaviour. And we do have a reason for locking the mtu with the old pre-4.9 behaviour: So we can change the mtu of the interfaces without it affecting the mtu of the routes through those interfaces.
