All, While waiting for responses to my proposal for IPv6 Adapter changes, I started implementing the minimal change solution.
I immediately ran into a problem that I hadn't anticipated. The current IP Adapter makes a socket for each interface. I had subconsciously translated that into IPv6 doubling the number of sockets. Unfortunately, while an interface can have only one IPv4 address (and therefore socket), an interface can have an indefinite number of IPv6 addresses. Creating sockets for each of an indefinite number of interface addresses is problematical in itself, but the real issue is that the current approach requires each send message to be sent on the "right" socket. The current code bothers to find the "right" IPv4 socket (a complicated process involving comparison of addresses under net masks) before it uses it. That process is burdensome as it stands, but it would become ridiculous if it were applied to the IPv6 addresses as well. I hadn't looked at this issue before because when I built and tested the ca-ipv6 patch, I implemented my new approach (knowing that the Ethernet and WiFi adapters were being merged). IP sockets weren't meant to be used this way, and the further we go along this path, the uglier and more burdensome the code will become. I will provide my proposed solution. I've implemented similar code many times, most recently in ca-ipv6 patch. It is the lowest risk and fastest way to get to IPv6, and provides us with a path to further growth of the IP Adapter. John Light Intel OTC OIC Development From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Light, John J Sent: Wednesday, June 17, 2015 11:20 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] Proposal for IP Adapter and request for feedback All, I recently completed the patch titled "IP address plumbing changes to support IPv6". Now I am preparing to provide the IPv6 capability itself. This work will primarily affect the IP Adapter since the data paths it requires were handled in the previous patch. There are two ways to approach the remaining IPv6 work, and I want a feedback on how this work should be accomplished. I can * Make a minimal change to the existing IP Adapter code, or * Simplify the existing code so that adding IPv6 doesn't make it more complicated. Here I will spell out the technical issues involved with the two approaches. Here is a quick summary of the existing IP Adapter code issues that might change. 1. Create two sockets for every interface that can support IP addressing, one each for secure and non-secure connections. These sockets come and go as network interfaces appear and disappear. 2. A thread dedicated to continually scanning the network interfaces to maintain a separate list of interfaces for use by the IP Adapter. This happens every two seconds. 3. The IP Adapter currently allocates non-multicast ports from the range 6298-6307, using a loop to test them for availability. 4. After each message is received, the source address of the message is tested for being on the same subnet as the interface on which the message was received. This test involves determining the subnet mask of the associated subnet and comparing the source and destination addresses in the subnet mask bits. 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. b. If the application asks only for IPv6 communication, only Sockets ABCD are needed. c. If the application asks only for secure communications, only Sockets ABDF are needed. d. Sockets CDEF would be bound to INADDR_ANY so they can handle IP traffic from any interface, even as interfaces come and go. 2. The network monitor will no longer run on its own thread, and it will be called only when an multicast is requested. a. When a multicast is sent, the network monitor will fetch a list of IP interfaces, and the multicast will be sent to that list. b. This eliminates the 1-2 second latency between enabling an interface and being able to use it. This will become more important as 6LoWPAN is adopted. As soon as the interface is created, it can be used by IoTivity. c. The use of INADDR_ANY in Sockets CDEF eliminates any further need for the network monitor. d. The network monitor no longer needs to call back into the IP Adapter to update a list, so all the code related to that callback can be eliminated. 3. The IP Adapter will no longer allocate ports other than the CoAP multicast ports. a. The ports 6298-6207 are in the range assigned by IANA, and we have no right to use them. While ports 6298 and 6299 are currently unassigned by IANA, ports 6300, 6301, and 6306 are assigned, and our use of them is a violation of network standards. 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. c. The proposal will implement that simple method, providing standards compliance and simplifying the code. 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. b. This test consumes considerable resources, involving finding and using the subnet mask, and requires considerable code. c. In any case, there is no equivalent code for IPv6, so nothing equivalent will be provided. After these changes, the IP Adapter will be much smaller and easier to maintain. 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. 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. John Light Intel OTC OIC Development -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150618/52f83f28/attachment.html>
