Re: [DNA-BOF] DAD Optimization Problem Statement

[Jari Arkko <jari.arkko@kolumbus.fi>]

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.

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

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

I have also read your draft and have some comments:

>    This document tries to clarify problems for current IPv6 DAD
>    specification, especially unreasonable delay.

"Unreasonable" may be a bit debatable. Suggest toning this down
a bit, maybe as in "This document discusses issues related to the
current IPv6 Duplicate Address Detection (DAD) specification. In
particular, the document addresses the delays DAD causes for fast
moving mobile nodes."

> 1. Introduction
> 
>    The current specifications for detecting duplicate IPv6 addresses are
>    described in [1] with use of Neighbor Solicitation and Neighbor
>    Advertisement messages. In the current specifications, an IPv6 node
>    has to perform a Duplicate address detection (DAD) procedure before
>    it tries to assign its a unicast address to its interface, regardless
>    of whether it is obtained through stateful, stateless or manual
>    configuration. However, the current DAD specifications prevent a node
>    from transmitting and receiving a packet with a new address on a link
>    within the first second of attachment.

Perhaps you should say that its not always one second, depends on
DupAddrDetectTransmits * RetransTimer.

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

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

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

> 3.2 Autoconfiguration-related Variables
> 
>    An address is ¡®Tentative¡¯ while it is tested for its uniqueness. It

Illegal chars.

> 3.3 Link local scope of DAD
> 
>    The current DAD scheme can guarantee the uniqueness of an address
>    only inside a link. It uses the Neighbor Solicitation/Neighbor
>    Advertisement message exchange to detect duplicate address. Because
>    the messages can't go over a router, DAD may not detect a duplicate
>    address in an another link.
> 
>    Here is an example. Assume a router has two interface attached to two
>    separate links. It assigns the same prefix A:: to them and advertises
>    the Router Advertisement messages with the prefix A:: with L bit
>    (on-link flag) off and A bit (autonomous address-configuration flag)
>    on.

Can someone educate me on the use of L=0 advertisements? Why
are they used? Seems that the RFC 2462 Section 5.5.3 rules
say even an L=0 advertisement causes an address to be configured
and DAD invoked.

>                            +------+
>                  A::       |      |         A::
>             ---------+-----+Router+-----+---------
>                      |     |      |     |
>                 A::1 |     +------+     | A::1
>                  +---+---+          +---+---+
>                  | Host1 |          | Host2 |
>                  +-------+          +-------+
> 
> 
>    Assume there is a host with address A::1 in the first link. Then
>    another host arrives at the second link and forms an address with
>    stateless address autoconfiguration. The second host happens to have
>    1 as its interface id and picks A::1 as its address. Then, even
>    though the second host performs DAD, it can not detect the duplicate
>    address at the first link. If the second host moves to the first link
>    (or the first host moves to the second link), hence, the address
>    collision occurs, because the moving host considers the new link as
>    the same link as the previous one and does not create a new address
>    at the new link.

Isn't this just because the node failed to notice that it was
on a new link? This would happen for link-local addresses, too,
without considering any RAs.

> 4.1 Stateless DAD Optimization
> 
>    In this strategy, the DAD states of addresses are not stored in a
>    node. This strategy attempt to detect duplicate addresses without
>    relying on a centralized server or router to keep track of the DAD
>    states of addresses, instead relying on the already configured nodes
>    to cooperate in the DAD process.
> 
>    A DAD optimization protocol can be developed based on the premise
>    that DAD is far more likely to succeed than fail. Although an address
>    is even randomly auto-configured, DAD is far more likely to succeed
>    than fail by a factor of at least 10,000,000,000 to one. So, a DAD
>    optimization protocol can make DupAddrDetectTransmit zero. But, it
>    must propose a sophisticated recovery mechanism by way of precaution
>    against the address collision.

I think the adopted term is "optimistic DAD"
> 
> 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.

> 5. Security Considerations
> 
>    This document does not introduce any security issues.

I'm pretty sure it does. We just don't know them yet ;-)

--Jari