Re: RFC 8201 Packet Too Big Processing

On Mon, Apr 20, 2020 at 10:14 AM Timothy Winters <tim@qacafe.com> wrote:
>
> 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.
>
Timothy,

Yes, Linux does not check the MTU value in the PTB message, it sets
PMTU to the maximum of 1280 and the received value. I'll propose a fix
on netdev list shortly.

Tom

> ~Tim
>
> On Mon, Apr 20, 2020 at 12:35 PM Bob Hinden <bob.hinden@gmail.com> 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 <tim@qacafe.com> 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 <ek.ietf@gmail.com> 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 <tjcarlin@iol.unh.edu> wrote:
>> > On Fri, Apr 10, 2020 at 2:33 PM Timothy Carlin <tjcarlin@iol.unh.edu> wrote:
>> > On Fri, Apr 10, 2020 at 2:20 PM Fernando Gont <fgont@si6networks.com> wrote:
>> > On 10/4/20 14:36, Timothy Carlin wrote:
>> > > On Fri, Apr 10, 2020 at 1:27 PM Fernando Gont <fgont@si6networks.com
>> > > <mailto:fgont@si6networks.com>> wrote:
>> > >
>> > >     On 10/4/20 14:19, Timothy Carlin wrote:
>> > >      > Hi Fernando,
>> > >      >
>> > >      > On Fri, Apr 10, 2020 at 1:14 PM Fernando Gont
>> > >     <fgont@si6networks.com <mailto:fgont@si6networks.com>
>> > >      > <mailto:fgont@si6networks.com <mailto:fgont@si6networks.com>>> 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
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------