Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?
SLIRP is a clever tool that turns network traffic (raw IP frames on one side) into connect(2), read, write etc system calls on the other side. eg. If it sees a virtual machine is making a connection by sending a TCP SYN packet, it will on one side turn that into a connect(2) system call, and on the other side send back the appropriate TCP packets to complete the connection. It also does ARP, DNS, etc. If you think of a kernel as something that turns socket system calls into packets, then SLIRP is the opposite.
SLIRP is mainly useful when you don't have (or don't want) root permissions to send raw packets. I may be one of the few people here to have used SLIRP back in the early 90s for its original purpose: You have dial up access to a shared SunOS terminal login, how do you turn that into a full network connection for your local Linux PC? SLIRP (+ expect, SLIP and some scripting) solved this exact problem.
> I may be one of the few people here to have used SLIRP back in the early 90s for its original purpose
While I was still in college in 1999 -- I figured out how to pair a local ppp device with SLIRP on the Sun machines we had shell access on over ssh, enabling me to bounce internet access through our CS network, which got access to a few things we couldn't directly access from our dorms.
Later in my career I learned about the TCP-over-TCP meltdown effect, which explained why I had to restart it every once in a while.
Very difficult, it's not portable so it would be basically a rewrite. I read that similar APIs are present in FreeBSD, but at least it's POSIX-based so that does not really say anything about the complexity of a Windows port.
Anyhow, the presentation mentioned above explains which Linux extensions are needed.
Because you want containers to be able to allocate ports that are already in use on your host. Or at least you don't want that to be a source of errors.
On top of that, you usually want to isolate the container workload with an observable network abstraction instead of granting it full (albeit non-root) access to host network facilities (including sockets).
