Subject: DAD and unique ID on link?

From: Markku Savela <[email-masked]>
Date: Wed, 6 Mar 2002 12:12:06 +0200

Last year, in Seattle, I asked that RFC-2462 should be changed so that
at any specific point of time, the id-part of address should be unique
for each host on the link.

That is, it should not be legal for two hosts on same link to use same
ID part of the IPv6-address, regardless of the prefix.

The main reason for this request is that, if id alone is not required
to be unique on link, then *EVERY HOST* on the link must do DAD on
every assigned id on every new prefix it sees from RA. On a link with
many nodes, this causes a flood of DAD's after RA! [a host may have
multilple ID's due to privacy drafts, and due other reasons].

Apparently my request has been totally forgotten. It's really a minor
issue, and should just be clarified.

*********
Do I have to write a new modified draft of RFC-2462 to get this issue
hanndled? Or, how to proceed on this?
*********

I've coded our stack do what "aggressive ID defendign", which is
basicly: when DAD arrives (NS with src=::),

 1) if target is my valid address, reply with NA

 2) if target my tentative address, declare it duplicate

--- up to this point, this is the normal DAD processing. The following
    step is my "tweak"

 3) if target is not may address (valid or tentative), but if the ID
    part of the target matches any of my valid addresses, I will reply
    with NA as if the tested address were mine (regardless of the
    prefix in target).

So far, the only thing that seems to break, is TAHI tests in prefix
lifetime checks, where it uses DAD NS to see if I actually deleted the
prefix. (If it used normal NS to test this, everything would go ok).

--------------------------------------------------------------------
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: Thomas Narten <[email-masked]>
Date: Fri, 08 Mar 2002 14:10:17 -0500

Note: folks may want to reread the thread from last year on this topic
before commenting. I've appended it below for convenience.

> for each host on the link.

This is one solution to the problem. But first, is there an
understanding and agreement on what the problem is that needs fixing?
(more below).

> ID part of the IPv6-address, regardless of the prefix.

Why? Note that this is a solution to the problem, but may be more
restrictive a solution than is necessary to address the actual problem
at hand.

> multilple ID's due to privacy drafts, and due other reasons].

Actually, I made a proposal in which one would not need to run DAD on
addresses other than link-local if the ids were globally unique (e.g.,
generated from the EUI-64 identifier). One would still need to run DAD
on other addresses (e.g., temprorary addresses).

It seems to me that your proposal would result in the running of DAD
in exactly the same situations. I.e, it would not eliminate the need
to run DAD on all temporary addresses, for example. Right?

> issue, and should just be clarified.

Not totally forgotten, but no concrete action either. :-(

Thomas

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

	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)

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

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]>
To: [email-masked]
CC: [email-masked], [email-masked]
Date: Sat, 2 Jun 2001 04:44:38 +0300
Subject: Re: DAD

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

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

From: "Sellers, Julian P" <[email-masked]>
To: "'Thomas Narten'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
Date: Tue, 5 Jun 2001 16:04:13 -0500 
Subject: RE: DAD 

Thomas,

Is there a problem with requiring nodes to perform DAD on the link-local
address generated from a given interface identifier, even if they only want
to use the site-local or the global address?  That's what I thought the
following sentences from 5.4 of RFC 2462 required:

        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.

It's not clear to me what the qualifier "In such cases" refers to.  Maybe
this paragraph just needs to state clearly that

     - If a node has successfully performed DAD on a link-local address, the
node has the
       right to all addresses on the same link that contain the same
interface identifier.
     - If a node has not performed DAD on the link-local address, or if the
link-local
       address has failed DAD, the node must not use any address on that
link generated with
       the same interface identifier.

Julian

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> Sent: Friday, June 01, 2001 1:47 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: DAD 
> 
> 
> 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: "Brian Zill" <[email-masked]>
To: "Sellers, Julian P" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 5 Jun 2001 16:51:53 -0700
Subject: RE: DAD 
Thread-Topic: DAD 
thread-index: AcDuBCKGkPjmAWCZROiV02r53J3DrQAFXQlA

Julian,

When this idea was suggested at the Interim Meeting, several people
expressed concern about needing to have a link-local address for every
interface identifier you might be using.  A node may want to have a
large number of global addresses, for example, and the overhead of
requiring that it keep a corresponding link-local address for each might
be prohibitive.  I think I'd prefer to just perfom DAD on all the global
addresses instead.  It's the same amount of DADing going on, and you
don't need to keep all those link-local addresses around.

--Brian

> -----Original Message-----
> From: Sellers, Julian P [mailto:[email-masked]] 
> Sent: Tuesday, 05 June, 2001 14:04
> To: 'Thomas Narten'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: DAD 
> 
> 
> Thomas,
> 
> Is there a problem with requiring nodes to perform DAD on the 
> link-local address generated from a given interface 
> identifier, even if they only want to use the site-local or 
> the global address?  That's what I thought the following 
> sentences from 5.4 of RFC 2462 required:
> 
>         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.
> 
> It's not clear to me what the qualifier "In such cases" 
> refers to.  Maybe this paragraph just needs to state clearly that
> 
>      - If a node has successfully performed DAD on a 
> link-local address, the node has the
>        right to all addresses on the same link that contain 
> the same interface identifier.
>      - If a node has not performed DAD on the link-local 
> address, or if the link-local
>        address has failed DAD, the node must not use any 
> address on that link generated with
>        the same interface identifier.
> 
> Julian

From: Markku Savela <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Date: Wed, 6 Jun 2001 09:14:55 +0300
Subject: Re: DAD

> From: "Brian Zill" <[email-masked]>

> When this idea was suggested at the Interim Meeting, several people
> expressed concern about needing to have a link-local address for every
> interface identifier you might be using.  A node may want to have a
> large number of global addresses, for example, and the overhead of
> requiring that it keep a corresponding link-local address for each might
> be prohibitive.  I think I'd prefer to just perfom DAD on all the global
> addresses instead.  It's the same amount of DADing going on, and you
> don't need to keep all those link-local addresses around.

My proposal, doing the DAD related comparison only with the ID part,
solves the same problem, but lets you do single DAD / Id, regardless
of the number of prefixes you combine with this id. And, you don't
need to generate link-local address, if you are not using it.

There was some concern about the backwards compatibility, but I
*still* cannot see this introducing any more problems than what
already exists legally by the current specification, where you can
have hosts reserving ID for all combinations by DAD on link local, and
hosts that don't do that.

And, if you change specification, might as well change it to what I
proposed :-).

-- 
Markku Savela <[email-masked]>

---

From: Markku Savela <[email-masked]>
Date: Mon, 11 Mar 2002 15:19:05 +0200

> on other addresses (e.g., temprorary addresses).

I have some mild uneasines about solutions which require the IP layer
to be aware of internal structure of the interface identifier (like
whether it is EUI-64 or not).

Of course, this leads into implementation logic, where the stack must
always ask the network interface to give id (in case of EUI-64), and
additionally, there would be need for API to ask random ID from
interface. But, I prefer such solution, because then interface ID just
always just a string of bits for the stack.

Btw, amusingly I stumbled on 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. ....

This sounds good to me, exactly what I need :-)