Re: Non routable IPv6 registry proposal

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jan 20, 2021 at 4:32 PM Brian E Carpenter <
[e-mail]> 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.