Re: [DNA-BOF] DAD Optimization Problem Statement

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

Hi JinHyeock,

JinHyeock Choi wrote:
> Dear Jari 
> 
> Kindly find my inline comments. 
>  
> 
>>>   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.
> 
> 
> Current DAD scheme uses NS/ NA exchange which can't go over a router. 
> Hence if there exists a duplicate (global) address in an another link, a node 
> can't detect its presence. 

If we were talking about networks where all addresses
aren't on-link (which I think we were trying to avoid),
then the router should be ND-proxying.

DAD has to work, or this type of link will never be
deployed. Therefore i think that it's the problem
of the multi-link or ND proxy people when they develop
standards, rather than our problem.

If people are doing DIID (checking only the link-local
address) on systems where they are told by an RA that
the on-link bit is not set, then that's _their_
problem, as they're not actually doing DAD on their
non-link-local address.

Once again, I don't think this is a problem for
our standardization.

> 
>>>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? 
> 
> 
> This is tricky and gave me some trouble when I thought over movement 
> detection. 
> 
> My guess is that it enables the node to check whether it has a valid address. 
> In other words, if its IP address belongs to the advertised prefix (whether 
> L=0 or L=1), the node can expect that the internet routing system will deliver 
> packets destined to that address to itself. 
> 

Indeed, this should include appropriate DAD NS packets
for non-on-link prefixes.

In this case, the router knows each of the destinations
to which packets must be routed from off-link.
It therefore is required to know which addresses are
in use, or to resolve DAD by passing ND traffic.

If the router knows which addresses are on which links,
it's not even necessary to proxy DAD, since
the router is a DAD oracle.

I think it's not worth worrying about here.
It is an architectural issue in DAD, not an
optimization issue.


>>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.
> 
> 
> As in RFC 2461, a prefix might be used for address configuration with 
> some of the addresses belonging to the prefix being on-link and others 
> being off-link. 
> 
> But I am afraid this kind of usage may result in duplicate addresses 
> like below. 

This is not the case, if the route has to deliver packets
to these hosts from off-link.  In that case, it MUST
know where to send them, and must keep some state, or
relay ND messages between links.

I've not even heard about a deployed IPv6 network of this form.


> 
>>>                           +------+
>>>                 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.
> 
> 
> Address collision occurs even when two nodes remain at two separate links. 
> In the above example, the problem is that two nodes happen to have the 
> same global IP address and have no way to detect it. 
> 
> I think the above paragraph is misleading. The paragraph after 'If the second 
> host moves....' should be deleted like below.  
> 
> 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.
> 
>   

Please remember that we've been cautioned about
tackling multi-links in DNA:

http://webcamserver.eng.monash.edu.au/~warchive/dna/2003-06/msg00063.html

I'd really prefer to leave all this (section 3.3, and
link-local scope of DAD)  out of the document,
since it is not a DAD optimization issue.

It is an architectural issue for those proposing
multi-link subnets.

Greg