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

From: Dirk Trossen <[email-masked]>
Date: Tue, 25 Jan 2022 07:19:44 +0000

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?".

It seems that any answer would very much depend on the viewpoint of those wanting to answer the question (e.g., application vs network view). At different layers and different parts of the network, addresses may have different purposes and (desired) properties. Hence, scoping the possible answers is key, so let me try to do so.

Our discussion in the PS/GA drafts has been focused on Internet addressing, so scoping the wanted answers to an "Internet address" seems obvious. But our discussions so far also suggested that wanting to understand what we (as users) want from the network is a key aspect moving forward.

Hence, I would suggest that any answers to the question above ought to be guided by what we (as users) want from the network, e.g., in terms of reachability, privacy, security, exposure of desired capabilities and possibly more.

With that in mind, please let us know your views on this question in an attempt to tie our larger discussions back to the question on "addressing".

Best,

Dirk

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Jan 2022 08:46:13 +0100

Hi Dirk,

On 25.01.22 08:19, Dirk Trossen wrote:
>
> Hence, I would suggest that any answers to the question above ought to 
> be guided by what we (as users) want from the network, e.g., in terms 
> of reachability, privacy, security, exposure of desired capabilities 
> and possibly more.
>
The orthodoxy here is the seminal work of Shoch[1]. And of course 
there's Saltzer et al.[2]  The assumptions being made today by different 
players are indeed all over the map.  Routing is a function of the 
network.  Or is it?  Privacy is something the endpoint must manage.  Or 
is it?  So I like your approach for discussion.

Eliot

[1] http://www.postel.org/ien/txt/ien19.txt
[2] http://web.mit.edu/Saltzer/www/publications/endtoend/endtoendA4.pdf

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Jan 2022 11:38:09 +0000

> On 25 Jan 2022, at 6:19 pm, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 
> All,
>  
> 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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Jan 2022 10:17:29 -0800

> 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. While
the addresses at each end point of a connection may differ, they must
be consistent for the lifetime of the connection at both endpoints.
That's where NAT breaks things, if NAT state is evicted or lost TCP
connections routed through NAT are no longer viable, hence that's why
it's correct to say that NAT breaks the end to end model. TCP
properties also makes it difficult to change the addresses of TCP
connections on the fly for privacy, but giving each connection it's
own unique IP address is potentially feasible since there are no
necessary protocol requirements for consistent addressing between
different connections.

Tom

>
> Geoff
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Jan 2022 18:47:14 +0000

There is both a topological view of an address and a protocol view.

The topological view is some place in the network, be that a node or an interface.

The protocol view is that it is an instruction, for example to deliver the packet to the place identified by the address field lookup. In IP this was originally an interface somewhere in the network. In MPLS we generalised and abstracted this to make the label an instruction what sometimes said deliver the packet closer to some network object, but sometimes was an instruction to do something else.

In SRv6 they designed a hybrid of this with the prefix having the original IP meaning, and the suffix providing some other instruction together with some parameter such as send the packet to this VPN.

Thus in my mind the address field in a packet is an opaque instruction that is looked up in some large table and causes the forwarder to take some set of actions that are referenced by the table.

Stewart

> On 25 Jan 2022, at 18:18, Tom Herbert <[email-masked]> wrote:
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Jan 2022 19:30:47 +0000

> On 26 Jan 2022, at 5:17 am, Tom Herbert <[email-masked]> wrote:
> 
> 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.

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.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Jan 2022 19:41:49 +0000

> On 26 Jan 2022, at 5:47 am, Stewart Bryant <[email-masked]> wrote:
> 

Stewart,

There is an alternative view here that inverts this perspective. From the perspective of the network, a packet's IP address is a token that helps the network determine which egress interface is to be used for the packet to be kicked out of the network! MPLS, next hops addresses, encapsulation, virtual circuits are all somewhat isomorphic from such a perspective. The differences lies in the amount of work the network performs on acceptance of the packet. In some models it performs an initial lookup to select the egress point and then uses this initially computed egress tag to guide the packet’s journey through this network (MPLS, virtual circuits, encap). Other models, including hop-by-hop destination based stateless forwarding, perform this same egress point computation at every internal switching point.
 
My point is that the semantic construct of an “address” does not limit or predetermine which of these models your network must use, nor does a network’s choice of switching architecture necessarily redefine the semantics of an IP address.

Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jan 2022 09:03:34 +1300

On 26-Jan-22 08:30, Geoff Huston wrote:
...
> 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.

Right. And it's well understood that users don't care about addresses (unless circumstances force them to, such as instructions to browse to 10.1.1.1 to set up their new home gateway). I don't think much has changed since my rant 8 years ago (https://dl.acm.org/doi/10.1145/2602204.2602215).

It increasingly seems to me that what we lack is some kind of transaction 
identifier that can survive both changes of address and transport layer failures. Possibly this is what OSI called the session layer.
  
> 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 “…

I just reread RFC2101. I wouldn't change a word, especially this:

"Thus, IPv6 will amplify the existing
problem of finding stable identifiers to be used for end-to-end
security and for session bindings such as TCP state.

