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.

  1. I know they are different layers, but does TCP use IPs for part of how it distinguishes sessions?
  2. 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?
  3. Does this depend on the OS implementation? ( I am most interested in Linux at the moment)
  • Removed 'linux' tag because this isn't OS-specific. – romandas Sep 3 '09 at 13:21
  • Added nix tag, because I would still like know how the sockets work – Kyle Brandt Sep 3 '09 at 13:33
  • Although, the socket details might be to big of a topic for that, I will go look in my Stevens books (TCPIP Illustrated and APUE) for more details – Kyle Brandt Sep 3 '09 at 13:46
  • Re: tags - Right, but nothing about your question (other than the mention of your interest in *nix sockets) nor the answer is *nix-specific. They are TCP/IP-specific. – romandas Sep 3 '09 at 19:02

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.

| improve this answer | |
  • +1 aggred if the client changes there IP the application on the server dosen't have anyway of knowing about that change. – Mark Davidson Sep 3 '09 at 13:16
  • 3
    Ah, I see the TCP+IP now, from RFC 793 "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" – Kyle Brandt Sep 3 '09 at 13:19
  • Good job -- I was just editing that reference in when you commented. – romandas Sep 3 '09 at 13:22

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.

| improve this answer | |

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

| improve this answer | |
  • When you say stevens, is that in TCP/IP Illustrated? If it is vol 1, can you let me know where? I have a copy at home :-) – Kyle Brandt Sep 3 '09 at 13:35
  • My copy is at home too, but this is certainly in there. – romandas Sep 3 '09 at 14:03
  • My copy is also at home, but it's in the first chapter about TCP. Chapter 19 I think – Cian Sep 3 '09 at 14:05
  • In Stevens': p. 226, paragraph 1 and 2 describe the ip-port pairing. I can't seem to find any reference to where the connection "should be dropped".. mainly because I can't find any instance where he mentions any of those things changing within an active connection. I find it rather interesting that, without keepalive timers, TCP is supposed to maintain an idle, open connection indefinitely (see chap. 23). I really need to go back and read this tome again. – romandas Sep 4 '09 at 1:45

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.

| improve this answer | |

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.

| improve this answer | |

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).

| improve this answer | |
  • Thanks Gerald, 'Socket Pair' is a good starting point for me to research that aspect of my question. – Kyle Brandt Sep 4 '09 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.