the 64 most-significant bits of a sHA-1 hash calculated from the quence number of the connection initial sequence numbers Migrate SYN segment, S, the connection key, K, and the request open send:(nothing) R=SHAl(Ni, Ni, K, S, D) SYN segments may now correctly arrive on a bound port not in the Listen state. They should be processed only if they contain the Migrate option as specified above. Otherwise, they should be treated as specified in [31]. Upon receipt of a syn packet with the Migrate option, a TCP stack that supports migration attempts to locate the connection on the receiving port with the corresponding (SYN. R token. The token values for each connection were precomputed at d: SYN. ACK (SYN SENT connection establishment, reducing the search to a hash lookup If the token is valid meaning an established connection on this address, porn) pair has the same token, and the reg No is greater than any previously received migrate request, the fixed host then computes R SHAl(Ni, N,, K, S, I)as described above, and YESTABLISHED compares it with the value of the request in the Migrate SYN. If the comparison fails, or the token was invalid a rSt is sent to the If, on the other hand, the token and request are valid, but the regno is smaller than a previously received request, the sYN is assumed to be out-of-order and silently discarded. If the reqNo is identical (MIGRATE. WAIT ---- to the most recently received migrate request this SYN is assumed to be a duplicate of the most recently received SYN, and processed cordingly. Figure 4: Partial TCP state transition diagram with Migrate transitions(adapted from 33, figure 1812D) Otherwise, the destination address and port associated with the matching connection should be updated to reflect the source of the in MIGRATE-WAIT for over a specified period of time. We recom Migrate SYN, and a SYNACk packet generated, with the ACK mend using the 2MSL ([31]specifies a Maximum Ifetime field set to the last received contiguous byte of data, and the con- (MSL)as 2 minutes, but common implementatio Ise values nection placed in the SYN-RCVD state. Upon receipt of an ACk, of I minute or 30 seconds for MSL [33])period he connection continues as before for the TIme-wait state 4.5 MIGRATE WAIT state any segments received while in the MIgrate WAIt state should be processed as in the ESTaBLiSHEd state, except that no ACKs This section assumes that the reader is familiar with the TCP state should be generated The only way a connection is removed from machine and transitions [33, Chapter 18] the migrate-WaIT state is on the receipt of a Migrate SYN with Special processing of TCP RST messages is required with migrate- the same fashion as if it were in the established state when it able connections, as a mobile host's old IP address may be reas- received the SYN signed before it has issued a migrate request to the fixed host. Figure 4 shows the modified TCP state transition diagram for connections The MIgrate-Walt state prevents connections from being in that have successfully negotiated the Migrate-Permitted option. The advertently dropped if the address allocation policy on the mobile receipt of a RST that passes the standard sequence number checks hosts previous network reassigns the mobile hosts old IP address n the ESTABLISHEd state does not immediately terminate the before the mobile host has reconnected at a new location and had connection, as specified in [31]. Instead, the connection is placed chance to migrate the connection. It also prevents the continued into a new MIGRATE_WAIT state.(A similar, but far less likely sit retransmission of data to an unreachable host uation can occur if the fixed host is in the FIN- WAITI state-the This passive approach to disconnection discovery is preferred over application on the fixed host has closed the connection, but there remains data in the connection buffer to be transmitted. For sim- an active. mobile-initiated squelch message because any such mes- age could be lost. Furthermore, a mobile host may not have suf plicity, these additional state transitions are not shown in figure 4.) ficient(if any) notice of address reassignment to issue such mes- Connections in the migrate-WaIT state function as if they sages. As an added performance enhancement, however, mobile hosts aware of an impending migration may themselves emit or ACKs), and are moved to CLOSEd if they remain special RST to the peer, which will force the connection into MI- Migrated connections will generally originate from the same GRATE-WAIT, preventing additional packet transmission until the port as before. However, if the mobile host is behind a NAT,it And any guaranteed-reliable transmission mechanism could possible the connection has been mapped to a different port. take unbounded timethe 64 most-significant bits of a SHA-1 hash calculated from the sequence number of the connection initial sequence numbers N, Migrate SYN segment, S, the connection key, K, and the request sequence number, I. R = SHA1(Ni, Nj , K, S, I) SYN segments may now correctly arrive on a bound port not in the LISTEN state. They should be processed only if they contain the Migrate option as specified above. Otherwise, they should be treated as specified in [31]. Upon receipt of a SYN packet with the Migrate option, a TCP stack that supports migration attempts to locate the connection on the receiving port with the corresponding token. The token values for each connection were precomputed at connection establishment, reducing the search to a hash lookup. If the token is valid, meaning an established connection on this
address, port pair has the same token, and the reqNo is greater than any previously received migrate request, the fixed host then computes R = SHA1(Ni, Nj , K, S, I) as described above, and compares it with the value of the request in the Migrate SYN. If the comparison fails, or the token was invalid, a RST is sent to the address and port issuing the Migrate SYN, and the SYN ignored. If, on the other hand, the token and request are valid, but the reqNo is smaller than a previously received request, the SYN is assumed to be out-of-order and silently discarded. If the reqNo is identical to the most recently received migrate request this SYN is assumed to be a duplicate of the most recently received SYN, and processed accordingly. Otherwise, the destination address and port5 associated with the matching connection should be updated to reflect the source of the Migrate SYN, and a SYN/ACK packet generated, with the ACK field set to the last received contiguous byte of data, and the con￾nection placed in the SYN RCVD state. Upon receipt of an ACK, the connection continues as before. 4.5 MIGRATE WAIT state This section assumes that the reader is familiar with the TCP state machine and transitions [33, Chapter 18]. Special processing of TCP RST messages is required with migrate￾able connections, as a mobile host’s old IP address may be reas￾signed before it has issued a migrate request to the fixed host. Figure 4 shows the modified TCP state transition diagram for connections that have successfully negotiated the Migrate-Permitted option. The receipt of a RST that passes the standard sequence number checks in the ESTABLISHED state does not immediately terminate the connection, as specified in [31]. Instead, the connection is placed into a new MIGRATE WAIT state. (A similar, but far less likely sit￾uation can occur if the fixed host is in the FIN WAIT1 state—the application on the fixed host has closed the connection, but there remains data in the connection buffer to be transmitted. For sim￾plicity, these additional state transitions are not shown in figure 4.) Connections in the MIGRATE WAIT state function as if they were in the ESTABLISHED state, except that they do not emit any seg￾ments (data or ACKs), and are moved to CLOSED if they remain 5 Migrated connections will generally originate from the same port as before. However, if the mobile host is behind a NAT, it is possible the connection has been mapped to a different port. CLOSED LISTEN SYN RCVD SYN SENT ESTABLISHED MIGRATE WAIT 2MSL timeout appl: close or timeout appl: passive open send: nothing appl: active open send: SYN recv: SYN send: SYN, ACK recv: ACK recv:SYN,ACK;send:ACK appl: send data send: SYN recv: RST recv: SYN; send: SYN, ACK recv: SYN migrate T,R send: SYN, ACK appl: migrate send: SYN migrate T,R recv: RST recv: SYN migrate T,R send: SYN, ACK Figure 4: Partial TCP state transition diagram with Migrate transitions (adapted from [33, figure 18.12]) in MIGRATE WAIT for over a specified period of time. We recom￾mend using the 2MSL ([31] specifies a Maximum Segment Lifetime (MSL) as 2 minutes, but common implementations also use values of 1 minute or 30 seconds for MSL [33]) period of time specified for the TIME WAIT state. Any segments received while in the MIGRATE WAIT state should be processed as in the ESTABLISHED state, except that no ACKs should be generated. The only way a connection is removed from the MIGRATE WAIT state is on the receipt of a Migrate SYN with the corresponding connection key. The connection then responds in the same fashion as if it were in the ESTABLISHED state when it received the SYN. The MIGRATE WAIT state prevents connections from being in￾advertently dropped if the address allocation policy on the mobile host’s previous network reassigns the mobile host’s old IP address before the mobile host has reconnected at a new location and had a chance to migrate the connection. It also prevents the continued retransmission of data to an unreachable host. This passive approach to disconnection discovery is preferred over an active, mobile-initiated squelch message because any such mes￾sage could be lost.6 Furthermore, a mobile host may not have suf- ficient (if any) notice of address reassignment to issue such mes￾sages. As an added performance enhancement, however, mobile hosts aware of an impending migration may themselves emit a special RST to the peer, which will force the connection into MI￾GRATE WAIT, preventing additional packet transmission until the 6 And any guaranteed-reliable transmission mechanism could take unbounded time.