Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Tom Herbert <> Tue, 09 March 2021 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0AF13A0EA7 for <>; Tue, 9 Mar 2021 14:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 S4dxViJZi85I for <>; Tue, 9 Mar 2021 14:07:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 656E73A0EA4 for <>; Tue, 9 Mar 2021 14:07:41 -0800 (PST)
Received: by with SMTP id t1so23584793eds.7 for <>; Tue, 09 Mar 2021 14:07:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JgtXYUw9KiDBxIMY4flWJNOBkJg8eKqRYyplCrM/KPk=; b=yZeZZlve+qyZ01mOq44CEfzZQXVCTbu1T6W2kW4rThnsN/HObs9yLkN1BhMbxgUqte tRvPkCVm/cB8HMzcv6iEOU/G9PoH1weBoiPSdICs+tU3wWqPx7DIzok2dmH/7LORO6Kl Q0T+HjEvD5BWZn7fuTsfKLE5e5apIXd9fH/61laaWJtCyiWXRmQsyWsIV3gkeddw3L64 2uaCodWJ69XrsZ+9rIbxagVi+zNEjrcW0AwQxn46ory2+h/L6gNUlsIwWM9qPYkqbmOD 17rfijE58yWcyJ/VfxdWUx7leoMXNmhYt+OAUSmYDBEZuITzoPHHceaYFHJbDrYHv9vd SvLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JgtXYUw9KiDBxIMY4flWJNOBkJg8eKqRYyplCrM/KPk=; b=sKNcX8vpsvWyT1XaEbSYen3OzPRo7tLX9JqqIcJYMMixpDvggDPsyq3lLxjPKSOb+/ VSgIeDP/P3GIj53Kuf0NdMU+uCw8RGbopm146j166eR/EYHFJ6+PLR3CcVb1ueU30ayW pHRlWmKFeGiST/uMCskhQiVdTDultuFGW/BfKMnoQD7i6nAdij7SuJb+IdUz17vJ6zu+ SuWro8XjmIcbRjpBUpJJLnIMONgfgl6qnQ+EANH5CUdXJmwDLtWGkvxARxx2OwyM5pI5 IOJ2HzdZK3JpD/9MAFkUpf3BkEHEd4kFp7rHIqh2THxduaeVIiO3WJUB06QbRXEFFWUq uQuQ==
X-Gm-Message-State: AOAM533Cr4f8eXpQU9OI8Zrzx2UKVK6pzA9h1ww0BlyqaSMGhZeHKnk7 kzA4rXgPQd4mCZSz29CCUjUyXGkrRbslJQ0/2PbBxA==
X-Google-Smtp-Source: ABdhPJzSTkeNPm/Hntu+NJVi8QifvN/Nzlv2T3uyXg3lSzdfruaNHlF+/L/GOAxQCDXfvoxxbCeX5K9MsS7kIqvjRxg=
X-Received: by 2002:a05:6402:354d:: with SMTP id f13mr6656003edd.228.1615327659581; Tue, 09 Mar 2021 14:07:39 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 9 Mar 2021 15:07:22 -0700
Message-ID: <>
To: Fred Baker <>
Cc: Fernando Gont <>, Mark Smith <>, Gorry Fairhurst <>, IPv6 Operations <>,,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Mar 2021 22:07:43 -0000

On Tue, Mar 9, 2021 at 6:07 AM Fred Baker <> wrote:
> > On Feb 24, 2021, at 9:01 AM, Tom Herbert <> wrote:
> >
> > The problems have been caused by some
> > routers implementations that have assumed unwritten requirements (like
> > routers must access transport layer),
> For the record, I don't know that this is a "router implementation" issue as much as it is an "operator requirement" interacting with the design of IPv4/IPv6 and UDP/TCP/ICMP. The protocol number, which operators filter on in ACLs, is carried in the transport layer headers.


Yes, ACLs on transport layer ports are common requirements, however
the problem arises from related requirements that arise due to the
limitations of routers to be able to locate the transport layer
information in a packet. An example of such an implied requirement
from this draft is "don't send packets with IPv6 header chains that
are too long because some routers can't parse deep enough into packets
to find the transport layer ports due to implementation constraints
(like limited size parsing buffer)". While the rationale for the
requirement may make sense, the problem, at least from the host stack
perspective of trying to send packets with low probability they'll be
dropped, is that a requirement that "don't IPv6 header chains that are
too long" is is useless without any quantification as exactly to what
"too long" might be.