Subject: [rfc2462bis issue 275] DAD text inconsistencies

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 23 Feb 2004 22:21:49 +0900

Since we have a discussion about optimistic DAD, this is probably a
good chance to start a related discussion for rfc2462bis.

As you know, there have been many discussions on DAD, including

- whether omitting/optimizing DAD is a good idea
- (if yes) in which case we can omit DAD
- DAD vs DIID
- ...

without getting any convergence (particularly about DAD
omission/optimization or DIID), unfortunately.

Through the past discussion and by considering the purpose of
rfc2462bis, I believe rfc2462bis is NOT the place where DAD
optimization or DAD omission or DIID should be specified (even if we
agree on introducing some of them).  And I believe we agree on this as
a base line.

Meanwhile, one source of the confusion is an unclear wording of
RFC2462.  It says in Section 5.4 that

      - Each individual unicast address SHOULD be tested for uniqueness.

and then says

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

I do not necessarily think this is inconsistent (whereas the issue
title contains "inconsistencies"), but the "MAY" following the
"SHOULD" has surely tempted people to cause the DAD related
discussions and to propose DAD omission/optimization or DIID.

In my understanding, we have basically agreed in the passed discussion
that we should honor the sense of the "SHOULD" rather than the "MAY".
(but I may be wrong here, in which case please correct me)

Having considered these points, possible resolutions *for rfc2462bis*
that I can think of are:

1. harden the requirement: Each individual unicast address MUST be
   tested for uniqueness.  No MAY for omitting the rule (i.e., remove
   it).  We can use SHOULD instead of MUST if we need compromise.

2. MUST run DAD on all addresses for which the interface identifier is
   NOT globally unique (such as non EUI-64 ID).  This is a proposal by
   Thomas Narten in June 2001. (see the issue tracker for more
   background information)

3. do nothing for this in rfc2462bis; leave Section 5.4 as is, do not
   add any text.

4. no change in the protocol specification, but add an appendix (or
   something) to discuss the issue on the effect of
   omitting/optimizing DAD.

I personally prefer option 1, because this makes the intention very
clear, avoiding further similar discussions and waste of energy.
"MUST" may be too strong for compatibility with existing
implementations, and if so, we can use "SHOULD".  (And this does even
not conflict with the proposed "optimistic DAD")

I would not take option 2, though this makes the specification a bit
clearer, since even EUI-64 IDs can collide (due to manufacturer error,
etc).

We could live with option 3.  After all, current RFC2462 does not have
an "error" on this point.  This option may be a bit irresponsible,
though, since the unclear text has caused diverging discussions
without success.

We could also live with option 4, although I do not have a concrete
idea on what should be written in the appendix.

Even though I have my own preference, I'm quite open to other
opinions.  I'd really like to make a consensus on this quickly and
move forward.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Mon, 23 Feb 2004 14:59:50 +0100

In your previous mail you wrote:

=> IMHO this is the same thing, i.e., optimizing gives the same result
than omitting.

=> the last one finished by a decision (DAD, not DIID). I asked the
WG chairs to clarify this point at a previous meeting, cf
http://www.ietf.org/proceedings/02jul/145.htm
look at "DAD vs. DIID Discussion -- Chairs", BTW slides are at
http://playground.sun.com/ipng/presentations/July2002/yokohama-dad-vs-diid.pdf

   - ...

   
   
=> I vote for this in the context of RFC 2462bis.

=> I agree.

Thanks

[email-masked]

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 24 Feb 2004 09:48:30 +1100

On 2004-02-23, Francis Dupont wrote:
> [JINMEI Tatuya wrote:]

Omitting DAD altogether removes the ability to detect and correct
address collisions, whereas optimizations such as Optimistic DAD
mean that while there may be a short term disruption the problem
will be detected and corrected.

> http://playground.sun.com/ipng/presentations/July2002/yokohama-dad-vs-diid.pdf

Which is great, and will be even better when 2461/2bis are adopted,
but there are already many implementations out there.  Thus my 
suggestion in Optimistic DAD section 3.4 that when configuring an
address PREFIX::SUFFIX, you should be sure toalso configure and
check LINKLOCAL::SUFFIX.

Is this going to be required by 'new' DAD?  I'm not 100% sure about
the DAD vs DIID changes yet.

-----Nick

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 10:17:45 +0100

=> in the real world this kind of problem cannot be corrected...
The only thing you can do is to avoid to reproduce the same error again.

Regards

PS: optimistic DAD is like optimistic russian roulette: look at in the
chamber after to check it is empty.

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Feb 2004 20:54:54 +1100

Hi Francis,

> The only thing you can do is to avoid to reproduce the same error again.

That's a rather broad statement to make,
since there may not be L2 address conflicts, and
EUI based v6 addresses may not be used.

What really matters then is the effect on (the real)
address owner's and configuring node's applications.

I think it's worth getting implementors' experience
with address conflicts with DAD, without DAD and with
optimizations.

> chamber after to check it is empty.

That's highly emotive talk which doesn't help the discussion.

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 24 Feb 2004 21:04:25 +1100

