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

Brian E Carpenter <> Fri, 15 May 2020 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB50E3A005B for <>; Fri, 15 May 2020 16:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 73stxjMw8Ctj for <>; Fri, 15 May 2020 16:50:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A905A3A0029 for <>; Fri, 15 May 2020 16:50:04 -0700 (PDT)
Received: by with SMTP id z15so4640385pjb.0 for <>; Fri, 15 May 2020 16:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0PL18ljocClDQXXhiqY2lIH2rFbNRbzWMZlg+0UjMO0=; b=YD3jB84E2oBBN6Rps59kn0TmVDF2S2S3Ht/Ot0Edz36t+OwQxuTqSrGkVtsmBG7YVF 3VLDiOvQw7jkhwJn+8xv6m2j2g4u4afMEcyNviHvjDzj2iaOWB2kj4B0gmBs+pCnqlAT 2JE6WFt9u18eZvrxSwjkD+cK3LAci+sxUYWvZUY+2AU5H7iHwe9tIYZyJ7In0Zh3tXaD Hz69iolP4CSvL0npie7S3aP5HPDNcmmwPIWLTVpkgUil4/JGftw8Bx/lzsgDAnb3/kOI PI5S5fg8SnimNzo06Puyk/Cdi2kT32lOlfgT0IDhh7qQ3Zykc4QjU5ZYEGJjq1eCxJDz JEUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=0PL18ljocClDQXXhiqY2lIH2rFbNRbzWMZlg+0UjMO0=; b=lvPLbQH3XCmOFkfOlr2W82QlRTm+SnOqzFWfgW/9fHMv/0Eg0CBJn0hGpxSLrHlTMR UMuB0uc5sxkC3dgP+wS0JpzwQD/mzQeN675SEmFeui9gYP6v4ZWeS+9ofQr+bS5EeWs+ UGtEvcl0kQH0VdwdRS4/hcJnSp6yzRTLJEqKw0u/6StQXwhUoDVg5Qx+qLP7ytz7pOLa 6gXeN9z+gRMUDjuW1JDVJEJs4bobA/Dwla7S6V6t2NXjOpgHq9n1NoXGWtYb+OmOmRFp R/EZ07X82dsqG/kGPwLS9tAcL6Qcn2fOlsO+nEklpDQ83NrpquNghxpYYDGf0aL+K44H KdaA==
X-Gm-Message-State: AOAM530BFTjLfLMkBS8kowvYQAc/NGCNgL1tyfg25So9XNAvTOC4Espw ygTmwO2z3aXhibuGJjC/bNCeE3Xu
X-Google-Smtp-Source: ABdhPJyKX8WB48OZjCtdI8S5vey0l62Fh96xRne9zjW4zJRsUIbRtxLCFAdUQ/NdpVS9AGkEq+8IIQ==
X-Received: by 2002:a17:902:326:: with SMTP id 35mr5412232pld.188.1589586603777; Fri, 15 May 2020 16:50:03 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id n2sm2143333pfe.161.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 16:50:03 -0700 (PDT)
Subject: Re: Spring Appeal and [Errata Rejected] RFC8200 (6003)
To: Sander Steffann <>, Erik Kline <>
Cc: Fernando Gont <>, Bob Hinden <>, 6man WG <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sat, 16 May 2020 11:49:58 +1200
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: 7bit
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, 15 May 2020 23:50:06 -0000

On 16-May-20 10:32, Sander Steffann wrote:
> 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. 

And there's the problem right there. "reads to me" but not to other people.

The text is objectively ambiguous because it can be read either way. (I read it the same as you, but you and I are not the IETF.)

I actually agree with the AD: this is not something we can fix by erratum, because we objectively haven't got consensus about what it means.

We need an "updates" RFC to fix this. And we have a draft for that. And a process to follow to reach rough consensus.


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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------