On Monday 16 March 2015 18:17:30 Light, John J wrote: > We have completed the first phase of changes to support IPv6 in Iotivity. > They will soon be pushed to the ca-ipv6 branch (branch of > connectivity-abstraction branch).
Hi John Thanks for posting this and for the effort in getting IPv6 up and running. I recommend that everyone working with IoTivity read through at least the first parts of the document, as they point out a few things that are not obvious if you're not used to IPv6. > * It supports both IPv6 and IPv4 sending and receiving for both the > Server and Client. > > * It only involves the Ethernet adapter in CA, but it does so without > regard to interfaces, so it should work on Wi-Fi as well. Indeed, which brings back the discussion about interface detection and selection and whether the distinction between Ethernet and WiFi makes sense at all. Your work proves that it doesn't, so I'd like to see the distinction removed from the connectivity abstraction branch. As we discussed, interface selection is probably better. I can contribute the code for detection and enumeration on Linux and OS X/BSDs (it's the same code) and if you push me, I could contribute for Windows too. With Arduino I imagine there's no detection -- you know what's in your system. But even on a per-interface selection, there's the question of whether one wants to use IPv4 or IPv6. As we discussed last week, I don't think there is much reason to allow this selection -- IoTivity should just use both for discovery if they are available. As for non-discovery, I think we need have an opaque class representing "a device" or "a service", not the URI. The URI should not be exposed in the API except for debugging and for showing to the user in a UI. Internally, IoTivity keeps track of the multiple addresses that the remote service can take, as the same device might be reached over IPv6, IPv4 and over Bluetooth. > * It skipped several other variations: > > o No DTLS support. > > o No Single Thread support. > > o No network interface support. > > o Only IPv6 Link Local multicast and addressing. IPv6 global unicast addressing is identical to link-local addressing. As for non-link-local multicast, I don't think we're there yet, so it shouldn't be a problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
