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
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
