Re: [arch-d] Treating "private" address ranges specially

Toerless Eckert <tte@cs.fau.de> Thu, 01 April 2021 00:04 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE913A3C41 for <architecture-discuss@ietfa.amsl.com>; Wed, 31 Mar 2021 17:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 JwuN7LzrqmU1 for <architecture-discuss@ietfa.amsl.com>; Wed, 31 Mar 2021 17:04:36 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132F53A3C3E for <architecture-discuss@ietf.org>; Wed, 31 Mar 2021 17:04:30 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F00AF54802F; Thu, 1 Apr 2021 02:04:22 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E5A3F4400B1; Thu, 1 Apr 2021 02:04:22 +0200 (CEST)
Date: Thu, 01 Apr 2021 02:04:22 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Geoff Huston <gih@apnic.net>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, architecture-discuss@ietf.org
Message-ID: <20210401000422.GI8957@faui48f.informatik.uni-erlangen.de>
References: <4329d51a-d5ba-45b3-9fb0-6795dc6fccd3@www.fastmail.com> <CAMGpriWA4B8AThNKBOHo-bfAdQ2s5iYv8rBOB7X8UVc5GsqENA@mail.gmail.com> <CAMGpriUJkWYPyw7=oAj_GnGu2J14T3=VZYNWPZtAs870P=x0sg@mail.gmail.com> <a68636c2-5df0-46eb-8147-79ec6a992f8a@www.fastmail.com> <CAMGpriU_L8HbLFX_mMBtBXxy=XOc5BAnYgVR9R8TQO=DPvRD_g@mail.gmail.com> <F59E2FC3-19CE-4D14-9F1C-9F7125D89455@mnot.net> <CAMGpriVJCsird15oBfT=gSDTr59_yf9TkLmOSO7a9DGX0VRjOg@mail.gmail.com> <CA+9kkMB2iOA-QaCidJHVN=qqZ8TtPXV=xyfuKh+i44VzZLWG3w@mail.gmail.com> <0cfae1b5-378d-1b28-9a60-89ef15cd793a@gmail.com> <F0EA1E64-2197-4BD1-BFEE-774072D3B49F@apnic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F0EA1E64-2197-4BD1-BFEE-774072D3B49F@apnic.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/yv5FUDutjnMBgwMygDf5RYLPTfc>
Subject: Re: [arch-d] Treating "private" address ranges specially
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 00:04:40 -0000

Btw: If you look at the proposal in more detail, the browser actually does not try to
"know best" only by itself, but it uses a protocol for consultation from an entity
that hopefully does know better. That aspect i really like. Except that the solution
around such an approach would need to be revisited from scratch as opposed to be
extened ad-hoc as in this proposal. Especially the part where the browser does try to know the
semantic of an address purely from some IPv4/IPv6 architectural "address scopes".

Disclaimer: superficial, quick assesment..

Cheers
    toerless

On Thu, Apr 01, 2021 at 10:45:44AM +1100, Geoff Huston wrote:
> +1 to Brian - I find this whole ???browsers know best??? approach misguided as well!
> 
> 
> Geoff
> 
> 
> 
> > On 1 Apr 2021, at 7:27 am, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > 
> > Hi,
> > 
> > On 31-Mar-21 22:07, Ted Hardie wrote:
> > 
> > <snip>
> > 
> >> The document's description of the address space architecture is:
> >> 
> >> 
> >>      2.1. IP Address Space
> >> 
> >> Every IP address belongs to an IP address space, which can be one of three different values:
> >> 
> >> 1. local: contains the local host only. In other words, addresses whose target differs for every device.
> >> 
> >> 2. private: contains addresses that have meaning only within the current network. In other words, addresses whose target differs based on network position.
> >> 
> >> 3. public: contains all other addresses. In other words, addresses whose target is the same for all devices globally on the IP network.
> > 
> > The problem is that this classification is worse than heresy; it's nonsense.
> > 
> > 1) local. That seems trivially true (assuming that it covers virtual hosts, not just physical ones). Or is it? If a device has multiple interfaces (physical or virtual) which might lie in different administrative domains, each of which has several IP addresses, including but not limited to loopback addresses, are they all equally "local"?
> > 
> > 2) private. There is no definition of "private" address in any IETF document. There is no way of looking at the bits in an address and determining that it's private, because there's no definition of private.
> > 
> > 3) public. Ditto. Globally reachable != public. "Globally reachable" itself is an over-simplification. See recent very loud discussions in IPv6-land about ULA addresses.
> > 
> > The attempt to use the IANA registry to determine things that are undefined is just nonsense. It's an attempt to over-simplify something that is inherently complex. The ground truth about address scope exists only in the entire Internet's routing tables, and simply *cannot* be deduced from the bits in an address.
> > 
> > BTW, whoever designed the Python ipaddress module got this wrong too.
> > 
> > So IMHO this whole effort is fundamentally misguided and should be scrapped.
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
tte@cs.fau.de