On 2004-02-24, Francis Dupont wrote:
> [Nick 'sharkey' Moore wrote:]
>    

Was there a specific non-recoverable scenario you had in mind there?

-----Nick

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 11:26:55 +0100

=> L2 address conflicts are very uncommon. Personally I never got one.
The usual problem is a config which is copied but not updated,
and the auto-conf does not save you because it is not used for every nodes.

=> usually both the real owner and the offender are dead. Murphy's law
makes the real owner an important server.

=> I am an implementor and from time to time a network manager so
I can say that:
 - address duplications happen
 - at least once DAD saved us from real trouble even the IPv6 network
   was very small at this time
So I really believe in the DAD usefulness and if you'd like to remove
or "optimize" DAD on one of my networks my answer will be "NO!".

Regards

   
   
=> the optimistic DAD is an old topic now and I believe some of us don't
(didn't? :-) understand our opinion about it.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 11:40:42 +0100

=> just ask large network managers. Address duplication is a real
nightmare to fix in the real world.

PS: as I explained already many times in this list, the decision to
omit/optimize/junk the DAD must be in the hand of the network manager,
as he is the guy who shall have to cleanup the mess when the should-not-
happen event will happen. And this is very easy, just say that the
DupAddrDetectTransmits configuration parameter MUST be set according
to the link policy (today policies are more link-type, what I'd like
to get is a per-link policy defined by the local network manager).

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Feb 2004 13:16:02 +0200

> or "optimize" DAD on one of my networks my answer will be "NO!".

I believe the optimistic DAD folks are very keen on keeping the DAD
functional. That is, it is a requirement that networks and nodes must
be able to recover from a collision situation. No one is proposing
removing DAD.

Since most folks appear to agree that any optimization is not
a part of 2462bis and that Jinmei's option 1 is reasonable, I
think we can close the issue for 2462bis.

As for the rest, I believe we should discuss optimistic or optimized
DAD schemes under a different thread, since this really has nothing
to do with 2462bis. And for that discussion, let's not label someone's
method a priori as "removal". There may be specific concerns in the
specific methods, but if that's the case then they have to be
corrected or rejected.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Feb 2004 13:22:02 +0200

> nightmare to fix in the real world.

Sure. But aren't you assuming that they have to go in and manually
recover? I believe what the optimistic or optimized DAD
folks intend to do is to provide a *protocol* that allows both
(a) faster operation and (b) recovery if a collision happens.

I am unable to say for sure if, say, draft-moore, accomplishes this goal.
It probably needs more analysis before we can be certain. However,
I do not see any obvious problems.

Note: In some cases the collisions is due to L2 address collision,
which I agree is quite troublesome. But optimistic DAD does not
appear to change anything with regards to this. If you get a collision
then you detect that with optimistic DAD as well, and then follow
2462bis rules to disable the interface, or whatever that was required.
And in many cases the address collision is not based on L2.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Feb 2004 14:04:27 +0200

Sorry to respond to my own e-mail. But I wanted to clarify one thing.
Manual recovery is fixing the problem, like reconfiguring the address.

The recovery that optimistic DAD provides is however different. It
just corrects a temporary disruption that the optimistic assumption
may have caused. Whether you have DAD or optimistic DAD running at
the bottom is insignificant to the network manager, iff optimistic DAD
detects collisions reliably.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 15:02:44 +0100

recover?

=> it is the case for IPv4 because this kind of event is very rare
so there is no need to add an automatic recover tool. But IMHO
the real question is where are these problems for? They don't come
from hazard but in 99.99% of cases from configuration errors.

   I believe what the optimistic or optimized DAD
   folks intend to do is to provide a *protocol* that allows both
   (a) faster operation and (b) recovery if a collision happens.
   
=> this is a half baked solution, i.e., either you don't want duplicates
on your network and you enforce DAD, or you accept possible problems
and you makes the live of mobile nodes (and of implementors) far easier.

=> the problem is the goal of optimistic/optimized DAD has no interest.

   Note: In some cases the collisions is due to L2 address collision,
   which I agree is quite troublesome.

=> L2 address collisions are fatal. And IMHO we should not even try to
solve them at L3 (:-).

   But optimistic DAD does not
   appear to change anything with regards to this. If you get a collision
   then you detect that with optimistic DAD as well, and then follow
   2462bis rules to disable the interface, or whatever that was required.

=> what we need is collision avoidance, no collision detection after
damage.

=> currently there are three common ways to assign addresses:
 - EUI64 based, i.e., relying on L2 address universal uniqueness
   (read my EMEI draft to use it on mobile phones too)
 - RFC 3401, i.e., relying on the "birthday" paradox
 - manual, i.e., relying on the care of node managers.
Obviously only the last one is a real source of trouble. Unfortunately
it is a common case for routers (EUI64 requires that you work only with
a mouse and cut&paste), some servers (DNS servers for instance, when you
look at http://www.root-servers.org/ you get no EUI64 based IID) and
some other cases (multi-interface KAME hosts here). But this should be
easy to avoid this case on a link dedicated to mobile nodes...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 15:13:30 +0100

Sorry to respond to my own e-mail.

=> our keyboards have large enter keys, and often more than one (:-).

   But I wanted to clarify one thing.
   Manual recovery is fixing the problem, like reconfiguring the address.
   
=> and in some cases (*all* the real cases I saw in fact) it was the
only way to fix the problem.

=> you make a hidden and wrong assumption on the real source of
the problem...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Feb 2004 15:52:57 +0100

> makes the real owner an important server.
   
   This is not going to happen in Nick's optimistic DAD draft.
   
=> I disagree: even in Nick's draft the second system has both
a service disruption and has to switch to another address.
So as to be the second system is just a matter of race Murphy's law
implies it will be the important one.

Regards

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Feb 2004 21:44:12 +1100

Hi Francis,

The procedures don't affect existing neighbour cache entries
(such as would be in place for an important server).
Additionally, the procedure cleans up cache entries for itself,
and provides for stifling of upper layer (non-)reachability indications
from the tentative address.

Maybe you're thinking about another (prior) proposal.

> or "optimize" DAD on one of my networks my answer will be "NO!".

Well I'm not sure if optimize has any sinister meanings.

An optimization doesn't necessarily remove or undermine an
existing procedure (if done correctly).

> (didn't? :-) understand our opinion about it.

Roulette aside, I'm sure that if you can shoot a
hole in the draft's technical merits, it will go away.

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 25 Feb 2004 06:38:00 +1100

On 2004-02-24, Francis Dupont wrote:
> [Greg Daley wrote:]

... and the result to the second system of an address collision
under unmodified DAD is ...?

We're talking about an extremely rare event here, an address
collision of _well-distributed addresses_, eg: 3041-like or
SEND-CGA-like addresses.  Opti-DAD explicitly excludes manually
configured addresses (although it may be used with EUI-64s).

Just how many nodes _per network_ were you thinking of having?

And when it happens, the first node may get a few stray packets
and the second node will have its address configuration delayed
by a few milliseconds -- but not for as long as it would have
taken to perform DAD anyway.   I don't see the disaster in this.

cheers,

-----Nick

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Feb 2004 16:15:07 -0800

Hi Francis,

> and you makes the live of mobile nodes (and of implementors) far easier.

So let me ask a question. If you believe optimized DAD is a half baked
solution then why isn't DAD also a half baked solution? The reason I ask
this is because both don't really do anything to get rid of address
collisons, they just provide a procedure for detecting them. The difference
is that optimized DAD is intended to fail more quickly and allow a node to
use the address while it is tentative. Now it is possible that the protocol
described in Nick's draft has some flaws that would cause problems for
detection, but I don't think that should stop us from trying to figure out
some way of improving DAD so it functions better for mobile nodes.

> => the problem is the goal of optimistic/optimized DAD has no interest.

Well, that certainly isn't the case for me, and I will take the liberty of
saying that I believe most mobile wireless service providers interested in
IPv6 would agree.

>> => what we need is collision avoidance, no collision detection after

Ah, now I believe I understand your objections better. I agree this would be
ideal, as this could replace DAD as well. Perhaps you'd like to make a
proposal? It seems like it might be difficult to provably prevent collisions
though.

>    (read my EMEI draft to use it on mobile phones too)

As I believe Nick mentions in the draft, this doesn't guarantee uniqueness
because mistakes sometimes occur in manufacturer assignment of addresses,
and there is also the possibility of attacks.

> easy to avoid this case on a link dedicated to mobile nodes...

What about DHCP? Perhaps you believe that DHCP will never be used in IPv6
networks, but there are some people who believe it will still be important.

            jak

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2004 17:38:47 +0900

>>>>> On Mon, 23 Feb 2004 22:21:49 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> good chance to start a related discussion for rfc2462bis.

(...snip...)

> not conflict with the proposed "optimistic DAD")

So far, I've not seen an objection to Option 1, and two people
(Francis and Jari) seem to agree on this approach.

So, I'd now like to propose a concrete change.  The simplest way to
implement the option would be to remove the second exception shown in
Section 5.4 of RFC2462.  That is, the revised text would be:

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. On the
   other hand, Duplicate Address Detection MUST NOT be performed on
   anycast addresses.

   The procedure for detecting duplicate addresses uses Neighbor
   Solicitation and Advertisement messages as described below...

Can we live with this simple resolution?

If yes, is the requirement of "DAD **MUST** take place" acceptable?  I
believe this is acceptable in essence, but I'd like to know this does
not cause a severe compatibility issue with existing implementations
that conform to RFC2462.

					JINMEI, Tatuya

---

From: Markku Savela <[email-masked]>
Date: Thu, 26 Feb 2004 11:46:58 +0200

> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[email-masked]>

You are ignoring the installed base. There are already out and
delivered, and in real use, implementations which do the DAD only for
the link local. And if the ID is used combined with global prefixes,
the it is assumed DAD on link local is sufficient.

This is valid as per currently valid RFC, and still consider this a
sensible implementation. Apparently, nobody else truly supports the
multiple IDs and prefixes, with full combination? In such case, doing
DAD on each new combination for each announced prefix on RA is
frightening.

And even with single id and new prefix this is not good: on RA with a
new global prefix, every node on the link is going to do DAD based on
its ID and new prefix. And, as far as I know, there is no delay
requirement here, so everyone is doing it at same time.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 26 Feb 2004 20:54:32 +1100

> (Francis and Jari) seem to agree on this approach.
[...]
> Can we live with this simple resolution?

I don't object to Option 1 either, and I think the standard has
to be made clearer on exactly what needs to be done.

> not cause a severe compatibility issue with existing implementations

My only concern would be whether or not there needs to be 
a requirement to defend LINKLOCAL::SUFFIX when configuring
UNICASTPREFIX::SUFFIX.

Otherwise, a configuring 'old DIID' node may not detect a collision
with an existing '2462-bis DAD' node, since the former will only
check the Link Local and the latter might not be defending that.

(I'm thinking here of nodes which use RFC3041-like random
or SEND-CGA-like hash generated addresses)

-----Nick

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2004 21:01:20 +0900

>>>>> On Thu, 26 Feb 2004 20:54:32 +1100, 
>>>>> "Nick 'Sharkey' Moore" <[email-masked]> said:

> or SEND-CGA-like hash generated addresses)

Sorry, I don't understand the concern...by which scenario might the
latter not be defending the link-local address?  (perhaps I don't
understand what you meant by "defend"...)

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 26 Feb 2004 23:15:08 +1100

[...]

> understand what you meant by "defend"...)

