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:
<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>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>[2] The joining device does not know the GP at this point, which would either mean the parent router doesn't elide the GP16 (special case) or preferably uses MAC src: IEEE, IP src: LL64.</RCC>RA from parent router MAC src: Short IP src: GP16
SLLAO: Short
<RCC>[3] See above comment [1] re. eliding SLLA option</RCC>
<RCC>[4] I don't think this will work. I think src has to be MAC src: IEEE, IP src: LL64 and the tentative 16-bit address should be carried in the ARO</RCC>MAC dst: IEEE IP dst: LL64 Initial NS from joining node MAC src: IEEE IP src: GP16 (tentative)
<RCC>[5] See above comment [1] re. eliding SLLA option, unless of course you are using it as below to carry state all the way to 6LBR and back.</RCC>SLLAO: IEEE
<RCC>[6] Based on the RA, (comment [2] above) this should also be MAC dst: IEEE, IP dst: LL64.</RCC>.MAC dst: Short IP dst: GP16
<RCC>[7] This would be OK at this point, albeit a little imbalanced. On the other hand, if we used LL64 at this point, we would have the problem about how the joining node learns the 16-bit link layer of the parent router. LL16 would be one solution but we generally agreed that we'd try and avoid using these. Maybe there's a cleaner way?</RCC>(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
<RCC>[8] Doesn't the parent router has to have some state (tentative neighbor cache) for the joining device at this point? It needs to maintain timers, for example. If this becomes a real NCE then its IEEE address will be needed. So again maybe the SLLAO could be elided?</RCC>MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR)
<RCC>[9] See comment [4] above. Ideally this should be MAC dst: IEEE, IP dst: LL64, with the tentative 16-bit address carried in the ARO along with the status pertaining to that address.</RCC>IP dst: GP16 (tentative)
<RCC>Agreed. The joining node autoconfigures its GP16 if it's successful.</RCC>(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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
