Re: [6lowpan] 6lowpan-nd version 2

["JinHyeock Choi" <[e-mail]>]

Dear Samita

Thanks for your clarification.

>> The above is possible only after DAD is completed, which results in
>> delay. How about including 'Tentative Option' instead?
>>
> Are you talking about Optimized DAD?

yes.

> How much time should we be saving?

1 sec by default.

> Will it be worth the extra code ?

It depends. :-)

> This document is only concerned with the base ND changes.

I see.

>> >   Since every host sends a RS when it attaches to the PAN and there is
>> >   a single router for the PAN (the PAN co-ordinator), this router will
>> >   observe the arrival of all the IPv6 link local addresses
>>
>> This may not be so. Allow me an example. When a host attaches to a
>> network, while performing DAD, it may receive an unsolicited
>> (periodic) RA. Then the host would not send an RS. Also the host may
>> generate a new (link-local) address while staying at the same link for
>> the privacy reason. Then it would simply configure a new address
>> without sending an RS.
>
> In case of LowPan-ND, we are requiring to send unicast RS to the IPv6-router.
> We have not decided whether DAD should be mandatory for these devices or not.
> Since this draft assumes each node has EUI-64 addresses, DAD may not be
> required in theory. But in practice, it may choose to do DAD through
> the Ipv6-router.
> However, it will not receive unsolicited RA while waiting on DAD, because in
> this ND-extension RA will happen (most likely) through unicast L2 messages.
> Since both the DAD and RA will be sent by the same Ipv6 router, I'd assume
> they will happen in sequence. But due to radio link issues, we cannot guarantee
> that one will reach the destination always in sequence. Perhaps, we
> need to re-word the above mentioned text to clarify "observe the
> arrival..." part of the sentence.

ok.

>> How about monitoring the incoming DAD NS to generate the list instead?
>> That's the approach WiMAX takes right now.
>
> Will discuss that. As mentioned above that DAD may not be mandatory.

ok.

>> >   Firstly, it might very well be possible to increase the default time
>> >   significantly as long as the hosts can use some other mechanism to
>> >   detect when the router (the PAN co-ordinator) disappears.
>>
>> We also try to increase the maximum of MaxRtrAdvInterval.
>
> What was the value?  Which draft is it in?


> Sorry, that sentence is problematic. We are missing a punctuation.
>
> It means that DAD means broadcast in 802.15.4 network and should we
> skip DAD for 802.15.4 network?

ok.

>> >                             This RS message MUST carry sender's
>> >   link-layer address (SLLA) option.
>>
>> If the RS is sent before completing DAD, it can't carry SLAA. In that
>> case it may carry Tentative Option.
>
> Can you please point me to the Tentative Option document?

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

Take notice that the draft is planned to be merged into a single DNA draft.

>> In WiMAX, the router would not send a Redirect message. Usually L2
>> address is not used for data forwarding inside a link. In WiMAX, an MS
>> has only an AR, a default router, as its on-link neighbor.
>
> Please see section 10 of this draft for application on other technologies.
> RFC2461 actually recommends using off-link RA advertisements for
> the non-broadcast/non-multicast networks neighbor soliciation. This is
> not new in this draft.

I see.

>> As I wrote the above, an MS has only its AR as its on-link neighbor in
>> its Neighbor Cache. So I don't think it's necessary for AR to relay an
>> address resolution query.
>
> So, according to your description,  each MS is off-link to the other.
> So any packet has to be forwarded to the AR first. It sounds like
> the AR needs to have a different IPv6 link and L2 link (for each MS),
> such that an IPv6-link consists of multiple MSes.
> So, if AR follows IPv6 neighbor discovery it should advertise RA with L=0
> and all data packets are forwarded through it like a star topology in 6lowpan.

yes.

> Thanks for pointing out the differences in Wimax technology. As I mentioned
> before, this draft only provides guidelines for other technolgies so that
> mimimal change is required to adopt IPv6 ND on other non-broadcast/multicast
> networks.

I see.

Thanks for your kind consideration.

Best Regards

JinHyeock

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