Steve,

Let me clarify my point:
    u=0 => RFC3041, Manual, DHCPv6 or RFC2472 (4.1)
RFC3041 => u=0

What i am trying to say is that despite that u=0 doesn't necessary mean
that RFC3041 is in use. In practice, it could be the case that a high
number of those IID are using RFC3041 and hence the anonimity set is not
going to be big enough. In an environment where it is known not to be
DHCPv6 we end with P(u=0 => RFC3041) ~ 1.

I still haven't seen a strong justification of why a IPv6 address should
include a bit "claiming" its global uniqueness. I know it is a loooong
time discussion but still i don't see that is justified.

I rather prefer an approach that RFC3041 is the default for all the nodes
and the nodes that want to "opt-in" to have a global unique IID are free
to do it so.

I want to stick to Erik's question and i agree in the value of having
certain reserved bits in the IID but "how to use those bits" and "its
collateral  implications" (for privacy observability for example) should
be discussed out of RFC2473.

Agreed?

/aep

On Wed, 13 Mar 2002, Steve Deering wrote:

> At 10:51 AM +0100 3/13/02, Alberto Escudero-Pascual wrote:
> >I want to stick to the question of Erik but i argue why nodes for example
> >that want to use a privacy extension (RFC3041) have to indicate that their
> >IID is not EUI-64 based and hence the use of the privacy extension is
> >observable.
>
> Alberto,
>
> The u bit in the current IID definition indicates whether or not the
> IID can be considered globally unique.  The zero value (implying *not*
> globally unique) is used not only for randomly-generated ("privacy")
> IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP
> that are not derived from the node's IEEE-802 or EUI-64 address.  In
> other words, u=0 does *not* mean randomly generated; it means not-
> globally-unique.
>
> Steve
>

-- 
--------------------------------------------------------------------------
That you are not paranoid, it doesn't mean that they are not watching you!
http://www.it.kth.se/~aep


--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to