Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt

Brian E Carpenter <> Tue, 04 August 2020 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 623333A11D9 for <>; Mon, 3 Aug 2020 18:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.147
X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[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.949, 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 rUw6F4CF-nIZ for <>; Mon, 3 Aug 2020 18:22:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5E203A11D7 for <>; Mon, 3 Aug 2020 18:22:48 -0700 (PDT)
Received: by with SMTP id t11so2125978plr.5 for <>; Mon, 03 Aug 2020 18:22:48 -0700 (PDT)
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=OLQvd5OFyfI5m/cKr0G9OBjceVL6Pf0bvcxTEkJOJZk=; b=DoYhSNoCKOJEEk057F7ljhAuoknaK8lx/YSaIoIkp6ztZegoyLaWYnNCGTrd54mA1p 5nLFMSnVvCgGpQmmZtgfmT+daHAixfAIA3jzXPLm/3gWwXy9WtHt1RuPQnpH34PyyW4p 2VZ/MVuWWYb/pEXSl1IED5kH+3RXS3QgSIclIq5xw6Od38C3911MoqePyMvIXmUL9eri aStic3QLnFlFEtAxaFZTKAa9o7OfGtLR0ExSLCY9TpRb+ADD4w42/rGRwVS9amoNfC5I lp78W54wzkGJAatYrEgnnoEcygw/cedrckNnYXOgIzp/tmpOAnJVNm1eKa9U0DgmsfC7 gwtQ==
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=OLQvd5OFyfI5m/cKr0G9OBjceVL6Pf0bvcxTEkJOJZk=; b=ErHedpA4kBlsTExIAobord4XVLdXkM/V73zqRA8zJqhG1aJUmV12qTzo2WreGX5Sgw Gj1oxa5uYjZx5n9UqDAdabtd/GdMpWXtyVbZFztiYMcTzNlAiQm5OVWePleeRRWZ9t/u WasY1XCShZu6qeDhzVn/roHd1jnjSE+Dona+EqFa85XjmtPjePNF13MAAliWZIKJSB/n zlorc3MHltjN6CrrpYStaGkchjRNZ+Ex7iwoWHOSpa1fT4P4vYwFc7bUqSzMVk3okXTZ bCYA6TBBFAUQO16sGdYEuoUbIBLuGzLD572qkkPWOzbK06929oqYckops3kQaCfMDrV8 PvOQ==
X-Gm-Message-State: AOAM532cRYLKT/5LqUqyRej+2pKXlJvurG0grIpGzFX/XaywJfWieO1D Gv8UvKRvcMndeYnNnquGDpcQE9kT
X-Google-Smtp-Source: ABdhPJyhtkktGJdTHsHyVIQCLUrQu+GVVs+xlFQhkwh6Boj4NfCugqRaz0KqMi5XUxF6ZwaQ5ONT4Q==
X-Received: by 2002:a17:90a:e558:: with SMTP id ei24mr2045864pjb.54.1596504167841; Mon, 03 Aug 2020 18:22:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id k8sm22247793pfu.68.2020. for <> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2020 18:22:47 -0700 (PDT)
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 4 Aug 2020 13:22:43 +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: <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt
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: Tue, 04 Aug 2020 01:22:50 -0000

I've tracked this draft since it started, so many of my previous comments have already been integrated. Now that it's a WG document, I've tried to read it again with fresh eyes.

General: I think this is a very useful document for the reason it gives:

>    o  Raise awareness about the operational and security implications of
>       IPv6 Extension Headers

I suggest ensuring that the OPSAWG and OPSEC WGs are made aware of this draft before it reaches WGLC.

Now a few detailed comments:

> 4.  Packet Forwarding Engine Constraints
>    One of the common
>    methods of handling next-hop lookup is to send a small portion of the
>    ingress packet to a lookup engine with specialised hardware (e.g.
>    ternary CAM or RLDRAM) to determine the packet's next-hop.

Am I correct in thinking that some implementations do this in parallel with receiving the rest of the packet, i.e. overlap the destination lookup with receiving the payload? If so, that seems worth mentioning, to underline the strong focus on line speed processing.

>    If a hardware forwarding engine on a modern router cannot make a
>    forwarding decision about a packet because critical information is
>    not sent to the look-up engine, then the router will normally drop
>    the packet.

I wonder if this is slightly misleading, because it also applies to middleboxes that are not strictly speaking routers.

>    NOTE:
>       Section 5 discusses some of the reasons for which a modern router
>       might need to access layer-4 information to make a forwarding
>       decision.

It might be worth pointing out the obvious at the beginning of this NOTE: the destination address is always in the first 40 bytes, so the concern is about forwarding engines that do *not* forward based only on the DA.

> 5.1.  ECMP and Hash-based Load-Sharing
>    Clearly, widespread support of [RFC6437] would relieve middle-boxes
>    from having to process the entire IPv6 header chain, making Flow
>    Label-based ECMP and Hash-based Load-Sharing [RFC6438] feasible.

There's a slight confusion there. RFC6438 *does not* depend on the source setting the flow-label, because it's about setting the flow label for ECMP in foo-in-IPv6 tunnels, where it's the tunnel ingress that needs to follow RFC6437. There is a problem for non-tunneled packets, but that is not covered by RFC6438.

So my friendly rewrite is:

Clearly, widespread support of [RFC6437] would relieve middle-boxes
from having to process the entire IPv6 header chain, making Flow
Label-based ECMP and Hash-based Load-Sharing feasible. This can
be achieved for provider-based tunnels [RFC6438] and in principle
for server-farm load balancing [RFC7098]. However, this is not
true today for wide-area ECMP or load sharing.

> 6.1.  Inability to Find Layer-4 Information

It seems to me that a mention of how TLS also causes this is relevant. If TLS is in use, does it matter whether there are extension headers? There's some good recent analysis in .


On 01-Aug-20 07:31, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>         Title           : Operational Implications of IPv6 Packets with Extension Headers
>         Authors         : Fernando Gont
>                           Nick Hilliard
>                           Gert Doering
>                           Warren Kumari
>                           Geoff Huston
>                           Will (Shucheng) Liu
> 	Filename        : draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt
> 	Pages           : 16
> 	Date            : 2020-07-31
> Abstract:
>    This document summarizes the operational implications of IPv6
>    extension headers, and attempts to analyze reasons why packets with
>    IPv6 extension headers may be dropped in the public Internet.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or