Re: IPv6 payload length check?

Gyan Mishra <> Mon, 10 February 2020 05:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A315120091 for <>; Sun, 9 Feb 2020 21:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mttm4LAHoUKP for <>; Sun, 9 Feb 2020 21:18:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47659120020 for <>; Sun, 9 Feb 2020 21:18:00 -0800 (PST)
Received: by with SMTP id h8so6181594iob.2 for <>; Sun, 09 Feb 2020 21:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z4zXhmWr3RBCodf+2sBNsUsKkNBi8462IcV5p+VMk9g=; b=Cf7kp0IuDiO6sntUcVLXtOFPNyNewcB7/1sC+xYQ2I6FG9DaCGx3vbVpiuK4Plr87N 59NeZK5SLTZesnSAIbm+E0jAC0Ww9YueepG8QRcn0G522g9YpVlVI5y7W5EQ2dgjD2Wn usM4zzWSzGexkMKNrLuZ+FaDt/8MrPNMxiX0FA0oEZnUQz4I79hdYxaBOWAcFmVhFdI7 bAh+gf7yrG5wHXBni3JX9CAMFyen8s534R4HIyk1Y0ybzFdgR5ZNuJpXrgot5sLZQDlI C9ZZEgY4yb6XrT1VWuyX3wCfgqKzo/OfZYfykJg8tn7rGmv3CK40GY4IkLmGjiXIpfgp FEnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z4zXhmWr3RBCodf+2sBNsUsKkNBi8462IcV5p+VMk9g=; b=N6mnqkXcNr1yQ5+CLKQ7ZfGEVx5B61OaOd7oN4CyfCzdVzNrrxQtmJjCqkc94hHg3p FvmH7GiT9s9xszxCho4KUCOuon/NpUBAI6gafaE+qysOd2jtaOWFChsX2VZpn9wezJm/ wUJ2p86Hyk79QnP/y2L1r9xdCAStWQUEFmultAgPPZ2ho0oCBFFUOuslWolii4Q61Zaw d94UuMka69+jUagk63whRAwTswNVhotaS09qygQZl9i5XOFYFypkGyXFI4LOiPv2+X6D 2BoFeCCj/kgEF0oXkXqrzw0UP0hEw+O+7T3eEy9Iu/XIVuj8RGxx7ubNVR7e++mrzFpJ V5lw==
X-Gm-Message-State: APjAAAXfnK2JfD55wLYrzN31D3RAYIxQDqtdGbtGwKlHPsQLAcUgg0YK oM7r9bvCiEwloZdSDSkth3pKmQxJyvSg1FQRTLY=
X-Google-Smtp-Source: APXvYqy9ItPmGdkDb0u7ga1YogM2ansi7+M19Zk0WXxEOChnF4HLTuTZ6o14CWqBHXcUbT7e06PQCtSXDNYq2/LaYz4=
X-Received: by 2002:a02:86:: with SMTP id 128mr8668194jaa.3.1581311879419; Sun, 09 Feb 2020 21:17:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Mon, 10 Feb 2020 00:17:41 -0500
Message-ID: <>
Subject: Re: IPv6 payload length check?
To: Fernando Gont <>
Cc: "Aitken, Paul" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000da1c00059e31dc10"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Feb 2020 05:18:03 -0000

On Thu, Feb 6, 2020 at 1:30 PM Fernando Gont <> wrote:

> Hello, Aitken,
> On 3/2/20 12:30, Aitken, Paul wrote:
> > Can anyone point me to a standards reference for the check to validate
> > that the IPv6 payload length is less than or equal to the link layer
> > frame size upon forwarding a packet?
> There is no standards reference for that check.
> That said, years ago I worked on a consulting project where, among other
> things, we specified validation checks for IPv6 packets.
> This is the relevant excerpt for the "Payload Length":
> ----cut here ----
> The Payload Length is a 16-bit unsigned integer that indicates the
> length of the IPv6 payload (i.e., length of the rest of the packet
> following the fixed IPv6 header). Implementations should be aware that
> the IPv6 module could be handed a packet larger than that
> implied by the value of the Payload Length field. Such difference in the
> packet size might have todo with legitimate padding bytes at the
> link-layer protocol, but it could also be the result of malicious
> activity by an attacker. Furthermore, even when the maximum length of an
> IPv6
> datagram is 65855 bytes (40 bytes for the fixed IPv6 header, plus 65535
> bytes for the payload), if the link-layer technology in use allows for
> payloads larger than 65855 bytes, an attacker could forge such a large
> link-layer packet, and direct it to the IPv6 module. If the IPv6 module
> of the receiving system were not prepared to handle such an oversized
> link-layer payload, an unexpected failure might occur. Therefore, the
> memory buffer used to store the link-layer payload should be allocated
> according to the payload size reported by the Link layer.
> The IPv6 module could also be handed a packet that is smaller than the
> actual IPv6 packet size implied by the Payload Length field. This could
> be used, for example, to produce an information leakage. Therefore, the
> following check should be performed:
>            Payload Length <= LinkLayer.PayloadSize - 40
>        (The length of the ‘fixed’ IPv6 header is 40 bytes.)
> As stated in RFC 2675 [Borman et al, 1999], if a node that supports the
> Jumbo Payload option receives a packet with a Payload Length of 0 and
> with a Next Header of 0 (meaning that a Hop-by-Hop Options header
> follows), and the link layer indicates the presence of octets beyond the
> IPv6 header, the node must proceed to process the Hop-by-hop Options
> header to determine theactual length of the payload from the Jumbo
> Payload option.
> If the Payload Length is 0, but the Next Header is not 0, the packet
> should be dropped, and an ICMPv6 Parameter Problem (code 0) error
> message (with the ‘Pointer’ pointing to the high-order octet of the
> Payload Length ) should be sent to the Source Address of the offending
> packet (provided it is not a multicast address). Additionally, if the
> Payload length is 0 and the Next Header is 0, but the Hop-by-hop Options
> header does not include a Jumbo Payload option, the corresponding packet
> should be dropped, and an ICMPv6 Parameter Problem (code 0) error
> message (with the ‘Pointer’ pointing to the high-order octet of the
> Payload Length ) should be sent to the Source Address of the offending
> packet (provided it is not a multicast address).
> ---- cut here ----

  Agreed their is not any check in the IPv6 module for link layer MTU size
comparison to Layer 3 MTU.

>From a physical standpoint of the packet the last encapsulation before the
packet is transmitted onto the wire is the link layer Ethernet
encapsulation of 14 bytes + CRC 26 bytes.  So the IPv6 MTU would be 1500
and the link layer MTU after the final L2 encapsulation is done would be
1500+ 26 = 1526

Since the link layer encapsulation is the final encapsulation before the
packet is placed on the wire it is impossible for the IPv6 L3 MTU to be
greater then the link layer Ethernet encapsulation MTU.  This is for non
Jumbo but even for Jumbo frames L3 MTU greater then 1500 this would apply
as well.  If the outgoing interface L3 MTU is less then the packets L3 MTU
a ICMPv6 type 2 code 0 Packet to big would be sent back to the source.

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

Gyan  Mishra

Network Engineering & Technology


Silver Spring, MD 20904

Phone: 301 502-1347