nanog mailing list archives
Re: Re: IPv6 fc00::/7 — Unique local addresses
From: Mark Andrews <marka () isc org>
Date: Thu, 21 Oct 2010 12:48:45 +1100
In message <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9 () delong com>, Owen DeLong write s:
On Oct 20, 2010, at 5:29 PM, Mark Smith wrote:On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain <deepak () ai net> wrote: =20Use a pseudo random number, not follow bad examples. Where are these examples? I'd be curious as to what they say regarding why they =haven'tfollowed the pseudo random number requirement. =20Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'dmakethe address quite unreadable though. =20Unique Local IPv6 Unicast Addresses http://tools.ietf.org/rfc/rfc4193.txt =20=20 [snipped a bunch of stuff above].=20 =20 According to the RFC:=20 =20 3.2 =20 The local assignments are self-generated and do not need any =centralcoordination or assignment, but have an extremely high probability =ofbeing unique. =20 3.2.1. Locally Assigned Global IDs =20 Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is =ahigh probability of uniqueness. =20 The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network =numberedusing such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned =prefixallocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such =networks.=20 ---- =20 Global ID in this case means the 40 bit pseudo random thing. The =point here is, we are all supposed to pick our own poison and pray that = we are unique.=20 The chance of collision is dependent on both the randomness of 40 bits *and* how interconnected the ULA domains are. You'll have to sin a lot =to be that unlucky.=20 Here's the table from the RFC showing the odds of collision based on =interconnectedness -=20 The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. =20 Connections Probability of Collision =20 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 =20 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. =20 =20Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. =Anyway, the SIXXS tool seems pretty slick.=20=20 One thing I'm not keen on that sixxs have done is to create a =voluntaryregistry of the non-central ULAs. By creating a registry, I think some people who use it will then think that their ULA prefix is now guaranteed globally unique and is theirs forever. If there ever was a collision, those people are likely to point to that completely voluntary registry and say "I had it first" and are likely to refuse to accept that the voluntary registry has no status or authority over the random ULA address space. =20Which is part one of the three things that have to happen to make ULA really bad for the internet. Part 2 will be when the first provider accepts a large sum of money to route it within their public network between multiple sites owned by the same customer.
They can do that without needing to pay. They just setup tunnels between the sites. Alternatively the ISP provides virtual circuits between the sites for a small on going fee to cover the additional administrative costs and bills on the aggregate traffic across all the circuits to each site. The ISP doesn't need to accept ULA routes to cross connect the sites. It's not like ISP's don't provide virtual circuits today to cross connect parts of companies. Or companies don't run VPN tunnels between sites today.
Part 3 will be when that same provider (or some other provider in the same boat) takes the next step and starts trading routes of ULA space with other provider(s). At that point, ULA =3D GUA without policy =3D very bad thing (tm). Since feature creep of this form is kind of a given in internet history, I have no reason to believe it won't happen eventually with ULA. Owen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka () isc org
Current thread:
- Re: IPv6 fc00::/7 — Unique local addresses, (continued)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 20)
- Re: IPv6 fc00::/7 — Unique local addresses Mark Smith (Oct 20)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 21)
- Re: Re: IPv6 fc00::/7 — Unique local addresses Mark Andrews (Oct 21)
- RE: Re: IPv6 fc00::/7 - Unique local addresses George Bonser (Oct 21)
- Re: IPv6 fc00::/7 - Unique local addresses Jack Bates (Oct 21)
- Re: IPv6 fc00::/7 - Unique local addresses Mark Andrews (Oct 21)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 21)
- Re: Re: IPv6 fc00::/7 — Unique local addresses Mark Andrews (Oct 21)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 25)
- Re: Re: IPv6 fc00::/7 — Unique local addresses Mark Andrews (Oct 20)
- Re: IPv6 fc00::/7 — Unique local addresses Matthew Kaufman (Oct 20)
- Re: IPv6 fc00::/7 — Unique local addresses Graham Beneke (Oct 20)
- Re: IPv6 fc00::/7 ? Unique local addresses Adrian Chadd (Oct 20)
- Re: IPv6 fc00::/7 ? Unique local addresses Joel Jaeggli (Oct 20)
- Re: IPv6 fc00::/7 ? Unique local addresses Mark Smith (Oct 20)
- Re: IPv6 fc00::/7 — Unique local addresses Mark Smith (Oct 20)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 21)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 21)
- Re: IPv6 fc00::/7 — Unique local addresses Brandon Ross (Oct 21)
- Re: IPv6 fc00::/7 — Unique local addresses Owen DeLong (Oct 21)