Hello Karl, On 7/10/06, Mayer Karl <[EMAIL PROTECTED]> wrote:
So you would conclude from the EUI-64 identifier of the link-local address (received in the RS) also the non-link-local addresses, right?
Yes.
This is only possible in case *all* IP addresses are constructed by concatenating the respective prefix with the EUI-64 identifier. However, draft-ietf-6lowpan-format-03 leaves flexibility in the constructing of non-link-local IP addresses so I am not sure whether we can rely on this (or at least we have to make this an requirement).
I see your point.
Therefore my proposal was to send for each configured IPv6 address an NS message to the PAN coordinator with the respective IPv6 address as source address and the Source Link Layer Address option. The destination address could be any of the router's IPv6 addresses, the link-local address as well.
I got the idea. Will discuss with you further, before next revision of the draft.
>Do you have any idea to switch PAN co-ordinators at L2 layer? >If so, we could link IPv6-router switch along with that. Not much about this is written in the IEEE 802.15.4-2003 standard and I have no access to the IEEE 802.15.4b-2003 standard (and I don't think they solve this issue there). I assume 802.15.4 leaves it up to higher layers (e.g. to the 6lowpan layer) to deal with PAN coordinator selection. When sending an Association Request message, a node can signal its wilingness to be an alternate PAN coordinator via a respective flag. Similar to other failover mechanisms, a PAN coordinator receiving such a message with the flag set could subsequently send periodically an alive message just to his alternate PAN coordinators. In case an alternate PAN coordinator does not receive an alive message anymore it could perform an election process among all alternate PAN coordinators and become the PAN coordinator. Clearly, there are open issues and these are just first thoughts.
OK. Thanks for explaining. Regards, -Samita
> >> >-----Ursprüngliche Nachricht----- >> >Von: Samita Chakrabarti [mailto:[EMAIL PROTECTED] >> >Gesendet: Sonntag, 25. Juni 2006 01:30 >> >An: [email protected] >> >Betreff: [6lowpan] 6lowpan-nd version 2 >> > >> >Erik and I have updated >> >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for >> >publication. The new update includes a section on generic >application >> >of this draft for non-multicast, non-broadcast network. At the last >> >wg meeting, the request was made for such an update for the Wimax >> >effort on IPv6. >> > >> >Two questions to the working group and the chairs: >> > >> > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG >> >document ? >> > 2) Are we OK with publishing the draft as "IPv6 Neighbor >Discovery >> >Optimization >> > for IEEE 802.15.4 and other non-multicast networks" >so that it >> >contains >> > specifics on 6lowpan and a generic guideline for >other relevant >> >networks? >> > >> >Comments are welcome. >> > >> > >> >- Samita >> > >> >_______________________________________________ >> >6lowpan mailing list >> >[email protected] >> >https://www1.ietf.org/mailman/listinfo/6lowpan >> > >> >
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
