Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Lorenzo Colitti writes:
> On Thu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter <
> [e-mail]> wrote:
> 
> > > 2. A piece of remarkably bad luck, rather less likely than
> > >> winning any lottery I'm aware of.
> >
> 
> Can you elaborate on exactly how bad this luck is as a function of how many
> ULA prefixes you use your organization?

>From RFC4193 (1 in x added by myself).

      Connections      Probability of Collision

          2                1.81*10^-12 (1 in 552486187845)
         10                4.54*10^-11 (1 in 22026431718)
        100                4.54*10^-09 (1 in 220264317)
       1000                4.54*10^-07 (1 in 2202643)
      10000                4.54*10^-05 (1 in 22026)

> For example - if two large organizations that each use 200 ULA /48s (one
> per site) merge, what is the chance that one of them will collide?
> 
> I don't feel it's satisfactory to say "the probability of a collision is
> low" without saying how low it actually is. In fact, I think the draft
> should not be published without giving a few examples of these numbers. If
> *nobody* among the authors or on this list knows what the numbers actually
> are, then we should not advocate using ULAs. It is not good engineering
> practice to recommend something that you do not understand.
> 
> > You assume that people will actually follow the rules instead of saying
> > > "let's just do this like IPv4, and use NAT at the border".
> >
> > If CERs do the right thing the ULA prefix will be generated
> > correctly. But you're right, there will be a generation of
> > old-time IPv4 operators who will do exactly that whatever we
> > put in RFCs.
> 
> I'm not talking about home networks here, I'm talking about corporate IT
> environments.

Which should have trained staff who should know better.

If you have 200 odd sites pick the top 32 bits of the 40 bits
randomly and allocate the bottom 8 bits sequentually.  That doesn't
change the probability of collision when connecting to other sites
though the amount of work if there is a collision is likely to be
more. It avoids the top 32 bits being zeros and helps with human
factors like wanting address space to be clumped.

fde9:4d65:f9XX:: is just as easy to work with as fd00:0:XX::
especially when you are likely to have +200 GUA prefixes as well
to deal with which won't be sequentually assigned.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]