Addressing plan exercise for our IPv6 course
kauer at biplane.com.au
Sat Jul 24 19:42:03 CDT 2010
On Sat, 2010-07-24 at 14:07 -0500, Jack Bates wrote:
> > The chance that any
> > random prefix will conflict with any chosen prefix is very, very small.
> > The chance that two conflicting prefixes would belong to entities that
> > will ever actually interact is even smaller. Makes it an interesting
> > question as to whether the managed range is really necessary at all.
> 1) While the chance of conflict is small, it is not non-existent, and
> when the interaction does occur and a conflict does arise, there may be
> huge costs involved. Random is fine for small deployments. It is a
> horrifying prospect for a 500+ subnet network.
If two (or four, or ten, or a thousand) ULA prefixes are chosen
randomly, the chance that any will conflict with any others is far, far
less than the chance that your staff will make a terrible, disastrous
mistake that puts you out of commission for weeks. And if you happen to
have contingency plans for that, they will do just fine for dealing with
a ULA conflict.
And of course, to be an actual problem the conflicting prefixes have to
be in use by entities whose networks actually interact. Within an
administrative domain, uniqueness can be guaranteed anyway.
Winning a lottery is *far* more likely than that a randomly chosen
prefix from the ULA range will conflict with any other prefix in the
same range, randomly chosen or not.
 A ULA conflict is generally not going to require instant remedial
action. People planning interaction at a network level will (one
hopes!) do basic stuff like checking what prefixes are in use on
the two networks.
 Depending on the number of "players" in each "game", anything from
hundreds of times more likely to millions of times more likely.
Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the NANOG