RFC 8201 Packet Too Big Processing

Timothy Carlin <tjcarlin@iol.unh.edu> Fri, 10 April 2020 17:07 UTC

Return-Path: <tjcarlin@iol.unh.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDFE3A09A9 for <ipv6@ietfa.amsl.com>; Fri, 10 Apr 2020 10:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bydhmgBj3j5O for <ipv6@ietfa.amsl.com>; Fri, 10 Apr 2020 10:07:45 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F903A09A3 for <6man@ietf.org>; Fri, 10 Apr 2020 10:07:45 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id r26so3342135wmh.0 for <6man@ietf.org>; Fri, 10 Apr 2020 10:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=sIBw+Sz40CbgEfB4J6n3/lGpO3ZPSNyBRD397RzSj2Q=; b=P0m8M01zGhjkXbZGusUi7DSJDqQ/ztFO46GmKnEExLA4lNVL52F/NmevChtW5vBuSu LtMiVp446eXuX3anguH3tnRCM8rALR5hNQJg7EtVHSEPrEEPQt3udqsJZfJmbETnFU/L tWLE2A/dxDpRkhMvMBKlwiidTY3/wZG6nZAAQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sIBw+Sz40CbgEfB4J6n3/lGpO3ZPSNyBRD397RzSj2Q=; b=SmZ41LcTvHtqEiQ8cUvapt71A0Aj/m0A4YzjFWHkPrqsIcKhMH3ZNyLTZaoluicQd6 ztt1G5qEGT7lFk0QJnpNA3N1GhVbA+D5C0kqgnITGDMVJyb9gAriLMUSQv5ukOfHek3A IaQDhBkG48ioLK6J7jThIihxSnfw4JVkgTryrbILEmqrBij+35Jk9L77bfkAa1oDrXAb sKYy/Yi49a+4y0udiwqIfUHUufdIWX/gbD87yfUkIr24xvqpmoPIn1/LdqI3Q5VVlaZ+ geG9a275UdBBslJ8qgrT+II4E40K+ZeH7JR6eAd0A52UIJO6fTNUK32QaFTTu6q9TQoj amHQ==
X-Gm-Message-State: AGi0PuaFqzY6H+QDyHzivWbYUPgFk4A9y3X1zg3dgeiUWEfqDSFVk2Fk DyIZv2CBCWKsXPnZ16TBeEZ+Vu8BXM6Xfi2AqFMi3xjEpWs=
X-Google-Smtp-Source: APiQypIbl15Hc+G/1gk9AHaWHZ90zSfXcu+7//Zd2oejorswI6vjFEGmjgcSa/+7hQDrakTuE5wvd4YhwhMOurPMbEA=
X-Received: by 2002:a1c:96cf:: with SMTP id y198mr5969930wmd.186.1586538462927; Fri, 10 Apr 2020 10:07:42 -0700 (PDT)
MIME-Version: 1.0
From: Timothy Carlin <tjcarlin@iol.unh.edu>
Date: Fri, 10 Apr 2020 13:07:06 -0400
Message-ID: <CAB-aFv8wVjcXB73wLrBupbq3XLdmdMWE9i-8+TwHfYQE6V52_w@mail.gmail.com>
Subject: RFC 8201 Packet Too Big Processing
To: 6man@ietf.org
Content-Type: multipart/alternative; boundary="00000000000081788b05a2f2c5c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/j_cUFqd5nBIHE3ajPtrpGQxWMq8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 17:07:47 -0000

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.

Best Regards,
Tim Carlin
UNH-IOL