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

Tom Herbert <> Wed, 29 July 2020 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D0853A0BC4 for <>; Wed, 29 Jul 2020 08:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pk_3yZJ9rBTB for <>; Wed, 29 Jul 2020 08:18:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B08B3A0BD1 for <>; Wed, 29 Jul 2020 08:18:41 -0700 (PDT)
Received: by with SMTP id c16so4367298ejx.12 for <>; Wed, 29 Jul 2020 08:18:41 -0700 (PDT)
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; bh=6NDQSCPyF+uz9h5noAfk9fn5XoTaM/qcXutMfrzRh9g=; b=zULpKFfP7c8NguOMnNNohglbvDVFS0Ba6DaMOHxr+DwRwBQAMHoIJAfWeaK+7b1edu rQ/D0a04GWD6qRksM5zvYOVTbNm6fPz95DZR6wX8MucZ5bfhAYVv0TlBRhGASAGEhZQT rFc+cJv1P56pndbWM8+qYeA4Wr6640bEa9vpOhBxV8PEVxekn24OOKUXy4qsT1qKFqhH 5/woWX5qjD/snTX1hkglt/hDg6xlsUhFISdCG8te+ZNGufULtXqFyRM0tRA4TtSjOS+/ NkbRflT4pP797nNKVAE3sQH3r0rSee+PV78k4VvqXpjmLc4ETiThxfQ43SYOTtkJGaQV OlJg==
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; bh=6NDQSCPyF+uz9h5noAfk9fn5XoTaM/qcXutMfrzRh9g=; b=csZ38Q41Tl7EYa9M4IcAgqXRjam1CVjC+CYGEtEuVb2yAPGOuqLCt9TN9bsWBveQzC Nh58MDfD6+Al41wCE7TPxX6XdZxAZ7w7fTf6QFc4dRoz9/oLBmhFK+NvpRMcWthzWBvo izbkNBmLi1Iv+FwPsdq+ShZefLPiZqntwE2HkoeGDwKewiG91tQnAVMWVXfP1YBCGCHf Wd6s5thGC2JgMWjQvHq7vTK//phJcT5tWeHSEQfDExb45414KHTKurWhxFJXTwjKYzPx xnE6BwMofgUD3TDSCyduhpeuCAthNJT0SfPdZydOWDnQRXwT5raHXvSULrQ9mQYrTk4w 2/9A==
X-Gm-Message-State: AOAM533nwfQb85cjlrkAxW8s2HUT0I1YKjydTfcWhnHZCAh1f+mAOn+2 knNVpZRRguFTng3kL8W5KsWQECXNxJoPD3cU1otzaA==
X-Google-Smtp-Source: ABdhPJz5OUZVe14XGixrA70TQaHOo+j5PDDtHWie9rEZzkLuTL/hvbvITMogNIKV7tuSkJQNbvDDGJcyMZB7W9vg9jY=
X-Received: by 2002:a17:906:a242:: with SMTP id bi2mr30082791ejb.243.1596035919730; Wed, 29 Jul 2020 08:18:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <20200729084351.GG2485@Space.Net> <> <> <> <20200729122622.GT2485@Space.Net> <> <20200729145828.GX2485@Space.Net>
In-Reply-To: <20200729145828.GX2485@Space.Net>
From: Tom Herbert <>
Date: Wed, 29 Jul 2020 08:18:28 -0700
Message-ID: <>
To: Gert Doering <>
Cc: Ole Troan <>, Fernando Gont <>, IPv6 Operations <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
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: Wed, 29 Jul 2020 15:18:44 -0000

On Wed, Jul 29, 2020 at 7:58 AM Gert Doering <> wrote:
> Hi,
> On Wed, Jul 29, 2020 at 07:34:26AM -0700, Tom Herbert wrote:
> > > Can you see a way to make them work?
> >
> > 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).
> This looks like tremendous success story in the making.  Just like
> IETF succeeded with getting IPv6 and all the cool bits of it (look,
> ma, it has EH!!!  AND IPSEC!!) out into the fields.
> There is no incentive for network operators to make sure their network
> can transport EHs if it works "without".
> There is no incentive for application developers to code support for
> "anything with EH" if they have to assume "it will need to work across
> networks without".
> Now, if IETF could find big bags of money somewhere to hand this over
> to network gear vendors to build EH-friendly equipment without extra
> costs, and give some more money to network operators operating in an
> increasingly low-margin market to replace all their gear with "new and
> full of EH support!  same power consumption, same everything, same
> price, just more EH!", then there might be some hope.

Then they won't be able to use segment routing, IOAM, or new QoS
signaling like Network Tokens that are now being developed and being
deployed. That's fine, it's their prerogative. Some operators will
certainly make this decision to not invest in new technologies, like
when they decided to defer on IPv6, but I don't believe all operators
will come to that same conclusion. Even the data bears this out, the
oft quoted RFC7872 still shows that even in the worst case of HBH
options the majority of flows still made it to the destination. It's a
given that we can't rely on much to always work 100% on the Internet,
but IMO if we apply the right techniques we can opportunistically
provide something that works and provides value to users.



> But even then people will happily use the no-longer-in-use non-EH
> compliant gear to build new networks with lower setup costs.
> 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