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

Antoine FRESSANCOURT <> Wed, 26 January 2022 10:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A60993A1550 for <>; Wed, 26 Jan 2022 02:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b_xWLopQuT6f for <>; Wed, 26 Jan 2022 02:32:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E249A3A2EF2 for <>; Wed, 26 Jan 2022 02:32:15 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4JkKfx4YH9z67wkW for <>; Wed, 26 Jan 2022 18:27:53 +0800 (CST)
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; Wed, 26 Jan 2022 11:32:12 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 26 Jan 2022 10:32:11 +0000
Received: from ([]) by ([]) with mapi id 15.01.2308.021; Wed, 26 Jan 2022 10:32:11 +0000
From: Antoine FRESSANCOURT <>
To: "" <>
Thread-Topic: [Int-area] Continuing the addressing discussion: what is an address anyway?
Thread-Index: AdgRu64YB5eA1MJiQEiPQSsbU7BQswAJFf8AAA3yeIAAAo9agAAD6HeAABqluJA=
Date: Wed, 26 Jan 2022 10:32:11 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, 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: Wed, 26 Jan 2022 10:32:21 -0000


The discussion reminds me of several points made in rather old articles questioning the notion of addressing and the relationship with naming. 
-  Hauzeur, Bernard M. "A model for naming, addressing and routing." ACM Transactions on Information Systems (TOIS) 4.4 (1986): 293-311. (
- Chun, Woojik, Tae-Ho Lee, and Taesang Choi. "Yanail: yet another definition on names, addresses, identifiers, and locators." Proceedings of the 6th International Conference on Future Internet Technologies. 2011. (

I enjoyed those articles as they give a clear definition of naming and addressing, and define and address as a mapping to a specific location of an object relative to a potentially dynamic topology. Those articles are clear about the fact that an address should be dynamic if the topology in which the object lays is dynamic, because addresses only make sense relative to a topology they are used in (and should be optimized to allow locating an object efficiently in this topology). 

In today's internet, the topology as viewed by an entity is dynamic relative to its location because depending on where it sits, on which privileges it has and on network functions that are running in the environment, it views some part of the network as a single changing address hiding parts of an infrastructure by means of a dynamic NAT or has access to enhanced services addressed using a semantic address, thus making the address more specific than the usual host/interface granularity in IP.

Several Future Internet projects have proposed ways to enhance address's semantic to allow specific entities to be reachable in the scope of the objectives they wanted to achieve, and the IP limitations they wanted to tackle. 

In the discussions that are ongoing with regards to addressing, I really enjoy the fact that, in semantic addressing, the structure of an address can be used to convey information that can be used to route network packets in network topologies in which some elements don't need to know about every details of the services or concepts used by other nodes.  Giving an enhanced structure to addresses relaxes the load on the mapping function in the network. Indeed, if the address carries no semantic whatsoever, then if we want to deploy a specific function (possibly on a session basis) to be accessed by a given node, then this node needs to be given a very specific and dynamic semantic-less address while the context of his request should be passed while asking for a mapping. Such a dynamic mapping can be done, as Cloudflare has shown in the paper they presented during the last SIGCOMM conference, but it puts the complexity burden on the mapping function in the network, and it is done in a relatively small environment. 

Best regards,


-----Original Message-----
From: Int-area [] On Behalf Of Tom Herbert
Sent: Tuesday, January 25, 2022 10:23 PM
To: Geoff Huston <>
Cc:; Dirk Trossen <>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

On Tue, Jan 25, 2022 at 11:30 AM Geoff Huston <> wrote:
> > On 26 Jan 2022, at 5:17 am, Tom Herbert <> wrote:
> >
> > On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston <> wrote:
> >>
> >>
> >>
> >>> On 25 Jan 2022, at 6:19 pm, Dirk Trossen <> wrote:
> >>>
> >>> All,
> >>>
> >>> Thanks for the great discussion, following our side meeting at IETF 112, so far.
> >>>
> >>> I wanted to turn the discussion to a key question which not only arose in the side meeting already but also in the discussions since, namely “what is an address anyway?”.
> >>>
> >>
> >> In this world of NATs it seems that we treat addresses as no more than temporary ephemeral session tokens and we've passed all the heavy lifting of service identification over to the name system. These days you and I could be accessing the same service yet we could b e using entirely different addresses to do so. Or I could be accessing the same service at different times, and again be using different addresses each time. I find it somewhat ironic that we see increasing moves to pull in IP addresses as part of the set of personal information in some regulatory regimes, yet what the larger network sees of end clients is a temporary NAT binding to a public address that may be shared by hundreds if not thousands of others.
> >>
> >> And IPv6’s use of privacy addressing achieves a similar outcome in a different way. And QUIC’s use of the session token inside the encrypted envelope even makes the binding of an address to a single session fluid, as the same QUIC session can be address agile on the client side.
> >>
> >> So perhaps an address these days is just an ephemeral transport token and really has little more in the way of semantic intent.
> >
> > Geoff,
> >
> > That might be true for QUIC, but not for TCP. Each TCP endpoint 
> > requires stable addresses for the lifetime of the connection since 
> > the addresses are part of the four-tuple identifying the connection.
> Tom,
> I think you may have missed my initial characterisation of IP addresses in your response: "we treat addresses as no more than temporary ephemeral _session_ tokens” i.e. the NAT model relies on session level stability of the NAT association.
> My comment about QUIC is that the QUIC protocol does not even require that session-level stability of address association, and QUIC sessions essentially require stability of association only on a time basis approaching the RTT interval.
Yes, but TCP doesn't have those properties so we are bound by that at the least common denominator on the Internet until TCP is obsoleted.

> If you wish to construe various judgemental observations (Like "NAT is evil”, “NBATs break stuff”, etc,) feel free, but they are your constructions, not mine. The issue for me is not judgments of “good” or “bad”, but simply to explore, without overtones of judgement, exactly what an IP address represents in today’s Internet.
I'm not sure how I was making a judgment, NAT devices do factually and transparently break transport layer connections when NAT state is evicted, packets are rerouted, or network devices crash. Any discussion about what addresses are in the current Internet has to include this consideration. My point is that there are host requirements relating to addresses that the network must be aware of if it is applying more semantics than just for routing (this probably degenerates to the age-old problem that IP addresses convey both identity and location).


> Geoff

Int-area mailing list