Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs

Tom Herbert <tom@herbertland.com> Wed, 29 July 2020 14:34 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 5243D3A0BDC for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 07:34:41 -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 7O-xZYe-AxRr for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 07:34:39 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 9F5D53A0BDE for <v6ops@ietf.org>; Wed, 29 Jul 2020 07:34:39 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id n2so17566647edr.5 for <v6ops@ietf.org>; Wed, 29 Jul 2020 07:34:39 -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; bh=0X7FPiP7LwaqqMTUP+JhC6eCc0B+5tDVcZR0JqshLeQ=; b=C++dh35LT30kRHDF3CCKmUjenwKuFQPPzWu5wD1GtmWosADam+McsokJpZx8qunfRJ 9IcyWUhfdv9ziSSBsrJy3GM5KzWjWbHza8Dtv3kZ9jRJXLYkeeI+CJG+sbHOCovj2sQ9 3zUX/VA4eNfm+1xEXdEgd94dl+dBtmwROS304XM7ZrJTPEklul+OEDuBoghyPGJAZZWC G6JZ7FMjC3ys71tyy+Z1y+1x/K90hxINEthsEqLdaGDMZJhMrMWoCXNYPkMy7xKR0Jan OwZtYyBQWO5nJiOme6qfHureRt7notf5sqLCKNWhOgk0tjzMbuyO2hoKoTwlfE51A4Y7 ZtFw==
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; bh=0X7FPiP7LwaqqMTUP+JhC6eCc0B+5tDVcZR0JqshLeQ=; b=qyOy+cYVTAH5cwv71OfcZSRRIkZ/V3hDoZawSf0r4LgJZnrWJUxXPoqO6WF/Q8wsf+ kM8Ra8qsaUVjtKZ9AVGzuia2gUt8GnYlRIjnSPfEdLZW3JAn/Dons94RU0T1lgh7PPxg XaxWIp2NCnOzv4d93Up2EqdKKtHAtlq/YrrSfPp3FgY1uc7BFzhqZhNAchpy0Q4MGj+s n0gH0NlA5JovIWdi8Ei0Oki9RKfAauUP431ow3kWzWYnIZQ4nqSNCNpXkxq1MArSicmA FWaKlUKIS598T2KGAsRYoaa9TegkX8x4fnps2nCp6nJmzGff8El11DzMzRE987+r1CpU MXFw==
X-Gm-Message-State: AOAM532UbXOBTJaf+7RuBmxGiiyDPeofLg/WmPRLpGKLaTaURaNZVbm6 iNyJMIiCfKIZJZTPYeEtMK5hJvkElqZaeQ4OL+4gcd+JQNM=
X-Google-Smtp-Source: ABdhPJxvnt0w883b17XKsi31rxKbawjHkcZfShjnOepaYc5FpWDOU9GF4mAOPPwJ1GzJDjgkYVFWsec372YomcMjorY=
X-Received: by 2002:a05:6402:785:: with SMTP id d5mr15333785edy.370.1596033277928; Wed, 29 Jul 2020 07:34:37 -0700 (PDT)
MIME-Version: 1.0
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com> <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <a6ed89a8-c12e-b8d2-c720-5cc02e127a68@si6networks.com> <FCBD1043-A0B2-435A-9AB9-0FCE3566C769@employees.org> <20200729122622.GT2485@Space.Net>
In-Reply-To: <20200729122622.GT2485@Space.Net>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 29 Jul 2020 07:34:26 -0700
Message-ID: <CALx6S34kLn+n4TMQrO0YKncB_j2P5Z2M3-Sn1_81+eDaTONz1A@mail.gmail.com>
To: Gert Doering <gert@space.net>
Cc: Ole Troan <otroan@employees.org>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ggpl7NPrLgFO1N8PqxWyZ02xwpU>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
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: Wed, 29 Jul 2020 14:34:41 -0000

On Wed, Jul 29, 2020 at 5:26 AM Gert Doering <gert@space.net> wrote:
>
> Hi,
>
> On Wed, Jul 29, 2020 at 12:43:23PM +0200, otroan@employees.org wrote:
> > >> Anyway I don't quite understand what this document adds to work describing ossification in general
> > > Avoiding rehashing the same discussion everytime the issue of EHs comes up?
> >
> > So you are proposing to fully embrace ossification and deprecate all EHs?
>
> Can you see a way to make them work?
>

Gert,

Yes. We can apply the same principles that helped IPv6 get any
traction (even if it only took twenty years :-) ): Assume deployment
of any new feature on the Internet will be incremental, Provide an
automatic fallback to a lesser protocol when the feature doesn't work
over some path at the possible cost of degraded service to the user,
Collect real time data on status of feature support in different parts
of the Internet and make it public, Ensure there is economic value in
supporting the feature so it's not just an academic exercise, Be
flexible in use of the feature (e.g. extension header
insertion/removal).

IETF can address issues in the protocols themselves that inhibit
practical implementation. For instance, in retrospect wrt extension
headers it's clear that requiring every node to process HBH options
and requiring these devices to potentially process hundreds of TLVs in
the fast path wasn't feasible-- we can provide practical guidance to
mitigate these (which RFC8200 and RFC8504 does in these cases).
There's still work to be done, for instance hardware limitations
around how many bytes of headers a device can process is regularly
raised (including by this drat) but what exactly is "too big" has yet
to be quantified; it would be nice to provide guidance for host
implementations so they can know when they're sending a packet with
too many bytes of headers (draft-ietf-6man-icmp-limits-08 is a good
direction but only to the extent that ICMP is usable).

Tom

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops