What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs
already provide. Also entities that have such a strict requirement are
perfectly served with address space the RIRs provide.
Not so. The registries provide GUA, not ULA. Not everybody considers
the difference significant, but many if not most of the folks who want
to use ULA for anything at all do.
I think you misunderstood my terminology, which is afaik the one used by
the relevant documents,
I knew I should have used the longer explanation.
From what I've been able to determine, the folks who want Unique Local
Addresses usually want a block of addresses which only function on
You mean similar to the fact that the RFC1918 prefixes people use at
home can be reached because they are using NAT-PMP or uPNP on their NAT box?
Should their packets ever leak on to the public
Internet, the ULA users want them to fail.
If one does not want packets to get to the Internet then don't connect
it to the Internet.
By contrast, the registries
hand out Global Unicast Addresses. If packets with these addresses
make it to the public Internet, they'll probably work.
Unless they are firewalled or the route is simply not announced at all.
Please remember that there is no requirement for a RIR-provided prefix
to be announced onto the Internet.
I don't want to get into an argument over the security implications
(or non-implications) of addresses which are or are not publicly
routable. Suffice it to say there are networking professionals to whom
a GUA address is not a satisfactory substitute for a ULA address.
Hence, a registered ULA address IS NOT equivalent to what the RIRs
Hmmm ah, yes, "Network professionals", they obviously know what they are
doing as they call them self professional, it is at least a very nice
imaginary line they have
But yes, there are people who bill their customers a lot for things that
are not correct. People need to earn money one way or another.
IPv6 ULA (Unique Local Address) RFC4193 registration :: SixXS - IPv6 Deployment & Tunnel Broker
My "registration" was erased from that page. Don't know when. Don't
know why. But it speaks poorly for its function as a registry.
This was likely caused by the little note at the bottom:
"Prefixes which are not generated using the ULA generator will be
silently removed; ULAs are not supposed to look pretty."
Various folks are registering fd00::/48 or 'fun' stuff like
Hey, do you realize how many tries it took me to randomly generate
It is indeed possible, but it likely took you a lot of time on a very
nice fat supercomputer. Better spend your resources on something else I
In all seriousness, though, while protecting against someone blindly
registering lots of naughts is probably reasonable, a registry isn't
worth much if it won't record the address ranges folks actually choose
It is a registry for ULA addresses, these are random, not hand-picked.
If one cannot simply use the button which is located a bit above it,
then well, that is not the purpose of it.
We could have opted to allow only to register prefixes that where
generated by that output, but we chose to allow people who have
generated the prefixes locally to submit those too.
Regardless of how closely the RFC was followed in those
ranges' selection. In a sense, such a registry makes a net negative
contribution because its existence discourages the creation of another
I don't see how it makes a negative contribution. The people registering
non-ULA registered prefixes are doing so though, then again, they
automatically disappear thus it is a non-issue.
The script for generating the ULA is linked at the bottom of the page
and I am sure that anybody with 30 minutes of time can fix up a way of
storing prefixes into a file/db from a HTTP form... next to the complete
list being downloadable so if people want to clone it, it would be quite
easily done, note also that the offer for a RIR to take it over still
stands as stated on the page.