Re: RFC 8201 Packet Too Big Processing

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
> --------------------------------------------------------------------
>