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

Tom Herbert <tom@herbertland.com> Tue, 09 March 2021 22:07 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADD63A0EA4 for <last-call@ietfa.amsl.com>; Tue, 9 Mar 2021 14:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz-t6YyxWKHZ for <last-call@ietfa.amsl.com>; Tue, 9 Mar 2021 14:07:43 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5433A0EB2 for <last-call@ietf.org>; Tue, 9 Mar 2021 14:07:42 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id x9so23540456edd.0 for <last-call@ietf.org>; Tue, 09 Mar 2021 14:07:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; 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; d=1e100.net; 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=fFxOSbZNBBTMj2xAODBXf2k8CSpbBYnRMiHHVgZSUFgVYlIaHtmeoFEleKUZinXDwd cCc0eSRCSuNCtqi2k6FITkAC3uPKXpGrjGDIPgWz7JGD8+2PvInpnUAl/EQ4OOMrL5er woaI8hdVl7i+A49q5gKnh1uZ9YlVqFd7uO3IfQ9cLCideCudSK7c7Bpzd7t8eeTiJtKI 3Fp/AzzmOIyDI9d3P6yCva+pf4dU+uzS35PaPtNgdCL9s9mzpd/7bQZnUE6BjVJhEyEC Vf2J5mrJDb7VW+GxRWf15P86zS5UrAOrC90iL6iO8rhq+6Bigz8zEZn1Ow5bu51xXWtq mu9g==
X-Gm-Message-State: AOAM532GjoeMtF5cXvns820fDq3YgwmJQPkEtTcyuiwsdTJlG48PjJiO sOdgcF8d1WbfT9UKE6O7Po75FkcIawllBRLJU7J+jQ==
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: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com> <0e377231-c319-2157-30a0-759e2f96a692@gmail.com> <5f464f17-85ed-f105-35f9-02f35d04aed2@si6networks.com> <CALx6S364zGbq_HZNNVEaJHnHccuk4Zau2DXhmaVYbwnYQc-5bw@mail.gmail.com> <1847e8e3-543f-5deb-dd14-f7c7fa3677db@si6networks.com> <CALx6S34TPppMRJrOvyJ05LLeRvv+S51pQHJnzZDKk-qOdsF0AA@mail.gmail.com> <e41f3484-f816-e185-2d99-94323c8da732@si6networks.com> <CALx6S34qSxGijVcs229bAL5gMhMvMNYUXm3yEmrg6wxUiUAiaA@mail.gmail.com> <bf83d228-25bc-21bb-f984-d58ead6bf492@si6networks.com> <CALx6S35Kh-QAXJDAucuw5Wty37MBiwS=pqQknMZ+15b7D5Sn8A@mail.gmail.com> <34e78618-cb28-71a1-a9d3-7aec38032659@si6networks.com> <CAO42Z2zqD9_d2Fbr25Y2CV1GdzYKd167yf5DHeHna7V66pF65A@mail.gmail.com> <0bd316ac-1789-f4c6-d280-943ad6e60309@si6networks.com> <CALx6S34dMEEJ+OPUu_=FW1Y5AQuvAaHzBPEe448S7rfbMmHN_w@mail.gmail.com> <CEFDF511-9255-4913-840D-50CCBC2B7B17@gmail.com>
In-Reply-To: <CEFDF511-9255-4913-840D-50CCBC2B7B17@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 09 Mar 2021 15:07:22 -0700
Message-ID: <CALx6S36_w+zxyUt0DzQ9NKBs+SAPZDNhs_sqLBwi+qneOPSS5A@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, Mark Smith <markzzzsmith@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, IPv6 Operations <v6ops@ietf.org>, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, last-call@ietf.org, tsv-art@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/ALD5KN1K2487K_x9n189UTxKw5k>
Subject: Re: [Last-Call] [v6ops] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 22:07:44 -0000

On Tue, Mar 9, 2021 at 6:07 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
>
>
>
> > On Feb 24, 2021, at 9:01 AM, Tom Herbert <tom@herbertland.com> 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.

Fred,

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.

Tom