Re: [DNA-BOF] DAD Optimization Problem Statement

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Youn-Hee,

My replies have been sporadic but for other reasons.

Youn-Hee Han wrote:
> I am sorry for late reply. 
> I was away on my short summer vacation.
> 
> From the previous many mails, we seem to come to an
> agreement that 'DAD optimization' is only to reduce 
> the delay incurred by the current DAD.
> 
> So, in view of this agreement, I will reply your mail.
> 
> Jari Arkko wrote:
> 
> 
>>Youn-Hee Han wrote:
>>
>>
>>>I and Soohong have been writing a problem statement draft 
>>>for DAD optimization. Although we seems to need a more 
>>>discussion about the exact definition of 'DAD optimization',
>>>we hope that our works will help us discuss about it.
>>>
>>>You can see an incomplete version of the draft in the following link;
>>>http://myhome.personaldb.net/bluebibi/dadopti/draft-han-dna-dadopti-problem-statement-00.txt
>>>
>>>And, we can think another problems as follows.
>>>The followings are not contained in the current document.
>>>
>>>  [Possible subjects 1] 
>>>
>>>    The basic DAD procedure is very vulnerable to a simple Denial-
>>>    of-Service attack.  Basically, an attacker simply prevents a 
>>>    node from getting a link local address by claiming to have that 
>>>    particular address. 
>>
>>This is currently being take care of by the Secure Neighbor
>>Discovey (SEND) Working Group. See draft-ietf-send-ipsec-01.txt
>>(to be replaced soon by draft-ietf-send-ndopts-00.txt, but
>>that's a detail...)
>>
>>So, I wouldn't recommend tackling this problem here
>>for the basic DAD vulnerability. However, it would
>>very helpful if the new optimized DAD specification
>>was already SEND-compliant, in some manner TBD.
> 
> 
> Good Point. SEND is the solution of this problem.
> As Greg already said, I am also sure that new optimized 
> DAD specification should be SEND-compliant.
> 
> So, I would like to insert Pekka's proposal about 
> 'Interoperability with SEND' into the requirement draft.
> 

Sounds reasonable.

>>>  [Possible subjects 2]   
>>>
>>>   In order to process DAD, all nodes have to send solicited-node 
>>>   multicast address using NS message, whenever IPv6 addresses are 
>>>   composed of its interface identifier.  This procedure may reduce 
>>>   the network performance especially within the low bandwidth 
>>>   networks.
>>
>>I'm not sure there are other alternatives.
> 
> 
> Originally, this problem has been suggested by Soohong.
> Fankly speaking, I think that this is not severe problem.
> As Greg said, the solicited-node multicast packets are
> dilivered to a very small group.

But only in some link environments....
In others any multicast is very troublesome..

> 
>>>   [Possible subjects 3] 
>>> 
>>>   IPv6 node in 802.11 environments will never be able 
>>>   to receive the DAD packets if its MAC address is same as another 
>>>   node, because of the frame filtering based on the source MAC 
>>>   address.  In this case the DAD always succeeds even though the 
>>>   addresses are duplicate.
>>
>>Hmmm... interesting.
> 
> 
> This issue has been suggested by Soohong, too.
> If you are more interested in this issue, please refer
> http://www.ietf.org/internet-drafts/draft-park-ipv6-dad-problem-wlan-00.txt
> 
> But, I think that this issue is not included in the scope 
> of 'DAD optimization' in DNA wg.

I think that we need to ensure that these issues are not
lost (there are still issues with DAD), but we need to
find if there is a venue better resourced or targeted
to handle this work.

[cut]
> 
>>>   A proper support for a node to send or receive packets immediately
>>>   after attaching to a link is undermined by the disruption imposed by
>>>   the current DAD. Most of all, the current procedure for detecting
>>>   duplicate addresses consumes unreasonable delays and does not
>>
>>Perhaps you could just say "This delay is troublesome from the point
>>of view of fast handovers in a mobile environment."
> 
> 
> I am not trying to make 'DAD optimization' useful only 
> for fast handover. Preferably, I would like to say that
> "DAD optimization is a support for a node to send or receive
>  packets immediately after attaching to a link". 
> 
> This seems to be able to lead some debate.
> The problem is that we can not find another good 
> application of 'DAD optimization' other than fast handover.


I think that this is a fair description of the current
state of the art.....

When describing this as a new behaviour for
hosts, we need at least one good application
for a particular idea.

If we actually know of another realistic situation
then that's really better, since it implies that
our solutions can be tested against general requirements,
rather than just for a single subsystem (I think that's
what we're aiming for in DNA, supporting
other configuration subsystems).

So if anyone has another reason or occasion where DAD
can or should be done (and may be amenable to optimization),
then we should bring it forward for discussion.

Otherwise, it will be hard to encourage adoption
(or standardization) for hosts, unless they are
Mobile-IPv6 hosts.

> 
>>>   consider a node to have a fast handover in mobile environment.
>>>   Therefore, some considerations are required to be suggested for
>>>   reducing delay due to the detection of IPv6 address collision.
>>>
>>>   Another problem of the current DAD is that it guarantees the
>>>   uniqueness of an address only inside a link. Hence, when two adjacent
>>>   links have the same prefix and any two hosts are individually located
>>>   at the two links, the two hosts can have same address. If the two
>>>   hosts meet at one of the two links, the address collision will occur.
>>
>>I don't understand.
> 
> 
> I will elaborate this problem later. But, this seems to be 
> out of DNA wg's scope.
> 

I've been thinking about this issue, but we can
have a quick discussion soon about what to do with this
issue.

My original responses may not have taken into consideration
some of the more subtle concepts which were being conveyed.


>>>3. Problem Statement
>>>
>>>   This section tries to clarify the problems in the current DAD. The
>>>   problems are restricted within the limits of the DNA charter.
>>>
>>>3.1 Random Delay
>>>
>>>   If a node's interface is attached to a link, the Neighbor
>>>   Solicitation is the first message to be sent from an the interface.
>>>   So, the node should delay sending the message by a random delay
>>>   between 0 and MAX_RTR_SOLICITATION_DELAY (default: 1000 ms) as
>>>   specified in [1] to reduce congestion when many nodes start up on the
>>>   link at the same time, such as after a power failure, and may help to
>>>   avoid race conditions when more than one node is trying to solicit
>>>   for the same address at the same time.
>>>
>>>   The impact of this constraint on the performance of DAD can be
>>>   severe. If a node abides by this constraint, the completion of DAD is
>>>   delayed by some random amount, increasing the amount of time before a
>>>   node sends or receives packets immediately after attaching to a link.
>>
>>draft-ietf-mobileip-ipv6-24.txt, Section 11.5.2, has some text
>>about this issue.
> 
> 
> I am not sure that proposal of the Section 11.5.2 is the best solution.
> So, I think that this is an important thing for 'DAD optimization 
> problem statement'. And, a DAD optimization scheme should 
> handle this problem.


I agree that this is an issue for any host which is doing
DAD fast.   It is possible to listen for NA messages while
this period is active (possibly doing optimistic DAD after
the random timer expires... does this mean we can send
packets from this address before sending DAD NS?).

There can not be any use of an address though,
or even monitoring of a multicast group, unless we're
sure that packets are being directed to us.

This may mean sending Multicast group join (MLD-Report)
messages in some environments.   These messages would
have similar delay requirements to the DAD NS, in order
to maintain multicast packet arrival spread.

Certainly, it is necessary to determine the impact of
this behaviour so that we can optimize the delay
for fast DAD.

As a problem statement (rather than a solution), the
text from MIPv6 could be very useful though.

[cut]
> 
>>>4.2 Stateful DAD Optimization
>>
>>>   Stateful DAD optimization can maintain knowledge of the DAD states of
>>>   addresses by monitoring or brokering address usages. Nodes which
>>>   centrally store the states are then queried by other nodes which
>>>   desire a quick resolution to DAD procedures.
>>>
>>>   In order to support this strategy, the mechanism which is used to
>>>   collect the DAD states must therefore be supported by all nodes on
>>>   the link, even if they do not support the DAD optimization protocol.
>>
>>What would such mechanism be? An existing address probe, or something
>>new? The latter would probably be a non-starter, given that we want
>>co-existence for DAD and new, optimized DAD.
> 
> 
> There are two solutions counted among this strategy.
> - http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-02.txt
> - http://www.ietf.org/internet-drafts/draft-han-mobileip-adad-01.txt
> 
> A good 'DAD optimization scheme' can be developed newly or selected
> among the existing works based on the current works (problem statements
> and requirements).

I think that we have to look at the candidate solutions and
check that they achieve our requirements (Though there may
be some acceptable trade-offs, in some cases).

Let's check out that we've got the right requirements,
before we go on to the solutions.

I'll respond to Pekka about the different solutions/reuqirements
drafts in the next email.


Greg