Hi Margaret,

To the technical discourse below.

> -----Original Message-----
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 12:05 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: DAD vs. DIID
> 
> 
> 
> Hi Robert,
> 
> >Though, it is not entirely clear to me why
> >the /subnet IID uniqueness rather than the /link
> >uniqueness makes the case of privacy addresses easier.
> 
> To ensure IID uniqueness on a link, a node that implements
> privacy addresses would need to generate a link-local 
> address for each randomly generated IID (in addition to the
> global address generated for privacy), perform DAD on
> that address, and maintain that address for the lifetime
> of the privacy address in order to respond to other nodes'
> DAD messages.

A global prefix can use the same link-local address EUI again.
I have to now go check but I think the only requirement is not duplicate the linklocal 
address but the EUI of that address can be reused by non-link-local addresses.
Why does this not solve the privacy issue?

thanks
/jim

> 
> If we only require IIDs to be unique within a subnet, 
> a node that implements privacy addresses will only need
> to generate the single privacy address and perform
> DAD for that address.
> 
> As currently document (prior to the discussed changes)
> the privacy document is incompatible, in this minor way,
> with the addressing architecture and the autoconfiguration
> documents.  We had two options for what to change:
> 
>          - Relax the uniqueness restriction in the 
>                  addressing architecture, and make
>                  a corresponding change to the 
>                  autoconfiguration document.
>          -OR-
>          - Modify the privacy address document to 
>                  require the creation and maintenance of
>                  link-local addresses, as described above.
> 
> We had a consensus within the room in Yokohama to choose
> the first option, and we are currently checking that
> consenus with the list.
> 
> Margaret
> 
> 
> 
> 
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------

Reply via email to