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

Adrian Farrel <> Wed, 26 January 2022 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D8D63A0CC4; Wed, 26 Jan 2022 08:27:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WmWL4Ccd77Kc; Wed, 26 Jan 2022 08:27:11 -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 D397B3A0CC8; Wed, 26 Jan 2022 08:27:10 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 20QGR78I012576; Wed, 26 Jan 2022 16:27:07 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 37F1C46043; Wed, 26 Jan 2022 16:27:07 +0000 (GMT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 20EF04604B; Wed, 26 Jan 2022 16:27:07 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS; Wed, 26 Jan 2022 16:27:07 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 20QGR2rP029811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jan 2022 16:27:04 GMT
From: Adrian Farrel <>
To: "'David R. Oran'" <>
Cc: 'coin' <>,,
References: <> <>
In-Reply-To: <>
Date: Wed, 26 Jan 2022 16:27:00 -0000
Organization: Old Dog Consulting
Message-ID: <01ae01d812d1$8e6a36e0$ab3ea4a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AF_01D812D1.8E6CA7E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIrp5NUZpELGwOzM6ts/KvwGoi/oAF6tzdtq8J4ZBA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--6.860-10.0-31-10
X-imss-scan-details: No--6.860-10.0-31-10
X-TMASE-Result: 10--6.860200-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/xIbpQ8BhdbI61Z+HJnvsOkyKfhe0n3T2YeMTPaAHLLRFp tnr5l9Mi6lHZnkJa/VS25WIsdFfJGLKRmD27FFbq3nHtGkYl/VpIwovbX4T40OjMOEZ5AL0SsGA 1p74N3HXoI1jVOJ7e+Brr9rNMtgFT9le5XmUu9sBlI0vGyCjKv+IHwuSQU/r1teXjSBMYnmnl5C QXJ/1hHu4SW0N6QG4GCPRWzGbPmg7nyYsUXqFB8NB/IoRhBzVHoSDNlS6ABdf3rn0H78fXLNSLO Rr4Zhm8aiz3Dq8BYk7f29Smj6mdeOlVmb365UrbEVuC0eNRYvJ+0wZAOyZD1eWR07sSEnVAttNu UtVl2iy3swU7n/y13cfaZidVO+Tab15li10waDc0OtJVkKBtK+Ltjpr0h0cPKgGZaOQty4smFX0 89bePLK1u9NkuhgWrmFJ3RCBrPkJTvU6MzYfQNlXaU23cJsN3i+TAnPnbttg/+aUwNH0c1E+GBn Vm/sr7LluBF7lCexmBkIVKaxoItaEiiWmjr2gp/rf6exgxE+zbLuvAgD3xvBHfiujuTbedDpbrd hcd5/kobcIkx0DPUm47T1dOIME7Q8+LSipOfwSyaXLtlwnZHBmyTBaqiJvcVsObDLfVQsTDRvew 35mZe2zOwRQPV39zTWyZ6ygxlw0/QMF1B4qVfQdHNpBuxrOof6iC0fNopZkMR2L8iw5VqsZLv3M /59Rrg1GDbz/njaO5SMKXxCE4WXCbAkrOahe8cfsdX+Y7hRNZoq85oEW2FARiALQ52CfCTkg03y bTpsgoX06X6D5QMjDrUrwiy0HrNBtwY9jrji6eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKRC8pCQ VlPxVKMqIeOstifkU6UkIr/V+0fDJEoDuGx1v5edtI0DUmPDaJ0qORF1GIt6BLEnwhIK8Fg8J3H OCouGAYhnmiuMRd+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Int-area] [Coin] Fwd: [arch-d] 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 16:27:17 -0000

Hi Dave,


Thanks for forwarding to COIN (and thanks to Marie-Jose for flagging the overlap). As with all these types of thread, it is hard to know where to send responses, and we end up copying an ever-increasing set of mailing lists. Truly sorry for that.


Dave, I think you are right to distinguish the overlay and the underlay. I think it is important. I believe there is a difference between determining the next consumer of the packet (not necessarily the destination, but possibly an on-path value-add function), pre-selecting paths or pre-established tunnels, and choosing the next hop forwarding path.


Semantic Routing [1] is principally concerned with the last of these. That is not to say that ICN, overlays, etc. are not valuable tools. Far from it. But we wanted to look at the hop-by-hop behaviors commonly known as routing or forwarding. And while these approaches are applied per-packet they are essentially per-flow tools answering the question: how can the packets of this flow be best routed through the network to meet the demands of the flow.