The IAB feels that this is unfortunate, and that the transition to
IPv6 would be an ideal occasion to provide upper layer end-to-end
protocols with temporally unique identifiers. The exact nature of
these identifiers requires further study."

Here we are.

Regards
     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Jan 2022 12:12:52 -0800

> these identifiers requires further study."

So if the IAB, or the community at large, feels that overlays cannot or should not solve this problem, then let's just go with 8+8, per Mike O'Dell, and move on. 

So what I mean is, lets make a decision. We have been filibustering this for 20 years.

I believe there is code in kernels for transport protocols to transport checksum on the low-order 64 bits.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Jan 2022 13:22:41 -0800

> 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 t…
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 “…
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).

Tom

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jan 2022 07:24:31 +0100

[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?

Eliot

On 25.01.22 12:38, Geoff Huston wrote:
>
>> On 25 Jan 2022, at 6:19 pm, Dirk Trossen<dirk.trossen=[email-masked]>  wrote:
>>
>> All,
>>

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 26 Jan 2022 09:21:07 +0000

Geoff, Stewart, all,

Linking in the arch-d list, following Eliot's intention to widen the audience for input.

Let me come back to your statement "My point is that the semantic construct of an “address” does not limit or predetermine which of these models your network must use, nor does a network’s choice of switching architecture necessarily redefine the semantics of an IP address.", also relating to ephemeral nature you outlined in your original post.

Key to me is at which level of the system the ephemeral nature you identified exists, which may help us teasing apart the different 'scopes' of what an address may be.

If I follow your alternative perspective below that "a packet's IP address is a token that helps the network determine which egress interface is to be used for the packet to be kicked out of the network ", then the question arises how much of an ephemeral nature we see in the relations between a client and an ingress. If most traffic goes to your closest CDN, you pretty much have a stable relation, while the ephemeral nature is purely one between the client and DC-internal service endpoints; QUIC's sessionIDs aim at that aspect, enabling transport-level connectivity changes (within the DC, e.g., for load balancing or resilience reasons). The work in SIGCOMM2021 on "The Ties that un-Bind: Decoupling IP from web services and sockets for robust addressing agility at CDN-scale" (https://conferences.sigcomm.org/sigcomm/2021/files/papers/3452296.3472922.pdf) build on this observation, leading to the radical notion that a single IP address may enough "to rule them all" (the web services). 

But what if there is an ephemeral relationship nature in the network itself? What if my intended communication partner may not be bound to a single location, even distributed as possible destinations over many? We have models like anycast that describe a relationship with a stable identifier, resulting in a possible ephemeral relationship with a choice of network location associated with that anycast address. But is that relationship ephemeral during a transaction or across several; I'd argue that the former is handled with approaches in QUIC? If it's the latter, do I agree on the resulting semantic, often found in anycast mapping, that it remains stable even across transactions? 

This brings me to Stewart's statement regarding "Thus in my mind the address field in a packet is an opaque instruction that is looked up in some large table and causes the forwarder to take some set of actions that are referenced by the table." and the nature of that lookup and action. It poses questions on how stable the table content is (i.e. how frequently will routing impact the result of my lookup for a given address, but also what is the result of that routing anyway?). 

Also, how simple is the lookup:
1. Is it a one-to-one mapping, leading to unicast choices?
2. Is it a one-to-many choice? 
3. Is it a one-out-of-many-possible choice, which covers the anycast choice above? 

This third choice has a raft of questions that also link the scope of the network choice with the semantic of the overall relationship the client may want to establish. In other words, is the choice in item 3 determined via routing, falling back to option 1 as a result of delivery, or is it random over all choices possible or using some other scheduling mechanism (e.g., RR, weighted RR)? How do I deal with affinity across packets if there is indeed a dynamic ephemeral nature? How do I deal with choices being made that may differ based on semantic meaning outside of the 'network location' choice, i.e., what if choosing a location depends on the service I'm invoking?

The choices, most likely, are accompanied by metadata enabling them. Do they form part of the address or are they just that, metadata? Depending on the choice of metadata, it changes the nature of the address in the sense of how packet delivery is done and therefore how a network node "addresses" the possible destinations. 

Best,

Dirk

-----Original Message-----
From: Geoff Huston [mailto:[email-masked]] 
Sent: 25 January 2022 20:42
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; Dirk Trossen <[email-masked]>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Stewart,

Geoff

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 26 Jan 2022 09:23:52 +0000

Apologies, the below should read " then the question arises how much of an ephemeral nature we see in the relations between a client and an egress ", of course.

-----Original Message-----
From: Dirk Trossen 
Sent: 26 January 2022 10:21
To: 'Geoff Huston' <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Int-area] Continuing the addressing discussion: what is an address anyway?

Geoff, Stewart, all,

Best,

Dirk

-----Original Message-----
From: Geoff Huston [mailto:[email-masked]] 
Sent: 25 January 2022 20:42
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; Dirk Trossen <[email-masked]>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Stewart,

Geoff

