Re: Non routable IPv6 registry proposal

Phillip Hallam-Baker <> Fri, 22 January 2021 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EC203A10F3 for <>; Fri, 22 Jan 2021 08:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.687
X-Spam-Status: No, score=-0.687 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, ONE_TIME=0.714, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Ht67oBCr_om for <>; Fri, 22 Jan 2021 08:13:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC6A43A0D91 for <>; Fri, 22 Jan 2021 08:13:31 -0800 (PST)
Received: by with SMTP id w24so5934292ybi.7 for <>; Fri, 22 Jan 2021 08:13:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bYYIM3ll19ddMGRiKVQT9mt4CtVfX2xo29YCfRMDyVg=; b=RSdqZAb9iFCRUufk7VnZyzD5IioHwRLdLSpTOCxtuvwVYaY+tfvxmub2K+LhCK2X+c NlvFWIR9IFj5cWpVdMU/dvS7gDviav+NVBHyj/C0RJK8J/f6W7q9wGtCmrUG20E6JHjS YK7Wpryq1WSZjlBWLjYqiWVjyhPGsnRUeIdcrwUPfVziQZucybgVyipkOt5dCQoXRF94 s7gAmNUGCrdQg7WOcF2P49tNGZYvohj6DIhvBWFi8yrTcv0QUlJLOC77UYXyKoh10num L6aDQTfjHoqVn2SeHwHTKl2PYSK11ZEsMHIF0DsUdG6aXcrVPKtnm3Bh42SxoQVdJ+RJ 1enQ==
X-Gm-Message-State: AOAM530xpP0L5thcoaYYbxGI1STibIBB8pYvcep5yINviSc/YuWEC5AW O2n6KzNkoDybZJJiiqbSBvEHJ6H7AAsOOcTpgRA=
X-Google-Smtp-Source: ABdhPJzc4eaKcaYmJOm9QhHrV7678OmFzhngl7oPFhSh4F6aNdqi+HN05EgC/OcdFCFilKDqUjay/026RrN47eaNBdk=
X-Received: by 2002:a25:7704:: with SMTP id s4mr7792331ybc.523.1611332010872; Fri, 22 Jan 2021 08:13:30 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Fri, 22 Jan 2021 11:13:04 -0500
Message-ID: <>
Subject: Re: Non routable IPv6 registry proposal
To: Christian Huitema <>
Cc: Brian E Carpenter <>, Michael Richardson <>, IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000001f943305b97f7806"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2021 16:13:34 -0000

On Fri, Jan 22, 2021 at 1:24 AM Christian Huitema <>

> On 1/21/2021 9:57 PM, Phillip Hallam-Baker wrote:
> On Fri, Jan 22, 2021 at 12:45 AM Christian Huitema <>
> wrote:
>> On 1/21/2021 5:02 PM, Phillip Hallam-Baker wrote:
>> On Thu, Jan 21, 2021 at 2:56 PM Brian E Carpenter <
>>> wrote:
>>> Putting two things together:
>>> On 22-Jan-21 07:57, Phillip Hallam-Baker wrote:
>>> ...
>>> > A ULA->Public key registry provides exactly the right degree of
>>> incentive. It allows us to take an area that is currently flaky as heck and
>>> make it 'just work'. That area is VPN access.
>>> Yes, but afaik you (or I) can't claim ownership of random numbers. So if
>>> my ULA prefix is fd63:45eb:dc14::/48 and I provide a public key for it,
>>> what's to stop you using the same prefix and providing your own public key
>>> for it?
>> The registry undertakes to only issue each prefix once and bind it to a
>> public key specified by the holder.
>> The registry publishes the allocation in an append only log which is
>> attested by a blockchain type technique. So there is (almost) no scope for
>> the registry to defect.
>> How do you protect the registry against a Sybil attack?
>> -- Christian Huitema
> There is a one-time charge of $0.10 per registration. No renewal fees.
> That should work if the "block chain" signatures can only be appended by
> the organization maintaining the registry. I wonder why just $0.10, given
> that for the normal user just learning the process will cost way more than
> that. Also, just the credit card fees are larger than that. Plus, if you
> want to guarantee the ownership "forever", you probably need sustained
> revenues in the long term

I was in that business for a decade. I know exactly where the costs are and
I am planning to configure my businesses accordingly.

The IPv6 part is just a bolton to the Mesh callsign registry I am already
building. I can throw a /62 at every registrant with no hassle.

1) The Mesh Foundation, a not-for-profit runs the registry as public goods.
Sells blocks of 10,000 Mesh registrations for $100 each to anyone who wants
to set up a Mesh Service Provider (MSP) or just issue registrations.

2) Threshold Secrets, a for profit MSP that provides customer service,
account hosting etc. at commercial rates.

The big difference between my model and the traditional Internet account
model is that accounts are portable. You own your account, it is bound to
the public keys you own. So you can register with my MSP, use it for a
year, decide you don't like the service I provide and switch to Fred's.
That change is advertised through the registry.

All the costs of the registry are offloaded onto the MSPs. VeriSign sheds
the cost of customer service to the registrars. I am proposing to shed the
cost of resolution service as well.

So if I want to contact you on Signal, SMTP, etc. via your Mesh callsign
(@christian), my client goes to my MSP, and finds the location of your
current MSP servicing the account and presents an authenticated request for
your current contact info. If authorised, your client gets my current
contact info (or the contact info you are allowed, if I don't know you, its
probably just info on how to request a contact exchange).

I expect the operating expenses of the registry to be in the low seven
figures operating at scale. If I am incorrect, we raise the rates. If we
raise the rates higher than people find acceptable, we will get competition.

> So a DoS attack would merely swell the coffers of the not-for-profit Mesh
> foundation which will pay for development of code, etc.
> I am not sure that a Sybil attack is relevant as there is absolutely no
> accreditation going on here except between the registry and the small set
> of chosen peer notaries. And they are merely cross notarising. There are no
> subjective or unconstrained inputs here. Every input is deterministic, the
> only non determinism comes from timing.
> There are variants of the Sybil attack that concentrate on fractions of
> the address space. Also, if the space is just 40 bit wide, the attacker
> will start causing random collisions after registering 1 million entries.
I am proposing to issue in the registered space FC00::/8, not the random
space FD00:/8. And I am asking* for a /32 from which I will allocate /62s
so, I have room for 2^30 registrations in my initial allocation. If I start
to run out, I ask for an extra /32. There are 16 million /32s in that
space. So we don't run out till we have allocated a trillion registrations.
And these are densely packed.

[*] Asking for advice, not necessarily permission.

> Speaking of collisions, is there a way for registrants to test for
> collisions before registering? Is it correct to assume a publicly available
> blockchain?
> -- Christian Huitema
I don't see the random approach being feasible for the reasons you raise.
Since my plan is to add this to a registration service, I will be
allocating in dense blocks with a transparent allocation rubric.