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

Toerless Eckert <tte@cs.fau.de> Thu, 01 April 2021 01:54 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 D6CBB3A0CF1 for <architecture-discuss@ietfa.amsl.com>; Wed, 31 Mar 2021 18:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YLzJix_al6sz for <architecture-discuss@ietfa.amsl.com>; Wed, 31 Mar 2021 18:54:47 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 6133B3A0CE2 for <architecture-discuss@ietf.org>; Wed, 31 Mar 2021 18:53:50 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F3642548042; Thu, 1 Apr 2021 03:53:42 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EB2B54400B1; Thu, 1 Apr 2021 03:53:42 +0200 (CEST)
Date: Thu, 01 Apr 2021 03:53:42 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Joseph Touch <touch@strayalpha.com>, architecture-discuss@ietf.org
Message-ID: <20210401015342.GJ8957@faui48f.informatik.uni-erlangen.de>
References: <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> <1E1FB005-5830-46E0-B8DA-9ADC89A13B1E@strayalpha.com> <0f1d54e4-07da-725a-a655-66c226d44027@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0f1d54e4-07da-725a-a655-66c226d44027@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/E8P7V3W1SZiFGe98EG4CN31jhjU>
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 01:54:52 -0000

I think there are three levels of concern here:

a) The "designated" use/reach of addresses according to architecture
   This is what the proposal assumes can be used to deduce policy from

b) The actually operational use/reach of addressing with the addition of 
   reachability via NAT and the subtraction via routing and firewalling
   which i think Brian referred to and what i tried to explain in my
   prior mail, suggesting this is the minimum level of policy for reachability
   which to consider.

c) Th actual "third-party-access" policy an operator would desire a particular
   browser application to have. I think this will have nothing to do with
   a). At best it will be a subset of b), but in general, i think we won't
   know unless we look at explicit use cases and derive a design from them.

Cheers
    Toerless

On Thu, Apr 01, 2021 at 02:30:04PM +1300, Brian E Carpenter wrote:
> On 01-Apr-21 13:17, Joseph Touch wrote:
> > 
> > 
> >> On Mar 31, 2021, at 1:27 PM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >>
> >> 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.
> > 
> > How is this different from RFC6890?
> 
> While 6890 is better than what came before, I'm afraid that it still doesn't capture reality (and therefore the IANA registry doesn't either, which is no fault of IANA).
> 
> >> 1) local. That seems trivially true
> > 
> > Again, RFC6890?
> > 
> > ...
> >> 2) private. There is no definition of "private" address in any IETF document. 
> > 
> > RFC1918??
> 
> Yes, you're right, it does use the word "private". But that is in some old out-dated address space where things are relatively simple. In any case, the definition proposed in the cited document doesn't seem to limit itself to that, but tries to extrapolate the same categories to IPv6 and that simply doesn't work.
> 
> > 
> >> 3) public. Ditto. Globally reachable != public.
> > 
> > AFAICT, those are equivalent terms; there are lots of ???not officially private???, ???not officially local??? addresses that are not globally reachable either (e.g., most things behind NATs).
> > 
> > So at best, this hierarchy isn???t ill defined or lacking RFC authority; it???s just incomplete.
> 
> I really don't agree. There is a class of address prefixes that are *potentially* globally reachable and therefore potentially public, but there is no way to know by looking at a specific address. So there is no algorithm to reliably return "private" or "public". When I worked for the Network 9 company, you would have needed quite a large table to know which 9.x.y.z addresses were public and which were private. When you installed the corporate VPN, it didn't install a single route to 9/8. It installed a local routing table with a page or two of prefixes. The sort of algorithm proposed here would simply return "public" for any such address. (Try the attached Python script.)
> 
> Regards
>    Brian
> 

> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
> import ipaddress
> print("This will tell you what Python believes are the properties of any IP address")
> while True:
>     print("Please enter an IP address:")
>     _l = input()
>     if 'q' in _l or 'Q' in _l:
>         break
>     try:
>        _l = ipaddress.IPv6Address(_l)
>     except:
>         try:
>            _l = ipaddress.IPv4Address(_l)
>         except:
>             print("Invalid")
>             continue
>     # Now display address properties
>     print("That's", _l)
>     try:
>         print("Global", _l.is_global)
>     except:
>         print("Global (undefined for IPv4)")
>     print("Private", _l.is_private)
>     print("Unspecified", _l.is_unspecified)
>     print("Reserved", _l.is_reserved)
>     print("Loopback", _l.is_loopback)
>     print("Link Local", _l.is_link_local)
>     print("Multicast", _l.is_multicast)
>     print()
> print("Goodbye")

> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss


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