Re: Spring Appeal and [Errata Rejected] RFC8200 (6003)

Sander Steffann <sander@steffann.nl> Fri, 15 May 2020 22:33 UTC

Return-Path: <sander@steffann.nl>
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 8D7573A0C1B for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 15:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=steffann.nl
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 LotUJ4Nu8BDK for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 15:33:06 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 D43B23A0C19 for <ipv6@ietf.org>; Fri, 15 May 2020 15:33:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B496449; Sat, 16 May 2020 00:33:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1589581979; bh=Bhrf4vTR8VHDuZ1YhMP 5btE0aLCh56fB+wslZjAa4kE=; b=ehguoqODFqtCZAfiXeuhTal2BjrlFpXcpFi ebJUFdxgL86dnF/KMmLkMfMkuUIg3VrdEqAPa2L/nbNkBtpCjjTu9O1p+thouYVu Z0MK9h5kVDhpY0011to1eVkywsXtrHDwlihjniESmLrxUN5KdrK3v1Q6Q3GoXocw nqCYlwC8=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r-5QoJjA9tu1; Sat, 16 May 2020 00:32:59 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:9e3:2a70:3627:5486] (unknown [IPv6:2a02:a213:a300:ce80:9e3:2a70:3627:5486]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 14F9B3C; Sat, 16 May 2020 00:32:59 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <58642567-BDF2-4243-B2DF-E5F12E38FF89@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_0892A861-33C2-466A-A2A5-10641A2D7FC6"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Spring Appeal and [Errata Rejected] RFC8200 (6003)
Date: Sat, 16 May 2020 00:32:57 +0200
In-Reply-To: <CAMGpriXR55WawsnEnUYfdNUkvmTS34e4QjfSpDoNFZk-=Qabpw@mail.gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>
To: Erik Kline <ek.ietf@gmail.com>
References: <20200510184112.9643EF406D6@rfc-editor.org> <030874d9-28f5-48da-befb-f0a210c51347@si6networks.com> <A1A84435-E0A3-403C-A1CF-CC83F75BCC0B@employees.org> <ffea7f98-b5a8-7afd-727b-eba50087aa32@si6networks.com> <CAMGpriXR55WawsnEnUYfdNUkvmTS34e4QjfSpDoNFZk-=Qabpw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pkK2Frk608KfZR1WFHFT2tR689U>
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, 15 May 2020 22:33:10 -0000

Hi Erik,

> RFC 8200 includes an exemption to this behaviour for nodes whose
> address appears in the Destination Address field of the IPv6 header.
> This text has not changed from 1883 to 2460 to 8200.

I disagree with your interpretation of the text of 8200. It says:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

It mentions _the_ node identified in the DA, singular. It only specifies multiple nodes in the case of multicast. The combination of using singular and only using plural when explicitly talking about multicast reads to me as only referring to the final destination. The use of the word "until" signals the same to me. Using "until" for something that can occur multiple times sequentially in a packets lifetime would be very confusing.

Now, this does pose a problem, because strict reading of that text also means that a node can only learn that it is not the final destination by processing the routing header. As I read it, that node can process the routing header but then has to stop further processing when it finds out it is not the final destination. In blunt English: any further processing of headers is none of its business. As I understand it that is also the reason that a separate destination options header may appear *before* the routing header.

Cheers,
Sander