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

Toerless Eckert <tte@cs.fau.de> Tue, 01 March 2022 16:42 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 428E73A0D28 for <int-area@ietfa.amsl.com>; Tue, 1 Mar 2022 08:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.117
X-Spam-Level: *
X-Spam-Status: No, score=1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=1.997] autolearn=no autolearn_force=no
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 U4SMJANmatCu for <int-area@ietfa.amsl.com>; Tue, 1 Mar 2022 08:42:10 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054303A0D1B for <Int-area@ietf.org>; Tue, 1 Mar 2022 08:42:05 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id ADA7058C4AF; Tue, 1 Mar 2022 17:41:59 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9B68C4EA7C8; Tue, 1 Mar 2022 17:41:59 +0100 (CET)
Date: Tue, 01 Mar 2022 17:41:59 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Eliot Lear <lear@lear.ch>
Cc: Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>, "Int-area@ietf.org" <Int-area@ietf.org>
Message-ID: <Yh5M18z2/YVfpW7i@faui48e.informatik.uni-erlangen.de>
References: <57c643c667d94a77b9917bb17dc142a5@huawei.com> <7de0956f-3fde-1543-405b-b635f6e69362@lear.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7de0956f-3fde-1543-405b-b635f6e69362@lear.ch>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/rMCrFwBFfbx-fSSbQncY7CSwS-E>
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: Tue, 01 Mar 2022 16:42:21 -0000

Eliot, *:

Thanks for the historic reference to IEN19!

IEN19 defines that "an address indicates *where* it is". But in the
Internet, my rfc4291 subnet prefix is injected into Internet BGP,
so that (part of the IPv6) address does not tell me nada, zilch,zip
about *it*'s location. Only the routing system knows the location.

Maybe IEN19 was written with E.164 routing as its core reference, where
i guess (at least back then), the actual location of *it* was
indeed fixed by the physical point of attachment, and the dynamic
routing system only allowed to plot more than one path to *it*.

And of course, the other part of the rfc4291 address is already
called (interface) interface, so it too isn't indicating, where
*it* is. I am obviously using elecrtromagnetic broadcast via
a WiFi AP or a yellow ethernet to locate *it*, not the address.

Did we (e.g.: through locator/identifier split effort or other)
ever came up with some cross-technology consistent terminology for the
nature of an address, such as whether or how we decide if/what is
a locator and/or identifier (or any other name-calling for addresses) ?

For example: The use of locator/identifier in RFC6830 (LISP) i think is,
to use the White Knight's terminology, only what an address is
called by an xTR (or the LISP instance) but nothing more: It does not
defining what the nature of the locator or identifier addresses are.

So maybe there is no such thing as "are" unless we start having self-aware
addresses. Maybe we should only think about what (the parts of)
addresses "is called" by specific entities using them such as the network
routing subsystems address registries or APIs into the forwarding layer.

Cheers
    Toerless

On Tue, Jan 25, 2022 at 08:46:13AM +0100, Eliot Lear wrote:
> 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