Below > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Friday, July 15, 2016 7:46 AM > To: ???(Uze Choi) <uzchoi at samsung.com> > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] OcResource->getHost() api gives a tricky host address in > Android > > 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.
Not necessarily. The sentence about requiring which interface to send on if it's not the default interface is of course true. But it could be specified either in the URL or passed in APIs in conjunction with it. So for example if the URL is always passed along with an interface or local address, then it does not need a zone ID in the URL itself. Indeed, prior to RFC 6874, that was the only choice and it worked, but RFC 6874 was created since some middleware didn't surface the zone ID or interface up to the app and so the information was lost. Another nit is that, strictly speaking, the link local address does not require specifying which _interface_ to send on, it minimally requires specifying which _link_ to send on. Interface is not necessary but is of course sufficient since interface is more granular than link (you may have multiple interfaces attached to the same link). Some OS's (e.g., Windows) provide more flexibility whereas others (Linux?) are more limited and only support specifying the interface, which means if you have two interfaces on the same link... well that OS can't express that concept. > 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. That's not entirely true either. Some OS's _do_ permit it with IPv4 when you use IPv4-mapped addresses on an AF_INET6 socket. The fact that iotivity uses AF_INET sockets rather than dual-family sockets is a current limitation of iotivity. Of course if the intent is to not support IPv4 in production anyway then this is not a problem. > 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. Fine, although using another multicast scope (other than global) still requires use of a zone id or interface with the scoped multicast address. Dave > > -- > 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
