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

Fernando Gont <fgont@si6networks.com> Tue, 09 March 2021 23:03 UTC

Return-Path: <fgont@si6networks.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 B39E83A109E; Tue, 9 Mar 2021 15:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
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 FMPsbKu576uL; Tue, 9 Mar 2021 15:03:24 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1258E3A1094; Tue, 9 Mar 2021 15:03:22 -0800 (PST)
Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3716B280AA1; Tue, 9 Mar 2021 23:03:07 +0000 (UTC)
To: Tom Herbert <tom@herbertland.com>, Fred Baker <fredbaker.ietf@gmail.com>
Cc: 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
References: <161366727749.10107.14514005068158901089@ietfa.amsl.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> <CALx6S36_w+zxyUt0DzQ9NKBs+SAPZDNhs_sqLBwi+qneOPSS5A@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <ef2bd4f5-3b1e-b88c-ec8f-dd9a2f9a60ba@si6networks.com>
Date: Tue, 09 Mar 2021 20:03:03 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CALx6S36_w+zxyUt0DzQ9NKBs+SAPZDNhs_sqLBwi+qneOPSS5A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/1-gTQN25K7bxx4wsDQ_uV_Lu_Ho>
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 23:03:28 -0000

On 9/3/21 19:07, Tom Herbert wrote:
[...]
> 
> 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)".

You seem to be reading more from the document than what we actually said 
in the document.

There are no requirements in this document. We simply explain things 
operators need to do, what are the associated limitations in real-world 
devices, and what's the likely outcome.

That's not an implied requirement, but simply a description of facts.



> 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.

"too long" for the processing device(s). You don't know what devices 
will process your packets, hence cannot even guess what "too long" might 
mean.

What you know for sure is that the longer the chain, the lower the 
chances of your packets surviving -- as per RFC7872.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492