Historically, there is a lot of overlap with traffic engineering and “policy-based routing”, and there have been very many attempts at an approach over time, usually targeting a specific use case or network type. So we want to see whether there are trends, common threads, possible generalisations, and big holes not being considered properly. For the last of these, we have tried to put together a list of things that should be considered in research into routing and forwarding [2].


It is definitely true, as you note, that a forwarding device can be programmed centrally (in an SDN sort of way) to apply specific forwarding policies based on the information carried anywhere (accessible, i.e., not within the encrypted part) in a packet. That is not enough, however. The fields in the packets have to set consistently, and there may be the need to carry further information in the packets. Furthermore, a lot of care has to be taken about consistency in forwarding policies to avoid loops or packet loss. And, of course, the forwarders have to have a consistent view of the network (which may include additional information about link/node state and capabilities) if they are to behave correctly. I suspect we forget just how fragile a large forwarding network can be.


Thus, an SDN approach is not the only approach to Semantic Routing. One might also consider pre-programmed algorithms (as has been the case in routing for a few years) or algorithms and policy distributed horizontally (by the routing protocols) rather than vertically by the controller.


I suspect none of this is news to you, but it nevertheless seems to be missing from a lot of research into the topic.


Maybe, however, there is a line to be drawn between engineering and research. When you say “I am still befuddled about why one would want this capability in an underlay,” I think the answer has to be that that is OK. The whole point of research is to find out what works and what might be useful.










From: David R. Oran  <> <>
Reply: David R. Oran  <> <>
Date: January 26, 2022 at 10:37:00 AM
To: <>   <> <>
Subject:  Re: [arch-d] [Int-area] Continuing the addressing discussion: what is an address anyway?

I wade in here with more than a little trepidation, especially with my “ICN taint” where there are no classic “flows” and in fact no source addresses to apply semantics to, and only weak notions of destination addresses in the sense that content names at layer 3 may have a binding only to a single location in the network because that’s what you wanted when you constructed the name.

After reading the semantic routing docs, I am still befuddled about why one would want this capability in an underlay when it is already very common to employ a level of indirection by recursing at layer 3 to construct flexible overlays. One might want semantics other than an attachment point in an overlay, but we already have that, and can similarly recurse existing routing protocols to construct the desired topologies. So, I’m in the uncomfortable position of not seeing the need for any of this either as a native IP capability, nor going forward as an alternative to architectures like ICN which natively provide flexible semantics through the use of hierarchical or attribute-based names at L3.

If the goal is to try to decouple the IPv6 packet format from conventional notions of forwarding and routing, given the movement toward user-programmable switches and routers, we can do that without introducing the notion of semantic routing. As a extreme endpoint of this argument, consider the following:

*	Programmable switches can do match operations on any set of contiguous bit fields in a packet if they are in the first 256 bytes of the incoming buffer.
*	The extracted and matched bit fields can be used as input to a lookup table, or a cascaded sequence of lookup tables, or even something with FSM computation as long as the cycle count and memory accesses are highly limited.

Given this, there is no need, other than for standards compatibility, to assign any fixed semantics to ANY of the fields in an IPv6 packet, be they the “addresses”, the hop limit, ports, or anything else. In fact it may be that the only thing about the overall packet structure that demands precise standardization is how you demultiplex incoming frames/packets to the program that is assigned to handle them. Then if you don’t want to have source addresses and want to treat the concatenation of SA/DA (in any order or even segmented in pieces) as one single key to the forwarding operation, that’s just fine.

In this “endgame”, both routing and forwarding is simply defined by the program (or programs) you load in the devices. There’s no need to have conventional “protocol standards” beyond agreement among packet generators and packet parsers as to what the format of the packet is. IPv6 is just fine for this - there are enough bits to do a lot of stuff, even ICNish stuff as we’ve seen with the hICN effort ( <>

I don’t intend this as a flame; I’m seriously skeptical of the utility of using protocol standards as a way to achieve different routing functionality given where the technology is today and where it’s moving.


On 26 Jan 2022, at 1:24, Eliot Lear wrote:

[copy architecture-discuss]


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?


On 25.01.22 12:38, Geoff Huston wrote:


On 25 Jan 2022, at 6:19 pm, Dirk Trossen  <> <> wrote:
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.
Int-area mailing list <>

Architecture-discuss mailing list <> 


Architecture-discuss mailing list <>