IPv6 fc00::/7 — Unique local addresses

Thu Oct 21 00:29:01 UTC 2010

On Wed, 20 Oct 2010 19:39:19 -0400
Deepak Jain <deepak at ai.net> wrote:

> > Use 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't
> > followed the pseudo random number requirement.
> > 
> > > Use something like fd00::1234, or incorporate
> > > something like the interface's MAC address into the address? It'd
> > make
> > > the address quite unreadable though.
> > >
> > Unique Local IPv6 Unicast Addresses
> > http://tools.ietf.org/rfc/rfc4193.txt
> > 
> 
> [snipped a bunch of stuff above]. 
> 
> According to the RFC: 
> 
> 3.2
> 
>    The local assignments are self-generated and do not need any central
>    coordination or assignment, but have an extremely high probability of
>    being unique.
> 
> 3.2.1.  Locally Assigned Global IDs
> 
>    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 a
>    high probability of uniqueness.
> 
>    The use of a pseudo-random algorithm to generate Global IDs in the
>    locally assigned prefix gives an assurance that any network numbered
>    using such a prefix is highly unlikely to have that address space
>    clash with any other network that has another locally assigned prefix
>    allocated 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.
> 
> ----
> 
> 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.

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.

Here's the table from the RFC showing the odds of collision based on interconnectedness -

 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.

> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick.
> 

One thing I'm not keen on that sixxs have done is to create a voluntary
registry 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.

There also doesn't seem to be any limiting of the number of prefixes.
In an isolated network, which is where ULAs are supposed to be used,
it's far less of a problem, because the only time the chance of
collision occurs is if you interconnect with somebody else's ULA
domain. However, as this sixxs registry implies it is a global one, and
therefore there is a single instance of the fd::/8 address space,
limiting the number of prefixes that are assigned would seem to me to
be good idea. When I see examples such as -

fddd:7927:58e::/48	Steven Sorel	Deticon Networks	http://deticon.net
fd85:5d1d:c00b::/48	Steven Sorel	Deticon Networks	http://deticon.net
fda1:9347:699f::/48	Steven Sorel	Deticon Networks	http://deticon.net
fd41:eda2:4b7b::/48	Steven Sorel	Deticon Networks	http://deticon.net
fd58:fe0f:8706::/48	Steven Sorel	Deticon Networks	http://deticon.net
fd6a:3128:2a1d::/48	Steven Sorel	Deticon Networks	http://deticon.net
fdb0:8025:2463::/48	Steven Sorel	Deticon Networks        http://deticon.net

or 458 752 subnets, and http://deticon.net isn't reachable via IPv6 or
IPv4 (and hasn't been for quite a while - I checked a few months ago
when I discovered the registry), it seems to me that people have
already misunderstood what it's purpose is, and that the database is
already polluted with invalid entries that can't be verified for
existence, and which also can't be expired via some invalidation
mechanism, such as lack of payment of annual fees.

Regards,
Mark.