Re: RFC 8201 Packet Too Big Processing

[Timothy Winters <[e-mail]>]

Hi Bob,

Thanks for the clarity, I couldn't find that line earlier.  I think this
means that Linux is currently not following this line and processing the
PTB.

~Tim

On Mon, Apr 20, 2020 at 12:35 PM Bob Hinden <[e-mail]> wrote:

> Tim,
>
> RFC8201 is very clear on this, from Section 4:
>
>    If a node receives a Packet Too Big message reporting a next-hop MTU
>    that is less than the IPv6 minimum link MTU, it must discard it.  A
>    node must not reduce its estimate of the Path MTU below the IPv6
>    minimum link MTU on receipt of a Packet Too Big message.
>
> Bob
>
>
>
> > On Apr 20, 2020, at 9:10 AM, Timothy Winters <[e-mail]> wrote:
> >
> > Hi Erik,
> >
> > So I think the confusion comes from this line in 8021.
> >
> > "The recommendation in the previous bullet ensures that there are
> >       no longer any valid reasons for ICMPv6 PTB error messages
> >       reporting an MTU value smaller than the minimum IPv6 MTU
> >       (1280 bytes).  IPv6 nodes should therefore be updated to ignore
> >       ICMPv6 PTB error messages reporting an MTU smaller than 1280 bytes
> >       as invalid."
> >
> > So devices should ignore ICMPv6 PTB if smaller then 1280 based on this
> reading.
> >
> > ~Tim
> >
> > On Sat, Apr 18, 2020 at 7:38 PM Erik Kline <[e-mail]> wrote:
> > If the host downgrades the path mtu to 1280 (and no lower), that seems
> fine to me.
> > 8201 section 3:
> >
> > """
> >    Alternatively, the node may elect to end the discovery process by
> >    ceasing to send packets larger than the IPv6 minimum link MTU.
> > """
> >
> > And later on:
> >
> > """
> >    The node then uses the value in the MTU field in the Packet Too Big
> >    message as a tentative PMTU value or the IPv6 minimum link MTU if
> >    that is larger, and compares the tentative PMTU to the existing PMTU.
> > """
> >
> > I think the "it" that is to be discarded is likely not clear.  If a node
> discards the whole packet then no new MTU information can be learned.
> Rather, the "it" is the MTU value in the PTB and discarding /that/ and
> using IPv6 MTU instead seems perfectly reasonable to me and allowed by the
> text..
> >
> > On Fri, Apr 10, 2020 at 1:17 PM Timothy Carlin <[e-mail]>
> wrote:
> > On Fri, Apr 10, 2020 at 2:33 PM Timothy Carlin <[e-mail]>
> wrote:
> > On Fri, Apr 10, 2020 at 2:20 PM Fernando Gont <[e-mail]>
> wrote:
> > On 10/4/20 14:36, Timothy Carlin wrote:
> > > On Fri, Apr 10, 2020 at 1:27 PM Fernando Gont <[e-mail]
> > > <mailto:[e-mail]>> wrote:
> > >
> > >     On 10/4/20 14:19, Timothy Carlin wrote:
> > >      > Hi Fernando,
> > >      >
> > >      > On Fri, Apr 10, 2020 at 1:14 PM Fernando Gont
> > >     <[e-mail] <mailto:[e-mail]>
> > >      > <mailto:[e-mail] <mailto:[e-mail]>>>
> wrote:
> > >      >
> > >      >     Hello, Tim,
> > >      >
> > >      >     On 10/4/20 14:07, Timothy Carlin wrote:
> > >      >      > Hello,
> > >      >      >
> > >      >      > We've noticed during testing for RFC 8200 and 8201 that,
> > >     for packets
> > >      >      > larger than 1280, the Linux kernel is processing invalid
> > >     Packet
> > >      >     Too Big
> > >      >      > messages that indicate an MTU less than 1280, and
> subsequently
> > >      >      > fragmenting packets to a size of 1280. We've seen this
> > >     with 4.15
> > >      >     and 4.18.
> > >      >      >
> > >      >      > This is from Section 4 of RFC 8201:
> > >      >      >
> > >      >      >  >   If a node receives a Packet Too Big message
> reporting a
> > >      >     next-hop MTU
> > >      >      >  >   that is less than the IPv6 minimum link MTU, it must
> > >     discard it.
> > >      >      >
> > >      >      > Have others noticed this issue with Linux or other
> OSes?  I'll
> > >      >     also note
> > >      >      > that it correctly does not generate an atomic fragment
> if the
> > >      >     packet is
> > >      >      > less than 1280 bytes....
> > >      >
> > >      >     I'm trying to understand the scenario...
> > >      >
> > >      >     Host sends a packet of size > 1280
> > >      >     It receives an ICMPv6 PTB < 1280
> > >      >     And it retransmit the packet as a fragmented packet, where
> > >     none of the
> > >      >     fragments is larger than 1280 bytes?
> > >      >
> > >      >
> > >      > This is correct.  Since the ICMPv6 PTB < 1280, and invalid, we
> would
> > >      > expect the PTB to be discarded, and subsequent packets (for that
> > >      > destination) to remain unfragmented.
> > >
> > >     Agreed. Unless I'm missing something, there's no point in doing
> that
> > >     (at
> > >     the end of the day, if the offending MTU was < 1280, fragmenting
> > >     packets
> > >     at 1280 will be of no use).
> > >
> > >     Can you provide the exact kernel version, so I may try to take a
> > >     look at
> > >     the kernel code and figure out what's going on?
> > >
> > >
> > > 4.15.0-96-generic and 4.18.0-147 both seem to have this issue.
> >
> > Have you tried with newer kernels? e.g., I'm running 5.3.0-42-generic
> here.
> >
> >  I have not.  These were from two relatively new distributions, but
> apparently are lagging on the kernel version.  I'll try something newer.
> >
> > Indications are that this remains broken as of 5.3.0-050300-generic.
> Let me know if you want me to try another version.
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>