[Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

Wed Apr 21 22:00:51 UTC 2010

On Wed, 21 Apr 2010 09:11:38 -0700
David Conrad <drc at virtualized.org> wrote:

> On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote:
> > yes... for those less willing to search: "Unique Addresses are Good"
> > ...
> > This does seem to be pretty much exactly my point (their point I suppose)
> 
> Yup.  Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing.  It was a bit of a "War of RFCs" (1597, 1627, 1814, 1918).
> 
> My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet.  I guess I don't really see the harm... 
> 

That's not what I recollect when the site-local/ULA discussions were
going on in 2002. Specifically, ULA-Cs were to address the concern of
some people that the statistical possibility of collisions was too
high, and therefore they wanted to be assured of global ULA uniqueness
via central registry. The chance of collision is quite low - from
RFC4193, section 3.2.3,

"  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."

with 'connections' meaning backdoor links.

Traditional, non-ULA-Cs would do the job your talking about fine.

Regards,
Mark.