Subject: DAD

From: [email-masked]
Date: Sat, 02 Jun 2001 01:13:25 +0900

at the interim meeting, there was a discussion on DAD (whether
	it is mandatory for all address, or we can do it just for link-local
	and omit for globals that share the same interface id).

	the original text is in the second bullet.  i believe it is a bit
	confusing at best.  the first sentence recommends (SHOULD)
	running DAD on every address you have, and then the following sentences
	say that you MAY omit it in certain conditions.  my suggestion is to
	keep the first sentence and remove the exception sentences.

	it still leaves me a bit fuzzy feeling as DAD works only if everyone
	does it - so MUST sounds necessary to me for DAD to be useful.
	DAD does not always work anyways, due to network partition or ethernet
	chip initialization delays.  so i'm okay with SHOULD on the first line.

	in was mentioned that TAHI test files "FAILED" if people omits DAD.
	first of all I would like to comment that we cannot take test result
	in binary form - when we see "FAILED", we need to diagnose result
	carefully.  it may be an implementation choice, it may be TAHI's
	interpretation, whatever.  when TAHI guys run their test on KAME stack,
	they give detailed interpretation on why they marked some test "FAIL"
	(if they have enough time).  i guess the result "FAILED" for the DAD
	test is based on the following interpretation on "SHOULD" the first
	sentence.

RFC2119
>3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.

itojun

5.4.  Duplicate Address Detection

   Duplicate Address Detection is performed on unicast addresses prior
   to assigning them to an interface whose DupAddrDetectTransmits
   variable is greater than zero. 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.

(snip)
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Fri, 1 Jun 2001 19:37:03 +0300 (EEST)

> 	chip initialization delays.  so i'm okay with SHOULD on the first line.
[snip rest]

The partitioning reminds me of a fact I've been meaning to ask opinions
about.

If a link was partitioned when two hosts did DAD, and the network heals
up, what happens?  Is there any way to recover from the situation?
Are the both nodes screwed until either interface is brought up and down,
enabling DAD?

Which brings me to an idea: some implementations (routers, usually) have
knowledge of link status (cable is/is not plugged in, is broken etc.).
For these, would it make sense to defer DAD until link goes up and keep
the address tentative until then?  If a lot of implementations did this,
the consequences of broken linkcould be smaller.  Nodes have no way of
knowing if network was partitioned upstream, of course.

Also, it could be possible to redo DAD after link status cycled, but this
could add too much traffic to the network and might open a door for easier
address stealing.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Jun 2001 19:01:39 +0200

In your previous mail you wrote:

=> the situation is not so simple because a common case (in wireless networks)
is partial connectivity (and of course this can be highly dynamic).

Regards

[email-masked]

PS: as I have said yesterday I believe that DID (ie. your proposal)
is both better (ie. catch more cases) and simpler than current DAD.
But DAD is a DS so it will be hard to change/improve it...
PPS: in the real word DID/DAD will detect only mistakes in manual
router configurations (this is what the past has shown, of course
we don't (yet :-) know the future and privacy stuff can change this).
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Fri, 1 Jun 2001 20:23:22 +0200 (CEST)

> Are the both nodes screwed until either interface is brought up and down,

Yes, and you can't easily tell that you're hosed.

At some point in time we might have discussed having 3rd parties
doing address resolution detect when a multicast NS results in two
NAs containing different addresses and sound the alarm.
But I think the use fo proxy NAs (e.g. for mobile IP on the home link)
makes this type of 3rd party discovery tricky.
 
> knowing if network was partitioned upstream, of course.

That only helps at the attachment to the link - doesn't help e.g. if
two Ethernet hubs/switches loose the link between them.

> could add too much traffic to the network and might open a door for easier

Sure, an implementation can do DAD once the link is up for links that
have a notion of being up vs. down.

But that doesn't help with  internal partitions on the link.

  Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Jun 2001 14:46:39 -0400

Here is a suggestion for how to plug the main vulnerabilities that
were discussed in the meeting.

Problem (as I understand it): the main issue is that there are some
(non-link local scope) addresses that may be assigned to an interface
(e.g., manually configured, temporary addresses, DHCP assigned, etc.),
but for which there is no corresponding link-local address using the
same interface identifier. The stateless addrconf document (RFC 2462)
says that a node can skip DAD for global (and site local) scope
addresses generated from the same interface ID as the link-local
address. This opens up a potential hole where a node (doing normal
addrconf) has run DAD on the link-local address, but has not yet
configured a global-scope address using the same interface
identifier. Then, some other node (e.g., via DHCP, a temporary address
etc.) chooses the same interface identifier and creates such an
address, runs DAD successfully (since no other node is currently using
that address), and then assigns the address to its interface.  Later,
the first node (which is running normal addrconf) also generates the
address, but skips DAD, and now there are two nodes using the same
address. Oops.

Proposal: update specs to require that nodes MUST run DAD on all
addresses for which the interface identifier is NOT globally unique
(per the setting of the 'u' bit in interface identifier). DAD can be
skipped on addresses that contain IEEE EUI-64-derived interface
identifiers (and for which DAD has already been run on the
corresponding link-local address).

This means: still no need to run DAD on global addresses when doing
normal addrconf, provided the interface identifier comes from an IEEE
identifier. But one would have to run DAD for links with randomly
generated identifiers (e.g., some PPP links). One would also still
need to run DAD for temporary addresses. For DHCP addresses, we'd need
to make sure that the server sets the 'u' bit properly, and clients
would need to run DAD if the 'u' bit indicated locally unique only.

Does this solve the underlying problem in an acceptable fashion?

Thomas

---

From: Markku Savela <[email-masked]>
Date: Sat, 2 Jun 2001 04:44:38 +0300

> corresponding link-local address).

I would prefer the IPv6 address architecture leaves it open for future
address formats which do not use IEEE EUI-64 ID-format, and still have
all the machinery of Neighbor Discovery and ADDRCONF available.

Designs which force the stack to dig into insides of any id part are
very unappealing to me.

Address is n-bit prefix 128-n bit id, and as far as my current
implementation goes, the link layer may specify *any* n (0..128) to be
used [to prevent obvious replies, I do admit that the kinky values of
n=0 or n=128 may not quite work].

..although, one might consider a point-to-point link without link
layer addresses as "n=128".

-- 
Markku Savela <[email-masked]>