Re: IPv6 payload length check?

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 February 2020 22:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 0B2C8120132 for <ipv6@ietfa.amsl.com>; Tue, 4 Feb 2020 14:40:47 -0800 (PST)
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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.com
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 TIbg6MBjix_K for <ipv6@ietfa.amsl.com>; Tue, 4 Feb 2020 14:40:45 -0800 (PST)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 3D04F12008D for <ipv6@ietf.org>; Tue, 4 Feb 2020 14:40:45 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id ep11so65892pjb.2 for <ipv6@ietf.org>; Tue, 04 Feb 2020 14:40:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=up0q1aXQp2jRCC9VRMeuCAwlRZDnNKOKQ4oE/HmHPJc=; b=qXZ2+qOWL8W0Gk6x8QlzXyHG3RrOZfv/hZCPSYSR8ZUUnZgm6lM21GTKq98KqTn/dF VcBsAHgnsgvdYVT+TstKcq13/02ksjBErfHaYtkbS0r8vE78HpLeG7spAqXQo3O07fdQ UdD/o9iCK2kR5ZiRa0IjQGScv3nTx/9LCIwatmY9y51DGrjihktFfZiKmVBSxAYmeFUK p43/xsGv5BnOdy/hMIzcgoUCptq6UAeRmjJyPlH/xmP8BwWy0HAsr7Ezk+D7Xd3mHn9T huElTIqfjOg2AvXSFj0+s0grar4HyC3MqTBFgX4o07zEkXCB7iO68wF8UioUisI35n/8 Gy0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=up0q1aXQp2jRCC9VRMeuCAwlRZDnNKOKQ4oE/HmHPJc=; b=pPBrZoW/9PPuKaK4FOaGnns9zi/hiCOCCe7F3b0d35/N/yCTWMu8UDINQ6jOtyUlUW 5xZyXhxDewiFrGZ66RVZBbnTps2vGgodOuo6DfTm/6KBd6fuqwDev/GZqBotvYmrEGEX bBl1UU4s87TK036Mw87mSCAmXIlNPyHTE9gQXaCtIpNG3y7P9YL5JqiWlX99ylC41mhT EaWp0FonRvg5y/SglWN6P673fSEbdrq+QQ/GQFthQgeFpDzBx9Sj2TdpntwG1Waz46QE T1r0FKzSFpiIH2nDYvUzPgDLxw5rWCx2C5+85fi7WW7dGA6lanQrPkL/Q5n58rccRKmn fwvQ==
X-Gm-Message-State: APjAAAUNolI34lGuiNfZ8tlA8o5bmurfHgv7YoGXuGccfGdF7s08UGn4 41KtcP01Nmkd7r983WQC9SB0b7b9
X-Google-Smtp-Source: APXvYqw/yrqkzbocPt249aFOQvzHUdetbTrYN3BZBkOEVvq+rKKIxNrP7twIw7RoCTPbzLWLHVkJig==
X-Received: by 2002:a17:90a:f317:: with SMTP id ca23mr1773786pjb.20.1580856044230; Tue, 04 Feb 2020 14:40:44 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id t66sm10622410pgb.91.2020.02.04.14.40.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2020 14:40:43 -0800 (PST)
Subject: Re: IPv6 payload length check?
To: "Aitken, Paul" <paul.aitken@intl.att.com>, Erik Kline <ek.ietf@gmail.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
References: <90342768-7f25-b9dd-eeae-29db6045b40a@intl.att.com> <77f55628-6f9d-d06a-4e38-f84d76e716bb@intl.att.com> <CAMGpriWVN0EGLz5PyeyL5LTo_+A1i+xHCD6kw0E0pCRCcGcY2g@mail.gmail.com> <21c14789-73b8-1347-98bf-9c70c3d31e76@intl.att.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <7a10e4bd-b78b-ee4f-311e-d43b2a621303@gmail.com>
Date: Wed, 05 Feb 2020 11:40:38 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <21c14789-73b8-1347-98bf-9c70c3d31e76@intl.att.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3-8txtQRksHzORo96H4PyDG_Ru0>
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: Tue, 04 Feb 2020 22:40:47 -0000

On 04-Feb-20 20:43, Aitken, Paul wrote:
> Thanks Eric.
> 
> In this case the packet is *not* larger than the MTU of the outgoing link. Rather a packet has been received (or possibly generated locally) with an IPv6 payload length greater than the link layer frame size.

'generated locally' would surely be a coding bug (probably in the socket API), since such a case should simply be impossible. Either the packet would have been fragmented or IPV6_DONTFRAG is set and the send() will fail. In any case it wouldn't be a protocol issue.

> Probably this packet should not be forwarded. However, I couldn't find anything to say that it's invalid.

I don't see a fast-path switch checking for this condition, so I think it can only be detected at the final destination, as others have said. But it seems like an implementation issue, not part of a protocol spec.

   Brian

> 
> Thanks,
> P.
> 
> 
> On 03/02/2020 22:05, Erik Kline wrote:
>> Interestingly, 8200 contains this text in the Routing Header section (4.4):
>>
>> """
>>    If, after processing a Routing header of a received packet, an
>>    intermediate node determines that the packet is to be forwarded onto
>>    a link whose link MTU is less than the size of the packet, the node
>>    must discard the packet and send an ICMP Packet Too Big message to
>>    the packet's Source Address.
>> """
>>
>> Really that text would seem to apply even if a routing header is absent.  4443 on PTBs (3.2) has the text you might be looking for:
>>
>> """
>>    A Packet Too Big MUST be sent by a router in response to a packet
>>    that it cannot forward because the packet is larger than the MTU of
>>    the outgoing link.
>> """
>>
>> On Mon, Feb 3, 2020 at 7:31 AM Aitken, Paul <paul.aitken@intl.att.com <mailto:paul.aitken@intl.att.com>> 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?
>>
>>     Thanks,
>>     Paul
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZfTZz_O9E1tN4KFtMYO2ZkKk5U5-6SlI-21vZEhzDuU&m=qBignlV2D2HjQ1OG98CXIFMbZryHbieyfesxKE4ZOfg&s=Hcp5fCXJd8pXcMtmqOUaw179roZQXSQntvE-zFdQYbY&e=>
>>     --------------------------------------------------------------------
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>