Sorry, that's me being obscure:  By 'defend' I mean 'send an NA in
response to an NS for that address from the unspecified address',
eg: to 'defend' that address as being yours.

The scenario being that under non-IID based allocations such as
RFC3041 or SEND-CGA, a node offered prefixes A, B and C may
configure different suffixes X, Y and Z ... thus the addresses
A::X, B::Y, C::Z.

This breaks the old assumption that all allocated addresses (on
a given interface) will have the same suffix.  In order to 
defend the address C::Z from 'old-style DIID' nodes, the new-style
node would have to reply to NSs for LINKLOCAL::Z too.

I'm not sure that's explicitly explained in the text (maybe I've
just missed it?)

cheers, hope that clarifies things?

-----Nick

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 26 Feb 2004 21:36:07 +0900

>>>>> On Thu, 26 Feb 2004 11:46:58 +0200, 
>>>>> Markku Savela <[email-masked]> said:

> the link local.

If I were really ignoring the installed base, I would simply declare
the new text without asking the questions (in my previous message).  I
would be happy if I could get the above comment from you while I'm
listening to others since the first message of this thread...

Anyway, any comments at this stage are, of course, welcome.

> This is valid as per currently valid RFC,

Yes, but:

> and still consider this a

basically, you seem to argue for DIID (against) DAD.  Though I agree
that DIID vs DAD is somewhat controversial and there is surely a
tradeoff between those two, I believe the wg consensus was we should
honor DAD rather than DIID (as Francis showed some pointers).  And, I
don't see the need for revisiting the discussion.

