IETF Logo Mail Archive

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

Gert Doering <gert@space.net> Wed, 29 July 2020 09:21 UTC

Return-Path: <gert@space.net>
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 3A5823A112A for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 02:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net
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 eVEJ0YA0SEt7 for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 02:21:20 -0700 (PDT)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260993A1110 for <v6ops@ietf.org>; Wed, 29 Jul 2020 02:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596014475; x=1627550475; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gt8ZFxd7wyCLkmBPOn0hvWV+FyerxLQkzbQRl/SdrFY=; b=crE79AozTIW5H5l5yoHhyQWlfaSNAPOXYILDVXCR7EtvnWEFua1mNZP8 Ps43EgzJ0tvUdjmrLrTWQMdCGtcN2UAJ0uYD/NVkmm3iPrjyUGrX3dSK8 /2kx1js4keOJNQOXMmSSNcH7MMubaWotw5oTvMyVSdF7R6maqnGq50Nkr kCKKftmxOEJ0pUNc3tZ/6KavRWTQIffAlqaTL8uXVMa3DOkj5+sRyZPac Hgf3uQpo9XFEEbBNSGTgGsOAhnXzRQPXor8c+GV6uLGTjti9RoB1HEUAT t1pNsnDoLgApKf6rg0usq48nht8Zy1dbF9XrnO+74HWBe8D4BuESE7guh w==;
IronPort-SDR: vcG+JCyb0Ervt5JZdxJulYKwKHAsJ4Fpf3z/6HU+ZjE5IeW2YN3KOLM/4FBpkTRJO28Phdb7Kw XqdAXrm9qz0iA6WtEucNW1Phcw3Ma1XUrdbtH6KeyrFrLl1fwxIDmt00XjTVXxGzxuRo2OHPNx XojEs85hiqtBEnhLbUeHqLAc3k8QmbO9fExMu2AzQEfnn7HHuJMycc/DpKO78o834Q8K8mXBgo GG5gNWady7ODp7YLdnJRumSMX5eiO8sSWpZz0zJ9YIr5n+i4jJKLKlDaMHptLLijDZxeWUFDZh 6qM=
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 11:21:11 +0200
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 63FE140CFB for <v6ops@ietf.org>; Wed, 29 Jul 2020 11:21:11 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4ADDC40082; Wed, 29 Jul 2020 11:21:11 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 3F2D8126D1; Wed, 29 Jul 2020 11:21:11 +0200 (CEST)
Date: Wed, 29 Jul 2020 11:21:11 +0200
From: Gert Doering <gert@space.net>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Gert Doering <gert@space.net>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
Message-ID: <20200729092111.GK2485@Space.Net>
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com> <20200729084351.GG2485@Space.Net> <fd2398a5109e49a8adaa70895e43d552@huawei.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ZJyjsuEEfVDUfqWY"
Content-Disposition: inline
In-Reply-To: <fd2398a5109e49a8adaa70895e43d552@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AA0wnHPO0UwXNEXfDYf9OcXhhHk>
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 09:21:30 -0000

Hi,

On Wed, Jul 29, 2020 at 09:10:28AM +0000, Vasilenko Eduard wrote:
> This approach is not universal. We need something better.
> Some EHs (like APN6 or Network Token) do make sense only cross-border. 

It might be possible to make this work between cooperating networks.

For generic "across the wide internet, without underlying commercial
relationships that ensure that a particular EH will work" EHs do not
work well enough to be a suitable tool.

Not my decision.  

Just observation after 20 years of living with some of the ivory tower
silliness that went into IPv6 protocol design.  Like "it should be hard
to handle EHs in middleboxes" and "make this an unbounded chain! 
computers love unbounded work!"

> Because source to attach EH is assumed outside of administrative domain. Just today was discussion about "how to make Alternative Marking cross-border".
> Moreover, "business" by definition is between different legal entities. If all these new fancy features are not related to business - many people would be very sorry.

The Internet is, generally speaking, in a very sorry state.

Nothing new here.

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

v2.23.0 | Report a Bug | By Email