Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency

Tom Herbert <tom@herbertland.com> Mon, 27 July 2020 16:03 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70E3A1B47 for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2020 09:03:23 -0700 (PDT)
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=ham 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 x3UOAkhqpHI9 for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2020 09:03:19 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 12BB23A1ABF for <v6ops@ietf.org>; Mon, 27 Jul 2020 09:03:17 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id kq25so4672365ejb.3 for <v6ops@ietf.org>; Mon, 27 Jul 2020 09:03:17 -0700 (PDT)
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=4HWMPNmTT8APIVV1fMPztbGKD0QeG8aAmF0n53udmWo=; b=QySNDHq4mqGv60U1jSRKWVPil1Jtm3fiED3VZIxpWgQppcVzxoS/FvwR44rI1ZhA8f 6Nk8JXKlWYZwOxaPoN1nfE39cUI26nH/XmX+6bh1l07TF7oQF5cffble4MPuO+Azg1nu c/kYj+PgFmRZz1ko/Wv49yVYT7TbQhbBy8wgZRiob+zANzi0SLrEgUrOgPxG34iThmpJ 0RT/CR6RpWDJx682DcqCPC3ipV3lQNiJorw1zXRYDsN97xXZdRjydxD2TJjH5RHD/6OU eaAzB8M8pakg2jYlvpBKdrN33nPstuxeNoyjCWLUYICbK47xnx9035NJ0E9bA2qO8pGM RFjw==
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=4HWMPNmTT8APIVV1fMPztbGKD0QeG8aAmF0n53udmWo=; b=IqTjSncB3LsHoDH0Mh2AYUHt6QPCtN/0Z60nOr+vC+1HP0g6L3oeRPg4oJKOCzQx9k DkoAVt0LfLL4lo9JKVQwxwN/M5cFFFPJkM9qNuDnv4pOfmT8HW5YhLfKdDpOqnQwFt4j cjOE4s2OpQzlCns/GiJEngRgjCg5yRLv3OJTsDhWR7BXsoxRHlpAS4PMKM7Amx10duJf FoNm1kFcuyN8ECGcx5oU3DJyfPEqDuAFitp9B0bQzlnOGRmmQRfAs1ogR1NMoVmRjsTD cAU755bMArPwleJsF3VtZy1Bplr8mRjLID4hWPIQbFepoQlqmfwfvSJXqSAW038jD45s MFZA==
X-Gm-Message-State: AOAM532fnhk7K3TdhxLSMhGLXpytfjfGJj8BsW1eQAgg6jgXL/Pznajb 7D++5dgFMFb/SEuiD0UYvt+sOTWV9O1Sz/ugbHmiOQ==
X-Google-Smtp-Source: ABdhPJx4GZVKc0KEAIVC+hZcWHEXcj2uW47QfR2yg/QDNsV0Guvd6sX8cWcSbdfwQKSJAJEqDRFDHl5WumbXnBOSnTI=
X-Received: by 2002:a17:907:104a:: with SMTP id oy10mr15092594ejb.267.1595865796352; Mon, 27 Jul 2020 09:03:16 -0700 (PDT)
MIME-Version: 1.0
References: <daa1c0efd47f47cfa9c2cffe4c917930@huawei.com>
In-Reply-To: <daa1c0efd47f47cfa9c2cffe4c917930@huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 27 Jul 2020 09:03:05 -0700
Message-ID: <CALx6S35-JwsBVSGBux43UWdmtrBYe3SgjrHe2b50j6YPCcpNmw@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" <draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8xlX-opxLYc6aFjnmQ4sIDKibGc>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 16:03:29 -0000

On Mon, Jul 27, 2020 at 2:22 AM Vasilenko Eduard
<vasilenko.eduard@huawei.com> wrote:
>
> Hi Fernando,
> You did mention "implementation-dependent" in security section. But majority of people would bypass security section on the 1st pass of reading your draft.
> Except security people, others would look to functionality 1st, them may be security (may be not:-(). Hence, you almost ignore "implementation-dependency" in such a way (putting it into security section).
> I propose to introduce additional 5.x, because (IMHO) "implementation-dependency" is the biggest problem in this draft - it is related to money/expenses (especially to replace hardware).
> It would be even bigger problem on next years with proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of IPv6 headers extensibility.

I really hope by " abuses of IPv6 headers extensibility" you meant "
uses of IPv6 headers extensibility".

> People need to check hardware (and software) capability far in advance, or else could be negative surprise. Warn them.

Within several IETF working groups we have been pointing out all the
issues around these "negative surprises" for several years, like
middebox protocol non-conformance and ossification (see discussions
about extension headers, discussions about IP fragmentation,
discussion about using alternative transport protocols, and wider use
of encryption). Instead of just warning people that things probably
won't work, can vendors fix these problems? For instance, RFC8200
allows intermediate nodes to ignore HBH EH. Has this been implemented
by router vendors in lieu of dropping packets with or relegating them
so some slow path that basically renders them useless?

Tom

> Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: 26 июля 2020 г. 8:46
> To: IPv6 Operations <v6ops@ietf.org>
> Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org
> Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)
>
> Folks,
>
> We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers".
>
> The I-D is available at:
> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
>
> Your feedback will be appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> Date: Sat, 25 Jul 2020 22:28:50 -0700
> From: internet-drafts@ietf.org
> To: Fernando Gont <fgont@si6networks.com>, Gert Doering <gert@space.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>, Nick Hilliard <nick@inex.ie>
>
>
> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> has been successfully submitted by Fernando Gont and posted to the IETF repository.
>
> Name:           draft-gont-v6ops-ipv6-ehs-packet-drops
> Revision:       04
> Title:          Operational Implications of IPv6 Packets with Extension Headers
> Document date:  2020-07-25
> Group:          Individual Submission
> Pages:          15
> URL:
> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
> Htmlized:
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04
>
> Abstract:
>     This document summarizes the security and operational implications of
>     IPv6 extension headers, and attempts to analyze reasons why packets
>     with IPv6 extension headers may be dropped in the public Internet.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops