Subject: Re: DAD vs. DIID

From: [email-masked]
Date: Fri, 9 Aug 2002 17:41:35 +0200

Hi Margaret,

Thank you for your clarification. I now get the point.

> This change would modify the scope of that uniqueness
> to be a subnet prefix, not the whole link.  So,
> within a set of interfaces using a particular
> subnet prefix, the IID would identify a particular
> interface.
>
> (..)
>
>     OLD:    IIDs are required to be unique on a link.
>
>     NEW:    Only complete addresses are required to
>             be unique on a link.
>
> Relaxing the restriction to the second case makes
> the use of privacy addresses easier,

I understand that there is no actual need to
require /link IID uniqueness.

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.

Robert

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 09 Aug 2002 12:05:14 -0400

Hi Robert,

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

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

---

From: Markku Savela <[email-masked]>
Date: Fri, 9 Aug 2002 20:17:46 +0300

> From: Margaret Wasserman <[email-masked]>

> of the privacy address in order to respond to other nodes'

Well, that is only one possible implemetation.

Another way, when node sees DAD with ID part matching any of the nodes
ID's, it can act as if it had the address and defend it (note: this is
ONLY with DAD probes, for normal NS it replies only if address is
actually configured as whole).

This solution does not need actual generation of link local address.