Re: Never fragment: getting PMTU info transmitted reliably

["C. M. Heard" <[e-mail]>]

On Thu, 17 Jan 2019 07:12:09 -0800 Tom Herbert wrote:

> Using flow label or transport layer information is only best effort for
> persistence. Intermediate devices are allowed to change devices flow
> labels, NAT evictions of UDP may change the client side ports and address
> mid-flow.
>
>
It would be more accurate to say that there is no means to prevent
intermediate
devices from making unauthorized changes to the flow label. This is what
RFC 6437 Section 2 <https://tools.ietf.org/html/rfc6437#section-2> says:

   Once set to a non-zero value, the Flow Label is expected to be
   delivered unchanged to the destination node(s).  A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons as described in
   Section 6.1 <https://tools.ietf.org/html/rfc6437#section-6.1>.

   There is no way to verify whether a flow label has been modified en
   route or whether it belongs to a uniform distribution.  Therefore, no
   Internet-wide mechanism can depend mathematically on unmodified and
   uniformly distributed flow labels; they have a "best effort" quality.


A more fundamental obstacle is that end systems that set the flow label
sometimes do not set it correctly, rendering it unusable for its intended
purpose. See, for example,
https://mailarchive.ietf.org/arch/msg/opsec/PIJgzLPmlJ-X2x6q1L6P7zzF7qI.

Taking the long view, it is not unreasonable to expect that it would take a
decade or more to get a mechanism like this to work in the open Internet,
if the experience with EDNS(0) is any indication. The same can be said for
the change to Hop-by-Hop Options processing requirements introduced by
RFC 8200. I say leave the flow label alone and give it a chance to work,
and at the same time, support specifications such as
https://tools.ietf.org/html/draft-hinden-6man-mtu-option
and give them a chance to work.

Mike Heard