I proposed the text for rfc2462bis in my previous message because it
will make the specification simpler and clearer based on the
"consensus", and three others apparently agreed (I admit I cannot call
this a "majority" though)

Of course, it is not my goal in rfc2462bis to invalidate existing
implementations compliant to RFC2462, including those that implement
"DIID".

Fortunately, the tightened requirement will not introduce
interoperability issue (IMO): when a (global) address collide, if a
DAD node comes after a DIID node, the DAD node will detect the
duplication and stop using the address.  If a DIID node comes after a
DAD node, and the corresponding link-local address happens to not
collide, the DIID node cannot detect the duplication, and the two
nodes will continue to use the duplicate address.  This is bad, but is
not worse than the RFC2462 world.

So, I'm wondering if we can deal with this by some moderate wording.
(for example, "future implementations MUST do DAD").

> requirement here, so everyone is doing it at same time.

Hmm, this is a good point.  An obvious workaround is to impose a
random delay when the node is starting a DAD process for an address
configured by multicasted RA.

Does this kind of additional requirement make sense? > all
If so, should we include this in rfc2462bis?

					JINMEI, Tatuya

---

From: Markku Savela <[email-masked]>
Date: Thu, 26 Feb 2004 15:25:13 +0200

> don't see the need for revisiting the discussion.

Yes, DIID probably (or something similar). I believe that simplest
solution is that a specific ID value can be allowed only for single
node on the link. Any use of same ID part with any prefix by another
node should be viewed as an address collision.

I've expressed this opinion years ago, on this list and elsewhere. So
assumed my "vote" would have already been noted. But, I guess one
needs to repeat opinion at least once per week, to be noted. It is
very frustrating to see incorrect (IMHO) decisions being made by
"consensus".

---

From: Mika Liljeberg <[email-masked]>
Date: Thu, 26 Feb 2004 21:45:21 +0200

>    something) to discuss the issue on the effect of

Option 5, add the following clarification:

