Re: Non routable IPv6 registry proposal

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 20 January 2021 21:58 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 91C7A3A1530 for <ietf@ietfa.amsl.com>; Wed, 20 Jan 2021 13:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 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] 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 CCGeRTCBna2S for <ietf@ietfa.amsl.com>; Wed, 20 Jan 2021 13:58:32 -0800 (PST)
Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (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 16C423A1513 for <ietf@ietf.org>; Wed, 20 Jan 2021 13:58:31 -0800 (PST)
Received: by mail-yb1-f173.google.com with SMTP id b11so88240ybj.9 for <ietf@ietf.org>; Wed, 20 Jan 2021 13:58:31 -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=AbZ/SyoY6+PUXqgnAzzNmE2RTh14iSfGb+2b0YQK6Ks=; b=PG/0D4AlY58u80+3SpSOU6YHznfVKXbquId68MNcbbw+NZWpX7ZER1xMrQLymkyAoz Ll0ABUvfzqwbMPNExmCP7/mmF5gnG3n+Rl9HEPCNwP4BSIM8sM02lkFs9R2/lcdTmVjC FDfgL9GJg4rrfWQlrLA21v4TmGMT/Z//CSxFzpI1yeN2h0DcbMm9vWWgauV2l4/jSnYl IVFGvi77E8qAygJlR4tnQsBWRY9W5R+R6D+3huF5XsoroKEqSZ6PHGGS3rkIhJ1j0Zt7 K2uvWLI+OhmZgXaSPZMb2YiX1C0MD7axQvbKHEviTnttZ18l7376ofDOCyi87WexxwCK vSwg==
X-Gm-Message-State: AOAM530yAJimrwJ3mmzj+nVCKrFt7Lh9O2RFyozUVqab//g9bDuwF+k0 d9zZ+EKhPajeIlIOhW9tnPGy1f3rb/Mq0ozO8BA=
X-Google-Smtp-Source: ABdhPJx9e4GLIXvSM/zI+R/v/f6Sl5oXVFgU6Edrdyc5bY0gbZqSOnXtO+5JR2C9NUhk4P8Lz+wUMr1E0ttxcV3e7UM=
X-Received: by 2002:a25:7704:: with SMTP id s4mr18212590ybc.523.1611179911160; Wed, 20 Jan 2021 13:58:31 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <abdac3dd-f601-1fae-8c9f-fbe393930558@foobar.org> <e9a49b69-b629-356b-c33a-4d49794c3e89@gmail.com>
In-Reply-To: <e9a49b69-b629-356b-c33a-4d49794c3e89@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 20 Jan 2021 16:58:20 -0500
Message-ID: <CAMm+Lwh7nQRm=4fLkOKOgQA9L9TS_wh3qSmmV_Ko+N+afDtw+Q@mail.gmail.com>
Subject: Re: Non routable IPv6 registry proposal
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Nick Hilliard <nick@foobar.org>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004626e005b95c0ea8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/epJRIvb-fpa1HM7cD5yGTwrD73M>
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: Wed, 20 Jan 2021 21:58:34 -0000

On Wed, Jan 20, 2021 at 4:32 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> > if you don't need
> > both, then ULA should work fine.
>
> More completely: if you don't need both, *or* if you are willing to risk
> the unlikely inconvenience of renumbering if your ULA network ever merges
> with, or directly interconnects with, another ULA network that by chance
> has the same pseudo-random prefix, then ULA should work fine. The birthday
> paradox part of this is discussed in section 3.2.3 of RFC 4193.
>
> RFC 4193 also reserves, but does not specify, a range of such addresses
> (usually known as ULA-C) that could in theory be centrally registered, if
> people don't accept the birthday paradox risk. That was the topic of the
> recent discussion that Nick mentioned. So there is no need to assign
> anything new. The only issue is how to fund such a registry and guarantee
> it indefinitely.


Following the IPv6 practice, we wouldn't declare 'a registry'. We would
instead create a meta-registry and allocate a unique address range to each
provider that meets some threshold of apparent competence.

So lets say I decide to start up a registry. I write up an RFC describing
the answers to the issues you raise and I get FC00::0000/32 to allocate on
an experimental basis. Worst that can happen is I screw up and lose track
of who was allocated what. I can now issue 4 billion /64s before I have to
come and ask for more space. And there is still room for 32 million other
registries like mine doing the same.


As for the business model, I was thinking I would bundle this service with
the callsign service I am already working on because it provides another
little part of the puzzle to provide end users with autonomy. So for $0.10
someone can get a unique callsign of 9 characters or more plus a unique /64
in IPv6.

Why only a /64? Thats because I expect people who need more IP address
space to also want more callsign space. If I have a property at 64 Zoo
Lane, I register @64_zoo_lane and get a chunk of IPv6 space for that
property to use internally as permanent allocation to the devices at that
location. Its big enough to map a MAC-48 or EUI-64 address inside on a 1:1
basis.

When the property is sold, the callsign and ULA IP space move with the
property.


The only time a registration would ever be updated in my model is to bind
it to a different public key. And that transition would be signed by the
previous authorized key. If the key is lost, the new owner of the building
just burns the IP address space and allocate a new chunk and tell the local
routers to make the necessary mappings.