---

From: Antoine FRESSANCOURT <[email-masked]>
Date: Wed, 26 Jan 2022 10:32:11 +0000

Hello,

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. (https://dl.acm.org/doi/abs/10.1145/9760.9761)
- 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. (https://dl.acm.org/doi/abs/10.1145/2002396.2002399)

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,

Antoine

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

On Tue, Jan 25, 2022 at 11:30 AM Geoff Huston <[email-masked]> wrote:
> > requires stable addresses for the lifetime of the connection since 
> > the addresses are part of the four-tuple identifying the connection.
>
> Tom,
>
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 “…
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).

Tom

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Jan 2022 19:34:50 +0000

> On 26 Jan 2022, at 5:24 pm, Eliot Lear <[email-masked]> wrote:
> 
> 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).

You raise the ghost of QoS in your message. I am reminded of Andrew Odlzyko’s (http://www.dtc.umn.edu/~odlyzko/) 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? 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.

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.

regards,

   Geoff

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 27 Jan 2022 07:51:32 +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.

Best,

Dirk

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

Hi Eliot,

[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. 

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.

[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?

[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?

regards,

   Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 27 Jan 2022 12:02:01 +0100

Hi Geoff, Dirk, 

I  wanted to add a couple of comments on your excellent points, see inline.
 (trimmed a little bit of the text)

Ciao

L.

> On 27 Jan 2022, at 08:51, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 

[snip]
> 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 i…

This last point is tackled in the current set of documents and also touched in the previous thread (but can certainly be improved upon this thread).
I think that we are at the stage that _no_ there is no strong reason yet to upgrade the existing infrastructure (we do not even know to what to upgrade). However, the innovation is there and is happening, raising the question:

- Up to what point we can “build on top” without risking to jeopardize the whole?  

In the long run, up to what point we can continue the way we are solving problems today? Seeing this as a possible risk, I would prefer to discuss now about what can be done (including the “is it worthwhile?” question). Up to us to answer this tough question and engineer an improved architecture that provide sufficient  benefits to be adopted in less time that IPv6 adoption.

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

Isn’t what we are trying to do here? ;-)

I think that the discussions happening in the INTArea mailing list are very fruitful. We just need to capture the current understanding in the documents, trying to formalize the problem we face.

As other already mentioned there is an architectural discussion to be made (and happy that the architecture discuss mailing list is in this thread), but we need to start somewhere and addressing is a good starting point.

What we need is to gather the experience each and everyone of us can provide in order to shape something meaningful to move forward…..  starting from the addresses ;-)

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 28 Jan 2022 12:48:59 +0100

Sorry, I  take advantage of this valuable public conversation between
you to mention a point that might be related.

Le 25/01/2022 à 20:30, Geoff Huston a écrit :
> [...] 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. [...]

Without jugding, and without thinking others might judge, i.e. to
qualify as 'good' or 'bad'.

I do think there might be value in questioning whether there might be
something inherent in the IP addressing system which might lead to less
positive consequences.  It is a question on the cause-to-effect dynamics.

What in the IP addressing system makes it possible that NAT has been
designed and used largely?  Lack of space in v4 - ok - but is there
anything more to that problem, now that IPv6 solves the space size
problem?  Is the fact that NAT kind of probably protection is helping?

For example, if the IP addressing system had variable length addresses
(instead of fixed length) - would that make the translation process of
NAT be unacceptably long, and hence no NAT would be feasible?

Other than that, what other characteristic of the IP addressing system
might have an impact on the existence of NATs?

What other characteristic of the IP addressing system has no impact at
all on the existence of NATs?  I.e. one could change that characteristic
but NATs would still be designed.

Other than NAT and IP addresses, there are other aspects of the current
Internet addressing that are less desirable.

For example: the open Internet and its open addressing system leads to a
need of privacy respecting for the individual; which is good.  At the
same time, the new privacy rules are not making everyone happy.  Some
times it goes to large extents.  For example, some addresses of web
sites are not visible to others _because_ of that privacy ruling.  Not
all websites in all countries accept to abide to the privacy rules of
other countries.  Such websites refuse to abide and block access altogether.

That situation is clearly against the openness of access in the Internet.

It is not a matter of paying money or not to access data.  Even if one
pays one is still not given access because one is situated in a country
of a particular privacy ruling.

It is a strange situation in which the ruling of privacy is not
accepted.  Those sites who do not accept to deliver data according to
the privacy rules do so not because they dont agree with a general
principle of privacy, but because they dont agree with that particular
ruling (GDPR in this case) of privacy.

What is at fault for that situation?

Is there something in the Internet addressing system at higher layer
(above IP) that might be qualified as being a little bit in error for
that lack of access?

For example, if the 'cookies' used by HTTP involved host names (host
names are also a sort of addresses) whose structure was agreed locally,
then there would be more positive view of the generally negative view of
'tracking'.  For example, a locally agreed way to identify people is
generally accepted (license plates, faces, more) but a universal way of
identification (hostname containing 'Windows' characteristics) might be
less accepted.

Alex