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

Gert Doering <> Wed, 29 July 2020 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3E7B3A0C1C for <>; Wed, 29 Jul 2020 07:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 y-8nEVMk4t-w for <>; Wed, 29 Jul 2020 07:58:41 -0700 (PDT)
Received: from ( [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3A383A0CB8 for <>; Wed, 29 Jul 2020 07:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=esa; t=1596034712; x=1627570712; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3QMsTa3eg7HzyO/wYF86ECP0gHmZrygWHKaVWElzVCw=; b=JL8ckuwkADkZ2Nod6McAYcECdojBR0CHAKyO9A8UhfpvcpaUsUSg1fYQ Ab4rl0ZiyktumrRhy3L29sI+bt0G5olsvr8jxpaHMS7H8dUiJQbRGajh+ D2aUiNEyj1PPMFfQrkU+FNZybInqsY9Bsi3SZPnhZkJPhc1pfHcfV/Mwz K2vv1LTPpZ8hX+xzoYTJY1iTS/OI/ZFO8qKFXDB8rsYaPAX4UP/bJvsKL GbGk7kyXGNoAtSoixq1QtE1sQVcZvF3VsrfRjHA3/wJFr3QdOKOkiOklG yVhjSScjrnihve2zjov/fQDIq8mmvWcy6dnbvA2yMtn2kHk0SFyt/KMzn Q==;
IronPort-SDR: v8HQiU24pFK4KxAggojYRBvEBvzkKMRgKmTLn//N9n7x3JpzXN5U9OCkc2UETJo4OQx0gg//3w 9HqE7tINX/yhyUlDCjCa0JryFCF6BCq2MITK/xmJFTxQSQbHJDIfxtFX5qOAJcC2/omWs5E05G MGyAXaWewXcK8Rsyzt4BHS3tk34+5TqTklHDoS8xMzCerX2uS+qP5SlsH0MSMHMRbR/BbYT9ve 5x+vKkYS5yvBKn3ahHkljYH5VTGNwWlPa4JMU56Shik1OrCz7vJF+V9BefY/1G4cGkzyPJi87E N3s=
X-SpaceNet-SBRS: None
Received: from ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 16:58:29 +0200
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 095F841261 for <>; Wed, 29 Jul 2020 16:58:29 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from ( [IPv6:2001:608:2:2::251]) by (Postfix) with ESMTP id 9EFC940CFB; Wed, 29 Jul 2020 16:58:28 +0200 (CEST)
Received: by (Postfix, from userid 1007) id 98DB818679; Wed, 29 Jul 2020 16:58:28 +0200 (CEST)
Date: Wed, 29 Jul 2020 16:58:28 +0200
From: Gert Doering <>
To: Tom Herbert <>
Cc: Gert Doering <>, Ole Troan <>, Fernando Gont <>, IPv6 Operations <>
Message-ID: <20200729145828.GX2485@Space.Net>
References: <> <20200729084351.GG2485@Space.Net> <> <> <> <20200729122622.GT2485@Space.Net> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t8zr4fefo56TD9MG"
Content-Disposition: inline
In-Reply-To: <>
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 14:58:44 -0000


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.

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