Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 07 December 2020 19:17 UTC

Return-Path: <jmh@joelhalpern.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 D1BCF3A0603 for <ipv6@ietfa.amsl.com>; Mon, 7 Dec 2020 11:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-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=joelhalpern.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 4uDdM_jRbKtG for <ipv6@ietfa.amsl.com>; Mon, 7 Dec 2020 11:17:24 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4503A05AA for <ipv6@ietf.org>; Mon, 7 Dec 2020 11:17:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CqY3S4FQZz6G99X; Mon, 7 Dec 2020 11:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1607368644; bh=LPyOiB6Fuj183gOTX2Zawcjr9e70/KBhtgbK/T651VI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GMsTVhHFPqsbRE1tvMQBT67H92/4yL9JDyEUUnLeZ7w+klmwRDgrc6KYgO8PopsFz TWMgd/VkhrQ7ZrHFmNWlJxvfH9lxbx4dk/Pf+AijUlakBcRXT2KGWJqMYbzRCXBMLm aNPrdxzQz181VeZVxalFlM2Z+jR9acga3kAp726U=
X-Quarantine-ID: <F0loXTlYsQa6>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CqY3R24kMz6G8lx; Mon, 7 Dec 2020 11:17:22 -0800 (PST)
Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Tom Herbert <tom@herbertland.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>, Fernando Gont <fernando@gont.com.ar>
References: <5c2257307541431981be5a4dd3f9880c@boeing.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <584098e8-6d49-72c3-f9d4-6f043ee51927@joelhalpern.com>
Date: Mon, 07 Dec 2020 14:17:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <5c2257307541431981be5a4dd3f9880c@boeing.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rCG_a9yeG31WqxY-H2dS9j49ewE>
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, 07 Dec 2020 19:17:26 -0000

Heavily trimmed

On 12/7/2020 12:32 PM, Templin (US), Fred L wrote:
...
> I am not concerned about a Linux host; I am concerned about IPv6 routers.
> Do IPv6 routers look at extension headers beyond the first one trying to see
> if there is an out-of-place HbH header and then drop the packet if there is?
> If so, I don't think they should.
> 
> Fred

This sounds like the classic IP Header checksum case.
The practical answer was that while the standard said that an invalid 
IPv4 header checksum required dropping the packet, most routers did not 
bother checking.  They simply made sure that any changes they made to 
the checksum did not turn an invalid checksum valid.

There is a practical tension, in that it would be nice to drop bad 
packets (of whatever kind) as early as possible.  So it would be nice to 
drop a packet that the far end will silently reject early.
But doing extra work to drop packets is generally frowned on.
And if the rejection is not supposed to be silent, it is much better to 
let the far end entity do the work of responding.

None of which has much to do with the topic at hand, but is related to 
the concern you expressed.

Yours,
Joel