> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 22, 2007 10:10 AM
> To: [email protected]
> Subject: RE: draft-ietf-ipv6-ula-central-02.txt
>
> > I couldn't agree more about less mystery and more transparency.
> > The use-case I am most interested in is Mobile Ad-Hoc Networks
> > (MANETs) in which two or more MANETs can merge (e.g., due to
> > mobility). If each MANET used ULA-C's, then they could inject
> > each others' prefixes into their IGPs with no opportunity for
> > collision. If each MANET instead used RFC4193 ULAs, then they
> > could *probably* still inject each others' prefixes. But,
> > however small the risk of collision, RFC4193 ULAs still have
> > one drawback that ULA-C's do not - uncertainty.
>
> Certainty in the abstract does not equate to certainty in the
> real world.
Yes - I have to agree with this statement.
> > So perhaps another question is whether it is too much to ask
> > for more certainty (ULA-C) and less mystery (RFC4193 ULA)?
>
> Personally, I am less certain about the probability of ULA-Cs
> being administered such that a collision will never happen
> than I am about the unlikelyhood of a collision between
> randomly assigned ULAs. -- George Mitchell
Would it make you feel more certain if the ULA-Cs were
self-generated by sites exactly as in (RFC4193, Section 3.2)
and then "registered" with a central authority that would
register the address as long as it is not a duplicate? I
don't think ('draft-ietf-ipv6-ula-central', Section 3.2)
currently says that, but it seems like it would result in
a scenario that is no worse than for RFC4193 yet with a
central authority accountable for certifying uniqueness.
That said, I would be astonished if this idea has not been
entertained and debated before.
Thanks - Fred
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------