> It seems that there is good enough support for 'ff:fe' (ff:fe00 due to the way this is put in the middle of two 24-bit fields.)
> As discussed before, 6lowpan-hc can no longer simply point to Section 6 of > RFC 4944 since the PAN ID is no longer used. As far as I can see, HC does not have to change 4944 at all. HC with the results of this discussion simply is more efficient if the 4944 conditional "if no PAN ID is known, 16 zero bits may be used" is true. So I see no need for either: > I see two approaches: > > 1) 6lowpan-hc updates Section 6 of RFC 4944 to indicate how an IID is > generated from a 802.15.4 short address. > > 2) 6lowpan-hc becomes self contained by saying how to expand a 802.15.4 short > address into an IID (note the slightly different choice of wording). An > update to RFC 4944 would be left for another draft (presumably the ND draft). Instead, I would say: Note: This form of compression only addresses the case where instead of a PAN ID, 16 zero bits are used according to section 6 of RFC 4944. This case appears to be the common implementation practice for RFC 4944. If, however, a PAN ID is used, only the case SAM=01/DAM=01 can be used to obtain some compression. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
