"I don't think you can, since you can't join an IPv4 multicast group on an AF_INET6 socket. That means you need to have a pair of pairs of sockets for multicast."
The two multicast sockets (A and B) won't be bound at all (or bound to INADDR_ANY). Multicast messages will be sent on unicast sockets, C or E, respectively, so the responder will reply to the right socket. For instance, an IPv6 multicast will be sent on Socket C, so the response will be returned to Socket C. If the connection is to be secured, the conversation will move to Sockets D and F. I don't think we need any additional sockets. Also, as you mentioned, we will assume the lack of IPV6_V6ONLY = 1 in our sockets, in order to handle the general case simply. I agree that we may need to use IP_PKTINFO / IP_RECVIF at some point to choose interfaces. (That's not what the current interface testing does.) John Light Intel OTC OIC Development -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Wednesday, June 17, 2015 1:57 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Proposal for IP Adapter and request for feedback Hi John Thanks for the post. Just a few details that we didn't discuss when we talked yesterday: On Wednesday 17 June 2015 18:20:12 Light, John J wrote: > Here is how I would simplify the IP Adapter, relating to the above > issues issues. > > 1. A total of six sockets will be created at IoTivity startup. They > will remain unchanged until shutdown. > > a. These are the sockets. > > i. > Socket A: non-secure, multicast listen for IPv6 and IPv4. > > ii. Socket > B: secure, multicast listen for IPv6 and IPv4. > > iii. Socket > C: non-secure, unicast send/recv, multicast send for IPv6. > > iv. Socket > D: secure, unicast send/recv, multicast send for IPv6. > > v. Socket > E: non-secure, unicast send/recv, multicast send for IPv4. > > vi. Socket > F: secure, unicast send/recv, multicast send for IPv4. After we talked, it occurred to me: can you receive IPv4 multicasts on an IPv6 socket? I don't think you can, since you can't join an IPv4 multicast group on an AF_INET6 socket. That means you need to have a pair of pairs of sockets for multicast. Sending and receiving unicast can be done in the same socket on Dual Stack implementations, but like we talked yesterday, to accommodate for independent Dual Stack implementations (no IPV6_V6ONLY = 0), we should design the code to work in IPV6_V6ONLY = 1. So you may need 8 sockets, not 6. > b. The socket mechanism provides a simple method of assigning ports, > and it's much simpler. Simply request port 0, and the network will supply > a port which is not used by anyone else. That's the correct way to do it, indeed. > 4. The testing of subnet masks after receiving messages will be > eliminated. > > a. This test accomplishes nothing. Reception of a packet by recvfrom > is ensured by the network layer to include all and only messages to > that port. Agreed. The OS can already be configured to drop martian packets before even being received by the application, often even before the firewall. On Linux, see sysctl net.ipv4.conf.$IF.rp_filter > I will say a few words about why I am qualified to make such drastic > changes. I have been programming sockets in both Linux and Windows > since about 1990. I wrote a connectivity abstraction for a commercial > product > (PC-Xware) in the early 90s, and contributed to the first two > WinSockathons at about that time. Since then I have used sockets for > research projects at Intel. And just to add to that: John and I have been discussing this implementation for some time and I've been doing IPv6 since 1999. > Please indicate your preference for the direction I should go on the > IoTivity-Dev mailing list by Monday. I will push a patch for IPv6 > next week. If the consensus is for my proposal, I will deliver a patch > for it next week. If not, I will do the obvious patch to the current IP > Adapter. > If I don't make these changes as part of IPv6. I will submit the > remainder of the changes in this proposal as a series of patches over > the next few months. Just one more thing: we discussed the "firewall" problem. When the adapter scanner finds a new interface, it needs to call back to the user to find out if the user wants IoTivity to send and receive in that interface. If using the 6- or 8-socket solution, you need to use IP_PKTINFO / IP_RECVIF to get the ID of the interface that the packet was received on and decide whether to discard it or not. Alternatively, we can punt this problem to the system firewall. -- 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
