>From the constraint device perspective, as of now IPv6 seems to me a mandatory feature in their architecture and in particular there are good protocol sets being developed by IETF such as IPv6 over IEEE802.15.4(e), BLT, NFC and so on. IETF 6lo working group is working on those protocols and they do not deal with IPv4 any more. In the n meantime, they do not deal with Wi-Fi for the constraint device at this time.
Question here, so do we also not consider Wi-Fi interface for the IoTivity Lite device? Daniel, Hi Daniel, An example use case would be: Someone brings home two iotivity devices with IP interfaces: One constrained device (1) that can only embed a single IPv6 stack and another device (2) that has an OS that only has an active IPv4 stack (because that OS doesn?t have an IPv6 stack or it is simply disabled). The two devices will not discover each other although they both have an active IP interface. So one has to *figure out what the problem is* and then how to fix it. A) If the second device (2) is IPv6 disabled, he needs to figure out *how to enable* it (edit /etc/rc.conf, ? ) B) If the second device?s (2) OS doesn?t have an IPv6 stack, *acquire a third device* that bridges some of the functionality (convert IPv4/IPv6 adresses of the service description/discover, translate network layer security and QoS, ? ) Another use case is when I am running in the woods (no ISP infrastructure) with all my constrained battery powered wearables connected to my smart watch. Ipv6 SLAAC would be a very handy feature I would not be able to rely on if my smart watch is only IPv4 enabled ... There are probably many more use cases, but in general single protocol stack is simpler (devel, trouble shooting, bug fix, evolution, testing, setting up, ?) and technically favorable if they one functionality overlap the other. So enabling IPv6 on all iotivity devices, as part of the iotivity stack install (A) or add (develop or port) the missing IPv6 stack to the iotivity target platform (B), avoids the complexity depicted above (for the consumer and for the one that will have to develop the functional bridge). Hence my question: does iotivity have IPv4 only porting targets and if yes, which ones and how can we enable IPv6 on them (config, port/dev an IPv6 stack, ?) I hope this clarifies, Stephane. *From:* Daniel Park [mailto:soohongp at gmail.com] *Sent:* Friday, 20 March, 2015 8:33 AM *To:* Thiago Macieira *Cc:* Stephane Lejeune (stlejeun); iotivity-dev at lists.iotivity.org *Subject:* Re: [dev] IPv6 changes to IoTivity Funny discussion...afaik most OS has IPv6 stack and users can enable this interface whenever necessary. But the limitation of IPv6 deployment until now is lack of use cases even if IPv6 has lots of good features against IPv4. So what sorts of use cases are you guys considering with IPv6 mandatory in IoTivity? Daniel, Soohong Daniel Park, Ph.D. Samsung Software R&D Center 2015. 3. 18. ?? 6:52? "Thiago Macieira" <thiago.macieira at intel.com>?? ??: On Tuesday 17 March 2015 17:27:22 Stephane Lejeune wrote: > Is the issue with the IPv6 maturity in FreeBSD or just with the default > config? (Could this be enabled as part of the iotivity app/package > installation?) Just the default config. One line in /etc/rc.conf and it turned back on. The point is that disabling of IPv6 is a common occurrence, out of ignorance more than anything. That might have served a purpose in the past, when improperly configured networks were the norm. But it's turned into a chicken- and-the-egg problem: if no one turns IPv6 on, no one will find improperly configured networks. Like I said, I don't know if we can mandate IP, even for smart home. But you're right (in the other email) that this is not an IoTivity discussion. We should take this back to OIC and have the discussion there. If we can speed up IPv6 deployment, we should. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150323/acfa1dda/attachment.html>
