> The risk of a ULA prefix conflict is for *all practical purposes* zero.
It wouldn't puke nice graph with 'n', it did try, but never finished.
So if there are million assigned ULA's there is 36.5% chance of collision, if
formula is right.
That's duplication, not collision. Collision only occurs when two ULA
domains want to interconnect, and have duplicate routes they would like
Here is what the RFC says about odds -
3.2.3. Analysis of the Uniqueness of Global IDs
The selection of a pseudo random Global ID is similar to the
selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
[RTP]. This analysis is adapted from that document.
Since Global IDs are chosen randomly (and independently), it is
possible that separate networks have chosen the same Global ID. For
any given network, with one or more random Global IDs, that has
inter-connections to other such networks, having a total of N such
IDs, the probability that two or more of these IDs will collide can
be approximated using the formula:
P = 1 - exp(-N**2 / 2**(L+1))
where P is the probability of collision, N is the number of
interconnected Global IDs, and L is the length of the Global ID.
The following table shows the probability of a collision for a range
of connections using a 40-bit Global ID field.
Connections Probability of Collision
Based on this analysis, the uniqueness of locally generated Global
IDs is adequate for sites planning a small to moderate amount of
inter-site communication using locally generated Global IDs.
If operator fscks-up their residential DSL product, lets say the assign all the
/128 user could want, but from single shared /64 subnet, not routing dedicated
/48 to each customer. Users who need to route, will want solution and some
vendor will step in, providing router which will auto-assign ULA + NAT66, will
that vendor sell million copies of said CPE?
But I don't think it is interesting to discuss the random chance of collisions,
as human factor will guarantee collisions, many people will assign fd::/48 to
get short and memorable addresses in their network. (You've made your bed, now
lie in it.)
That bed was called "site locals", and the prefix was fec0::/10. If two
separate organisations choose to make ULAs effectively site locals, and
then join their ULA domains, then they deserve the pain they'll get
because they haven't followed the RFC4193 formula.
At the end of the day you can't stop people doing stupid things unless
you take away the variables that they can set. If people are arguing
that ULA specs won't be followed correctly, then any other IPv6 spec
variable may also not be set correctly by the same person. Ultimately
that means that incompetent networking people are running the network.
I don't think you can use that as a valid reason to dismiss ULAs, and
then not use it to dismiss the whole of IPv6 *and* IPv4.