Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Dirk Trossen <> Thu, 27 January 2022 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EB743A1736; Wed, 26 Jan 2022 23:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.237
X-Spam-Status: No, score=-0.237 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, URI_DOTEDU=1.659] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6IC-H-EtDJbN; Wed, 26 Jan 2022 23:51:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 222193A1730; Wed, 26 Jan 2022 23:51:37 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Jkt7d2Fkbz6H8F9; Thu, 27 Jan 2022 15:51:09 +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; Thu, 27 Jan 2022 08:51:33 +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; Thu, 27 Jan 2022 07:51:32 +0000
Received: from ([]) by ([]) with mapi id 15.01.2308.021; Thu, 27 Jan 2022 07:51:32 +0000
From: Dirk Trossen <>
To: Geoff Huston <>, Eliot Lear <>
CC: "" <>, "" <>
Thread-Topic: [Int-area] Continuing the addressing discussion: what is an address anyway?
Thread-Index: AQHYEuvcVeDDeIeyKUuL4sj4Zxskn6x2eatw
Date: Thu, 27 Jan 2022 07:51:32 +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: [Int-area] Continuing the addressing discussion: what is an address anyway?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jan 2022 07:51:42 -0000

Hi Geoff,

Thanks for the thoughts below, which is much aligned with previous interactions on the development of the current Internet. Please see inline.



-----Original Message-----
From: Int-area [] On Behalf Of Geoff Huston
Sent: 26 January 2022 20:35
To: Eliot Lear <>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

> On 26 Jan 2022, at 5:24 pm, Eliot Lear <> wrote:
> [copy architecture-discuss]
> Geoff,
> This is a pretty good characterization.  In fact, it's exactly where we went in the NSRG nearly 20 years ago, just after MO first kicked out 8+8.  For people's reference, we looked at naming at different levels, including at L3, in DNS, URNs (which were relatively new things then), HIP, etc.  There were then several efforts in both the IRTF and IETF to deal with portability of connectivity in transport.  I think QUIC gets a lot of that right.  QUIC – at least at the moment – as some limitations for local use (either you have certs or some sort of prearranged bidirectional authentication).  I think it's a fair engineering assumption that those will be kinked out.
> With all of that having been said, I go back to Dirk's note: what properties do we need at L3?
> 	• If QoS is still a thing, then admission control has to be part of the story.
> 	• There is a tussle between endpoint privacy and the endpoint itself being a threat.  In the latter case, the endpoint has to be identified.  But to whom?
> As you describe, a lot of routing has moved up a layer.  Sort of.  But not all.  CDNs need to be well aware of topology, and that comes from L3, perhaps with additional OOB info.
> So... what's missing from L3 at this point that we need, and is it even a good question to ask?  I ask that because I have seen recently a retrenching AWAY from IPv6.  If that is happening, what makes us think that any new L3 beyond IPv6 would ever get adopted?  OR... what is missing from IPv6 that would cause people to move?

Hi Eliot,

Thanks for your thoughtful response.

In my mind “What is the role of IP addresses in today’s Internet?” and “What properties / semantic role do we need from, or implicitly assume, from IP addresses” are quite distinct questions.

Some brief background (which I am sure you are aware of, but to help me organise my thoughts, and possibly for the benefit of others on this list):…

Its pretty clear that we commenced down the road of re-casting the role of IP addresses at about the same time as we started down the track of consumer deployment via dial-up ISPs. We introduced the notion of time-shared addresses, where the IP address you got was temporal for the life of the connection, and we subsequently introduced the notion of port-based address sharing via NATs. I don't think issues of impending scarcity wewre the predominate driving factors here - I think it was a more mundane issue of cost transfer to the consumer. i.e. from the ISP’s perspective we headed donw the shared address road becuase it was cheaper for the industry at the time to do so.

At around the same time (late 80’s early 90’s) we heading down the “running out of addresses” path which ultimately lead to the design of IPv6.

It is useful here to contrast the differences in these two approaches - the latter was an IETF-led command-and-control effort that attempted to anticipate future industry needs and produce a technology that would meet these needs. On the other hand the industry was being driven by two imperatives, one unchecked demand that completely swamped any efforts to satiate it (we were building as fast as we could, not as fast as consumers wanted), and the imperative to strip cost. 

The recasting of the role of addresses was not a particularly deliberative process then, or now. It was an industry response to the prevailing conditions, and in a deregulated market-based activity that’s the only driving factor out there. 

If we are going to repeat the IPv6 exercise and attempt to second-guess the future market for the means of delivery of digital artifacts to consumers, then I guess we need to understand what is driving this industry today and in the near future. It appears to be true that CDNs feature big time right now. If you include video streaming data then I have heard figures of between 70% to as high as 90% of all delivered data being video streaming (No, I have not seen good public data to confirm these mutterings - I wish I did!). It also appears that enterprise network demand is morphing into the same CDNs as cloud services. The shared public network and its infrastructure is being marginalised (and privatised).

