We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shuji-bonji/rfcxml-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
> 🤖 This file was auto-generated by rfcxml-mcp's `generate_checklist` tool.
>
> Generated: 2026-01-18
> Tool: @shuji-bonji/rfcxml-mcp
> Source: RFCXML (high accuracy)
---
# RFC 9293 実装チェックリスト
**Transmission Control Protocol (TCP)**
生成日時: 2026-01-18T16:38:42.505Z
## 必須要件 (MUST / REQUIRED / SHALL)
- [ ] Sentences using "" are labeled as "MUST-X" with X being
a numeric identifier enabling the requirement to be located easily when
referenced from. (section-2.1)
- [ ] A TCP receiverprocess the RST and URG fields of all incoming segments, even when the receive window is zero (MUST-66). (section-3.4)
- [ ] A TCP implementationuse the above type of "clock" for clock-driven selection of initial sequence numbers (MUST-8), andgenerate its initial sequence numbers with the expression: (section-3.4.1)
- [ ] F()be computable from the outside (MUST-9), or an attacker could still guess at sequence numbers from the ISN used for some other connection. (section-3.4.1)
- [ ] A TCP implementationsupport simultaneous open attempts (MUST-10). (section-3.5)
- [ ] Note that a TCP implementationkeep track of whether a
connection has reached SYN-RECEIVED state as the result of a
passive OPEN or an active OPEN (MUST-11). (section-3.5)
- [ ] If the local
TCP connection is closed by the remote side due to a FIN or
RST received from the remote side, then the local
applicationbe informed whether it closed normally or
was aborted (MUST-12). (section-3.6)
- [ ] When a connection is closed actively, itlinger in the
TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime) (MUST-13). (section-3.6.1)
- [ ] TCP endpointsimplement both sending and receiving the MSS Option (MUST-14). (section-3.7.1)
- [ ] If an MSS Option is not received at connection setup, TCP implementationsassume a default send MSS of 536 (576 - 40) for IPv4 or 1220 (1280 - 60) for IPv6 (MUST-15). (section-3.7.1)
- [ ] The maximum size of a segment that a TCP endpoint really sends, the
"effective send MSS",be the smaller (MUST-16) of the send MSS
(that reflects the available reassembly buffer size at the
remote host, the EMTU_R) and the largest transmission size permitted by the IP layer (EMTU_S): (section-3.7.1)
- [ ] where MMS_R is the maximum size for a transport-layer
message that can be received (and reassembled at the IP layer) (MUST-67). (section-3.7.1)
- [ ] However, therebe a way for an application to disable the Nagle algorithm on an individual connection (MUST-17). (section-3.7.4)
- [ ] The RTObe computed according to the
algorithm in, including Karn's algorithm for taking RTT samples (MUST-18). (section-3.8.1)
- [ ] A TCP endpointimplement the basic congestion control algorithms slow start, congestion avoidance, and exponential backoff of RTO to avoid creating congestion collapse conditions (MUST-19). (section-3.8.2)
- [ ] The
following procedurebe used to handle excessive
retransmissions of data segments (MUST-20): (section-3.8.3)
- [ ] In particular, R2 for a SYN segmentbe set large enough to provide retransmission of the segment
for at least 3 minutes (MUST-23). (section-3.8.3)
- [ ] An application(MUST-21) be able to set the value for R2 for
a particular connection. For example, an interactive
application might set R2 to "infinity", giving the user
control over when to disconnect. (section-3.8.3)
- [ ] If keep-alives are included, the applicationbe able to turn
them on or off for each TCP connection (MUST-24), and theydefault to off (MUST-25). (section-3.8.4)
- [ ] If keep-alives are included, the applicationbe able to turn
them on or off for each TCP connection (MUST-24), and theydefault to off (MUST-25). (section-3.8.4)
- [ ] Keep-alive packetsonly be sent when no sent data is outstanding,
and no data or
acknowledgment packets have been received for the
connection within an interval (MUST-26). (section-3.8.4)
- [ ] This intervalbe
configurable (MUST-27) anddefault to no less than two hours (MUST-28). (section-3.8.4)
- [ ] This intervalbe
configurable (MUST-27) anddefault to no less than two hours (MUST-28). (section-3.8.4)
- [ ] Consequently, if a keep-alive mechanism is implemented itinterpret failure to respond to any specific probe
as a dead connection (MUST-29). (section-3.8.4)
- [ ] However, TCP implementationsstill include support for the urgent mechanism (MUST-30). (section-3.8.5)
- [ ] A TCP implementationsupport a sequence of urgent data of any length (MUST-31). (section-3.8.5)
- [ ] The urgent pointerpoint to the sequence number of the octet following the urgent data (MUST-62). (section-3.8.5)
- [ ] A TCP implementation(MUST-32) inform the application layer asynchronously whenever it receives an urgent pointer and there was previously no pending urgent data, or whenever the urgent pointer advances in the data stream. (section-3.8.5)
- [ ] The TCP implementation(MUST-33) provide a way for the application to learn how much urgent data remains to be read from the connection, or at least to determine whether more urgent data remains to be read. (section-3.8.5)
- [ ] However, a sending TCP peerbe robust against window shrinking, which may cause the
"usable window" (see) to become negative (MUST-34). (section-3.8.6)
- [ ] If the window shrinks to zero, the TCP implementationprobe it in the standard way (described below) (MUST-35). (section-3.8.6)
- [ ] Probing of zero (offered) windowsbe supported (MUST-36). (section-3.8.6.1)
- [ ] As long as the receiving TCP peer continues to
send acknowledgments in response to the probe segments, the
sending TCP peerallow the connection to stay open (MUST-37). (section-3.8.6.1)
- [ ] A TCP implementationinclude a SWS avoidance algorithm in the sender (MUST-38). (section-3.8.6.2.1)
- [ ] A TCP implementationinclude a SWS avoidance algorithm in the receiver (MUST-39). (section-3.8.6.2.2)
- [ ] A TCP endpointimplement a delayed ACK (SHLD-18), but an ACK
should not be excessively delayed; in particular, the delaybe
less than 0.5 seconds (MUST-40). (section-3.8.6.3)
- [ ] Every passive OPEN call either creates a new connection
record in LISTEN state, or it returns an error; itaffect any previously created connection record (MUST-41). (section-3.9.1.1)
- [ ] A TCP implementation that supports multiple concurrent connectionsprovide
an OPEN call that will functionally allow an application to
LISTEN on a port while a connection block with the same
local port is in SYN-SENT or SYN-RECEIVED state (MUST-42). (section-3.9.1.1)
- [ ] The optional "local IP address" parameterbe supported
to allow the specification of the local IP address (MUST-43). (section-3.9.1.1)
- [ ] If an application on a multihomed host does not specify the
local IP address when actively opening a TCP connection,
then the TCP implementationask the IP layer to select a local IP
address before sending the (first) SYN (MUST-44). (section-3.9.1.1)
- [ ] At all other times, a previous segment has either been sent
or received on this connection, and TCP implementationsuse the same
local address that was used in those previous
segments (MUST-45). (section-3.9.1.1)
- [ ] A TCP implementationreject as an error a local OPEN
call for an invalid remote IP address (e.g., a broadcast or
multicast address) (MUST-46). (section-3.9.1.1)
- [ ] If PUSH flags are not
implemented, then the sending TCP peer: (1)buffer data indefinitely (MUST-60), and
(2)set the PSH bit in the last buffered segment (i. (section-3.9.1.2)
- [ ] If PUSH flags are not
implemented, then the sending TCP peer: (1)buffer data indefinitely (MUST-60), and
(2)set the PSH bit in the last buffered segment (i.e., when there is no
more queued data to be sent) (MUST-61). (section-3.9.1.2)
- [ ] Therebe a mechanism for reporting soft TCP error
conditions to the application (MUST-47). (section-3.9.1.8)
- [ ] The application layerbe able to specify the Differentiated Services field
for segments that are sent on a connection (MUST-48). (section-3.9.1.9)
- [ ] When received options are passed up to TCP from the IP
layer, a TCP implementationignore options that it does not understand (MUST-50). (section-3.9.2)
- [ ] An applicationbe able to specify a source route when
it actively opens a TCP connection (MUST-51), and thistake
precedence over a source route received in a datagram (MUST-52). (section-3.9.2.1)
- [ ] An applicationbe able to specify a source route when
it actively opens a TCP connection (MUST-51), and thistake
precedence over a source route received in a datagram (MUST-52). (section-3.9.2.1)
- [ ] When a TCP connection is OPENed passively and a packet
arrives with a completed IP Source Route Option (containing
a return route), TCP implementationssave the return route and use it
for all segments sent on this connection (MUST-53). (section-3.9.2.1)
- [ ] TCP implementationsact on an ICMP error message passed up from the IP
layer, directing it to the connection that created the
error (MUST-54). (section-3.9.2.2)
- [ ] 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 STATESegments 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 are
processed. In general, the processing of received segmentsbe
implemented to aggregate ACK segments whenever possible (MUST-58).
For example, if the TCP endpoint is processing a series of queued
segments, itprocess them all before sending any ACK
segments (MUST-59). There are four cases for the acceptability test for an incoming
segment:Segment Acceptability TestsSegment Length Receive Window Test0 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 In implementing sequence number validation as described here, please note. If the RCV.WND is zero, no segments will be acceptable, but
special allowance should be made to accept valid ACKs, URGs, and
RSTs. If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so drop
the segment and return): <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the acknowledgment, drop the unacceptable segment
and return. Note that for the TIME-WAIT state, there is an improved algorithm
described infor handling incoming SYN
segments that utilizes timestamps rather than relying on
the sequence number check described here. When the improved
algorithm is implemented, the logic above is not applicable for
incoming SYN segments with Timestamp Options, received on a
connection in the TIME-WAIT state. In the following it is assumed that the segment is the idealized
segment that begins at RCV.NXT and does not exceed the window.
One could tailor actual segments to fit this assumption by
trimming off any portions that lie outside the window (including
SYN and FIN) and only processing further if the segment then
begins at RCV.NXT. Segments with higher beginning sequence
numbersbe held for later processing (SHLD-31). (section-3.10.7.4)
- [ ] 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 STATESegments 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 are
processed. In general, the processing of received segmentsbe
implemented to aggregate ACK segments whenever possible (MUST-58).
For example, if the TCP endpoint is processing a series of queued
segments, itprocess them all before sending any ACK
segments (MUST-59). There are four cases for the acceptability test for an incoming
segment:Segment Acceptability TestsSegment Length Receive Window Test0 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 In implementing sequence number validation as described here, please note. If the RCV.WND is zero, no segments will be acceptable, but
special allowance should be made to accept valid ACKs, URGs, and
RSTs. If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so drop
the segment and return): <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> After sending the acknowledgment, drop the unacceptable segment
and return. Note that for the TIME-WAIT state, there is an improved algorithm
described infor handling incoming SYN
segments that utilizes timestamps rather than relying on
the sequence number check described here. When the improved
algorithm is implemented, the logic above is not applicable for
incoming SYN segments with Timestamp Options, received on a
connection in the TIME-WAIT state. In the following it is assumed that the segment is the idealized
segment that begins at RCV.NXT and does not exceed the window.
One could tailor actual segments to fit this assumption by
trimming off any portions that lie outside the window (including
SYN and FIN) and only processing further if the segment then
begins at RCV.NXT. Segments with higher beginning sequence
numbersbe held for later processing (SHLD-31). (section-3.10.7.4)
## 任意要件 (MAY / OPTIONAL)
- [ ] Similarly, sentences using "" are labeled with
"SHLD-X", "" with "MAY-X", and
"" with "REC-X". (section-2.1)
- [ ] A hostimplement a "half-duplex" TCP close sequence, so
that an application that has called CLOSE cannot continue to
read data from the connection (MAY-1). (section-3.6.1)
- [ ] However, itaccept a new SYN from the remote TCP endpoint to
reopen the connection directly from TIME-WAIT state (MAY-2), if it: (section-3.6.1)
- [ ] TCP implementationssend an MSS Option in
every SYN segment when its receive MSS differs from the
default 536 for IPv4 or 1220 for IPv6 (SHLD-5), andsend it always (MAY-3). (section-3.7.1)
- [ ] RFC 1122 allows that if a retransmitted packet is identical to the original
packet (which implies not only that the data boundaries have not changed, but
also that none of the headers have changed), then the same IPv4 Identification
fieldbe used (see Sectionof RFC 1122) (MAY-4). (section-3.8.1)
- [ ] An endpointimplement such alternative algorithms provided that the algorithms are conformant with the TCP specifications from the IETF Standards Track as described in RFC 2914, RFC 5033, and RFC 8961(MAY-18). (section-3.8.2)
- [ ] Implementersinclude "keep-alives" in their TCP implementations
(MAY-5), although this practice is not universally accepted. (section-3.8.4)
- [ ] An implementationsend a keep-alive segment with no
data (SHLD-12); however, itbe configurable to send a keep-alive
segment containing one garbage octet (MAY-6), for compatibility with
erroneous TCP implementations. (section-3.8.4)
- [ ] The senderalso
retransmit old data beyond SND.UNA+SND.WND (MAY-7), buttime out the connection if data beyond the right window edge
is not acknowledged (SHLD-17). (section-3.8.6)
- [ ] A TCP implementationkeep its offered receive window closed
indefinitely (MAY-8). (section-3.8.6.1)
- [ ] A TCP endpointimplement PUSH flags on SEND calls (MAY-15). (section-3.9.1.2)
- [ ] When an application issues a series of
SEND calls without setting the PUSH flag, the TCP implementationaggregate the data
internally without sending it (MAY-16). (section-3.9.1.2)
- [ ] A TCP receiverpass a received PSH bit to the application layer via the
PUSH flag in the interface (MAY-17), but it is not required (this was clarified in RFC
1122, Section). (section-3.9.1.3)
- [ ] The FLUSH callbe implemented (MAY-14). (section-3.9.1.7)
- [ ] TCP implementationspass the most recently received Differentiated Services field up to the
application (MAY-9). (section-3.9.1.9)
- [ ] A TCP implementationsupport the Timestamp (MAY-10) and Record Route (MAY-11) Options. (section-3.9.2)
- [ ] A TCP implementationsupport the Timestamp (MAY-10) and Record Route (MAY-11) Options. (section-3.9.2)
- [ ] Fifth, check the ACK field:if the ACK bit is off, drop the segment and return if the ACK bit is on,RFC 5961describes a potential blind data injection attack, and mitigation that implementationschoose to include (MAY-12). TCP stacks that implement RFC 5961add an input check that the ACK value is acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) =< SEG.ACK =< SND.NXT). All incoming segments whose ACK value doesn't satisfy the above conditionbe discarded and an ACK sent back. The new state variable MAX.SND.WND is defined as the largest window that the local sender has ever received from its peer (subject to window scaling) or may be hard-coded to a maximum permissible window value. When the ACK value is acceptable, the per-state processing below applies: SYN-RECEIVED STATEIf SND.UNA < SEG.ACK =< SND.NXT, then enter ESTABLISHED state
and continue processing with the variables below set to:SND.WND <- SEG.WND SND.WL1 <- SEG.SEQ SND.WL2 <- SEG.ACK If the segment acknowledgment is not acceptable, form a
reset segment<SEQ=SEG.ACK><CTL=RST> and send it. ESTABLISHED STATEIf SND.UNA < SEG.ACK =< SND.NXT, then set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue that are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers that have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response). If the ACK is a duplicate
(SEG.ACK =< SND.UNA), it can be ignored. If the ACK acks
something not yet sent (SEG.ACK > SND.NXT), then send an ACK,
drop the segment, and return. If SND.UNA =< SEG.ACK =< SND.NXT, the send window should be
updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK. Note that SND.WND is an offset from SND.UNA, that SND.WL1
records the sequence number of the last segment used to update
SND.WND, and that SND.WL2 records the acknowledgment number of
the last segment used to update SND.WND. The check here
prevents using old segments to update the window. FIN-WAIT-1 STATEIn addition to the processing for the ESTABLISHED state, if
the FIN segment is now acknowledged, then enter FIN-WAIT-2 and continue
processing in that state. FIN-WAIT-2 STATEIn addition to the processing for the ESTABLISHED state, if
the retransmission queue is empty, the user's CLOSE can be
acknowledged ("ok") but do not delete the TCB. CLOSE-WAIT STATEDo the same processing as for the ESTABLISHED state. CLOSING STATEIn addition to the processing for the ESTABLISHED state, if
the ACK acknowledges our FIN, then enter the TIME-WAIT state;
otherwise, ignore the segment. LAST-ACK STATEThe only thing that can arrive in this state is an
acknowledgment of our FIN. If our FIN is now acknowledged,
delete the TCB, enter the CLOSED state, and return. TIME-WAIT STATEThe only thing that can arrive in this state is a
retransmission of the remote FIN. Acknowledge it, and restart
the 2 MSL timeout. (section-3.10.7.4)
- [ ] Seventh, process the segment text:ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATEOnce in the ESTABLISHED state, it is possible to deliver segment
data to user RECEIVE buffers. Data from segments can be moved
into buffers until either the buffer is full or the segment is
empty. If the segment empties and carries a PUSH flag, then
the user is informed, when the buffer is returned, that a PUSH
has been received. When the TCP endpoint takes responsibility for delivering the data to the
user, it must also acknowledge the receipt of the data. Once the TCP endpoint takes responsibility for the data, it advances
RCV.NXT over the data accepted, and adjusts RCV.WND as
appropriate to the current buffer availability. The total of
RCV.NXT and RCV.WND should not be reduced. A TCP implementationsend an ACK segment acknowledging RCV.NXT when a
valid segment arrives that is in the window but not at the
left window edge (MAY-13). Please note the window management suggestions in. Send an acknowledgment of the form: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> This acknowledgment should be piggybacked on a segment being
transmitted if possible without incurring undue delay. CLOSE-WAIT STATE CLOSING STATE LAST-ACK STATE TIME-WAIT STATEThis should not occur since a FIN has been received from the
remote side. Ignore the segment text. (section-3.10.7.4)