Subject: [6lowpan] Question on 6loWPAN ND and HC interaction

From: Kerry Lynn <[email-masked]>
Date: Tue, 8 Mar 2011 17:16:06 -0500

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-