[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA-BOF] DAD Optimization Problem Statement
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.
> > [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.
>
> > [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 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."
Thanks for good suggestion.
>
> > 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.
>
Thanks. I willl modify it.
> > 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.
> > 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.
> > 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.
>
> > 3.2 Autoconfiguration-related Variables
> >
> > An address is ¡®Tentative¡¯ while it is tested for its uniqueness. It
>
> Illegal chars.
I will modify it.
> > 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.
Please refer JinHyeock's comments.
> > 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"
Yes. 'Optimistic DAD' is a good existing solution.
> >
> > 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).
Youn-Hee Han