[DOT] I agree that understanding the 'now' is important but I wonder if this was the dominant thinking that led the development of the Internet? I think we can dig out similar 'status quo' type of observations around the same time when the stake of IP-based communication was put in the ground (I wonder what the service with similar traffic numbers was back then). Was the point of IP(v4 or v6 alike) to "second-guess the future market", as you put it, or to specifically avoid locking oneself into one way of 'doing communication' (if the latter had been the basis in the 70s, how come that IP came around instead of continuing to optimize the then status-quo?)? 

[DOT] But more importantly, should the 'doing communication' aspect (the technology behind it) be skewed towards a particular economic model and technological realization? Key here is, to me, that the Internet specifically wants (and has been wanting) to avoid such lock-in as an aspect of permissionless innovation that is not built on a technological foundation that is skewed to the dominant economic model of the time. I would argue that the model you observe today is an outcome of that idea, not an accident in the light of what may be read as a futile 'second guessing' exercise. 

You raise the ghost of QoS in your message. I am reminded of Andrew Odlzyko’s ( arguments at the time: the cheapest way to provision QoS for your customers is to buy more transmission capacity. True then. True today. CDNs exploit today’s environment of abundance of computing and storage to eliminate distance in communications. By bringing content and service under the noses of consumers we eliminate the cost and performance issues of accessing remote services. The service outcomes are faster, cheaper and generally more resilient in the CDN world. The “public” world is now in the throes of the death of transit and the public network has shrunk to the last mile access network. Why? Ultimately the answer is "It's cheaper this way!”. The industry is not going to head back to the rationing world of QoS anytime soon, if ever, in my opinion.

So why do we even need unique addressing any more? Surely all I need to do is to distinguish myself from the other clients in the service cone of my local CDN. Why do I need to use an addresses that distinguishes me form the other billions of client endpoints? Is it for the few residual applications that have not yet been sucked into the CDN world?

[DOT] Wasn't the Internet one of the 'few residual applications' that wasn't adequately served by the model at the time? So yes, *I* do want it for the few residual applications NOT being hosted in a CDN. Why? Because the most dominant application (for some, for me, maybe even for most) in a few years may be JUST that residual application. Do I know? Well, would I have guessed that people spent tons of time uploading selfies of themselves in front of landmarks I can see properly due to their large faces in the way?

 The issue here is that uniqueness costs. And why should I spend a disproportionate amount of resources to support a function used by a residual trace amount of traffic? Sooner or later I will cut out that cost and not do it any more. As the CDN’s continue to exploit the abundance of computing and storage the current shift of more points of presence positioned ever closer to the end clients will continue.

There is also a second factor, that of sunk cost. Nobody wants to pay to upgrade existing infrastructure. Nobody. So those who want to change things build around, over and tunnel through existing infrastructure. In a deregulated world where piecemeal uncoordinated actions predominate, the level of coordination and orchestration required to uplift common shared infrastructure is simply impossible. We say to ourselves that we outgrew flag days on the Internet many decades ago, and thats true, but at times we appear not to understand precisely what that implies about today. We have built an application-based superstructure of encapsulated tunnels in the network (QUIC) that neatly circumvents the entire question of infrastructure renewal. Whereas IPv6 has been head-butting against the sunk cost of existing infrastructure for more than two decades then dramatic rise of QUIC, BBR, SVCB and HTTPS, and similar application-level technologies attests to the application world’s extreme distaste to engage with the existing infrastructure.

[DOT] Much of your statement do remind me of 'nobody wants to change' arguments heard elsewhere, not just in the communication industry. I fear that the Internet's in danger of experiencing the innovator's dilemma that has befallen so many other industries and their players before. Repeating arguments that may well have been formulated the last time around is one aspect of it. The question comes down to what the IETF feels should be its role in facilitating innovation beyond what we can see today. Maintain and improve (engineering towards) the status quo? More importantly, should this role also guide its thinking towards the future?

For me the question is not about IPv6 any more - that is largely a question whose answer really has little of industry relevance to offer. The question is more about the CDN world and the way applications create their own environment in a manner that is as disengaged and isolated from the underlying infrastructure as possible. (and if you think about it that is a pretty exact replay of the way IP’s stateless packet-based hop-by-hop forwarding treated the circuit-switched telephone infrastructure a few decades ago! What goes around, comes around!).

Then, as now, the issue was NOT “What’s the answer?” but “Whats the right question to ask?” - at least for me.

[DOT] You may notice that this question was asked as the third in a series of questions on the INTArea list, starting with 'what do we want from the network', which may be closer to what you consider the 'right' question?



Int-area mailing list