On Sun, Nov 09, 2003 at 08:49:40PM +0900, Jun-ichiro itojun Hagino wrote:
>
> - it is not expected to be routable, however, it will be treated
> as if it is a global address. therefore it is likely to be leak out.
> 1.0 asserts that "even if it leaks out there's no conflict", but
> "no conflict" is not enough - we do need to be 100% sure there's no
> leak out, otherwise it is unacceptable.
I don't think we'd ever get 100% confidence of zero leakage, but that shouldn't
deter us from having a site-local addressing scheme that at least cures the
other major problem of ambiguity in the addresses. I think the Hinden draft
can only fix the ambiguity problem. But if people use Hinden-draft the
leakage is more readily traced.
As I've pointed out a number of times the Hinden draft does not remove ambiguity
completely, given its specification of a local use algorithm. It is not completely
clear to me that the algorithm presented in the draft is a robust way to assess
the probability of collision - the analysis I undertook and documented
indicated that any 'perfectly' random selection algorithm, where one global
id was as likely as any other to be generated each time the algorithm
was run, would have a probability greater than 0.5 that at least 2
outcomes were identical once 1.24 million selection outcomes were
drawn from such a 'perfectly' random algorithm.
'no conflict' as an absolute assertion, as distinct form a prediction based
on probabilities and the degree of randomness of a random draw
algorithm that may or may not be used by end sites for global id selection
("after all its local use - so maybe I'll just save a bit of time and use an id
of '1' in my local config" :-( ) is not what the local use part of this draft is
actually providing here.
If you wanted to have an absolute assurance that no collisions occur in this space then it is necessary to drop the local draw section of the proposal and manage the entire space using the central registry draw mechanism.
So I think the "cures the other major problem of ambiguity" is not an entirely technically accurate statement - "mitigates" or even "provides some increased level of assurance" is a more precise phrase here.
And maybe that's adequate, or maybe not.
After thinking about this and looking at the evident need to make some progress
here I'd like to believe that this level of resolution of potential ambiguity
is adequate, given that there is always the option to use a central registry draw to
obtain a global id that is assuredly unique.
My other issues with the current rev of the draft are still on the table, and of course
I'd be happy to work with the authors to come up with some revised words that may find
some reasonable (rough) wg consensus, and still remain within the overall spirit
and intent of this proposal.
Geoff
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
