using "reserved" IPv6 space

Stephen Sprunk stephen at
Thu Jul 19 17:19:38 UTC 2012

On 18-Jul-12 13:07, Saku Ytti wrote:
> On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
>> Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful.
> If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers.

In my experience, pointing at RFCs is rarely how disputes are resolved
in the real world.

> Other potential problem with RFC, if you have software to generate two, if software runs parallel, it may generate same prefixes.

It is incredibly unlikely, and that is all RFC 4193 claims to offer:
/statistically /unique addresses.  If you want /provably/ unique
addresses, use GUAs--or lobby for ULA-C, which to date has been soundly
rejected for lack of usefulness.

> IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some cheapskates were assigning themselves 'free' OUIs from end of the space, confident it'll never collide. So duplicate OUIs can happen. Also some NIC vendors ship with non-unique MAC.

You'd still need two systems with duplicate MACs to run the algorithm at
exactly the same timestamp, which IIRC has a resolution of 2^-32 seconds.

> What makes RFC method good?

RFC 4193 doesn't mandate any particular algorithm; it just provides an
example that was designed to be easily implemented and used.  You can
use another RNG if you wish.


Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2312 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the NANOG mailing list