5 ms·
There are good reasons for layer 3 addresses to be network interface specific. In fact, that is how layer 3 is supposed to work. After all, each interface is p
by rocqua 7y ago
There are good reasons for layer 3 addresses to be network interface specific.
In fact, that is how layer 3 is supposed to work. After all, each interface is potentially connected to acdifferent network. Hence, routing to those interfaces is different, and layer 3 is about routing.
The mistake instead is that TCP is not fully layer 4. They are entangled with layer 3. Specifically, a TCP socket is defined by an (IP, port) pair. Where the IP is layer 3. As such, it is fundamentally impossible to persist a TCP connection accross multiple IPs.
There is no reason for this. If instead a socket were identified as (uuid, port) then after I change my ip address, I can continue receiving packets sent to (uuid, port). And the other side will still recognize packets from me, because only my IP changed, not the connection uuid.
You'd maybe need to add some spoofing defenses, but we need those in current TCP too.
- rocqua 7y agoP.s. this rant/idea was taken from this excellent blog post: https://apenwarr.ca/log/20170810 https://apenwarr.ca/log/20170810
- throw0101a 7y agoSCTP, another Layer 4 protocol, was designed with multi-homing in mind: * https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Multi_homing https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr... I think a lot of the effort put into QUIC, HTTP/2,3,4,whatever, etc, could have been avoided if SCTP was more broadly adopted.
- imglorp 7y agoIt is a shame. Do note that SCTP is heavily used in telecom. Every network element in that world needs to be redundant, along with the multiple routes to get to each of those redundant elements. SCTP helps hide some of that from the application layers. https://en.wikipedia.org/wiki/SIGTRAN https://en.wikipedia.org/wiki/SIGTRAN
- throw0101a 7y agoYes, I think that SS7 architecture was used as some design criteria when it came SCTP. Just about everything in the telco world has (at least) an A- and a B-side for HA.
- bogomipz 7y agoI believe the issue with SCTP is/was broken middle boxes though and not an aversion to SCTP as a protocol no?
- deleted 7y ago[deleted]
- paulsutter 7y agoYou might want to be careful lecturing John Nagle on TCP ;) (intended in the most lighthearted way possible!)
- alxlaz 7y agoWatching people try to teach John Nagle how to do networking is half the reason why I like reading the HN forums :-). I'm not one to defer to authority too easily, but it's my experience that, when someone with enough experience says something that sounds out of this world, it's a good idea to think about it for a bit.
- Animats 7y agoThere are arguments for unique IP addresses for interfaces. I'm just amused at the addition of yet another layer of address indirection.
- alxlaz 7y agoCertainly, I'm convinced that neither you, nor the fine folks at BSD were/are clueless about these things. I think it's important to know why these decisions were made, and what trade-offs were involved, so that I don't get dogmatic about them.
- rocqua 7y agoI had no idea. This kind of stuff is why I like HN. I have no idea who the real 'celebrities' are. It feels like most of the discussion is on a pretty even ground.
- deleted 7y ago[deleted]
- despair3435 7y agoYou are basically adding an address to TCP (the UUID) that names the host... Moreover, what happens if the connection fails during setup? A lot of edge cases here.
- rocqua 7y agoI am also removing the remote ip address from a socket. Hence, if you change your ip, you can just send from your new ip, include the same connection uuid, and I will still receive. You'd also need to know how to send data back. This could be done in many ways. Biggest thing is to deal with really easy hijacks where you tell a server that your victim 's data should instead be sent to you. This is harder with the current TCP.
- wyldfire 7y ago> Specifically, a TCP socket is defined by an (IP, port) pair It's actually the quadruple (local ip, port, rem ip, port) in the steady state.
- MuffinFlavored 7y agoDoes that mean `IP` by itself it a layer 3 term, but (ip, port) is a layer 4 term? Example: layer 3 knows nothing about ports?
- zAy0LfpBZLC8mAC 7y ago> Example: layer 3 knows nothing about ports? correct
- rocqua 7y agoTotally right, I misremembered the concept. That makes some of the explanations much easier too.
- dstaesse 7y agoAny architecture that needs two different identifiers for the same thing is very likely in need of some revision.
- rocqua 7y agoBut a connection (TCP) and a reachable/routable entity are not the same thing. Just like a phone number isn't the same thing as an SMS thread.
- dstaesse 7y agoSorry, my response was rather cryptic. I was more referring to the interface having both an L2 and L3 address. From an academic perspective, I agree with OP that assigning the L3 address to the interface probably causes more problems than it solves. MPTCP provides workaround over L4 to what is essentially an L3 problem. But it would take a huge architectural change to go back to assigning addresses to L3 hosts. Just to provide my 2 cents on the issue: There are a lot of things at play... Rekhter's law ("Addressing can follow topology or topology can follow addressing. Choose one.") doesn't combine well with the fact that it's not desirable to have end-hosts participate in routing updates. When these two are taken together, they have implications on scalability of any routing solution, especially in the cases of end-host mobility and multihoming. When the "topology follows addressing" (like TCP/IP), the constraint of not wanting to advertise the end-host address (as someone mentioned, no ISP will accept your /32 on BGP) assigning the end-host a different address per attached network is the simplest solution. This indeed boils down to the assigning L3 addresses to the interface. The TCP connection problem can be handled by tunnels (as is the case in Mobile IP or LISP) but tunnels are rather expensive since the tunnel endpoint in the network has to maintain al lot of state. In the case of "addressing follows topology", changes in topology, when taking the constraint of not advertising end-hosts via routing, requires address renumbering of the network elements. So, when taken as a pure L3 problem, it boils down to choosing which problem to solve: constantly tracking the end-hosts, or constantly renumbering the network. The latter, when used in combination with recursive network layering, shows quite some promise. It requires less addresses, but I know from experience that it's not the easiest idea to sell. MPTCP provides a pragmatic workaround on top of L4 that doesn't require tunnels. It's a shame that it's not completely transparent to the applications (it requires explicit code changes to enable).I agree with a lot of the concerns of getting this upstream in the kernel. I tried to play around with it a couple of times, but the distribution as a full kernel was a bit of a roadblock. Would be easier if it was distributed as a kernel patch. And it seems perfectly doable to implement it in user space, that might further speed up adoption. Anyway, take care :)
- codewiz 7y agoYou're essentially describing QUIC.