> -----Original Message----- > From: Thiago Macieira [mailto:thiago.macieira at intel.com] > Sent: Friday, July 15, 2016 1:59 PM > To: Dave Thaler <dthaler at microsoft.com> > Cc: ???(Uze Choi) <uzchoi at samsung.com>; 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 18:15:04 PDT Dave Thaler wrote: > > > 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. > > Hi Dave > > Indeed, the information could be present elsewhere and, in fact, *is*. The > OCDevAddr structure, which contains the details about the endpoint, contain > the interface index field. The Connectivity Abstraction code will handle the > index correctly, even for IPv4. > > But you touched the important point above: some APIs had no way to > surface this information. That is the case here: we have a function that > returns a URI. If that function continues to exist, then I say we keep the > ZoneID. > Conversely, if we want to remove the ZoneID, we should also remove the > API that returns the URI of a resource. > > Alternatively, we should fix the API to return an "oic://dev-id-goes-here/" > URI, instead of a CoAP URI. In fact, I think this is what we should do, > urgently. > (And I've been saying so for over a year)
I think we're agreed on all of the above. > > 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. > > Indeed, for a *link* local address, the Zone ID should specify the link. > However, the entire IPv6 API as defined by the RFCs call this "ifindex" -- the > interface index. Which API are you referring to? RFC 6874 never uses the term "ifindex" or "interface index". RFC 3542 and RFC 3493 do use ifindex, but never to refer to a zone ID or anything that can appear with a %. It only uses it with APIs that want to explicitly reference an interface. RFC 3493 uses the term "scope id" (e.g., sin6_scope_id) to refer to a zone id. RFC 4007 is the primary RFC that explains the relationship between zone id, interface index, etc., and is the main one relevant to this conversation. > > It is very hard for everyone involved (OS, application, etc.) to determine if > two interfaces are connected to the same link. We don't even try. It's part of OS configuration (outside the scope of iotivity), iotivity shouldn't be trying itself. > > > > 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. > > A limitation that I don't see going away. From experience with cross-platform > UDP development, dual-stack doesn't work very well, especially not > multicasting (sending or receiving). Using two single-stack sockets is more > reliable. > > The problem for IPv4 is minimised due to the extremely limited use of link- > local IPv4. Almost all situations where IPv4 is involved requires a DHCP > server > to be running. > > > > 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. > > On multicast addresses, yes, though the IPv6 API does not allow for it (or > ignores it). This is solved by either using the CMSG ancillary data or, like > IoTivity does, by setting IP_MULTICAST_IF or IPV6_MULTICAST_IF via > setsockopt. > > However, the big advantage is that if the devices in the network have non- > link-local addresses assigned, they will reply using it and hopefully the > system's routing tables will take over from this point on. If they only have > link-local, they will reply using that and we're no worse than we are now. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center
