RE: [DNA-BOF] DAD Optimization Problem Statement

[Soohong Daniel Park <soohong.park@samsung.com>]

Hi 


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

We didn't consider more detail about secure DAD but we just
tried to address one of DAD problems... 

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

It also one of DAD problems.
DAD does introduce some traffic overhead and a delay in interface
initialization. 

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

Please let me know your 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."

Definitely agree.. it's just draft

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

Right, we addressed default case. (1 * 1000ms)

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

Sure... I assure DAD optimization is tightly couple with mobile ip.

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

Tentative...^.^ because of wrong char for crlf.


Thanks


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