Subject: DAD or DIIDD

From: Francis Dupont <[email-masked]>
Date: Sun, 26 May 2002 16:03:16 +0200

In the Mobile IPv6, the home agent provides a neighbor discovery proxy
service (RFC 2461 7.2.8: basically it answers to Neighbor Solicitations
as for one of its addresses but with a short delay (collision avoidance)
and with always the Override flag set to zero).
So if someone tries to perform a DAD over one of these proxied addresses,
the DAD should fail. But what happens if the DAD is performed for the
associated link-local address?
To summary the debate in the mobile-ip list, the question is "the mobile
node returning at home may or may not use the link-local address which
is associated to its home address, i.e. shares the interface ID?"
This raises a question I summarize by DAD or DIIDD (Duplicated Address
Detection of Duplicated Interface ID Detection). The two references
are subtilely incoherent:

RFC 2373 (and last I-D draft-ietf-ipngwg-addr-arch-v3-07.txt):

2.5.1 Interface Identifiers

   Interface identifiers in IPv6 unicast addresses are used to identify
   interfaces on a link.  They are required to be unique on that link.
   ...
   In many cases an interface's identifier will be the same as that
   interface's link-layer address.

RFC 2462 4. PROTOCOL OVERVIEW

   For safety, all addresses must be tested for uniqueness prior to
   their assignment to an interface.  In the case of addresses created
   through stateless autoconfig, however, the uniqueness of an address
   is determined primarily by the portion of the address formed from an
   interface identifier.  Thus, if a node has already verified the
   uniqueness of a link-local address, additional addresses created from
   the same interface identifier need not be tested individually. In
   contrast, all addresses obtained manually or via stateful address
   autoconfiguration should be tested for uniqueness individually. To
   accommodate sites that believe the overhead of performing Duplicate
   Address Detection outweighs its benefits, the use of Duplicate
   Address Detection can be disabled through the administrative setting
   of a per-interface configuration flag.

and in 5.4.  Duplicate Address Detection

   ... Duplicate Address Detection MUST take
   place on all unicast addresses, regardless of whether they are
   obtained through stateful, stateless or manual configuration, with
   the exception of the following cases:

      - Duplicate Address Detection MUST NOT be performed on anycast
        addresses.

      - Each individual unicast address SHOULD be tested for uniqueness.
        However, when stateless address autoconfiguration is used,
        address uniqueness is determined solely by the interface
        identifier, assuming that subnet prefixes are assigned correctly
        (i.e., if all of an interface's addresses are generated from the
        same identifier, either all addresses or none of them will be
        duplicates). Thus, for a set of addresses formed from the same
        interface identifier, it is sufficient to check that the link-
        local address generated from the identifier is unique on the
        link. In such cases, the link-local address MUST be tested for
        uniqueness, and if no duplicate address is detected, an
        implementation MAY choose to skip Duplicate Address Detection
        for additional addresses derived from the same interface
        identifier.

We have two solutions to solve this issue:
 - the first one is to affirm that DAD is not a DIIDD:
  * removal of the uniqueness of IIDs in address architecture
    (only link-local addresses must be unique)
  * removal of the "same interface identifier" considerations in RFC 2462
  * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast addresses
  Implementation changes are:
   - for stateless configuration or stateless configuration-like mechanisms
     the only difference is the removal of the MAY in 5.4.
   - for other mechanisms the DAD detection for the address itself doesn't
     change but this choice makes clear the associated link-local address
     should not be object of a DAD.
  This is the simpler fix but IMHO not the best.

 - the other option is to change the DAD in a DIIDD:
  * no change in address architecture (cf an Erik Nordmark's argument
    about architectural purity)
  * the "a set addresses formed from the same interface identifier" is
    in totally abusive way applied even for a set of one address so
    DAD for the associated link-local address becomes mandatory and
    DAD for the address itself MAY be skipped.
  Implementation changes are:
   - for stateless configuration: no difference
   - for stateless configuration-like mechanisms: the rule to apply is
     the same than for stateless configuration (i.e. clarification)
   - for other mechanisms the DAD for the associated link-local address
     is mandatory but the DAD for the address itself becomes optional
     (or will become optional in X years for compatibility).
  This choice has a real impact on router implementations, I'd like to
  get a feed-back from router vendors (is it acceptable?)

Regards

[email-masked]

PS: I believe we should solve this issue before the next IETF meeting!
--------------------------------------------------------------------
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: [email-masked]
Date: Sun, 26 May 2002 23:26:17 +0900

>  This is the simpler fix but IMHO not the best.

	i vote for this (DAD is DAD, not DIIDD).  this is future-proven even
	if we have other address architecture (which does not use /64).

itojun

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Sun, 26 May 2002 13:27:32 -0700

Francis, is the following question equivalent to what you are asking ?

Does the Home Agent do a Neighbor Advertisement proxy for 
link-local addresses of mobile nodes which are away ? 

Related question, does MIPv6 allow link-local addresses as Home
Addresses ? 
The mobile node, when it returns may use a different interface to
connect to the home network. The Home Agent does not know how many
interfaces the mobile device has, nor should it.  

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Sunday, May 26, 2002 7:03 AM
To: [email-masked]
Subject: DAD or DIIDD

So if someone tries to perform a DAD over one of these proxied
addresses,

We have two solutions to solve this issue:
 - the first one is to affirm that DAD is not a DIIDD:
  * removal of the uniqueness of IIDs in address architecture
    (only link-local addresses must be unique)
  * removal of the "same interface identifier" considerations in RFC
2462
  * DAD becomes mandatory (i.e. SHOULD -> MUST in 5.4) for unicast
addresses
  Implementation changes are:
   - for stateless configuration or stateless configuration-like
mechanisms
     the only difference is the removal of the MAY in 5.4.
   - for other mechanisms the DAD detection for the address itself
doesn't
     change but this choice makes clear the associated link-local
address
     should not be object of a DAD.
  This is the simpler fix but IMHO not the best.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 27 May 2002 07:13:53 +0200

In your previous mail you wrote:

=> no, my question is a general one.

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Mon, 27 May 2002 01:00:20 -0700

So, should/does the HA proxy for the link-local address in the home network
?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Francis Dupont
Sent: Sunday, May 26, 2002 10:14 PM
To: Dr. Subrata Goswami
Cc: [email-masked]
Subject: Re: DAD or DIIDD

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 May 2002 09:50:40 +0200 (CEST)

>     about architectural purity)

FWIW My brief note on the mobile-ip list didn't really argue for one option
or the other (of the two options that you've carefully analyzed) but merely
point out that the mobile-ip discussion wasn't consistent with the text,
and as I understand it, the intent in RFC 2373.

I personally think the simpler approach of just saying that we do DAD
(and not DIIDD) makes sense at this point in time.

  Erik