Re: [icnrg] recasting address semantics

Jens Finkhaeuser <> Fri, 25 February 2022 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCEF93A0801 for <>; Fri, 25 Feb 2022 06:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zjKHin59qChp for <>; Fri, 25 Feb 2022 06:31:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE9DE3A07F7 for <>; Fri, 25 Feb 2022 06:31:57 -0800 (PST)
Date: Fri, 25 Feb 2022 14:31:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail; t=1645799512; bh=0O+RW0NQ5ZnYcKxCA4F05Fw6RMe5DKY9iUHl/FHPVCw=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=A+4ieVLd/yQjmky+eNXwbDKujJ5dx9/IIRokqXA+1U7LBNX+NprW3k8pX5qQkzHH/ tY46OiUG0Be/9mmbBCm7YgkIgoyVFmhEkvzOPOIfRhrgSOeEJ0CobfD8ac/9CC8qB8 KVWI9L8xrH4sOCsS/I94DelyJEvr5T8dKSetEoyg=
To: Dirk Trossen <>
From: Jens Finkhaeuser <>
Cc: Dirk Kutscher <>, ICNRG <>
Reply-To: Jens Finkhaeuser <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------a8c45c1c6f14f1cffef42538d91bf05d50f7f77f5fec6657e023e1b3b7549d11"; charset="utf-8"
Archived-At: <>
Subject: Re: [icnrg] recasting address semantics
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Feb 2022 14:32:04 -0000

Hi Dirk, Dirk (couldn't resist), all,

I recently joined the mailing list because I have an interest in the topics here, so you won't know me. For context, I'm recently doing R&D work on future internet protocols under grants from the European Commission's Next Generation Internet Initiative and the Internet Society Foundation. I also work on behalf of AnyWi Technologies B.V. on a number of R&D projects mostly regarding drone communications. I'd be happy to discuss this with anyone at any time, but don't want to hijack this topic; this just by way of mini-introduction!

I find that post and the response interesting because they echo thoughts I have been having, and so I have comments.

First, I do actually agree with Geoff *in principle* that the time for addressing has changed. This is mostly motivated by the amount of interest - not just from AnyWi - in stable addresses for highly mobile "devices" as drones are (some call them flying mobile phones, which in a particular size class, is not wrong). For safety and regulation purposes, stable addresses for these command & control links are highly desired here. At the same time, a lot of that stability relates to tamper-proofing of communications, which in practice really means that the stable identifier for a drone is a (hash of a) public key.

Geoff misses a key point in the "mobile IP" problem in that the regulation here demands multiple distinct wireless radio technologies, which means transferring an IP from one mobile tower to another or even to another mobile provider is not sufficient. The transfer must also cross completely distinct organizations without much interface between them, such as an offshore oil drilling platform providing local WiFi-p for landing and takeoff, and a satellite provider for flying over open ocean. For cost management reasons, especially that second phase might be routed over the internet.

The preferred solution at the moment is to provide some virtual tunnel and perform the handover transparently to drone and ground station. Going into that might go to far; the point is, the problem of a stable address that moves across networks is still very urgent, and not solved by handover between one LTE provider and another. For identification and verification purposes, we do need stable addresses. But for mobility purposes, they cannot be concerned with location.

The second observation I have echoes Dirk's a little, in this view:

> What I find wrong is to manifest the observation of "Today's Internet is dominated by Content Distribution Networks (CDNs) and their associated 'clouds'." as an apparent guidance for developing Internet technologies that may want to go beyond this model since it bears the danger of skewing technology development along a dominant economic model. I would argue that the strength of the Internet's original innovation philosophy to enable serendipitous discovery and permissionless innovation is something that may go down the drain with that view. Or vice versa, I wonder if most of what we enjoy as 'the Internet' today would have emerged if this attitude had been at the forefront of its origin some 40 odd years ago (I can hear similar "Today's..." statement, just from a different community back then, wondering what those IP people really want...). Maybe we simply observe the innovator's dilemma here?

I feel Geoff's article is a bit superficial in how it lays blame for NATs and lack of IPv6 adoption at managing the last mile. For a number of reasons, I consider data center providers to also push in that direction, even though the typical lament I hear here is that the lack of IPv6 adoption forced their hand. There is a distinctly observable trend over the past decade(s) where centralization of services goes hand in hand with data center virtualization technologies and treating IP addresses as increasingly transient. That is, it's not so much that CDNs (and their 'clouds') are a solution to the problem as much as clouds (and then also CDNs) created the problem in its magnitude in the first place.

Practically speaking, instead of pushing harder for IPv6 adoption and solving the service resolution problem with more responsive DNS, etc., larger cloud providers deliberately chose to virtualize IPv4 aggressively in order to manage this much smaller space. And since the pool is exhausted, those who have IPv4 blocks now have more leverage in pushing further in this direction than those who don't. The apparent goal here is consolidation.

Of course, this is somewhat speculative, and I'm sure there are good counter arguments to be made as well. I'm not set in this opinion, just haven't seen much data yet to convince me otherwiseJ.

In either case, this leaves me in somewhat of a pinch: needing more virtualization of addressing on the one hand (drones) and desiring a lot less on the other (more decentralization). My grants currently cover the periphery of this issue, but eventually I hope to work on this as well. Hence my interest in this cropping up here and now!