Re: RFC 8200: The Devil's Paragraph

Brian E Carpenter <> Fri, 28 February 2020 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5CDB3A0C1E for <>; Thu, 27 Feb 2020 18:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ur83X5aXubtG for <>; Thu, 27 Feb 2020 18:08:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A92163A0C1F for <>; Thu, 27 Feb 2020 18:08:41 -0800 (PST)
Received: by with SMTP id d9so671472pgu.3 for <>; Thu, 27 Feb 2020 18:08:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XWmgWN0rXoBoUK2Lr8z6sQEKOnIqz7ozFeLP+S1TGfA=; b=F/7ghIiD9ibAQeRq0/4byYSO06qXt04ncx6n5ViYpkUoTpSueNbV+FzLux/LXIZVN8 uh44xPVVjmrxrrCALAoUA7whR4aN3yyyZhVO2o/eh9y5AuvY33tWLEd19t2R3+QRO1l/ qcvmUaGpJebhp4wy3urSsBH0D9MedUcayxT7rHWKgdFm8bvVRJnRSLFRJtgoOqgFy8Ks mwy2jsbV3VKMTI8szjDAqH5XDFCdwLGJ737GBbw7T4+bxFLAvcHOHqs0WmMW/p8lq6S5 b7n6c8kDcxjfcuV+9R7B4qwehn5llNcNjJX4WGnEZ959ds8MWbmVepdDPqbVRKHWAlip jP9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XWmgWN0rXoBoUK2Lr8z6sQEKOnIqz7ozFeLP+S1TGfA=; b=HArsYdXvVVonB8xn73ZXgp5SfBuLFso1Hqj/7GVJD8TJ72oC2uil2LE7PkM7atUlvG eFOGp+21eFQO8j1LczlMv/DYMkLyMCB3vooML7Glg2rriGFj7aoxdcXwgueI7daPJZQH NXVGszG1WcEbJ+oR9iN+OM17J0LGAHR6jqpdHjMpjti+ZwoBEcZPL6670weWICrKtk4n L/SjH2TQzDu5KwIu4+tOxmPvqf4ef3SCitMeWxc0c0gOzneup4rFzD8yJFH5qQtiro/7 e56nQDLUmtIdWyppDS62XcMhDzI0nvDRW8FR6+dRDDW38pyurcEdyzAu6PauVjk4W7CQ MG1Q==
X-Gm-Message-State: APjAAAWlx+YJwvGRVbsfxctZw0JW6ub3169S+PVyTkUwuQWUqFJem/6B c46P0gDjCPL3TPs07nol1OigoUxK
X-Google-Smtp-Source: APXvYqxbQc75eJIwM8+/tMDGGWimjtnHQLRcgf0etAgLJp2p9Vi7NDvPPLdA/2kd5Kw7wNTCIk+HBA==
X-Received: by 2002:a63:4282:: with SMTP id p124mr2341796pga.59.1582855720853; Thu, 27 Feb 2020 18:08:40 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id c68sm9021114pfc.156.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 18:08:40 -0800 (PST)
Subject: Re: RFC 8200: The Devil's Paragraph
To: Ron Bonica <>, 6man WG <>
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 28 Feb 2020 15:08:37 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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: Fri, 28 Feb 2020 02:08:43 -0000


Rather than getting involved in the errata/appeal discussion, I'll comment here.

On 28-Feb-20 11:52, Ron Bonica wrote:
> Folks,
> Looking more closely at “The Devil’s Paragraph”, it may have a few problems.  Currently, 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.”
> The problem is that the rules for processing, insertion and deletion are different. It should say the following about extension header processing:
> “The Hop-by-Hop Options header can be processed by any node in packet’s delivery path. 

The word "process" itself is troublesome, and I believe I said this at some point in the 2460bis discussion. I'd rather see it broken into two parts
  "read and interpreted"
  "modified (without changing the data length)"
with separate rules for each.

That said, putting the rule for the HbH header first rather than making it an exception seems much clearer.

> The Destination Options header and Routing header can be processed by any node in a packets delivery path, so long as one of that node’s addresses appears in the Destination Address field of the packet’s IPv6 header. The Fragment Header, Authentication Header, and Encapsulating Security Payload header can only be processed by packet’s ultimate destination.”
> Regarding insertion and deletion, we should say one of the following:
> “Extension headers cannot be added to a packet after it has left the its source node and extension headers cannot be removed from a packet until it has arrived at its ultimate destination”.
> We can debate whether we want to make a special exception for Routing headers where Segment Left is equal to 0. But the current text is too permissive. For example, it allow the penultimate segment endpoint to insert destination options. 

I don't understand how it does that. But then it was always clear to me (as to Fernando) that "destination" meant "ultimate destination".

> When it does so, the destination node falsely assumes that the source node originated the destination option.

That's right, and it's an unverifiable assumption.