Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
Eliot Lear <lear@lear.ch> Wed, 26 January 2022 06:24 UTC
Return-Path: <lear@lear.ch>
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 2A08F3A26CF; Tue, 25 Jan 2022 22:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 0Ya-NCTs62_d; Tue, 25 Jan 2022 22:24:46 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 6F97D3A26CE; Tue, 25 Jan 2022 22:24:42 -0800 (PST)
Received: from [192.168.0.227] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 20Q6OYti180244 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 26 Jan 2022 07:24:34 +0100
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1643178274; bh=/WKqb2F3nh5ofYC5XSsDcdLaYpLOLX+eOO7gyD0VZ5c=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=DVfTWN7I07cG25a16K5XsMuIU/O5TZpRotS43QIs47ODD+Y1qST28LlB4RdrKtxT3 Nhrlur4X/FZlJ1hHIc9jYDnsa36n1x67Y8JP0TlyEMDmprDr5DGh3pMKBcSKy7MTKC gXgyeGSUxPTHn6WhZ3DDYPDxGYt2mVsrEtEK3Ee0=
Message-ID: <c4ec1cce-b754-0d85-6abe-1d065349bc7f@lear.ch>
Date: Wed, 26 Jan 2022 07:24:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: Geoff Huston <gih@apnic.net>
Cc: "Int-area@ietf.org" <Int-area@ietf.org>, architecture-discuss@ietf.org
References: <57c643c667d94a77b9917bb17dc142a5@huawei.com> <D9F21BA9-4EFC-4AFD-8C91-B411A3289734@apnic.net>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <D9F21BA9-4EFC-4AFD-8C91-B411A3289734@apnic.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------aEMquQrqXRVbneHkvm3DThwu"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/eMrAJIwGZ8IHiqAaz71T_-LViNU>
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 06:24:51 -0000
[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=40huawei.com@dmarc.ietf.org> 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 > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
- [Int-area] Continuing the addressing discussion: … Dirk Trossen
- Re: [Int-area] Continuing the addressing discussi… Eliot Lear
- Re: [Int-area] Continuing the addressing discussi… Geoff Huston
- Re: [Int-area] Continuing the addressing discussi… Tom Herbert
- Re: [Int-area] Continuing the addressing discussi… Stewart Bryant
- Re: [Int-area] Continuing the addressing discussi… Geoff Huston
- Re: [Int-area] Continuing the addressing discussi… Geoff Huston
- Re: [Int-area] Continuing the addressing discussi… Brian E Carpenter
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Tom Herbert
- Re: [Int-area] Continuing the addressing discussi… Eliot Lear
- Re: [Int-area] Continuing the addressing discussi… Dirk Trossen
- Re: [Int-area] Continuing the addressing discussi… Dirk Trossen
- Re: [Int-area] Continuing the addressing discussi… Antoine FRESSANCOURT
- Re: [Int-area] [Coin] Fwd: [arch-d] Continuing th… Adrian Farrel
- Re: [Int-area] Continuing the addressing discussi… Geoff Huston
- Re: [Int-area] Continuing the addressing discussi… Dirk Trossen
- Re: [Int-area] [arch-d] Continuing the addressing… Luigi Iannone
- Re: [Int-area] Continuing the addressing discussi… Alexandre Petrescu
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Meaning of Identifier, Locator, an… Joel M. Halpern
- Re: [Int-area] Continuing the addressing discussi… Brian E Carpenter
- Re: [Int-area] Meaning of Identifier, Locator, an… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Jens Finkhaeuser
- Re: [Int-area] Continuing the addressing discussi… Antoine FRESSANCOURT
- Re: [Int-area] Continuing the addressing discussi… Jens Finkhaeuser
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Antoine FRESSANCOURT
- Re: [Int-area] Continuing the addressing discussi… Antoine FRESSANCOURT
- Re: [Int-area] Continuing the addressing discussi… Jens Finkhaeuser
- Re: [Int-area] Continuing the addressing discussi… Alan DeKok
- Re: [Int-area] Continuing the addressing discussi… Toerless Eckert
- Re: [Int-area] Continuing the addressing discussi… Antoine FRESSANCOURT
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Jens Finkhaeuser
- Re: [Int-area] Continuing the addressing discussi… Bless, Roland (TM)
- Re: [Int-area] Continuing the addressing discussi… Templin (US), Fred L
- Re: [Int-area] Continuing the addressing discussi… Dino Farinacci
- Re: [Int-area] Continuing the addressing discussi… Jens Finkhaeuser
- Re: [Int-area] Meaning of Identifier, Locator, an… Dino Farinacci