You are correct in that the "conflicts" matters at the point that the two sites want to interact in such a fashion that the expose their local use addresses to each other, now or at any time in the future.
Now if you have a random selection algorithm that truly has 2**40 bits of entropy the chances of any two identified random draws from this space having a clash remains 1 / (2**40), but if you take the total pool of such randomly drawn numbers and ask "how big does the pool need to get to lift the change of a clash within the pool above 0.5?", then the pool size is 1.24 million. If the expectation that this address format is to be used extensively for local connectivity independently of upstream connectivity then I would contend that uniqueness is essential, and the local selection methodology should not be proposed, as its uniqueness properties are flawed.
So I suppose I am saying that this is "nowhere near unique", and that if the entire idea
of this concept is to avoid the use of reused private RFC1918-styled addresses
and the associated NAT functionality, then this local selection algorithm should
not be included in this proposal.
regards,
Geoff
At 10:03 AM 28/08/2003 -0400, Hans Kruse wrote:
But don't "conflicts" matter only for separate sites that later decide to connect to each other using these addresses?
In that context 1 out of 1.24 million seems small. That does not mean we should not include that math, just that the conclusion is valid, especially for an address type that is designed to be near-unique as opposed to guaranteed unique.
--On Thursday, August 28, 2003 08:14 +1000 Geoff Huston <[EMAIL PROTECTED]> wrote:
The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd contend that this is definitely not "small" as described in the draft.
Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
