3 ms·

I suspect the concept of port might not have been needed had we started with IPv6. As it currently stands we allocate each physical host a /64. That would mean

I suspect the concept of port might not have been needed had we started with IPv6. As it currently stands we allocate each physical host a /64. That would mean that even if we by default used port 1 or whatever we would basically never run out of possible service end points. An IP address + port is just a way to multiplex an address. It is kinda fun to work directly at IP level and not use TCP or UDP at all. I highly recommend giving it a try.

bscphil 5y ago
> It is kinda fun to work directly at IP level and not use TCP or UDP at all. Possibly dumb question: if you're not using ports (because you're not using TCP at all), what does routing look like, in terms of this article? How does the kernel decide which traffic goes to application A and which traffic goes to application B? Or is all traffic directly visible to each application, if they aren't bound to a port? Can you bind to a specific IP, or just to an interface?
- YarickR2 5y ago
  There are many more questions besides you've ready asked; basically, who or what is providing TCP-like transmission reliability and synchronisity, who's doing ICMP , who's doing fragmenting, and why does one need to reimplement better part of the stack
- simiones 5y ago
  The normal way to "work directly at IP level" (or even below) is to use a RAW socket. The kernel will deliver all traffic matching the IP (or other things - raw sockets can essentially own the whole NIC) to your socket, and from there it's all up to you. The kernel will only look at the IP headers, the rest of the packet (TCP/UDP headers specifying ports, for example, if any) will be delivered to the raw socket. Not sure of the implementation details, but in principle the same logic about specificity of socket binding could be done by the kernel when deciding which socket to actually send the data to. Any other logic (CRC validation, packet ordering, confirming packets have been received, MSS etc.) are all disabled, you just get the raw packet as it was received on the wire, based on the IP headers (an the same happens when you send a packet on a raw socket).
thatcherc 5y ago
What would be a good search term to dive into "work directly at IP level and not use TCP or UDP at all"? Sounds interesting but not sure how to get there from just a basic familiarly with sockets.
- deleted 5y ago
  [deleted]
- kccqzy 5y ago
  SOCK_RAW
- IgorPartola 5y ago
  SOCK_RAW as others said as well as https://en.m.wikipedia.org/wiki/IP_header https://en.m.wikipedia.org/wiki/IP_header
marcan_42 5y ago
We do not allocate each physical host a /64; we (usually) allocate each network segment (broadcast domain) a /64. Of course, for p2p use cases that ends up with a single-host network. Most of that address space is used to allow for stateless autoconfig, though. It would be certainly possible to fit in port multiplexing, but you'd have to make a trade-off in increasing collision risk, depending on how you do it. Or go back to static addresses or DHCPv6.
- IgorPartola 5y ago
  Hey my $5/month VPS gets a /64. That’s not even a physical host but a virtual one.

bscphil 5y ago

> It is kinda fun to work directly at IP level and not use TCP or UDP at all. Possibly dumb question: if you're not using ports (because you're not using TCP at all), what does routing look like, in terms of this article? How does the kernel decide which traffic goes to application A and which traffic goes to application B? Or is all traffic directly visible to each application, if they aren't bound to a port? Can you bind to a specific IP, or just to an interface?

YarickR2 5y ago
There are many more questions besides you've ready asked; basically, who or what is providing TCP-like transmission reliability and synchronisity, who's doing ICMP , who's doing fragmenting, and why does one need to reimplement better part of the stack
simiones 5y ago
The normal way to "work directly at IP level" (or even below) is to use a RAW socket. The kernel will deliver all traffic matching the IP (or other things - raw sockets can essentially own the whole NIC) to your socket, and from there it's all up to you. The kernel will only look at the IP headers, the rest of the packet (TCP/UDP headers specifying ports, for example, if any) will be delivered to the raw socket. Not sure of the implementation details, but in principle the same logic about specificity of socket binding could be done by the kernel when deciding which socket to actually send the data to. Any other logic (CRC validation, packet ordering, confirming packets have been received, MSS etc.) are all disabled, you just get the raw packet as it was received on the wire, based on the IP headers (an the same happens when you send a packet on a raw socket).

thatcherc 5y ago

What would be a good search term to dive into "work directly at IP level and not use TCP or UDP at all"? Sounds interesting but not sure how to get there from just a basic familiarly with sockets.

deleted 5y ago
[deleted]
kccqzy 5y ago
SOCK_RAW
IgorPartola 5y ago
SOCK_RAW as others said as well as https://en.m.wikipedia.org/wiki/IP_header https://en.m.wikipedia.org/wiki/IP_header

marcan_42 5y ago

We do not allocate each physical host a /64; we (usually) allocate each network segment (broadcast domain) a /64. Of course, for p2p use cases that ends up with a single-host network. Most of that address space is used to allow for stateless autoconfig, though. It would be certainly possible to fit in port multiplexing, but you'd have to make a trade-off in increasing collision risk, depending on how you do it. Or go back to static addresses or DHCPv6.

IgorPartola 5y ago
Hey my $5/month VPS gets a /64. That’s not even a physical host but a virtual one.