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. S -- 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
smime.p7s
Description: S/MIME Cryptographic Signature
