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) > 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. 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. > > 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
