Subject: Re: [16ng] Fwd: I-DACTION:draft-madanapalli-ipv6-over-802.16-ipv6cs-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Jun 2006 12:49:33 -0700 (PDT)

Hi Syam,

----- Original Message ----
From: Syam Madanapalli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Hongseok Jeon <[email-masked]>; [email-masked]
Sent: Monday, June 26, 2006 12:45:41 PM
Subject: Re: [16ng] Fwd: I-DACTION:draft-madanapalli-ipv6-over-802.16-ipv6cs-00.txt

Hi Behcet,

On 6/26/06, Behcet Sarikaya <[email-masked]> wrote:
>
>
> Hi Syam,
>   My concerns on the relay DAD are the following:
> 1. Relay DAD originates in 6lowpan, see this link (section 7):
> http://www.ietf.org/internet-drafts/draft-chakrabarti-6lowpan-ipv6-nd-01.txt
> this draft was not even referenced in your draft :)?

I have never read the draft. So I did not know that I need to refer to
this draft.
I have proposed initially to do the proxy DAD in Dallas meeting but Erik
(now one of the authors) suggested relaying DAD probes to the actual address
owner, so that we comply with SeND. Otherwise the concept of omniscient
router with address cache to help the DAD procedures has been developed
independently based on WiMAX Architecture.

If majority of the people feels that we could have a draft to just talk about
DAD procedures in networks without multicast support which can be used
in both 6LoPAN and 16ng WGs, I am open for that.

> 2. Relay DAD is based on involving the address owner, e.g. MS2 in Fig. 7 of
> your draft and MS2 could be in dormant mode and it would need to be paged
> and so on.
> In 6lowpan networks this could be OK because the sensor nodes are sleeping
> most of the time and there is no paging.

Even I did not like it for the same reason you mentioned, but looking
at the very
very low probability of address collision, I think it is OK to do paging.

The other proposal that I have made is to do the counter DAD from the AR.
Let us say MS1 configures same address as MS2 and starts DAD procedures/
AR looks into its address cache and finds that the address is duplicate and
initiates DAD procedures for the same address as if it is also configuring the
same address, and the DAD NS is sent to only MS1. When MS receives the
DAD NS for the same address that it is trying configure, it discards
the address.

But we (authors) could not dig further and see if this is compliant with SeND.
Even if this Send compliant, it may be new security threat that SeND has not
solved currently.
==> This sounds good to me, we can work on the counter DAD.
==>I hope this is going to lead us to a solution and then we can let Relay DAD be used
==>in 6lowpan.
==>Hopefully this is going to resolve the current chaotic situation around Relay DAD, i.e.
==>there are currently 3 drafts on it.
==>Regards,
==>--behcet