A node that has the configured address PREFIX::IID and follows the "DAD
all addresses" logic MUST defend FE80::IID as well as PREFIX::ID. A node
that follows the "DAD only link-local address" logic MUST defend all
addresses derived from IID.

The above will allow DAD and DIID to coexist peacefully.

My vote goes to option 5. Failing that, option 4 seems least
objectionable.

Regards,

	MikaL

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 27 Feb 2004 07:54:03 +0900 (JST)

> I can see where you are coming from: for DAD to safely
> interoperate with DIID it must send even more messages: wouldn't
> it be nice to just send a single NS/NA pair?  After all,
> DIID is already compatible with DIID.

	this i remember very precisely.  we have already discussed DIID/DAD to
	death and picked DAD already.  i don't think it necessary to open the
	topic up again.

itojun

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 27 Feb 2004 10:40:49 +1100

On 2004-02-27, Nick 'Sharkey' Moore wrote:
> 
> I'm convinced that a change needs to be made to the wording to
> resolve this issue, but I'm not sure which is the better option.

My suggested text for "DAD but interoperable with DIID":

[5.4. Duplicate Address Detection][...]

   - Each individual unicast address MUST be tested for uniqueness.

   - When configuring a global unicast address, the link-local
     address with the same suffix as that address MUST be configured
     and tested for uniqueness in order to maintain interoperability
     with RFC2462 behaviour.

-----Nick

---

From: Greg Daley <[email-masked]>
Date: Fri, 27 Feb 2004 11:10:09 +1100

Hi itojun,

I think Nick was expressing frustration in this case,
rather than proposing to adopt a bad solution.

> 	death and picked DAD already.  i don't think it necessary to open the

What we really need is a way to ensure that we can use DAD
in a way which prevents existing DIID nodes from causing
troubles.

We can tell people that DIID exists, but is deprecated, and
has to be dealt with to ensure backward compatability with
old devices.

We can handle this by ensuring that addresses which are
in use by a DAD node aren't assumed to be available by DAD
nodes. This will may need algorithmic modification in some cases.

Essentially, a newly configuring DIID node MUST send a DAD NS
for the fe80::suffix address.  This goes to the solicited
nodes' address for the suffix.

Whan the existing node has completed DAD on a prefix::suffix
address, it is already a member of the same solicited nodes'
address.

Therefore, even if it doesn't have the particular target
address configured (it hasn't got fe80::suffix configured
itself) it will see the DAD NS from the DIID node.

Since we know that nodes attempting to do DIID will do
DAD on the link-local address, any other addresses configured
for DIID should be tentative at the time.  Transmission of an
DAD defence for the currently configured prefix::suffix address
should work to prevent DAD.

If the host already posesses the fe80::suffix address, that would
be used instead (and is sufficient for defending against DIID).

Only in the case where the link local address wasn't configured
(CGA addresses for SEND, rfc-3041 addresses) would the algorithmic
modification be required.  In the SEND case, it is unlikely that
any suffix will be configured more than once on an interface
(which means only one message will respond to the DAD attempt).

In the case that the configuring node was doing full DAD for a
number of addresses with the same suffix, it will have already
joined the solicited nodes' group.   Therefore, it should receive
the DAD defence NA from the node.

Even if it hasn't already sent the DAD NS for a global prefix,
it may still receive the DAD defence NA, since it receives the
solicited nodes' datagram.

In the worst case, the defending node will transmit a defence for
both the link-local and the global prefix DAD NS's.

Greg

Greg

---

From: Greg Daley <[email-masked]>
Date: Fri, 27 Feb 2004 12:32:28 +1100

Hi Sharkey,

>      and tested for uniqueness in order to maintain interoperability

I think that configuring additional addresses which
don't match the prefix used to generate the suffix in
the CGA is going to cause problems.

(the following is simplified):
Essentially, the CGA is generated from a nonce, a prefix
and a public key.

in this case:

           prefix::PrK(Hash(Nonce,prefix,PuK)).

The recipient of the nonce and public key (provided in
SEND messages can check that the private key owner
generated the address.

If the prefix changes and the suffix stays the same:

the receiver would have fe80::PrK(Hash(Nonce,Prefix,PuK))
and the Nonce and PuK, but not the original prefix.

Unless the recipient knows the original prefix,
the hash is useless (doesn't prove anything).

The messages would have to be treated as unsecured
for SEND (unless new SEND procedures were defined).

I'm pretty sure that SEND nodes work around
unsecured messages in the case of DAD (they currently
accept a single unsecured DAD NA response.

The solution is pretty ugly though, since it relies
upon function which is hacked into SEND.

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 27 Feb 2004 13:44:08 +1100

> the CGA is going to cause problems.

Good point.  However, the MN registering A::X only needs to
defend the LL::X against DIID-compatible nodes.
I think we can assume that SEND-CGA nodes will follow the
_new_ DAD standard. So the unsecured defensive NA should be okay,
since it won't be needed against SEND-CGA nodes.

... I think.  Any SENDites want to comment?

NB:  Is there a plan for 3041bis?  It's rather bound up with
DIID too.

cheers,
-----Nick

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 Feb 2004 21:23:19 -0800

Not quite sure I entirely understand the issue, but SEND makes no change in
the basic underlying DAD algorithm. If the address suffix generated from the
key hash changes due to a change in the prefix, then the address has to be
re-DAD-ed. If the node decides to reuse the old suffix, then the address
isn't a CGA and SEND can't be used. SEND includes support for interoperation
between SEND and nonSEND nodes, so it should work if a node decides not to
use SEND.

            jak

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2004 14:32:20 +0900

>>>>> On Fri, 27 Feb 2004 13:44:08 +1100, 

> NB:  Is there a plan for 3041bis?  It's rather bound up with

A quick response.  I guess you are talking about the following part of
RFC3041:

      Note: because multiple temporary addresses are generated from the
      same associated randomized interface identifier, there is little
      benefit in running DAD on every temporary address.  This document
      recommends that DAD be run on the first address generated from a
      given randomized identifier, but that DAD be skipped on all
      subsequent addresses generated from the same randomized interface
      identifier.
(the last paragraph of Section 3.3)

However, RFC3041 actually has a successor,
draft-ietf-ipngwg-temp-addresses-v2-00.txt (expired for a long period
though),  which reversed the logic:

      Note: although multiple temporary addresses are generated from the
      same associated randomized interface identifier, DAD should still
      be run on every temporary address. Otherwise, it is possible that
      two nodes will select the same interface identifier but not detect
      the collision if they run DAD on addresses generated from
      different prefixes.
(the last paragraph of Section 3.3)

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2004 14:38:28 +0900

>>>>> On Thu, 26 Feb 2004 23:15:08 +1100, 

> cheers, hope that clarifies things?

Honestly, I was not 100% sure about the point when I first saw the
message.  But I think I now understand it by the succeeding messages
in this thread.

Thanks for the elaboration.

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 27 Feb 2004 16:39:13 +1100

On 2004-02-27, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> RFC3041: [...] (the last paragraph of Section 3.3)

Yep, and the other references to 'Interface Identifier' throughout,
since we're no longer really making up an II and generating
addresses from it, we're just making up random suffixes.  Well,
that's how I'd see it, anyway.

> though),  which reversed the logic:

Ah, thanks, I hadn't seen that.  I'll have a read.  I guess
that'd be the basis for 3041bis if we decide we need one.

-----Nick
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey/>
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move."
	-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

---

From: Greg Daley <[email-masked]>
Date: Fri, 27 Feb 2004 16:41:17 +1100

Hi Sharkey,

> ... I think.  Any SENDites want to comment?

I'm not really a SENDite, but...

> NB:  Is there a plan for 3041bis?  It's rather bound up with

I think that you're right about this (! missed that)
since the SEND devices will have distinct IIDs for each
prefix anyway, DIID isn't useful for them.

It doesn't mean I like your solution... :)

Greg

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2004 14:52:31 +0900

>>>>> On Fri, 27 Feb 2004 07:09:02 +1100, 

> I'm also dubious about relying on votes at IETF meetings for
> technical issues ... because often an option which seems 'obvious'
> at the time actually isn't once the drafts have been considered
> in detail.  And most of the WG attendees won't have considered
> them in detail before the meeting.  Sad but true.

(I know this is not a technical discussion, so I'll try to refrain
myself from making further posting on this particular point.  But feel
free to respond to this message, of course)

I see your frustration, but we have been experiencing similar cases
for controversial discussions many times here in the IETF.  The
"consensus" or "decision" often looks like an unreasonable result just
supported by a majority without thinking the issue carefully, if you
are against the consensus.  Let's just recall the recent site-local
discussions...

Unfortunately, we must often make a decision, or even compromise
anyway to move forward.  Even though there are some valid points in
DIID, I don't think what we have now in this discussion is worth
revisiting the past decision and delaying the process.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2004 15:32:09 +0900

> Questions for the group:

> * DIID offers less signalling.   What advantages does DAD offer?

An obvious advantage is less probability of (missing) duplication (as
was pointed out even in this thread several times).

A supplemental advantage would be simplicity and clarity in the
specification (and probably in implementations).  I know this kind of
argument is more or less subjective and may not be convincing though.

The important thing is that we had discussed these tradeoffs long
before, and we made a decision for DAD.  I admit there are some new
issues (e.g., SEND CGAs are obviously new), but I personally don't
think they are powerful enough to revisit the decision.

> * Does DAD retain these advantages when made compatible with DIID?
> 	(by testing/defending LL::X, as per my earlier suggestion)

> * Can backwards compatibility be dispensed with?
> 	(I'm going to be a hard sell on that one ...)

Honestly speaking, I don't see the need for making DAD "compatible"
with DIID in the first place.  Recall that DAD is not "compatible"
with DIID in this sense, even with the current RFC2462.  Since there
are currently always-DAD implementations as well as DIID ones, we
already have the "compatibility" issue.  That is, this is not a new
compatibility issue introdueced by the proposed change (MUST do DAD,
period.) in rfc2462bis.

Meanwhile, even DAD is not perfect in that we can still miss
duplication due to a timing problem or packet loss.  Even if we
introduce some new effort to make DAD compatible with DIID, it will
not be perfect either.

I thus conclude that we don't need a change, at least in rfc2462bis,
to make DAD compatible with DIID.

Again, my plan is simple.

- just say "MUST do DAD for all unicast addresses" (or SHOULD if we
  need a wording compromise) in rfc2462bis.
- this does not make the current status worse in the sense of
  "compatibility" with DIID, since there are already always-DAD nodes.
- as implementations gradually migrate to rfc2462bis, the
  "compatibility" issue will go away automatically.  Even if DIID
  implementations remain forever, the situation will basically be the
  same as the current one.

But as I said in a previous message, it's not my purpose to invalidate
existing DIID implementations.  For example, I don't want to see a
DIID implementation be called "non-compliant" in a spec-conformance
test event, etc.  If I can avoid the scenario by adding some careful
note in rfc2462bis, I'm willing to do that.

					JINMEI, Tatuya

---

From: "S. Daniel Park" <[email-masked]>
Date: Fri, 27 Feb 2004 16:15:30 +0900

> > And even with single id and new prefix this is not good: on 
> > RA with a new global prefix, every node on the link is going to do 
> > DAD based on its ID and new prefix. And, as far as I know, 
> > there is no delay requirement here, so everyone is doing it at
> > same time.
>

no change in the main sentence but add an appendix (or
something) to discuss the issue on the random delays of
the multiple RAs...but isn't bound for multi6 ?

Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 27 Feb 2004 18:59:25 +1100

> was pointed out even in this thread several times).

... if you're testing multiple addresses with the same suffix,
there'll be more chance of collision with another node using the
same suffix, true.  But it'd be more elegant to increase
DupAddrTransmits if that were your aim.  And SEND-CGA nodes 
will configure different suffixes per prefix: odds are, only
one will collide.

But honestly, I don't really want to reopen the DAD vs DIID
debate either.  I'm happy to do DAD.  I'd be happier if it
was interoperable with DIID, because of the installed base.

> argument is more or less subjective and may not be convincing though.

It's pretty close to convincing me -- the concept of an Interface
Identifier is unnecessary and can be done without, so I 'like'
DAD better.

> with DIID in this sense, even with the current RFC2462.

There is not currently a true DAD vs. DIID division.
2462 specifies that nodes SHOULD test all addresses, and they MUST
test the LL.  That bit is written on the assumption that all
suffixes will be the same -- otherwise it is meaningless.

All I'm proposing (see my previous post with the very short
bit of suggested text) is to clarify the rules for the post-IID era,
with a check for the link-local to maintain compatibility with
2462-compliant nodes *whether they check all addresses or just the LL*.

> introduce some new effort to make DAD compatible with DIID, it will

True, true, I suggest increasing DupAddrTransmits in Optimistic DAD
for this reason.

>   need a wording compromise) in rfc2462bis.

