Re: Non routable IPv6 registry proposal

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 20 January 2021 21:33 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 63D5A3A150C for <ietf@ietfa.amsl.com>; Wed, 20 Jan 2021 13:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, LOTS_OF_MONEY=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 uEEcRjDWKW7E for <ietf@ietfa.amsl.com>; Wed, 20 Jan 2021 13:33:32 -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 A39CC3A15CE for <ietf@ietf.org>; Wed, 20 Jan 2021 13:33:19 -0800 (PST)
Received: by mail-yb1-f169.google.com with SMTP id k132so69591ybf.2 for <ietf@ietf.org>; Wed, 20 Jan 2021 13:33:19 -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=M72p2+nQILC4FpgB/WSQDBO4b39H0lTuwG4C2Ho6tkk=; b=L7u2J5zXzSwjtgAfiiEzG9YK6XUKRVwDk2cGGt+OI6k3DZY63c1P9Kg5VLq0wx7EWD X1Lchb/aU+zAJZ3HTGX9Pme8GnIvUvFBV37ifcd9Kb74bhFEVBsjminPS1Nl3jBKJP7h n0lcj1oOjaZWYp3mP5kz+paQs10qwKNXpQeR7FtC8wE+aYfm17LgLPKTLWHbw/TB7gcJ tsn5Oij2YkMGE69b6LNmtMXLSZDBkWmnJAl87ut/vd/W2a5v38olKvYkI2NjHqdH8RaE Sk+N0LdtKyzVAD3+Ln9fejglgH9UEi97/kf4gFkvvOOuesicE5+ZmBFOwwdw9fzgcdKe c6/w==
X-Gm-Message-State: AOAM531WwqRwas4pXSqMweD5QeO1jLKKtbxoKY9KaB5ft1ImH2So2Ahu zvz1x/foMM3qLuo9sNcx1Jfc7P2TD79JkElBFb7Qn5djwDcQTQ==
X-Google-Smtp-Source: ABdhPJy80dHwNXHVL6Eqd4nBftoGdcPMz0hrzJLQNADRTuNVcxo/pb1h4VfD6uHvMVi4C+4Dmp47CJikZ973tnWFcgA=
X-Received: by 2002:a05:6902:6cc:: with SMTP id m12mr15732219ybt.56.1611178398818; Wed, 20 Jan 2021 13:33:18 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <abdac3dd-f601-1fae-8c9f-fbe393930558@foobar.org>
In-Reply-To: <abdac3dd-f601-1fae-8c9f-fbe393930558@foobar.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 20 Jan 2021 16:33:08 -0500
Message-ID: <CAMm+LwgBRSAYShSGmcaWY1JM=G8zvFovR_qAoFgMmbafrFgkYA@mail.gmail.com>
Subject: Re: Non routable IPv6 registry proposal
To: Nick Hilliard <nick@foobar.org>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021a42d05b95bb4ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7-ZazE2Fczp4lRpERJMBkogzlzE>
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:33:34 -0000

On Wed, Jan 20, 2021 at 3:58 PM Nick Hilliard <nick@foobar.org> wrote:

> Phillip Hallam-Baker wrote on 20/01/2021 20:06:
> > The proposal is to reserve a significant block of IPv6 space (e.g.
> > 2002::/16) as non routable address space to be allocated in Class A/B/C
> > sized chunks on a permanent basis either through random assignment or by
> > a new registrar TBD for a negligible one-time fee ($0.10 or less).
>
> this idea was the subject of a recent discussion on 6man, subject
> thread: "Re-Launching the IPv6 ULA registry".  The original email was here:
>
> https://mailarchive.ietf.org/arch/msg/ipv6/fFpPHY55pwKlEopyyAZyZI8azg0/


> There were several aspects which cropped up, but the core issues seem to
> be whether the end user needs both address permanence and the
> requirement for interconnection to third parties.  If you need both of
> these, then registered addresses are a good idea; if you don't need
> both, then ULA should work fine.
>

Random addresses are almost certainly going to be fine.

Registering an address is low value, registering a binding of an address to
a public key is much more useful.

The economics you're proposing may need a bit more consideration,
> especially given that registries need long term stability, both
> financial and from the point of view of governance.
>

Governance is much less of a concern for numbers with no semantics. My
other proposal in this space, the Mesh callsign registry for names of the
form @alice etc. is a lot more complex. Obviously @microsoft has to go to
the place everyone expects and not just because Microsoft can afford the
lawyers. It is a security concern because there is an expectation that goes
to the 'right place'. I have spent 20 years on those issues at VRSN and
Comodo.

Governance in the numbers space comes down to denial of service attacks.
What happens if we have a US administration which tries to kick Iran off
the net by denying them the right to register numbers? Well right now what
would happen is they would just make up their own numbers and continue.
Start imposing PKI based verification of addresses and that type of attack
can become real.

It is very important to understand the impact of the technology on the
business model. Servicing DNS names is expensive and will always be
expensive because the registry is required to provide a resolution service
with low latency, 99.999% uptime, etc. etc. The RPKI is expensive because
it is based on PKIX and the assumption certificates expire every time the
earth circles the sun a given number of times.

The business model for my proposed registry is essentially the exact same
thing as that for the 'million dollar home page': Charge a small fee for a
one time registration, let other folk worry about providing hosting in
perpetuity.


I have done a lot of thinking on the callsigns and will be able to offer
them for $0.10 each for names of 9 characters or more. The surplus funds
going to a not-for profit to fund development of open source code and
specifications. Why do I expect there to be a significant surplus? Because
shorter names will attract an exponentially increasing premium. You can
be @nick_hillard for $0.10 or you can demonstrate your commitment to the
project by being the first to buy @hillard at $10 or you can be a really
good patron and pay $10,000 for @nick.