Timothy J. Salo wrote:
Is there a requirement that 6lowpan devices be able to create arbitrary IPv6 interface identifiers? Or, was this feature simply included because it seemed like a good idea at the time?
I don't think there is any explicit requirement for nodes using arbitrary interface identifiers. Though I do think that when the format doc was drafted, it was meant to support IPv6 with a minimal set of constraining assumptions. One obvious example is support for the minimum IPv6 MTU. While its unlikely that we'll see LoWPAN nodes transmitting relatively large datagrams, the support for the full minimum IPv6 MTU was included as part of the LoWPAN format specification. Many would argue that this adds non-trivial complexity.
Should the 6lowpan format specification require that IPv6 interface identifiers be derived from 802.16.4 addresses?
I wouldn't go as far as to limit LoWPAN nodes to using only interface identifiers derived from link addresses. Rather, I would prefer an approach where DAD and link address resolution is not required for IPv6 addresses with interface identifiers that have universal scope (i.e. u/l bit set to one). DAD would still be required IPv6 addresses with local scope interface identifiers. The main advantage of this approach is that it would be possible for nodes using only global scope interface identifiers to avoid implementing any form of DAD and be completely agnostic to whatever LoWPAN DAD approach is defined. It would just need to route the packets between nodes participating in the DAD protocol. I would also go as far to say that interface identifiers derived from 802.15.4 short addresses also do not require DAD, as it is assumed that lower layers will enforce the uniqueness of the short address within the PAN. For nodes that do want to use arbitrary local scope interface identifiers (e.g. for privacy), then they would be burdened by the extra support required for DAD. This follows the "pay-as-you-go" spirit of the LoWPAN format, where only nodes that utilize more "advanced" functionality carry most of the extra costs.
-- Jonathan Hui [EMAIL PROTECTED] _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
