Note: This RFC has been obsoleted by RFC 9293
Source of RFC: Legacy
Area Assignment: tsv
Errata ID: 3305
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-31
Held for Document Update by: Martin Stiemerling
Date Held: 2015-03-24
Section 3.9 says:
p70 SEGMENT ARRIVES Otherwise, first check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. There are four cases for the acceptability test for an incoming segment: Segment Receive Test Length Window ------- ------- ------------------------------------------- 0 0 SEG.SEQ = RCV.NXT 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 0 not acceptable >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
It should say:
Added my Martin Stiemerling (TSV AD): A document update will address this problem and the TCPM working is expected to find a solution.
Not sure how to correct it systemmatically, so I just present the problem.
If in SYN-RECEIVED state, and received a SYN-ACK packet with no data as:
SEG.SEQ = IRS
SEG.ACK = ISS + 1
However in SYN-RECEIVED state, RCV.NXT = IRS + 1, which means the SYN-ACK packet will fail on the second test above. The SYN-ACK packet will be dropped and a ACK packet is sent in reply. As a result, we lost the SYN part, but it is fine because we've already received SYN packet once. However, we also lost the ACK part which is supposed to be the ACK of our SYN. Thus we will never reach the ESTABLISH state.