Re: Non routable IPv6 registry proposal

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 23 January 2021 16:49 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D03A08C5 for <ietf@ietfa.amsl.com>; Sat, 23 Jan 2021 08:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 AYxD2_xPMK0t for <ietf@ietfa.amsl.com>; Sat, 23 Jan 2021 08:49:19 -0800 (PST)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (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 F20933A08AA for <ietf@ietf.org>; Sat, 23 Jan 2021 08:49:18 -0800 (PST)
Received: by mail-yb1-f169.google.com with SMTP id x78so8730211ybe.11 for <ietf@ietf.org>; Sat, 23 Jan 2021 08:49:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Htd2n8qYQEQQ7cCAzdwwLa7lzZtzkR6VfkdSmch9ld0=; b=XB5IKPTJV58OqzC9cqWgPBBbUf/E0qIs1lADFbvMjyJxAKJVSM17R9C3DmC24aFpJp EW3P1FC0tcbszj5BCIMrq0Hc+fpaUdDEbFmR+t3hizHkA4bQbwIEkmYa3RqE1DnvK0hb sJxe/xEoEuQ1Uc6bfrgdneGCWUptB421KdZvGQcH1Ys5DpP2qgeWj1RYsqeJH72XPk49 Tzu0v5H+0MEMxlzu3Q9lzphFD6cZVdrSQDsOFl1q5+c62Nv0/MggJd0W8seSgqIgsH7z OyXj6V3vN5ZCGHhgRVyeG1jCDKZ0MPYCaEUkJBa25WsUhNVUo49abxk4+QOiZaF12YpM SXLg==
X-Gm-Message-State: AOAM532HtjF3bN+JdI/NmZONvyuaSikNqaeIs/C/BbL6MxE/3uy8rnSR Uj75zztnAPZ4MFcJ8mnZwVQz0nVNvRvUPbHXTxg=
X-Google-Smtp-Source: ABdhPJxBvBQ4OAwXMbJ9J6r2QnncX+V31gPqftJ3nPyOpo8n71GaKWTWDiDojHpjF/bXEJHzTLZ1u0OsBNfApsODxR0=
X-Received: by 2002:a25:bc44:: with SMTP id d4mr13537168ybk.522.1611420557952; Sat, 23 Jan 2021 08:49:17 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <72F969A9-AF94-47B6-B48C-B3CD4D9A7C72@strayalpha.com> <7cc9e38c-5a00-ec59-a8c2-10503cc40d50@si6networks.com> <CB1A6DF0-8CDD-495D-9F7B-80BF72F08C1E@strayalpha.com> <53d7190a-3e1f-66b3-0574-8e8fbb3a7a5e@si6networks.com> <90718D2A-3483-45D2-A5FB-205659D4DCDB@cisco.com>
In-Reply-To: <90718D2A-3483-45D2-A5FB-205659D4DCDB@cisco.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 23 Jan 2021 11:49:05 -0500
Message-ID: <CAMm+Lwhrtw5ZSDA2qsC7FjW0q_O1V-pW8+cVbYA-K71ToAs1qg@mail.gmail.com>
Subject: Re: Non routable IPv6 registry proposal
To: Eliot Lear <lear@cisco.com>
Cc: Fernando Gont <fgont@si6networks.com>, Joseph Touch <touch@strayalpha.com>, The IETF List <ietf@ietf.org>, Nico Schottelius <nico.schottelius@ungleich.ch>, The IAB <iab@iab.org>
Content-Type: multipart/alternative; boundary="000000000000f0ca3605b99415a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lQjD9u3OUfkpzNBJcR_0HSS8ddg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jan 2021 16:49:21 -0000

On Sat, Jan 23, 2021 at 5:02 AM Eliot Lear <lear@cisco.com> wrote:

> Hi everyone,
>
> As Nick Hillard pointed out, this came up in December on the IPv6 list.
> The registry is managed by Nico Schottelius and Ungleich[1].  Does that
> make this registry The Registry?  Perhaps not.  Does it address the Sybil
> attack?  No.
>

Registries cost money to run. The only advantage of the random allocation
is that you don't need a registry. Once you decide that you need a
registry, random allocation makes no sense.


> There is clearly demand for such registration, given that there is already
> a registry of over 5,000 networks, and it is clear that Ungleich is
> satisfying that demand.  This raises some questions.  It may be the case
> that a listing may lead to people believing that they are somehow
> guaranteed that their use is indeed unique, when in fact no such guarantee
> can be made or kept under the current scheme.  Also I think there are some
> tough questions that may need to be resolved around points of contact and
> relevant laws.  These are things that both ICANN and the various RIRs have
> paid considerable attention to
>

It is non routable space. So a point of contact isn't very useful. What are
the laws that you think might apply? We haven't taken much notice of
international communications laws in the past. And ICANN only started
paying attention to EU privacy law when they realised that they were about
to be whacked with a very expensive lawsuit.

One might ask: why aren’t people just going through the RIR system to get
> globally routable space?
>

Because that is a registration that only exists on sufferance of the RIR.
Case in point, Parler is about to be kicked off the net again as their IPv4
and IPv6 assignments are pulled.

The RIRs already have too much power. We should not extent their monopoly
into non-routable space.

  One of the key principles of stewardship of the address space in the past
> as been efficiency.  Another has been aggregation.
>

Aggregation is precisely the thing that distinguishes routable from
non-routable allocation and it shows the reason why the random allocation
approach to ULAs is bjorked. For purposes of routing, IPv6 is really a 64
bit space, not a 128 bit space and the lower 64 bits are intended for
'local' use. So you want aggregation, you certainly want allocations to be
significantly larger than a /64. A /48 looks like the right size.
Particularly since the routing address space is a 32 bit AS number

Allocating in /48 blocks for non routable space where aggregation is
irrelevant makes very little sense to me.


Here are some considerations the IAB, RIRs Nico, Phil, you Fernando, and
> other interest parties, might reasonably discuss:
>
>    1. Are those principles are still being observed at the RIRs and how
>    they have evolved,
>    2. What are the blockers to using an RIR block?
>
> They can be taken away and the RPKI is based on a completely inappropriate
technology for the task.

3) What should the applicable principles be?
>

