On Sun, 25 Jul 2010 11:40:19 +0300 Saku Ytti <saku@ytti.fi> wrote:
On (2010-07-25 17:32 +1000), Karl Auer wrote:
The risk of a ULA prefix conflict is for *all practical purposes* zero.
http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+
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 to exchange. 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 2 1.81*10^-12 10 4.54*10^-11 100 4.54*10^-09 1000 4.54*10^-07 10000 4.54*10^-05 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.
If your IT staff includes personnel who've done painful renumbering due to M&A, there is good chance they'll allocate random, otherwise they'll likely opt for short and memorable network, as they did with RFC1918. Just because we get IPv6, doesn't mean people will get sudden burst of insight in design and engineering.
-- ++ytti