3 ms·

> I am not conflating them. But consider that you can run IP over IP. What level protocol is IP in this case? What about IP/IP/IP/IP? Is IP on the left level 7?

> I am not conflating them. But consider that you can run IP over IP. What level protocol is IP in this case? What about IP/IP/IP/IP? Is IP on the left level 7? There is only one L3 to the local stack at any given point in packet flow. Sure, you can run IP in IP but the parent, or root, IP stack is the one in control until the encapsulated IP is deencapsulated and moved up. Encapsulating a L3 protocol doesn't magically make it something else as it pertains to OSI. Finally TCP isn't an abstraction and it has rules based on it's version. So, yes, if you're writing network applications at the TCP level you very much do care about ND or ARP.

IgorPartola 7y ago
Look, if you believe in the sanctity of the network layers, sure. I don't. In a TCP/UDP scenario, to me UDP is the packet layer because that's how I'm using it. If I am doing TCP/IPv6/UDP/IPv4, which I have actually done in real life when IPv6 access required that you set up a tunnel over UDP/IPv4, I am free to think of IPv6 as the level 3 protocol because that's functionally what it is. As for ARP vs ND, when I do bind('localhost', 5555, 'TCP') I really don't care whether localhost is IPv6 or IPv4 or pidgeons throwing rocks with notes.
- windexh8er 7y ago
  > 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.
  - IgorPartola 7y ago
    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.
    - windexh8er 7y ago
      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. [0] https://tools.ietf.org/html/rfc768 https://tools.ietf.org/html/rfc768

IgorPartola 7y ago

Look, if you believe in the sanctity of the network layers, sure. I don't. In a TCP/UDP scenario, to me UDP is the packet layer because that's how I'm using it. If I am doing TCP/IPv6/UDP/IPv4, which I have actually done in real life when IPv6 access required that you set up a tunnel over UDP/IPv4, I am free to think of IPv6 as the level 3 protocol because that's functionally what it is. As for ARP vs ND, when I do bind('localhost', 5555, 'TCP') I really don't care whether localhost is IPv6 or IPv4 or pidgeons throwing rocks with notes.

windexh8er 7y ago
> 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.
- IgorPartola 7y ago
  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.
  - windexh8er 7y ago
    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. [0] https://tools.ietf.org/html/rfc768 https://tools.ietf.org/html/rfc768