On sexta-feira, 15 de julho de 2016 13:56:19 PDT ???(Uze Choi) wrote: > I'd like to mention not standard but IoTivity API. > Considering use case, interface information is not required. > e.g) compare the resource with previously connected or check the > duplication and create resource object without discovery step by putting > address. Moreover, IPv4 and other transport do not provide this information > either, which mean eventually user should handle it case by case. If > transport information is required, we can use the other API which provides > it.
Hi Uze, Your argument is incorrect. This information is required because of the way that IPv6 works. If your device has two or more interfaces, IPv6 *requires* that you specify which network interface you want to send on for a link-local address if it's not the default interface. If you strip that information, you will lose connectivity to the other device. Moreover, you will be able to compare it to itself later, since that device will remain accessible only on that given interface. It won't change later. It will only change if the interface name changes, but that's something out-of- scope for us and has been fixed by systemd-udev for at least three years (if your system doesn't implement the fix, it's the integrator's fault). Finally, you can't apply this to IPv4 because IPv4 doesn't permit it. The fact that IPv4 lacks a given functionality is not a reason to not use it in IPv6. IPv6 is simply better and more capable than IPv4. All of the above said, I'd like to argue that we should simply stop using link-local addresses as much as possible. That's why we should be using the realm-local multicast scope in IPv6 instead of the link-local one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