Personal autonomy of Internet users.


> 4) Are there risks to the Internet ecosystem of which ungleich (and
> similar) registry uses should be aware?
>


> 5) What are the relevant policies that need to be incorporated into any
> new registry?
>


> 6) What prefix should be used?
>

Set up an IANA registry and allocate /32s (or less) in FC00::/8. The first
256 registries that come and ask for allocations get a /32. The next 1024
get a /30 and so on.

If any registry can show they have allocated 75% of their initial
allocation, they get an allocation four times larger.


> 7) Were there to be a more “official” registry, what are the roles of the
> various players, including this community, ICANN, the RIRs, ungleich, etc?
> And
>

The WebPKI has never had an official registry. But it worked because
instead of asking for permission, we went ahead and did it. Over numerous
objections from IETF community.


> 8) And who gets to decide these questions?
>

Well not the incumbent providers. And especially not when Big Tech is in
the crosshairs on capitol hill and there are multiple Federal and civil
anti-Trust suits being thrown about. The EFF's blatant lying about the PIR
allowed them to fill their coffers bilking the rubes but left ISOC and
therefore IETF with the conflict of interest.


> If that sounds like an IAB workshop or a program or a BoF… well… It could
> be that the IAB and the RIRs have crisp answers to all of these questions.
> In which case, I’m talking about an email or perhaps a statement that
> satisfies at least my curiosity and apparently those of others ;-)
>

Or we could do an experiment and then walk back the cat on lessons learned.

The current status of my code is that the Mesh now passes all its unit
tests, I am just working on coding a robust server with sufficient
instrumentation etc. I will be adding the callsign registry in another
couple of months. Once that code is ready, I launch. Adding the IPv6 ULA
allocation to the callsign registry is 4 hours coding and 20 testing.


> One aspect with which I take great issue is that this should even be
> considered for IPv4.  IMHO, that would be getting blood from a stone.
>

At the very start of this thread, I pointed out that the motivation for all
this is precisely the fact that 10.0.0.0 simply isn't big enough. It is
worth considering but only to know why it can't work.