On 07/19/10 09:58 AM, Robert Cragie wrote:
Hi Zach,

The main issue I have is premature (and strictly illegal) use of the
tentative MAC short/ IP GP16 address. Additional comments below,
bracketed bu <RCC></RCC>.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>


On 12/07/2010 3:27 PM, Zach Shelby wrote:
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

<RCC>[1] I think it is worth exploring the ability to elide the SLLAO.
It's not strictly needed as the link-layer (MAC) address can be obtained
from MAC header. RFC4861 does not mandate it either.</RCC>

RFC 4861 doesn't require it because the router can always multicast a RA or multicast a NS. We want to avoid that for 6lowpan-nd, thus the router must always be able to determine the link-layer address of the host. The only generic way we have to do that is to require the SLLAO. (Anything else would be some form of header compression that can omit a SLLAO when the source MAC address is the same as in the MAC header.)

   Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to