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

Geoff Huston <gih@apnic.net> Wed, 26 January 2022 19:35 UTC

Return-Path: <gih@apnic.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18E43A1D43; Wed, 26 Jan 2022 11:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp17SLFkaxzw; Wed, 26 Jan 2022 11:34:59 -0800 (PST)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01on20631.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE433A1D45; Wed, 26 Jan 2022 11:34:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZLlWS8SDJye4HJg9JDH8yaCflowH23UZcywNwo8n6KeDIvziVGqSphJB0Cfw4QJ6XvR+S2IZRcC/T6afTVAJ7pPcTtC3MArfkR7bUyAdjvobhAJy5netvV5wOTVXNk74ILcGrPIWh7q/XpJ9rOfiCEuNcqgLw2Z5kAk+roNZHINmEVUFDw7US5Pkkavcfu1y0Z9Td+jPFh75of9WUmJA/1ZU5M6cj/1JDiWbdFM5iU3vix7xcVW+fT6ZJve+2CHhsTUksujpZ9NCKldMXafBtcaFAq/MS56KsR06uVCi0Rq4JtuLoYIIOkBUIYKfj1hq75DIFRRCHTU0vMp6uv1lbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i8urbDIlIX1I1jaNLc53nyrlG2/agk2B8nxs2VsnXfg=; b=FZdfpLYqdE2e3M/nPMwwavxuKlf+r5EVg/1ndZr75o34VCXkDw0GsAgbAUEIAGqX7zrRZvgbi8QDtCChgcs+87wZU2sHzjbK6nKpFCLBzahJ32uDZTTNOxhF/iEstzYuYRMsJk4CB9iAGsgELOAynOh4CdiIIUSH4qRLAYTx7XWrkvc4DTBchascuXK5T7gbPElXHAYiMtoSKdthdGBPyKkQaYBA1xg5Cw6I5H6qKdeIrPd7qhw6XunDGEPXiYV4eumXBTGUZQGYAQFovJzqy0CKQIrRLq8cjf6nRM5/qu1dv/o93HBsbq5sJC1Rn3/5PdDUGClLPMBXMVkyXpvi8A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i8urbDIlIX1I1jaNLc53nyrlG2/agk2B8nxs2VsnXfg=; b=D5i6OJaiE2uYlg5AzFhEegmivI7YHYMpTzqEsV3H3ZrSurkbetxvmz7VYFd8WLklVgQOPI0A2ZImCYtUOl9KQ906LLmef5qfwj1bhiwlwbsveEN6KwhC5JC0gZN2iZ3O2+2Eu4bTESu7r5qn9RSCcOLxrvTXsl+XEWz6eSuaLfA=
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by MEYP282MB3595.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:179::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Wed, 26 Jan 2022 19:34:50 +0000
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::4947:7cc4:5d71:b148]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::4947:7cc4:5d71:b148%4]) with mapi id 15.20.4930.017; Wed, 26 Jan 2022 19:34:50 +0000
From: Geoff Huston <gih@apnic.net>
To: Eliot Lear <lear@lear.ch>
CC: "Int-area@ietf.org" <Int-area@ietf.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Thread-Topic: [Int-area] Continuing the addressing discussion: what is an address anyway?
Thread-Index: AdgRu64YB5eA1MJiQEiPQSsbU7BQswAJFf8AACdWp4AAG5n8AA==
Date: Wed, 26 Jan 2022 19:34:50 +0000
Message-ID: <D01FC5EF-95E3-4B56-B438-300FC89EAF37@apnic.net>
References: <57c643c667d94a77b9917bb17dc142a5@huawei.com> <D9F21BA9-4EFC-4AFD-8C91-B411A3289734@apnic.net> <c4ec1cce-b754-0d85-6abe-1d065349bc7f@lear.ch>
In-Reply-To: <c4ec1cce-b754-0d85-6abe-1d065349bc7f@lear.ch>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3693.40.0.1.81)
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 001c8d7d-a578-4094-a123-08d9e102eb8c
x-ms-traffictypediagnostic: MEYP282MB3595:EE_
x-microsoft-antispam-prvs: <MEYP282MB3595A3D34FE66EED3F45915FB8209@MEYP282MB3595.AUSP282.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lFF0r+toLx+xQiwFhVTlwGHXR//B7hC0xreoSBmVYJftPFc9dMPetJe2AxeURYr+XmLAYbxpwGJyiGvsVsGGwhMLxmKdCjovi2G9eNTTnoxal9gKSwbtDxzLrkzfFwkfBjqxvsq6RZq8Vem5IhTmxTuZEJCbyBzRhizkzGPtsvJnhpoGWyLLw/J+9siBHVAMOxDY7ah5FFv1lghxvfE6FQsuAJOadNBSxdzw7cRIWBzhYlVHAEKQlJEspDcGLzAlrcn8D0Q9SmV8tt7bALjJYnm+e3sZAgf2OeWfdG2JJwD2OmfzBENuvWlOMS7SfJwabMKDbiqiVW8mqGWITIwEa480vPAeTBknOARWiBzLXyNEyIyg20Xw0YEw3p8EwItPNhQevnsyAFfzOkVvFiENq3Vcsmteuk5nqXGCrH/hWeZSXuLDUleqwdjBFn0/xKPL3qxh3L37ncVh+welmXylsjv/pwhUyRZU6uYvimgCJ3i7nA3ijm/yXHLHvORQAQ7hk8LnQHrRzKjNcVb9S+3wMJr3Gy1DW2ojVojRx210wGOVrWu/PMogh1caRW7+Q/AJTPmMjegDsl4uU1djuV0sVkHBEr62mada8tc3+VaJTOsGDioLF0qhlINeBQdarMzO+X3AZ4wNTlatL8ZB7w35pKrGnmjaUoFeeZ+kUDf4jwzNGM+3Bsc+srwhoFw9+88aR6b7q2xlY3o79HCHpr74EZPMGk/pyhp2Zp/oSRisuN7v90nE03H6yRUZlgMf0IITMZCoGhQwnSokGsUvIMulypU1+GoR+FTo7Q8iYR9Gs6hkO+IcpA5lxB3CCJr2ZorIJRedEFOapCtm8rI3FtSX5w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(376002)(396003)(346002)(366004)(136003)(39830400003)(83380400001)(508600001)(36756003)(66476007)(54906003)(66574015)(6486002)(71200400001)(316002)(186003)(6916009)(66556008)(66446008)(64756008)(33656002)(76116006)(66946007)(2616005)(38070700005)(53546011)(86362001)(122000001)(6512007)(6506007)(4326008)(8676002)(5660300002)(38100700002)(8936002)(2906002)(45980500001)(20210929001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 9LE2cNtVyHVYY3jet8vGN908rls9p+Orx1YpZwKhBB7eEw11Y5CBGTOAmZAUXGhNETvlS79L5AAdoMqhAGn9kUgIYIz548Vw2/mDidm8u8kGajFcCJwrk+B6reGFEAEIR26Dq3xLQvc7WvpwS8RwXTngdHrbW+6OQH6RK7nrJ2kTouZyLs/WyJNeAJukpWsBhKShU0EVszYjNS9CmMQN9Tp5K8OvvABfMbmJK47jn4hu8K79Kwgxq3QwXICjk+xG2JE/SNkVAAiaWYSeyov/pLTu2Cvd+uZ0hogL106KuFUjpMsASr4ghnsM9M9Q0K6MJJ74Ifxu7iNKsMwwq6q682JlD3AoNotOenHc8/bCl2qnlObd558N+XRT+AGh0kFwxLc5s0iscaA8Am/Sm035tnF3aZl7N4JNBrJ2VFZOEN+8mRSyI1sR0fVbvIwK7v9MufNYPl3/hT/+aJGcLP2TV43P3i/O63rwQ9e6clHv8kNIn4OhVK8uWHgggLPbdkbnNizYjxej2b7iFeaoXLhYht7GrKCtFr59eY+kNbbtXN6EQXe8Z4Kzm+B0Z/DoirD2JGYsCmOMvLSRHwftQGqFQtNjGfVb3iae47KToMWCO9pbiZd7DnDt0vt0B0YvMJEswRrjA76ePnmjie982UVbV4kDcdNgqcvO4GF+VJ8E9kattmGZjE5vtA9/IykHNGz0jf/17gSy6bCDQVpsDLCWFHsRT+30TVJUAwNG7aQHVT4k1JOV1U/7g9LQPdO2zidzL+qq4aoEuTbU9ixEilIin2tdApbZGFozgYREM0nUOB5RpbInpnO0TsaDehoZsNHXoXyZAbY8PV+s48d7HCas4uiKSY3LICCiUb0iy0PxIpV1ZtscG5G4V2GoL21ujxrGrzA2kNYJj1lSH/yI7V/0SAaHW8jrWIGdAFIBfOYTQOSVH5DBnW6Hg5exCe0zgZ2ipBxvZ8MobUvEszjjCnbVDSheqYG+5Oi7Rjt3NnVzM46owoytfNg6zZvXV3vM+YaWVdxDhBqFQMf5iZrm46H7SJ3XESDOXV6bf+ipab1rtGJ1Ad9Tng7yKSvfy2Y5l9nl7sbA5zjY+NCJ5xYrpMtOEYHPXyF73xFM0uTgCjMKtyChSay1J+R49jcI6LGwOqtBWGjdjPCi3MVFoCSuZmAbiPKqJpzI92P25djgMyyTzurGVIXW2EUVUC1ki4ADt/pAy15UE/nQHpPeuHceqDbp2QA1KxBj+nkhE80Gr+ppLtinfDfxjDM5RJDY+haH2d2FFAEYT4ms6/JNZM0eTu48PjmFCVuTIQmxWoy0cMX5SAkTlz6gNRW+S7wdhGk4qwT3So9gofEjHZUvDDLGkBO6vN038V8JZHmmkq19oC3kF5A1CP9DMx7SU1UW7L1+7VwZiMeyIC/17jbG/LYocP0Dz8HjjmadsrnARlPPGZDJhf9MTa7Yi1qjlTyU4Drv1deF38et7rcxaSRYP5jiIUG9jKu+jOaS0FoTnTx/Ezihknv2Q3TYvpEM548fON7k4Oyyz0F9O7Si4yDvH09uU290LRQrZA3oZlfXzqk/kbb+3uNfxlXCNZes2VkDVrCM/G5lCPFHvWuUM9SB7KUP0HOuS/nGM0stNfe/oAWUSSxG1NrPw8b16lKhtn8VgpPm1M01
Content-Type: text/plain; charset="utf-8"
Content-ID: <965AA8A75E0ABF4B80CFD1AC5708669A@AUSP282.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 001c8d7d-a578-4094-a123-08d9e102eb8c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2022 19:34:50.7057 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FqrMdieaQPEa+iHvbwwdGD6uxo/5M4/sQiybh6J/oMC9u3js44heppJfK7Cy6xgp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYP282MB3595
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/szViUC6pumTk-_VFQ73p4SL6zso>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2022 19:35:04 -0000

> On 26 Jan 2022, at 5:24 pm, Eliot Lear <lear@lear.ch> 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).

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