On Wed, Jan 20, 2021 at 4:32 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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.