I'm happy with MUST.

>   "compatibility" with DIID, since there are already always-DAD nodes.

see above.  If I haven't explained myself properly, just let me
know.  Again, this is only an individual opinion that backwards
compatibility in this case is acheivable and important.

Anyway, see you all in Seoul,

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 27 Feb 2004 19:03:59 +1100

> free to respond to this message, of course)

Nah, I'll quit my whinging.

> Let's just recall the recent site-local discussions...

No, please, let's just not! :-)

(If I go suddenly silent on this issue for a while, I'm not
sulking, I'm flying ...)

-----Nick

---

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Feb 2004 08:00:23 +0200

> ... I think.  Any SENDites want to comment?

Thanks for bringing this issue up. Actually, it seems that if we want
SEND nodes to be compatible with DIID-only plain ND nodes, there is
indeed a need to defend the link-local address. Doing so is possible,
although in my opinion its a bit awkward:

- SEND specification has to be amended with a new rule.
- SEND nodes have to send plain ND messages (they are unable to
   secure the LL::X probe because X depends on prefix, and
   we are not really trying to create the address LL::X but rather
   A::X). Nevertheless, sending plain ND messages is possible.
- The amount of messages for DAD is duplicated.

So I guess what I'm asking is whether we really need to do
this. Did someone make a poll earlier about how many DIID-only
implementations there are? What where the results, are we likely
to encounter DIID-only hosts? Or perhaps SEND needs to do defend
LL::X only when running in ND-compliant mode?

--Jari

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 28 Feb 2004 22:54:07 +0900

>>>>> On Fri, 27 Feb 2004 16:15:30 +0900, 
>>>>> "S. Daniel Park" <[email-masked]> said:

> the multiple RAs...but isn't bound for multi6 ?

We may be able to address this issue as a future extension in an
appendix.  But please note that the problematic case can happen even
for a single RA (in that sense, there is no direct connection to
multi6).

p.s. I've registered a separate issue for this on the issue tracker.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 29 Feb 2004 17:16:30 +0900

>>>>> On Fri, 27 Feb 2004 18:59:25 +1100, 

> 2462-compliant nodes *whether they check all addresses or just the LL*.

I'm now a bit confused (probably I still did not understand your
previous scenario correctly)...

