[DNA-BOF] Re: =?EUC-KR?B?PyBSZSA6UmU6IFtETkEtQk9GXSBEQUQgT3B0aW1pemF0aW9uIA==?==?EUC-KR?B?UHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgIENIT0lKSU5IWUVPQ0sgICAgICAgaQ==?==?EUC-KR?B?X05ldHdvcmtpbmcgTGFiIFNhbXN1bmcgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIA==?==?EUC-KR?B?VGVjaG5vbG9neVJlc2VhcmNoZXI=?=

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

Hi JinHyeock,

CHOIJINHYEOCK wrote:
> Hi Greg
> 
> 
>>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.
> 
> 
> Even if all addresses aren't on-link, the router doesn't have to be 
> ND-proxying necessarily. In the example below, what give rise to 
> trouble is a prefix with L bit off and A bit on. If both bits are off, 
> I see no problem.

I see what you mean now.

If managed addresses are in use, then DAD would only
be useful on the local link (because it won't work otherwise).


> 
>>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.
>>
> 
> Correct me if wrong, but I am afraid that there is no way 
> people can do DAD on their non-link-local address other than 
> the above (DIID like). What other mechanism can they rely on?
>  

DIID means "Assume all addresses are free if link-local is".
DAD checks each address.  In your scenario, the availability
of the link-local address is about the only way to check
validity on this link, but it is not a guarantee for global addresses
in any case, since the link-local address may be duplicated on
another link for the same subnet.

>>>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. 
>>
> 
> What I described above has nothing to do with DAD, I just try to elaborate the 
> usage of the prefix with L=0. 
> 
> And if we put A bit off, we can do DAD in stateful manner (maybe in DHCP 
> server). 
> 

OK. L=0, A=1 doesn't work unless there's ND-proxying.

L=0, A=0,M=1, may work if we can trust the router, and all
hosts on our (small) link.

Maybe this is sufficient to put into a draft (aimed at
updating 2462)?

>>>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.
> 
> 
> What I trying to say is that if we put L bit off and A bit on, there may 
> be a problem, two identical global addresses, as described in an example. 
> 

Absolutely.  I get it now, but I think this is not an
existing scenario in deployed networks.

DAD optimization is not likely to be
impacted because of this network design because
the original DAD will fail anyway (we have a big
problem with DAD in this scenario, but DAD
optimization makes this no worse).

We'd have to start specifying solutions for
non-optimized nodes to fix this problem, which is
what we're trying to avoid in DNA.

[cut]
>>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.
> 
> 
> Though, I think this is a problem, I can't be sure this is a
> DNA problem. If folks think not, I will not cling to it with
> tooth and nail :-). 
> 

I think that this is more a problem with the
lack of specificity in existing DAD specifications,
rather than a DNA problem.  I've not yet seen a network
like the one you describe, but would be interested
to hear of a wireless environment like this
(or one planned).

It's not that DAD is bad, it's just that this looks a
lot different to the scenarios for which DAD was
developed.

Greg