Hi Jonathan >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?
[Pascal] Who knows? One might use a disseminated sensor network as access for some signaling, or limited upstream when no other medium is available. If we do not need that assumption, let's not make it... >> 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. > [Pascal] Agreed. I understand that we decide which formats do not need DAD (those described in the draft) and decide that those are ever DADed, or are optimistically DADed. But that does not secure the address ownership like SeND does. I understand that a device could roll its 16-bit short address if it really wanted to for privacy reasons, correct? If so, what I'd suggest is that when the u/l bit is set to local, we force the 16 bits at a given place, say the last bits of the address, and leave the rest up to the device. That way, DAD is not necessary and the specification is still open for the device to do what it likes with the rest of the address, such as a CGA that we would define over 48 bits instead of 64. >> 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.t xt [Pascal] It seems fair to believe that the coordinators and FFDs will end up proxying ND and some routing for the RFDs, which this draft proposes. At the moment, the IPv6 routers do not talk 6LowPAN and there's a gateway that interconnects say, Ethernet and 802.15.4. Should there be a specific 6LowPAN ND support in the router? And can we define that functionality so that it can be proxyed/snooped in the gateway? Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