Suppose that a DIID node has an interface identifier (which is
probably derived from the hardware address) "I".  The DIID node first
tries "DAD" for fe80::I.  If the node does not see a duplication, then
it will configure a global address P::I without doing DAD.  This is
the optimization described in RFC2462.

Then, also assume the DIID node has some "suffix" which is different
from the interface identifier, "I", and even does not have any kind of
relationship with I.  For example, a suffix prepared for an RFC3041
temporary address might be related to I, since a part of the seed for
the suffix might be I.  On the other hand, a suffix for a SEND CGA
address would probably have no relationship with I.  Let's call the
former type of suffix "S1" and the latter type of suffix "S2".

Are you worried about the case where the DIID node omits DAD for the
address P:S1 because fe80::I is proved to be unique but a different
node happens to have already used the same address P:S1?  Then yes,
this may cause a problem.  From a practical point of view, however,
the only example of this kind of suffix that I know of is a suffix for
an RFC3041 temporary address.  And, in this case, we have already
agreed that each temporary address should be tested for its uniqueness
and the specification is updated (though currently expired,
unfortunately).  So, practically, there should currently no
new compatibility issue.  And if we take the proposed change in
rfc2462bis, we will be able to avoid similar compatibility issues in
the future.

Now, are you worried about the case where the DIID node omits DAD for
the address P:S2 simply because fe80::I is proved to be unique, even
though S2 is not related to I at all?  If so, I'd say that this is a
bug of the specification that specifies the creation and usage of this
type of suffix, or a bug of the implementation of the DIID node.

In either case, I don't see the need for an additional workaround in
rfc2462bis.

Or, am I totally missing the point?

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 29 Feb 2004 17:28:43 +0900

>>>>> On Sun, 29 Feb 2004 17:16:30 +0900, 

> former type of suffix "S1" and the latter type of suffix "S2".

Oops, I should have been more careful...the suffix for a SEND CGA
address also belongs to the former category.

> an RFC3041 temporary address.

So we should also consider the CGA case.  Realistically, however, does
this really cause a compatibility issue?  The compatibility issue only
happens when we have a DIID based implementation that supports SEND
CGA and it is deployed.  Is this really the case in the real world so
we need to worry about the compatibility?

I not, then the following logic will still apply.

> So, practically, there should currently no

					JINMEI, Tatuya

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 16:30:19 -0800

Jinmei,

> we need to worry about the compatibility?

When an address suffix is formed from a different key or subnet prefix,
including link local addresses, SEND will DAD it. This is in conformance
with RFC 2462 and has the effect of the SEND node DADing all autoconfigured
addresses (LL as well as unicast global). The NS sent by a SEND node will
include the SEND ND options. A nonSEND node will receive the NS, ignore the
options (as per 2462) and reply with an unsecured NA if it has a duplicate.
Section 8, paragraph 9 of the SEND spec describes what the SEND node does in
this case. Briefly, it will accept the first unsecured NA, but will reject
unsecured NAs after the first. So a node that has DIIDed an address first
will have the opportunity to defend it.

Conversely, however, there is a problem with a DIID node that just DADs its
LL address and assumes from there that the IID can be used for a global
address, since the SEND node will just check against its LL address, due to
the difference in prefixes. The SEND node's already configured unicast
global address might then conflict with the DIID node's. However, this
problem would occur between any DIID node and a node that uses different
address suffixes for LL and uncast global addresses.

So, unless I'm missing something, I don't think there would be any problem
between SEND nodes and DIID nodes that would not also occur betwee, say, RFC
3041 nodes and DIID nodes.

            jak

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 01 Mar 2004 11:03:53 +0900

>>>>> On Sun, 29 Feb 2004 16:30:19 -0800, 
>>>>> "James Kempf" <[email-masked]> said:

> address suffixes for LL and uncast global addresses.

Since I seem to have been failing to understand the point, please let
me rephrase that to be sure.  Are you talking about a scenario like
this?

We have two nodes, a "SEND node" and a "DIID node".

SEND node:
  - (for simplicity) do not implement the DIID-style optimization
  - have an (e.g.,) EUI-64 based interface identifier, I.
  - configure a SEND (CGA) address P:A (where A is the identifier, A != I)

DIID node
  - implement the DIID-style optimization
  - (for simplicity) do not implement SEND
  - happen to have A as an interface identifier

The SEND node comes to a link.  It perform DAD for both fe80::I and
P:A, and confirms that these are unique.

Then the DIID node comes to the same link.  It performs DAD for
fe80::A, and confirms it is unique.  So the DIID node start using
P:A without doing DAD while P:A is actually duplicate.

					JINMEI, Tatuya

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 20:53:51 -0800

> P:A, and confirms that these are unique.

No, the SEND node performs DAD for fe80::C, where C is a function of the key
and some other parameters. The prefix on LL addresses is also calculated
from the key.

> P:A without doing DAD while P:A is actually duplicate.

Yes, that's the concern. If the DIID node comes on the link second, then it
will assume that A is a unique prefix even though it only DADs it for the LL
address.

            jak