Re: [Mipshop] Possible Solution to Duplicate Problem?

[Greg Daley <[e-mail]>]

Hi Theo,

Theodoros Pagtzis wrote:
[cut]
>> Ignoring the premise, which I don't agree with (It doesn't matter
>> whether or not SEND/CGA is in use for optimistic DAD):
> 
> 
> please correct me if I am wrong, but in version
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt, 
>  section 3.1 (General) you specify that it SHOULD be
> 
> 
>  " Nodes implementing Optimistic DAD SHOULD additionally implement
>         Secure Neighbor Discovery [SEND]. "
> 
> is that what you mean by saying that 'it doesn't matter whether or not 
> SEND/CGA is in use'. If so why bother with implementing it?
> 

You've missed my point.


You said below:

"1) if it does not need it then doing DAD takes as long as MIPv6 period."

It doesn't matter in this case that SEND is used.
it would take as long if SEND was used or wasn't used.

The rest of your assumptions about DAD are incorrect too:


> With oDAD I have a question which IMO is pertinent to see how the 
> optimism in usage of the nCoA can be sustained without implicit delays 
> arising from the Addr Resolution process.
> 
> Page 7 of the above revision mentions that:
> 
> "NSs sent as part of DAD are sent from the unspecified addr WITHOUT a 
> SLLAO".
> 
> I assume this is sent to the all-nodes multicast addr..

No! it is sent to the solicited nodes' address (RFC2461/2).

> Now when the NAR receives this it sends its own NS to initiate addr 
> resolution and thus derive the MN LLA. However:

No it doesn't! it sends a response to all-nodes (RFC2461/2).

> page 9 mentions that the MN must not reply to a NS for an Optimistic 
> addr from the unspecified address. If this is the case, and assuming the 
>  Optimistic addr is pending DAD resolution (and thus cannot be used as 
> the source addr in the NA), HOW will the MN notify its LLA to the NAR??

Why would it?

an NS from the unspecified address is another device
performing DAD.

This means that the optimistic DAD node has discovered a duplicate,
and should de-configure the address.

> Also I was under the impression that until the nCoA becomes 'Preferred' 
> as per RFC2461, the NUD cannot resolve its state in the NCE to 
> REACHABLE, (lingers between INCOMPLETE and PROBE). As such packets 
> cannot be forwarded in either direction. Could it be that even if the 
> address appears to be usable (but optimistically DAD resolvable), is 
> blocked by the NCE state of NUD??

That impression could be remedied by referring to RFC2462 and RFC2461.

Packets can be forwarded in STALE, and DELAY states, even if you
were right (which you're not).

Addrconf relies on Neighbour Discovery state, not the other way around.




>>>   1) if it does not need it then doing DAD takes as long as MIPv6 
>>> period.
>>
>>
>>
>> Which, it has been argued, is effectively no time at all using
>> Optimistic DAD.
> 
> 
> The 'no time at all' qualifier appears to be a bit too 'optimistic'. 
> Currently, the MN must deal with timeouts of a number of RA before it 
> can consider a change in link and thus kickstart the address config 
> process. This is 3-4 router adverts which at best is 160ms.

This has got nothing to do with FMIPv6, though,
it's got to do with router discovery.

Actually, that's what the DNA Working Group is doing.

There's no need for timeouts if you've got a CPL.
A single RA should suffice to indicate change.
New methods have also been described which
augment RA knowledge to

RA delivery should be possible using hash-fastRA which
will give RAs with no induced delay.

i.e. the over the air round trip time.  (~< 15ms on a wireless lan).

All this is designed to work with Optimistic DAD.

here's one of the (complete) descriptions of how to
accomplish this:

http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol-01.txt

Here is a description (by someone who knows FMIPv6),
of how this would interact with FMIPv6:

http://www.ietf.org/internet-drafts/draft-koodli-dna-fmip-00.txt

Clearly, the issue is being looked at closely.

>>
>>>   2) if it does need it then FMIPv6 *requires* SEND/CGA during a 
>>> reactive handoffs and then it is not FMIPv6 anymore. It is FMIPv6 + 
>>> SEND/CGA + CARD + whatever comes next.. (i.e. for a fast handoff 
>>> protocol it seems pretty heavy - aside clean interoperability issues..
>>
>>
>>
>> The difference between now and 2000/2001 is stark in the development
>> of other protocols which assist handovers.
> 
> 
> nobody denies that other protocol may have emerged to assist handoffs in 
> a period of 4 years. The insights I referred to back in 2001 have to do 
> with FMIPv6 problems of today identified back in 2001..
> 
> More to the point, when one designs a protocol he HAS to indicate the 
> dependencies IMO, particularly IF without them the protocol fails on the 
> fundamental optimisation objective (i.e. the measure of handoff latency) 
> during average case scenarios (e.g. reactive handoff). Indicating the 
> performance dependencies/limitations is our responsibility, it is not an 
> option..
>

Well, it seems a more fundamental thing than that is to know
the protocols which are to be analysed.

Greg

_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop