Re: [icnrg] recasting address semantics

Dirk Trossen <> Fri, 25 February 2022 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB47E3A0DD1 for <>; Fri, 25 Feb 2022 06:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mK2kVdR1BLdE for <>; Fri, 25 Feb 2022 06:57:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 313EB3A101A for <>; Fri, 25 Feb 2022 06:57:41 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4K4t6g6Qqkz67lp5; Fri, 25 Feb 2022 22:52:43 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.21; Fri, 25 Feb 2022 15:57:37 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Fri, 25 Feb 2022 14:57:36 +0000
Received: from ([]) by ([]) with mapi id 15.01.2308.021; Fri, 25 Feb 2022 14:57:35 +0000
From: Dirk Trossen <>
To: Jens Finkhaeuser <>
CC: Dirk Kutscher <>, ICNRG <>
Thread-Topic: [icnrg] recasting address semantics
Thread-Index: AQHYKWga85a81zR2+0mPkvxzj5PbfKyifywAgAHW3ICAAAOYwA==
Date: Fri, 25 Feb 2022 14:57:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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:58:06 -0000

Hi Jens,

Thanks for your thoughts on this. Please see inline.



-----Original Message-----
From: Jens Finkhaeuser [] 
Sent: 25 February 2022 15:32
To: Dirk Trossen <>
Cc: Dirk Kutscher <>; ICNRG <>
Subject: Re: [icnrg] recasting address semantics

Hi Dirk, Dirk (couldn't resist), 
[DOT] It had to happen at some point :-)

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!
[DOT] maybe we could come back to this offlist, indeed.

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. 
[DOT] On that point, I do not disagree, BTW, but it's the remainder of the argument that irks me. 

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.

[DOT] My inner cynical me would probably refer you to Geoff's observation that the currently dominant model serves 70 to 90% of traffic very well, so transit is dead and other not-so-well-served comms models are dead, too (and, BTW, we need no innovation in routing). It's this part of the blog that makes me warn in terms of not falling into the trap of skewing technology evolution in favour of a current dominant economic model: we may just increasingly squeeze out those aspects (and with it, use cases) that do not fit this dominant model, ultimately stifling the innovation the Internet would want to see (still happening at app level, indeed, as long as the provisioning model aligns with  the dominant POP model though). Coming back your problem, it seems to just fall in-between the cracks of not fitting the right dominant model of "how to do things" for those 70 to 90%. Of course, my non-cynical me tells me that this should not be the answer and your desire should be served by what we may call the Internet. 

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). 
[DOT] What you formulate is a view of what you (your use case) may want from the network as a feature. It may be a great input into the discussion that is happening on the INT area mailing list, where we have two ongoing drafts on internet addressing (the ones Geoff refers to in his blog post). As a result from a side meeting we organized at IETF112, we have now compiled input we received to the question on "what are features users want from networks" from the INT area mailing list discussions. An update to the drafts including that input is imminent (with the upcoming IETF113 deadline). Maybe we can get you to formulate some input for a possible update that will likely follow after IETF113?

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!