> Look, if you believe in the sanctity of the network layers, sure. I don't.
And herein lies the issue. A layer 3 protocol can never be anything else. Unless you're writing some sort of dissector or have another use case. This isn't a "belief", it is what it is. But even when said layer 3 protocol rides a higher layer, let's say IPv4 on UDP, it's still a layer 3 protocol that is layer 4 payload until decapsulated and processed as such. What you describe is encapsulation and decapsulation, this isn't new or interesting and in most cases it's generally a bad idea just looking at it from a perspective of overhead.
I'm also not sure your pseudo code is legit considering you're binding a socket that's already been defined and the socket() is the real question mark here that differentiates IPv4 and IPv6. I think you may have glossed over the fact that some platforms don't support binding v4 on v6 sockets, while some do. Regardless your example is neither universally correct or ideal in many cases.
The problem is that the layer models break down above IP/level 3. Imagine you defined IPv77 which was identical to IPv4 but included port info. So this is equivalent to UDP/IP. What layer protocol is that?
Or say you managed to run UDP directly on top of ETH. Because if you don’t need routing across different networks this is perfectly possible. A protocol is just two interfaces: where it interacts with the lower level protocol and higher level protocol. It is all encapsulation, that’s my point. This is why the layer model is mostly not really used when discussing these things.
So back to the example or UDP being implemented as a layer 3 protocol: when using it, you wouldn’t actually know the difference, would you?
As for my code example, you are right. It should be like so:
s = socket(TCP, IPv6);
bind(s, “localhost”, 5555);
c = accept(s);
Note that past the call to socket() and storing the remote address, I don’t care whether TCP here runs on carrier pigeons or paper planes. Heck, I could treat the addresses as completely abstract strings if I want and never know that they are the names of two pigeons. TCP abstracts that away from me. I don’t worry about things like packet delivery, congestion, routing, etc. When I use the TCP interface, I can ignore most of the underlying details. When I implement it, it’s the opposite: I care a whole lot because I need a different implementation for every underlying protocol.
I'm sorry but you're making things up at this point. Feel free to read the first paragraph of RFC 767 [0], most notably the last sentence:
"This User Datagram Protocol (UDP) is defined to make available a
datagram mode of packet-switched computer communication in the
environment of an interconnected set of computer networks. This
protocol assumes that the Internet Protocol (IP) is used as the
underlying protocol."
As for your code, again, you make a lot of assumptions. As I mentioned before opening a socket as IPv6 does not guarantee backwards compatibility with IPv4 addressing. So, again, my point is that you do have to care about the version of IP. In your original example you conveniently skipped the socket call and claimed "See, I can just consume any IP!". Now you're just glossing over the glaring assumption, as I stated in the last post, that not every platform guarantees backward compatibility with IPv4 on an IPv6 socket.
Also... Your pigeon analogy makes zero sense to the argument you're attempting to make because it's highly irrelevant to the protocols and how they actually work in computing environments.
If you care to read the OSI layer 3 protocols state that they are concerned with deciding which physical path data will take. UDP and TCP have no routing facilities I'm aware of because port numbers don't define path. So, again, UDP is not a layer 3 protocol just because you feel like it is.
I understand and agree with you that IPv4 and IPv6 are OSI layer 3 protocols and UDP and TCP are layer 4. At the same time, the OSI model above the fourth layer has been widely considered mostly useless, and some have called into question the whole thing. Yes, RFCs exist that point to what you are saying. But again, I can 100% implement TCP on top of UDP without ever thinking about IP packets. And no, I don't care which layer 3 protocol TCP is using underneath, so long as I can initialize the socket properly and get the local/remote addresses. Take a look at a complete example of a TCP server: https://www.cs.cmu.edu/afs/cs/academic/class/15213-f99/www/c...
Where in there do you see anything about ARP or ND? Or hops vs TTL? Or IP packet header sizes? Or header checksums? Or priority flags? You can take this code, add a couple of macros for getting the correct AF_ value and structs and the code would be 100% abstracted away from any mention of the underlying layer 3 protocol.
Google has been developing transport layer protocols on top of UDP for years now. Why? Because getting a new layer 4 protocol to work is nearly impossible. Yet, if we all agreed that it was something we wanted, they could easily do so, which makes these new protocols functionally transport layer. If it helps you sleep at night, you can say that they are temporarily exiled to be encapsulated in UDP, but really they'll return some day to their proper place in the OSI model.
And herein lies the issue. A layer 3 protocol can never be anything else. Unless you're writing some sort of dissector or have another use case. This isn't a "belief", it is what it is. But even when said layer 3 protocol rides a higher layer, let's say IPv4 on UDP, it's still a layer 3 protocol that is layer 4 payload until decapsulated and processed as such. What you describe is encapsulation and decapsulation, this isn't new or interesting and in most cases it's generally a bad idea just looking at it from a perspective of overhead.
I'm also not sure your pseudo code is legit considering you're binding a socket that's already been defined and the socket() is the real question mark here that differentiates IPv4 and IPv6. I think you may have glossed over the fact that some platforms don't support binding v4 on v6 sockets, while some do. Regardless your example is neither universally correct or ideal in many cases.