Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs

Brian E Carpenter <> Thu, 30 July 2020 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BC763A0C99 for <>; Wed, 29 Jul 2020 20:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 znWf1uSwhsaV for <>; Wed, 29 Jul 2020 20:52:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F371B3A0C97 for <>; Wed, 29 Jul 2020 20:52:05 -0700 (PDT)
Received: by with SMTP id q17so13044225pls.9 for <>; Wed, 29 Jul 2020 20:52:05 -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=/1oB02xiDkc+ORghd6hKI6y1hJm1WYmgIZXtsV8EaNQ=; b=raXa3y6va8kvgTC16ommedhK2CYpkx9RmsoxbEbymB2W+quDCeLIzwYVbSbo8EU/A6 XIRXIvRI0nThU8DGABW1eVK7QEFJkruZqoTZ2UakrLVCkLxA4isI3AtFBTIELvrNMTCi /5OQf+1W4QL8uxeGynUjArt3ggQwIPaa06NSVVJbBdd1a7zry1V8d3LocvdXM5t4s72r Kd33E98J/kW+8qhZk/FAEuSA9juf30RUZbOGx8A9zubse7PcmE5GcpIxvyEPSG1WgOeI 7AXWEKxNOavsc7bYwcL4gyeWqpqpMrBrA7Cw0K58hB8SHajVEp5vsriqSTMRkqCKBrfv /2cw==
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=/1oB02xiDkc+ORghd6hKI6y1hJm1WYmgIZXtsV8EaNQ=; b=btE6csme/59d/SMeC/Wp//CGa24AzfWodaX0aw9N8/Ri01KE12RnOND8yPAgatlkAS eS684t2o6qHLXIWBVpuDBlXnITFZceNTKnbAkAbojdZrlf95gdnVQ2TICJAWZWFfyImX CG0HmCrCwX60mSNbfqMkL8k8cMnLHyRR/DJYH+KI7owZplqWOl9ixIAzpyffNbmoRh0m QSmfFpoffQHFUT0r5LwiTeSFYGzm63LkwP7Mlexo+t/OIQVsy+qPYHbEBJM+Jitn0Xrl pupALea0SIgpH4f+w9fHwqvgkDZGNxugnKWoB22xfy7mxFUtNMFg9Cr9PEOZga0szUjH rZ0Q==
X-Gm-Message-State: AOAM530T1oAh4gk4Mzqvfw1beOhnBjbcHU0I0vyN+DVv/WIybdPBYgMm ObkPpy27odkfxznTPoVGJn4pl3WRQs8xEA==
X-Google-Smtp-Source: ABdhPJxctDGPcs+WIfrRBIpVhKvsclZ3YUwWAz5j+mtiY3Dk+M+Zd/Jx8MWLPtVFI7is3MnRVkhaEg==
X-Received: by 2002:a17:902:a418:: with SMTP id p24mr32101026plq.55.1596081124919; Wed, 29 Jul 2020 20:52:04 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id f89sm3798056pje.11.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 20:52:04 -0700 (PDT)
To: Fernando Gont <>, Joseph Touch <>, Owen DeLong <>
Cc: IPv6 Operations <>
References: <> <20200729084351.GG2485@Space.Net> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 30 Jul 2020 15:52:00 +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: quoted-printable
Archived-At: <>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 03:52:07 -0000

And it may be another unpopular fact of life, but I believe that RFC8799 is relevant. Certainly some basic rethinking about interoperability is needed.


On 30-Jul-20 14:25, Fernando Gont wrote:
> Hello, Joe,
> On 29/7/20 17:16, Joseph Touch wrote:
> [...]
>>>> If we are merely documenting what happens to be implemented, we cease to be a standards body and become merely reporters.
>>> If we avoid any introspection or consideration of operational reality, the cease to be a relevant standards body and become an ivory tower.\
>> That’s why I said “merely”. Doing both and appreciating the balance is fine - the point is that “what is implemented/able TODAY” is NOT the only consideration.
> FWIW, I don't think we should limit ourselves to documenting the 
> problem.Indeed, documenting the problem can certainly be a starting 
> point to consider possible ways to mitigate it.
> For a long time, the status quo was assuming that EHs work. More 
> recently, thanks to a number of efforts (Geoff's measurements, what we 
> did in RFC7872, and others), there has been increased awareness about 
> the packet drops.
> I would expect that a common understanding that there are underlying 
> issues that lead to the packet drops (and it's not just folks playing 
> with "firewall" rules at random) can serve as a starting point to 
> consider what can be done to make things better, closing the gap (to the 
> extent that is possible) between what the IETF says IPv6 is, and the 
> operational reality of it.
> Thanks,