Greetings, I wonder if I might sanity check my understanding of how 6loWPAN hc-15, nd-15, and RFC 4944 all fit together.
I ran a diff of hc-06 and hc-15 and I see that somewhere along the way a new section was inserted in draft-ietf-6lowpan-hc at 3.2.2. I thought the intent was to clarify the language of RFC 4944 section 6, but on a closer reading they appear to be at odds. In particular, RFC 4944 MAY potentially include the 16_bit_PAN in the upper 16 bits of the 802.15.4 short address derived IID. That section in the RFC also says: "A different MAC address set manually or by software MAY be used to derive the Interface Identifier. If such a MAC address is used, its global uniqueness property should be reflected in the value of the U/L bit." But it doesn't specifically **disallow** the 0xFFFE pattern in the middle of those alternatives (meaning implementations may not correctly determine whether a locally assigned IID can be compressed or not). ** The bottom line is that the compressor and decompressor MUST implement the same procedure for mapping short addresses if the IID is to be properly re-constructed. ** Now hc-15 section 3.2.2 is intended specifically to clarify the SAM=3 and DAM=3 modes, but I see that a lot of text has been added to hc-15 section 3.1.1 for the other SAM and DAM modes as well. Let me next interject what draft-ietf-6lowpan-nd-15 section 4.2 says: "A context may be a prefix of any length or an address (/128), and up to 16 6LoWPAN Context options may be carried in an Router Advertisement message." Now, paraphrasing hc-15 section 3.1.1, it seems the decompressor MUST use all of the (0 to 128) valid context bits as the prefix, any bits not covered by the prefix are taken from the IID as reconstructed according to hc-15 3.2.2, and if there are any gaps (say the prefix was /16) then those missing bits will be set to zero. IOW, the correct way to decompress a short address seems to be to re-construct it (according to sect 3.2.2) in a field of 128 zeros, then overwrite the high order bits with the context. Is this interpretation correct? I hope that in real situations, the context length will only assume reasonable values. When using the 16-bit short address, it doesn't seem to make any sense to use contexts longer than /112 since there's no guarantee that short addresses will be unique in their (less than 16) low-order bits in a given prefix. This question is partly inspired by a thread on the Contiki list regarding checksum errors in WireShark. I think that WireShark is currently copying Context/128 and overwriting with the IID, which seems to be incorrect for context > 64? -K-
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
