Re: [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 1B09C3A0EB3 for <>; Tue, 9 Mar 2021 14:07:44 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xJ6wM6QugZhd for <>; Tue, 9 Mar 2021 14:07:43 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00D983A0EAC for <>; Tue, 9 Mar 2021 14:07:42 -0800 (PST)
Received: by with SMTP id l12so23626350edt.3 for <>; Tue, 09 Mar 2021 14:07:42 -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=G0FfWv3/hbxWinnZFMiKNwAPZYv4t97PKM7DToIblMnyYNbi0NNQZs/8pxYFpWt2Hb KMLvyHhEmu0svWTWtmPb+BAzvKa4b5tqYFaQPIWcE0AOgRE/e2YcOiSfuYIidBiFymv4 wdlgz5Jay2KFMgmyU0epLD0r7hZXw5CrNOFXubj7xyd/f0vywhyxEK3Xwaik2VLIkfVP b02TnOfuUtMl6Pa1VeSP2T8q9yY6jA+l9YiAyU8JE2LorQudYnZvob5CJxXyx+I8HoLt Q6RliNFOq60JxpjvyeqZaJXEo/srpH12nlEzM0mshTjx6ZDfNE4awRk9hAQxyT5JOGom 0sHQ==
X-Gm-Message-State: AOAM533JtpiIqCnM9HeSphufT3eO4Pnv7Zez91go2gxdBSy07t3J+MLH GfDe3dMLie9/oyEp9vUPCf1MN7ZQ6L4swzwrttnMQQ==
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: [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: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Mar 2021 22:07:44 -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.