> On 10. Jun 2017, at 19:04, Tommy Pauly <tpa...@apple.com> wrote: > > > >> On Jun 9, 2017, at 4:55 PM, Michael Tuexen >> <michael.tue...@lurchi.franken.de> wrote: >> >>> On 9. Jun 2017, at 12:16, Tommy Pauly <tpa...@apple.com> wrote: >>> >>> HI Michael, >>> >>>> On Jun 8, 2017, at 7:13 PM, Michael Tuexen >>>> <michael.tue...@lurchi.franken.de> wrote: >>>> >>>> On 8. Jun 2017, at 15:50, Tommy Pauly <tpa...@apple.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I wanted to point the TAPS group to some of the work that we announced >>>>> this week at WWDC that relates to the Post-Sockets API effort. You can >>>>> see a video of the session here (relevant section at ~13:50), along with >>>>> the slides: >>>>> >>>>> https://developer.apple.com/videos/play/wwdc2017/707 >>>>> >>>>> In the current betas of iOS 11, we have introduced “User-Space >>>>> Networking” beneath our networking APIs. The transport and IP protocols >>>>> are now being co-located with the security and application protocols in >>>>> the process, meaning that we are no longer using sockets within the >>>>> implementation of these APIs. This shift allows us to reduce the context >>>>> switches between protocol layers, and could potentially open >>>>> opportunities for the kind of stack flexibility and customization that >>>>> the TAPS group is looking at. We’re excited to be making some first steps >>>>> into a truly “Post-Sockets” world! >>>> Hi Tommy, >>>> >>>> so this means I can run my own TCP stack and my own IPv6 stack in my >>>> application, if I understood that correctly. >>>> How is the port number space managed between the different applications? >>>> I'm wondering how the demultiplexing is >>>> done? >>>> Can I also use the API for a transport protocol supporting the port number >>>> concept, but not being UDP or TCP, >>>> like SCTP or UDP-Lite or DCCP or whatever might come up in the future? >>> >>> The ability to run your own stack is not currently exposed; the user-space >>> stack for TCP, etc, is part of the system library. However, this >>> architecture does open up the possibility to extend or modify this in the >>> future. If people have specific ways that they think this would be most >>> useful to extend and modify, please let me know. >>> >>> The kernel is still responsible for managing the port namespace between >>> applications, and demultiplexing incoming packets to the correct processes. >>> Since that is part of the kernel, the port demultiplexing still needs to >>> understand where to look for port numbers in known protocols. It seems like >>> for the use-case you’re mentioning for new protocols, it could be useful to >>> allow that logic to be extended, or ‘learn’ new protocols. This isn’t >>> something we’re doing now, but definitely an interesting idea! >> Leaving the port multiplexing / demultiplexing at the kernel makes a lot of >> sense. Are you doing something >> like: >> * open a TCP socket. >> * bind it. >> * set a socket option that you want to send/recv raw TCP packets >> That way you could pass the packets up and down to a userland stack and could >> coexist with a kernel stack. (Assuming that the kernel/userland boundary >> still uses sockets). >> However, that doesn't fit the figure shown a WWDC, where you had the IP >> stack and the TCP >> as part of the userland stack. So does the application the route selection, >> interface >> selection? > > The figure shown on the slides shows the TCP/IP stack in the process-space > since the actual formation of the TCP and IP headers is done there, along > with all of the TCP state machine logic and IP fragment reassembly, etc. The > kernel/user boundary is not using sockets at all for these connections, but > instead is using a new mechanism for memory-mapping to the kernel. The > application can influence the route and interface selection with preferences > (no-cellular, for example), which are combined with the kernel policies and > routing tables, as in the Policy Context in the Post-Sockets draft. This > provides a binding for ports and interface, which is used for subsequent > traffic flows and is validated by the kernel on egress. Effectively, this > means that the IP part of the stack in user space can be thinner, since the > routing information is more fixed and doesn’t require more routing lookups as > is typically done in a kernel implementation. Ahh, I see. Similar to the multistack approach described in https://www.ietf.org/proceedings/95/slides/slides-95-tsvarea-2.pdf > >> >> Is there any documentation available for the interface between kernel land >> and userland? > > No, not yet at this time. This is the initial roll-out of the architecture, > so it’s still early days. > >> Is the same architecture available on Mac OS X? > > We do not currently expose the same functionality on macOS. As mentioned in > the talk, this is in part due to the fact that it is not compatible with > network kernel extensions, which are common on macOS, but will be deprecated > at some point in the future. I see. Thanks a lot for your explanations. They really help to understand what Apple is providing!
Best regards Michael > > Thanks, > Tommy > >> >> Best regards >> Michael >>> >>> Thanks, >>> Tommy >>> >>>> >>>> Best regards >>>> Michael >>>>> >>>>> Thanks, >>>>> Tommy >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
