Timothy J. Salo wrote:
Support for the minimum IPv6 MTU enables 6lowpan devices to interoperate with traditional IPv6 hosts. Ensuring interoperability between 6lowpan devices and non-6lowpan IPv6 hosts seems to be a pretty important objective.
True. Though I don't think any LoWPAN network will ever operate as a transit network for more capable networks. Thus, leaving interoperability in LoWPAN networks to imply that protocols and applications will actually process such large packets. I suspect very few, if any, will make use of the full minimum IPv6 MTU. The one exception is ICMP, but do we really expect LoWPAN nodes to generate ICMP errors to maximum sized packets?
Arbitrary link-local interface identifiers, on the other hand, do not appear to provide any benefits that are nearly so fundamental. Perhaps they are useful in some circumstances (although I haven't heard what these circumstances might be) but they don't appear to be really important, much less facilitate interoperability.
There are a class of applications that may require support for privacy extensions. One of the major issues with RFID is privacy. Like RFID, current or future LoWPAN application may associate a LoWPAN node with an item or person, making tracking possible without the users knowledge or consent. It's not that I'm a privacy advocate, but privacy tends to be a concern that slows or inhibits technology adoption and shouldn't be treated lightly. If we do decide to adopt the approach you suggest, then we should either provide a solution that satisfies privacy advocates or understand that we will face adoption hurdles in those applications.
I think that the loss of functionality that results from restricting 6lowpan interface identifiers to 64-bit and 16-bit 802.15.4 addresses is minimal (and might even be null), but the benefits are substantial. I recommend we make this change to the 6lowpan format document.
I agree with you that tying LoWPAN interface identifiers to 802.15.4 addresses removes the need for both address resolution and DAD. If we are comfortable with dropping privacy extensions, then it will definitely lower the resource requirements of LoWPAN implementations. If privacy wasn't an issue, then I'm all for it. The key question is whether the lowered resource requirements outweigh the benefits of privacy extensions. While we could get concrete numbers for the former, the latter is a bit more difficult to quantify. Where on the tipping point do people think we lie? Are there other applications or use cases where arbitrary interface identifiers are desirable?
FYI, there is some work within LoWPAN to minimize ND costs in LoWPAN networks. Though I haven't had a chance to look at it in detail yet. http://tools.ietf.org/wg/6lowpan/draft-chakrabarti-6lowpan-ipv6-nd-03.txt
-- Jonathan Hui [EMAIL PROTECTED] _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
