Background
As we design IPv6 networking for multi-tenant projects on the Datum Cloud platform, we ran into a fundamental difference between how public and private IP address pools should behave.
For public IP addresses, uniqueness is non-negotiable — two projects can't have the same globally routable address. But for private addresses (e.g. ULA ranges like fd20::/20), uniqueness across allocations doesn't matter. A project might have multiple networks — staging, production, a sandbox — and there's no reason those networks can't all use the same private prefix. They're isolated from each other by design.
Today the IPAM service enforces uniqueness on all allocations. That's the right behavior for public pools, but it's an unnecessary constraint for private ones — and it pushes consumers toward workarounds like explicit binding that obscure the real intent.
What we want
Pool operators should be able to declare whether a pool enforces unique allocations or not. For private pools, overlapping allocations should be explicitly permitted. For public pools, the current uniqueness enforcement stays as-is.
This way, a consumer asking for a /48 from a private pool always gets one — no conflict, no ceremony — while a consumer asking from a public pool still gets a guaranteed non-overlapping block.
Why this matters
Without this, consumers have to either:
- Accept that private networks within a project can't reuse the same prefix (an unnecessary constraint that leaks allocation concerns into network design decisions), or
- Work around it with explicit binding, which obscures intent and adds operational complexity
The distinction between "this pool cares about uniqueness" and "this pool doesn't" is a property of the pool's purpose, not the consumer's request. It belongs in the pool policy, not in consumer workarounds.
References
Background
As we design IPv6 networking for multi-tenant projects on the Datum Cloud platform, we ran into a fundamental difference between how public and private IP address pools should behave.
For public IP addresses, uniqueness is non-negotiable — two projects can't have the same globally routable address. But for private addresses (e.g. ULA ranges like
fd20::/20), uniqueness across allocations doesn't matter. A project might have multiple networks — staging, production, a sandbox — and there's no reason those networks can't all use the same private prefix. They're isolated from each other by design.Today the IPAM service enforces uniqueness on all allocations. That's the right behavior for public pools, but it's an unnecessary constraint for private ones — and it pushes consumers toward workarounds like explicit binding that obscure the real intent.
What we want
Pool operators should be able to declare whether a pool enforces unique allocations or not. For private pools, overlapping allocations should be explicitly permitted. For public pools, the current uniqueness enforcement stays as-is.
This way, a consumer asking for a
/48from a private pool always gets one — no conflict, no ceremony — while a consumer asking from a public pool still gets a guaranteed non-overlapping block.Why this matters
Without this, consumers have to either:
The distinction between "this pool cares about uniqueness" and "this pool doesn't" is a property of the pool's purpose, not the consumer's request. It belongs in the pool policy, not in consumer workarounds.
References