Re: Validation of Packet Too Big Payload using Echo Request

Fred Baker <fredbaker.ietf@gmail.com> Mon, 27 January 2020 19:40 UTC

Return-Path: <fredbaker.ietf@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 A082F3A0987 for <ipv6@ietfa.amsl.com>; Mon, 27 Jan 2020 11:40:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 WYJDjJqjDgi3 for <ipv6@ietfa.amsl.com>; Mon, 27 Jan 2020 11:40:11 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 1A0CE3A0115 for <6man@ietf.org>; Mon, 27 Jan 2020 11:40:05 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id q10so5373653pfs.6 for <6man@ietf.org>; Mon, 27 Jan 2020 11:40:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fo3vTUDuFK9qyRd4qYADmQwJ9C5IPhuRpyXx8sGkwgM=; b=W0q+JfV+8Cb6FWPVn3mL7xasl5SdejvJDq7cLhgCRVw0ZZW/nH0Rbfm04F5OD/2TKw M0iaBWUvHh9z0+IuOwFqhln8ZR8V3P3YHeiHpEYkQYnq5uTHA8n7xR2+RvS/WjQgZNiW C+gH3fC68qnndCa6XWaTND8SQShOLNdUNo74yU7R+GIFFg33UzD+FwxGIy4jHnfSoLq7 Ye4OBBGBQYHWdjv8nLhYP8+gcW5gLKyZdMMRpOITeA+TTVGkJbPq33g6lYYXlsSO5633 Xsmg88mde9Tow3GBWTAe3mHJ3k0fYgok60xWSZVE0xT+z6+DGmMbm2nn1Lnu07n3bZ7K HaPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Fo3vTUDuFK9qyRd4qYADmQwJ9C5IPhuRpyXx8sGkwgM=; b=Q7ClYG7XlLgT349T2JPyoEnINbpIKs3xI16Faf3n8pKDq/Q+M7CS6Kj0YP2rsR/l88 2OKO6il0r06D2G68Gyxdu6AlmFh5yl9EVgO8zlGUIuNYoQt0SpTIHEmFXPenYfUU3yX8 xNuXN8GkuSP7gXmK4Uu9acrL9HSMyJjg0pcADRT2rjddczR3zmVAkuckQyHoTCMbr6uK K6psjVlj9EuBJkD+41cYHzebWDpYGpDfscdJk9VMZDcbeyruf10WxPBq03DRkEQ/ONDs 1X4CH8DJ+tlGsWzo9LmN2+40zSXoSzOBkxIhTz05Ux6dI8nPzDn9RDkgKglUUw5MsK6q rNyw==
X-Gm-Message-State: APjAAAX0PeiIeQFLlElWug1ZqlDGIYS5WK4TP/RYT2Z03E+PLi0hgQwM ScK6sxT0uDhO9Kp3PX8Jy1E=
X-Google-Smtp-Source: APXvYqwR+WESCvuDrdL7pA/7HNmBrEiKKc7wK+kumPipa5OYDPucJ/0wvZ/ILNwUFcmNJbwyLaCUoA==
X-Received: by 2002:a62:16d0:: with SMTP id 199mr237373pfw.96.1580154000156; Mon, 27 Jan 2020 11:40:00 -0800 (PST)
Received: from [172.20.3.120] (rrcs-74-87-33-234.west.biz.rr.com. [74.87.33.234]) by smtp.gmail.com with ESMTPSA id q11sm16152801pff.111.2020.01.27.11.39.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jan 2020 11:39:59 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <F9ACCBEA-D009-48BF-B2F6-7179C0DDCB2A@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_21EC08E5-96C1-4DD5-8D91-FE74D55E82DB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: Validation of Packet Too Big Payload using Echo Request
Date: Mon, 27 Jan 2020 11:39:58 -0800
In-Reply-To: <CAOSSMjVzTmCRxLg8k+9t+j0u9iMMWa+T_8P7kVRKGLkiup_jDw@mail.gmail.com>
Cc: 6MAN <6man@ietf.org>
To: Timothy Winters <twinters@iol.unh.edu>
References: <CAOSSMjVzTmCRxLg8k+9t+j0u9iMMWa+T_8P7kVRKGLkiup_jDw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lqtrgnzUq1LXo6WiXZVj_Z_R2LA>
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: Mon, 27 Jan 2020 19:40:22 -0000

PTB and PMTU activates in IPv4 applies to streams of packets, not sessions. Given that IPv6 operates from the same definitions, I don't see why it would be applied to something different in IPv6.

Now, in fairness, TCP has a way to address PTB/PMTU - it changes the MSS in use for a session. UDP doesn't have anything so clear. But IMNSHO, that is a deficiency in UDP, not in ICMP. UDP, or the process using it, is informed of the limitation. It fails to act on it.

> On Jan 27, 2020, at 8:45 AM, Timothy Winters <twinters@iol.unh.edu> wrote:
> 
> Hello,
> 
> The IPv6 Ready Logo Committee updated testing to include a test for validating the Packet Too Big message content based on the following part of 8201.
> 
> "Nodes should appropriately validate the payload of ICMPv6 PTB
>    messages to ensure these are received in response to transmitted
>    traffic (i.e., a reported error condition that corresponds to an IPv6
>    packet actually sent by the application) per [ICMPv6]."
> 
> I've included the steps below used to verify the IPv6 implementation validates the Packet Too Big.
> 
> Step
> Action
> Expected Behavior
> 1.
> TR1 forwards an Echo Request from TN2 to the NUT.  The packet size is 1500 octets.
> The NUT should respond without fragmenting the packet to the Echo Request using TR1 as a first hop.
> 2.
> TR1 transmits a Packet Too Big message to the NUT with an ICMPv6 Identifier does not match the Echo Reply in Step 1.
> 
> 3.
> TR1 forwards an Echo Request from TN2 to the NUT.  The packet size is 1500 octets.
> The NUT should respond without fragmenting the packet to the Echo Request using TR1 as a first hop.
> 
> We received a comment that this validation shouldn't apply to ICMPv6 and it should only apply to TCP or protocols that have state.   Do we think this only applies to TCP or is it valid for all traffic?
> 
> ~Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------