Hi Zach, Thanks for clarifying the example, I was just going through the same exercise myself and I have a couple of questions: - In the NS, why not use "SLLAO: short" since the ARO already carries the IEEE. This would avoid to use an additional refresh NS to establish the mapping "GP16 / short" - Also concerning the processing of the RS and the draft says: "A Router Solicitation might be received from a host that has not yet registered its address with the router. Thus the router MUST NOT modify its Neighbor Cache with the SLLA option from the Router Solicitation. The SLLA option is only used to form the link-layer address to which the router sends the Router Advertisement." I'm not sure I understand the last sentence. Isn't the IPv6 DST of the RA the IPv6 SRC of the RS. Then a temporary, "neighbor cache" entry "source RS / SSLAO RS" would be needed to establish the mapping with the layer 2 address, no? - Similarly upon receiving a RA the host should install a neighbor cache entry for the router. Is there a lifetime or other information associated with this entry?
Best, Mathilde -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Zach Shelby Sent: lundi, 12. juillet 2010 16:27 To: 6lowpan 6lowpan Subject: [6lowpan] ND exchange example I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.4 device bootstrapping for the first time, generating a 16-bit address, and then registering it in an unmanaged network. ZigBee IP is trying to minimize the number of addresses each node has to configure - the goal is to use just LL64 and GP16. LL64 is avoided where possible though as it has 6 bytes of extra overhead per address. Below the suggested example uses GP16 for RS/RA and NS/NA exchanges where possible. LL64 is used more for bootstrapping before the GP16 is confirmed. A couple questions come up here: 1. Can we make an exception for using global addresses for RS/RA and NS/NA between the host and router? RFC4861 requires the use of link-local. Using GP16 would save some complexity and overhead. 2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (see Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the source of the NS and the destination of the NA. This means those addresses can't be compressed by 6lowpan, but then again we save the Registration Address field from ARO... Is any change needed here or can we live with the proposed solution in Ticket #87? RS from joining device MAC src: IEEE IP src: LL64 SLLAO: IEEE MAC dst: Broadcast IP dst: All-routers Multicast RA from parent router MAC src: Short IP src: GP16 SLLAO: Short MAC dst: IEEE IP dst: LL64 Initial NS from joining node MAC src: IEEE IP src: GP16 (tentative) SLLAO: IEEE MAC dst: Short IP dst: GP16 (Note: parent router stores no L2 state about the tentative address, carried in the SLLAO to the 6LBR and back) Initial NA from parent router (success) MAC src: Short IP src: GP16 MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR) IP dst: GP16 (tentative) (after this point the LL64 isn't really used anymore) Refresh NS MAC src: Short IP src: GP16 SLLAO: Short MAC dst: Short IP dst: GP16 Refresh NA MAC src: Short IP src: GP16 MAC dst: Short IP dst: GP16 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
