Following up: would NETransparentProxyProvider be appropriate to intercept TCP/UDP flows and redirect them to a custom transport? And for traffic not covered by NETransparentProxyProvider (ICMP, ARP, etc.), would declaring the device via IOEthernetController creates conflicts with the proxy interception, or can both coexist cleanly?

Why? What are you actually trying to do here? More specifically, what do you expect to actually be interacting with your user space component? If you go down this route, then you're telling the system "here is a network interface you should use" and the system is absolutely going to try and use it. At that point you're going to be forced to try and find ways to keep the system "away" from the interface you just created... since the point of an network interface is to provide an generic endpoint the system can interact with. Maybe there's a reason you want to do this, but if your ultimate goal is just to communicate with your device, then this seems like an awful lot of work to avoid using IOUserClient. Keep in mind that IOUserClient is sufficiently fast and powerful that there's always a way to do basically ANYTHING you want. Sorry for the confusion. The goal is not just to communicate with the device from our app. We want to expose a network accelerator to macOS — a device that handles the full network stack from Layer 2 (Ethernet) to Layer 4 (TCP/UDP), offloading those layers from the macOS network stack entirely, similar to a SmartNIC. In that context, what would be the right DriverKit approach to expose such a device to macOS?

Thank you for your swift answer. I filled an ER on the Feedback assistant n° FB23032382. All the best.

Thank you for your prompt answer. I'll follow up if I have other questions on that topic.

I can't find your FB, is it still actual? Is the new macOS 26 has this feature?