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
