What happens to a TCP session when the IP of a client changes?
I did a simple test of having netcat listen on a port, and connecting to that port from a client machine. I then changed the IP of the client while that nc session was open and sent some data, no data was received by server after changing the IP.
- I know they are different layers, but does TCP use IPs for part of how it distinguishes sessions?
- Does my example not work because of how the application handles it, or is this not working because of something happening at TCP/IP/Ethernet layers?
- Does this depend on the OS implementation? ( I am most interested in Linux at the moment)
My understanding is that a TCP socket consists of the IP+port number, so changing the IP breaks that connection. nc has no way of knowing the IP changed, so it continues sending data to the original IP until the session times out.
See RFC 793 (Transmission Control Protocol), specifically section 2.7:
2.7. Connection Establishment and Clearing
To identify the separate data streams that a TCP may handle, the TCP provides a port identifier. Since port identifiers are selected independently by each TCP they might not be unique. To provide for unique addresses within each TCP, we concatenate an internet address identifying the TCP with a port identifier to create a socket which will be unique throughout all networks connected together.
I suggest using Wireshark or another packet sniffer to watch the traffic for yourself and see it in action.
The previous answers will tell you, that TCP connections cannot be kept alive when the IP address changes. That was correct in 2009, when those answers were written.
However in January 2013 RFC 6824 was published, which introduces a way to keep TCP connections alive when the IP address changes. As of June 2014, it is not yet widely supported. Most notably the reference implementation exists as a patch for Linux, and iOS7 supports MPTCP by default. Wikipedia lists a total of five implementations.
The session will die. TCP sockets are dst port, dst ip, src port, src ip. If any of these change, the connection should be dropped (at least, according to Stevens).
EDIT: This is true of any RFC compliant implementation. RFC 793, section 2.7
Others have answered from the point of view of the connection being identified by the IP+Port pair. Let me talk a little about how it works in the layered structure.
TCP is a layer that provides the 'illusion' of a reliable stream on top of an unreliable packet layer (IP). For that, it has to keep account of several variables to manage the stream, and also have to provide the relevant parameters to the layer below.
So, when you ask TCP to open an stream, you give it the IP+Port of the destination. It keeps that IP number, and each time it has to transfer something, assembles an IP packet and tells the IP layer to send it to the intended machine, identified only by the original IP number.
When you changed the IP number of one machine, the other one's TCP layer doesn't have any mean to know what happened. It only sees that any IP packet sent to the original IP number is no longer answered (maybe it gets an ICMP message telling that there's no machine with that IP number). Also, it doesn't get any more packets with that IP number. Obviously the connection will be dropped after some timeout.
Even worse, it might start to get some unrelated packets from a different origin (the new IP number), but those assume a connection is already in place! Of course, the only answer that machine might get (if at all) is a RST packet to make it immediately cease and desist.
TCP sessions are identified by the ip address and port number on both sides of the connection. Changing the ip address on one side would break that session.
The (source address, source port, destination address, destination port) combination is called a socket pair. It's used by the TCP stack to identify the connection. Once it's established, TCP has no way of updating any of these.
SCTP lets endpoints change their addresses on the fly but it isn't widely deployed (not yet, anyway).